Slashdot Mirror

Yeah, I think the article is a little off base about RTF. It's not IP-encumbered. As you pointed out, you can download the spec from MS. There's a ton of OSS implementations. There are perl modules that read and write it. There's an O'Reilly book on it (free short version of it here).

Okay, so RTF changes when a new version of Word comes out. That means that, e.g., it shouldn't be used for archiving government documents, and it's not suitable as a universal format for people to collaborate on extremely complex documents using different software. It doesn't mean RTF is useless or evil. I write fiction, and RTF turns out to be a very useful lingua franca for magazines that accept electronic submissions. For a fiction manuscript, you don't need anything very fancy --- basically just the ability to underline, and put a header on each page. RTF works just fine for that, and I'm really, really glad that RTF is the de facto standard for this purpose, and not doc.

It's unfortunate that OOo's RTF support is so horrible. E.g., if you save a document from OOo in RTF format, open it, edit it again, and save it again, you lose the whole document. Yeesh!

In fact, the opposite is the case. Tom Christiansen and some other Perl hackers wrote Perl Power Tools (PPT), which provided a pure Perl implementation of various Unix commands. That means that it was like having Unix on top of Perl. Perl Power Tools Background on PPT

All Perl needs is a C compiler, and a standard C library. It runs just about everywhere people want it to.

Take a look at Tcl::Tk or Tkx. They provide a wrapper around an existing Tk, so you don't need to wait for the Perl/Tk to be updated.

Take a look at Tcl::Tk or Tkx. They provide a wrapper around an existing Tk, so you don't need to wait for the Perl/Tk to be updated.

Bleached Perl?

When you'd rather do it in Acme::Eyedrops by hand, then I'll be impressed.

Larry has said that he went too simple for the object model in Perl5. It's different in Perl6.

You might want to check it out once there's something a little closer to the final Perl6 available. Right now, you can try it out but count on updating your kit quite often, as the language is still in quite a bit of flux. For those willing to live on that cutting edge, most of them prefer it to Perl5. They're mostly people who really liked Perl5 but wanted more Lisp, Prolog, Haskell, Ruby, Python, D, or Java niceties.

There's multiple dispatch in Perl6, optional static typing, a full grammar system instead of source filters, proper prototypes, a clearer idea of exceptions, a native switch statement (which there is in 5.10), and more. A large part of Perl6's default object system is available in Perl5 via the Moose packages on CPAN if anyone's interested.

One of the interesting things about Perl5's objects is that, like the language motto says, There's More Than One Way To Do It (often abbreviated TMTOWTDI or TIMTOWDI in the Perl community). There are half a dozen object systems for Perl5 as modules and it's quite possible to write even more. The Perl6 default object model is based on the strengths of some of the more popular Perl5 ones with nice touches from other languages. It'll still be possible to make an alternative object system for Perl6, but it'll probably be a lot more rare that someone does.

You're not that far from reality.

PerlData Link is actually this one, not the current link that points to the blog.

Completely offtopic, but never a bad time to push a worthy tool: there's an excellent command-line, Perl-based tool to upload images to Flickr. Not necessarily your cup of tea if you want/need to organise or sort images before uploading, but if you've got a lot of photos to put online all at one, tagged and titled, this might be the tool for you! Anti-Perl people (the thought!) can look up other script-based command line tools on Flickr's API page (of all places).

STD_DISCLAIMER(no_relation, happy_customer);

FWIW, lots of the powerful bits that make Movable Type great have been GPL'ed for some time: Data::ObjectDriver, XML::Atom, memcached. And of course, OpenID has been an open standard for a while now, too.

FWIW, lots of the powerful bits that make Movable Type great have been GPL'ed for some time: Data::ObjectDriver, XML::Atom, memcached. And of course, OpenID has been an open standard for a while now, too.

Well, maybe 'phone_numbers' to 'numbers' might be a little far, unless you have a business need to restrict numbers in some way. I understand the idea though, that you shouldn't have so many values in your tables, just a lot of FK to very simple tables with just a PK and a value. I don't see this as fundamentally wrong, and sometimes in the end can help make you DB design more flexible. Also any decent ORM would make this easy. My ORM of choice DBIx::Class (current version: http://search.cpan.org/~ash/DBIx-Class-0.08008/) would probably look like

my $telephone = $teacher->phone_number->number;

I'd probably preload the numbers table in the phone_number join to simplify it even more.

If the ORM is designed well it makes it easier to do the right thing DB design-wise, in my opinion.

--john

The Perl 6 community is more focused on getting it right than getting it into the marketplace ASAP. While this is frustrating for many -- it seems like every other day, there's a Perl 6 feature I want to use in my Perl 5 program -- it has contributed positively to the development of Perl 5 and Perl 6 alike. Perl 6 is painstakingly designed and planned as truly a next-generation dynamic language, and as features are completed, they often spill down into Perl 5. (See the perldelta for v5.10, out very soon, for some good examples.)

Unless someone is willing to finance full-time development on Perl 6, this is the best we get. I think it's pretty good.

Like so many other "good" languages, PERL is quickly becoming a dinosaur. At least with PERL, we do have a number of decent replacements...

What are you talking about? PERL was never a good language. Fortunately, it was never as popular as Perl, despite having a confusingly similar name.

I'm not very old, but in the old days ... 1990, we used to pay other companies for reusable code. They called them "Libraries" and came with unlimited redistribution of runtime licenses for no additional charge. Of course, it was easier then because any serious development team only shipped object code (.o, .a, .so, .dll) files with interface files (.h) - you know, header files? http://snippets.snippets.org/index.php

Script-based languages make this just slightly less useful ... to the library vendor. OTOH, I had to use fidonet to find a copy of the C/C++ snippets all those years ago. The internet/google made that a trivial exercise this morning. Perl code has this. It is called a module - http://search.cpan.org/
    I suspect Java, PHP, Python, Ruby all have repositories of reusable code too. Google is your friend, but check the license and be certain your project/company can live with whatever restriction the author chose to use. Generally, I use the v2 LGPL for non-work stuff, myself. For non-core work stuff, BSD license is preferred provided the company doesn't keep it all as a "trade secret". I don't have problems with trade secrets, where they make sense. Company owners tend to want to protect everything for some reason.

So... the formalised use of old code... you mean like CPAN?

(and half a bazillion other projects... Hell, not it's been going on before Microsoft decided they needed a working TCP/IP stack for Windows 2000 or anything...)

/P

Oh, c'mon! It has one potential use - It sounds like a munged pr0n version of something for Perl. That alone would make the effort worth it, no?

/P

Hardware emulation is a provable science. Screw turing, all you need to do is prove any given computer can emulate a sega saturn and it can emulate anything.

As for quantum emulation... there's already an answer to that. :)

Sure: http://www.corion.net/perl-dev/Javascript-PurePerl-0.09.tar.gz

This did not come from cpan.org, I misremembered, though the authors ought to post it there. Came from here: http://www.corion.net/perl-dev/.

That said, depending on what you're doing w/JS, CPAN's worth a look. There are a ton of new JS projects up there in the last six months, including what looks like a javascript interpreter! (Take that, Rhino!) Suggest searching CPAN, there are a lot of exciting new JS projects.

cheers...

I know it's not quite what you asked, but would this work?

Right. So innovative that I only put a CPAN Perl module (CGI::PathInfo) up for that kind of crap, oh, SEVEN YEARS ago.

There are many ways to skin this cat. I believe most of them have been mentioned, but I will outline my experiences anyway.

swish-e is a grand-daddy of an indexer. It can act as a robot, crawl your local file system, or get its input from STDIN. If indexing HTML, swish-e will index the document's metatags and provide field searching against them. Swish-e comes with a C, Perl, and PHP API. I don't think swish-e supports anything but ASCII very well.

kinosearch is my new favorite. Written in C but with a Perl API, this indexer works a lot like Lucene. Its resulting indexes (files) may be readable by Lucene. Kinosearch works by initializing a "document" with attributes, filling each attribute with values, and saving the document. Searching is fast an easy. It does not support wildcard searching, but uses extensive stemming instead. Kinosearch does not index files from your file system; you must parse your data and feed it to Kinosearch.

Ht:/dig is nice, but the last time I looked, it had no API. I found this to be too limiting. It indexes documents.

The Google Appliance is cool (and kewl) but also very expensive. This black box (well, it is really gold or blue) does a lot of the work for you. Configuring its output is dependent on your ability to do XSLT. You can feed the Google Appliance database dumps and other streams of data. Nice. I still think the price is steep.

There's Plucene, a Perl port of Lucene. Too slow, and seemingly unsupported.

Lucene and its kin seem to be the Gold Standard these days. I appreciate that, but alas, I don't have any Java experience. Increasingly people swear against SOLR, a Web Services-based interface to Lucene.

Zebra is an unsung hero. It has been around for more than ten years, actively supported and used extensively in Library Land. (I'm a librarian.) This thing can index just about any kind of document. It supports every type of searching feature (stemming, wild card, fielded, Boolean logic, relevance ranked, etc.). It can read files or be fed things from STDIN. Fast!

As an added bonus, I advocate readers explore abstracting their search interfaces with something like OpenSearch or Search/Retrieve via URL (SRU). These abstract layers allow you to create user interfaces to your underlying indexers without worrying what those indexers are. In other words, these abstract layers define the syntax for queries, the transport mechanism to the index, and the structure of the returned result. Given such a framework, you can write an OpenSearch or SRU interface to your index, but if you decide that Lucene is not what you want to use anymore but Kinosearch is, then you can change your indexer without the need to change your user interface. Very nice. OpenSearch is simpler to implement but is weak when it comes to expressive searches and search results. SRU is more robust but also more complicated.

Try this one:
http://search.cpan.org/~tbone/Crypt-Discordian-0.01/lib/Crypt/Discordian.pm

http://search.cpan.org/~krs/GMail-IMAPD-0.93/lib/GMail/IMAPD.pm

I read a review of it, and I'm not sure I agree with all of the implementation choices, but supposedly it works.

I'd rather have real IMAP from google though.

What? No. There are no limitations in the C implementation of the Python 2 runtime environment that are not also in the C implementation of the Perl 5 runtime environment. Both of the languages have a lot of similar characteristics. Both were developed at around the same time, with Perl starting a few years earlier. Perl 4 came out in 1991, Perl 5 in 1993, Python 1 came out in 1994.

The "Perl engine" only runs Perl code. It does not run any other languages.

You can run Python from within Perl though using both runtimes:

http://search.cpan.org/~neilw/Inline-Python-0.20/Python.pod

And perhaps one day you can run both scripts interchangeably if Parrot achieves is goals:

http://www.parrotcode.org/

In the meantime, if you want to write in a dynamic language you can run Python in the JVM or IronPython in the CLR. Then you can use a single runtime to call into Java or C# or Javascript or Ruby or VisualBasic. You can not do this with Perl 5, it is extremely unlikely that Perl 5 will every be supported outside of it's single C implementation. These limitations in the Perl 5 runtime are why your Perl community has been doing a from-scratch rewrite of Perl these last 7 years or so ...

I want to run Python scripts in my Perl environment because, among other reasons, Python's runtime has the problems mentioned in this Slashdot story summary. And I don't want to have to install and maintain a Python runtime, or learn its peculiarities. But I do want all its functionality, including the Python scripts embedded in lots of my OS. During my transitions from Ubuntu 6.4 to 6.10 to 7.4, the Python libraries and installs got very corrupted, including some apps using different versions of Python side by side, getting entangled (not to mention the bloated redundancy). So I'd like to just have a wrapper for Perl that can handle all those Python scripts.

Python claims to "run everywhere", but I can't find an actual list. I'd be surprised if it actually runs on the extremely complete range of platforms Perl actually runs on. If Python scripts actually ran on Perl engines, then it would.

I'm not entirely clear on why this is more interesting than just using timing like most of the rest of the world does. Perl has, for example, long used a setjmp/longjmp-based timing test for its Math::TrulyRandom package by Matt Blaze and Don Mitchell of AT&T and of course most modern Unix-like systems implement /dev/random and /dev/urandom again based on timing. RFC1750 has given useful directions on how to generate random numbers on generic hardware for well over a decade. I recall first reading this RFC, not long after it came out. It really changed my understanding of random numbers on computer hardware.

This just doesn't seem all that newsworthy, though it's cool enough as yet another random number generation technique, I suppose.

I'm going to take advice on hiring programmers from a Perl cool-aid drinker. Sure, just the very minute I get my brain replaced with a cauliflower. Perl is an horrifically bad language. It's called "write-only" for a reason. It makes great programmers produce merely adequate code, makes good programmers produce bad code, and makes bad programmers think they're great. Feh. A properly trained, incentivized and provisioned Java team can run rings around a Perl team in terms of working code produced, as well as (more importantly) cost to develop and cost to maintain.

If you need a language to keep you from doing bad things, that already suggests that you're a bad programmer. However, I won't deny that there exist bad programmers and as such the language should try to prevent them from doing bad things.

However, on the flame-bait portion of the post: I have experience in both Java and Perl and a number of other things. In the early days yes, Perl was a very bad language and encouraged bad practices. As time went on, things were implemented to help prevent these things. For example everything now has scope and if used correctly, it is actually a little tricky to mix bad code that ignores scope rules and good code that does follow scope rules. Things like the use strict; pragma and my declarations make Perl much more usable and maintainable. Somethings could be better, but it is quite obvious that Perl people are getting it, even more so than some Java people. There are actually a number of benefits to using Perl but obvious you with your closed mind and lack of knowledge refuse to accept that.

Now on to Java. I've worked with Java lot as well. One of the best laid out languages in terms of built-in classes that are ready to use. But it comes at a cost: things get deprecated and now your code won't work if you move to the next version. Instead you're stuck trying to hack a way to get multiple VMs to play nicely on people's machines or you're forced to upgrade the code. Then there's J2EE and all sorts of technologies built on top of Java. Java while organized and has some really good clean syntax, fails miserably at compatibility and packaging of libraries and software. For example if I want to use any specific technology beyond the basic servlet and jsp, I better be prepared to read and read some more about configuring my IDE, classpath and such to use the correct JARs. Then once I've gotten my head over that, the community will start working on the next whiz-bang stuff and now everything I currently use is obsolete. That's because the Java world seems to love building rather than maintaining. If something new comes along, they'd rather deprecate the existing "old" solution and add a new one rather than fix the old. The result is you're always outdated and there's too much documentation to read. I don't mind learning new things, but in the Java world the lifetime of each technology is simply too short to be useful for anyone.

Perl on the other hand has adopted a better model in my opinion. All packages and libraries are installed to the host system and often being some sort of unix, you work directly on the server. Each module on cpan.org is expected to: configure itself, test itself, and install itself. That means when I find a module that can help me or I'd like to use, I do the following:

perl Makefile.PL
make
make test
make install

If a dependency doesn't exist, I will be told. If a test fails I will be told. If I don't care about a couple of test cases failing, I can still install the module. It is very clear to me what is missing and to what degree something is failing (failed test cases). It doesn't get any simpler than that. In Java, you might need an additional JAR but you won't be told until you compile/run where you'll get a nasty message that something is missing. So much for automated testi

I want to log into that machine and run some quantum Perl scripts on it. Nothing like an existing library of code to kickstart a new architecture.

Perl has it.

use Fatal qw(open close etc...);

This lightweight, fast, simple database eliminates many of the headaches associated with using a full-on SQL installation, and works just as well for most of what most developers and users need.

If you're a Perl geek, like me, you will find this Perl module for seamless SQLite interface to be a power tool. The next time you need to get something working by morning, and it's 2am and the person "in charge of databases" hasn't called back, you'll be thanking it.

1. Try out DBD::CSV
2. grep the flat file
3. SQL with joy!

It is much stranger than trinary values like red,green,blue.

The implication is that all the solutions are in there and when you pick the input states everything stabilizes to the correct answer *PPOPOOF*.

The best doc on the subject that I read is the instructions for the perl module docs for Quantum::Superpositions. It is not in any way necessary to know (or even like perl) to read the pod pages for the module.

It was fashionable in perl, for a while, to try to solve problems with superpositions. I think people still do it from time to time.

No platform even comes close to the library support provided by the Java platform.

Perhaps you need to visit CPAN. Use the source, Luke!

A cornerstone of documentation in the Unix/Linux/*BSD world is the man page, a very concise and targetted form of documentation that programmers and sysadmins in particular find extremely convenient, especially for documenting library functions and commandline tools.

Unfortunately many FOSS projects don't provide man pages, not even a single one to document the commandline options of an application for example.

This is where newcomers to FOSS technical documentation could make a wonderful contribution. Just take any existing READMEs etc, or run an app with -h or --help or whatever it takes to find out how it's used (perhaps read the sourcefile headers, even if you're not a coder), and make a corresponding man page. That would be totally wonderful, and much appreciated by many.

What's more, there are many tools available to help you along the way. One good place to start is with perldoc/perlpod and the POD format (which are not tied to Perl at all even though they came from that community). These very handily allow you to generate both man pages and HTML equivalents extremely easily, as well as LaTeX format for high quality output and publishing.

As should be apparent, the best documentation system allow you to generate multiple different forms of output from a single input, and man pages + HTML should be the very least that is acceptable to you. (HTML-only documentation is pretty useless in many situations.) Be sure to check out the man2html suite too, which is very handy.

The Doxygen suite is very powerful as well, but automatically extracted man pages are no substitute for the real thing written by a competent technical author. That's where you come in.

It's great to hear of new people wishing to help with FOSS documentation, and man pages are a key element of the overall picture and an easy place to start as well. They really are the bedrock upon which much of FOSS is based, and deserve attention.

If you really want the flashing lights, swirling thingies or generally make your charts management friendly, I'd recommend this library for PHP (or for Perl use the SWF::Chart wrapper).

With enough animated transitions to last you a good 3-4 promotions you should be set :)

Grace can produce some nice results, but the Perl interface to it is just a wrapper around their terrible command line interface (maybe it's improved in the last few years, but when I tried it it was almost entirely undocumented and nigh-unusable).

There's always Acme::Bleach if you're having trouble making it a one-liner.

Acme::Ook is your friend I guess

Please, no "I'm a frick'in chimp, not an orang-utan, you insensitive clod" jokes please!

oh, I think we may see a few

(Have to give credit to an AC buried farther down for pointing out his contact page...)

In addition to the phone # you've provided, here's a fax #: (315) 663-3036

He also seems to use IM a bit, he's got an AIM account (MikeFromSyracuse), an MSN Messenger account (mike@silentmike.us), and a Yahoo account (mikechatcny).

Oh, and his "email me" page doesn't have so much as a CAPTCHA on it.

You should note that I'm not advocating spamming the living shit out of his ugly, pathetic, lying ass. Indeed, I would never even suggest that you do the digital equivalent of ass-raping his ISP with a railroad spike! I'm just blatantly telling you what you need to know, should you ever hypothetically do such a thing, even though you won't, of course. Wink wink, nudge nudge, say no more!

Just upload your code to CPAN, and the CPAN Testers will test it for you. Easy!

If there's no suitable application out there, I would do this with Perl, starting with a prototype that just reads in text files, processes them, and writes them back - then you can graduate to a more sophisticated version that uses a database if needed.

However, the relevant searching would take some time to do efficiently in a DB, and the stated number of subnets is quite small, so writing the algorithms in Perl would be easier - and as I expected there are some potentially useful CPAN modules:

- http://search.cpan.org/~luismunoz/NetAddr-IP-4.004 /IP.pm - NetAddr::IP, lets you manipulate IP addresses and subnets, including splitting and merging
- http://search.cpan.org/~muir/Net-Netmask-1.9015/Ne tmask.pod - manipulate netblocks, closer to what's needed

Of course, on Windows Perl you can even use Perl as a macro language to manipulate Excel spreadsheets via OLE - or on *nix you can just read the Excel values directly from Perl without converting to CSV. See CPAN for details...

If there's no suitable application out there, I would do this with Perl, starting with a prototype that just reads in text files, processes them, and writes them back - then you can graduate to a more sophisticated version that uses a database if needed.

However, the relevant searching would take some time to do efficiently in a DB, and the stated number of subnets is quite small, so writing the algorithms in Perl would be easier - and as I expected there are some potentially useful CPAN modules:

- http://search.cpan.org/~luismunoz/NetAddr-IP-4.004 /IP.pm - NetAddr::IP, lets you manipulate IP addresses and subnets, including splitting and merging
- http://search.cpan.org/~muir/Net-Netmask-1.9015/Ne tmask.pod - manipulate netblocks, closer to what's needed

Of course, on Windows Perl you can even use Perl as a macro language to manipulate Excel spreadsheets via OLE - or on *nix you can just read the Excel values directly from Perl without converting to CSV. See CPAN for details...

http://cpan.org/ CPAN is for PERL, C-SPAN is for swine.... had to be said