Hi list,
after yesterday's PAR 0.93 release, I decided to add a very simple new
feature: Starting with the SVN revision 104, pp accepts filenames as
parameters from which to read options.
Long command lines are a cause for concern on Windows where the length
of a command line is
Hi,
That did the trick on both platforms. ( setting TMPDIR )
Thank you.
But, from my point of view it would be better to
set this within perl. TMPDIR will probably be set
on lots of systems and can´t be changed without creating trouble.
And it should not be that hard to implement it in
Steffen Mueller:
If I could find a
(legal) copy of the (fast) Microsoft VC++ compiler, I would have
engineered a 0.91 release already. But I'm still hunting for a copy
without shelling out boat loads of cash. (So if you have a spare
license ...)
This might help:
the problem was not DOS or UNIX format or anything else but POD in a
string. My module generates POD at runtime, and so the code contains
something like
my $synopsis=EOS;
=SYNOPSIS
code here
EOS
which made pp cut everything from the =SYNOPSIS line on. As it is in a
string
On 1/3/06, eyck [EMAIL PROTECTED] wrote:
pure perl can be cross-platform compatible, same goes for par-archives of
such scripts, but binary files (and such is the one that you created)
sually are not supposed to run on different OSes.
Ok, I think that's where my mis-understanding
So how does code that expects non-library files like .mgk files, to be
found in certain locations relative to other files work when they are
not found? Of course, a lot of the .mgk files are optional and you
get defaults when they are not found, but what if you don't want the
defaults?
On approximately 12/11/2005 3:21 AM, came the following characters from
the keyboard of Steffen Mueller:
So I took the low-tech way of downloading from CPAN, and adding the
par_unsetenv line per the above suggestion.
So then I recompiled the world, including several PAR-using
On approximately 12/11/2005 3:21 AM, came the following characters from
the keyboard of Steffen Mueller:
So then I recompiled the world, including several PAR-using
applications, and all the ones that also use Image::Magick from the
Bribes repository (which was set up to work with PAR,
On approximately 12/12/2005 4:17 PM, came the following characters from
the keyboard of Glenn Linderman:
. . .
Seems like one could fix or workaround the missing libraries by
doing explicit --addfile commands? Except that --addfile doesn't seem
to always extract the resulting files.
On approximately 12/12/2005 6:20 PM, came the following characters from
the keyboard of Alan Stewart:
I really haven't fully investigated the algorithm by which Image Magick
finds its libraries, but the default build makes it very tied to the
installation of Image Magick in a particular
I tried the --link option you mentioned in another branch of this
thread. It didn't help. It did result in two copies of each of the
Image Magick libraries being included in the built executable, though...
one in shlib\MSWIN32 and the other in lib\auto\Image\Magick\
but they
);
sprintf(buf, PAR_ARGV_%i, i);
par_unsetenv(buf);
par_setenv(buf, argv[i]);
}
and recompile PAR.
HTH, Alan Stewart
On 17 Mar 2005 at 13:11, Schupp Roderich (extern) Com MD PD SWP 2 wrote:
Alan Stewart wrote:
What about bracketing the whole pp stuff into
=begin pp
...pp information, format TBD...
=end pp
I was also thinking that way. However, =head2 shows up in the
output
think it
might
fit with gpp (opening a source file directly instead of a .gpp file).
Thanks in advance,
Robin
Alan Stewart
. But is there
anything I can do to make pp works with this crazy module?
This is not the only Module that uses non-.pm stuff inside the installed lib.
That's
one of the situations -a or -A exists for.
Matt
Alan Stewart
in test_129. You only need
to copy it to site/lib/.
Alan Stewart
It worked.
For completeness, let me add
1) I went into the directory where I originally unzipped PAR a month ago.
2) I copied over your new zip, unzipped it and copied the new PAR.pm to
./lib/PAR.pm, overwriting the old
On 28 Feb 2005 at 22:48, the.noonings wrote:
My zip posting of the modified PAR.pm was silently blocked from [EMAIL
PROTECTED] The
modified PAR.pm and par.pl are available in the svn repository.
Alan Stewart
The answer is obvious, I know. I also know (I just KNOW) I am going to look
I mis-stated: the patched PAR.pm will require re-compiling PAR to get it into
parl.
Just copying PAR.pm over is insufficient.
Alan Stewart
= [ \okay_response,
$we_top,
]
)-pack(-ipadx =10);
#
MainLoop;
#
}
Alan Stewart
,
either.
Alan Stewart
On 23 Feb 2005 at 8:42, the.noonings wrote:
- Original Message -
From: the.noonings the.noonings[at]verizon.net
To: par[at]perl.org
Sent: 21 February 2005 20:27
Subject: Works as root but not as user
Hello,
I have a problem running pp on Mandrake Linux as a regular
global because, once set, they affect all subsequent PAR apps.
Alan Stewart
two runs of an app under
different
conditions, or maybe from running pp (which also creates temps) and then the
app.
Alan Stewart
the PAR pieces and re-installing PAR 0.87. I have
had
executables not run because of -d, but I have never had pp itself bomb because
of -d,
so I am guessing your PAR install is messed up.
Alan Stewart
.
Robert
I saw your question on comp.lang.misc and interpreted the errors you got there
as a
possible icon problem, but that is not true here. I have had no problem with
the -d
option for any script I have. Can you give us a small example script that fails
for
you?
Alan Stewart
want obfuscation, you need to use a PAR obfuscation filter,
like:
pp -f Bleach
or:
pp -f Bytecode
By default, PAR packages can be read with any zip file utility. Even so,
obfuscation
only slows down the determined hacker. It won't stop him.
Alan Stewart
defaults. Do you need the original permissions or would a better
default or a pp option for the default permissions be acceptable?
BTW, my unzip (Info-ZIP 5.42) say that I need unzip -X to restore ACLs from
the zip
file when unzipping.
Alan Stewart
.
Robert
I saw your question on comp.lang.misc and interpreted the errors you got there
as a
possible icon problem, but that is not true here. I have had no problem with
the -d
option for any script I have. Can you give us a small example script that fails
for
you?
Alan Stewart
On 4 Feb 2005 at 12:00, Alan Stewart wrote:
On 18 Jan 2005 at 15:36, H. Wade Minter wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I'm using PAR/pp to package my Perl/Tk app, and it's all good. Now I'm
moving in the direction of setting up a simple plugin architecture
On 4 Feb 2005 at 22:03, Salih Gönüllü wrote:
Alan Stewart wrote:
You are right. The docs for Archive::Zip say that anything added with
addString() will
have permissive defaults. Do you need the original permissions or would a
better
default or a pp option for the default permissions
On 19 Oct 2004 at 19:58, Edward Peschko wrote:
ok, then another question.. have you used vc6 to compile perl itself? For some
reason,
when I use vc6, ..\perl.h has a bunch of incorrect return codes (ie: it expects
'sys/time.h' which doesn't exist, and has 'long long', etc), and I looked
for a gpp bug fix.
Alan Stewart
errors, so it silently gets what it
can.
Alan Stewart
Perl modules that you are using in this app?
Alan Stewart
over after the crash somewhere.
-jess
-Original Message-
From: Alan Stewart [mailto:[EMAIL PROTECTED]
Sent: Friday, September 17, 2004 9:11 PM
To: Jesse Schoch; [EMAIL PROTECTED]
Subject: Re: Par locking, death, and purgatory
On 17 Sep 2004 at 12:31, Jesse Schoch wrote
On 22 Aug 2004 at 0:20, Pavel wrote:
Hello
I am trying to start perl script from PAR
script1.pl that runs without parameters and was converted to exe
script2.pl runs with parameters and should have the same environment
as script1.pl
I cannot chande or modify script2.pl so I need use
test.exe -l inside.pl outside.pl
and the output of test.exe is a dir list of c:\windows and c:\windows\system, so the
command interpreter is not the problem itself.
Is this anything like what you are trying to do? Are you trying to use pp -g on
script1.pl?
Alan Stewart
for you.
Alan Stewart
is forgiving.
Alan Stewart
On 5 Aug 2004 at 19:35, Alan Stewart wrote:
It's not PAR. It's the C binary frontend compiled by VC++ 7.0 that links to
MSVCR70.dll. Bill wants you to upgrade all your systems to .NET where it will be
available. Either use -l or put it in the same dir as the exe or use VC++ 6.0.
BTW
is
inheriting the file handles of the first. Beyond that I don't have a clue :(
Alan Stewart
message.
Anyway, you can't rely on the constant being implemented as a sub, and as Rob said, it
is not neccessary.
Alan Stewart
?
Sure.
Alan Stewart
On 28 Jul 2004 at 14:00, Alan Stewart wrote:
I probably shouldn't have said broken, but not classic. PodStrip.pm is looking
specifically for the POD commands listed in the perlpod doc. The commands =header
and
=usage are not defined there. I'll look closer at what PodStrip does.
Well
On 28 Jul 2004 at 17:41, Glenn Linderman wrote:
So thinking about this some more, I guess I don't understand why the
cache-gibberish gibberish is so much longer than the filename gibberish.
Well, long is better, less chance of a duplicate. The cache dir is created by the
binary frontend
to
recompile PAR to use it, snapshots and binaries become available again :(
Alan Stewart
and ran the exe or just
ran
wperl tk_stdio_demo.pl.
HTH
Alan Stewart
The following section of this message contains a file attachment
prepared for transmission using the Internet MIME message format.
If you are using Pegasus Mail, or any another MIME-compliant system,
you should be able to save
-threaded apps.
I will continue to look into this a bit later tonight.
Second caveat: I am only guessing.
Good luck :)
Alan Stewart
attachment par.dat to par.zip.
Alan Stewart
The following section of this message contains a file attachment
prepared for transmission using the Internet MIME message format.
If you are using Pegasus Mail, or any another MIME-compliant system,
you should be able to save it or view it from within
? I remember a discussion about how to re-instate the console a while ago.
Alan Stewart
with these patches, if a user is only going to run your app once, you
should get a slight increase in startup with pp -C since inc/ is not created at all.
Alan Stewart
The following section of this message contains a file attachment
prepared for transmission using the Internet MIME message format
the ASCII subset that just happens
to match utf8, or something.
Alan Stewart
extract a .par archive built from the same script (including base modules)
in under a second.
How does the first time startup compare to the speed if you set PAR_GLOBAL_CLEAN=1
before running the app, so it's not cached?
Alan Stewart
, version 1.0, so if
you'd like to improve it, feel free.
Autrijus, for the contrib directory, if I may...
Alan Stewart
The following section of this message contains a file attachment
prepared for transmission using the Internet MIME message format.
If you are using Pegasus Mail, or any another MIME
On 18 Jul 2004 at 21:37, Autrijus Tang wrote:
On Sun, 18 Jul 2004 17:43:45 -0700, Alan Stewart [EMAIL PROTECTED] wrote:
I do a lot of little Tk apps with PAR, and although disk space is cheap, I
sometimes
have to send these by very slow means. My parsimonious soul doesn't like to send
the parl.pl frontend in memory, but
that
shouldn't be very large.
Still digging
Alan Stewart
. Under a default C compile,
this means [^a-zA-Z0-9], so non-English letters become underscores also. This is to
ensure a valid path name. The path preceeding par-$USER is not constructed, it pre-
exists, so it has or doesn't have spaces as you wish.
Alan Stewart
a
bit cleaner. No traces of PAR left, if all PAR exe's are -C.
That's not possible if some PAR's are cached, so you may have empty par-$USER dirs
left laying around.
Alan Stewart
people :)
However, the purpose of Obfuscate and Bytecode is not to process pod. Size reduction
(if any) is an unplanned side effect.
upx (upx.sourceforge.net) will shrink the size of the exe, but won't help speed it up,
unless you are fetching the exe from slow media.
Alan Stewart
downloaded the SDK or the
additional include files, you hit some more missing stuff next (see my earlier post).
Alan Stewart
On 5 Jul 2004 at 10:47, Knut Virow wrote:
Alan Stewart wrote: (on 03.07.2004)
As mentioned elsewhere, you can download the precompiled packages from:
http://aut.dyndns.org/par/
and manually put it in the PAR-0.xx directory before making PAR.
But if you are Internet connected when you
of the binary is still automatic.
The readme doesn't really say that having a C compiler overrides having the pre-built.
We probably need an install query if both are present. Autrijus??
Alan Stewart
or
Windows native widget app.
Alan Stewart
Tk/DragDrop/Win32Drop.pm Tk/DragDrop/Win32Site.pm
Tk/DragDrop/XDNDDrop.pm Tk/DragDrop/XDNDSite.pm
) ],
at Module::ScanDeps.pm line 292.
See if that helps.
Alan Stewart
...
HTH,
Robert
There should be a new version of Module::ScanDeps that will eliminate the need for
this
extra use statement, coming real soon. Autrijus is on travel and p4.elixus.org has
been down, so I don't know when real soon is :(
Alan Stewart
\automated_pp_test.pl
at line 7563)
Autrijus has identified using -M to add an ordinary files as deprecated in favor of
-a. I would suggest removing these tests and just leaving the ones that use -M to add
modules and -a for ordinary files.
Alan Stewart
Packer.pm has a typo on line 872:
$alias = s{^[a-zA-Z]:}{} if $^O eq 'MSWin32';
should be:
$alias =~ s{^[a-zA-Z]:}{} if $^O eq 'MSWin32';
Alan Stewart
-o t9.exe t9.pl
The stat preceding -l _ wasn't an lstat at c:/ActivePerl/lib/File/Find.pm line 252.
Alan Stewart
);
Alan Stewart
both have for 5.8.3.
You may find that you have no problem running your application on a machine that
doesn't have perl installed (or at least not in c:\perl).
Or your problem may go away if you download the snapshot and compile yourself.
Alan Stewart
it break for you?
Alan Stewart
. This is on WinXP, but my limited testing suggests that it appears
on other versions as well.
Did the same with no fault here, build 809, XP, and the latest snap of PAR compiled
with VC 6. Are you self compiling PAR or using the binary download?
Alan Stewart
it. Is
it something that we should have concern
over?
Do you mean the signature test, or the first test of basic.t? I've never installed the
signature modules, so for my Win32, signature is skipped, and all basic.t passes.
Alan Stewart
::SHA1 installed?
Of course, if you just ignore this error, you won't know if you are using the one true
PAR, or some insidious variation ;) Most of the current snapshots don't include a
SIGNATURE file.
Alan Stewart
On 15 Apr 2004 at 9:10, Roderich Schupp wrote:
OTOH, static.c could possibly set LD_LIBRARY_PATH as long as that only affects the
environment for the PAR execution.
PAR does set LD_LIBRARY_PATH, the code is in myldr/mktmpdir.c.
You are right. In mktmpdir.c, there is code that prepends
into the ActivePerl html dir, but
PAR doesn't have them (yet).
I have no idea what could be different about the bribes compile. I am using VC 6.0 and
I think Autrijus is also.
Has anyone seen this problem with anything other than the bribes package??
Alan Stewart
On 14 Apr 2004 at 15:27, the.noonings wrote:
On SUN machines, LD_LIBRARY_PATH is a system wide dynamic variable that PAR
dare not change. I don't know about Linux except that on my current Linux
machine it does not exist. In any case, I don't think any environment
setting could help because
there.
OTOH, static.c could possibly set LD_LIBRARY_PATH as long as that only affects the
environment for the PAR execution.
Alan Stewart
.
and he patched it already. This is different from the extra long SHA1 name Rick is
seeing. In the patch, the Control-L becomes an underscore.
Alan Stewart
On 7 Apr 2004 at 22:41, Rick Fitzsimmons wrote:
Hi,
Been having problems since updating to 0.80. One user gets error message
with Windows 2000 [Version 5.00.2195] when running a pp'd executable,
but another user has no trouble at all. After many attempts, I've also
seen this happen
OK.
Alan Stewart
for you and -C wouldn't (they are
one and the same option). But be aware that previously, setting PAR_TEMP=xxx (or
setting PAR_GLOBAL_TEMP=xxx now) overrides all clean options.
Try the latest snap and see if it helps.
Alan Stewart
pp.
Does that seem possible to you, or am I out of my mind?
Not mutually exclusive, given the state of my mind :)
Alan Stewart
, 1);
return;
}
Alan Stewart
(as he's under RedHat).
OK. I assumed that it was a Windows OS, since he had an .exe file extension.
Alan Stewart
On 3 Mar 2004 at 14:07, Alan Stewart wrote:
Autrijus, I see the same fix in several places:
#if defined(__APPLE__) defined(__DYNAMIC__)
static char ** environ;
environ = *_NSGetEnviron();
#else
extern char ** environ;
#endif
I'm not a Mac user, so I can't check out the #ifdef values
On 3 Mar 2004 at 14:28, Alan Stewart wrote:
Here are the similar lines from the perl source:
#if defined(__APPLE__) defined(PERL_CORE)
# include crt_externs.h /* for the env array */
# define environ (*_NSGetEnviron())
#endif
which define environ rather than setting
%PAR::LibCache) {
print $_\t$PAR::LibCache{$_}\n;
}
print $0 done\n;
-
Alan Stewart
the pp'd script is called t2.pl.
Alan Stewart
\\ in your full path above vice \.
Alan Stewart
That was intentionally not done based on the assumption that PAR itself does not
create
any subdirs when using -C. All the extraction is flat.
I know it was discussed. Autrijus, what was the reasoning for that again?
Alan Stewart
changes, so they don't accumulate.
Alan Stewart
to see if I am still in the loop with the list. Could be
my
ISP :(
Alan Stewart
for the next couple weeks, so I won't be doing anything soon.
There is always PAR 0.80_01 :)
Alan Stewart
. If the temp dir name generated automatically by
PAR
is OK with you, then you don't need $ENV{PAR_GLOBAL_TEMP} either. If you do specify
PAR_GLOBAL_TEMP, that overides any -C or PAR_GLOBAL_CLEAN anyway.
Alan Stewart
days
ago,
deleting all PAR_xxx. With the patch I sent in, you won't have to do that to keep
PAR_TEMP from foo carrying over to bar and messing it up. Nor do you need to restore
it. It has already done it's work.
See my other reply for the remaining gotcha.
Alan Stewart
in progress and foo.exe isn't
creating it's own cache directory, so there are collisions when foo.exe unpacks. By
cleaning out the PAR_xx variables, I can get bar/foo to run with and without -C and -d.
On 16 Feb 2004 at 21:30, Alan Stewart wrote:
I think I see a clue. When I build bar and foo
and PAR_DEBUG getting to the second exe.
On 17 Feb 2004 at 0:27, Alan Stewart wrote:
I haven't figured out how to fix this the right way yet, but here is a work around
that
may work for you.
Put this:
for (keys %ENV) { delete $ENV{$_} if /^PAR_/ }
right before:
Win32::Process
On 18 Feb 2004 at 3:11, Autrijus Tang wrote:
On Tue, Feb 17, 2004 at 10:25:25AM -0800, Alan Stewart wrote:
The work-around I mentioned below is overkill and prevents having systems defaults
for
PAR_TEMP, PAR_CLEAN and PAR_DEBUG getting to the second exe.
Nice catch.
So all we have
On 16 Feb 2004 at 15:16, Autrijus Tang wrote:
On Sun, Feb 15, 2004 at 09:35:02PM -0800, Alan Stewart wrote:
On 16 Feb 2004 at 7:31, Autrijus Tang wrote:
http://aut.dyndns.org/dist/Win32-Exe-0.04.tar.gz
MD5 (Win32-Exe-0.04.tar.gz) = b2f60472ee77f746c8a5d17dacc23a4e
I can make
1 - 100 of 126 matches
Mail list logo
