Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Alias (5735)

Alias
  (email not shown publicly)
http://ali.as/
+ -

  Journal: DBD::SQLite 1.31 releasing next week and may break your code on 2010.09.08 21:11

Journal by Alias on 2010.09.08 21:11
User Journal

After 6 or 7 months (mainly waiting around for the next "recommended upgrade instruction" from the SQLite project) the latest DBD::SQLite release should occur next week.

You can get the 1.30_06 release candidate from the CPAN, or from the following URL if your mirror hasn't synced yet.

http://svn.ali.as/cpan/releases/DBD-SQLite-1.30_06.tar.gz

Read More 0 comments

+ -

  Journal: Should Module::Install move to explicit plugin declaration? on 2010.09.05 21:26

Journal by Alias on 2010.09.05 21:26
User Journal

Module::Install has been through a long period of gradual stability over the last year, without any really dramatic improvements to the grammar or APIs.

With the more urgent "it doesn't work with blah" stuff mostly solved now, one of the big remaining issues is around error clarity and excessive magic.

For example, some random author that is trying to checkout a Catalyst project needs:

1. To have Module::Install installed.
2. To have Module::Install::Catalyst installed.

Read More 6 comments
Comments: 6
+ -

  Comment: Re:Porting Rakudo to .NET (Score 1) on 2010.08.20 9:35

It's been my experience that Microsoft doesn't necessarily work that way, except in a limited fashion.

What they are both interested and capable the most in is in the area of "Interop" as they call it. Contained, concrete steps they can take to remove roadblock from the path of otherwise active technologies, and to make them work better on Windows.

Some of these are financial, like the CPAN Testing Lab and their (rumored) free code signing certs. Some are toolchain related like CoApp.

The issues where they are the only ones that can fix a problem are the ones they are the most interested in. I can bring it up, but I suspect you won't see much interest.

Read More 7 comments
Comments: 7
+ -

  Comment: You know what I'd do? (Score 1) on 2010.08.20 9:25

by Alias on 2010.08.20 9:25 (#72329)
Attached to: Will parrot be the last one standing?

Fork the JVM and call it something different.

Read More 6 comments
Comments: 6
+ -

  Journal: Speaking at Microsoft TechEd - Any issues you want raised? on 2010.08.19 22:20

Journal by Alias on 2010.08.19 22:20
User Journal

Next week I will at Microsoft's TechEd Australia event, courtesy of Microsoft Australia and Microsoft Open Source Labs.

More specifically, I'll be attending the Open Source mini-conf and discussion day on Tuesday, and presenting in the Community Presentations to Microsoft session on the current state of Perl and Windows on Wednesday.

Read More 7 comments
Comments: 7
+ -

  Journal: Class::XSAccessor now even faster'er on 2010.08.15 22:04

Journal by Alias on 2010.08.15 22:04
User Journal

The new 1.07 release of Class::XSAccessor mentions the use a new somewhat-evil technique for making the code even faster than it was previously.

But how much faster is it?

The following are being run on a fairly typical corporate Windows XP machine, with Strawberry Perl 5.10.1 and thread support.

First, some benchmarks using the previous 1.05 release (two runs)

Read More 1 comments
Comments: 1
+ -

  Journal: Why does Object::Tiny only support getters on 2010.08.14 20:39

Journal by Alias on 2010.08.14 20:39
User Journal

http://perlalchemy.blogspot.com/2010/08/objecttinyrw-and-moosexnonmoose.html

Zbigniew Lukasiak tries out Object::Tiny and wonders why it is that I didn't allow for the creation of setters when it is only a one line change.

Like most ::Tiny modules the reason is a bit complex and the result of compromises.

Read More 2 comments
Comments: 2
+ -

  Comment: Can we migrate it to blogs.perl.org somehow? (Score 1) on 2010.08.12 7:08

by Alias on 2010.08.12 7:08 (#72305)
Attached to: use Perl;

... or at least give me all MY data in a SQLite database or something, so I can migrate it?

(Assuming the site goes away, of course)

Read More 15 comments
Comments: 15
+ -

  Comment: Caching doesn't need email (Score 1) on 2010.08.09 22:53

by Alias on 2010.08.09 22:53 (#72270)
Attached to: CPAN Testers 2.0: The death of via email is wrong.

... we can add offline support for http without TOO much difficulty.

Read More 9 comments
Comments: 9
+ -

  Comment: I recommend you take a look at ORLite (Score 1) on 2010.08.06 23:30

by Alias on 2010.08.06 23:30 (#72265)
Attached to: My reply to Removing database abstraction

I created ORLite to address precisely the problem you are talking about.

ORLite tries to use as little abstraction as possible, and in particular there is no abstraction of where clauses.

my @objects = ORLite::TableName->select( 'END_SQL', 'Bob' );
where name in (
        select name from people where husband in (
                select name from people where name like ?
        )
)
END_SQL

Read More 5 comments
Comments: 5
+ -

  Journal: Trailer Theory - Reinvented for Ignite Sydney as Economics on 2010.08.04 0:40

Journal by Alias on 2010.08.04 0:40
User Journal

Back in 2005 in only my fifth use.perl post ever, I outlined an idea I had been developing for a couple of years that I called "Trailer Theory".

A few years ago on my Portable Perl world hack'a'tour, I took with me a lightning talk version of the concept. It was a pretty crude talk but was received, it seemed, fairly well by the development community.

Read More 0 comments

+ -

  Comment: Re:semantics vs syntax (Score 1) on 2010.08.03 20:11

by Alias on 2010.08.03 20:11 (#72240)
Attached to: Protesting the Moose with sugary alternatives

The idea of encapsulation is the very reason that we have most APIs.

The idea that you don't NEED to know how something is implemented is always going to be better, as long as that lack of knowledge does not compromise the integrity of the systems or lead to perverted incentives.

What good is a car that requires an intimate understanding of the underlying engine and brakes and gearbox. It might be handy if you are an enthusiast of a racing car driver or pushing the limits in some other dimension.

What good is a toilet that requires you understand the sewerage system?

But for the masses, encapsulation and the hiding away of knowledge is the primary goal. Encapsulation creates specialisation, which creates productivity, which creates prosperity.

Read More 17 comments
Comments: 17
+ -

  Comment: Re:Moose Notes (Score 1) on 2010.08.03 18:38

by Alias on 2010.08.03 18:38 (#72239)
Attached to: Protesting the Moose with sugary alternatives

No, this does NOT count as "heavy".

Perl                     3,120 K
Perl + Moose            11,840 K
Perl + MooseX::Atom     11,852 K

Read More 17 comments
Comments: 17
+ -

  Comment: Re:MooseX::Declare (Score 1) on 2010.08.03 4:01

by Alias on 2010.08.03 4:01 (#72234)
Attached to: Protesting the Moose with sugary alternatives

To further clarify based entirely on memory load overhead (using only require, so without any work done in import methods).

Perl                       3.1 meg
Perl + Moose              11.8 meg
Perl + MooseX::Declare    21.6 meg

Read More 17 comments
Comments: 17
+ -

  Comment: Re:MooseX::Declare (Score 1) on 2010.08.03 3:48

by Alias on 2010.08.03 3:48 (#72233)
Attached to: Protesting the Moose with sugary alternatives

That would fall into the category of

"b) Use this SECOND heavy sugar layer on top of the FIRST sugar layer, on top of Class::MOP."

Read More 17 comments
Comments: 17