Re: PerlRun problem: can't find method "uri"?
On Tuesday 30 April 2002 03:44 pm, you wrote: > You better fix these errors, and keep 'use strict' in place. Then > PerlRun should work without any problems in most cases. If after fixing > those problems you still have problems, come back with your relevant > questions again. > It's a good idea to have your code running under 'use strict' no matter > if you use mod_perl or not. This will save you a lot of grief in a long > run. --- I agree with Stas that if you fix the problems with your script running under "strict" this will most likely go away. --- I see, thank you for the suggestion. There are so many error in the script, usually related with global variable. I change/add this in the script. global variable: use var qw($myvar $in); local variable: my $myvar; I still don't know how to change this variable: local($long, $lat, $level); [error] PerlRun: 'Global symbol "$long" requires explicit package name at /home/httpd/... > It depends on your definition of "easier". > > Easier==sloppier: better stay away from mod_perl. > Easier==more flexible: go with mod_perl. > > As for the speed, I doubt you will find something *significantly* faster > than mod_perl. Assuming that you learn how to get the most our of mod_perl. --- It will be much faster to fix your CGI scripts so they run under mod_perl than to re-write them in PHP or JSP. --- I see. Well, we will try to porting 1 big script to see the speed different. Any help would be great > [p.s. please make sure you reply back to the list!] Ok :) Best Regards, Ricky
Re: [Fwd: Re: Cheap and unique]
In my post I've missed the 'd' token in "%05d"
Here are a few possible solutions that will do all the work for you
Apache/UUID.pm
--
package Apache::UUID;
use strict;
my($base, $seq);
die "Cannot push handlers" unless Apache->can('push_handlers');
init();
sub init {
Apache->push_handlers(
PerlChildInitHandler => sub {
$seq = 0;
$base = $^T . sprintf("%05d", $$);
1;
});
}
sub id { $base . $seq++; }
#sub format { ... }
1;
__END__
startup.pl
--
use Apache::UUID; # must be loaded at the startup!
test.pl
use Apache::UUID;
print "Content-type: text/plain\n\n";
print Apache::UUID::id();
Since I've used $^T token, the module must be loaded at the startup, or
someone may modify $^T. If you use time(), you don't need the child init
handler (but you pay the overhead). and can simply have:
package Apache::UUID;
use strict;
my($base, $seq);
sub id {
$base ||= time . sprintf("%05d", $$);
$base . $seq++;
}
1;
the nice thing about the childinit handler is that at run time you just
need to "$base . $seq++;". but probably this second version is just fine.
also you probably want to add a format() function so you get the ids of
the same width.
another improvement is to use pack(), which will handle sprintf for you
and will create a number which is more compact and always of the same width:
package Apache::UUID;
use strict;
my $seq;
sub id { unpack "H*", pack "Nnn", time, $$, $seq++;}
1;
Another problem that you may need to tackle is predictability... but
that's a different story.
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache 2.0 worker MPM
On Wed, 1 May 2002, Stas Bekman wrote: > No, it's due to the fact that Apache 2.0 wasn't released yet (meaning > that there are still API changes) and not everything has been > implemented in mod_perl 2.0. If you want to see what works look at the > test suite under t/ in the source distro. umm, no. support for threaded mpms is alpha because of exactly what patrick suggests, ithreads is not quite stable yet. ithreads in 5.8.0-tobe will be much better, but still has yet to be proven in a production environment with apache/modperl. support for prefork is considered beta simply because ithreads (multiple interpreters in the same process) are not used. the label of alpha/beta in the README has nothing to do with apache changing apis or what features have not been implemented in modperl-2.0.
Re: [Fwd: Re: Cheap and unique]
Michael Robinton wrote:
>>>I'm just curious - what's wrong with the function you're already using?
>>
>>Mod_Perl hangs on to it's PID, so it's no longer unique. (I _believe_)
>
>
>> TIMESTAMP . $$ . $GLOBAL++
Do not use concat, but sprintf 0 padding. Here is an example that can
happen easily which produces two identical ids in two different procs:
P TIMESTAMP $$ $GLOB CONCAT SPRINTF
A 1020227781 753 3 10202277817533 1020227781007533
B 1020227781 7533 10202277817533 10202277810007533
As you can see if you don't pad $$ with 0 to the max proc's len (on some
machines 63999) you can get two identical UUIDs in CONCAT column above.
The same can happen with the edge of timestamp when its first digit
switches from 9 -> 10, but then this number is so big, this is most
likely won't be a problem.
So a much safer solution would be :
$uuid = time . sprintf("%05", $$) . $GLOBAL++;
s/05/06/ or other if your system's process ID can be bigger than 5 digits.
if you don't modify $^T and you don't reuse the timestamp set for you in
$r, this will save you a few more millisecs:
$uuid = $^T . sprintf("%05", $$) . $GLOBAL++;
Since $^T . sprintf("%05", $$) is unique across processes. It's not
possible to create two processes with the same $$, at the same time.
$^T is the time the Perl interpreter has been started, unless it was
modified later.
You can also move all this "work" in the ChildCleanup Handler, so during
the request time, you use a value that has been already precalculated
for the current request at the end of the previous one. (just make sure
to initialize it during the ChildInit Handler for the first request).
p.s. this concept works on Unix for sure, it's possible that on some OSs
it won't work.
p.p.s. in mod_perl 2.0 we have APR::UUID that does this work for you.
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache 2.0 worker MPM
Patrick Mackinlay wrote: > Hello, > > I am looking into using mod_perl with Apache 2 and the worker MPM, I was > wondering what the status is of mod_perl for this setup. I noticed that > in the docs it says it is in the alpha stage, is this due to perls > ithreads not being quite ready? No, it's due to the fact that Apache 2.0 wasn't released yet (meaning that there are still API changes) and not everything has been implemented in mod_perl 2.0. If you want to see what works look at the test suite under t/ in the source distro. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
[ANNOUNCE] Apache::ASP 2.33 released
Hey,
Apache::ASP 2.33 is released, which you can find in your local CPAN, or
http://www.perl.com/CPAN-local/modules/by-module/Apache/
Below are the changes for 2.33 & 2.31 since I never officially
announced 2.31. This is a big release which has some bug fixes,
lots of new test cases to verify the API, and some significant changes
to code structure and the asp-perl CGI/command line processor.
For more information on Apache::ASP, please see
http://www.apache-asp.org
Thanks,
Josh
_
Joshua Chamas Chamas Enterprises Inc.
NodeWorks Founder Huntington Beach, CA USA
http://www.nodeworks.com1-714-625-4051
$MODULE=Apache::ASP; $VERSION = 2.33; $DATE="04/29/2002"
- fixed up t/server_mail.t test to skip if a sendmail server
is not available on localhost. We only want the test to run
if there is a server to test against.
+ removed cgi/asp script, just a symlink now to the ./asp-perl script
which in this way deprecates it. I had it hard linked, but the
distribution did not untar very well on win32 platform.
+ Reordered the modules in Bundle::Apache::ASP for a cleaner install.
- Fixed bug where XMLSubs where removing tag
when it was needed in XSLT mode.
+ $Server->Mail({ CC => '...', BCC => '...' }), now works to send
CC & BCC headers/recipients.
+ Removed $Apache::ASP::Register definition which defined the current
executing Apache::ASP object. Only one part of the application was
using it, and this has been fixed. This would have been an unsafe
use of globals for a threaded environment.
+ Decreased latency when doing Application_OnStart, used to sleep(1)
for CleanupMaster sync, but this is not necessary for Application_OnStart
scenario
+ Restructure code / core templates for MailErrorsTo funcationality.
Wrote test mail_error.t to cover this. $ENV{REMOTE_USER} will now be displayed
in the MailErrorsTo message when defined from 401 basic auth.
+ $Server->RegisterCleanup should be thread safe now, as it no longer relies
on access to @Apache::ASP::Cleanup for storing the CODE ref stack.
+ test t/inode_names.t for InodeNames and other file tests covering case
of long file names.
- Fixed long file name sub identifier bug. Added test t/long_names.t.
+ CacheDir may now be set independently of StateDir. It used to default
to StateDir if it was set.
++ Decomposition of modules like Apache::ASP::Session & Apache::ASP::Application
out of ASP.pm file. This should make the source more developer friendly.
This selective code compilation also speeds up CGI requests that do not
need to load unneeded modules like Apache::ASP::Session, by about 50%,
so where CGI mode ran at about 2.1 hits/sec before, now for
light requests that do not load $Session & $Application, requests
run at 3.4 hits/sec, this is on a dual PIII-450 linux 2.4.x
- Caching like for XSLTCache now works in CGI mode.
This was a bug that it did not before.
+ $Server->File() API added, acts as a wrapper around Apache->request->filename
Added test in t/server.t
++ *** EXPERIMENTAL / ALPHA FEATURE NOTE BEGIN ***
New $PERLLIB/Apache/ASP/Share/ directory created to
hold system & user contributed components, which will be found
on the $Server->MapInclude() path, which helps $Response->Include
search '.',Global,IncludesDir, and now Apache::ASP::Share for
includes to load at runtime.
The syntax for loading a shared include is to prefix the file
name with Share:: as in:
$Response->TrapInclude('Share::CORE/MailError.inc');
New test to cover this at t/share.t
This feature is experimental. The naming convention may change
and the feature may disappear altogether, so only use if you
are interesting in experimenting with this feature & will
provide feedback about how it works.
*** EXPERIMENTAL / ALPHA FEATURE NOTE END ***
+ asp-perl script now uses ./asp.conf instead of ./asp.config
for runtime configuration via %Config defined there. Update docs
for running in standalone CGI mode
+ Make use of MANFEST.SKIP to not publish the dev/* files anymore.
- Script_OnEnd guaranteed to run after $Response->End, but
it will not run if there was an error earlier in the request.
+ lots of new test cases covering behaviour of $Response->End
and $Response->Redirect under various conditions like XMLSubs
and SoftRedirect and global.asa Script_OnStart
+ asp-perl will be installed into the bin executables when
Apache::ASP is installed. asp-perl is the command line version
of Apache::ASP that can also be used to run script in CGI mode.
Test case covering asp-perl functionality.
+ asp CGI/command line script now called asp-perl. I picked this
name because Apache::ASP often has the name asp-perl in distributions
of the module.
+ Apache::ASP::CGI::Test class now subclass of Apache::ASP::CGI. To facilitate
thi
Re: [Fwd: Re: Cheap and unique]
> >I'm just curious - what's wrong with the function you're already using? > > Mod_Perl hangs on to it's PID, so it's no longer unique. (I _believe_) >TIMESTAMP . $$ . $GLOBAL++ I use the above. If you create a global for the child process then that is adequate since the PID belongs to the child and will be unique at least for a second until the next time tick -- it's not plausible to create 65k children in one second. If you need the variable global across multiple servers then include a unique part of the host address as part of the variable in addition to the time stamp. Michael
Re: Client capabilities (and JavaScript)
Hi, With minimal JavaScript code you could identify the browser's capabilities. Here is how you might approach the task. If the browser is Lynx then send text only version otherwise send JavaScript browser "sniffer". The JavaScript sniffer can check for CSS, DHTML, DOM, plugins, etc... then redirect back to the server for the correct implementation. If you don't mind the redirection (in JavaScript of course) then you're all set. Redirection may not seem attractive but consider that JavaScript runs within the client (read: browser) right so you got to get the information back some how. Server side browser sniffing might be implemented through a database of browser supported features and user-agent strings. Just thought you might want to the idea. Good luck. : ) M - Original Message - From: "Per Einar Ellefsen" <[EMAIL PROTECTED]> To: "Joel Palmius" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Tuesday, April 30, 2002 4:45 PM Subject: Re: Client capabilities > At 13:12 30.04.2002, Joel Palmius wrote: > >Is there a mod_perl API (or some other standard way) to determine what a > >client web browser is capable of displaying? (images, tables, plugins...) > > > >I am developing a web questionnaire system in mod_perl (1.26) and I'm > >thinking about maybe dividing the display code into different levels > >depending on what the client can handle (no graphics no css for lynx-like > >browsers, stylesheets and images for most browsers, and plugin extensions > >for more advanced browsers). > > The easiest is probably to ask the user. Tackling this in programming code > will probably fail as you have a too wide array of different user agents, > which each have their own options enabled/disabled. If the user won't > understand those questions (that might be normal), well, try to make > something that works for everyone. For example, you talk about CSS, but if > used correctly, text-based users will be able to use a page that has CSS > even if they don't have support for it. In the end, nobody really cares > about all the extra "stuff", and the way that works for everyone will > probably be the best (of course, don't be too conservative either; anyone > using lynx for example will know its limitations). > > > -- > Per Einar Ellefsen > [EMAIL PROTECTED] > > >
RE: XML::LibXSLT / Apache / MOD_Perl Segfaults
Yes, I have done that as well. On Tue, 30 Apr 2002, Clayton Cottingham wrote: > Have you compiled apache with noexpat in the apache? > > -- > Clayton Cottingham > Air Games Wireless Inc. > Suite 204, 309 W. Cordova St. > Vancouver BC V6B 1E5 Canada > Tel: +1.604.408.2228 > Cel: +1.604.720.3510 > Fax: +1.604.408.2649 > Email: [EMAIL PROTECTED] > Web: www.airg.com > > > -Original Message- > From: D. Hageman [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, April 30, 2002 2:56 PM > To: Matt Sergeant > Cc: D. Hageman; [EMAIL PROTECTED] > Subject: Re: XML::LibXSLT / Apache / MOD_Perl Segfaults > > > I should note then that it will also segfault if I don't attempt to > preload it and just 'use' it in a module. The only difference is that > the > backtrace is significantly longer. :-) > > On Tue, 30 Apr 2002, Matt Sergeant wrote: > > > D. Hageman wrote: > > > I am having some issues utilizing XML::LibXSLT into a mod_perl > application > > > I am working on. The problem displays itself as a segfault on > server > > > startup. The setup I have is a standard RedHat 7.2 box with the > following > > > updated packages: > > > > > > apache 1.3.23 > > > mod_perl 1.26 > > > libxml2 2.4.21 > > > libxslt 1.0.17 > > > perl 5.6.1 > > > > > > The CPAN modules are all the latest as of today. The test is just a > > > > simple perl section with: > > > > > > > > > use XML::LibXSLT; > > > > > > > > > It's probably something to do with the BOOT section in LibXSLT. Just > > don't load it that way - you're not winning much by trying to make it > > shared anyway (because it's mostly XS/C code, rather than perl code). > > > > Matt. > > > > > > > > -- //\\ || D. Hageman<[EMAIL PROTECTED]> || \\//
RE: XML::LibXSLT / Apache / MOD_Perl Segfaults
Have you compiled apache with noexpat in the apache? -- Clayton Cottingham Air Games Wireless Inc. Suite 204, 309 W. Cordova St. Vancouver BC V6B 1E5 Canada Tel: +1.604.408.2228 Cel: +1.604.720.3510 Fax: +1.604.408.2649 Email: [EMAIL PROTECTED] Web: www.airg.com -Original Message- From: D. Hageman [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 30, 2002 2:56 PM To: Matt Sergeant Cc: D. Hageman; [EMAIL PROTECTED] Subject: Re: XML::LibXSLT / Apache / MOD_Perl Segfaults I should note then that it will also segfault if I don't attempt to preload it and just 'use' it in a module. The only difference is that the backtrace is significantly longer. :-) On Tue, 30 Apr 2002, Matt Sergeant wrote: > D. Hageman wrote: > > I am having some issues utilizing XML::LibXSLT into a mod_perl application > > I am working on. The problem displays itself as a segfault on server > > startup. The setup I have is a standard RedHat 7.2 box with the following > > updated packages: > > > > apache 1.3.23 > > mod_perl 1.26 > > libxml2 2.4.21 > > libxslt 1.0.17 > > perl 5.6.1 > > > > The CPAN modules are all the latest as of today. The test is just a > > simple perl section with: > > > > > > use XML::LibXSLT; > > > > > It's probably something to do with the BOOT section in LibXSLT. Just > don't load it that way - you're not winning much by trying to make it > shared anyway (because it's mostly XS/C code, rather than perl code). > > Matt. > > > -- //\\ || D. Hageman<[EMAIL PROTECTED]> || \\//
Is ActivePerl required with a mod_perl-Apache installation
Is there anyway to build mod_perl and Apache so that my target installation does not require ActivePerl on WinNT platforms. I'm currently doing my development on a WinNT that has ActivePerl installed and in my PATH. This is where I'm developing perl modules. When I move my installation over to a test WinNT machine without ActivePerl I get an error when Apache hits the LoadModule line for mod_perl.so. -pete
Re: [Fwd: Re: Cheap and unique]
> > >>Mod_Perl hangs on to it's PID, so it's no longer unique. (I _believe_ >> > >But the timestamp will make it unique - as long as you're not serving >several requests per second. > > I'm building the system so I can be confident up to thousands of requests/second. Looks like unique_id_module is good for around 65K requests, which is fine ;) A global counter hanging around is a good solution, but not perfect if we deploy on multiple servers. It appears the mod_unique module uses timestamp, a PID, a counter and the IP address, which is fine. David
Re: [Fwd: Re: Cheap and unique]
David Jacobs wrote: > > > > >I'm just curious - what's wrong with the function you're already using? > > > >Steve > > > > Mod_Perl hangs on to it's PID, so it's no longer unique. (I _believe_) But the timestamp will make it unique - as long as you're not serving several requests per second. If you are, you could use a counter as well as, or in place of, the timestamp. All I'm saying is that CGI by itself doesn't guarantee a unique PID - your CGI's original author probably knew that, and incorporated the timestamp to guarantee uniqueness. > mod_unique_id looks like a good solution, pending performance. Yeah, agreed. > Thanks for your help so far, everyone! > > David -- Steve Piner Web Applications Developer Marketview Limited http://www.marketview.co.nz
Re: XML::LibXSLT / Apache / MOD_Perl Segfaults
I should note then that it will also segfault if I don't attempt to preload it and just 'use' it in a module. The only difference is that the backtrace is significantly longer. :-) On Tue, 30 Apr 2002, Matt Sergeant wrote: > D. Hageman wrote: > > I am having some issues utilizing XML::LibXSLT into a mod_perl application > > I am working on. The problem displays itself as a segfault on server > > startup. The setup I have is a standard RedHat 7.2 box with the following > > updated packages: > > > > apache 1.3.23 > > mod_perl 1.26 > > libxml2 2.4.21 > > libxslt 1.0.17 > > perl 5.6.1 > > > > The CPAN modules are all the latest as of today. The test is just a > > simple perl section with: > > > > > > use XML::LibXSLT; > > > > > It's probably something to do with the BOOT section in LibXSLT. Just > don't load it that way - you're not winning much by trying to make it > shared anyway (because it's mostly XS/C code, rather than perl code). > > Matt. > > > -- //\\ || D. Hageman<[EMAIL PROTECTED]> || \\//
Re: XML::LibXSLT / Apache / MOD_Perl Segfaults
D. Hageman wrote: > I am having some issues utilizing XML::LibXSLT into a mod_perl application > I am working on. The problem displays itself as a segfault on server > startup. The setup I have is a standard RedHat 7.2 box with the following > updated packages: > > apache 1.3.23 > mod_perl 1.26 > libxml2 2.4.21 > libxslt 1.0.17 > perl 5.6.1 > > The CPAN modules are all the latest as of today. The test is just a > simple perl section with: > > > use XML::LibXSLT; > It's probably something to do with the BOOT section in LibXSLT. Just don't load it that way - you're not winning much by trying to make it shared anyway (because it's mostly XS/C code, rather than perl code). Matt.
XML::LibXSLT / Apache / MOD_Perl Segfaults
I am having some issues utilizing XML::LibXSLT into a mod_perl application I am working on. The problem displays itself as a segfault on server startup. The setup I have is a standard RedHat 7.2 box with the following updated packages: apache 1.3.23 mod_perl 1.26 libxml2 2.4.21 libxslt 1.0.17 perl 5.6.1 The CPAN modules are all the latest as of today. The test is just a simple perl section with: use XML::LibXSLT; , argc=3, ubp_av=0xbb04, init=0x804f32c <_init>, fini=0x8074e10 <_fini>, rtld_fini=0x4000dcd4 <_dl_fini>, stack_end=0xbafc) at ../sysdeps/generic/libc-start.c:129 -- //\\ || D. Hageman<[EMAIL PROTECTED]> || \\//
Perl Callbacks not working
Hello,
I am trying to use a Perl Module that is an interface to a C Library.
These module use some "callbacks" , like these perl Code:
use strict;
use Mail::CClient qw(set_callback);
set_callback (login=> sub { return ("login","password"); } )
I think this is related with the cacching feature of mod_perl that need to
be disabled for pages that uses these callbacks.
Thanks in advance,
Vitor
Re: [Fwd: Re: Cheap and unique]
Hi, > >I'm just curious - what's wrong with the function you're already using? > > Mod_Perl hangs on to it's PID, so it's no longer unique. (I _believe_) TIMESTAMP . $$ . $GLOBAL++ might work just as well (as $global will persist).. Cheers, Alex -- Alex Krohn <[EMAIL PROTECTED]>
[Fwd: Re: Cheap and unique]
> >I'm just curious - what's wrong with the function you're already using? > >Steve > Mod_Perl hangs on to it's PID, so it's no longer unique. (I _believe_) mod_unique_id looks like a good solution, pending performance. Thanks for your help so far, everyone! David
Re: Cheap and unique
David Jacobs wrote: > > I'm converting a few CGI scripts that used the PID as a cyclical unique > number (in concert with TIMESTAMP - so it was TIMESTAMP.PID). > > Our goal is to find a replacement function that is extremely cheap > (cheaper than say, random(100)) and will never repeat. Any ideas? > Has anyone else faced this problem? > > tia > David I'm just curious - what's wrong with the function you're already using? Steve -- Steve Piner Web Applications Developer Marketview Limited http://www.marketview.co.nz
RE: Cheap and unique
Of course "srand" seeds "rand". And yes, it is a good way to generate random numbers for a one time application RUN. CGI on the other hand could pose a problem, as stated in the "Programming in PERL" book. Salutations - RB -Original Message- From: Paul Johnson [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 30, 2002 4:35 PM To: Perrin Harkins Cc: OCNS Consulting; David Jacobs; [EMAIL PROTECTED] Subject: Re: Cheap and unique On Tue, Apr 30, 2002 at 04:08:00PM -0400, Perrin Harkins wrote: > OCNS Consulting wrote: > >Check your "Programming in PERL" book. Specifically, the "srand" function. > > 'random' ne 'unique' > > A random function could return the same number 10 times in a row. It's > very unlikely, but it could happen. That's the definition of random. 'srand' ne 'rand' :-) I suspect that Mr or Mrs Consulting was thinking about the seed to srand that used to be required. Not to say that that is a good solution to this problem though. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
RE: Cheap and unique
Hello, OCNS>You could try -> Math::TrulyRandom CPAN module. Perrin's comments still apply. There is no guarantee that a random number generator of any type (truly random or otherwise) will return unique values. In fact, one would fully expect repetition after some amount of time. Humbly, Andrew -- Andrew Ho http://www.tellme.com/ [EMAIL PROTECTED] Engineer [EMAIL PROTECTED] Voice 650-930-9062 Tellme Networks, Inc. 1-800-555-TELLFax 650-930-9101 --
RE: Cheap and unique
You could try -> Math::TrulyRandom CPAN module. RB -Original Message- From: Perrin Harkins [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 30, 2002 4:08 PM To: OCNS Consulting Cc: David Jacobs; [EMAIL PROTECTED] Subject: Re: Cheap and unique OCNS Consulting wrote: > Check your "Programming in PERL" book. Specifically, the "srand" function. 'random' ne 'unique' A random function could return the same number 10 times in a row. It's very unlikely, but it could happen. That's the definition of random. - Perrin
Re: Cheap and unique
OCNS Consulting wrote: > Check your "Programming in PERL" book. Specifically, the "srand" function. 'random' ne 'unique' A random function could return the same number 10 times in a row. It's very unlikely, but it could happen. That's the definition of random. - Perrin
RE: Cheap and unique
If you look at the docs for mod_unique it will generate a unique number in a properly configured server farm making it a good candidate for this process if you are worried about getting a unique number across several systems. > -Original Message- > From: Perrin Harkins [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, April 30, 2002 2:44 PM > To: David Jacobs > Cc: [EMAIL PROTECTED] > Subject: Re: Cheap and unique > > > David Jacobs wrote: > > I'm converting a few CGI scripts that used the PID as a > cyclical unique > > number (in concert with TIMESTAMP - so it was TIMESTAMP.PID). > > > > Our goal is to find a replacement function that is extremely cheap > > (cheaper than say, random(100)) and will never repeat. > Any ideas? > > Yes, mod_unique_id will do that, as will Sys::UniqueID and > Data::UUID on > CPAN. Of course that random function is probably very > lightweight, but > it's not actually unique. > > - Perrin > >
RE: Cheap and unique
Check your "Programming in PERL" book. Specifically, the "srand" function. RB -Original Message- From: David Jacobs [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 30, 2002 3:39 PM To: [EMAIL PROTECTED] Subject: Cheap and unique I'm converting a few CGI scripts that used the PID as a cyclical unique number (in concert with TIMESTAMP - so it was TIMESTAMP.PID). Our goal is to find a replacement function that is extremely cheap (cheaper than say, random(100)) and will never repeat. Any ideas? Has anyone else faced this problem? tia David
Re: Cheap and unique
David Jacobs wrote: > I'm converting a few CGI scripts that used the PID as a cyclical unique > number (in concert with TIMESTAMP - so it was TIMESTAMP.PID). > > Our goal is to find a replacement function that is extremely cheap > (cheaper than say, random(100)) and will never repeat. Any ideas? Yes, mod_unique_id will do that, as will Sys::UniqueID and Data::UUID on CPAN. Of course that random function is probably very lightweight, but it's not actually unique. - Perrin
Re: Cheap and unique
Hi there, On Tue, 30 Apr 2002, David Jacobs wrote: > I'm converting a few CGI scripts that used the PID as a cyclical unique > number (in concert with TIMESTAMP - so it was TIMESTAMP.PID). > > Our goal is to find a replacement function that is extremely cheap > (cheaper than say, random(100)) and will never repeat. Any ideas? Have a look at Time::HiRes? 73, Ged.
Cheap and unique
I'm converting a few CGI scripts that used the PID as a cyclical unique number (in concert with TIMESTAMP - so it was TIMESTAMP.PID). Our goal is to find a replacement function that is extremely cheap (cheaper than say, random(100)) and will never repeat. Any ideas? Has anyone else faced this problem? tia David
Apache 2.0 worker MPM
Hello, I am looking into using mod_perl with Apache 2 and the worker MPM, I was wondering what the status is of mod_perl for this setup. I noticed that in the docs it says it is in the alpha stage, is this due to perls ithreads not being quite ready? Is anyone using such a setup, on linux with glibc 2.1, successfully? Thanks, Patrick -- Patrick Mackinlay[EMAIL PROTECTED] ICQ: 59277981tel: +44 7050699851 Yahoo messenger: patrick00_ukfax: +44 7050699852 SpaceSurfer Limited http://www.spacesurfer.com/
Re: Can mod_perl help me use ENV variables in httpd.conf?
Fran Fabrizio wrote:
>
> I spoke too soon.
>
> I need:
>
>
> push @Alias, [ qw(/cgi-bin/chimpkit/
> $ENV{SERVER_ROOT}/cgi-bin/chimpkit/) ];
>
>
> This does not appear to be possible because there's no way to pass in
> SERVER_ROOT to the apache startup. I have SERVER_ROOT getting set in
> root's .bashrc, but when I execute ./apachectl start it appears to not
> pass in any ENV at all, and the server seems to set only a
> fewGATEWAY_INTERFACE, MOD_PERL and PATH. I can't use PerlSetEnv of
> course because I'm trying to make a portable mod_perl.conf in the first
> place. I can't use SetEnv in the httpd.conf because that doesn't get
> set until the fixup phase. Is there any way?
>
what about:
warn "ServerRoot: ", Apache->server_root_relative;
?
you also might want to do something with -D flags to httpd. it would mean editing
apachectl, but then you could either do
do stuff
or
$ServerRoot = 'ClientA' if Apache->defined('ClientA');
or somesuch.
HTH
--Geoff
Re: Can mod_perl help me use ENV variables in httpd.conf?
I spoke too soon.
I need:
push @Alias, [ qw(/cgi-bin/chimpkit/ $ENV{SERVER_ROOT}/cgi-bin/chimpkit/) ];
This does not appear to be possible because there's no way to pass in SERVER_ROOT to
the apache startup. I have SERVER_ROOT
getting set in root's .bashrc, but when I execute ./apachectl start it appears to not
pass in any ENV at all, and the server seems
to set only a fewGATEWAY_INTERFACE, MOD_PERL and PATH. I can't use PerlSetEnv of
course because I'm trying to make a portable
mod_perl.conf in the first place. I can't use SetEnv in the httpd.conf because that
doesn't get set until the fixup phase. Is
there any way?
-Fran
Fran Fabrizio wrote:
>
> Yikes, I just found an example of the exact thing I needed in the
> cookbook (recipe 2.16). Sorry, and thanks!
>
> -Fran
Re: Apache::DBI fails to compile?
F.Xavier Noria wrote: > I installed Apache::DBI and "make test" run no test, but the "make test" > of Apache::AuthCookieDBI tries to use Apache::DBI and fails because > Apache/DBI.pm in line 202 invokes Apache->module(), which it seems it is > not in the interface of the Apache class I have installed: > > $ perl -MApache::DBI -e1 > Can't locate object method "module" via package "Apache" (perhaps you forgot to >load "Apache"?) at /usr/local/share/perl/5.6.1/Apache/DBI.pm line 202. > Compilation failed in require. > BEGIN failed--compilation aborted. > > This is the version of Apache.pm I have installed: > > $ perl -MApache -le 'print $Apache::VERSION' > 1.27 > > and mod_perl is 1.26, do you know what could wrong? That's normal. You cannot test modules that use mod_perl API without running them inside mod_perl server. I've the same problem as you've reported. This test suite is simple broken. If you talk to the Jacob Davies, please tell him that it's a good idea to set the prerequisites in Makefile.PL, so his module will be installable from CPAN, without doing any manual work. All Apache:: module authors should be moving to use the new Apache::Test framework soon, since it lets you test the code under running mod_perl server and works with both versions of httpd/mod_perl. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Help with Basic Auth mod_perl2
Peter: please subscribe to the users list, see
http://perl.apache.org/preview/modperl-docs/dst_html/maillist/list-modperl.html
for more information. That is where you should post questions like this,
not the development list which is exclusively for mod_perl core development.
I forwarded your e-mail to [EMAIL PROTECTED], so that others can
reply there.
At 19:23 30.04.2002, Peter Rothermel wrote:
>greetings,
>
>I'm somewhat new to this group so please point me
>to the FAQ if I'm asking the wrong questions for this
>forum.
>
>I'm trying to migrate from Apache 1.3 on Unix to Apache 2.0
>on WinNT and I'm running into problems getting my perl modules
>working. Here's the first of my problems:
>
>I've added an Authentication Handler to a location that uses
>basic auth and can't get this simple example from the Eagle book
>running. It looks like $r->coonection->user is no longer supported.
>If I use $r->user the auth handler works fine. I'm I not using Apache::compat
>correctly?
>
>
>Here's my auth handler:
>
>sub authenBasic ($) {
> my $r = shift;
>
> my ($res, $sentpass) = $r->get_basic_auth_pw;
> return $res if $res != OK;
>
># my $user = $r->user;
> my $user = $r->connection->user;
> unless ($user and $sentpass) {
> $r->note_basic_auth_failure;
> $r->log_reason("Both a username and password must be supplied",
>$r->filename);
> return AUTH_REQUIRED;
> }
>
>Here's the error message that gets sent to the browser:
> Server error!
> Error message:
>Can't locate object method "user" via package
> "Apache::Connection" at C:\Apache2
>/blib/lib/Apache/AgentAuthCookie.pm line 23.
>If you think this is a server error, please contact the
> webmaster
>Error 500
>localhost
>04/30/2002 09:41:43 AM
>Apache/2.0.36-dev (Win32) mod_perl/1.99_02-dev Perl/v5.6.0
>
>
>Here's the entry in the error.log:
> [Tue Apr 30 09:41:43 2002] [error] [client 127.0.0.1] Can't locate
> object method
> "user" via package "Apache::Connection" at
> C:\Apache2/blib/lib/Apache/AgentAuthCookie.pm line 23.
>
>
>
>In my httpd.conf file:
>
>PerlSwitches -Mblib=C:\Apache2
>PerlModule Apache2
>
> PerlResponseHandler Apache::HelloWorld
> SetHandler modperl
>
>
>PerlModule Apache::compat
>PerlRequire "/apache2/conf/startup.pl"
>
>Alias /modperl /apache2/perlmods
>
>
> SetHandler perl-script
> Options ExecCGI
> PerlSendHeader On
>PerlOptions +GlobalRequest
>PerlResponseHandler ModPerl::Registry
> allow from all
>
>
>PerlModule Apache::WGTI::hello
>PerlModule Apache::AgentAuthCookie
>
>
> SetHandler perl-script
>
> AuthType Basic
> AuthName "WatchGuardAgentUser"
> PerlAuthenHandler Apache::AgentAuthCookie::authenBasic
> require valid-user
> PerlHandler Apache::WGTI::hello
>
>
>
>In my startup.pl:
>
>$ENV{MOD_PERL} or die "not running under mod_perl!";
>use Apache2 ();
>use Apache::compat ();
>
>use Carp ();
>use CGI ();
>CGI->compile(':all');
>CGI->compile(':standard');
>
>use CGI::Carp;
>
>use Apache::AgentAuthCookie;
>1;
--
Per Einar Ellefsen
[EMAIL PROTECTED]
RE: schedule server possible?
What I am thinking is that if we can use Apache 2 to do it. That is, to make Apache's function beyond a request/response model. If this API is not there, I am proposing, if possible, 1. Add an Apache API to call sub init; when starting a thread. 2. Within sub init, it calls an Apache API to disable this thread from receiving request, so that it can be used solely for scheduling purpose. Any thumb up or down on this? Steve Lihn FIS Database Support, Merck & Co., Inc. Tel: (908) 423 - 4441 > -Original Message- > From: Garnet R. Chaney [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, April 30, 2002 12:46 PM > To: Lihn, Steve; [EMAIL PROTECTED] > Subject: RE: schedule server possible? > > > Steve, > > How about another process on the same machine that > periodically accesses > > http://localhost/administration/schedule_tick.pl > > > - Garnet > > Family Friendly Search - http://www.find11.com > BidSearch - See how much others are bidding on keywords - > http://bidsearch.find11.com > > > -Original Message- > From: Lihn, Steve [mailto:[EMAIL PROTECTED]] > Sent: Monday, April 29, 2002 11:57 AM > To: '[EMAIL PROTECTED]' > Subject: schedule server possible? > > > Hi, > The Apache 2 Connection handler opens up the possibility of > using it for all kinds of protocol servers. > > However, I have a wild question: Is it possible to use Apache mod_perl > for a schedule server? I.e., a server that is self existent. > > For example, I can use Apache 2 for Telnet, FTP, SMTP, or > even Telephony > Server. > But I will need a thread that processes the backend stuff, such as > maintaining > the database and message queue (more like a cron). Is this > configuration > possible? > > Steve Lihn > FIS Database Support, Merck & Co., Inc. > Tel: (908) 423 - 4441 > > > > > -- > -- > -- > Notice: This e-mail message, together with any attachments, contains > information of Merck & Co., Inc. (Whitehouse Station, New > Jersey, USA) that > may be confidential, proprietary copyrighted and/or legally > privileged, and > is intended solely for the use of the individual or entity > named in this > message. If you are not the intended recipient, and have > received this > message in error, please immediately return this by e-mail > and then delete > it. > > == > == > == > > -- Notice: This e-mail message, together with any attachments, contains information of Merck & Co., Inc. (Whitehouse Station, New Jersey, USA) that may be confidential, proprietary copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named on this message. If you are not the intended recipient, and have received this message in error, please immediately return this by e-mail and then delete it. ==
Re: mod-perl and Apache 2.0.35
At 18:50 30.04.2002, Kent, Mr. John wrote: >Anyone have instructions on how >to install mod-perl on Apache 2.0.35. > >Mod-Perl is looking for Apache's /src file which >doesn't exist in 2.0.35. Please remember that mod_perl 1.x is not compatible with Apache 2.x. The mod_perl development version for 2.0 that was released not long ago (1.99) is Apache 2 compatible. However, it hasn't stabilized yet. For the time being you'd be better off using mod_perl 1.x with Apache 1.3.x, but that's likely to change soon. -- Per Einar Ellefsen [EMAIL PROTECTED]
mod-perl and Apache 2.0.35
Anyone have instructions on how to install mod-perl on Apache 2.0.35. Mod-Perl is looking for Apache's /src file which doesn't exist in 2.0.35. Thanks, John Kent -
RE: schedule server possible?
Steve, How about another process on the same machine that periodically accesses http://localhost/administration/schedule_tick.pl - Garnet Family Friendly Search - http://www.find11.com BidSearch - See how much others are bidding on keywords - http://bidsearch.find11.com -Original Message- From: Lihn, Steve [mailto:[EMAIL PROTECTED]] Sent: Monday, April 29, 2002 11:57 AM To: '[EMAIL PROTECTED]' Subject: schedule server possible? Hi, The Apache 2 Connection handler opens up the possibility of using it for all kinds of protocol servers. However, I have a wild question: Is it possible to use Apache mod_perl for a schedule server? I.e., a server that is self existent. For example, I can use Apache 2 for Telnet, FTP, SMTP, or even Telephony Server. But I will need a thread that processes the backend stuff, such as maintaining the database and message queue (more like a cron). Is this configuration possible? Steve Lihn FIS Database Support, Merck & Co., Inc. Tel: (908) 423 - 4441 -- Notice: This e-mail message, together with any attachments, contains information of Merck & Co., Inc. (Whitehouse Station, New Jersey, USA) that may be confidential, proprietary copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by e-mail and then delete it. ==
Re: Client capabilities
At 13:12 30.04.2002, Joel Palmius wrote: >Is there a mod_perl API (or some other standard way) to determine what a >client web browser is capable of displaying? (images, tables, plugins...) > >I am developing a web questionnaire system in mod_perl (1.26) and I'm >thinking about maybe dividing the display code into different levels >depending on what the client can handle (no graphics no css for lynx-like >browsers, stylesheets and images for most browsers, and plugin extensions >for more advanced browsers). The easiest is probably to ask the user. Tackling this in programming code will probably fail as you have a too wide array of different user agents, which each have their own options enabled/disabled. If the user won't understand those questions (that might be normal), well, try to make something that works for everyone. For example, you talk about CSS, but if used correctly, text-based users will be able to use a page that has CSS even if they don't have support for it. In the end, nobody really cares about all the extra "stuff", and the way that works for everyone will probably be the best (of course, don't be too conservative either; anyone using lynx for example will know its limitations). -- Per Einar Ellefsen [EMAIL PROTECTED]
Re: PerlRun problem: can't find method "uri"?
At 09:09 30.04.2002, Ricky wrote: >When running under apache::perlrun, the script sometimes crash. >In error_log show : >"can't locate object method "uri" via package "Apache::perlrun" This got me wondering: are you specifying Apache::PerlRun in any configuration or Apache::perlrun? Please remember that Perl packages and modules are case-sensitive, so Apache::PerlRun (which is the correct one) is different from Apache::perlrun. >Currently research about mod_perl. >Is it a good decision try to move to mod_perl because the implementation time >is slow. >Is there any other tech that easier/more faster than mod_perl? >How about PHP or JSP? Well, if you don't want to change your scripts, it's most likely that implementation in PHP or JSP will be a lot slower: you'll have to find competent people in those fields, learn the technology, etc. While with a few fixes to your current code you should be able to run it under mod_perl. As for PHP and JSP, they take completely different approaches (code-in-HTML at the most basic level), which are mostly considered to be a bad thing (as they mix logic and presentation). Of course, these technologies have their own advantages, but it will not be easier to work with them than with mod_perl. -- Per Einar Ellefsen [EMAIL PROTECTED]
Re: Can mod_perl help me use ENV variables in httpd.conf?
Yikes, I just found an example of the exact thing I needed in the cookbook (recipe 2.16). Sorry, and thanks! -Fran
Re: Can mod_perl help me use ENV variables in httpd.conf?
Yup. See the directive. Good description of how it works in the Eagle Book. -- Fran Fabrizio <[EMAIL PROTECTED]> > > I am trying to make a portable mod_perl.conf. I have things like: > > Alias /cgi-bin/chimpkit/ /usr/local/apache/cgi-bin/chimpkit/ > > SetHandler perl-script > PerlHandler Apache::Registry > Options +ExecCGI > PerlSendHeader On > > > which really needs to become something like: > > Alias /cgi-bin/chimpkit/ $SERVER_ROOT/cgi-bin/chimpkit/ > etc... > > I don't think I can do this directly with Apache but I found a random > newsgroup thread that suggested something like the following might work: > > > push @PerlConfig,> SetHandler perl-script > PerlHandler Apache::Registry > Options +ExecCGI > PerlSendHeader On > > EOF > > > Is this a good way to solve this problem, is there an easier way, and > does this even work? :-) > > Thanks, > Fran -- Steven Lembark 2930 W. Palmer Workhorse Computing Chicago, IL 60647 +1 800 762 1582
Re: Client capabilities
On Tue, 30 Apr 2002 16:26:00 +0400 "Mike V. Andreev" <[EMAIL PROTECTED]> wrote: : On Tue, 30 Apr 2002 13:00:33 +0100 : Simon Oliver <[EMAIL PROTECTED]> wrote: : : SO> The main problem is that a client can be modified from the "standard" : SO> install to prevent JavaScript, StyleSheets, Images, etc and there is no : SO> way to detect this server side. : : (and some text-based browsers can be configured to use external program : to show images on user request [links for example] ) w3m renders images indeed :-). -- fxn
Can mod_perl help me use ENV variables in httpd.conf?
I am trying to make a portable mod_perl.conf. I have things like: Alias /cgi-bin/chimpkit/ /usr/local/apache/cgi-bin/chimpkit/ SetHandler perl-script PerlHandler Apache::Registry Options +ExecCGI PerlSendHeader On which really needs to become something like: Alias /cgi-bin/chimpkit/ $SERVER_ROOT/cgi-bin/chimpkit/ etc... I don't think I can do this directly with Apache but I found a random newsgroup thread that suggested something like the following might work: push @PerlConfig, < SetHandler perl-script PerlHandler Apache::Registry Options +ExecCGI PerlSendHeader On EOF Is this a good way to solve this problem, is there an easier way, and does this even work? :-) Thanks, Fran
Re: PerlRun problem: can't find method "uri"?
Ricky wrote: > When running under apache::perlrun, the script sometimes crash. I agree with Stas that if you fix the problems with your script running under "strict" this will most likely go away. > In mod_perl manual said that the script usually run in apache::perlrun > widthout change but not in my script. One thing that often causes problems is old Perl4-style library files. If you have functions that you load from some .pl files which have no package name and are pulled into the main namespace, you should change them into real Perl5-style modules. There are lots of reasons you should fix this; mod_perl is just one of them. > And I can't add "use strict" because it will crash the script immediatelly. > In error_log show : > "Variable "%in" is not imported at /home/httpd/html/scdf/scdf.plx line 174." > "Global symbol "$sth" requires explicit package name at > /home/httpd/html/scdf/scdf.plx line 171." If you've read the documentation and you still need help understanding how to program with the "strict" pragma, I suggest looking on http://perlmonks.org/. > Is it a good decision try to move to mod_perl because the implementation time > is slow. > Is there any other tech that easier/more faster than mod_perl? > How about PHP or JSP? It will be much faster to fix your CGI scripts so they run under mod_perl than to re-write them in PHP or JSP. - Perrin
Re: Client capabilities
On Tue, 30 Apr 2002 13:00:33 +0100 Simon Oliver <[EMAIL PROTECTED]> wrote: SO> The main problem is that a client can be modified from the "standard" SO> install to prevent JavaScript, StyleSheets, Images, etc and there is no SO> way to detect this server side. (and some text-based browsers can be configured to use external program to show images on user request [links for example] ) About images: Why don't use "alt" attribute of "img" tag to make a design suitable for both text-based and graphic browser ??? Mike Andreev
Re: Client capabilities
Martin Haase-Thomas wrote: > > HTTP defines an 'Accept' header. But that's not much use. For example lynx replies with HTTP_ACCEPT text/html, text/plain, image/*, image/jpeg, text/sgml, video/mpeg, image/jpeg, image/tiff, image/x-rgb, image/png, image/x-xbitmap, image/x-xbm, image/gif, application/postscript, */*;q=0.01 But it can't render images or postscript! Your best bet is to use the HTTP_USER_AGENT header. From this you can work out what browser the client is using and marry this info with a database of browser capabilities (Microsoft provide one for use with IIS). The main problem is that a client can be modified from the "standard" install to prevent JavaScript, StyleSheets, Images, etc and there is no way to detect this server side. You can detect JavaScript at the client side and redirect to a JavaScript enabled URL or use the tag to provide alternative content. Again at the client side you can use DHTML to determine client capabilities and redirect or display alternative content accordingly but this will not work with all browsers, see: http://msdn.microsoft.com/workshop/author/clientcaps/overview.asp -- Simon Oliver
Re: Client capabilities
HTTP defines an 'Accept' header. Joel Palmius wrote: >Is there a mod_perl API (or some other standard way) to determine what a >client web browser is capable of displaying? (images, tables, plugins...) > >I am developing a web questionnaire system in mod_perl (1.26) and I'm >thinking about maybe dividing the display code into different levels >depending on what the client can handle (no graphics no css for lynx-like >browsers, stylesheets and images for most browsers, and plugin extensions >for more advanced browsers). > >Only, I can't figure out how to determine if a client is capable of >displaing an image, a stylesheets or (as an example) a J2RE 1.4 >java-plugin compatible applet. > >When reading the "HTTP_ACCEPT" environment variable, both lynx and mozilla >say they can handle "image/png", while in practise lynx cannot display >that. > > // Joel > > > > -- "Constant shallowness leads to evil." --- Martin Haase-Thomas |Tel.: +49 30 43730-558 Software Development| [EMAIL PROTECTED] ---
Client capabilities
Is there a mod_perl API (or some other standard way) to determine what a client web browser is capable of displaying? (images, tables, plugins...) I am developing a web questionnaire system in mod_perl (1.26) and I'm thinking about maybe dividing the display code into different levels depending on what the client can handle (no graphics no css for lynx-like browsers, stylesheets and images for most browsers, and plugin extensions for more advanced browsers). Only, I can't figure out how to determine if a client is capable of displaing an image, a stylesheets or (as an example) a J2RE 1.4 java-plugin compatible applet. When reading the "HTTP_ACCEPT" environment variable, both lynx and mozilla say they can handle "image/png", while in practise lynx cannot display that. // Joel
Re: PerlRun problem: can't find method "uri"?
Ricky wrote: > Hi All, > I am trying to porting mod_cgi script to mod_perl script because > the mod_cgi script don't run correctly under mod_perl. > > When running under apache::registry, the script show wrong result. what do you mean, wrong results. Have you read http://perl.apache.org/preview/modperl-docs/dst_html/docs/1.0/guide/porting.html > When running under apache::perlrun, the script sometimes crash. > In error_log show : > "can't locate object method "uri" via package "Apache::perlrun" > > In mod_perl manual said that the script usually run in apache::perlrun > widthout change but not in my script. > > And I can't add "use strict" because it will crash the script immediatelly. > In error_log show : > "Variable "%in" is not imported at /home/httpd/html/scdf/scdf.plx line 174." > "Global symbol "$sth" requires explicit package name at > /home/httpd/html/scdf/scdf.plx line 171." You better fix these errors, and keep 'use strict' in place. Then PerlRun should work without any problems in most cases. If after fixing those problems you still have problems, come back with your relevant questions again. It's a good idea to have your code running under 'use strict' no matter if you use mod_perl or not. This will save you a lot of grief in a long run. > Our company planning to move from Perl/CGI to better/faster technology. > Currently research about mod_perl. > Is it a good decision try to move to mod_perl because the implementation time > is slow. > Is there any other tech that easier/more faster than mod_perl? > How about PHP or JSP? It depends on your definition of "easier". Easier==sloppier: better stay away from mod_perl. Easier==more flexible: go with mod_perl. As for the speed, I doubt you will find something *significantly* faster than mod_perl. Assuming that you learn how to get the most our of mod_perl. [p.s. please make sure you reply back to the list!] __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
