|
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
| [reply] |
|
|
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..
| [reply] |
|
|
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 |
| [reply] |
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. | [reply]
[d/l]
[select] |
Off topic, but...
by bibliophile (Prior) 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....
| [reply] |
|
|
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.
| [reply] |
|
|
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
| [reply] |
Re: Using PAR: risk assessment
by TStanley (Canon) on Dec 09, 2004 at 17:56 UTC
|
| [reply] |
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.
| [reply]
[d/l] |
|
|
| [reply] |
|
|
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!
| [reply] |
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).
| [reply] |
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.
| [reply] |
