Hi Claudio,
as a Windows user, I can't help with your Apple problem, but...
> By the way, why is the application trying to call something in
> "Users/we/perl5/perlbrew" which is a path in the machine where I
> compiled the application?
this is likely a problem of the Perl distribution you are
Roderich Schupp wrote:
[...]
> The Windows standards suggest to make exectuables write protected.
>
> Bullshit advice. If the files are owned by the user, the malware can
> unprotect them.
with the correct ACL, a restricted user cannot modify the files
unnoticed (needs at least to confirm
Hi All,
how can I run a program directly from the *unpacked* file tree?
I just want to use PAR to bundle all dependencies to get a "portable"
Perl based Windows application, with dedicated unpacking instead of the
automatic "runtime" unpacking.
Thanks in advance,
Oliver
Hi all,
when I use PAR_GLOBAL_TEMP, new versions of the application don't
overwrite existing libraries.
For example, running a new version of ExifTool (for Windows) will fail
then because the libraries of the old version are kept.
I need then to delete the contents of the directory specified
Hi Roderich,
first, I would like to thank you for maintaining PAR!
[...]
I just want to use PAR to bundle all dependencies to get a "portable"
Perl based Windows application, with dedicated unpacking instead of the
automatic "runtime" unpacking.
Can you elaborate on what you are
Hi,
PatchContent.pm has an entry for XSLoader.pm:
goto \::bootstrap_inherit unless $module and defined
_load_file;' => 'goto \::bootstrap_inherit;
This means, the "unless $module and defined _load_file" condition is
stripped in line 34 of XSLoader.pm with the effect that "goto
Hi Johan,
I've uploaded a perl GUI program:
https://www.squirrel.nl/pub/xfer/uploads/3C6TeP1OMnL8q7ciPFkyneaA.exe
this is made with 64 bit Perl. My launcher currently supports only 32
bit Perl because the 64 bit version was even slower running ExifTool.
It is not exactly a trivial program,
Hi Johan,
I have an application that comes in two forms: as a command line tool, and
as a GUI tool. I want to package these in a single binary, using pp
which benefit do you expect from packing:
Avoiding "installation", reducing size, or something else?
multi-script feature. So far, so
Hi Johan,
I've uploaded a perl GUI program:
https://www.squirrel.nl/pub/xfer/uploads/3C6TeP1OMnL8q7ciPFkyneaA.exe
I managed to run this application from the pp created archive contents
after applying a few modifications you might want to revise:
In wxchordpro.pl, I replaced lines 10..12 with
Hi Johan,
which benefit do you expect from packing:
Avoiding "installation", reducing size, or something else?
Mostly avoiding complexity and unnecessary overhead. The cli version is
fully contained in the gui version.
Which kind of complexity and overhead do you mean?
What would be the
Hi Johan,
What would be the drawback of using a (subset of a) portable Perl
distribution together with your Perl code, IOW just a bunch of files,
and run it directly?
It seems non-trivial to put the bunch of files together, distribute
par is good in doing this selection.
them and have the
[...]
If you want to use my wrapper with 64 Bit Perl, you need to compile it
yourself. If you switch to 32 bit Perl, I can support you with special
it was not so difficult as I thought initially so I compiled a 64 bit
wrapper including the icon:
Hi Johan,
I, too, have been using pp + innosetup for many years, so that is not the
problem. BTW my apps are Perl/Wx based.
Seemingly I'm not recognizing the advantage in using pp *in addition* to
InnoSetup.
What is the point to use InnoSetup just to transport *one single exe*?
If you work
Hi Johan,
I unpacked the zip and tried to run.
First problem: the .exe files are not executable:
Are you running under real Windows or Wine? This doesn't sound like a
Windows issue.
[...]
While looking at the (modified) source: what is the purpose of
unshift @INC,
Ralf.Neubauer wrote:
Is there a better way?
did you consider to use pp to crete the set of required files, but *not*
at runtime?
You can then put all the required files to a safe directory, optionally
even write protected for ordinary users to avoid unexpected modification.
I made a simple
Neubauer, Ralf wrote:
[PAR_TEMP]
What is your concept for getting rid of old PAR_TEMP locations once you get (or
create) an updated version of the application or just stop using it?
My simple concept is not to hide the unpacking but tell the users the truth:
There is a bunch of files
Wed Jan 13 06:02:22 2021: Request 134044 was acted upon.
Transaction: Ticket created by list...@gmx.net
Queue: PAR-Packer
Subject: You are flooding par@perl.org with useless messages (EOM)
Broken in: (no value)
Severity: (no value)
Owner: Nobody
Requestors:
17 matches
Mail list logo
