'do' fails to find file with relative path name in packed app

2009-01-24 Thread Scott Stanton
I'm running into a problem with the 'do' function in a packed application on Windows using perl 5.8.8 and the latest par-packer. As long as the file name I pass to 'do' is an absolute path, everything works as expected. However, if I pass a relative path, the script fails if it is running in a pa

RE: interference from the registry on Windows

2008-12-08 Thread Scott Stanton
we need a bit more error handling/reporting in this code. I'll report back once I figure out where it's hitting the error. --Scott -Original Message- From: Bob Davis [mailto:[EMAIL PROTECTED] Sent: Monday, December 08, 2008 1:30 PM To: Scott Stanton Cc: Steffen Mueller; pa

RE: interference from the registry on Windows

2008-12-08 Thread Scott Stanton
o I'm not sure what it is about this user's configuration that triggers the problem. --Scott -Original Message- From: Steffen Mueller [mailto:[EMAIL PROTECTED] Sent: Monday, December 08, 2008 12:19 PM To: par@perl.org Subject: Re: interference from the registry on Windows Hi

interference from the registry on Windows

2008-12-08 Thread Scott Stanton
I'm running into a problem at a customer site where they appear to have a conflicting install of Perl that is interfering with my PAR Packed executable. My intent is for the packed program to be fully self contained. I would prefer that it have nothing to do with any previously installed Perl dis

problems building large wrapped app

2008-10-14 Thread Scott Stanton
I'm running into crashes on Windows trying to build a large wrapped app (>200MB, it's an installer). The problem happens on the second call to Win32::Exe->new->update in Packer.pm (around line 1257). I'm not sure why we need to set the icon and info for the exe both before and after the append_pa

RE: 2 process of par

2008-08-15 Thread Scott Stanton
You'll also lose the return of the exit code from the child process, which is probably why the tests fail. --Scott -Original Message- From: Bob Davis [mailto:[EMAIL PROTECTED] Sent: Friday, August 15, 2008 2:50 PM To: par@perl.org Subject: Re: 2 process of par bob davis wrote: > I know

RE: 2 processes on win32

2008-08-15 Thread Scott Stanton
One reason the parent process can't exit is that it is also responsible for doing the cleanup if the 'clean' switch is specified. On Windows, you cannot delete a file that is in use, which means it is impossible to delete the .dll and .exe files in the child process. However, the parent can wait

RE: problem with POSIX package and par

2008-05-31 Thread Scott Stanton
".dll files can't change names" That's partially true. You can change the names of xs module dlls because they are directly loaded. The problem is any bundled dlls they reference (e.g. ssleay32.dll) are indirectly loaded by the system. Those dlls must have the original name, and must be found in

RE: problem with POSIX package and par

2008-05-29 Thread Scott Stanton
go away completely if we can get to the point where we only extract dlls and read everything else from the zip file. --Scott -Original Message- From: Steffen Mueller [mailto:[EMAIL PROTECTED] Sent: Thursday, May 29, 2008 2:39 AM To: par@perl.org Subject: Re: problem with POSIX package and p

RE: problem with POSIX package and par

2008-05-29 Thread Scott Stanton
s there magic in par that's supposed to make 'caller' return the unhashed name? --Scott -Original Message- From: Steffen Mueller [mailto:[EMAIL PROTECTED] Sent: Thursday, May 29, 2008 2:39 AM To: par@perl.org Subject: Re: problem with POSIX package and par Hi Scott, Sc

problem with POSIX package and par

2008-05-29 Thread Scott Stanton
I have a trivial program test.pl: use POSIX qw(strftime ceil floor); I create a par binary like so: pp test.pl -o test.exe When I run it, I get the following output: Subroutine import redefined at POSIX.pm line 21. Subroutine croak redefined at POSIX.pm line 29. Subroutine AUT

pp and perl 5.10.0

2008-05-23 Thread Scott Stanton
I'm trying to get pp working with a new perl 5.10.0 build and I'm running into some problems. I'm getting the following confusing error message: $ pp --clean -lib "../server/src/perl" --exclude Text::Iconv \ --exclude Unicode::Map8 --module warnings::register \ -o ectool ectool.pl Can't

RE: :Packer segmentation fault with threads

2008-05-14 Thread Scott Stanton
eanup code are worth looking at if you are working on this stuff now. We're using these patches in our production code and it seems reasonably stable, although we're not using threads. -Original Message- From: Steffen Mueller [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 14,

RE: :Packer segmentation fault with threads

2008-04-15 Thread Scott Stanton
I'm not familiar with Perl's threading model. Is it possible the END block is being called for each thread? I can see how that might cause segfaults if a memory mapped library is moved from its original location while still in use. Some platforms don't handle that very well. If that's the case,

RE: problem with pp

2008-01-08 Thread Scott Stanton
r the change might not be enough. Also, you may see no debug output due to buffering. Try setting $|=1 at the top of the script. --Scott -Original Message- From: Roderich Schupp [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 08, 2008 9:27 AM To: Steffen Mueller Cc: Henry Wu;

RE: problem with pp

2008-01-07 Thread Scott Stanton
EMAIL PROTECTED] Sent: Monday, January 07, 2008 11:52 AM To: Scott Stanton Cc: Henry Wu; par@perl.org Subject: Re: problem with pp Hi Scott, thanks for chiming in. Scott Stanton schrieb: > I think the problem can be resolved with the following patch. Give it a > try and let me know how i

RE: problem with pp

2008-01-07 Thread Scott Stanton
I think the problem can be resolved with the following patch. Give it a try and let me know how it goes. --Scott --- par.pl 2008-01-07 10:36:58.166470600 -0800 +++ par.pl.new 2008-01-07 10:36:42.996128400 -0800 @@ -680,8 +680,12 @@ }x; my $extract_name = $1;

RE: Improving speed of par app startup

2007-11-28 Thread Scott Stanton
Well, sort of. I need a solution that is portable across Solaris, Linux, Windows, MacOSX, HP-UX, etc. with minimal fuss. A pp app gives me portability and simplicity of installation (i.e. no installation required). The user can simply copy the binaries anywhere they like and it just works. I

RE: Improving speed of par app startup

2007-11-28 Thread Scott Stanton
of the overhead. --Scott -Original Message- From: Roderich Schupp [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 28, 2007 8:57 AM To: Scott Stanton Cc: Steffen Mueller; par@perl.org Subject: Re: Improving speed of par app startup On Nov 28, 2007 5:42 PM, Scott Stanton <[EMAIL PRO

RE: Improving speed of par app startup

2007-11-28 Thread Scott Stanton
our users that they have to disable their anti-virus software before they use our applications is not an option. --Scott -Original Message- From: Dr.Ruud [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 28, 2007 2:06 AM To: par@perl.org Subject: Re: Improving speed of par app startup

RE: Improving speed of par app startup

2007-11-28 Thread Scott Stanton
slower than I'd like. --Scott -Original Message- From: Roderich Schupp [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 28, 2007 12:42 AM To: Scott Stanton Cc: Steffen Mueller; par@perl.org Subject: Re: Improving speed of par app startup On Nov 27, 2007 11:05 PM, Scott Stanton <[

RE: PAR: shared library dependencies

2007-11-27 Thread Scott Stanton
: Steffen Mueller [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 27, 2007 11:44 AM To: Scott Stanton Cc: par@perl.org Subject: Re: PAR: shared library dependencies Hi Scott, Scott Stanton wrote: > I just updated to the latest M::SD and have started seeing problems on > Windows related t

Re: Improving speed of par app startup

2007-11-27 Thread Scott Stanton
> Steffen Mueller wrote: > That's actually a good idea: Avoiding dll file name clashes using a > directory for each external (non-perl-module) dll. Currently, we extract > the external dlls under their original name, IIRC. However, I don't know > how you can make those directories accessible to

RE: PAR: shared library dependencies

2007-11-27 Thread Scott Stanton
I just updated to the latest M::SD and have started seeing problems on Windows related to case sensitivity. The call to scan_dispatch() ends up creating multiple entries for the same module with different spellings. For example, on my system I end up with both 'Socket.pm' and 'socket.pm' as keys

Improving speed of par app startup

2007-11-26 Thread Scott Stanton
I am trying to find a way to get self-contained par apps to approach the speed of PerlApp binaries on Windows. I ran a few tests on a sample application to compare performance on my system. Here are my results: First, I made a standard perlapp self-contained executable. Perlapp unpacks just

PAR-Packer dependencies

2007-10-18 Thread Scott Stanton
PAR-Packer/trunk/Makefile.PL lists a dependency on PAR version 0.977, but par/trunk/lib/PAR.pm still claims to be 0.976. Is this intentional? --Scott