Re: Perl compiler?
On Mar 20, 2004, at 20:33, Chris Devers wrote: On Sat, 20 Mar 2004, Bohdan Peter Rekshynskyj wrote: Is there such an animal? And is it GNU-ed? Aside from /usr/bin/perl (or C:\perl\perl.exe)? There is (was? is, I suppose...) that could produce Windows .exe files out of win32 Perl scripts, but it doesn't have a very good reputation as far as I can tell. shudder For every other platform Perl runs on (everything?), /usr/bin/perl is pretty standard, and you're generally better off just distributing programs that way than trying to compile them to some kind of binary. Well, I want to distribute the programs to my clients - without source... If they can modify it - there's a concern of security - and never mind the ownership of code et cetera! Also, compiled versions run way faster (Would love to develop Perl/TK in Aqua using a compiler and distributing!) If you think about it, if you want binaries, you're going to have to recompile them for every platform you're interested in. The same ascii Just a Mac! Of course, that's the platform. Perl script will generally run without modification on OSX, Linux, Solaris, Irix, AIX, HP/UX, BeOS, SCO, etc. A binary, on the other hand, will have to be custom made for every one of those platforms, and often you'll need different versions of your program for different versions of the platform it is being ported to. Just a Mac! :-) For some reason, the Java people seem to think this kind of thing is a big deal, even though every *nix scripting language has been able to do this more or less forever... :) Chuckle! Well, many people think they were ingenious with coming up with JVM, but such young ones as I who started computing in the 1970's know that IBM first had (and still does have) a nice operating system called VM - it ran all their stuff - MVS, DOS/VSE, and VM on one mainframe... You could, and still can, if you're feeling kinky, run VM (Virtual Machine) under VM, under VM und so weiter et cetera ad nauseam amen! :-D It emulates the entire 360/370/Enterprise/waz architecture. Way kewl - puts JVM et cetera et alii to shame! We saw Apple do this amazingly well in the transition from Motorola's 680xx series to the PowerPc.. Why do you want a compiler, out of curiosity? What are you trying to do? Answered above. If you want to write something to share with other OSX users, you should NOPE! Security and commercial! generally be able to just use a regular script -- the only real issue to think about is being compatible with Perl 5.6 for pre-Panther users. Thanks for your feedback - appreciate it! BUT, I guess, there isn't any? Cheers, BPR -- Chris Devers - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Please take the time to preview my forthcoming book of essays! http://www.ZeusonaCork.com Join the blog too! Thank you! - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Re: Perl compiler?
On Mar 21, 2004, at 10:16 AM, Bohdan Peter Rekshynskyj wrote: On Mar 20, 2004, at 20:33, Chris Devers wrote: On Sat, 20 Mar 2004, Bohdan Peter Rekshynskyj wrote: Is there such an animal? And is it GNU-ed? Aside from /usr/bin/perl (or C:\perl\perl.exe)? There is (was? is, I suppose...) that could produce Windows .exe files out of win32 Perl scripts, but it doesn't have a very good reputation as far as I can tell. shudder Perl2Exe has a spotty reputation, but since it is a potential solution to your problem I would recommend you look at it and look at the actual criticisms so you understand what the concerns are. Despite the name it is really just a binary packaging tool, and can be used to deploy on various flavors of unix as well as Win32. http://www.indigostar.com/perl2exe.htm For every other platform Perl runs on (everything?), /usr/bin/perl is pretty standard, and you're generally better off just distributing programs that way than trying to compile them to some kind of binary. Well, I want to distribute the programs to my clients - without source... If they can modify it - there's a concern of security - and never mind the ownership of code et cetera! Also, compiled versions run way faster If your program is slow, you should work on optimizing it rather than hoping that a compiler will magically make it faster. (Would love to develop Perl/TK in Aqua using a compiler and distributing!) Dropscript + a source filter might make you feel better. It still would be trivial to get at your source using various tools, but the casual browser would see line noise and might be deterred. I would really recommend looking at PAR (the Perl Archive Toolkit). This can generate a packaged standalone executable, and can handle bundling modules as well (a big plus). It has an input filter to obscure your source code. I haven't tried it on OS X, IIRC it depends on DynaLoader, which had some issues on OS X last I checked (10.1, things may be better now), so YMMV. IMHO, the best reason to create a standalone executable is not to improve performance, or to protect source code, but to provide convenient packaging. But, as mentioned, PAR can use an input filter to obscure your code to make it much more complicated to alter your code. This is not going to stop the bad guys from getting at your code. See http://par.perl.org/?FAQ Can PAR completely hide my source code? Keep in mind that no matter what language you use a determined bad guy can decompile it. Randal Schwartz' advice in that FAQ about licensing is well worth consideration for whatever packaging scheme you decide on. trimmed
Re: Trying to understand signals and restartable system calls
On Mar 21, 2004, at 8:55 AM, Mark Alldritt wrote: [..] I take if from your responses that Perl doesn't automatically restart system calls after a signal is processed as Programming Perl and the Perl Cookbook suggest it does. I don't actually own the code that is doing the read, so its not easy for me to modify it. [..] Actually, not really. It is more a case of the version of Perl that was shipped with Mac OSX. I ran into that problem while demonstrating some code that formerly worked under perl 5.6, and will still work on verions of perl 5.8.X greater than the verision that apple shipped: http://www.wetware.com/drieux/pbl/Sys/gen_sym_big_dog.txt So the real question is 'how defensive' does one want to write their code when stepping into Signal Handling - and the issues with possible cross platform in compatability issues... ciao drieux ---
B/C - Re: Trying to understand signals and restartable system calls
On Mar 19, 2004, at 1:31 PM, Joel wrote:
I'll toss in my two cents here, since I've done something like this
before in a production-type environment.
IMHO, The best thing to do would be to have your signal handler set a
flag (in the manner described by drieux) and have your loop react to
that
flag when it changes. This is a slight difference from what drieux did.
[..]
$SIG{USR2} = sub { $sig_flag++};
[..]
You know, that's one of those 'religious' issues that
I still don't feel that I have a 'solid' answer on one
way or the other... I think as a general rule of thumb
I'd probably tilt more towards this strategy but...
ciao
drieux
