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 ]

dagolden (6584)

dagolden
  (email not shown publicly)
AOL IM: xdaveg (Add Buddy, Send Message)
+ -

  Comment: gorgeous (Score 1) on 2010.08.22 23:52

by dagolden on 2010.08.22 23:52 (#72342)
Attached to: TPF News website redesign

It looks awesome! I hope that Explore bar makes it across all the perl.org sites (and even further into community sites).

-- dagolden

Read More 3 comments
Comments: 3
+ -

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

by dagolden on 2010.08.03 20:36 (#72241)
Attached to: Protesting the Moose with sugary alternatives

It sounds like you're talking about encapsulation from the standpoint of users and APIs, which is different. Or, rather, it's the same but applied to Moose itself rather than what someone is designing using Moose.

Unlike users, the designers of a system must understand the dynamics of the design. That can't be safely abstracted away. Role composition is a design activity that involves satisfying certain constraints and avoiding certain conflicts in order to get the desired behaviors.

My point was that the Moose API is very transparent about these design decisions and the temporal order in which they are carried out. The Moose API could have provided visual sugar which obscured the temporal order, but it did not. I think that's the right design decision for a very complex tool like Moose.

MooseX::Atom provides an alternate approach that appears to optimizes visual clarity over design clarity. That's a valid choice if you prioritize the other way.

-- dagolden

Read More 17 comments
Comments: 17
+ -

  Comment: semantics vs syntax (Score 1) on 2010.08.03 10:34

by dagolden on 2010.08.03 10:34 (#72235)
Attached to: Protesting the Moose with sugary alternatives

First, as a minor nit, you can declare multiple attributes at once, which is a little less repetitive.

has [qw( this that )] => ( is  => 'ro', isa =>'Str' );

As for "with", do you understand in what cases you need to put "with" after you declare your attributes? Even if you do, does everyone on your team (now and in the future)?

The thing I've come to appreciate about Moose is that it expects you to know what you're doing. E.g. you compose roles after attributes when roles require those attributes.

Using sugar to put the roles "on top" (visually) with delayed composition makes it easier for people to not think about what they're doing. In many cases, laziness is great -- there are lots of things we'd rather not think about. But roles are not subclasses. They're not mix-ins. They have different semantics.

It seems to me like the designers of Moose have aimed to make the declarative syntax match the semantics pretty closely. Moose isn't trying to be sugary -- it's trying to be transparent. As each declaration is processed, the class evolves as per the declaration. That's a pretty good approach for keeping people out of trouble from lazy thinking about how Moose actually works.

To be clear, I do think the idea of a thin layer of sugar on top of Moose makes a lot of sense, particularly for things like autoclean and immutability, where you have more specific goals or constraints than Moose itself.

[As I understand it, the reason that Catalyst needs "extends" in a BEGIN block is because of the way that Catalyst uses Perl attributes on subroutines (which, despite the name, have nothing to do with Moose attributes). That's a Catalyst design choice, not a Moose one. Once the project committed to using subroutine attributes, they got all the warts that go with that.]

-- dagolden

Read More 17 comments
Comments: 17
+ -

  Perl 5.13.3 released on 2010.07.20 14:44 dagolden

Submitted by dagolden on 2010.07.20 14:44
Releases
dagolden writes "

Look at Crowley, doing 110 mph on the M40 heading towards Oxfordshire. Even the most resolutely casual observer would notice a number of strange things about him. The clenched teeth, for example, or the dull red glow coming from behind his sunglasses. And the car. The car was a definite hint.

Crowley had started the journey in his Bentley, and he was dammned if he wasn't going to finish it in the Bentley as well. Not that even the kind of car buff who owns his own pair of motoring goggles would have been able to tell it was a vintage Bentley. Not any more. They wouldn't have been able to tell that it was a Bentley. They would only offer fifty-fifty that it had ever even been a car.

There was no paint left on it, for a start. It might still have been black, where it wasn't a rusty, smudged reddish-brown, but this was a dull charcoal black. It traveled in its own ball of flame, like a space capsule making a particularly difficult re-entry.

There was a thin skin of crusted, melted rubber left around the metal wheel rims, but seeing that the wheel rims were still somhow riding an inch above the road surface this didn't seem to make an awful lot of difference to the suspension.

It should have fallen apart miles back.

-- Neil Gaiman and Terry Pratchett, "Good Omens"

It gives me great pleasure to announce the release of Perl 5.13.3.

This is the fourth DEVELOPMENT release in the 5.13.x series leading to a stable release of Perl 5.14.0. You can find a list of high-profile changes in this release in the file "perl5133delta.pod" inside the distribution.

You can (or will shortly be able to) download the 5.13.3 release from:

http://search.cpan.org/~dagolden/perl-5.13.3/

The release's SHA1 signatures are:

This release corresponds to commit 414abf8 in Perl's git repository. It is tagged as 'v5.13.3'.

We welcome your feedback on this release.

If Perl 5.13.3 works well for you, please use the 'perlthanks' tool included with this distribution to tell the all-volunteer development team how much you appreciate their work.

If you discover issues with Perl 5.13.3, please use the 'perlbug' tool included in this distribution to report them.

If you write software in Perl, it is particularly important that you test your software against development releases. While we strive to maintain source compatibility with prior stable versions of Perl wherever possible, it is always possible that a well-intentioned change can have unexpected consequences. If you spot a change in a development version which breaks your code, it's much more likely that we will be able to fix it before the next stable release. If you only test your code against stable releases of Perl, it may not be possible to undo a backwards-incompatible change which breaks your code.

Perl 5.13.3 represents approximately one month of development since Perl 5.13.2, and contains 12,184 lines of changes across 575 files from 104 authors and committers.

Notable changes in this release:

  • \o{...} has been added as a string escape for octals.
  • \N{} and charnames::vianame now know about the abbreviated character names listed by Unicode, such as NBSP, SHY, etc.
  • Most dual-life module have been synchronized with the latest production release on CPAN.
  • There is a new internal function PL_blockhook_register for XS code to hook into Perl's lexical scope mechanism

There is one major known issue:

  • Bug fixes involving CvGV reference counting break Sub::Name (currently version 0.04). A patch has been sent upstream to the maintainer.

Thank you to the following for contributing to this release:

Abhijit Menon-Sen, Abigail, Alex Davies, Alex Vandiver, Alexandr Ciornii, Andreas J. Koenig, Andrew Rodland, Andy Dougherty, Aristotle Pagaltzis, Arkturuz, Ben Morrow, Bo Borgerson, Bo Lindbergh, Brad Gilbert, Bram, Brian Phillips, Chas. Owens, Chip Salzenberg, Chris Williams, Craig A. Berry, Curtis Jewell, Dan Dascalescu, Daniel Frederick Crisman, Dave Rolsky, David Caldwell, David E. Wheeler, David Golden, David Leadbeater, David Mitchell, Dennis Kaarsemaker, Eric Brine, Father Chrysostomos, Florian Ragwitz, Frank Wiegand, Gene Sullivan, George Greer, Gerard Goossen, Gisle Aas, Goro Fuji, Graham Barr, H.Merijn Brand, Harmen, Hugo van der Sanden, James E Keenan, James Mastros, Jan Dubois, Jerry D. Hedden, Jesse Vincent, Jim Cromie, John Peacock, Jos Boumans, Josh ben Jore, Karl Williamson, Kevin Ryde, Leon Brocard, Lubomir Rintel, Maik Hentsche, Marcus Holland-Moritz, Matt Johnson, Matt S Trout, Max Maischein, Michael Breen, Michael G Schwern, Moritz Lenz, Nga Tang Chan, Nicholas Clark, Nick Cleaton, Nick Johnston, Niko Tyni, Offer Kaye, Paul Marquess, Philip Hazel, Philippe Bruhat, Rafael Garcia-Suarez, Rainer Tammer, Reini Urban, Ricardo Signes, Richard Soderberg, Robin Barker, Ruslan Zakirov, Salvador Fandino, Salvador Ortiz Garcia, Shlomi Fish, Sinan Unur, Sisyphus, Slaven Rezic, Steffen Mueller, Stepan Kasal, Steve Hay, Steve Peters, Sullivan Beck, Tim Bunce, Todd Rinaldo, Tom Christiansen, Tom Hukins, Tony Cook, Vincent Pit, Yuval Kogman, Yves Orton, Zefram, brian d foy, chromatic, kmx, Ævar Arnfjörð Bjarmason

Many of the changes included in this version originated in the CPAN modules included in Perl's core. We're grateful to the entire CPAN community for helping Perl to flourish.

Development versions of Perl are released monthly on or about the 20th of the month by a monthly "release manager". You can expect following upcoming releases:

  • August 20 — Florian Ragwitz
  • September 20 — Steve Hay
  • October 20 — Tatsuhiko Miyagawa
  • November 20 — Chris Williams
"
Read More 0 comments

+ -

  Comment: Tiny? 99%? (Score 1) on 2010.03.05 11:33

by dagolden on 2010.03.05 11:33 (#71752)
Attached to: When a 99% solutions works, and when it doesn't

At 2200+ SLOC, I don't think it qualifies as a "Tiny" module except in comparison to CPAN(PLUS).

-- dagolden

Read More 9 comments
Comments: 9
+ -

  Comment: Can't RTFM if you can't FTFM (Score 1) on 2010.02.10 22:48

I have sympathy for your experience. Fortunately, I think the redesigned perl.org makes it much easier now to find documentation, including explaining perldoc.

But to make it even easier, I just committed a patch to the Perl core that adds a note to "perl -h" about running "perldoc perl" for more help.

In perldoc perl (the same thing you'd get from "man perl"), it now mentions perldoc right away, advises users to see perldoc perlintro if they are new to Perl, and points users to perl.org for online resources.

So, come Perl 5.12, if someone can't find the manual, the problem will be behind the keyboard.

-- dagolden

Read More 3 comments
Comments: 3
+ -

  Comment: Re:making hard things easier (Score 1) on 2010.02.09 9:23

I agree that it's not fair to blame "the powers" -- and, frankly, tsee and I are also among that crowd these days. We need more dialog on what is achievable and supportable and what not. But I think saying "fork perl and maintain it" is an overreaction.

I was the person that first built and released Strawberry Perl, so I have some experience on this topic. It was actually fairly easy. Build Perl, drop in a pre-configured CPAN::Config, and install extra stuff right from CPAN. The "hard" part was getting everything to work on Win32.

That sort of approach could potentially be done directly in the Perl core -- though probably building from bundled tarballs, not downloading directly from CPAN. I suspect a lot of dual-life modules outside the module toolchain could be packed in core as tarballs and built/tested by the toolchain rather than by the hybrid process that happens today. Maybe one day I'll have enough round tuits to make that happen.

Even without that, I think the (admittedly recent) trend of Perl's development is making it easier to coordinate dual-life modules in core. One of those trends was giving out commit bits to dual-life maintainers like me, so updates don't all fall on the pumpking and a handful of committers. But the more recent trend of time-boxed 5.11.X releases means that having the absolute latest/greatest version on CPAN also in core isn't as much of a release hurdle. I think we can do more to make the process smoother.

I'm not suggesting throwing everything and the kitchen sink into core. But I do think there needs to be a renewed discussion of what "out of the box" functionality should be in core. One that I feel adamantly about is that CPAN should be able to bootstrap itself via HTTP without requiring any external command line tools. That is my #1 project for Perl 5.13.

Hopefully, I have enough track record as a "doer" not just a "talker" to do a credible job of it and convince people that this will make life easier for users and maintainers.

-- dagolden

Read More 62 comments
Comments: 62
+ -

  Comment: making hard things easier (Score 1) on 2010.02.08 23:58

I tend to think of this along the lines of "making hard things easy and impossible things merely hard". With that in mind, the frontier has shifted since Perl was developing rapidly.

My gut feeling is that the "wow" factor has become harder for Perl to achieve because what wows people isn't insanely great string, dataset and administrative task manipulation. People want to see results quickly. That's not just about the learning curve -- it's the end-to-end process.

Part of the advantage of Java in an educational setting is that you get a decent GUI quickly which is more like "real programs" for anyone except die-hard CLI addicts. Ditto PHP, but for dynamic web pages on shared hosting.

Here are some areas where I think Perl is not as easy as it could or should be. A lot revolves around CPAN, since that is one of the strengths of Perl and we're not making it easy enough for people to take advantage of it:

  • Installing CPAN modules locally

    CPAN(PLUS) should be designed for the case of a non-root user installing modules locally for use with the system Perl. local::lib has the right idea, but even bootstrapping it isn't the easiest things for someone new to Perl. What it does should have been built into CPAN(PLUS) ages ago. (I have a feature branch for CPAN.pm that provides this capability and will be looking to merge it after Perl 5.12 is released.)

  • Automatic, transparent CPAN configuration

    The latest dev of CPAN.pm is much less annoying and verbose that it used to be. It does a pretty quiet auto-configuration and can even automatically locate mirror sites. But it could be better yet. A lot of the guts should be hidden from the ordinary user.

  • CPAN popularity metrics

    CPAN has nearly 20,000 distributions. Even search.cpan.org gives dozens or more results on a search. Figuring out which of several similar modules is time consuming, even for experts. Combinations of CPAN Ratings, CPAN Testers results, etc. help. The top 100 list is another useful tool. But we need something better that either ties all these things together or replaces it with something else.

  • Shared hosting website deployment as easy as PHP

    I can't do anything but draw the parallel. It makes the jump from HTML to a dynamic site really easy. No messing with frameworks, templating, HTTP engines. Doesn't HTML::Mason work more or less that way? It doesn't have a mod_php to go with it, but I wonder if something in between HTML and MVC would help people who want simple dynamic sites (backed by the power of CPAN.

  • Improve parallel processing and leveraging multi-core systems

    Perl threads still suck. The best alternative is to fork off the entire interpreter and cobble together some way to collect results? (Parallel::Iterator, for example). There's got to be a better way to do this.

  • Smart defaults in core

    Not just strict being on by default, but the core modules themselves should be a smart set of tools for modern programming tasks. I'm not saying the core should have the kitchen sink, but there should be some basics that come installed with any Perl without making users mess with CPAN. Things like HTTP, SSL, DBI (and probably SQLite) would be good places to start, I think. I'd like to see a standard OO included, but suspect that's too controversial to achieve.

How's that for starters?

-- dagolden

Read More 62 comments
Comments: 62
+ -

  Comment: hacking in a nicer error message? (Score 1) on 2010.01.22 10:31

You really like to goad me to put my "evil hat" on. This is a crude example to show the concept -- it would need to be a bit more helpful and a bit more robust for real use.

package Nice;
use strict;
use warnings;
no warnings 'once';

*CORE::GLOBAL::require = sub {
  my $mod = shift;
  eval { CORE::require($mod) };
  if ($@) {
    if ( my ($mod) = $@ =~ /\ACan't locate (\S+)/ ) {
      $mod =~ s{/}{::}g;
      $mod =~ s{\.pm$}{};
      $@ = <<"END";
Can't locate $mod in your Perl library.  You may need to install it
from CPAN or another repository.  Your library paths are:
END
      $@ .= "  $_\n" for @INC;
    }
    die $@;
  }
  return 1;
};

1;

Here's an example:

$ perl -MNice -MFoo::Bar -e 1
Can't locate Foo::Bar in your Perl library.  You may need to install it
from CPAN or another repository.  Your library paths are:
  /opt/perl/5.10.1/lib/5.10.1/x86_64-linux-ld
  /opt/perl/5.10.1/lib/5.10.1
  /opt/perl/5.10.1/lib/site_perl/5.10.1/x86_64-linux-ld
  /opt/perl/5.10.1/lib/site_perl/5.10.1
  .

Could be done via PERL5OPT or perhaps the site-customization file.

-- dagolden

Read More 13 comments
Comments: 13
+ -

  Comment: Just skip if AUTOMATED_TESTING? (Score 1) on 2010.01.15 6:23

I generally think of CPAN Testers as trying to reflect the "end user experience" -- and some people just happen to report in bulk using automated smokers. I would rather just have xt tests skipped if AUTOMATED_TESTING is true, since an xt FAIL is meaningless to an end user.

-- David

Read More 3 comments
Comments: 3
+ -

  Comment: To summarize your post... (Score 1) on 2009.12.01 13:48

by dagolden on 2009.12.01 13:48 (#71290)
Attached to: Why Should I Program in $Language?

Was that all pretty much just saying "we need an object system in core?"

+1 for sentiment, but we need more than sentiment. We need a plan that p5p supports. (And, probably, a long-term feature branch in the core to prototype, test and get buy-in around.)

As for the toolchain footnote, you're right, which is why I'm working on things like this and this. It can get better and it will get better.

-- dagolden

Read More 24 comments
Comments: 24
+ -

  Comment: Module::Build broken in 5.11.2 -- and how to fix (Score 1) on 2009.11.21 6:36

by dagolden on 2009.11.21 6:36 (#71201)
Attached to: Perl 5.11.2

Module::Build is missing an updated file in 5.11.2, which is my fault, not Acme's.

Problems will appear if the YAML module is installed: building distributions with Build.PL will fail.

The fix is to install a new Module::Build from CPAN: DAGOLDEN/Module-Build-0.35_09.tar.gz

M::B 0.36 is coming "soonish" and will also address the problem.

David

Read More 2 comments
Comments: 2
+ -

  Comment: Maint branches on my github (Score 1) on 2009.10.29 19:57

by dagolden on 2009.10.29 19:57 (#71021)
Attached to: buildperl.pl

FWIW, I've done similar work in the past and published it on my github clone of the perl repository:

git://github.com/dagolden/perl.git

Relevant branches are:

maint-5.6.2
maint-5.8.0
maint-5.8.1
maint-5.8.2
maint-5.8.3
maint-5.8.4
maint-5.8.5
maint-5.8.6
maint-5.8.7
maint-5.8.8

Hope that helps others looking to build old versions of Perl.

-- David

Read More 1 comments
Comments: 1
+ -

  Comment: Hurrah! (Score 1) on 2009.10.27 8:27

Wow! What can I say? I'm very pleased and very supportive. +1 to all the new contributors who have been making this possible.

-- dagolden

Read More 9 comments
Comments: 9
+ -

  Comment: Wrong links? (Score 1) on 2009.10.25 18:34

by dagolden on 2009.10.25 18:34 (#70972)
Attached to: Testing Needed: Strawberry October 2009 BioPerl
Comments: 5