At 11:40 AM +0200 6/2/04, Willem Grooters wrote: >Sorry, something went wrong and a reply was sent to the original sender >in stead of the list.
The Perl lists give you reply to sender by default; you need to explicitly choose reply to all to reply to the list. >So this is our communication. For completeness, I kept all of the >original answer. For efficiency, I've snipped quite a bit :-). > >>What you ask for is a real PERL compiler that creates VMS-compliant >>>objects, isn't it? >> >>Yes, or even simply a "builder" that could compile and link an >>entire set pf perl scripts into an image that one could invoke with >>RUN. Perl will never be a compiled language the way FORTRAN and COBOL are, though of course it compiles its scripts to bytecode before executing them. On the Perl to C translator, see: http://www.perldoc.com/perl5.8.4/pod/perlcompile.html I think what this gets you in that subset of cases for which it even works is a Perl op-tree implemented in C. In other words, you get a C program that executes the particular stream of Perl byte codes that make up your program. > >I guess what I'm saying here is that typically a Perl script >>pulls in many other perl modules and if compiling them separately into >>individual modules was too hard then for my purposes at this point >>just having an image alone would be nice. Loading a large number of modules can be a performance problem. Over the years we've occasionally discussed storing Perl modules in text libraries and using the librarian to fetch them; it should be much more efficient than rooting around in the file system. You'd still have all the image activations for the shareable images. > >My particular need arises >>from my recent work in Spamassassin. Think about the way it's used. >>It's invoked once for every single mail message coming into the system >>and each time it's run that means Perl is re-building (er, um >>compiling and linking or whatever the Perl builder does internally) >>the program before running it. >>That's a ton of wasted CPU time and unnecessary latency in mail > >proccessing and won't scale well. Indeed, but that's not the way most people use it on Unix. It can be embedded in a wide variety of mailers or run as a separate daemon. You'd have a Perl interpreter started and running, and you'd have Spamassassin compiled and running, sitting there waiting for mail messages to process. These things may not work out of the box on VMS, but that's a porting challenge. Karol, I seem to remember you had trouble some time back getting an embedded Perl to work, but I think that's really the right way to do this and worth revisiting. > >>Still, I do have some concerns but didn't reply yet (on- or off-list) >>on Craig's message. >>>Most important is there is the real danger(!) that Perl programs will >>>introduce even more Unix-like requirements like STREAM_LF files and >>>inter-process communication (the PIPEs). I agree that if there is some >>>form of communication between different systems, you'll have to use >>>some 'generic' format, but system-specific methods must be possible >>>when communication on one platform (MBX on VMS, for instance). >>> >>>It should be VERY clear - to ANY developer on this project - that VMS >>>is NOT another Unix. It can do some things the Unix way, but it has > >>quite some capabilities Unix can only deram about. USE THEM. Calm down, Willem. What the project needs is more developers able and willing to keep up the tradition of letting Perl be Perl, and use the C run-time, homegrown hacks, VMS system services, DCL, and anything else within reach to make that happen. What the project does NOT need is to have this list become yet another forum for OS wars. -- ________________________________________ Craig A. Berry mailto:[EMAIL PROTECTED] "... getting out of a sonnet is much more difficult than getting in." Brad Leithauser
