Re^2: Mouse role fails

[karlgoethebier]

in reply to Re: Mouse role fails
in thread Mouse role fails

Hi, this code fails with Active State Perl and Strawberry but is OK on a linux box:

use IO::File;
use Data::Dumper;
my $fh = IO::File->new();
$fh->open(shift);
my @lines = $fh->getlines();
undef $fh;
print Dumper (@lines);

Perl versions:

Strawberry: This is perl 5, version 16, subversion 1 (v5.16.1) built for MSWin32-x86-multi-thread

Active State: This is perl 5, version 14, subversion 2 (v5.14.2) built for MSWin32-x86-multi-thread

Linux Box Perl: This is perl, v5.8.8 built for x86_64-linux-thread-multi

It seems that the role didn't fail but IO::File/IO::Handle does(same errors), as you assumed.

Regards and thank you, Karl

[tobyink]

If ActiveState and Strawberry are on the same box, it might be that they are getting confused about their libraries. XS libraries built for one are very unlikely to run correctly on the other.

Looks like I somehow duplicated this post instead of updating it!

[tobyink]

If ActiveState and Strawberry are on the same box, it might be that they are getting confused about their libraries. XS libraries built for one are very unlikely to run correctly on the other.

Also, for what it's worth, Moo is gaining traction over Mouse as a light-weight Moose replacement. Although its surface syntax is less Moose-compatible, its killer feature is that if Moo detects that Moose has been loaded, it can inflate Moo classes and roles into full Moose classes and roles.

[karlgoethebier]

Hi, i also thought about giving MOO a try.

The platform for the ETL stuff that i have to do is M$-Dog with IIS 7. I have very little influence on the setup of this box - that means: use good old CGI. So performance is really an issue. And the tool must run under cmd too.

What do you think about this?

Regards, Karl

[tobyink]

That link benchmarks Moo 0.009007 which is over 18 months old; the current version is 1.000005.

An important speed factor for Moo is the availability of Class::XSAccessor. If that module is installed, Moo uses it to create very fast accessors. If it's not installed, Moo falls back to slower, pure Perl accessors.

Because I've recently been working with Ingy on Moos (despite the name, it's actually smaller than Moo), I have some fairly up-to-date benchmarks for accessors across the Moose family...

https://github.com/tobyink/moos-pm/blob/master/devel.benchmarks/bench-results-IntelAtomN270%401.6GHz.txt

Moo has the fastest of the pure Perl accessors; and with XS, again it's the fastest.

[VinsWorldcom]

Am I missing what this is (not) supposed to do? Seems to work fine for me on Windows 7 x64 and Strawberry 5.16.1 (64-bit):

VinsWorldcom@C:\Users\VinsWorldcom\tmp> ver

Microsoft Windows [Version 6.1.7601]

VinsWorldcom@C:\Users\VinsWorldcom\tmp> perl -v

This is perl 5, version 16, subversion 1 (v5.16.1) built for MSWin32-x
+64-multi-thread

VinsWorldcom@C:\Users\VinsWorldcom\tmp> perl test.pl test.pl
$VAR1 = 'use IO::File;
';
$VAR2 = 'use Data::Dumper;
';
$VAR3 = 'my $fh = IO::File->new();
';
$VAR4 = '$fh->open(shift);
';
$VAR5 = 'my @lines = $fh->getlines();
';
$VAR6 = 'undef $fh;
';
$VAR7 = 'print Dumper (@lines);';

[tobyink]

"Seems to work fine for me"

Good. This means that you have a non-broken copy of IO::File.

[Anonymous Monk]

Hi, you don't miss anything.

I did the same thing as you. And i swear i didn't work. I was really surprised - IO::FIle/IO::Handle is good stuff. I will post the output tomorrow (I don't have remote access to the fishy box).

Regards, Karl