in reply to Re^14: problem with par as other user
in thread problem with par as other user

That's a problem yea. People go after what they know. Since I've been testing PAR, perl2exe out, I have some experiences. :)

Sure, they are good and seems to be working. However, things I've noticed with PAR that I don't like:

1. First of it doesn't clean up itself afterwards. Which is nice in one way, however,
2. I'm not sure how or if it "caches". That is, when running the same file again, does it extract all again or check if already extracted? Can be a problem if script is modified and it runs the same extracted data... and not the new...
3. In memory is WAAY faster aswell, not cluttering up hd. Besides, you shouldn't really rely on that there must be hd space to be able of running some application. It's damn annoying to run out of space in general and if hd gets full while running some app, just because you are just running it is even more annoying.

perl2exe is quite nice too. But since that is commercial I don't like it that much. ;) Also, eventhough I doubt it, but if you "protect" your script using perl2exe, you never know if the creators of perl2exe can get your data.

Since I love doing stuff in Perl, and love the idea of one file, no installation hustle, PAR been nice, but your solution is better. Probably faster aswell. I do apps in perl, pack it and send it (and the reciever doesn't have to care about installing Perl and all modules needed for the script). With PAR it doesn't really feel good knowing it extracts "junk" that it never deletes. Sure, the standalone executable may be abit bigger, and not sharing files between other applications may seem like some waste of space, but in general I don't see how that can be too bad. Besides, having it all in one pack, you have all dependencies there and know that it works. A big plus is also that all files are packed in .zip and only extracted as needed (hopefully this means that same file isn't extracted twice!). Having it all in a .zip means even less space on hd. I'm jelous of programming languages like C/C++ in that way. But with your solution this is pretty close to that. Who cares that the binary may be abit faster than parsing and running scripts when most apps don't rely on pressing every clockcycle out of the CPU. With Perl you can archive your goals faster (and it doesn't have to be wierd, unreadable code) and you can concentrate more on the app in question.

I'm sure I've missed some other points about PAR and perl2exe that I discovered before, but I don't remember them atm.

YAAP could work although I prefer having a name that describes the module more... Hmm...

/ Ace

Replies are listed 'Best First'.
Re^16: problem with par as other user
by vkon (Curate) on Jun 30, 2006 at 20:43 UTC
    first of all, if you're uncertain about PAR features/behaviours, just ask PAR people.
    Fortunately there's mailing list par@perl.org, subscribe by writing a letter to par-subscribe@perl.org. I very doubt they're unresponsive, so they'll shed a light quickly.
    (same for Tcl::Tk mailing list tcltk@perl.org)

    On the speed - after PAR cached its unZIP (after its first run), it will be very the same as within perl library itself, just with slightly different @INC path, it should be reasonably slow only first time. (this is all configurable, AFAIK)
    But if you do want speed boost within perl/Tk apps - go to Tcl::Tk, its faster x2, in addition to be more flexible. Yet perl's memory allocator is a win on win32.

    Actually I agree on all your points about PAR and perl2exe (I meanHDD and opensource)
    Moreover, I suspect that commercial packers go very same way as I did, but their added value is not very deep, its quite near on the surface...
    they did more testing than I did and wrote code, but essential part is small. Perl is almost redistributable without additional packers.

    An essential additional remark:
    I did several versions of bootstrap mechanics of what you've just reviewed, WRT who unzips the file module/perl58.zip
    In some versions its Perl's Archive::Zip, but in the version you've tried this is Tcl/Tk's unzipping.
    If moving to CPAN, then Perl-only solution is preferred, but Tcl/Tk way was faster in this particular case
    (usually perl faster than tcl/tk a bit, but extracting members from perl58.zip was faster in Tcl/Tk because it was implemented in C internally)

    Sometimes I just scared on how many ways to do things. TIMTOWTDI.
    Best regards,
    Courage, the cowardly dog...
    ... err, Vadim.

[reply]
      Confusing with 2 nicks :).
      And if I could just find some proper documentation for Tcl::Tk. I have it installed and love that you just have to change a few things to make PerlTk code run using Tcl::Tk instead...

      Anyway, I'm going with you on this one. I can use PAR in the meantime. Until this is matured enough. Would be nice to make this work properly. And if put on CPAN, and a community is created for it, it can be damn good!
[reply]
        Documentation on Tcl::Tk should be improved, may be I'll improve it someday. But essentially it should refer reader to Tcl/Tk documentation, where widget behaviours and parameters are described. (I did wiki for Tcl::Tk generally for adding documentation by myself at http://www.vkonovalov.ru/cgi-bin/perl-tcltk-wiki.cgi, there are some good examples on code and screenshots)

        But perl/Tk syntax, while recognized to be smart and good, it is too noisy (compared to Tcl/Tk), there are just too many '(' and ',' and '=>'.

        My approach is in the middle. I create widgets and layout with Tcl/Tk and then use perl/Tk syntax to manage existing widgets, similar to http://www.vkonovalov.ru/vtcl-usage/Using_vtcl_for_creating_Tcl-Tk_GUI_for_Perl.html

        May be best choice for you could be Tkx? Look at http://search.cpan.org/~gaas/Tkx-1.04/Tkx/Tutorial.pod. Documentation is good, and author deserves deepest respect, so you'll be on the good way.

        As for alternate packager - I'll add it to CPAN, sooner or later :)

[reply]

In Section Seekers of Perl Wisdom