Slashdot Mirror

The evaluated http://gate.ac.uk/ which is GPL software but ended up using http://search.cpan.org/~acoburn/Lingua-EN-Tagger/. There are several other tools in this space that can be glued together to create this type of software:

http://www-nlp.stanford.edu/
http://tcc.itc.it/research/textec/tools-resources/ jinfil.html
http://wordnet.princeton.edu/
http://www.alias-i.com/lingpipe/web/faq.html
http://www.isi.edu/licensed-sw/halogen/index.html

Not trivial, but if you wanted to DIY, you don't need to start from scratch. Though, having a bunch of hardware to chug through 1000s of documents would still be needed :).

I don't see why everyone is so critical of PHP.

PHP started out as a set of Perl scripts in 1995, presumably using the then-new Perl 5. When it became its own language in 1997, it somehow lost namespaces, the module loading system, DBI, use strict, and everything else in Perl that doesn't register on the suck-o-meter. It also did silly things like adopt the TCL global variable system, rather than using the one that C, Perl, Java, and even things like VB use.

So, yeah, there's a reason every is critical of PHP.

Sources: perldoc perlhist (perl 5.000 was released on 1994-Oct-17), PHP History (PHP/FI 1.0 was a bunch of Perl scripts released in 1995, PHP/FI 2.0 was written in C in 1997), DBI::Changes (First official DBI release was 0.58 released in 21 June 1995)

I don't see why everyone is so critical of PHP.

PHP started out as a set of Perl scripts in 1995, presumably using the then-new Perl 5. When it became its own language in 1997, it somehow lost namespaces, the module loading system, DBI, use strict, and everything else in Perl that doesn't register on the suck-o-meter. It also did silly things like adopt the TCL global variable system, rather than using the one that C, Perl, Java, and even things like VB use.

So, yeah, there's a reason every is critical of PHP.

Sources: perldoc perlhist (perl 5.000 was released on 1994-Oct-17), PHP History (PHP/FI 1.0 was a bunch of Perl scripts released in 1995, PHP/FI 2.0 was written in C in 1997), DBI::Changes (First official DBI release was 0.58 released in 21 June 1995)

My current job invovles alot of work similar to what you have to do. Both Visual Basic and Perl can do anything within office that Visual Basic for Applications can do. VB accomplishes the connection by specifying the respective office compenent's DLLs in the VBs references dialog box. Perl can talk to Office via Win32::OLE pm, see http://search.cpan.org/~jdb/libwin32-0.26/OLE/lib/ Win32/OLE.pm. Using the method produces code very similar VBA macros but with all the advantages of perl syntax and functionailty. In your situation I would use Perl for its excelent Office interaction and ease of text processing. There are nice free tools out there for packaging perl scripts as transparent binaries as well, so you don't have to worry about people not having Perl, etc on their laptops.
I'll check up this thread later if anyone wants to pick my brain about this stuff.

Perl's DBIx::Class comes to mind.. im pretty sure its been around since before 2000, though Id have to verify that.. and I'm pretty sure ORM wasnt the authors of this module's idea.. IANAL but this seems like it would be an easy case for Red Hat to win, on the surface.

http://search.cpan.org/~jrobinson/DBIx-Class-0.060 03/lib/DBIx/Class.pm

"Perl is the most wonderfully architected, elegant, flexible language in the world."

Indeed. In fact, it's the only language in the world that can guarantee perfect software, every time. Even when you're drunk. 8^)

"Perl is the most wonderfully architected, elegant, flexible language in the world."

Indeed. In fact, it's the only language in the world that can guarantee perfect software, every time. Even when you're drunk. 8^)

(shameless plug)
Try this Perl module. You need double-ROT-128 to secure arbitrary binary data.

See? Completely less capable.

Seriously though, I meant to link to PERL instead.

How about Catalyst-View-PHP.

The post said Perl, not PERL. The latter isn't as capable.

as almost always, CPAN is your friend in all things perl-related.

aside from that, i really don't understand why you'd use PHP if you're familiar enough with perl to use it.

mod_perl is mod_perl... it will always suck to some extent. I think if you're looking for better ease of use while still retaining the performance and caching enhancements, you'd be better off looking at SpeedyCGI (CPAN) either in its shebang form (for the cost of a fork) or via mod_speedycgi.

Virtually all of the benefits of a persistent perl implementation, with little of the pain of migrating to mod_perl's runtime and dealing with Apache:: modules up the yingyang (as long as your script is already use strict compliant).

I, for one, can't wait until I can use this, as I'm often asked at my job to generate Excel reports of insurance claim data to send off to insurance company employees, and it'll be nice not to have to open up OO.org just to copy and paste the CSV data from the DB just to convert it to XLS, as the recipients of the spreadsheet wouldn't know what to do with comma-separated data. (emphasis added)

Here is a fish: (*) What if there were a tool that would, say, convert CSV to XLS format? Knowing that a huge number of translators are available, I took a guess and googled:

csv2xls

csv2xls.pl

Learn how to fish: In general, "There's got to be a better way" is a flag which tells me:

• - Wait a minute!
• - There may already be a solution.
• - Don't reinvent the wheel.
• - Look and see what other people have done in the same (or in a similar) situation.

So, this problem was an instance of the general case of looking for a tool that converts from one extension to another. ps2pdf, pdf2txt,

Even if I don't find an all-inclusive solution to my problem, I often find other supporting tools that make my life easier. Further, I can then often use those tools / techniques to simplify things to the point where I CAN solve the problem.

(*) Give a man a fish and you feed him for a day. Teach a man to fish and you feed him for a lifetime. - Chinese Proverb

> What could be better than this for programming in Whitespace!! [?]

Why, Acme::Bleach of course.

(And, even cooler, is Acme::Greek ;))

> What could be better than this for programming in Whitespace!! [?]

Why, Acme::Bleach of course.

(And, even cooler, is Acme::Greek ;))

> I just mirror my scsi disks with a big ultra-ATA device weekly and daily.

You might like my backup software, Chroniton. It will happily run from cron and make incremental backups (and allow you to easily restore from one). It also stores everthing to the filesystem, so even if my software crashes and burns (which it won't; it's heavily tested in practice and with unit tests :), your data will still be just fine. All of your file's metadata is safely versioned and archived, as well. Take a look, it's perfect for backups to external hard drives (that's what it's designed for anyway).

Version 0.03, due out tomorrow, will support backup of extended filesystem attribures and will default to the builtin tar on systems without GNU tar. :)

Mechanize::SpamCop is another tool you can use.

How in God's name would you switch a from MySQL to PostgreSQL to Oracle to MS SQL or to anything. Have you ever actually written a real database application?

You said:
        It's been my experience that Perl sucks at this and PHP excels.

I think that you are fairly correct in your assessment. I would only add that it seems to fail to suck quite as strongly in this regard if you use petal

Oh, and yes. PostgreSQL does support views.

'Sounds like a rudimentary form of Lincoln Stein's CGI.pm . See http://search.cpan.org/ for more.

I second this! Templating systems abound, and are actually easier to use than embedding markup in code (or worse, code inside markup, as is possible with PHP[0]).

In fact, looking at Perl's HTML::Template module, one can see how easily and quickly anyone with HTML knowledge can make a template.

It's not just limited to HTML, either. The Template Toolkit is a very easy-to learn templating system that works for any kind of text-based templates. I've even seen it used to populate ODF documents...

Basically, there's just no excuse for not separating code and data this way in any kind of production code.

[0]: Not knocking PHP, here: good PHP programmers avoid escaping from markup into PHP, but PHP *does* make it possible. A lot of programmers abuse the capability.

One thing to look at is CGI::Ajax. Also the home page.

At least I can do testing and some other nice things without coding javascript.

Here are a few of mine:
http://images.google.com/images?q=%25s
http://www.imdb.com/find?q=%25s
http://www.m-w.com/cgi-bin/dictionary?va=%25s
http://freshmeat.net/search/?q=%25s&section=projec ts
http://search.cpan.org/search?mode=all&query=%25s
http://dir.gmane.org/search.php?match=%25s
http://search.gmane.org/search.php?query=%25s&sort =date

Try Data::Encrypted found on CPAN (http://search.cpan.org/~amackey/Data-Encrypted-0. 07/Encrypted.pm)... From the module description:

Often when dealing with external resources (database engines, ftp, telnet, websites, etc), your Perl script must supply a password, or other sensitive data, to the other system. This requires you to either continually prompt the user for the data, or to store the information (in plaintext) within your script. You'd rather not have to remember the connection details to all your different resources, so you'd like to store the data somewhere. And if you share your script with anyone (as any good open-source developer would), you'd rather not have your password or other sensitive information floating around.

Data::Encrypted attempts to fill this small void with a simple, yet functional solution to this common predicament. It works by prompting you (via Term::ReadPassword) once for each required value, but only does so the first time you run your script; thereafter, the data is stored encrypted in a secondary file. Subsequent executions of your script use the encrypted data directly, if possible; otherwise it again prompts for the data. Currently, Data::Encrypted achieves encryption via an RSA public-key cryptosystem implemented by Crypt::RSA, using (by default) your own SSH1 public and private keys.

Why not just store the username/a hash of the password in a cookie?
The credential check would then be a comparison of the hash and a hashed entry in a database. This way, the password is never stored in plaintext.

Another method that I've seen involves a one time pad with sessions (stored on the server), so that no single side has sufficient information to determine the password. The only problem with this is that the password length would be revealed .

Of course, you could then just take advantage of sessions and store it on the server side. For Perl, CGI::Session (http://search.cpan.org/~markstos/CGI-Session-4.13 /lib/CGI/Session.pm) might work.

Ricky

> I can't say that I've *ever* seen PHP or Perl that looked like someone put some thought into it.

I think you should pay a visit to the CPAN. It's 4G+ of perl modules that are well documented, fully unit-tested, and largely platform independent. I've seen some bad web applications in my time (all PHP incidentally), but there are plenty of excellent perl programmers writing excellent perl code.

If you're interested in learning to write good Perl, I suggest you take a look at Damian Conway's book, "Perl Best Practices".

http://www.amazon.com/gp/product/0596001738/102-74 64862-7276945?v=glance&n=283155

(And of course read Perl's excellent Fine Manual.)

It'd probably be possible to port Gnome to C++/Qt, or KDE to C/GTK.

Just rewrite every thing in Perl!

;-)

It'd probably be possible to port Gnome to C++/Qt, or KDE to C/GTK.

Just rewrite every thing in Perl!

;-)

For another, a lot of those are that way because *iTunes* did not get the CDDB data, ...

...and I had to manually enter the artist and album tags.

Or, as many other people have suggested, if you've already made the odd choice to manually enter this data as filenames and directory structure but not id3 tags, you can use either your own or someone else's tools to propagate that information in the other direction.

Maybe you need to investigate something like MP3::Tag that would allow you to write a simple script to iterate through your directories and add the tags that would allow iTunes to pull in your existing files. In doing so, make sure that the track number tag is set. I've found that some mp3 players will ignore naming convention and sort the songs by the name of the song in the ID3 tag if the track number isn't set. The iTunes program may be doing the same thing.

It all boils down to iTunes uses the tags in the mp3 files for determining how it arranges them in the library. It would be nice if it auto-tagged files by their directory structure if no tags exist. I don't know if someone has written a plug-in to do that or not. But, if you want iTunes to be the library for your files, you need to get those mp3s tagged.

> Beat that!

OK. Catalyst (MVC framework), Prototype, and Perl. Hundreds of times more functionality, and infinitely less expensive.

> Beat that!

OK. Catalyst (MVC framework), Prototype, and Perl. Hundreds of times more functionality, and infinitely less expensive.

The disadvantages of Ubuntu, as I see them, are:

1. It's a bleeding-edge distro. Every release ships with some broken stuff. For instance, one of the most important apps I need to use every day is a Perl/Tk app, and it turns out that Perl/Tk is broken in breezy badger (Perl/Tk apps crash when run alongside GTK2 apps).
2. For people (not me) who really care a lot about doing audio and video, I can see how it might be convenient to have a commercial distro, where some of the proprietary codecs, etc., would be easier to install.
3. For people (not me) who want commecial support, a commercial distro might be better.

I am using Firefox under Linux.

Open in a New Window works fine for me.

Sample search: perlfunc (the Perl "functions" man page)

Their link is an elaborate redirection, but it includes the referenced URL:

http://g.msn.com/9SE/1?http://www.cpan.org/doc/m anual/html/pod/perlfunc.html&&DI=293&IG=9da9786ace 3b46b69a7236fae232eb6f&POS=5&CM=WPU&CE=5&CS=OTH&SR =5

But when I right-click on it, and select Open Link in New Window, it does just that. And the displayed page is a nice, clean redirection to CPAN.org. (Of course they've got me in their Permanent Record now.)

Ironically, this page doesn't contain the term "perlfunc", it's been removed since they indexed it, so CPAN.org redirected me too.

So where's the cache entry?

:-)

Keep in mind Interchange grew out of a time when the web was wild and young, and pre-packaged e-commerce options were few.

These days, Perl's CPAN offers a tremendous amount more in the way of high quality building blocks for such a project, but nothing I'm aware of has been built with this approach with a feature-set that comes close to rivaling osCommerce. Handel is start, but only covers basic shopping cart functions now.

The appeal of osC is the 2000 contributions that are available for free as extensions. Having helped several people set up stores with it, basically whatever customization people want, someone else has already made it and published it for free, so there has been a very low cost to get started with osCommerce for each store.

Still, I agree it can be painful and scary to work with. I miss automated test suite, like I'm using to building based on Perl's Test::WWW::Mechanize. It pains to me to hand apply a patch that doesn't come as a diff, but a series of instructions like "Around line 23, notice this code and add this line....".

In the short term, I support osCommerce for pragmatic reasons. For the longer term, I encourage developers to continue to build cleaner solutions from the ground up. For Perl, see Handel as a starting point.

Catalyst is the hot new Perl based Model-View-Controller framework. It's been out for about a year, it's production ready easy for any competent programmer to work with, and backed by massive collection of libraries on CPAN. It has a large friendly and active user community, which you can find via the website.

Me, I'm using it for lots of things - my project of the moment is gluing in some of the tasty AI modules on CPAN into it for automatic classification.

> You just wait! Perl 6 is coming... Any minute now... should be here soon... really... oh heck...

What features of Perl 6 are you waiting for? Many are already available for Perl 5 on the CPAN.

On the server side ...

• PDF::API2 for LAMP.
• Apache Formatting Objects Processor for J2EE
• I used PDFLib for ASP.NET but it now appears to no longer be open source. Curious as I didn't think that was possible. Goggling around found PDFSharp.
• PyX is for Python developers.

> Sadly, the programming language cannot be changed due to reasons of efficiency and availability of core libraries.

You can easily embed C/C++ in other languages. Take a look at Inline::CPP, for example. With code like:


      use Inline CPP;

      print "9 + 16 = ", add(9, 16), "\n";
      print "9 - 16 = ", subtract(9, 16), "\n";

      __END__
      __CPP__

      int add(int x, int y) {
            return x + y;
      }

      int subtract(int x, int y) {
            return x - y;
      }


you can put the parts that need to be fast in C++, and the parts that need to be easy in Perl. (If you do the GUI in perl, you won't have to worry about portability or memory allocation. And the app will be fast, because the computation logic is written in C++.)

> The application can be naturally divided into several modules, such as GUI, core data structures, a persistent object storage mechanism, a distributed communication module and several core algorithms.

Yup. There's no need for the GUI to know how to do computations, remember. The more separate components you have, the more reliable your application (can) be. Make sure you have good specs for communication between components. Ideally, someone will be able to write one component without having the other one to "test" with. For testing, write unit tests that emulate the specs... and make sure your tests are correct!

http://search.cpan.org/~ingy/IO-All-0.33/lib/IO/Al l.pod#A_Tiny_Web_Server

Your point?

I don't think the source code to del.icio.us is open. This is why I use de.lirio.us instead, which uses Rubric: "a notes and bookmarks manager with tagging."

-metric

Perhaps you can use Perl from inside Java or .Net? I don't know, here's the source of that perl module just in case:

http://search.cpan.org/~wross/HTML-TagFilter-1.03/ TagFilter.pm

use HTML::TagFilter;
my $tf = new HTML::TagFilter;
my $clean_html = $tf->filter($dirty_html);

In general when looking at restricting things I find it's better to determine what is ok instead and only let through those things you know are not harmful. For example, maybe you wrote a website in 1998 that let users post to a guestbook, so you filtered out javascript, frames, etc. Well along comes xhtml+css and now there's new ways to embed javascript, so you have to update the things you strip out. You are now constantly reacting to the changes or extensions of the specification which may result in malicious behaviour in the future.

Instead the easier way would be to do something like only allow img, b, i, and a tags, and for img you only allow src attributes and for a you only allow href attributes. For both those attributes they must start with http:/// or https://./ Now no matter how html changes in the future or new browser extensions are added, they can't be exploited because your policy, by default is going to deny those things since they are new and not allowed.

Being a perl person, I use a module from cpan for this called HTML::TagFilter, which saves a lot of time :p

Perl is a REALLY sweet language. The only thing that i don't like about it is its poor OOP support - i always preffer to code the "old fashion" way (to the point i even dislike objects), but right now i'm working on a proyect sposored by my university, and trying to model a large network using object-oriented code is quirky on Perl, to say the least.

    Other than that, i really like it. It's easy to write, runs really fast for interpreted code, and and it's extensible as hell (CPAN). Great for scripting!

If people don't want their code used in any situation, perhaps they should consider the Death and Repudiation License.
http://search.cpan.org/src/AUTRIJUS/YAML-Syck-0.04 /COPYING

Don't get me wrong, Perl's extensibility (and the sheer size of CPAN) is probably its greatest strength. But other languages (including Python) have lots of extensions and available libraries too; if you're going to compare languages, compare the language itself. Libraries and extensions are a whole other story.