Slashdot Mirror

• WWW::Mechanize for the automated fetching.
• for the HTML validation

• WWW::Mechanize for the automated fetching.
• for the HTML validation

I recommend httperf and http_load for banging on lists of URLs really hard. At one place I worked, one of our developers rigged up some shell scripts that would play back log files through httperf and that worked pretty well.

If you want to record browser sessions for testing specific paths through the site, look at http-recorder or roboweb. There's also webchatpp, HTTP::WebTest, and HTTP::MonkeyWrench on CPAN. More info on this can be found on the mod_perl mailing list or on PerlMonks.

I recommend httperf and http_load for banging on lists of URLs really hard. At one place I worked, one of our developers rigged up some shell scripts that would play back log files through httperf and that worked pretty well.

If you want to record browser sessions for testing specific paths through the site, look at http-recorder or roboweb. There's also webchatpp, HTTP::WebTest, and HTTP::MonkeyWrench on CPAN. More info on this can be found on the mod_perl mailing list or on PerlMonks.

I recommend httperf and http_load for banging on lists of URLs really hard. At one place I worked, one of our developers rigged up some shell scripts that would play back log files through httperf and that worked pretty well.

If you want to record browser sessions for testing specific paths through the site, look at http-recorder or roboweb. There's also webchatpp, HTTP::WebTest, and HTTP::MonkeyWrench on CPAN. More info on this can be found on the mod_perl mailing list or on PerlMonks.

I hate having to restart apache every time I want to test some code.

Did you check out Apache::Reload?

Well said. Conversely, even if you like php, you might find that a perl module at cpan could save many hours of development. There are all sort of considerations, tools, etc -- doesn't make sense to be religious about one language.

There are a few options for content management systems built on top of AxKit.

First if your needs are really simple you can try the AxKit wiki, which is the only wiki out there that allows you to enter data in either XML (sdocbook), WikiWiki text, or Perl's POD format. Although right now the wiki is extremely simplistic (no versioning or user management), it's quite extensible.

Next up the ladder of complexity is CallistoCMS which is has a really cool online editor component, basically allowing you to do almost WYSIWYG editing of XML content live in the web browser (all just uses pure HTML+CSS+JS+DOM, no ActiveX or Java plugins involved).

Finally there's XIMS, which is basically what you might consider as a full blown CMS, including versioning, metadata, workflow, etc etc.

Perhaps you need to stop playing games, and start programming. Then again... the coputer really is the game for some of us. =)

Acme::Comment

Acme::Comment allows multi-line comments which are filtered
out. Unlike the pseudo multi-line comment if (0) {}, the
code being commented out need not be syntactically valid.

The problem is, really, that Perl 5 and Perl 6 are two completely separate languages. You shouldn't even bother thinking about backwards compatibility; the developers aren't. Larry stepped on that before much of anything else.

From what I've read, Regexen are staying _basically_ similar (basically), but Damian Conway being the sick evil bastard he is, they're going to incorporate some higher capabilities into the engine that look an awful lot like his Parse::RecDescent grammar parsing module.

I mean, really, at their base, he's moving around flags a little, making whitespace default insignificant, and tinkering a few flags. It's when he starts making rules and backtracking capabilities (which exist in the current language, in clunky form, as he demonstrated) that it starts getting wacky.

What it comes down to, though, is that noone should be thinking 'Oh, man, now I'll have to port all my perl to perl 6.', because Perl 5 isn't going to die out or anything, just get phased out like perl 4 - left at a stable rev for support purposes.

I never liked that module. The tokens it returns are array references that don't even bother to keep similar elements in similar positions, thus forcing you to memorize the location of each element in each token type or repeatedly consult the docs. If you refuse to do event driven parsing, at least use something like HTML::TokeParser::Simple which is pretty cool as it's a factory method letting you call accessors on the returned tokens. You just memorize the method names and forget about trying to memorize the token structures.

If you really can't wait to get at the CVS version, the most recent release (parrot-0_0_7) also has the perl6 compiler (in languages/perl6). I don't know what nifty new things they've recently added in CVS, but the release version seems to work for (simple) programs. It's in Jeff Goff's directory (JGOFF) on CPAN.

# This script is a simple script that creates an aimbot
# shamelessly adapted from Net::IRC

For Perl, I wouldn't bother with any kind of reference. Just find scripts that roughly do what you want and hack them; it's blind groping around, but that's the way Perl works. If you can't get it to work that way, you probably should be writing in something else other than Perl.

Most people coming to computers and computer programming wrongly think that objects are either the best, or even the only, way to build abstractions.

Since for me, anyways, Perl's usefulness is at least 50% about the HUGE body of modules already out there, I'd say the single most valuable Perl resource is CPAN. In fact, there are so many modules there and the numbers are increasing so rapidly that there are almost TOO many modules, creating an embarassment of riches...it's getting difficult to find just what you need because there is often more than a few modules out there to do it.

Oh no, we wasted our time! Our boss, Mr. Anonymous Coward doesn't like what we did! He'll fire us for sure! Quick, porters, let's rip out all of the things we wanted to work on for our own projects, and let this brave, kind soul show us the way!

Oh wait, you're talking about PERL I work on Perl. My mistake, sorry.

Sounds kind of like what the Regexp::English perl module does.

You may also want to look at the YAPE::Regex series of modules that allow parsing/extracting/explaining of regex.

Sounds kind of like what the Regexp::English perl module does.

You may also want to look at the YAPE::Regex series of modules that allow parsing/extracting/explaining of regex.

I found this book an excellent introduction for Perl programers who want (or have) to start processing XML. It cuts through the long list of XML modules on CPAN (485 results!) and gives you the basic techniques and tools you can use.

XML is really not that difficult to deal with but it can be a little intimidating. "Perl & XML" is written in a simple and direct style that gives the reader enough information to start writing code, and pointers to find more specific information once they have chosen the tools they need.

Armed with this book, The Perl-XML FAQ and Kip Hampton's column on XML.com any Perl programer can start working confidently with XML.

For 18 months of Damian and half a year of Dan and Larry... what has been produced?

I'll let Larry and Dan speak for themselves, but as for myself: in the eighteen months I was supported by the Perl community I produced the following...

• Released 55 significant updates to 21 CPAN modules...
• ...including 16 entirely new modules...
• ...5 of which were subsequently considered important enough to be included in the Perl 5.8 core distribution;
• Wrote four extended documents (Exegeses 2,3,4 and Synopsis 5) explaining the Perl 6 design;
• Wrote a Perl Journal article on the practicalities of porting Perl 5 code to Perl 6;
• Developed a 125 page alternative design for a future Perl (named Perl 5+i), much of which has fed back into the Perl 6 design process;
• Wrote several articles for various Perl community channels like use.perl;
• Added 88 discussion nodes to the Perl Monks website;
• Posted 192 responses to messages posted on the comp.lang.perl.* newsgroups;
• Replied to over 5000 Perl-related email messages;
• Gave 167 hours of presentations on 56 Perl topics in 21 different cities in 9 countries on 4 continents.

What finished products can we take back to our workplace and use?

• Attribute::Handlers
• Attribute::Handlers::Prospective
• Attribute::Types
• Class::Delegation
• Filter::Simple
• Getopt::Declare
• Hook::LexWrap
• Inline::Files
• Lingua::EN Inflect
• NEXT
• Parse::RecDescent
• Perl6::Currying
• Perl6::Placeholders
• Perl6::Variables
• Regexp::Common
• Switch
• Text::Balanced
• Text::Reform

Mailing list traffic?

Apocalypses/Exegeses?

Acme::*?

A lot of travel time...

...and expenses?

Lectures given in far away cities...

...to a few hundred perl hackers?

Half a design for a language...

...nobody really begged for?

• Have my name introduced as an operator in the language.

  package Carnage4Life;
  require Exporter;
  @ISA = qw(Exporter);
  @EXPORT = qw(Carnage4Life);
  sub Carnage4Life { print "It's all been done" }

• Make whitespace significant to syntax

  See this module

• Rename it from Perl to "Carnage4Life: Scripting Edition

  ln -s "/usr/bin/Carnage4Life: Scripting Edition" "/usr/bin/perl"

• Add C++ templates to the language.

  Perl uses run time polymorphasim, and hence doesn't use a Templating system for code. Or maybe you could just run the C++ code inline

• Include the fuck() and unfuck() function calls that do exactly that.

  Is something that deletes all your source code and still continues to run it close enough?

Did you laugh? Okay, go donate!

Seriously though, these are all silly examples. Perl's used for a lot of sensible stuff. The biggest mistake most people make is mistaking humour like this for a lack of professionalism

• Have my name introduced as an operator in the language.

  package Carnage4Life;
  require Exporter;
  @ISA = qw(Exporter);
  @EXPORT = qw(Carnage4Life);
  sub Carnage4Life { print "It's all been done" }

• Make whitespace significant to syntax

  See this module

• Rename it from Perl to "Carnage4Life: Scripting Edition

  ln -s "/usr/bin/Carnage4Life: Scripting Edition" "/usr/bin/perl"

• Add C++ templates to the language.

  Perl uses run time polymorphasim, and hence doesn't use a Templating system for code. Or maybe you could just run the C++ code inline

• Include the fuck() and unfuck() function calls that do exactly that.

  Is something that deletes all your source code and still continues to run it close enough?

Did you laugh? Okay, go donate!

Seriously though, these are all silly examples. Perl's used for a lot of sensible stuff. The biggest mistake most people make is mistaking humour like this for a lack of professionalism

• Have my name introduced as an operator in the language.

  package Carnage4Life;
  require Exporter;
  @ISA = qw(Exporter);
  @EXPORT = qw(Carnage4Life);
  sub Carnage4Life { print "It's all been done" }

• Make whitespace significant to syntax

  See this module

• Rename it from Perl to "Carnage4Life: Scripting Edition

  ln -s "/usr/bin/Carnage4Life: Scripting Edition" "/usr/bin/perl"

• Add C++ templates to the language.

  Perl uses run time polymorphasim, and hence doesn't use a Templating system for code. Or maybe you could just run the C++ code inline

• Include the fuck() and unfuck() function calls that do exactly that.

  Is something that deletes all your source code and still continues to run it close enough?

Did you laugh? Okay, go donate!

Seriously though, these are all silly examples. Perl's used for a lot of sensible stuff. The biggest mistake most people make is mistaking humour like this for a lack of professionalism

Here's another dead givaway: 10377 sv

I'd like to see a package management system somewhat like CPAN (more info). I like being able to use a ReadLine enabled interface and automatic dependancy checking. I like being able to break the install into parts: I gan get the module, tweak it as I see fit, then install it. It just seems like a better system then fink, apt-get, etc.

I'd like to see a package management system somewhat like CPAN (more info). I like being able to use a ReadLine enabled interface and automatic dependancy checking. I like being able to break the install into parts: I gan get the module, tweak it as I see fit, then install it. It just seems like a better system then fink, apt-get, etc.

Well, your scanner is TWAIN-compliant, correct? It's relatively simple. If the photos are always going to be the same size, just write a program (even in Visual Basic ::shudder::) to acquire an image from the scanner (there are some Kodak Imaging ActiveX controls in your System directory that you can use, AFAIK). Then just shell one of the ImageMagick command-line utilities which can split images. You could also use Perl and the Perl ImageMagick modules on CPAN. (But I'm not sure how you could acquire the image in Perl).

What I want to know is how this impacts those of use who own/operate our own domains and SMTP server (i.e. those of us who do not use ISP supplied SMTP servers to send out mail).

I hope Jenda is already working on a new version of Mail::Sender...
Because he's not pro-terrorist, now is he?

In one of my jobs, I worked with a Fargo ID card printer... and I found that even on Windows the drivers were shaky. As far as I know, no ID card printer provides drivers for any platforms other than Mac and Win, so it's pretty much between one of those two that you've got to choose.

I'm curious: what's your reason for wanting to control the digital camera with a computer? Personally I would just mount it on a tripod and take the shot manually.

The only reason I can think of (that you might computer-control) is for focusing, that is, through an image on a monitor rather than squinting at the digicam's 1.8" LCD. But digicams don't have that ability anyway (not that I know of, unless you switch into video mode). For that, what my school did at its ID card printing center was to get some DV video cameras (with stills capability) and fed live the video live into computers. Seems overkill to me, frankly.

Also, I'm not sure what your requirements are exactly, but LDAP access is QED (quite easily done) with the right modules.

i lost ``touch'' with php so to speak about a year ago. i gave php up for perl a while ago. does the pear db now come with a conveniant way to install it, or does it come with the main php disto? one of the nifty things about cpan is how easy it is to install perl modules. cpan also represnets a unified development arena for the perl community. pear was trying to do this but i dont think it was having the same effect. that was one of the really frustrating things about php.

which db abstraction layer should i use?

there were quite a few to choose from at the time, and none of them were as mature as dbi.

where should i go to find pre defined modules for php?

there was no central location for this.

the lack of uniformity in the php community can be very disheartening for someone like myself. this might have changed in the last year or so, but when i switched from php to perl it really lacked momentum.

php may be more intuitive at first, but it seriously lacks alot of the functionality that comes with other languages like perl and python. while i can only speak for perl, i understand python has a similar component base. perl has cpan which makes php look like a screwdriver in a workshop full of tools. if you only plan on making a web page to take form variables and email them to someone, sure php is great. if you want to make a serious web-based application and you dont want to make everything from scratch then php is really inadiquate.

i speak from expirence here. about a year ago i made the switch from php to perl and i haven't been happier. at the time of leaving the only database abstraction layer was in beta while perl had dbi in a quite stable form.

while i realize the parent was probably a troll, i would strongly encourage people considering php vs (perl, python, etc.) to consider the amount of code already available outside of the base distribution of the scripting language.

I meant to respond earlier, but didn't get the chance. There are several ways to go about this. One is to the oft-mentioned CamelBones, which is in initial stages, but is a great start for Cocoa bindings. For Carbon, there is a vaporware project I've played with, a SWIG-based glue for Perl, Python, Tcl, Ruby, and maybe more, and more details of it will be forthcoming when it's ready.

Right now there is also the Carbon-based MacOSX::File, which offers much of the same functionality as the Mac::Files module included in MacPerl, and there is OSXMacPerl, a basic clone of the MacPerl module (DoAppleScript and more are provided).

And some day I would like to port the Mac:: modules to Carbon, if I get the tuits.

To move on to languages that learnt from perl, that improved on it, that don't have to drag around a syntax and culture that values neat tricks and trying to guess what the programmer really meant over providing the needed building blocks and letting you build code that does what you say, not what it thinks it heard you say.

You're not that familiar with Perl culture, are you? Providing needed building blocks? We've got CPAN, a frighteningly large library of building blocks.

Sure, Perl values neat tricks. So do C hackers. Sure, sometimes the tricks are strictly for entertainment value. What's the harm (assuming you don't do anything foolish like using it in production code)? Sometimes a little trick will get a throwaway tool written and used more quickly.

As for the syntax, that's exactly what Larry is working on right now. The language has become a bit crufty, Perl 6 will try to clean out the cruft. I have no idea how well it will work, that's to be seen.

Or even, dare I say it, to move on to languages outside the perl family for some programming and choose the right tool for the job for a change.

Really out of the Perl culture loop, I see. Perl is all about using the right tool for the job. Part of Perl's strength is as a glue language: use whatever tool best fits a particular job, but when you've run into several tools, Perl makes it easy to glue them together. Perl has many ways to call over programs and process their output. Perl can call libraries written in other languages. Perl can be embedded into other languages. Perl tries its hardest to play nice with everyone else. In almost every case, you could provide a 100% Perl solution, but the Perl culture values the right tool for the right job, so it makes sense to make using other tools easy.

Sometimes you have a problem where Perl has nothing to add to a particular solution. The true Perl spirit is to leave Perl out.

True Perl hackers value working solutions over using their favorite tool.

Perl was great, it introduced many people to programming, just like COBOL did. But now it's time to move on.

COBOL didn't adapt to any significant extent. It was largely limited to its roots. Perl adapts. Perl has done as well as it has because it's a powerful and flexible language. Perl looks daunting because of its size, people miss that Perl is best learned like a human language, slowly and over time. Perl, like a human language, has adapted to changing times, picked up good ideas, and generally stayed fluid. When Perl was originally created, the web didn't exist, yet Perl proved to be an exception language for all sorts of web work. Why? Because Perl had lots of powerful primatives upon which was quickly built libraries to support common tasks.

To move on to languages that learnt from perl, that improved on it, that don't have to drag around a syntax and culture that values neat tricks and trying to guess what the programmer really meant over providing the needed building blocks and letting you build code that does what you say, not what it thinks it heard you say.

You're not that familiar with Perl culture, are you? Providing needed building blocks? We've got CPAN, a frighteningly large library of building blocks.

Sure, Perl values neat tricks. So do C hackers. Sure, sometimes the tricks are strictly for entertainment value. What's the harm (assuming you don't do anything foolish like using it in production code)? Sometimes a little trick will get a throwaway tool written and used more quickly.

As for the syntax, that's exactly what Larry is working on right now. The language has become a bit crufty, Perl 6 will try to clean out the cruft. I have no idea how well it will work, that's to be seen.

Or even, dare I say it, to move on to languages outside the perl family for some programming and choose the right tool for the job for a change.

Really out of the Perl culture loop, I see. Perl is all about using the right tool for the job. Part of Perl's strength is as a glue language: use whatever tool best fits a particular job, but when you've run into several tools, Perl makes it easy to glue them together. Perl has many ways to call over programs and process their output. Perl can call libraries written in other languages. Perl can be embedded into other languages. Perl tries its hardest to play nice with everyone else. In almost every case, you could provide a 100% Perl solution, but the Perl culture values the right tool for the right job, so it makes sense to make using other tools easy.

Sometimes you have a problem where Perl has nothing to add to a particular solution. The true Perl spirit is to leave Perl out.

True Perl hackers value working solutions over using their favorite tool.

Perl was great, it introduced many people to programming, just like COBOL did. But now it's time to move on.

COBOL didn't adapt to any significant extent. It was largely limited to its roots. Perl adapts. Perl has done as well as it has because it's a powerful and flexible language. Perl looks daunting because of its size, people miss that Perl is best learned like a human language, slowly and over time. Perl, like a human language, has adapted to changing times, picked up good ideas, and generally stayed fluid. When Perl was originally created, the web didn't exist, yet Perl proved to be an exception language for all sorts of web work. Why? Because Perl had lots of powerful primatives upon which was quickly built libraries to support common tasks.

Wow - I really hope you don't actually consider Perl to be a suitable alternative to Java, it is a scripting language for crying out loud (and an incredibly ugly one IMHO), I can't believe that whatever magic fairy-dust they plan to sprinkle on Perl6 will change this much.

As an experienced Java developer, I have never really felt disappointed by the Java libraries (with the sole exception of the lack of support for asynchronous networking until 1.4) - what exactly is your beef with them?

Wow - I really hope you don't actually consider Perl to be a suitable alternative to Java, it is a scripting language for crying out loud (and an incredibly ugly one IMHO), I can't believe that whatever magic fairy-dust they plan to sprinkle on Perl6 will change this much.

As an experienced Java developer, I have never really felt disappointed by the Java libraries (with the sole exception of the lack of support for asynchronous networking until 1.4) - what exactly is your beef with them?

"Perhaps even one of them Perl monkeys will quickly hack such a background tool."

Been done already. Check out Mail::Miner.

I don't know how much detail that you require from your load test...but for a basic test, this may work.

Write a series of relatively simple perl scripts distributed across -- say 5 or 10 client machines.

Check out cpan for X11 protocol modlues. On each load test host, have your perl script open a bunch of client connections (say, 50-75 per load test client) -- and maybe even launch a few real-world apps (and seed which clients open which apps based on your usage expectations). This will give you a general idea of how well your system runs under load. You can even use perl modules to specific X apps to do some stuff with the client apps that you launch.

You can easily do data drilling on either your client machines or your X server. For basic results, memory utilization, load, etc. For a little more in-depth data, check out response times, connect times, login times, load times -- all on a number-of-concurrent-connections basis.

-Turkey

Semi off-topic, but you just can't compare CPAN to PEAR

CPAN and PEAR have nothing in common. CPAN stands for Comprehensice Perl Archive Network. This highly active site is maintained by the Perl community. From CPAN you can find hunderds (thousands?) of Free Perl libraries and corresponding on-line documentation.

PEAR web page says "PEAR is a framework and distribution system for reusable PHP components". So among other things, it acts as an abstraction layer to various RDBM's.

I don't think there's full equivalent to PEAR in Perl world but what the original poster probably meant is DBI - The Perl Database Interface.

• Timeliness
  • When I am searching for a software product it's not a leisure activity, rather it's usually directly related to my job and I 'm looking for a solution
  • now (a lot of contracts depend on finding existing sofware to handle certain features off the bat as a base). When I have to wait more than a few minutes for the registration key (yes, I use a real, albeit HoTMaiL, address) I go to the next resource.
• Internal Server Error, or [ODBC Error], etc
  • I can't believe how many times I've gone through the torturous sign-up process only to find an error in the download process. Perhaps your potential clients are getting an error -- or, perhaps some other inconvenience? This happened to me more than once at Sun.com.

For example, I spent a long time looking for a decent in-the-browser page editor for hosting clients to edit their pages online. I looked for a long time, actually not starting out in the open source realm for some reason, and tried many of the low-cost closed source page editor solutions (mainly perl based). Most were simply some form of "here's a TEXTAREA field with the page code; have fun". The few attempts at a WYSIWYG editor, in the commercial offerings I found, were laughable. But then I found Richtext Editor on sourceforge. WOW! This is the slickest in-page editor I've seen to date. Yeah, it has a ways to go, but provides an incredible headstart to getting there. Will I contribute back my changes? Of course -- that's the way you "pay" open source projects. Love it. It only works with IE 5+ - for now (and 92% of thise visting our sites use IE 5+).

Now, if someone wanted to write a real abstraction layer, maybe one that would let you use either Perl/Tk, Perl/GTK+, or something else... that coule be interesting :-)

See Wx.

I wish that PERL had a GUI abstraction layer, similar to DBI for databases.

See Gtk, Gnome, Tk, Qt and Wx CPAN distros.

I wish that PERL had a GUI abstraction layer, similar to DBI for databases.

See Gtk, Gnome, Tk, Qt and Wx CPAN distros.

I wish that PERL had a GUI abstraction layer, similar to DBI for databases.

See Gtk, Gnome, Tk, Qt and Wx CPAN distros.

I wish that PERL had a GUI abstraction layer, similar to DBI for databases.

See Gtk, Gnome, Tk, Qt and Wx CPAN distros.

I wish that PERL had a GUI abstraction layer, similar to DBI for databases.

See Gtk, Gnome, Tk, Qt and Wx CPAN distros.

Here you go: Perl GoogleWhack module

You have permission now. Perl's module with an http api (read downloading the pages and extracting data) was removed from CPAN at google's request.

I'm assuming there's a module out there that can do this easily on the fly?