Slashdot Mirror

James A. A. Joyce writes "The title says it all. There's a tiny blurb over at dev.perl.org. Download Perl 1.0 here, for all of those nostalgics in the Slashdot audience! It's only 263KB, so why not give this piece of 1980s computing history a try?"

caseywest writes "Today at his State of the Onion speech during the 2003 O'Reilly Open Source Convention, Larry Wall announced the Ponie project (somewhere within his legendary humorous presentation). Ponie involves rewriting central parts of the Perl 5 interpreter to run on Parrot, the Perl 6 virtual machine, including a C API emulation layer to make existing XS code work. Arthur 'sky' Bergman is sponsored by his employer Fotango to develop Ponie. Currently, a press release and a FAQ are available. More details will be available in due time."

Mark Leighton Fisher writes "Some readers might be interested in Outstanding Objects (Developed Dirt Cheap); or "Why Don't Developers Search the Literature?" It seems like I still see a lot of wheel reinvention going on, even with the wealth of code and information now available on the Net."

Dr. Zowie writes "Perl Data Language 2.4.0 was just released; get it here. This release includes even more powerful array slicing, a complete GIS cartography package, API access to the Gnu Scientific Library, and a host of other goodies. Between PDL and its less-mature siblings Numeric Python and Octave, the established commercial languages' days appear numbered."

Web Sawy asks: "I work for a large-ish company (4000+). We have a number of disparate divisions and, believe it or not, varying knowledge on How Technology Works. It was brought to my attention that one part of the corporate website has been using 'a third party tool' to 'compare the performance of individual ads'. In other words, some external party is tracking user surfing habits. How does one go about educating co-workers on the evils of these third party services, which are currently 'helping' the Marketing department? What technologies are people using to do this type of reporting to help the Marketing department generate their numbers? In the world that I live, I can't even see those third-party ads (or hidden images!). I certainly can build my own user tracking system using existing technologies but before I fight that major uphill battle, I wonder if Slashdot readers would share their insights."

With TiVo's release of the much anticipated Home Media Option (anticipated by me, anyway), I renewed my quest to find a way to integrate my computer's media files with my TV. TiVo's solution is not an option for me, because I don't have a Series2, and even if I did, the TiVo solution doesn't work with DirecTV units (for now, anyway). So I looked into something I saw a few months ago on ThinkGeek: QCast Tuner for PlayStation 2. QCast Tuner is software that plays audio, video, and image files from your computer to your network adapter-equipped PS2. There are two pieces to the software, the PS2 DVD and the computer software (on a separate CD), for Linux, Mac OS X, and Windows. I used the Mac OS X version, of course. There's a configuration utility to set up what you will share, and to what users/IP addresses. Then a separate program launches the server, which serves up the files and playlists. It's all written in Java, which means the UI stinks, but it seems to work well.

It can handle many media formats; to me, the most important are MPEG-1, MP3, and JPEG. But it also handles DivX, MPEG-2 and MPEG-4, Ogg Vorbis, and PNG, and can be updated to handle other formats. But it doesn't handle the majority of my movie file archive, which are QuickTime, and that's a shame. And if you try to open a file it can't read (I changed some .mov files to .mpg, as it filters by name), it seems to hang.

I got the PS2 Network Adapter installed first, popped it onto the back of the machine, and ran the setup disk to configure it. Then I played a game of Madden 2003 online. I scored a touchdown on a tight end slant on the first play, then got one more play at the end of the half (a 30-yard reception to Troy Brown), and then didn't take another snap. Stupid 1-minute quarters. I lost 14-7.

Then I remembered I had this QCast Tuner thing, and I installed it on my PowerBook G3/500, where I keep my images, my MP3s, and my EyeTV recordings. It didn't take much to set it up, same as with the initial setup: I manually entered my IP address, router address, etc. and the IP address of the PowerBook G3. The software on the PowerBook updated and configured the PS2 software, and restarted it, and I was ready to go.

From the main screen you can elect to view pictures, or play music and video. I tried music first, where I had shared my iTunes directory, which has one directory per artist (except for compilations, which are in a separate directory). I have 293 directories in this directory, and there is no good way to skip to the bottom of the list; you can go one screen at a time, but that takes a little while. So I picked Ben Folds to start out with.

The user interface, apart from not handling long lists well, has several usability problems. To go up a directory, you select the ".." directory, which is something that Unix geeks know, but most PS2 users would expect to use the triangle button or something.

You cannot play songs from these lists, either; you need to add them to the playlist, then hit L1 to switch to the playlist, and then play from there. To get the ID3 tags to show up, you have to hit L1 again, and select that option (along with the shuffle and repeat options). And if you leave the playing screens (which makes the music stop, so you can't manage playlists while playing music) and come back, those options get reset.

You cannot get the time remaining of a song, and the UI doesn't show the full track name -- or track number -- if it is too large for the available space (it has trouble even with track "1/10", though "1/9" fits). And you can't scan forward or backward in a song or movie (which is often the case with streaming software), you can only pause, play, stop, and skip to another file.

To make it easier to find what you want to play, you can make playlists. Select the files you want to play in the interface, and save the playlist, which is stored on the server. I didn't want to do this for all my MP3s, but I had an easier solution: I wrote a small Perl script to create symlinks to my MP3 artist directories in other directories beginning with the first letter of the artist; and I share that directory of directories of symlinks instead. So instead of going down a list of 390 artists to get to Wesley Willis, I just select W, and he's right there.

My problem with EyeTV was greater: as noted in my review of EyeTV, the filenames bear no resemblance to the contents of the files, unlike the MP3s. But the solution I wrote for EyeTV was easily modified to serve me here, too. The playlists are just text files with the path (relative to the share point) on one line, and just the filename on the next line.

I thought I could change the filename line to be any arbitrary text (like "McLaughlin Group 2003.04.11") and have one playlist for all my EyeTV recordings, but that didn't have any effect; the display still showed the filename. So instead, I created multiple playlists, one for each program. So the playlist "EyeTV: McLaughlin Group" has paths for each McLaughlin Group recording I've got saved. It would have been nice to have an EyeTV playlist directory, instead of naming the playlists "EyeTV: ", but I could find no way to make nested playlists. If a playlist is not in the root playlist directory, it is not recognized as a playlist.

I can now watch the shows I used to have to watch on the computer, on the TV. It makes me feel kinda dirty, like it should have been on the TV all along. Oh well. And any changes to my music and TV recordings are regularly updated, as the two programs run via cron every half hour (and I can even begin watching a program that is currently recording).

QCast is bitten by the iTunes ID3 comment bug whereby data is stored with a frame header of "COM ", which is illegal. So QCast doesn't recognize any of the ID3 tag at all. I can't blame QCast for Apple's bug, especially since it bit my code too; this was the final straw that made me convert all my tags to ID3v2.2.0 (only v2.3.0 and v2.4.0 are affected). Maybe the QCast people can fix that problem when they add QuickTime support (he says hopefully).

The final issue I have is how to integrate it into my TV "experience." I don't want to have to turn on the PS2 and wait for it to boot every time I want to listen to music, so do I leave it on whenever I am around? And my system isn't set up to easily switch between PS2 and TiVo and DVD; my switch box has no remote, but does switch to a device that is turned on, which is nice for DVDs, but useless for when you leave the PS2 on all the time. I could plug the PS2 into the spare inputs on the VCR (which is on a separate input to the amplifier, and has its own button on the remote control), but that is kinda sloppy. And do I buy an IR remote control for the PS2? Is there an IR remote that can turn the PS2 off and on? These are problems mostly inherent in the design of using PS2 for multimedia, and there's not a lot I can do except to try to figure out ways to do things that work for me.

Basically, QCast Tuner is a nice idea, and it works well despite its UI and design flaws (some of which can be fixed on subsequent updates, I imagine), if you can fit it into your setup (or change your setup to suit it). I'm still undecided on using it long-term, but I am going to keep trying it out for awhile and see how it goes.

Leeji writes "Here is an interesting read about one geek's project to build and launch a weather balloon. The flight recorder is a small $200 Soekris Engineering computer running Bering Linux. It also uses a Garmin GPS, HAM packet radio, an automated Aiptek Pencam Trio digital camera, army surplus batteries, and lots of geek duct tape."

Casey West writes "Version 0.25 of the award-winning POE networking and multitasking framework has been released. This version is mainly a bug fix release." Read on for more... Thanks go out to everyone who helped make this release happen, especially our new committers and testers.

• ActivePerl 5.8.0 is supported.
• Gentoo Linux is supported. Previously Perl would segfault.
• TCP clients and servers now support different kinds of sessions (Session, NFA, and custom types).
• TCP servers now gracefully handle aborted connections. This prevents them from stopping under heavy load.
• TCP clients and servers are more configurable in general.
• Several unimplemented features in Wheel::Run have been completed.
• POE::Kernel's call() honors array vs. scalar context now.
• Fixed a bug that sometimes prevented POE::Kernel from returning.
• Fixed a leak in signal dispatching. Terminal signals now destroy sessions at the proper times.

POE's web site contains detailed changes for every public release.

http://poe.perl.org/?POE_CHANGES

The latest tarball should be heading towards your favorite CPAN mirror. It is also on the web, and so is a Windows PPD. Users who need advanced notice of changes can follow it via anonymous CVS or POE's mailing list.

http://poe.perl.org/?Where_to_Get_POE http://poe.perl.org/?POE_Support_Resources

Thanks again to everyone who helped with this release.

About POE

POE is an award-winning networking and multitasking framework. It has been in active, open development for over four years. Its developer community has created a large and growing list of reusable components.

http://poe.perl.org/?What_POE_Is http://search.cpan.org/search?mode=module&query=PO E::Component

POE's robustness and performance have made it an integral part of mission critical applications since 1998. It is used in a wide variety of fields and in projects ranging from just a few lines of code to tens of thousands.

• Financial:
  Market servers, clients, billing systems, and automated trading agents.
• Web:
  Commerce servers, content management systems, application servers, data warehousing, WAP proxies, ad exchanges, web crawlers/spiders, and a variety of specialized agents.
• System Administration:
  Large-scale host monitoring and maintenance, distributed load testing, a distributed file system (InterMezzo), radius monitoring, system log management and reporting, and spam detection.
• Entertainment:
  Interactive TV servers; mp3 jukeboxes and streaming servers; multi-server multi-game server monitoring, management, billing, and tournament control; and a plethora of IRC applications and agents.
• Software Development:
  Compile farm management, build management, distributed testing.
• Monitoring and Automation:
  X10 home control, weather station monitoring, alarm monitoring.

We look forward to hearing how POE has helped you.

-- Rocco Caputo / troc@pobox.com / poe.perl.org / poe.sf.net

"

Casey West writes "Version 0.25 of the award-winning POE networking and multitasking framework has been released. This version is mainly a bug fix release." Read on for more... Thanks go out to everyone who helped make this release happen, especially our new committers and testers.

• ActivePerl 5.8.0 is supported.
• Gentoo Linux is supported. Previously Perl would segfault.
• TCP clients and servers now support different kinds of sessions (Session, NFA, and custom types).
• TCP servers now gracefully handle aborted connections. This prevents them from stopping under heavy load.
• TCP clients and servers are more configurable in general.
• Several unimplemented features in Wheel::Run have been completed.
• POE::Kernel's call() honors array vs. scalar context now.
• Fixed a bug that sometimes prevented POE::Kernel from returning.
• Fixed a leak in signal dispatching. Terminal signals now destroy sessions at the proper times.

POE's web site contains detailed changes for every public release.

http://poe.perl.org/?POE_CHANGES

The latest tarball should be heading towards your favorite CPAN mirror. It is also on the web, and so is a Windows PPD. Users who need advanced notice of changes can follow it via anonymous CVS or POE's mailing list.

http://poe.perl.org/?Where_to_Get_POE http://poe.perl.org/?POE_Support_Resources

Thanks again to everyone who helped with this release.

About POE

POE is an award-winning networking and multitasking framework. It has been in active, open development for over four years. Its developer community has created a large and growing list of reusable components.

http://poe.perl.org/?What_POE_Is http://search.cpan.org/search?mode=module&query=PO E::Component

POE's robustness and performance have made it an integral part of mission critical applications since 1998. It is used in a wide variety of fields and in projects ranging from just a few lines of code to tens of thousands.

• Financial:
  Market servers, clients, billing systems, and automated trading agents.
• Web:
  Commerce servers, content management systems, application servers, data warehousing, WAP proxies, ad exchanges, web crawlers/spiders, and a variety of specialized agents.
• System Administration:
  Large-scale host monitoring and maintenance, distributed load testing, a distributed file system (InterMezzo), radius monitoring, system log management and reporting, and spam detection.
• Entertainment:
  Interactive TV servers; mp3 jukeboxes and streaming servers; multi-server multi-game server monitoring, management, billing, and tournament control; and a plethora of IRC applications and agents.
• Software Development:
  Compile farm management, build management, distributed testing.
• Monitoring and Automation:
  X10 home control, weather station monitoring, alarm monitoring.

We look forward to hearing how POE has helped you.

-- Rocco Caputo / troc@pobox.com / poe.perl.org / poe.sf.net

"

Casey West writes "Version 0.25 of the award-winning POE networking and multitasking framework has been released. This version is mainly a bug fix release." Read on for more... Thanks go out to everyone who helped make this release happen, especially our new committers and testers.

• ActivePerl 5.8.0 is supported.
• Gentoo Linux is supported. Previously Perl would segfault.
• TCP clients and servers now support different kinds of sessions (Session, NFA, and custom types).
• TCP servers now gracefully handle aborted connections. This prevents them from stopping under heavy load.
• TCP clients and servers are more configurable in general.
• Several unimplemented features in Wheel::Run have been completed.
• POE::Kernel's call() honors array vs. scalar context now.
• Fixed a bug that sometimes prevented POE::Kernel from returning.
• Fixed a leak in signal dispatching. Terminal signals now destroy sessions at the proper times.

POE's web site contains detailed changes for every public release.

http://poe.perl.org/?POE_CHANGES

The latest tarball should be heading towards your favorite CPAN mirror. It is also on the web, and so is a Windows PPD. Users who need advanced notice of changes can follow it via anonymous CVS or POE's mailing list.

http://poe.perl.org/?Where_to_Get_POE http://poe.perl.org/?POE_Support_Resources

Thanks again to everyone who helped with this release.

About POE

POE is an award-winning networking and multitasking framework. It has been in active, open development for over four years. Its developer community has created a large and growing list of reusable components.

http://poe.perl.org/?What_POE_Is http://search.cpan.org/search?mode=module&query=PO E::Component

POE's robustness and performance have made it an integral part of mission critical applications since 1998. It is used in a wide variety of fields and in projects ranging from just a few lines of code to tens of thousands.

• Financial:
  Market servers, clients, billing systems, and automated trading agents.
• Web:
  Commerce servers, content management systems, application servers, data warehousing, WAP proxies, ad exchanges, web crawlers/spiders, and a variety of specialized agents.
• System Administration:
  Large-scale host monitoring and maintenance, distributed load testing, a distributed file system (InterMezzo), radius monitoring, system log management and reporting, and spam detection.
• Entertainment:
  Interactive TV servers; mp3 jukeboxes and streaming servers; multi-server multi-game server monitoring, management, billing, and tournament control; and a plethora of IRC applications and agents.
• Software Development:
  Compile farm management, build management, distributed testing.
• Monitoring and Automation:
  X10 home control, weather station monitoring, alarm monitoring.

We look forward to hearing how POE has helped you.

-- Rocco Caputo / troc@pobox.com / poe.perl.org / poe.sf.net

"

Casey West writes "Version 0.25 of the award-winning POE networking and multitasking framework has been released. This version is mainly a bug fix release." Read on for more... Thanks go out to everyone who helped make this release happen, especially our new committers and testers.

• ActivePerl 5.8.0 is supported.
• Gentoo Linux is supported. Previously Perl would segfault.
• TCP clients and servers now support different kinds of sessions (Session, NFA, and custom types).
• TCP servers now gracefully handle aborted connections. This prevents them from stopping under heavy load.
• TCP clients and servers are more configurable in general.
• Several unimplemented features in Wheel::Run have been completed.
• POE::Kernel's call() honors array vs. scalar context now.
• Fixed a bug that sometimes prevented POE::Kernel from returning.
• Fixed a leak in signal dispatching. Terminal signals now destroy sessions at the proper times.

POE's web site contains detailed changes for every public release.

http://poe.perl.org/?POE_CHANGES

The latest tarball should be heading towards your favorite CPAN mirror. It is also on the web, and so is a Windows PPD. Users who need advanced notice of changes can follow it via anonymous CVS or POE's mailing list.

http://poe.perl.org/?Where_to_Get_POE http://poe.perl.org/?POE_Support_Resources

Thanks again to everyone who helped with this release.

About POE

POE is an award-winning networking and multitasking framework. It has been in active, open development for over four years. Its developer community has created a large and growing list of reusable components.

http://poe.perl.org/?What_POE_Is http://search.cpan.org/search?mode=module&query=PO E::Component

POE's robustness and performance have made it an integral part of mission critical applications since 1998. It is used in a wide variety of fields and in projects ranging from just a few lines of code to tens of thousands.

• Financial:
  Market servers, clients, billing systems, and automated trading agents.
• Web:
  Commerce servers, content management systems, application servers, data warehousing, WAP proxies, ad exchanges, web crawlers/spiders, and a variety of specialized agents.
• System Administration:
  Large-scale host monitoring and maintenance, distributed load testing, a distributed file system (InterMezzo), radius monitoring, system log management and reporting, and spam detection.
• Entertainment:
  Interactive TV servers; mp3 jukeboxes and streaming servers; multi-server multi-game server monitoring, management, billing, and tournament control; and a plethora of IRC applications and agents.
• Software Development:
  Compile farm management, build management, distributed testing.
• Monitoring and Automation:
  X10 home control, weather station monitoring, alarm monitoring.

We look forward to hearing how POE has helped you.

-- Rocco Caputo / troc@pobox.com / poe.perl.org / poe.sf.net

"

Casey West writes "Version 0.25 of the award-winning POE networking and multitasking framework has been released. This version is mainly a bug fix release." Read on for more... Thanks go out to everyone who helped make this release happen, especially our new committers and testers.

• ActivePerl 5.8.0 is supported.
• Gentoo Linux is supported. Previously Perl would segfault.
• TCP clients and servers now support different kinds of sessions (Session, NFA, and custom types).
• TCP servers now gracefully handle aborted connections. This prevents them from stopping under heavy load.
• TCP clients and servers are more configurable in general.
• Several unimplemented features in Wheel::Run have been completed.
• POE::Kernel's call() honors array vs. scalar context now.
• Fixed a bug that sometimes prevented POE::Kernel from returning.
• Fixed a leak in signal dispatching. Terminal signals now destroy sessions at the proper times.

POE's web site contains detailed changes for every public release.

http://poe.perl.org/?POE_CHANGES

The latest tarball should be heading towards your favorite CPAN mirror. It is also on the web, and so is a Windows PPD. Users who need advanced notice of changes can follow it via anonymous CVS or POE's mailing list.

http://poe.perl.org/?Where_to_Get_POE http://poe.perl.org/?POE_Support_Resources

Thanks again to everyone who helped with this release.

About POE

POE is an award-winning networking and multitasking framework. It has been in active, open development for over four years. Its developer community has created a large and growing list of reusable components.

http://poe.perl.org/?What_POE_Is http://search.cpan.org/search?mode=module&query=PO E::Component

POE's robustness and performance have made it an integral part of mission critical applications since 1998. It is used in a wide variety of fields and in projects ranging from just a few lines of code to tens of thousands.

• Financial:
  Market servers, clients, billing systems, and automated trading agents.
• Web:
  Commerce servers, content management systems, application servers, data warehousing, WAP proxies, ad exchanges, web crawlers/spiders, and a variety of specialized agents.
• System Administration:
  Large-scale host monitoring and maintenance, distributed load testing, a distributed file system (InterMezzo), radius monitoring, system log management and reporting, and spam detection.
• Entertainment:
  Interactive TV servers; mp3 jukeboxes and streaming servers; multi-server multi-game server monitoring, management, billing, and tournament control; and a plethora of IRC applications and agents.
• Software Development:
  Compile farm management, build management, distributed testing.
• Monitoring and Automation:
  X10 home control, weather station monitoring, alarm monitoring.

We look forward to hearing how POE has helped you.

-- Rocco Caputo / troc@pobox.com / poe.perl.org / poe.sf.net

"

mcwetboy writes "Calendar publishing with iCal requires a .Mac membership or a WebDAV server. Most ISPs and hosting companies don't offer WebDAV -- or at least mine don't -- but you can run WebDAV under Apache on your Mac, and publish calendars and share them among a local network or among multiple users of a single computer. Already two different tutorials explaining how to do this have appeared on the Web: this one at Mac OS X Hints and this one courtesy of Shawn Wall. I'm sure Slashdot readers could offer even more suggestions." I set up mod_dav for the first time within an hour of downloading iCal the other day, with help from this article. Now, if only iCal weren't really slow and buggy ...

Not only did Larry Wall answer your questions, but he said they were excellent questions. You've got to love Larry Wall, not just because he's a nice guy and created Perl, but also because he is the first Slashdot interview guest ever to send his answers preformatted in squeaky-clean HTML. We appreciate this like you wouldn't believe. They're great answers, too -- straightforward, heartfelt, and entertaining. Enjoy! 1) Perl as a "scripting" or a "programming" language
by Marx_Mrvelous

I've been using perl for a very long time, but primarily as a scripting language. I indeed mostly use it for extraction and reporting. With the recent developments in perl, however, there seems to be the trend that perl is able to do much, much more (while retaining compatibility to be "just" a scripting language).

What do you think about how people are using Perl today? Are you satisfied that most people use it for simple tasks like log parsing? Would you like to see more advanced applications being built with Perl verses a compiled language?

A:

I am perfectly happy for Perl to continue parsing logfiles. Perl has always been, and always will be (I hope), a humble language. When I am 80 years old, even if everyone in the whole world puts me on a pedestal and thinks I'm the renaissanciest man that ever lived, I still intend to take out the trash when my wife asks me to. Just because I'm learning Japanese doesn't mean I have to stop speaking English.

But just as people grow (and are stretched), Perl continues to grow (and be stretched). Perl has acquired new skills over the years, and people have been using Perl to do all sorts of things that are arguably at the limits of its capabiliites. The solution to that is not to stop people from doing that, but to increase Perl's dynamic range.

The thing is, people are already building more advanced applications with Perl. But there are some aspects of that process that aren't as easy as they could be. They're hard. In times past we were proud of the fact that the hard things were even possible with Perl5. We often chant the slogan: "Easy things should be easy, and hard things should be possible."

But as with any slogan, there are some qustionable assumptions hidden behind the sentiment. We assume that it's obvious which things should be easy or hard, and that the things that are currently easy are the things that ought to be easy. We assume that making the hard things easy will necessarily cause the easy things to become hard. But sometimes it's not obvious what should be easy or hard. Sometimes the wrong things are easy. And sometimes there are ways to make the hard things easier without making the easy things harder.

Some of the complexity in a Perl5 program is necessary to the solution, and some of it isn't. We can't eliminate the necessary complexity, but we can hope to get rid of some of the needless complexity. That will make everything easier. Well, most everything...

I'm really under no illusions that we can make everything easier at once. There's no such thing as a perfect language. Merely making a more expressive language means it's in some sense more difficult to learn to express yourself responsibly. That's the price of power. Manhattan will always be more difficult to understand than a set of beads.

But in any event, let me assure you that Perl6 will not be as difficult to learn as Japanese. :-)

2) Perl Beginners
by KoopaTroopa

I'm a CS student who's recently become very interested in Perl along with other languages. However, I don't really have too much everyday (or even occasional) need to actually USE much Perl. I am big into learning as much as I can about it for its own sake.

Now, for the question: Given this approach to learning Perl (just for a general working knowledge, maybe light usage,) is it really worth spending a lot of my time learning Perl now, or should I wait for the big Perl6 revision?

A:

I don't think you would be damaged by learning Perl5, though I'm sure there are those who would disagree--or at least choose to be disagreeable.

It really depends on your curiosity level, I think. Some people would learn both Perl5 and Perl6 merely to see how a language design evolves over time. Those folks are pretty hardcore. Count yourself lucky if you're not one of them. But despite appearances, Perl5 isn't a totally horrible language, and we're hoping to save all the good bits of it in Perl6. People moving from Perl5 to Perl6 shouldn't find it too difficult to unlearn the naughty bits, especially since it's the naughty bits that tend to be frustrating. And if you're ever in a situation where you need to use Perl6 for real, it's likely you'll have to deal with legacy Perl5 code anyway. So as usual the answer is: "It depends..."

Gildor was silent for a moment. 'I do not like this news,' he said at last. 'That Gandalf should be late, does not bode well. But it is said: Do not meddle in the affairs of wizards, for they are subtle and quick to anger. The choice is yours: to go or wait.'

'And it is also said,' answered Frodo: 'Go not to the Elves for counsel, for they will say both no and yes.'

'Is it indeed?' laughed Gildor. 'Elves seldom give unguarded advice, for advice is a dangerous gift, even from the wise to the wise, and all courses may run ill. But what would you? You have not told me all concerning yourself; and how then shall I choose better than you? But if you demand advice, I will for friendship's sake give it. I think you should now go at once, without delay; and if Gandalf does not come before you set out, then I also advise this: do not go alone. Take such friends as are trusty and willing. Now you should be grateful, for I do not give this counsel gladly.'

3) Structured programming and perl
by slashnot007

The reason I like perl is it is not a structured programming language. In my work I find it is 50% a get the job done parsing language and 25% sequencer of programs and deamons and 25% major ojbect oriented programming effort often a cgi.

Thus I worry that perl has Python-envy. I've tried to use python several times but always go back to perl. The reason is my daily need for a parser dominates my choice of language and maintains my fluency, since I dont want to have to be fluent in both, perl becomes my language of choice for advanced tasks too, even though python might be better for strcutrued programming.

So my question is, is perl6 making make perl a structued language like python? Would it be a good idea if perl did not develop any further for fear of becoming too complicated and thus disorganized? (witness the evolution of java from clean slate to giant mess with intricate redundant libraries half of which are deprecated).

A:

Er, what do you mean by "structured"? 25 years ago all of these languages would have been considered "structured", in the sense that a block generally has only one entrance point. (There were also people who thought that a block should only have one exit. Thankfully these folks did not prevail, since functions representing decision trees often have one entry but multiple exit points.)

But you obviously mean "structured" in a different sense, or perhaps several different senses. Syntax is structure, and different languages have different syntax, but I don't think that's what you mean.

I'll assume you mean "structured" the way a grade school teacher means it, as in "structured play time", as opposed to "free play time". Python's slogan is "There's only one obvious way to do it." That's fine from the computer's viewpoint, but kinda sucks from the human viewpoint. "You can play any game you like, as long as it was organized by the teacher."

Java was, in that sense, much less structured than Python, I think. That's part of the reason for Java's success, but it came at a price. One of the problems with Java is that they swept a bit too much of the innate complexity of life under the carpet of the libraries. And so now they've had to replace the carpets several times.

So, yes, Java started with a "clean slate", but it was a rather undersized slate, methinks. But as for "structured play time" in Java, the structure has been imposed more by cultural norms than by the language itself.

As for Perl, it has never been "structured" in that sense, though it has always been structured in the sense that you can create as much structure as you like. The whole point is that the structure is optional, not imposed externally. If you're playing with your schoolmates at recess, you can always choose to organize a football game, but the teacher isn't making you do that.

Playing football is like programming in the large. You have to agree on a lot of rules to do it with other people. Perl5 doesn't make it terribly easy to agree on a set of rules, and we hope to make that easier in Perl6. You have to have discipline to do programming in the large, but you'll choose the discipline by turning up the big discipline knob yourself, not by having someone else turn it up for you. Perl6 will give you the big knob.

I am philosophically opposed to turning up the knob for you, because I don't know how fast you want it turned up. (Perl6 will turn it up for you a little by default--if you write a module or class, it'll automatically default to a stricter mode than it uses for your main program.) But the reason I don't like doing it for you is that you know how fast you want to learn, and I don't. As Gildor says, you haven't told me enough about yourself for me to give you advice. If I don't know how hard you can paddle, I can't tell you how big of a wave to try to catch. We all have to start with the small waves.

We find the same problem in teaching reading to kids. Some people shout "Whole language!" while others shout "Phonics!" Well, guess what, they're both oversimplifying. You have to learn some phonics, and then you learn some larger bits based on that, and some larger bits based on that, and eventually you find that you're intuiting whole language. The whole language folks fall into what I call the "Expert Fallacy". You look at how experts do something, and assume that's how everyone should do it. There are some people who are natural readers. They naturally figure out the bits and pieces themselves. But if you try and teach everyone that way, half your kids never figure out the phonics.

Programming is the same way. Language designers tend to look at how experts program and then think that everyone ought to learn to program that way from the start. That's a bit like expecting a new surfer to do well on 40 foot waves. Some will make it, but most will wipe out.

Perl is designed to help people learn the bits of programming they need right now without forcing them to learn the techniques they aren't ready for. But when they are ready for them, Perl tries to be there too. We just don't tell the beginners that the speedometer on their golf cart wraps around several times.

4) What will you *not* put into Perl 6?
by TreyHarris

What would you say has been the number one requested feature that you will not put into Perl6, and why not?

A:

That depends on what you call a feature, and what you call a request. If you look at all the RFCs at dev.perl.org, you'll find that most of the feature requests are bogus on some level or other because they tend to suggest bandaid solutions. Nevertheless, I think it's best to treat them all as a "cry for help". With computer languages, about 75% of the bandaids have a bullet hole underneath.

So, for instance, I officially rejected the RFC asking for multiline comments, while actually accepting the underlying premise that it was too difficult to do block comments. But the better solution is not to introduce more syntax, but to fix the POD syntax to do what people want.

But this is Perl, after all, so there has to be more than one solution. The other solution is to make the Perl grammar malleable enough that the user can install their own multiline comment mechanism anyway via a pragma, so there! That's fine by me, as long as the syntactic warpage is lexically scoped. "All is fair if you predeclare."

Another often-requested feature that's not going into Perl6 is implicit lexical declarations. That's one of those features that seems like a good idea when you're looking at small snippets of code, but it breaks down when the scopes get larger than you can see in a glance. Scoping by indentation has the same problem, but nobody has seriously requested that for Perl6, for some strange reason...

Now you might think that getting rid of the $, @, and % sigils would be the number one requested feature, but typically that is suggested only by people who don't know Perl and probably wouldn't use Perl even if we did get rid of them. The folks who know Perl tend to like the sigils.

5) perl vs other languages
by larry bagina

Whenever perl pops up in slashdot, there are plenty of language zealots claiming perl is obsolete and you should really be using php or ruby or python instead.

What are your thoughts on these other scripting languages? What do you like about them, what do you dislike?

A:

Well, in general, the thing I don't like about other computer languages is that they're not Perl. :-)

Seriously, Perl matches the way I think pretty well, because what I mostly want in a computer language is a wide dynamic range. I want a language in which you can say both dirty, low-level stuff and fancy, high-level stuff. I want a language where both baby-talk and fluency are acceptable. Other computer languages tend to try to level those distinctions.

As for specifics, I must say that the example of Ruby is the main reason I decided against implicit lexical scoping for Perl6. We'll be sticking with explicit my declarations. But I have to like the majority of Ruby simply because that's the part that was borrowed straight out of Perl. :-)

I also liked Ruby's unary splat operator, so I borrowed it for Perl6.

The main problem I see with Ruby is that the Principle of Least Surprise can lead you astray, as it did with implicit lexical scoping. The question is, whose surprise are you pessimizing? Experts are surprised by different things than beginners. People who are trying to grow small programs into large programs are surprised by different things than people who design their programs large to begin with.

For instance, I think it's a violation of the Beginner's Principle of Least Surprise to make everything an object. To a beginner, a number is just a number. A string is a string. They may well be objects as far as the computer is concerned, and it's even fine for experts to treat them as objects. But premature OO is a speed bump in the novice's onramp.

I confess, I have a soft spot in my heart for inside-out languages like PHP. The first real compiler I ever wrote was for a sort of text-processing macro language in which the commands were embedded in the data. This is part of a more general class of programming languages in which a peculiar form of processing is assumed by default, such as the pattern/action syntax of awk that assumes an invisible outer loop.

Perl can do that, but it's not the default. I think languages like awk and PHP hobble themselves in the long run by attaching themselves to a particular ecological niche, particularly when a generalist like Perl can effectively occupy the same niche. So I've never felt tempted to even try PHP. I'd only be speaking second-hand if I said that PHP has some serious namespace and extension mechanism issues. So I won't say that. :-)

Python is cool to look at small bits of, but I think the "outline" syntax breaks down with larger chunks of code. I'm with Aristotle on the structure of discourse--a story should have a beginning, and middle, and an end. So should blocks.

There's something to be said for forcing everyone to code in the same style, but that's not the Perl Way. At least, it's not the default Perl Way. But all is fair if you predeclare. It's perfectly fine for you to import a pragmatic module that enforces a certain style policy. It's even fine if your company forces you to import that pragma. Of course, if you want real programming discipline, I'd suggest you use Damian's Klingon module...

6) Perl and .NET
by prostoalex

What is your opinion of .NET in general and Perl's role in it? Given that .NET supports Perl as one of the languages would you recommend actually using it for any projects? Do you see good future for this tandem?

A:

As far as I'm concerned, .NET is just another architecture that we need to port Perl to run on natively. The current approach to .NET interoperability is a bit of a hack, I think. That is partly Perl's fault for not having a sufficiently powerful type declaration system, but it's also a problem that .NET doesn't really support dynamically typed languages very well. I foresee that we'll have something like a Parrot interface that functions as a (hopefully thin) layer of glue over other VMs such as .NET or Java machines. The less impedence mismatch there is, the thinner the layer can be.

I recommend that you use Perl where it makes sense to use Perl, and avoid using it where it doesn't make sense. I am not the judge of whether it makes sense to use Perl on .NET, simply because I'm way too ignorant and stupid to be making those kinds of decisions for you. Sorry.

As for the future, I really don't know. Long, long ago (when our galaxy was far away) I shoehorned Perl and Java into the same process, and it never aroused much excitement. Certainly the Java folks tend to turn up their noses at non-100% Java solutions, but it got a pretty chilly reception from the other end as well. By and large, Perl programmers don't seem to have much appreciation for Java. I think the language architects who aren't living in reality tend to like multi-language solutions a lot more than ordinary folks do.

Which is, of course, why we're doing exactly the same thing with Parrot. Go figure. :-)

6.5) From a project managers prospective
by mustangdavis

What are your thoughts on the comments made by people that Perl is not designed for projects that require more than one programmer? Many people have stated over and over again that Perl code can not be managed by more than one person ... what are your thoughts on that statement? How would you manage a large Perl project? Do you think Perl should be used for large projects? (or should it be used strictly as a "quick and dirty" programming language?) BTW: I love your work (someone had to say it)

A:

I do not manage any large projects, appearances to the contrary notwithstanding. I haven't an executive bone in my body. All my managerial skills are delegated. Ask anyone I've delegated to...

However, those who claim that Perl code cannot be managed by more than one person are obviously smoking something worse than crack. They're simply ignoring the many examples of people who have done just that. But you wouldn't expect to hire random people off the street to come in and collaborate on writing a novel. You can do it by hiring a few good novelists who already know how to figure out how to work together, or at least how to fight with each other productively. In the absence of that level of expertise, you can also do it by setting up policies under which random people can work, rather like the rules for writing about the world of Liavek, in which, for instance, every story has to mention a camel.

That being said, there are things we can do to make Perl6 better at helping managers and architects set up such policies for programming in the large. Having a standardized opaque object type will help there as well. Nobody is going to claim that Perl6's OO is "bolted on". Well, except maybe for certain Slashdotters who don't know the difference between rational discussion and cheerleading...

7) Role of Religion?
by Anonymous Cowdog

I remember reading at some point that you are a Christian, and there have been suggestions that some of your early missionary impulses (a desire to do good, help others) are perhaps part of the zeal you have put into Perl over the years.

Preferring a scientific view, I am not religious, and have no desire to be. Perhaps there is a God, but if there is, I think he/she has no opposable thumbs; in other words, has no power to change anything; reality is just playing out according to the laws of physics (whatever those are).

Please tell us how in the world a scientific or at least technical mind can believe in God, and what role religion has played in your work on Perl.

A:

Well, hmm, that's a topic for an entire essay, or a book, or a life. But I'll try to keep it short.

When you say "how in the world", I take it to mean that you find it more or less inconceivable that someone with a scientific mind (or at least technical mind, hah!) could chooose to believe in God. I'd like to at least get you to the point where you find it conceivable. I expect a good deal of the problem is that you are busy disbelieving a different God than the one I am busy believing in. In theological discussions more than any other kind, it's easy to talk at right angles and never even realize it.

So let me try to clarify what I mean, and reduce it to as few information bits as possible. A lot of people have a vested interest in making this a lot tougher to swallow than it needs to be, but it's supposed to be simple enough that a child can understand it. It doesn't take great energetic gobs of faith on your part--after all, Jesus said you only have to have faith the size of a mustard seed. So just how big is that, in information theory terms? I think it's just two bits big. Please allow me to qoute a couple "bits" from Hebrews, slightly paraphrased:

You can't please God the way Enoch did without some faith, because those who come to God must (minimally) believe that:
A) God exists, and
B) God is good to people who really look for him.

That's it. The "good news" is so simple that a child can understand it, and so deep that a philosopher can't.

Now, it appears that you're willing to admit the possibility of bit A being a 1, so you're almost halfway there. Or maybe you're a quarter way there on average, if it's a qubit that's still flopping around like Shoedinger's Cat. You're the observer there, not me--unless of course you're dead. :-)

A lot of folks get hung up at point B for various reasons, some logical and some moral, but mostly because of Shroedinger again. People are almost afraid to observe the B qubit because they don't want the wave function to collapse either to a 0 or a 1, since both choices are deemed unpalatable. A lot of people who claim to be agnostics don't take the position so much because they don't know, but because they don't want to know, sometimes desperately so.

Because if it turns out to be a 0, then we really are the slaves of our selfish genes, and there's no basis for morality other than various forms of tribalism.

And because if it turns out to be a 1, then you have swallow a whole bunch of flim-flam that goes with it. Or do you?

Let me admit to you that I came at this from the opposite direction. I grew up in a religious culture, and I had to learn to "unswallow" an awful lot of stuff in order to strip my faith down to these two bits.

I tried to strip it down further, but I couldn't, because God told me: "That's far enough. I already flipped your faith bits to 1, because I'm a better Observer than you are. You are Shroedinger's cat in reverse--you were dead spiritually, but I've already examined the qubits for you, and I think they're both 1. Who are you to disagree with me?"

So, who am I to disagree with God? :-) If he really is the Author of the universe, he's allowed to observe the qubits, and he's probably even allowed to cheat occasionally and force a few bit flips to make it a better story. That's how Authors work. Whether or not they have thumbs...

Once you see the universe from that point of view, many arguments fade into unimportance, such as Hawking's argument that the universe fuzzed into existence at the beginning, and therefore there was no creator. But it's also true that the Lord of the Rings fuzzed into existence, and that doesn't mean it doesn't have a creator. It just means that the creator doesn't create on the same schedule as the creature's.

If God is creating the universe sideways like an Author, then the proper place to look for the effects of that is not at the fuzzy edges, but at the heart of the story. And I am personally convinced that Jesus stands at the heart of the story. The evidence is there if you care to look, and if you don't get distracted by the claims of various people who have various agendas to lead you in every possible direction, and if you don't fall into the trap of looking for a formula rather than looking for God as a person. All human institutions are fallible, and will create a formula for you to determine whether you belong to the tribe or not. Very often these formulas are called doctrines and traditions and such, and there is some value in them, as there is some value in any human culture. But they all kind of miss the point.

"Systematic theology" is an oxymoron. God is not a system. Christians are fond of asking: "What would Jesus do in this situation?" Unfortunately, they very rarely come up with the correct answer, which is: "Something unexpected!" If the Creator really did write himself into his own story, that's what we ought to expect to see. Creative solutions.

And this creativity is intended to be transitive. We are expected to be creative. And we're expected to help others be creative.

And that leads us back (finally) to the last part of your question, how all this relates to Perl.

Perl is obviously my attempt to help other people be creative. In my little way, I'm sneakily helping people understand a bit more about the sort of people God likes.

Going further, we have the notion that a narrative should be defined by its heart and not by its borders. That ties in with my linguistic notions that things ought to be defined by prototype rather than by formula. It ties in to my refusal to define who is or is not a "good" Perl programmer, or who exactly is or isn't a member of the "Perl community". These things are all defined by their centers, not by their peripheries.

The philosophy of TMTOWTDI ("There's more than one way to do it.") is a direct result of observing that the Author of the universe is humble, and chooses to exercise control in subtle rather than in heavy-handed ways. The universe doesn't come with enforced style guidelines. Creative people will develop style on their own. Those are the sort of people that will make heaven a nice place.

And finally, there is the underlying conviction that, if you define both science and religion from their true centers, they cannot be in confict. So despite all the "religiosity" of Perl culture, we also believe in the benefits of computer science. I didn't put lexicals and closures into Perl5 just because I thought people would start jumping up and down and shouting "Hallelujah!" (Which happens, but that's not why I did it.)

And now let's all sing hymn #42...

8) Thanks Larry
by wdr1

Like many others, I love Perl. I use it both professionally and personally. You've not only helped make my career, but also given me a very pleasent past-time. I was wondering what I can do to say thank-you? Can we give you money? Dontate something to someone, etc.?

When the new Programming Perl came out, I didn't really need anymoe (viva perldoc!), but wanted to make sure I was putting a few bucks in the pockets of those who made Perl great. What else can I do to say thanks?

A:

Hmm, what timing! You must be from one of those churches where they pass the offering plate right after the sermon... :-)

Even just saying thanks is much appreciated. But if you want to help out more, there are lots of places to donate time or money. Unfortunately, it takes time to figure out how to donate time, since you have to hang out with various interest groups until you get, er, interested in one of them. But it's part of Perl culture to value contributions to Perl culture, so don't hold back just because your contribution is not somehow technical. That's not how we work.

Donating money is easy (except, of course, for the money part). Tax-deductible contributions can be made to the Perl Foundation. Much of my support for this year has come through the Perl Foundation--my full-time work on the Apocalypses would have been impossible without it. If you can persuade the companies you work for to make donations or to match your donations, that's also a worthwhile investment of time (and in some cases, agony). Please allow me to express my sincere gratitude here for everyone who has contributed already. This program is made possible by viewers like you.

9) perl 6 niche
by maraist

perl 1-5 have been great UNIX configuration/management languages. This includes small-scale webserver platforms. It's very difficult to find any other language that is as versitile in this respect where it reigns in it's niche. It is the perfect combination of speed, power, simplicity and huffman encoding (especially given the co-UNIX-tools look-and-feel).

Perl6 on the other hand, changes this formula around; favoring a more general solution that potentially reduces performance (due to abstractions), and deviates substantially from the UNIX-family-syntax - Namely: c-ish-syntax ( colon, question mark, select, exception-handling, etc), awk/sedish reg-ex's, raw c-libray-wrappers, etc. It was these very similarities that made learning and accepting perl so trivial since learning CIS and UNIX administration was sufficient to master perl in 2 days.

My question is: does perl6 have a niche in mind? Or is it spreading itself too thinly; competing more and more against Java/python/C# and thus losing it's identifiable niche?

A:

Excellent question. I love the evolutionary biologists' way of talking about organisms as if they're evolving on purpose: "I think I'll develop feathers now and become a bird...", though in Perl's case, of course, there is some amount of purpose in my head (some would say "not enough"), not to mention the heads of other Perl developers (some would say "too much" (or is it the other way around?)), but it's still great fun to talk about Perl as if it were its own beastie, or as if it were a character in a novel that runs away with the plot despite the intentions of the author, kinda like this sentence has.

Anyway, from the start, Perl has never really been satisfied with staying in any one particular ecological niche. That's not terribly healthy approach in evolutionary terms, especially when your niche goes away. Perl's been pretty lucky so far to land in stable niches, but if some of its current niches dry up someday, that's really only to be expected, and indeed almost hoped for. It's probably the fault of closing ecological niches that we aren't all still swinging from trees, after all. (Of course, some of us still are, but that portion of us isn't heavily represented on Slashdot. Er...appearances to the contrary notwithstanding.)

Perl started out as just a text processing language--a better awk and sed--but it very rapidly spread to the ecological niche of system administration. On Unix, at least, a lot of system administration is text processing. With version3, however, Perl very intentionally escaped the text-processing-only niche by adding the capability to process binary data. Perl4 UNintentionally spread from the sysadmin niche into the CGI/Web niche. Perl5 accellerated that trend by intentionally occupying the extensible-glue-language niche, which had the unforeseen (by me) but predictable result of enabling Web sites to hook all their backend databases to the various textual Internet protocols.

But if you're worried about Perl trying to inhabit the "good for everything" niche, that's actually been Perl's intention since Perl5 came out. After all, you can't add OO to any language without making it perfect. ;-)

Seriously, I think that, for many of the people who use Perl today, the ecological niche they're thinking of is already labeled "everything", even if it isn't quite. For those folks, trying to make Perl better for the "everything" niche is not really an issue--they're already panting for it. These are the people who will actually carry Perl over to the next ecological niche it spills into, and the ones after that. I just made Perl a glue language, and other people applied it to bootstrapping the Web. Making Perl the best tool for growing programs from small to large is actually one of the underlying design goals of Perl6. But other people will use that to inhabit, or even create, other ecological niches. I hope to be surprised again as I was with the Web. I could, of course, be completely wrong.

10) How to get people to take Perl seriously
by kin_korn_karn

I'm a perl programmer who uses it daily. The push is on from the C?O types to get rid of Perl, even though a bunch of us here know it and are very proficient and fast with it. The new standard is Java with web services and all that other BS. This sickens me, because a) I'm biased towards Perl and b) I know Java is simply a fad language and the overhead/infrastructure only serves to give do-nothing architect types jobs.

The high-level technical people in my company don't take Perl seriously. They see it as some kind of super-Awk or an artifact of the early days of the web. Smart people know better, but we're not in charge.

What do you think it would take to get people to take Perl seriously as a programming language [again]? Is widespread use of Perl a goal of yours, or do you not care?

A:

Well, if Java really is a "fad" language, we don't have to do anything to beat it, now do we? :-)

Leaving that aside, my goal is (and has always been) for Perl to be as useful as possible. It naturally follows that if people are avoiding Perl for artificial reasons, Perl is not being as useful as possible. So there's a place for advocacy. It is an unfortunate fact that, human nature being what it is, an ounce of cheerleading often beats a pound of rational discussion.

However, my job is not to lead cheers, but to make sure that Perl is designed to be maximally useful. It has never been a direct goal of mine to be "taken seriously". For good or ill, I am composed of far more levity than gravity. And I'm afraid some of that rubs off on Perl, too. But if Perl is everything it ought to be, it will naturally attract serious attention over the long term. If ecological niches are natural, and if nature abhors a vacuum, it follows that ecological niches abhor vacuums too. I expect to hear some great sucking sounds over the next ten or twenty years.

When direct database access to the information you need isn't available, but web pages with the right data are, you might pursue "screen-scraping" -- fetching a web page and scanning its text for the appropriate pieces of text in order to do further processing. LWP (Library for WWW access in Perl) is a collection of module to help you do this. mir writes: " Perl & LWP is a solid, no-nonsense book that will teach you how to do screen-scraping using Perl. It describes how to automatically retrieve and use information from the web. An introduction to LWP and related modules from simple to advanced uses and various ways to extract information from the returned HTML." Perl & LWP author Sean M. Burke pages 264 publisher O'Reilly and Associates rating 9 reviewer mir ISBN 0596001789 summary Excellent introduction to extracting and processing information from web sites.

The good: The book has a nice style and good coverage of the subject, includes introduction to all the modules used, reference material and includes good, well-developed examples. I really liked the way the authors describe the basic methodology to develop screen-scraping code, from analyzing an HTML page to extracting and displaying only what you are interested in.

The bad: Not much is bad, really. Some chapters are a little dry, though, and sometimes the reference material could be better separated from the rest of the text. The book covers only simple access to web sites; I would have liked to see an example where the application engages in more dialogue with the server. In addition, the appendixes are not really useful. More Info:

If it had not been published by O'Reilly, Perl and LWP could have been titled Leveraging the Web: Object-Oriented techniques for information re-purposing, or Web Services, Generation 0. An even better title would have been Screen-scraping for fun and profit: one day we might all use Web Services and easily get the information we need from various providers using SOAP or REST, but in the meantime the common way to achieve this goal is just to write code to connect to a web server, retrieve a page and extract the information from the HTML. In short, "screen-scraping." This will teach you all about using Perl to get Web pages and extract their "substantifique moëlle" (the pith essence, the essentials) for your own usage. It showcases the power of Perl for that kind of job, from regular expressions to powerful CPAN modules.

At 200 pages, plus 40 pages of appendices and index, this one is part of that line of compact O'Reilly books which covers only a narrow topic in each volume but which covers those topics well. Just like Perl & XML , its target audience is Perl programmers who need to tackle a new domain. It gives them a toolbox and basic techniques that to provide a jump start and avoid many mistakes.

Perl & LWP starts from the basics: installing LWP, using LWP::Simple to retrieve a file from a URL, then goes on to a more complete description of the advanced LWP methods for dealing with forms and munging URLs. It continues with five chapters on how to process the HTML you get, using regular expressions, an HTML tokenizer and HTML::TreeBuilder, a powerful module that builds a tree from the HTML. It goes on with an explanation of how to allow your programs to access sites that require cookies, authentication or the use of a specific browser. The final chapter wraps it all up in a bigger example: a web-spider.

The book is well-written and to-the-point. It is structured in a way that mimics what a programmer new to the field would do: start from the docs for a module, play with it, write snippets of code that use the various functions of the module, then go on to coding real-life examples. I particularly liked the fact that the author often explains the whys, and not only the hows, of the various pieces of code he shows us.

It is interesting to note that going from regular expressions to ever more powerful modules is a path followed also by most Perl programmers, and even by the language itself: when Perl starts being applied to a new domain first there are no modules, then low-level ones start appearing, then, as the understanding of the problem grows, easier-to-use modules are written.

Finally I would like to thank the author for following his own advice by including interesting examples and above all for not including anything about retrieving stock-quotes.

Another recommended book on the subject is Network Programming with Perl by Lincoln D. Stein, which covers a wider subject but devotes 50 pages to this topic and is also very good.

Breakdown by chapter:

• 1. Introduction to Web Automation (15 pages): an overview of what this book will teach you, how to install Gisle Aas' LWP, some interesting words of caution about the brittleness of screen-scraping code, copyright issues and respect for the servers you are about to hammer, and finally a very simple example that shows the basic process of web automation.

  2. Web Basics (16p): describes how to use LWP::Simple, an easy way to do some simple processing.

  3. The LWP Class Model (17p): a slightly steeper read, closer to a reference than to a real introduction that lays out the ground work for the good stuff ahead.

  4. URLs (10p): another reference chapter, this one will teach you all you can do with URLs using the URI module. Although the chapter is clear and complete it includes little explanation as to why you will need to process URLs and it is not even mentioned in the introduction roadmap.

  5. Forms (28p): a complete and easy to read chapter. It includes a long description of HTML form fields that can be used as a reference, 2 fun examples (how to get the number of people living in any city in the US from the Census web site and how to check that your dream vanity plate is available in California) and how to use LWP to upload files to a server. It also describes the limits of the technique. I appreciated a very educative section showing how to go from a list of fields in a form to more and more useful code that queries that form.

  6. Simple HTML processing with Regular Expressions (15p): how to extract info from an HTML page using regexps. The chapter starts with short sections about various useful regexp features, then presents excellent advice on troubleshooting them, the limits of the technique and a series of examples. An interesting chapter, but read on for more powerful ways to process HTML. On the down side, I found the discussion of the s and m regexp modifiers a little confusing.

  7. HTML processing with Tokens (19p): using a real HTML parser is a better (safer) way to process HTML than regexps. This chapter uses HTML::TokeParser. It starts with a short, reference-type intro, then a detailed example. Another reference section describes the methods an alternate way of using the module, with short examples. This is the kind of reference I find the most useful, it is the simplest way to understand how to use a module.

  8. Tokenizing walkthrough (13p) a long Example showing step-by-step how to write a program that extracts data from a web site, using HTML::TokeParser. The explanations are very good, showing _why_ the code is built this way and including alternatives (both good and bad ones). This chapter describes really well the method readers can use to build their code.

  9. HTML processing with Trees (16p): even more powerful than an HTML tokenizer: HTML::TreeBuilder (written by the author of the book) builds a tree from the HTML. This chapter starts with a short reference section, then revisits 2 previous examples of extracting information from HTML using HTML::TreeBuilder.

  10. Modifying HTML with Trees (17p): More on the power of HTML::TreeBuilder: a reference/howto on the modification functions of HTML::TreeBuilder, with snippets of code for each function I really like HTML::TreeBuilder BTW, it is simple yet powerful.

  11. Cookies, Authentication and Advanced Requests (13p): Back to that LWP business... this chapter is simple and to-the-point: how to use cookies, authentication and referer to access even more web-sites. I just found that it lacked a description on how to code a complete session with cookies.

  12. Spiders (20p): a long example describing how to build a link-checking spider. It uses most of the techniques previously described in the book, plus some additional ones to deal with redirection and robots.txt files.

• Appendices

  I think the Appendices are actually the weakest part of the book, most of them are not really useful, apart from the ASCII table (every computer book should have an ASCII table IMHO ;--).

  • A. LWP modules (4p): the list and one line description of all modules in the LWP library, long and impressive! But not very useful,
  • B. HTTP status (2p): available elsewhere but still pretty useful,
  • C. Common MIME types (2p): lists both the usual extension and the MIME type,
  • D. Language Tags (2p): the author is a linguist ;--)
  • E. Common Content Encodings (2p): character set codes,
  • F. ASCII Table (13p): a very complete table, includes the ascii/unicode code, the corresponding HTML entity, description and glyph,
  • G. User's View of Object-Oriented Modules (11p): this is a very good idea. A lot of Perl programmers are not very familiar with OO, and in truth they don't need to be. They just need the basics of how to create an object in an existing class and call methods on it. I found the text too be sightly confusing though, in fact I believe it is a little too detailed and might confuse the reader.
  • Index (8p): I did not think the index was great (code is listed with references to 5 seemingly random pieces of code, type=file, HTML input element is listed twice, with and without the comma...), but this is not the kind of book where the index is the primary way to access the information. The Table of Content is complete and the chapters are focused enough that I have never needed to use the index.

You can purchase Perl & LWP from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

BorrisYeltsin writes "The Parrot project has just released a functional compiler for Parrot. Almost all of the previous Apocalypses have been implemented as well as some other toys, including but not limited to: Ruby and Python parsers, BASIC and Scheme interpreters and a Forth compiler, the team are now working on Perl 6 regexes. Check it out at cvs.perl.org."

mbadolato writes "I'm surprised this hasn't been reported yet. Over at use.perl they're reporting that when the current issue of SysAdmin comes out, this will be the last installment of The Perl Journal. It's a shame. TPJ originally was stopped as a stand-alone, but was then included into Sysadmin. Now that's going too. We all owe a big thanks to all the contributers, and to Jon Orwant, for providing us a great resource in TPJ over the years."

mbadolato writes "I'm surprised this hasn't been reported yet. Over at use.perl they're reporting that when the current issue of SysAdmin comes out, this will be the last installment of The Perl Journal. It's a shame. TPJ originally was stopped as a stand-alone, but was then included into Sysadmin. Now that's going too. We all owe a big thanks to all the contributers, and to Jon Orwant, for providing us a great resource in TPJ over the years."

passthecrackpipe writes "Leonard Lin has put up the presentation Lawrence Lessig gave at OSCON (mirror). It is great. It requires Flash." Nice Flash work, very impressive, and of course Lessig is a superior speaker. Worth your time and the 8Mb download.

twoshortplanks writes "The latest version of Perl has been released, with new features such as better Unicode support, a new threads implementation, new IO layer support, and a whole plethora of bundled modules - plus a wonderful collection of regression tests and new documentation. The release notes and links to mirrors for download are on dev.perl.org." This is not a release candidate, it's the real thing, representing over two years of work by patch pumpkin holder Jarkko Hietaniemi and his merry band. Hugo van der Sanden is the new pumpking for perl 5.10.

caseywest writes "For those of you attending the Open Source Conference, there is a golden opportunity to get some free coaching and consultation on your work. A Birds-of-a-Feather session on "Perl Mentoring/Code Reviews" will be given for the third year running. Some of the top Perl People will be on hand as resident experts to advise you on your own Perl projects. This is *one-on-one* coaching: No spectators, no audience, no distractions; just the kind of personal mentoring, targeted to your specific application, from some of the best people qualified to give it. We encorage other communities to hold mentoring sessions, you still have time to register your BOF, email me if you want to make it happen and need advice. "

Here's how it works: You bring some Perl code (ideally at most 3 pages, as a printout, or on a laptop, handheld, or floppy) and receive specific advice which would normally cost a large amount of money in consulting fees. Feel free to ask for advice on anything from style to improving efficiency.

Time spent with the expert will depend on supply and demand.

Date: Thursday 7/25
Time: 7:00pm - 9:00pm
Location: Grande Ballroom A in the East Tower"

dogma01 writes "It looks like the grants to fund: Larry, Damian, and Dan have pretty much run out. :(" Keeping guys like these working on Perl is definitely a good thing(tm) if you are looking to support the Open Source Community somehow. You can donate here if you are feeling generous.

Simon Cozens writes "The Apocalypses are Larry Wall's explanation of the design of Perl 6. In Apocalypse 5, Larry turns to redesigning regular expressions. He set out to intentionally 'break' a lot of the regular expression culture we're all used to, and these are the results - and they're mindblowing."

mbadolato writes "use Perl; is reporting that the long-awaited Perl 5.8 has just been released in the form of RC1. It is a release candidate, and is not recommended for use in a production environment, but downloading and testing is strongly encouraged. Read the story for the announcement, and also read perldelta to see what's changed." I think this might be the best .0 release in Perl 5's history, and is will also be the first release of perl to ship with full support for Mac OS X (perl 5.6.1 had a few nagging issues), as well as Classic Mac OS.

mbadolato writes "use Perl; is reporting that the long-awaited Perl 5.8 has just been released in the form of RC1. It is a release candidate, and is not recommended for use in a production environment, but downloading and testing is strongly encouraged. Read the story for the announcement, and also read perldelta to see what's changed." I think this might be the best .0 release in Perl 5's history, and is will also be the first release of perl to ship with full support for Mac OS X (perl 5.6.1 had a few nagging issues), as well as Classic Mac OS.

mbadolato writes "Use.perl is running an interview with Larry Wall and Damian Conway, in which they answer questions about Perl 6. Questions were selected by the ten highest rated questions posed by readers last week."

mbadolato writes "Use.perl is running an interview with Larry Wall and Damian Conway, in which they answer questions about Perl 6. Questions were selected by the ten highest rated questions posed by readers last week."

mbadolato writes "Use.perl is running an interview with Larry Wall and Damian Conway, in which they answer questions about Perl 6. Questions were selected by the ten highest rated questions posed by readers last week."

Krellis writes: "The Perl Foundation today announced that they have awarded a Perl Development Grant to Larry Wall, the creator of Perl and designer of Perl 6, joining Dan Sugalski and Dr. Damian Conway, the other 2002 grant recipients. The Perl Development Grants are funded by donations; over USD 80,000 has been donated so far, a total of USD 240,000 is needed for the three grants. See http://donate.perl-foundation.org/ for more information on how you can pitch in - every dollar counts! See also the use.perl.org story for more information."

howardjp writes: "The Perl Mongers have announced that they are starting a new magazine called The Perl Review (not to be confused with the literary journal Pearl). Its first issue was published on 1 February in PDF-only format, but the article 'Extreme Publishing' describes the process by which they plan to expand. With The Perl Journal's future still somewhat in doubt, this is welcome news."

howardjp writes: "The Perl Mongers have announced that they are starting a new magazine called The Perl Review (not to be confused with the literary journal Pearl). Its first issue was published on 1 February in PDF-only format, but the article 'Extreme Publishing' describes the process by which they plan to expand. With The Perl Journal's future still somewhat in doubt, this is welcome news."

paulywog writes: "It hasn't been posted to the YAPC website yet, but the announcement was on usePerl this weekend. The site for the YAPC 2002 will be my alma mater, Washington University in St. Louis. Goofy name for a school in eastern Missouri, I know, but it's a great place for conferences. ... So, if you're in the St. Louis area and are a PERL fanatic, watch for upcoming information on yapc.org or the St. Louis Perl Monger's site." See also the Yet Another Society site.

paulywog writes: "It hasn't been posted to the YAPC website yet, but the announcement was on usePerl this weekend. The site for the YAPC 2002 will be my alma mater, Washington University in St. Louis. Goofy name for a school in eastern Missouri, I know, but it's a great place for conferences. ... So, if you're in the St. Louis area and are a PERL fanatic, watch for upcoming information on yapc.org or the St. Louis Perl Monger's site." See also the Yet Another Society site.

Puppet Master writes: "Just remembered that Perl was created on this day (12/18) in 1987 by Larry Wall..." Check out the Time Line and the discussion on use.perl.org and I'll take this chance as a reminder to donate to the Damian Conway/Dan Sugalski slavery fund.

Puppet Master writes: "Just remembered that Perl was created on this day (12/18) in 1987 by Larry Wall..." Check out the Time Line and the discussion on use.perl.org and I'll take this chance as a reminder to donate to the Damian Conway/Dan Sugalski slavery fund.

Thanks to Pudge of Slashteam for pointing out that very early version of Parrot has been released. You may recall Parrot from The April Fool's joke - but it's coming to life.

So, we've gotten a lot of submissions about various things related to the O'Reilly Open Source Convention. Michael Tiemann had a few words before the convention; Dan Gillmor wrote a column about it; Fred Baker made a few flameworthy remarks. For whatever reason the whole conference seemed to be dominated by the Mundie-Tiemann debate. See our earlier story for some good links, or watch the debate video, or just read some post-debate coverage here or here. And if you haven't heard enough from Mundie, you can even read his post-debate letter.

pudge (Slashcode wrangler, MacPerl maintainer, and use.perl editor) wrote in to tell us that The Perl Journal has been bought by CMP. This of course ends the ongoing struggles with Earthweb that has resulted in many subscribers (including me) going without what is one of the best technical journals being published today. CMP of course publishes several other good journals including Dr. Dobbs. Besides Jon Orwant (who will continue as Senior Contributing Editor) nobody is happier to see TPJ return then me!

pudge writes: "The Perl Journal is back in the hands of Jon Orwant, after a sorrowful chapter in the hands of EarthWeb. No details available yet, just the good news. He is now accepting article proposals for future issues, and Issue #20 will be printed and mailed soon." It's cool to see something decent being revived in a month when it seems like many companies are either failing or scaling back.

Pudge tells me that perl 5.6.1 is released. Tell your boss you won't get any work done today, you have to, er, upgrade your personal knowledgebase of evolving regularly expressional technology. Then test every one of the bugfixes, like ""a\nxb\n" =~ /(?!\A)x/m". Pick your favorite new feature or bugfix from the announcement and tell us about it.

chipmunk writes "My prayers have been answered! Larry and Guido have joined forces to produce Parrot, what will surely become the best language ever written. The power of Perl and the sanity of Python. The Py3K and Perl 6 development are merging, with Jeremy Hylton and Dan Sugalski as joint development leads. Read more in the press release on use Perl;, and see a joint interview on perl.com!"

It's about time. It's like the right brain and left brain are working together, at long last. O'Reilly has already inked a deal to publish Programming Parrot, and Yet Another Society is set to merge with the recently launched Python Software Foundation. Both Guido and Larry will be working for ActiveState.

antiher0 writes "The first beta of Perl::Flash is done! You can now use Perl to generate flash animations, etc. I've been waiting for something like this to come along :) BTW, be sure to check out the demo page. You can also check out the project breakdown here."

Chronic reviewer chromatic writes again, this time with a review of the newest iteration of what is probably the emblematic Perl book, the O'Reilly camel book. Read on to see how it stacks up to earlier versions of that work, and whether your Perl skills would benefit from reading through it.

Programming Perl (third edition) author Larry Wall, Tom Christiansen, & Jon Orwant pages 1067 publisher O'Reilly & Associates rating 9.5 reviewer chromatic ISBN 0-596-0027-8 summary The definitive guide to the Perl language, updated for 5.6.1.

The Scoop Longtime Perl fans know Programming Perl as the Camel, because of the cover animal. With the first edition in 1991, Perl programmers gained not only a charmingly appropriate mascot, but the ultimate language reference. True to form, this Camel's grown with the language. In the four years since the last release, it's increased in size by 67%.

Everything you liked about previous editions has returned, in one form or another. Additionally, this third edition covers the largest changes made for Perl 5.6 (actually 5.6.1, as the book's ahead of the current stable release by a bit) -- Unicode, threading, and more Perl guts.

While the previous editions were exceptionally well-written references, they were also aimed squarely at experienced programmers. This edition pushes back the starting blocks somewhat, providing a gentler introduction to the world of Perl. The wealth of new information is staggering, but as you'd expect from the luminous authors, even the core language reference is highly readable and entertaining.

What's to Like? Logically, the book is divided into five main sections. (Gone are the massive 80-page chapters of the second edition). The first section, one chapter, gives a good overview of Perl, as a language and a philosophy. It includes a quick introduction. The second section gives the language's gory details, covering just about everything you would need to know. It's arranged in terms of ascending complexity. The enhanced, extended, and improved regular expression chapter stands out as the best member of this group.

The third section discusses Perl as technology. Here's where Unicode comes in, as well as the internals of Perl (through the internal compilation process, using the debugger, or using XS to extend Perl with C code). Everything here is quite good. Expectably dry subjects like Unicode or threading are readable and even a little entertaining. If you're not convinced, you can skip around and still learn quite a bit.

The fourth section is devoted to Perl as culture, with discussions about portability, security, good practices, documentation, CPAN, and a bit of poetry. The security chapter is quite good, but left me wanting more information. Any chapter here is accessible if you've made it through the second section, so feel free to pick and choose what you need to know.

Rounding up the spare bits is the reference section. Not only will you find descriptions of the special variables, built-in functions, and standard library, but the organization and presentation of these descriptions has improved. Functions have little annotations listing which magic variables they set, possible exceptions they raise, and the like. That accounts for 150 pages of the overall goodness. Don't skip the glossary at the end, if you're confused or looking for amusement.

What's to Consider? While it's a temporary conundrum, it's a little odd to read about features that aren't quite implemented yet. This is most noticeable in the Unicode discussions and the chapter on threading. Occasionally, the authors will describe a feature and then admit that the specifics will likely change. (Have a look at the documentation.) Granted, the bulk of the language is mature and stable, and the definitive guide can't very well get by with ignoring major features, but it reads a little oddly.

The intended audience is still the serious Perl programmer. Dabblers and casual learners will find enlightenment and instruction. Realize, though, that while it's easier to start your journey here, absolute beginners would do well to explore a Learning Perl or Elements of Programming with Perl first. People who've programmed before (beyond dabbling with VB, or doing mouseovers in Web pages) should have little difficulty picking up the Perl language and mindset.

The only other possible improvement that comes to mind is expanding certain chapters. As noted before, there's more to say about security and efficiency. It would also be nice to have a chapter on common Perl idioms one might find in EFNet #Perl or at Perl Monks, or the latest Perl Mongers meeting. (Half of the fun is discovering and sharing new tricks and shortcuts.)

The Summary Part of being a good programmer is knowing where to turn for accurate and useful information. This is the place for all things Perl. If you use Perl regularly, put the new Camel on your shelf. Table of Contents

1. Overview
2. 1. An Overview of Perl
3. The Gory Details
4. 1. Bits and Pieces
   2. Unary and Binary Operators
   3. Statements and Declarations
   4. Pattern Matching
   5. Subroutines
   6. Formats
   7. References
   8. Data Structures
   9. Packages
   10. Modules
   11. Objects
   12. Overloading
   13. Tied Variables
5. Perl as Technology
6. 1. Unicode
   2. Interprocess Communication
   3. Threads
   4. Compiling
   5. The Command-Line Interface
   6. The Perl Debugger
   7. Internals and Externals
7. Perl as Culture
8. 1. CPAN
   2. Security
   3. Common Practices
   4. Portable Perl
   5. Plain Old Documentation
   6. Perl Culture
9. Reference Material
10. 1. Special Names
    2. Functions
    3. The Standard Perl Library
    4. Pragmatic Modules
    5. Standard Modules
    6. Diagnostic Messages
    
    Glossary
    Index

You can purchase this book at ThinkGeek.

maraist writes: "Larry Wall's Altanta Linux Showcase Talk on Perl 6 is now available. Highlights: Perl will be interpreted by Perl (syntax can look like any language), variables will be more localized and OO, more support of both low level and high level constructs, and the core will be streamlined."

Use Perl is reporting that Damian Conway has been sponsored by several companies and individuals (most impressively Black Star who donated half of the needed $55k). Now Damian can continue working on amazing perl projects like Quantum::Superpositions and Lingua::Romana::Perligata for the next year! Malicose noted that Damian sponsor page explains a bit more too.

jbc writes: "As discussed over at use Perl, the Perl community is attempting to raise US$55K in donations to support Perl überhacker Damian Conway for a year so he can devote himself to worthwhile pursuits related to Perl development. Thanks to a large donation from an as-yet-unnamed corporate donor, they're apparently already more than halfway there." Update: 10/15 11:31 PM by H : To actually give, go to the YAPC site.

qbasicprogrammer writes "The long awaited Perl 5.7.0 version has finally been released! Source code is available from CPAN. If you haven't upgraded yet, now is the time. In related news, development of Perl 6 is continuing swiftly as demonstrated by the Perl 6 Library." Check out the head's up story saying that it was coming - just a reminder this is *devel*. Don't play with it unless you know what you are doing.

qbasicprogrammer writes "The long awaited Perl 5.7.0 version has finally been released! Source code is available from CPAN. If you haven't upgraded yet, now is the time. In related news, development of Perl 6 is continuing swiftly as demonstrated by the Perl 6 Library." Check out the head's up story saying that it was coming - just a reminder this is *devel*. Don't play with it unless you know what you are doing.

qbasicprogrammer writes "The long awaited Perl 5.7.0 version has finally been released! Source code is available from CPAN. If you haven't upgraded yet, now is the time. In related news, development of Perl 6 is continuing swiftly as demonstrated by the Perl 6 Library." Check out the head's up story saying that it was coming - just a reminder this is *devel*. Don't play with it unless you know what you are doing.

Chris Nandor wrote in to tell us that Larry Wall has announced his vision for perl 6 as part of this keynote at the O'Reilly Open Source Convention. You can read an announcement at Perl.org or read Chris's summary of things (like information about the from-scratch rewrite being planned!)

The following was written by Chris "Pudge" Nandor... Perl Guru, Slashcode Guru, and all around swell guy.

Perl 6 To Be Complete Rewrite (But Not What You Think)

Larry Wall and other active Perl porters and Perl helpers met on Tuesday afternoon at Perl Conference 4.0 and mapped out a what is planned to become a complete rewrite of Perl that will become Perl 6 in 18 to 24 months, with a prerelease targeted for next year's conference.

Perl 5 will not be abandoned, but will primarily be concerned with bugfixes both major and minor.

The meeting for members of the perl5-porters mailing list was the result of an earlier, smaller meeting of Wall, Nathan Torkington, Chip Salzenberg, and others who basically decided that Perl needed to be fixed in certain ways, and that a rewrite was the best way to do it. Salzenberg started the Topaz project two years ago, to reimplement Perl in C++. Though Topaz itself will not be the basis for Perl 6, Salzenberg noted that the lessons learned in the experience will be very helpful to the new effort.

Torkington led the three-hour meeting, starting off by saying what was wrong with Perl. Much of the focus on the problems with Perl centered around how increasingly difficult it was to improve, extend, and embed Perl. A rewrite and redesign are needed, he said, and maybe it is time for a hard change. So while the focus of the effort seems to be on improving the Perl guts and API, the project will also be used as an opportunity to clean out some of the cruft, including bad and seldom-used features.

Some of the primary (and still vague) goals of the effort will be to reimplement the core so it is better, stronger, and faster; improve syntax; add new features where appropriate; have better version and installation management for perl and its modules; and have a clear and automated migration path, which may include a backward compatibility mode. Some old features may be removed, like typeglobs. Others will be improved.

The group hopes to re-shape Perl community, too. Instead of one all-encompassing perl5-porters list, tightly focused mailing lists with a terminal lifespan will be formed. To start off, the mailing list bootstrap at perl.org will be for discussion of the beginnings of the project. Like most, if not all, other new lists, when it has fulfilled its purpose, it will be closed.

Wall said, "Perl 5 was my rewrite of perl ... I think this should be the community's rewrite of perl, and the community's rewrite of the community."

Specifics have not yet been ironed out. A group has been formed to begin the work, which will primarily consist of planning the work to be done. No coding is to be done at this stage, only planning and support. Roles were determined for the group, and then they were filled. They now include the perl 5 maintainer (Jarkko Hietaniemi and Nick Ing-Simmons), the language design pumpking (Larry Wall), the internals design pumpking (Dan Sugalski), the documentation manager (Adam Turoff), the system administrator (Ask Bjoern Hansen), the quality assurance bloke (Michael Schwern), the spokesdroid (brian d foy), the customer relations person (Dick Hardt), and the project manager himself, Nathan Torkington. Other porters, such as Chip Salzenberg, volunteered to consult when needed.

Some of the short term goals of this group are to draft a language specification, start an RFC channel, get feedback, and set up mailing lists, a documentation repository, and a web site. Hansen will be setting up the mailing lists. The bootstrap list will be open to the public, while the list for the intial small group of people will be closed for posting by anyone not on the list. All lists will be readable by the public, through the web, and perhaps through email. Turoff is going to be preparing the notes for the morning meeting, and foy will be posting the notes and the mailing list links on the www.perl.org web site.