Release Notes
Version 1.1.6, September 20, 1999
For the latest information on PerlEx, please see:
Installation of PerlEx requires that you have administrator privileges on the computer which is hosting the target web server. We recommend that you apply NT Service Pack 4 to the target computer before installing PerlEx.
NOTE: We recommend stopping any web servers, ftp servers, and gopher services on the target computer before installing PerlEx.
Microsoft IIS 4.0 and Personal Web Server Installation:
We recommend that you turn off ISAPI caching before installing PerlEx
to ensure that the IIS Admin Service and its related services have
released DLLs prior to stopping the services.
Once PerlEx is installed, you may turn on ISAPI caching to enhance
performance.
To disable ISAPI caching:
We have noticed that certain third-party ftp servers may interfere with the IIS Admin Service's ability to shut down the IIS Admin Service or the World Wide Web Publishing Service properly. For best results, quit all Windows applications and stop any running web and ftp servers before installing PerlEx.
If you are using Microsoft IIS 4.0 or Microsoft Personal Web Server 4.0 as your web server, do not disable the IIS Admin Service before installing PerlEx, nor before uninstalling PerlEx.
Licensing: To operate properly, ActiveState PerlEx requires an Activation key. To get a key, go to the ActiveState PerlEx Web page at http://www.ActiveState.com/plex/default.htm and select either Buy it, to purchase a key, or Try it, to get a trial key. You can also select Product licensing from the ActiveState PerlEx program group in the Start menu, if you have already installed the software. Instructions on how to get your Activation Key will be emailed to you.
To successfully install and activate ActiveState PerlEx, you should:
net stop iisadmin /y
net start iisadmin net start w3svc
You can check to see if you have successfully installed PerlEx by running one of the sample scripts. To run the Sample scripts, select "PerlEx Sample Scripts" from the "ActiveState PerlEx" sub-menu of the "Start" menu. You can also check in the Registry key
[HKEY_LOCAL_MACHINE\SOFTWARE\ActiveState\License\PLEX11]to see if the Activation Key was installed.
If you have installed a beta version of ActiveState's Perl Development Kit and you have difficulties installing PerlEx, please install ActivePerl 519 (or a higher version) and then run the PerlEx installer. The latest version of ActivePerl is available at http://www.activestate.com/ActivePerl/
ActiveState PerlEx is a powerful addition to any web server running Perl scripts. To get the most out of it, we strongly recommend reading the online documentation and examining the Sample scripts.
FAQ
Q. PerlEx installed properly, but the licensing part failed, what should I do?
A. Select Product Licensing from the ActiveState PerlEx program group in the Start menu to start the licensing process again. From the product licensing screen, you can get trials or buy licenses for ActiveState PerlEx.
Q. Does PerlEx work well with all available CPAN modules?
A. Some CPAN extensions (Perl modules that contain XS code) are not thread-safe, and could cause problems running under heavy load in a PerlEx environment.
Any CPAN module written in pure Perl (i.e., that does not contain XS code) will work fine under PerlEx, as will the following extensions, which have been modified to make them thread-safe:
ActiveState is committed to ensuring that PerlEx works well with any extensions our customers rely on; when problems are brought to our attention, we will work with the extension authors to resolve the problem.
Q. Can I set up a persistent database connection with PerlEx?
A. Yes. See the section on BEGIN and END blocks in the documentation for more info.
Q. I've installed ActiveState PerlEx, but I can't get any of the samples
to work,
what should I do?
A. Try stopping and restarting your web server, to make sure that any configuration changes you have made are in effect.
Q. I edited some of my scripts and now they don't work, why?
A. If you change any of scripts that have require or use statements in them,you will either have to stop and restart the server or use the ReloadAll function for them to work properly. Please see the online documentation for more information on using the ReloadAll function. Also, there may be syntax errors in the script. You can look at the PerlEx error log, PerlExErr.log, for more information.
Q. Why are my HTTP headers being output twice?
A. The EnableCGIHeader registry entry determines whether HTTP headers are added or not, the default is to add HTTP headers. See the Registry entries section of the documentation for more information.
Q. My script worked with perl.exe, but doesn't work with PerlEx. Why?
A. See the "How to get my script to work with PerlEx" section of the documentation for some common problems. If that still doesn't work, you can try putting the script in the Noload registry entry, as some Perl programs are not compatibile with the PerlEx precompiler.
Q. My scripts that use CGI.pm don't seem to work. Why?
A. If you use the CGI.pm package in your scripts, we recommend using CGI.pm version 2.42 or higher.
There are some specific issues to deal with when using CGI.pm because global data is persistent across script invocations when running PerlEx. ActiveState is working with Lincoln Stein, the author of CGI.pm, in order to ensure future compatibility of PerlEx and CGI.pm.
You can avoid global data persistence problems by using the object interface.
New CGI objects are created like so:
my $cgi = CGI->new();
or this:
my $cgi = new CGI;
Thus, instead of this code:
use CGI qw/:standard/;
$aVariable = param('value');
you should create a CGI object:
use CGI qw/:standard/;
my $cgi = new CGI;
$aVariable = $cgi->param('value');
Do not create more than one CGI object in your scripts because when
doing a POST, after the first CGI object is created, subsequently
created CGI objects will not contain the posted data.
When using the function oriented interface to CGI.pm, you should call the following function before your script exits:
CGI::initialize_globals();
This will make sure that CGI.pm initializes its internal global
variables and handles future invocations of your script correctly.
This function must be called regardless of the path of execution in
your script, otherwise your script will work against the data from
the previous invocation of the script.
Currently there is no work around for this, so you should follow the guidelines above.
Q. I'm running PerlEx and it is really slow the first time, why?
A. The first time PerlEx runs one of your scripts, it will always be slow, as it is precompiling them, but every time you run them after that, you should experience a noticeable increase in speed. Also, if you have a script entered in the NoLoad registry entry, it will not run any faster.
Q. Are there any Unix versions of PerlEx?
A. There are currently no PerlEx Unix versions available.
Q. How can I check if PerlEx is running from within a script?
A. You can check if PerlEx is running form within a script by checking the following:
if ($ENV{'GATEWAY_INTERFACE'} eq "CGI-PerlEx") ...
Q. Why don't my scripts with __END__ or __DATA__ work?
A. PerlEx does not work with scripts which use __END__, nor does PerlEx work with scripts which use __DATA__. You have several choices of how to handles such scripts. You may either:
[HKEY_LOCAL_MACHINE\SOFTWARE\ActiveState\PerlEx\1.1\NoLoad]
Q. I'm running Netscape Enterprise v3.5.1 and I'm getting the error: "Could not find ns-httpd20.dll", what should I do?
A. This is a known problem with Netscape Enterprise Server v3.5.1. Netscape has posted a patch on their Web site that includes the updated ns-httpd20.dll.
Q. How do I optimize print() performance?
My script makes many calls to print, and PerlEx does not seem to be a lot faster than regular Perl CGI when running it. How do I optimize print() performance?
A. Outputting data is a relatively expensive operation, whether it is a regular Perl CGI script, or one running under PerlEx. While most scripts will not be affected to any significant degree by this fact, any Perl script that performs many calls to print will see an increase in speed by gathering as much data as possible before calling print. Perl makes this easy by providing the '.=' operator.
For example, if the following code:
$data = "Hello"; print $data; $data = " world"; print $data; $data = "\n"; print $data;
$data = "Hello"; $data .= " world"; $data .= "\n"; print $data;
Q. Why isn't my require'd file working properly?
I have a common file, C.plex, that is included (via require statement) by two other scripts, A.plex and B.plex. The first time either A.plex or B.plex is run, the script works, but then the other script won't run. What's wrong?
A. The problem here is a namespace issue. Once script C.plex is loaded by either script A.plex or by script B.plex, its data and subroutines become part of the calling script's namespace, if C.plex does not contain a namespace declaration. The solution is to declare a namespace in C.plex with a package declaration. C.plex will look like this:
package C;
sub foo
{
[...your code here...]
}
1;
A.plex and B.plex need to access subroutines in package C by using the following syntax:
&C::foo([your args here]);
In general, it is good Perl programming practice to explicitly declare a namespace in any file that will be loaded by other scripts.
We've included a tool called ActiveAdvicethat can help identify potential problems like this. You can invoke ActiveAdvice like this:
C:\>advice -MPerlEx c.pl
C.pl:1: Warning: No 'package' statement used to define namespace.
Q. Why does my Server Side Include produce HTTP headers?
A.
PerlEx does not distinguish between files which are served up in their entirety and files which are included. If you have EnableCGIHeader set to 1 in the registry, PerlEx will emit HTTP headers for each document which it serves.
If you use Server Side Includes in the documents that you are serving with PerlEx, set EnableCGIHeader to 0 in the registry, and provide your own HTTP headers for your documents.
Q. Why do I have unwanted data persistence problems when using certain modules?
A.Some modules on CPAN use global variables which will persist when using PerlEx. If you discover that this is the case, and if the module does not have a way for you to initialize your data, you may wish to add the scripts which use these modules to the Noload registry entry.
Q. Why are HTTP headers appearing in the browser body?
A.If you see HTTP header information appearing in the body of the client browser, you should change EnableCGIHeader registry entry to 0. You will then be responsible for outputting all HTTP headers.
The most up to date list of FAQs for ActiveState PerlEx can be found at: http://www.ActiveState.com/plex/docs/faq.htm
There are two methods for reporting bugs or problems:
The preferred method for reporting bugs or problems with PerlEx is to fill in the Online Bug Report. The form is located at http://www.activestate.com/cgibin/tiwi.pl.
Otherwise, Send email to support@ActiveState.com making sure to include a complete, step by step description of the problem, including the machine and operating system type.
We're interested in what you have to say! Do you have something that used to work that just doesn't work anymore? Any feature suggestions? Let us know! We can't guarantee that all suggestions will be implemented in future releases, but we'll do our best!
Thanks!
New Features, Bug Fixes and Changes from Release 1.1.5
New Features, Bug Fixes and Changes from Release 1.1.4
New Features, Bug Fixes and Changes from Release 1.1
New Features, Bug Fixes and Changes from Release 1.0
use CGI;
$my $cgiobj = new CGI;
my $value = $cgiobj->param('value');
print $cgiobj->header [...your code here...]
rather than:
use CGI qw/:standard/;
$value = param('value');
print header [...your code here...]
Alternatively, calling
CGI::initialize_globals();before your script exits will also work around the problem.
local $? = 0;