Beefy Boxes and Bandwidth Generously Provided by pair Networks
The stupid question is the question not asked
 
PerlMonks  

Using PAR: risk assessment

by spurperl (Priest)
on Dec 09, 2004 at 08:55 UTC ( #413454=perlquestion: print w/replies, xml ) Need Help??
spurperl has asked for the wisdom of the Perl Monks concerning the following question:

Dear fellow monks,

PAR is a well known packaging tool for Perl. As simple as "pp -o foo foo.pl" and you have an .exe with all the modules foo.pl needs that can run on PCs that haven't smelled a camel in their lives.

I'm now on the verge of an important decision. There's an application (win 2k) that has to written at work, and I badly want to propose Perl as an implementation. However, this application will work on remote PCs w/o a Perl installation, so I'm naturally inclined to use PAR.

This is a plea to a "risk assessment" advice. I don't want to spend a week coding only to find out PAR won't do... My application will use Tk, Win32::SerialPort and most probably Win32 threads. Have anyone had any problems using PAR with these elements ? Any other technical problems (licensing is not a problem) ?

I personally distributed PAR applications with wxPerl, Tk and other modules, with no problems. It's the tighly coupled Win32 code (SerialPort, threads) that I worry about.

Replies are listed 'Best First'.
Re: Using PAR: risk assessment
by jplindstrom (Monsignor) on Dec 09, 2004 at 09:21 UTC
    I haven't used the Win32::SerialPort module, but PAR works well with e.g. Win32 and Win32::GUI.

    The biggest problem I've had with programs like PAR and PerlApp is their inability to statically (at build time) determine which modules dependencies there are, but that's something you encounter and then figure out for that application.

    The usual risk management strategies say: experiment as soon as possible. Build a prototype with all the modules and kinds of functinonality you need (e.g. threads) and try it out.

    /J

      FYI: The latest version of PerApp from ActiveState ( PDK 6.0 )has a GUI interface !

      It WILL show, AND it will allow you to manage module dependencies in a tree view... as well as additional files you might want to be bound into the exe.

      you can add modules to a trim list, and you can manually add modules to be included if needed.
      It does a good job grabbing most modules required ( and dll's ).

      It also adds a new in-memory DLL loader option.

      and it also allows you save these settings in a project file..

        I've never been a big fan of fancy GUIs. There are some things I do like in the new PDK, but I doubt I'll ever use this particular GUI. I'll stick to my PDKcompile.

        For the original question: I do have a few multithreaded Perl apps packed using PerlApp. Never had any problems with the threads that'd be related to the packing.

        Jenda
        We'd like to help you learn to help yourself
        Look around you, all you see are sympathetic eyes
        Stroll around the grounds until you feel at home
           -- P. Simon in Mrs. Robinson

Re: Using PAR: risk assessment
by polypompholyx (Chaplain) on Dec 09, 2004 at 12:20 UTC
    I've used PAR to compile a Tk application (the woodlice.pl script I bundled with Tk::Taxis), and the executable works absolutely fine, despite the module using Tk, a hand-rolled event loop, Time::HiRes and a subclassed Canvas widget, all of which I thought might cause trouble. The only two issues I had were that the Tk::Taxis module did a use 5.008;, and the PAR I had installed whinged about this - not sure if this was due to PAR itself, or the fact I was using a ppm-installed version rather than compiling it myself - but commenting out the offending use statement fixed this. The other issue was that the module used some JPEGs in the canvas, and these (not being found by Module::ScanDeps) had to be bundled separately from the PAR executable and the path to them hard-coded into the module. All in all, it only took about ten minutes to get it to work. I've not tried it with threaded designs, but considering how little hassle I had with this, I'd be surprised if they caused any more trouble under PAR than they are prone to under normal perl.
Off topic, but...
by bibliophile (Parson) on Dec 09, 2004 at 15:19 UTC
    ...I am continually amazed at how topics come up on PM just as I am about to need them myself.

    Somebody, somewhere has clearly implemented PerlMonks::Precognition, but it's not up on the CPAN yet....

      I just used my local beta copy of the Precognition module to see when I was actually going to finish it. It said it was more usable for World Domination, so I decided against publishing. Of course, if you had my module, you would already know that.
      Somebody, somewhere has clearly implemented PerlMonks::Precognition....

      Yeah, I'm a "synchronicity freak" and think about that all the time. It is amazing how certain ideas all seem to come to the forefront of conciousness at the same time in different individuals. I first encountered this quote by some unknown ( to me ) sage, when learning about relativity.

      "There is no stopping an idea whose time has come". In other words, if Einstein didn't do it, someone else would have in fairly short order.

      I've concluded it's "cosmic conciousness".....some sort of sub-concious psychic link between all creatures. It depends what "channel" you "tune" into.

      Ooops, gotta go, my dog is calling me again. :-)


      I'm not really a human, but I play one on earth. flash japh
Re: Using PAR: risk assessment
by TStanley (Canon) on Dec 09, 2004 at 17:56 UTC
    I used PAR to build this into a standalone app without any problems at all.

    TStanley
    --------
    The only thing necessary for the triumph of evil is for good men to do nothing -- Edmund Burke
Re: Using PAR: risk assessment
by DaWolf (Curate) on Dec 10, 2004 at 06:45 UTC
    Actually I'm having a problem trying to PAR a script I did that shows the proccesses running on Windows and the softwares responsible for them.

    I'm not sure if I should be asking this here, but since it's directly related to this post I'll take my chances.

    My script uses:
    • Win32::Process::Info
    • Tk
    • Tk::HList
    • Tk::ItemStyle

    All this modules were installed via ActiveState's ppm.

    When I try to run the .exe created by PAR I get the following Windows error message (please note that I'm translating the message since my natural language and OS language is brazilian portuguese):

    "par.exe - Entry point not found. It wasn't possible to locate the Perl_Gsv_placeholder_ptr procedure's entry point in the dynamic library link perl58.dll."

    and when I click "Ok" I see this on the command prompt:

    Can't locate object method "_Typelibs" via package "Win32::OLE::Const" at C:/Perl/site/lib/Win32/OLE/Const.pm line 20. Compilation failed in require at C:/Perl/site/lib/Win32/Process/Info/WMI.pm line 162. BEGIN failed--compilation aborted at C:/Perl/site/lib/Win32/Process/Info/WMI.pm line 162. Compilation failed in require at C:/Perl/site/lib/Win32/Process/Info.pm line 190. at script/pmon2.pl line 44

    If I just run the script with Perl it runs fine.

    Here's the code:

    Am I missing something here, or it's all ok and the OP should be aware of this?

    Thanks and sorry again to post a question inside a reply.

      Hello DaWolf,

      I tried Your code on a (german) W2K machine and it works with PAR for me. The difference is just:

      • I use Perl 5.6.1
      • I do not connect to a remote machine. I did :
        Win32::Process::Info->new (undef, 'NT');

      ... but I ran this on a machine without Perl.

      And it came to pass that in time the Great God Om spake unto Brutha, the Chosen One: "Psst!"
      (Terry Pratchett, Small Gods)

        Hi, Brutha.

        First of all thanks a lot for your reply.

        I'll try an upgrade and replacing my machine's name for undef (actually I run this directly on my machine, but I thought the name wouldn't make a difference, since I've used it's name correctly).

        Second, I'd like to apologyze to spurperl and specially to Autrijus Tang (the module author) for putting his work on question.

        -- me!
Re: Using PAR: risk assessment
by Anonymous Monk on Dec 10, 2004 at 15:17 UTC
    PAR works and LibZip works too.

    PAR has a lot of resources to build your package, but if you want a tiny package I recommend LibZip, that make it tiny as possible and try to compress and remove all that is possible.

    I have used a lot LibZip to distribute and run some applications over a grid on Win32 (using threads).

Re: Using PAR: risk assessment
by scrubroot (Novice) on Dec 10, 2004 at 22:05 UTC
    I used to use Perl2Exe here at "Big Pharma" for a few years just as a simple way to package a Perl application for distribution to user's desktops. Perl2Exe worked fine for what I needed, but cost more than I felt something like that should have given what it did at the enterprise level. PAR can do almost all of the same things and you can complain about the price. Granted Perl2Exe would encrypt your source code within the executable, but I didn't really care about that. About two years ago I started to make the switch over to PAR and haven't run into any problems other than the executables getting a few hundred K larger. Speed and stability both seem about the same.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://413454]
Approved by zejames
Front-paged by Ovid
help
Chatterbox?
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others examining the Monastery: (3)
As of 2018-05-25 02:11 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    Notices?