Slashdot Mirror

Unfortunately my spider program was going pretty slowly since I couldn't get asynchronous I/O to work properly, so I abandoned the idea.

CPANPLUS, which is scheduled to replace CPAN.pm in the 5.10 core, has uninstall functionality.

[root@ocicat root]# perl -MCPANPLUS -e shell
CPANPLUS::Shell::Default -- CPAN exploration and modules installation (v0.03)
*** Please report bugs to <cpanplusbugs@lists.sourceforge.net>.
*** Using CPANPLUS::Backend v0.042. ReadLine support enabled.

CPAN Terminal> u File::ReadBackwards
Checking if source files are up to date
Retrieving /root/.cpanplus/mailrc.2.04.stored
Retrieving /root/.cpanplus/dslip.2.04.stored
Retrieving /root/.cpanplus/packages.2.04.stored
Uninstalling: File::ReadBackwards
unlinking /usr/local/lib/perl5/site_perl/5.8.0/File/ReadBack wards.pm
unlinking /usr/local/man/man3/File::ReadBackwards.3
unlinking /usr/local/lib/perl5/site_perl/5.8.0/i686-linux/au to/File/ReadBackwards/.packlist
Uninstalled File::ReadBackwards successfully
All modules uninstalled successfully
CPAN Terminal>
Exiting CPANPLUS shell
[root@ocicat root]#

it *is* nice to have this sort of stuff managed by your package manager.

The best of both worlds - modules built locally, with rpm ease of installation and de-installation.

All you need is to imagine a Beowulf cluster of...

Waitaminute!

You actually could think of this as a Beowulf cluster! The main twist is that each node in the network is being used interactively, rather than just acting as a slave that churns away on data chunks autonomously.

You don't state what kind of systems your colleagues are using, but if you're using Macs, then Rendezvous mDNS networking can take care of the "plumbing" part of the problem for you -- everyone can instantly start publishing their shared resources, and the trick then is to just figure out a way to search who has what content.

The search function could be done from a machine set up to automatically spider everyone's content & basically set up a little in-house search engine, with links back to each user's version of "http://johndoe.local/weather/data/2003/08/21/1530 _nws" or whatever.

If you're not running Macs, well that's a problem on several levels :), but the mDNS spec is an open standard, and it is IIRC available as an Apache module. There's mod_rendezvous , but it seems to have stalled with an OSX version only -- porting to Linux shouldn't be bad but is left as an exercise for the reader. There also seems to be the Net::MDNS::Server & Net::MDNS::Client Perl modules on CPAN, but they seem to have been born & stalled in the same week back in June. Not sure what that means.

In any case, if you can set up a spontaneous mDNS network, then that would solve the problem of getting every node on your network to be able to advertise what resources are available to other nodes on the network. The step after that is to set up a search interface, and that's really a solved problem -- any Perl hacker comfortable with LWP should be able to whip up a reasonably good search mechanism using &/or extending existing tools.

If you manage to get this to work, it would be interesting to read a writeup of how the lego parts end up being assembled :-)

All you need is to imagine a Beowulf cluster of...

Waitaminute!

You actually could think of this as a Beowulf cluster! The main twist is that each node in the network is being used interactively, rather than just acting as a slave that churns away on data chunks autonomously.

You don't state what kind of systems your colleagues are using, but if you're using Macs, then Rendezvous mDNS networking can take care of the "plumbing" part of the problem for you -- everyone can instantly start publishing their shared resources, and the trick then is to just figure out a way to search who has what content.

The search function could be done from a machine set up to automatically spider everyone's content & basically set up a little in-house search engine, with links back to each user's version of "http://johndoe.local/weather/data/2003/08/21/1530 _nws" or whatever.

If you're not running Macs, well that's a problem on several levels :), but the mDNS spec is an open standard, and it is IIRC available as an Apache module. There's mod_rendezvous , but it seems to have stalled with an OSX version only -- porting to Linux shouldn't be bad but is left as an exercise for the reader. There also seems to be the Net::MDNS::Server & Net::MDNS::Client Perl modules on CPAN, but they seem to have been born & stalled in the same week back in June. Not sure what that means.

In any case, if you can set up a spontaneous mDNS network, then that would solve the problem of getting every node on your network to be able to advertise what resources are available to other nodes on the network. The step after that is to set up a search interface, and that's really a solved problem -- any Perl hacker comfortable with LWP should be able to whip up a reasonably good search mechanism using &/or extending existing tools.

If you manage to get this to work, it would be interesting to read a writeup of how the lego parts end up being assembled :-)

#!/usr/bin/perl
use HTTP::Request::Common qw(POST);
use LWP::UserAgent;

$ua=LWP:UserAgent->new();
my req = POST 'http://books.slashdot.org', [sid => '74463', cid =>6677408', etc...]
$content = $ua->request($req)->as_string

It's a lot easier than the amount of documentation makes out. If you had read the book the original review was about then you'd know that.

As for those tutorials: perlbot is more a quick cookbook reference type thing; perltoot is part 1 of tchrist's OO tutorial; perltooc is part 2 and covers class data; while perlboot covers OO from the ground up.

toot/tooc are ideal for those used to OO elsewhere.
boot is great for newbies to OO.
bot is excellent as a "how do I ..." reference.

Sure, they could all do with some rewriting but those most qualified to do so (justifiably) point to "Learning Perl Objects, References and Modules" and Conway's "Object Oriented Perl". Patches welcome.

As for @ISA, it's cute and simple. Perl does multiple inheritance, so it makes sense to keep that information in an array. You can even modify this array at runtime to modify your inheritance. You can hide it all with base (despite where that link will take you, it is a core module and has been since 5.00405 [early 1999]).

What syntax would you prefer?

The startling thing about Perl OO is its flexibility.

It's a lot easier than the amount of documentation makes out. If you had read the book the original review was about then you'd know that.

As for those tutorials: perlbot is more a quick cookbook reference type thing; perltoot is part 1 of tchrist's OO tutorial; perltooc is part 2 and covers class data; while perlboot covers OO from the ground up.

toot/tooc are ideal for those used to OO elsewhere.
boot is great for newbies to OO.
bot is excellent as a "how do I ..." reference.

Sure, they could all do with some rewriting but those most qualified to do so (justifiably) point to "Learning Perl Objects, References and Modules" and Conway's "Object Oriented Perl". Patches welcome.

As for @ISA, it's cute and simple. Perl does multiple inheritance, so it makes sense to keep that information in an array. You can even modify this array at runtime to modify your inheritance. You can hide it all with base (despite where that link will take you, it is a core module and has been since 5.00405 [early 1999]).

What syntax would you prefer?

The startling thing about Perl OO is its flexibility.

It's a lot easier than the amount of documentation makes out. If you had read the book the original review was about then you'd know that.

As for those tutorials: perlbot is more a quick cookbook reference type thing; perltoot is part 1 of tchrist's OO tutorial; perltooc is part 2 and covers class data; while perlboot covers OO from the ground up.

toot/tooc are ideal for those used to OO elsewhere.
boot is great for newbies to OO.
bot is excellent as a "how do I ..." reference.

Sure, they could all do with some rewriting but those most qualified to do so (justifiably) point to "Learning Perl Objects, References and Modules" and Conway's "Object Oriented Perl". Patches welcome.

As for @ISA, it's cute and simple. Perl does multiple inheritance, so it makes sense to keep that information in an array. You can even modify this array at runtime to modify your inheritance. You can hide it all with base (despite where that link will take you, it is a core module and has been since 5.00405 [early 1999]).

What syntax would you prefer?

The startling thing about Perl OO is its flexibility.

It's a lot easier than the amount of documentation makes out. If you had read the book the original review was about then you'd know that.

As for those tutorials: perlbot is more a quick cookbook reference type thing; perltoot is part 1 of tchrist's OO tutorial; perltooc is part 2 and covers class data; while perlboot covers OO from the ground up.

toot/tooc are ideal for those used to OO elsewhere.
boot is great for newbies to OO.
bot is excellent as a "how do I ..." reference.

Sure, they could all do with some rewriting but those most qualified to do so (justifiably) point to "Learning Perl Objects, References and Modules" and Conway's "Object Oriented Perl". Patches welcome.

As for @ISA, it's cute and simple. Perl does multiple inheritance, so it makes sense to keep that information in an array. You can even modify this array at runtime to modify your inheritance. You can hide it all with base (despite where that link will take you, it is a core module and has been since 5.00405 [early 1999]).

What syntax would you prefer?

The startling thing about Perl OO is its flexibility.

It's a lot easier than the amount of documentation makes out. If you had read the book the original review was about then you'd know that.

As for those tutorials: perlbot is more a quick cookbook reference type thing; perltoot is part 1 of tchrist's OO tutorial; perltooc is part 2 and covers class data; while perlboot covers OO from the ground up.

toot/tooc are ideal for those used to OO elsewhere.
boot is great for newbies to OO.
bot is excellent as a "how do I ..." reference.

Sure, they could all do with some rewriting but those most qualified to do so (justifiably) point to "Learning Perl Objects, References and Modules" and Conway's "Object Oriented Perl". Patches welcome.

As for @ISA, it's cute and simple. Perl does multiple inheritance, so it makes sense to keep that information in an array. You can even modify this array at runtime to modify your inheritance. You can hide it all with base (despite where that link will take you, it is a core module and has been since 5.00405 [early 1999]).

What syntax would you prefer?

The startling thing about Perl OO is its flexibility.

It's a lot easier than the amount of documentation makes out. If you had read the book the original review was about then you'd know that.

As for those tutorials: perlbot is more a quick cookbook reference type thing; perltoot is part 1 of tchrist's OO tutorial; perltooc is part 2 and covers class data; while perlboot covers OO from the ground up.

toot/tooc are ideal for those used to OO elsewhere.
boot is great for newbies to OO.
bot is excellent as a "how do I ..." reference.

Sure, they could all do with some rewriting but those most qualified to do so (justifiably) point to "Learning Perl Objects, References and Modules" and Conway's "Object Oriented Perl". Patches welcome.

As for @ISA, it's cute and simple. Perl does multiple inheritance, so it makes sense to keep that information in an array. You can even modify this array at runtime to modify your inheritance. You can hide it all with base (despite where that link will take you, it is a core module and has been since 5.00405 [early 1999]).

What syntax would you prefer?

The startling thing about Perl OO is its flexibility.

A pointer to perlvar is probably useful.

The thing is, the average Perl program doesn't even use most of these. $_ is the most common (and its very purpose is why it's such a short name). $! and $@ for errors (but for some reason most of those who complain about perl's cryptic syntax are also those who skip error checking). @_, for argument passing.

And those 4 will get you through most of Perl except for a few odd bits. Any others are either one shot uses (which you probably should've written a comment for), or are just things you can let people look up.

One of the great things about perl is the thoroughness of the supplied docs. Such a shame most linux distros package them up in a separate perl-doc package that is rarely installed by default. It's also a shame that many of the (non-ORA) Perl basics books neither cover perldoc or even cover POD.

I totally agree with you. Even in the case of regexps, the /x modifier is available and you can use it to add spaces and even comments to enhance your code's readability. So again, it boils down to the programmer and his/her preferred style.

The difficulty lies in the fact that it is possible to obfuscate Perl to such a degree, and that so many Perl hackers seem to think more obfuscation makes them look like a better programmer.

It IS quite easy to obfuscate Perl code, but I disagree that Perl hackers like to obfuscate more than others. Just lurk around comp.lang.perl.misc for a while and see the quality of code over there. You are bound to get crappy code in any language, but crappy code comes from crappy programmers.

There's even a contect that rewards this kind of thing.

As for the contest(sic) you mentioned, I'm not aware of any such contests. The only thing that I know of is the Perl Golf contest, and I have participated in all of the official ones, and I can tell you that I learnt much more about Perl there than in the last 5 years that I've been hacking Perl. The idea is not to obfuscate, but rather to shorten the code as much as possible to solve a given problem.

For real obfuscation, check out Damian Conway's Acme::Bleach module and Andrew Savige's Acme::EyeDrops module, both availabe from CPAN.

Secondly you contradict yourself. First you say: I mean crap, as in the stuff that comes out of everyones ass.. This cleary coincides with the first definition of crap:

1 a usually vulgar : EXCREMENT b usually vulgar : the act of or product of defecating

2 sometimes vulgar : NONSENSE, RUBBISH; also : STUFF 4b

You appear to be confused, I suggest you read the Carp documentation, its very informative, and you'll learn a lot about Perl.

Secondly you contradict yourself. First you say: I mean crap, as in the stuff that comes out of everyones ass.. This cleary coincides with the first definition of crap:

1 a usually vulgar : EXCREMENT b usually vulgar : the act of or product of defecating

2 sometimes vulgar : NONSENSE, RUBBISH; also : STUFF 4b

You appear to be confused, I suggest you read the Carp documentation, its very informative, and you'll learn a lot about Perl.

Never knew "crap" was an adjective. Maybe you mean Carp? (Its not an adjective either.)

The two URLS you provide are very small when considered aside CPAN. CPAN is no less than 100 time larger in subject area and code than the combined content of the repositories you named.

The bulk of this code comes right out of the readme file for the Spreadsheet::ParseExcel::Simple module. The main changes I made were to add the LWP call to download the source file, and I tweaked the line to split up the columns (as later replies went over & fixed).

CPAN should get the credit for this -- I'm mainly cargo culting :-)

Apropos to the recent Perl 6 announcement I'll just go ahead and mention the perl interface as well. Wouldn't want anybody to forget.

Yes they weren't thoughtful enough to put in plain text so I can run your Perl scripts on it.

Here's one untested way to do it, based on the sample code given (Slashcode doesn't agree well with nicely indented Perl, so I've replaced standard indentation with vertical space instead to retain some clarity):

#!/path/to/perl -w

use strict;
use Spreadsheet::ParseExcel::Simple;
use LWP::Simple;

my $content = get("http://www.slyck.com/misc/p2p.xls");
open my $fh_excel, "p2p.xls" or die "cant write: $!";
print $fh_excel $content;

my $xls = Spreadsheet::ParseExcel::Simple->read('p2p.xls');
foreach my $sheet ($xls->sheets) {

while ($sheet->has_data) {

my @data = $sheet->next_row;
print $data[0], "\t", join("\t", split (/ */, $data[1]));

}

}

And hey presto -- if all goes well, the spreadsheet in question should end up being magically downloaded & converted to a tab delimited table on the fly.

Now that wasn't so bad, was it? And you didn't even have to do any of the work... :-)

whitespace hasn't even been made meaningful yet.

Check it out if you haven't already -- Acme::Bleach showcases the best and worse of perl: very short code (83 lines, including documentation you see in the link above), humorous (with subroutine names like whiten, brighten, dirty and dress) and does absolutely nothing Useful(tm). It's a cool perl hack.

the language is becoming more obtuse if thats possible.

Read the last page of Exegesis 6 to see the Perl 5 version of the code. It's astonishingly simpler and clearer in Perl 6.

The perl programmers I know don't get along well with other languages, mostly because they have spent so much time learning the intricacies of Perl syntax.

See the Inline modules on the CPAN.

I've never met a perl programmer who could tell me what a design pattern is either.

See Perl Design Paterns, an article on Perl.com.

I guess they don't go for re-use much in perl progging.

See the CPAN.

I think if I went to hell, satan would probably make me write a Perl parser. (without the help of Yacc)

I've read the Perl parser. You're right about this one.

the language is becoming more obtuse if thats possible.

Read the last page of Exegesis 6 to see the Perl 5 version of the code. It's astonishingly simpler and clearer in Perl 6.

The perl programmers I know don't get along well with other languages, mostly because they have spent so much time learning the intricacies of Perl syntax.

See the Inline modules on the CPAN.

I've never met a perl programmer who could tell me what a design pattern is either.

See Perl Design Paterns, an article on Perl.com.

I guess they don't go for re-use much in perl progging.

See the CPAN.

I think if I went to hell, satan would probably make me write a Perl parser. (without the help of Yacc)

I've read the Perl parser. You're right about this one.

* several CPAN modules

i saw him speak about linux kernel modules (or something) over at ManilaCon last May.

Dido, you rock man!!

Probably noone. Though, Perl is very common.

The distinction is that it isn't called PERL, it is Perl. There once (a short while) was a Perl ripoff called PERL that was a bit similar, but without all the features that makes a maintainable and secure application possible. If anyone is curious, you could have a look at Acme::Inline::PERL at CPAN, which brings the power of PERL to Perl. Yes, the ACME:: namespace is for sillyness and joke modules. :)

Doing so would then compress whitespace, remove colors, and basically un-SPAM the SPAM. I do this for web content, which I need re-rendered as text-based articles before they are sent to the client. It's about 12 lines of Perl, and can be easily stuffed into a SpamAssassin milter. If you want some working code, feel free to contact me (I'm also for hire, so I can do this as c custom gig for you or your company).

In fact, you could probably put a small function in your milter to just strip all HTML entirely, before the client ever sees it. There's no need to use OCR (and the overhead associated with it) to handle this, just turn the HTML back into text. It works with foreign, encoded, obfuscated entities, and should be no problem to correct before scoring.

Doing so would then compress whitespace, remove colors, and basically un-SPAM the SPAM. I do this for web content, which I need re-rendered as text-based articles before they are sent to the client. It's about 12 lines of Perl, and can be easily stuffed into a SpamAssassin milter. If you want some working code, feel free to contact me (I'm also for hire, so I can do this as c custom gig for you or your company).

In fact, you could probably put a small function in your milter to just strip all HTML entirely, before the client ever sees it. There's no need to use OCR (and the overhead associated with it) to handle this, just turn the HTML back into text. It works with foreign, encoded, obfuscated entities, and should be no problem to correct before scoring.

Doing so would then compress whitespace, remove colors, and basically un-SPAM the SPAM. I do this for web content, which I need re-rendered as text-based articles before they are sent to the client. It's about 12 lines of Perl, and can be easily stuffed into a SpamAssassin milter. If you want some working code, feel free to contact me (I'm also for hire, so I can do this as c custom gig for you or your company).

In fact, you could probably put a small function in your milter to just strip all HTML entirely, before the client ever sees it. There's no need to use OCR (and the overhead associated with it) to handle this, just turn the HTML back into text. It works with foreign, encoded, obfuscated entities, and should be no problem to correct before scoring.

Doing so would then compress whitespace, remove colors, and basically un-SPAM the SPAM. I do this for web content, which I need re-rendered as text-based articles before they are sent to the client. It's about 12 lines of Perl, and can be easily stuffed into a SpamAssassin milter. If you want some working code, feel free to contact me (I'm also for hire, so I can do this as c custom gig for you or your company).

In fact, you could probably put a small function in your milter to just strip all HTML entirely, before the client ever sees it. There's no need to use OCR (and the overhead associated with it) to handle this, just turn the HTML back into text. It works with foreign, encoded, obfuscated entities, and should be no problem to correct before scoring.

I'm sorry, but I think we've all just been trolled. I don't believe there's really an attempt to ask a valid question here. This individual has written a couple of perl scripts, and truly believes they will change the world. He hasn't done any research (no mention of CPAN, thinks that FreeBSD does Perl, etc.), and truly believes that a few Perl math routines will change the world. Can you spell "ego trip"?

But just in case I'm wrong, here's what you do: Point your browser to CPAN. Carefully read the instructions. Submit your scripts. If they're good, they'll get used, you'll make a name for yourself, and will be on the way to The Big Time.

I really can't believe this made /.

Check it out, it converts between timezones automagically, respects daylight savings, and all of the fun stuff.

It's really a lifesaver, here is a link DateTime.pm

Since your package is written in perl, it might be a good idea to check out CPAN.

Check if they have anything that looks like your package (there might well be some math packages already (also remember to check what is shipped with perl). If there is, you might consider joining forces with whoever maintains the package that comes closest to yours. Move the logic of your programs into the modules you have found and make your programs as simple as possible, using the features of the combined modules. Then include tests, documentation and anything else you think would be relevant and contact the module maintainer with a patch or a new version. If (s)he accepts the contribution, the result should be a better and more useful package than either of you had before.

If you think you have found the perfect package to join forces with, but the maintainer does not want to hear your arguments, consider closely what you are offering. It might be that (s)he is right to turn you down, or there might be something you need to fix to fit into the package. If you get nowhere - and you are absolutely sure you have found the perfect home for your code, you might be able to make a fork (e.g. if the package you want to fork is GPL). Stop and think once more, whether this is the right course of action! You should have a good argument ready if you fork a known package, and you will need to do it better than the competition.

If you didn't find anything like your package, you might still get it into CPAN. But if you want it to be as useful as possible, you should still consider making it a module (or several) and using that module from your programs/scripts. Also again make sure that tests and documentation is good and plentiful. Then read the FAQ about getting your package on CPAN.

You might also look into the source based distros, the BSDs and debian. They might be more up to including your package than the commersial distros, especially if you make it easy (use the GPL license, provide packages/ebuilds/spells/Makefiles and what ever else is needed for a proper package in their systems).

As countless others have no doubt pointed out, you may also want to look into making C implementations of your programs, get them on freshmeat, sourceforge, savannah and what not. All this is good advice. And most of all, make sure you expand and improve the programs, support your users and generally do your best to find your niche in the software landscape. That way you might be able to avoid getting labeled as "just another quick script submitted to freshmeat" (not that I have researched your package enough to make that judgement). Then inclusion in the distros is simply a matter of being useful to enough people (and making it as easy as possible to include your package).

Since your package is written in perl, it might be a good idea to check out CPAN.

Check if they have anything that looks like your package (there might well be some math packages already (also remember to check what is shipped with perl). If there is, you might consider joining forces with whoever maintains the package that comes closest to yours. Move the logic of your programs into the modules you have found and make your programs as simple as possible, using the features of the combined modules. Then include tests, documentation and anything else you think would be relevant and contact the module maintainer with a patch or a new version. If (s)he accepts the contribution, the result should be a better and more useful package than either of you had before.

If you think you have found the perfect package to join forces with, but the maintainer does not want to hear your arguments, consider closely what you are offering. It might be that (s)he is right to turn you down, or there might be something you need to fix to fit into the package. If you get nowhere - and you are absolutely sure you have found the perfect home for your code, you might be able to make a fork (e.g. if the package you want to fork is GPL). Stop and think once more, whether this is the right course of action! You should have a good argument ready if you fork a known package, and you will need to do it better than the competition.

If you didn't find anything like your package, you might still get it into CPAN. But if you want it to be as useful as possible, you should still consider making it a module (or several) and using that module from your programs/scripts. Also again make sure that tests and documentation is good and plentiful. Then read the FAQ about getting your package on CPAN.

You might also look into the source based distros, the BSDs and debian. They might be more up to including your package than the commersial distros, especially if you make it easy (use the GPL license, provide packages/ebuilds/spells/Makefiles and what ever else is needed for a proper package in their systems).

As countless others have no doubt pointed out, you may also want to look into making C implementations of your programs, get them on freshmeat, sourceforge, savannah and what not. All this is good advice. And most of all, make sure you expand and improve the programs, support your users and generally do your best to find your niche in the software landscape. That way you might be able to avoid getting labeled as "just another quick script submitted to freshmeat" (not that I have researched your package enough to make that judgement). Then inclusion in the distros is simply a matter of being useful to enough people (and making it as easy as possible to include your package).

In perl.
Blazing fast with mod_perl.
Very easy to learn.
More info here.

wheres the "Remote Windows Management Using Activestate Perl and a few Win32 Calls for Dummies?"

Here..
CPAN is your friend.

OK, I understand that much, but how is your site different from, say, the SourceForge snippet repository, the many PHP repositories, HotScripts, CPAN, or Vaults of Parnassus (for Python code). There are many repositories available.

I was convinced it was a secret cookie-changes-css thingy for anyone dumb enough to download that module.

Ah well, at least it's not "Slashdot Games Blue"

Phew!

cLive ;-)

You've not seen B::Deobfuscate yet then :)

David Cantrell > Acme-Pony-1.1.2 > Acme::Pony
Module Version: 1.1.2 Source

NAME
SYNOPSIS
DESCRIPTION
DIAGNOSTICS
AUTHOR
COPYRIGHT

NAME
Acme::Pony - An encoding scheme for Silly People

SYNOPSIS
use Acme::Pony;

print "Hello world";

DESCRIPTION
The first time you run a program under use Acme::Pony, the module removes all that nasty text stuff from your source file, turning it into a lovely ASCII-art rendition of a pony. In the spirit of other london.pm modules, the ASCII-art will consist entirely of the characters matching /[buffy]+/i, thus fulfilling Greg, Leon and Dave's fantasy of seeing Buffy riding a Pony.

DIAGNOSTICS

Can't pony '%s'
Acme::Pony couldn't access the source file for modification.

Can't unpony '%s'
Acme::Pony couldn't access the source file for execution.

AUTHOR
David Cantrell

This is based on Leon Brocard's 'Buffy' module and inspired by Damian Conway's brief talk on his Bleach module.

Leon contributed the code for scaling a vector Pony and filling it, replacing the bitmap Pony from the previous versions.

COPYRIGHT
Copyright (c) 2001, David Cantrell. The Artistic Licence applies.

I don't think I need to mention that Leon Brocard works for Fotango, and that Fotango owns up to adding their share of silly libraries to CPAN.

And now they've gotten to Larry Wall himself.... :-)

So, is there a URL for the State of the Onion talk this year then?

Actually, here's a good module that talks about PERL - very useful for Perl programmers.

Perl Design Patterns - one large document, in book form - or hit search.cpan.org and search for Object::PerlDesignPatterns

1. XML is still a form of text. You can look at it, you can read it, no its not text/plain that's why they call it text/xml! Were it binary then it would be called application/xml
2. Perl has better interfaces for XML than PHP. I can say that because I use them both and doing anything with XML in PHP is a real pain.

thank god for cpan!

This was a very interesting article. I natively speak Perl, C, and C++, know enough about PHP to get by, and still remember some Commodore 64 BASIC (10 ? CHR$(147)). I am also, as I believe I've said before, not afraid to learn things like Java, Python, Ruby, maybe even Visual Basic again (God forbid) should they prove exceedingly relevant to my case - in fact, I quite look forward to knowing (hopefully) all of them and then some. But never Pascal. (Just kidding.)

I've really found that the thing I hate most about programming in general is that no single language is the right one to use for any of my programs! I am very interested in any effort I ever come across to do functional merging of disparate environments. In addition to a couple of workarounds I've invented in the past for shoehorning Perl into PHP, I like reading about things like SWIG, the open CLR, and even COM (the concept more than the implementation), and a smile always comes to my face when I think about the Inline library written for Perl.

Now, the thing I really pine for is all of this interlanguage binding stuff being easy, fairly portable, more synactically simple, and less hacky. I know that these exist, but not quite completely together. If I write a program in Perl with use Inline C, I can never be sure that anyone else has all the development tools necessary to compile all the C on the fly. Writing a program in Visual Basic with a nice mouse-drawn GUI and an external component is really easy - but it's Visual Basic. Writing a component wrapper for Perl is fairly straightforward with SWIG, but some well-thought-out language features would make it easier. And COM... I'm going to have to try wrapping my head around that book again someday... I'm sure the ATL makes it all very simple, but can I use ATL from MinGW? From C? From Perl? And don't try to tell me that I need to learn yet another flavor of XML to make all of this work.

That's mis tus centavos.

(Note: I disclaim perfection. Don't hit me too hard; I admit I haven't done enough of my homework to claim this post isn't full of holes. Once I've looked this whole matter through, if ever, and if I still haven't come up with anything good, I may just have to take a deep breath, lay down a syntax, figure out how to use a lexer generator and a compiler compiler, and throw together some ghastly but very easy-to-use homogeneous aggregator system. Either that, or I wait for Parrot to interoperate with Mono...)

You appear to have misspelt "warnings" as "Safe". There's no point using Safe unless you're doing stuff that needs it.

These days, you should be using 'our' rather than 'use vars'. Plus, you say to avoid globals, but you 'use vars'?

You should learn Perl rather than rely on English.

You should not use Java like variable and function names, except where it matches with perlstyle.

As with most languages, the best way to understand code written in the language is to learn the language. Make use of its features and its strengths. Get involved in the community. Read books, read articles and more articles. Contribute to code repositories. etc.

The Inline module should erase complaints about the difficulties of extending Perl with C (or C++ or Python or Befunge or ...)

The Inline module should erase complaints about the difficulties of extending Perl with C (or C++ or Python or Befunge or ...)

The Inline module should erase complaints about the difficulties of extending Perl with C (or C++ or Python or Befunge or ...)

The Inline module should erase complaints about the difficulties of extending Perl with C (or C++ or Python or Befunge or ...)