Re: Shipping a Perl/Tk App

[jpeg]

At this point I'd suggest you go to java. It's going to be way easier to learn enough java and swing/swt and write a functional applet than it is to monkey around packing perl interpreters for PPC,Sparc,x86 and whatever else AND Tk libs AND Tk.pm into one package AND have it install, configure itself and run without benefits of the make install tests AND deal with the possibility of the user not being able to install software. It sounds like a nightmare.

This is one of the problems java was meant to solve. Java really isn't that bad. Try it.

Update:
Since the code you showed is a hello-world, I'm assuming that your app isn't written yet and you're in the planning stages. If you already have the app written, then obviously my advice isn't reasonable.

[tomazos]

Not to be impolite, but I have done my share of sipping on the Applet/J2SE/J2EE cool-aid but it just won't stay down. One word "ArrayIndexOutOfBoundsException". Imagine what the identifiers look like for the really complicated things like... ah... handling file streams. Its 50 shades of wrong.

Java is slow to write, slow to run and Sun don't let you compile it from source. Its half-open source.

The only supposed good thing about Java is that it stops people from writing difficult to read code by limiting them to spelling everything out in painfully verbose detail.

Or maybe I don't know what I am talking about. Tell me I'm missing something. What is good about Java?

[gri6507]

PAR takes care of all of the packaging issues. It even has packages a perl interpreter. As a result, the deliverable is a single executable that contains EVERYTHING. I don't see why you say it would be a problem. If you mean learning to program is Tk is difficult, then I would tend to disagree, because that's a relative statement. To some learning Java is more difficult that Tk

[jpeg]

Can PAR deliver a single binary that will run on Mac OS, Windows, and any flavor of 'nix? That's how I interpreted tomazos' requirements.

[waswas-fng]

well, even if you look at the *cough* ton *cough* of java apps that are shipped out there many you will find still ship separate installers for each platform. This is because they either a) require a specific vendors or version of java vm, b) run native code anyways to work with native os functions, or c) are written in such a way that they must be tweaked to run on each platform. I see no difference packaging up 3 PAR bundles (solaris, windows, linux) and offering them based on the OS that you will be running on.

[tomazos]

Well single binary would be nice, but I don't mind compiling multiple binaries. The important thing is that I want a single codebase, and that I am writing it in an easy-to-use rapid development environment (why I am trying to pick Perl/Tk). I have minimal time to spend on this side project, so every minute of my development time is at a premium.

The requirements of the actual project should really be handled by a web server/browser/HTML/CSS/Javascript, but even the minimal stuff I want to do in terms of text editing/diffing and displaying a simple tree of data are way too hard for the browser implementation of CSS/HTML to handle in a way that is consistent across platforms - and believe me I tried. Browser support for CSS 2.1 is about an inconsistent 50%.

Plus I enjoy writing code in Perl/Tk. I'll give PAR a shot.