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

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.

Replies are listed 'Best First'.
Re^17: problem with par as other user
by Ace128 (Hermit) on Jun 30, 2006 at 21:21 UTC
    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!
      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 :)

        Thanks for the links! Quite usefull. And you seem to have been doing this for a while. :)

        Question: Since I've been using Perl/Tk alot, what about all those lovely Tk::... modules then? How can one use them with Tcl/Tk instead? Is it just to use them as is or what? Or maybe I'm to tired to realize something crucial... :)

        Among others I find these quite usefull:
        Tk::JComboBox;
        Tk::MListbox;
        Tk::DynaTabFrame;

        Doesn't seem that they are included with Tcl/Tk installation.. Maybe they exist on a CPAN like site somewhere...?

        / Ace