Leon Timmermans

• Website: codespeaks.blogspot.com/

Recent Actions

• Commented on Belated "hello world"
  Good to have you here, curious what you have to say :-)...
• Commented on Why you don't need File::Slurp…
  Because File::Slurp is portable to non-Unix systems. Functionally it's identical to read_file(binmode => ':raw'), otherwise it's perfectly portable. Because File::Slurp can be rewritten in XS if speed is the overriding concern (and it will be faster than your 2-lines)....
• Commented on Why you don't need File::Slurp…
  If I recall, File::Slurp had issues with the PerlIO :encoding layer and required manual decoding of the slurped data instead, which is why I have avoided it. Not sure if this is still an issue. Looking at the code,...
• Commented on Why you don't need File::Slurp…
  mmap should be faster than sysread -s or read -s, and there exist a portable module for it. There is, and I wrote it ;-). Was planning to blog about that too at some point. It's close but not...
• Commented on Why you don't need File::Slurp…
  In general, in a shop with both newbs and monks it's preferable to use modules as much as possible. You're missing the point; I'm all for modules, I didn't write 50 CPAN modules for nothing. This code started when...
• Posted Why you don't need File::Slurp… to Leon Timmermans

  #! /usr/bin/env perl
  use strict;
  use warnings;
  use Benchmark 'cmpthese';
  use File::Slurp 'read_file';
  
  my $filename = shift or die "No argument given";
  my $count = shift || 10;
  
  cmpthese($count, {
      'Unix'  => sub { open my $fh, '<:unix', $filename or die "Coul…

• Commented on I Bless You in the Name of the Stringified Object
  I'm wondering if a "::" overload makes sense, specially if a future version of perl would allow for blessing into an anonymous stash....
• Commented on Introducing Platform
  Instead of having a hard-coded list of osnames you might want to rely on Perl::OSType. Though as Mr. Muskrat said there are some tricky bits such as cygwin....
• Commented on Don't release experiments to CPAN
  I agree with David. I release experiments to CPAN. Sometimes I don't do anything with it anymore, but someone else might. Because letting code rot in a corner is a waste of effort. That said, most of my experiments are...
• Commented on A funny thing happened on the way to the p5-mop...
  In the end, we were forced to conclude that Perl's method dispatch mechanism would almost certainly need to be changed to allow some kind of non-package based dispatching. This probably means some core level work, but we stopped short of...
• Commented on deb.perl.it - bridging CPAN and Debian → step2
  File::Temp is in core, so unless you need a more recent version perl-core will satisfy that dependency....
• Commented on pmtool-1.30 (Perl Module Tools) Released
  You should update that «VERSION => '1.00',» in your Makefile.PL though ;-)...
• Commented on Lock::File - yet another file locking module
  I think it's fairly confusing if not outright wrong that you use the names flock and lockf as if they are synonymous. They have fairly different semantics in POSIX....
• Commented on Recent work on ZMQ::LibZMQ3 and CZMQ
  You might be interested in Config::Autoconf...
• Commented on New CPANTS Site
  It seems it doesn't show any distributions that weren't released recently (even if it does seem to have calculated their score, as their average seems about what it used to be)....
• Commented on Versioning Loops
  It seems Perl::MinimumVersion::Reason was removed from Perl::MinimumVersion. That always causes issues like this. It's a known issue of our dependency system....
• Commented on On the utility of Module::Build::CleanInstall
  Wow, that is quite craptacular, I really though —uninst would do something sensible. I’m wondering if we can still change it to do the sensible thing....
• Commented on RFC Module::Build::CleanInstall
  It also appears that Module::Build->new( uninst => 1, … ) has the effect of defaulting the command option to 1, though I can’t find where this is documented. All commandline options are also constructor arguments, though I don’t think this...
• Commented on RFC Module::Build::CleanInstall
  This looks to me like what you really want is the —uninst argument to Module::Build (it’s a documented feature of Module::Build. Actually, you can simply do my $b = Module::Build->new( module_name => 'Foo', # more arguments uninst => 1, );...
• Commented on Counter-productive over time
  I agree. The zero-deps thingie is a bit silly to me, I don't like technical workarounds to social issues. Though actually there is one tool that I think we're missing that could be a killer app: a web-based CPAN client....
• Commented on Testing scripts in your distribution, portably
  Yeah. I extracted Devel::FindPerl from Module::Build to deal with such edge-cases. If D::FP can't find your perl, you're probably screwed anyway....
• Posted 2 weeks of perl to Leon Timmermans

  It all started with the Cluj.pm summer meeting on the 9th of August. I happened to be around there, so popped in. Cluj.pm is a refreshingly young perl monger group (I might even have been older than the average…

• Commented on Perl Reunification Summit
  Thank you for inviting me. It was a very enlightening meetup....
• Commented on Forgive me, for I have sinned
  No wait, that VMS caveat was only for %INC, not for anything else, I think....
• Commented on Forgive me, for I have sinned
  MacOS is dead, there's no need to consider it. For that matter, there's no need to use anything other than File::Spec, except I think (not sure where I got that) that you need to use File::Spec::Unix on VMS for some...
• Commented on Ricardo is pushing for smart match changes.
  A long time ago, Ricardo suggested big changes to smart matching. I added my thoughts on how that does not benefit Perl. Now he's pushing for those changes again. Is it really necessary to make this personal. This is not...
• Commented on When Perl is not applicable
  Have you considered using PDL? It makes a lot of big data handling in Perl a tremendous amount more efficient?...
• Commented on Several rants
  I disagree on most points. I still use File::Spec, and in fact some of the software I maintain really does have to be that portable. I don't find it all that much of a hassle, it has become a habit....
• Commented on Stop writing Perl books!*
  I do think it would be nice if there was a book on creating and maintaining CPAN modules, though the issue brian mentioned may be an issue....
• Commented on Lightning Talks
  Submitted mine :-)...

Comment Threads

• Buddy Burden commented on Don't release experiments to CPAN

  Guys, I think what Neil is talking about here is the modules we've all run across before: modules that don't even have any code in them, or only pseudo-code, or some quickly hacked code with no tests--this sort of thing. The modules that are really nothing more than placeholders for nifty ideas that may or may not ever go anywhere. But, in the meantime, they use up names and confuse n00bs.

  mst says:

  > ... because CPAN is how we share our work.

  This is the heart of the matter right here. Some people want to CPAN to be a place where we're all slinging code aro…

• Reini Urban commented on Why you don't need File::Slurp…

  mmap should be faster than sysread -s or read -s, and there exist a portable module for it.

• George Greer commented on Why you don't need File::Slurp…

  I use a one-liner slurp at $WORK. I am sooo tired of copy+pasting it into scripts when I start them (and perhaps remembering which is the most recent if I've changed it lately). I would much prefer it be as easy as a module.

• Nick Patch commented on Why you don't need File::Slurp…

  If I recall, File::Slurp had issues with the PerlIO :encoding layer and required manual decoding of the slurped data instead, which is why I have avoided it. Not sure if this is still an issue.

• Sawyer X commented on Belated "hello world"

  YOU'RE IN THE WRONG NEIGHBORHOOD, MOTHERFLUFFER!