SPUG: Re: Re: Perl Compiler.

[John Cokos, CEO, iWeb, Inc.]

Our need for compiled code comes from our desire to accomplish
2 specific tasks, not to handle machines without perl:

It's important to note that this is for CGI Programs (web apps)
and that 99% of the intended audience are on a unix system.

    1. Speed.
        I have a feeling that loading a pre-compiled shared object
        will be a hell of a lot faster than going through the normal
        load/compile/execute cycle.

    2. Code Security.
        As a commercial CGI Shop, we're quite interested in making
        the code, and our programs somewhat safe.  We estimate
        that there are at least as many unlicensed (stolen) copies
        of the program out there right now, and another 2 or 3 guys
        are in the process of reverse engineering the existing source
        to begin selling pirated copies on their own.  There's no
        way to stop or control this in the perl world, UNLESS you
        can find a way to compile it down to machine code, and put
        some hooks in there to disable the program unless it's properly
        licensed.  This isn't foolproof, but it should knock out most
        of the idiots.

That's the rationale behind my needs for the compiler.   I need
to do some digging into the B:: stuff, I suppose.

John

========================================
  John Cokos, President / CEO: iWeb Inc.
  http://www.iwebsys.com
  jcokos at ccs.net
========================================
----- Original Message ----- 
From: "Creede Lambard" <creede at rrauto.com>
To: <spug-list at pm.org>
Sent: Thursday, March 08, 2001 4:27 PM
Subject: SPUG: Re: Perl Compiler.


> Lately I've been using ActiveState's perlapp, which ships with the Perl
> Development Kit (PDK) 2.0 for you-should-pardon-the-expression Win32. It's
> not actually a compiler, but for Win32 it does a similar function in that it
> packages up your Perl app in an executable so you can deliver it to others
> without them having to install Perl on their machine. Why anyone would NOT
> want to install Perl on their machine is beyond me, but I've heard there are
> people who don't even have a computer, much less Perl, so I just sort of
> shrug my shoulders and assume it takes all kinds.
> 
> An-nee-way . . .
> 
> perlapp works quite well but has three minor drawbacks I've encountered so
> far:
> 
> 1. It requires Windows NT to create apps (but once they're created they
> should run on any flavor of Win32). Presumably 2000 will work as well. Some
> will argue that the fact that it requires any form of Windows is a major
> drawback, but hey.
> 
> 2. It costs $120, but for that you also get some other neat stuff like a
> visual debugger, a COM object that exposes a Perl interpreter (so you can
> run Perl apps inside of
> VB/VC/Delphi/VBScript/anyothercontainerthatunderstandsCOMobjects), and
> extensions that will turn your Perl app into a Win32 service or an ActiveX
> DLL, if that happens to be your particular kinky inclination, not of course
> that there's anything wrong with that. (If you spend lots of time on Windows
> I actually think the $120 is quite a bargain, especially if your company
> will pay for it.)
> 
> 3. Occasionally it's not exactly forthright about what needs to go into a
> standalone application. Consider this little script:
> 
>     #!/usr/bin/perl
> 
>     use LWP::UserAgent;
>     $ua = new LWP::UserAgent;
>     $ua->timeout(20);
> 
>     $rq = new HTTP::Request("GET","http://www.slashdot.org");   # So what if
> resistance is futile?
>     $rc = $ua->request($rq);
>     print "Slashdot is up!\n" if ($rc->code =~ /^2/);
> 
> If you run this program at a command prompt you will (assuming Slashdot IS
> up) see the response, "Slashdot is up." However, if you create a perlapp
> from this program with the command
> 
>     perlapp -f -c script.pl
> 
> and run it, you get this error or something like it:
> 
>     Can't locate URI/_foreign.pm in @INC (@INC contains: C:\TEMP\35300000\
> .) at URI.pm line 54.
> 
> Huh? Where'd URI/_foreign.pm come from? It turns out it's called by
> HTTP::Request, which is called by LWP::UserAgent. About an hour of digging
> and I finally got the program to run by adding in three modules by hand:
> 
>     perlapp -f -c -add=URI::_foreign;LWP::Protocol::http;URI::http script.pl
> 
> Just dropping them into a use line in the script didn't work -- the "-add"
> line has to be there.
> 
> I know this is slightly off the topic of compiling Perl but I thought I'd
> mention it since it serves a similar purpose and I can actually get it to
> work.
> 
> Cheers,
> -- Creede
> 
> Creede Lambard      | Never rush a miracle man.
> Senior Developer    | You get rotten miracles.
> Reynolds & Reynolds |
> creede at rrauto.com   | - Miracle Max,
>                     |    The Princess Bride
> 
> 
> 
>  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>      POST TO: spug-list at pm.org       PROBLEMS: owner-spug-list at pm.org
>       Subscriptions; Email to majordomo at pm.org:  ACTION  LIST  EMAIL
>   Replace ACTION by subscribe or unsubscribe, EMAIL by your Email-address
>  For daily traffic, use spug-list for LIST ;  for weekly, spug-list-digest
>   Seattle Perl Users Group (SPUG) Home Page: http://www.halcyon.com/spug/
> 
> 


 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
     POST TO: spug-list at pm.org       PROBLEMS: owner-spug-list at pm.org
      Subscriptions; Email to majordomo at pm.org:  ACTION  LIST  EMAIL
  Replace ACTION by subscribe or unsubscribe, EMAIL by your Email-address
 For daily traffic, use spug-list for LIST ;  for weekly, spug-list-digest
  Seattle Perl Users Group (SPUG) Home Page: http://www.halcyon.com/spug/