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
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
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
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
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
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
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
".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
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
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
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
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
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,
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,
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;
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
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;
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
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
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
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 <[
: 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
> 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
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
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/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
26 matches
Mail list logo
