Slightly OT: DBD::Oracle::ping
Hi!
In the code for DBD::Oracle::db::ping method there are lines
local $SIG{__DIE__};
local $SIG{__WARN__};
As I understand these lines don't do anything though I guess they are supposed
to suppress warning messages and possibly 'die' messages. Currently everytime
when ping fails and we have PrintError = 1 then the message goes into Apache error
log. What is worse if $dbh was disconnected then ping dies and kills the whole
process. As temporary fix we can user $dbh-{RaiseError} = 0, but then we'd
have to rewrite the code that was placed into eval blocks.
Is this a feature or something that should be fixed? Was it supposed to be
local $SIG{__WARN__} = sub {};
Andrei
Locating infinite loops
I have an error on my server that I think is caused by an infinite loop in perl code [*]. Does anyone have a reliable way to detect where this is happening on a server with lots of code? Matt. -- :-Get a smart net/:- [*] In case anyone was wondering, this is probably why you can't get to axkit.org at the moment, and my car is in the garage, so I can't get home to login and kill the rogue process, and ssh won't let me in due to timeouts. Yes, I need Apache::Watchdog, I know. _ This message has been checked for all known viruses by Star Internet delivered through the MessageLabs Virus Scanning Service. For further information visit http://www.star.net.uk/stats.asp or alternatively call Star Internet for details on the Virus Scanning Service.
Documentation patch for mod_perl//win32
Greetings. This documentationpatchaddressesthe single thread snafu on Win32. Comments, corrections and additions (even subtractions) welcome. (Also on the hot topic of the day: where in the doc does this fit?) Cheers, alf modperl_multithread_NT.pod Description: Binary data
Fastcgi on win [Was: Re: Documentation patch for mod_perl?]
Greetings.
[following Stas' suggestion I have subscribed to the list and
posted the patch there, so I am crossposting]
Do you know if FastCGI is multi-threaded or multi-process on
Windows?
Multi process. Each process speaks tomod_fastcgi over a
named pipe. As you mention, this (being multithreaded) avoids the problem
to which mod_perl succumbs.
[...]
Also, which FastCGI implementation do you recommend for
Windows?
I am in the process of testing mod_fastcgi, and that being
the only one I have seen so far, I should probably reccomend it...
;) It appears to be the only apache implementation by the
way. Also www.fastcgi.com
says that implementations for IIS and Iplanet were withdrawn by the firm that
was producing them.
Setting up is a bit of a pain (though recompiling perl with SFIO
is no longer required) Recompilationsmaybe required forapache,
mod_fastcgi,FCGI.pm. Also the Apache configuration can be a little
delicate.
After setup is taken care of, however, all it took to convert
the application was changing:
use CGI;
my $q=new CGI;
to
use FCGI;
use CGI::Fast;
my $q;
while($q=new CGI::Fast) {
}
So it wasn't bad, though I have to say that the app already
clears mod_perl and straight CGI, so it is exceptionally clean (by my
standards, at least).
I did run some tests - which basically check activation times, I
am working on getting more significant number on concurrency etc. Some patterns
do already emerge though:
Testing from a Linux box with:
ab -c30 -n 60 (30 concurrrent sessions, two requests each)
I get:
mod_perl (already compiled):
Concurrency Level: 30Time
taken for tests: 5.463 secondsComplete
requests: 60Failed
requests: 0Total
transferred: 292080 bytesHTML
transferred: 280620 bytesRequests per
second: 10.98Transfer
rate: 53.47 kb/s
received
Fast CGI (throttled at 4 concurrent servers already
running):
Concurrency Level: 30Time
taken for tests: 8.018 secondsComplete
requests: 60Failed
requests: 0Total
transferred: 292440 bytesHTML
transferred: 280980 bytesRequests per
second: 7.48Transfer
rate: 36.47 kb/s
received
Straight CGI gave me a server timed out with the same values. So
I lowered it to:
ab -c 10 -n 60
Concurrency Level: 10Time
taken for tests: 139.580 secondsComplete
requests: 60Failed
requests: 0Total
transferred: 292140 bytesHTML
transferred: 280680 bytesRequests per
second: 0.43Transfer
rate: 2.09 kb/s
received
So mod_perl has a slight speed edge over fastcgi (whichis
overthrottleda littlewith four servers). CGI is glacial as exepcted
- well, a little more actually, probablyaccounting for the catastrophic
event entailed bystarting a process on NT.
I plan to run some tests also on IIS with CGI and PerlEx and if
they're interesting I'll post them.
Cheers,
alf
Problems Confirugint Mod Perl/Mod SSL on Apache 1.3.22
I'm having a bit of a problem getting everything to work right. Everything Compiles, then it looks like it's running, but the moment your client (or telnet) connects, it shuts itself down. I've tried 'make clean make make install' to see if that remedies the problem, but that doesn't help. I've also reset my httpd.conf file to the defaults, and that doesn't help either. When I do just a 'plain-jane' ./apachectl start (as opposed to an ./apachectl startssl), I get the webpages, however, the mod_perl interface seems not to work. (HTML::Mason won't work). Any suggestions? Ian From RFC 1925: (3) With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead.
[modperl]
Hello, I have a mod_cgi application, which we are currently in the process of converting into a mod_perl application. the necessary configuration changes related to mod_perl have been made. however we are facing a no. of problems. some of the typical problems are: 1) We are a group of three developers, working in separate areas, however whenever one of us runs the application in one's area, and then another of us runs, in their area, the modules loaded from the first developer's area in the earlier run continue to be in effect. What could be the reasons for this. Is this a characteristic of mod_perl behaviour? 2) We get an Apache warning child pid 567 exit signal Segmentation fault (11) sometimes. At times this error causes the page to not get loaded at all. Could someone please guide us with these problems? george francis Apache/Mod_Perl * Disclaimer This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited. * Visit us at http://www.mahindrabt.com
Re: Slightly OT: DBD::Oracle::ping
Andrei A. Voropaev wrote:
Hi!
In the code for DBD::Oracle::db::ping method there are lines
local $SIG{__DIE__};
local $SIG{__WARN__};
As I understand these lines don't do anything though I guess they are supposed
to suppress warning messages and possibly 'die' messages. Currently everytime
when ping fails and we have PrintError = 1 then the message goes into Apache error
log. What is worse if $dbh was disconnected then ping dies and kills the whole
process. As temporary fix we can user $dbh-{RaiseError} = 0, but then we'd
have to rewrite the code that was placed into eval blocks.
Is this a feature or something that should be fixed? Was it supposed to be
local $SIG{__WARN__} = sub {};
That simply means that any die/warn handlers that the running code may
have set, are unset in the given scope. Therefore if there code wants to
print a warning or the code die()'s, the *default* handler will be used.
I think this is mostly used for protection from user-defined sighadler
which may have an ill-effect during eval {} blocks. See
http://perl.apache.org/guide/perl.html#Exception_Handling_for_mod_perl
I'm not familiar with DBD::Oracle, but you may need to run the faulty
code in the eval {} block to prevent die-ing.
_
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: [modperl]
George Francis wrote: Hello, I have a mod_cgi application, which we are currently in the process of converting into a mod_perl application. the necessary configuration changes related to mod_perl have been made. however we are facing a no. of problems. some of the typical problems are: 1) We are a group of three developers, working in separate areas, however whenever one of us runs the application in one's area, and then another of us runs, in their area, the modules loaded from the first developer's area in the earlier run continue to be in effect. What could be the reasons for this. Is this a characteristic of mod_perl behaviour? 2) We get an Apache warning child pid 567 exit signal Segmentation fault (11) sometimes. At times this error causes the page to not get loaded at all. Could someone please guide us with these problems? You just said it, read the guide :) 1) http://perl.apache.org/guide/control.html#Starting_a_Personal_Server_for_E 2) http://perl.apache.org/guide/debug.html but first look at the SUPPORT file in the mod_perl source distribution. Also check http://perl.apache.org/guide/troubleshooting.html _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: Locating infinite loops
Matt Sergeant wrote: I have an error on my server that I think is caused by an infinite loop in perl code [*]. Does anyone have a reliable way to detect where this is happening on a server with lots of code? http://perl.apache.org/guide/debug.html#Using_the_Perl_Trace -- _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: Locating infinite loops
Matt Sergeant asked:
I have an error on my server that I think is caused by an infinite loop in
perl code [*]. Does anyone have a reliable way to detect where this is
happening on a server with lots of code?
$SIG{ALRM} = sub {
Carp::confess(Got Apache::Event ALRM);
};
alarm(300);
Replacing 300 with some amount which any process should finish in.
Not elegent, but it seems to work. For instance, this:
use Carp;
$SIG{ALRM} = sub {
Carp::confess(Got Apache::Event ALRM);
};
alarm(3);
temp();
sub temp {
sleep(5);
}
...gives this result:
Got Apache::Event ALRM at testal.pl line 4
main::__ANON__('ALRM') called at testal.pl line 9
main::temp() called at testal.pl line 7
...which even shows which line Perl was up to when the SIGALRM was called
(line 9 in this case).
Re: Documentation patch for mod_perl//win32
Greetings. [...] This documentation patch addresses the single thread snafu on Win32. Comments, corrections and additions (even subtractions) welcome. (Also on the hot topic of the day: where in the doc does this fit?) Nice, but please repost it inlined. Otherwise people won't be able to comment on your words. [...] hhh I see - attachment stripping. So here it comes - brace. -SNIP---SNIP---SNIP---(sigh, the good ole days) =head1 OS caveats: multithreading on Windows NT =head2 The problem mod_Perl's multithreading capability is severely limited on Win32 platforms (WinNT and Win2K). It is in fact limited to the point of non-existence: mod_perl on Win32 is single threaded. A single instance of the interpreter is created, and it is protected with a server-wide lock, that prevents more than one thread to be using the interpreter at any one time. It is actually a little worse than that, as not only does the interpreter lock prevents parallel processing of perl requests, it also prevents Bany request to proceed (yes, this means that static content requests will also be blocked). This rather unfortunate situation is supposed to change when Apache 2.0 and mod_perl 2.0 will be officially released: in the 2 series, with full multithreading support, apache will be managing an interpreter pool whose dimensions (among other parameter) will be tunable, as documented in http://perl.apache.org/~dougm/modperl_2.0.html The 2.0 release is still some time away unfortunately, which means that users of 1.3.x are stuck in single threaded world. =head2 Does it really matter? How serious is this? For some people and application classes it may be a non-problem, assuming the static material issue is handled differently. If your application is CPU bound, and all requests take roughly the same time to complete, then having more processing thread than processors (CPUs) will actually slow things down, because of the context switching overhead. Note that even in this case, the current state of mod_perl will bar owners of multiprocessor Win32 machines from gaining a load balancing advantage from their superior hardware. On the other hand, applications dealing with a large service times spread - say ranging from fractions of a second to a minute and above - stand to lose a great deal of responsiveness from being single threaded. The reason is that short requests that happen to be queued after long ones will be delayed for the entire duration of the jobs that precede them in the queue; with multitasking they would get a chance to complete much earlier. As a real life example, think a manufacturing application where, most of the time, users are navigating a Bill Of Material - a hierarchical structure. The requests generated by this usage pattern have a rather short service time, when moving from a component (node) of the BOM to one of its children or siblings. Now and then, however, a new Bill Of Material is requested, an operation that may require up to 25 seconds to complete. During this time lapse, all other requests are queued, nobody is able to use the system, and everybody complains about being stuck. By contrast, the very same application, Brunning against a fixed BOM, falls in the first category above, and may be perfectly happy in a single CPU mod_perl environment. =head2 Workarounds If you need multithreading on Win32, either because your problem falls in the second category or because you can afford multiprocessor hardware, and assuming you cannot switch operating system, there is not much you can do - other than waiting for 2.0, that is. The only mod_perl solution to this problem appears to be a multi_server load balancing setup which uses mod_rewrite (or a URL partitioning scheme) to spread requests on several web servers, listening on different ports. If you code to Apache::Registry (writing CGI compliant code) and can characterize the time demanded by a request from its URL, you can use a similar rewrite based load balancing with a single server, by sending short requests to mod_perl while routing longer ones to the pure CGI environment - on the basis that startup, compilation and init times will matter less in this case. If you cannot do any of the above, then you will have to turn to some non mod_perl alternative. For CGI compliant scripts, two possible (portable) alternatives which are supported in an Apache/perl environment are straight CGI and FastCGI. In theory a CGI application that runs under mod_perl should have very few or none problems to run under straight CGI (though its performance may be unacceptable). A FastCGI port should also be relatively painless. My personal test of this theory tends to corroborate it: starting from an Apache::Registry CGI script, I had no perl-related problems when moving it to a CGI environment and very few for FastCGI. (I Bdid have quite a few problems related to assumptions that the application made about its environment, but that is not
How to create a browser popup window
Title: How to create a browser popup window Hello all, Can anybody give me the golden tip of creating a popup browser window from my mod_perl handler? I want to fill in this popup window with results generated within my handler. Is there a module available from CPAN which can handle this? Thanks in advance! Met vriendelijke groet / With kind regards, Domien Bakker Application Developer Application development Operations and Engineering ZeelandNet BV Postbus 35 4493 ZG Kamperland The Netherlands tel. +31 (0)113 377733 fax +31 (0)113 377784 domien@staff.zeelandnet.nl http://ww.zeelandnet.nl/
Re: How to create a browser popup window
Title: How to create a browser popup window how do I unsubscribe from this list. - Original Message - From: Domien Bakker To: [EMAIL PROTECTED] Sent: Tuesday, November 20, 2001 6:30 AM Subject: How to create a browser popup window Hello all, Can anybody give me the "golden" tip of creating a popup browser window from my mod_perl handler? I want to fill in this popup window with results generated within my handler. Is there a module available from CPAN which can handle this? Thanks in advance! Met vriendelijke groet / With kind regards, Domien Bakker Application Developer Application development Operations and Engineering ZeelandNet BV Postbus 35 4493 ZG Kamperland The Netherlands tel. +31 (0)113 377733 fax +31 (0)113 377784 domien@staff.zeelandnet.nl http://ww.zeelandnet.nl/
Re: How to create a browser popup window
This is not really a mod_perl question. Pop-up windows can only be created using client-side scripting like Javascript. Your handler would need to output the necessary Javascript to cause the pop, like: script url = /pop/source.html; name = popwin; h = 250; w = 350; var theWin = window.open(url, name, 'scrollbars=yes, resizable=yes, toolbar=no, height='+h+', width='+w); theWin.focus(); /script For more information on how that works, read Javascript docs: http://developer.netscape.com/docs/manuals/?content=javascript.html From: Domien Bakker [EMAIL PROTECTED] Date: Tue, 20 Nov 2001 15:30:45 +0100 To: [EMAIL PROTECTED] Subject: How to create a browser popup window Hello all, Can anybody give me the golden tip of creating a popup browser window from my mod_perl handler? I want to fill in this popup window with results generated within my handler. Is there a module available from CPAN which can handle this? Thanks in advance! Met vriendelijke groet / With kind regards, Domien Bakker Application Developer Application development Operations and Engineering ZeelandNet BV Postbus 35 4493 ZG Kamperland The Netherlands tel. +31 (0)113 377733 fax +31 (0)113 377784 [EMAIL PROTECTED] http://ww.zeelandnet.nl/
$r-set_handlers and $R-push_handlers
How can you specify a Location for these paramters, or can they be used only from within the current section? Issac Internet is a wonderful mechanism for making a fool ofyourself in front of a very large audience. --Anonymous Moving the mouse won't get you into trouble... Clicking it might. --Anonymous PGP Key 0xE0FA561B - Fingerprint:7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B
Re: $r-set_handlers and $R-push_handlers
How can you specify a Location for these paramters, or can they be used only from within the current section? $r is a request object, so modifications only affect the current request. If you want to affect all requests, you need to do it in the configuration stage. - Perrin
RE: $r-set_handlers and $R-push_handlers
set_handlers() and push_handlers() apply to the current request (except for the PerlRestartHandler and other handlers that are not request-oriented). it really doesn't make sense to have them apply only to a Location or otherwise - if you want them to apply only to a certain location use logic around $r-location, or use a Perl*Handler config within that Location. HTH --Geoff -Original Message-From: Issac Goldstand [mailto:[EMAIL PROTECTED]]Sent: Tuesday, November 20, 2001 11:22 AMTo: [EMAIL PROTECTED]Subject: $r-set_handlers and $R-push_handlers How can you specify a Location for these paramters, or can they be used only from within the current section? Issac Internet is a wonderful mechanism for making a fool ofyourself in front of a very large audience. --Anonymous Moving the mouse won't get you into trouble... Clicking it might. --Anonymous PGP Key 0xE0FA561B - Fingerprint:7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B
[ANNOUNCE] HTTP::WebTest 1.07
The following message is a courtesy copy of an article that has been posted to comp.lang.perl.modules,comp.lang.perl.announce as well. The uploaded file HTTP-WebTest-1.07.tar.gz has entered CPAN as file: $CPAN/authors/id/I/IL/ILYAM/HTTP-WebTest-1.07.tar.gz size: 61156 bytes md5: e7ca9ad3eb3a6020f380ffc4e84d6436 NAME HTTP::WebTest - Test remote URLs or local web files DESCRIPTION This module runs tests on remote URLs or local web files containing Perl/JSP/HTML/JavaScript/etc. and generates a detailed test report. The test specifications can be read from a parameter file or input as method arguments. If you are testing a local file, Apache is started on a private/dynamic port with a configuration file in a temporary directory. The module displays the test results on the terminal by default or directs them to a file. The module optionally e-mails the test results. Each URL/web file is tested by fetching it from the web server using a local instance of an HTTP user agent. The basic test is simply whether or not the fetch was successful. You may also test using literal strings or regular expressions that are either required to exist or forbidden to exist in the fetched page. You may also specify tests for the minimum and maximum number of bytes in the returned page. You may also specify tests for the minimum and maximum web server response time. If you are testing a local file, the module checks the error log in the temporary directory before and after the file is fetched from Apache. If messages are written to the error log during the fetch, the module flags this as an error and writes the messages to the output test report. Changes since 1.06: * HTTP::WebTest now uses Config.pm to find correct shebang string for script 'wt'. It should correctly set path to perl interpreter even if perl is installed in non-standart place. * Added test parameter mail_from which allows to set From: header in report e-mails. Thanks Joe Germuska [EMAIL PROTECTED] for patch. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | Ilya Martynov (http://martynov.org/)| | GnuPG 1024D/323BDEE6 D7F7 561E 4C1D 8A15 8E80 E4AE BE1A 53EB 323B DEE6 | | AGAVA Software Company (http://www.agava.com/) | -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
[OT] Re: How to create a browser popup window
Off topic but in the interests of, if not less popup windows, then at
least less broken ones:
You must include code to deal with the fact that you may have already
opened a popup window. Something like this:
SCRIPT LANGUAGE=JavaScript
!-- Hide
var popupwin = null;
function popup(loc,ww,hh) {
var mywidth = (ww + 10);
var myheight = (hh + 10);
var myspecs =
'menubar=1,status=1,resizable=1,location=1,titlebar=1,toolbar=1,scrollbars=1,width=
+ mywidth + ,height= + myheight + ';
if (popupwin == null || popupwin.closed) {
popupwin = window.open (loc, 'popupwin', myspecs);
} else {
popupwin.close();
popupwin = window.open (loc, 'popupwin', myspecs);
// If all your windows should be the same
// size then comment out the above two lines and
// uncomment the next two lines
// popupwin.focus();
// popupwin.location.href = loc;
}
}
/SCRIPT
A HREF='javascript://' onClick='popup(foo.gif,300,200); 'Look at foo/A
This one is good for calling with just an image as the href. You can use
any code you like, including the other example posted here. Just remember
to test whether you already have the window open or not and act
appropriately.
~~~
Nick Tonkin
On Tue, 20 Nov 2001, Ben Demonte wrote:
How to create a browser popup windowhow do I unsubscribe from this list.
- Original Message -
From: Domien Bakker
To: [EMAIL PROTECTED]
Sent: Tuesday, November 20, 2001 6:30 AM
Subject: How to create a browser popup window
Hello all,
Can anybody give me the golden tip of creating a popup browser window
from my mod_perl handler? I want to fill in this popup window with results
generated within my handler.
Is there a module available from CPAN which can handle this?
Thanks in advance!
Met vriendelijke groet / With kind regards,
Domien Bakker
Application Developer
Application development
Operations and Engineering
ZeelandNet BV
Postbus 35
4493 ZG Kamperland
The Netherlands
tel. +31 (0)113 377733
fax +31 (0)113 377784
[EMAIL PROTECTED]
http://ww.zeelandnet.nl/
Re: Problems Confirugint Mod Perl/Mod SSL on Apache 1.3.22
On Mon, 19 Nov 2001, Ian @ International Sports Agnecy wrote: if you telnet to port 80 and issue a head request manually, what does the server report exactly? it should list the modules you have properly installed. gedanken I'm having a bit of a problem getting everything to work right. Everything Compiles, then it looks like it's running, but the moment your client (or telnet) connects, it shuts itself down. I've tried 'make clean make make install' to see if that remedies the problem, but that doesn't help. I've also reset my httpd.conf file to the defaults, and that doesn't help either. When I do just a 'plain-jane' ./apachectl start (as opposed to an ./apachectl startssl), I get the webpages, however, the mod_perl interface seems not to work. (HTML::Mason won't work). Any suggestions? Ian From RFC 1925: (3) With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. -- gedanken
RE: [OT] Re: How to create a browser popup window
You must include code to deal with the fact that you may have already
opened a popup window. Something like this:
That is simply not true. window.open() with a named window ('popupwin', in
your example) ALWAYS reuses that window, on every browser I've ever been
able to test. The second call to window.open, with a new URL, simply
refreshes the contents of the popup w/ the new URL. Note, this is *only*
true for named windows. Windows without a window name string as the second
parameter to window.open() will open a new window every time.
It can, however, be a good idea to explicitly call focus() on your child
window, because in the situation I've just mentioned, if the child window's
url is refreshed, it is NOT automatically brought to the foreground.
The original post was wondering how to put mod_perl output in a popup
window. The answer is simply top call window.open() with the URL of the
mod_perl handler as its location.
If one is trying to be responsible about the window(s) being open, adding
a link like
a href=javascript:window.close()CLICK HERE CLOSE THIS WINDOW/a
in the child window is usually reasonably simple for the user to understand.
Of course, the normal caveats about users understanding something still
apply...
A corrected version of your sample script follows. It's much simpler now...
:-)
SCRIPT LANGUAGE=JavaScript
!-- Hide
var popupwin = null;
function popup(loc,ww,hh) {
var mywidth = (ww + 10);
var myheight = (hh + 10);
var myspecs =
'menubar=1,status=1,resizable=1,location=1,titlebar=1,toolbar=1,
scrollbars=1,width= + mywidth + ,height= + myheight + ';
popupwin = window.open (loc, 'popupwin', myspecs);
popupwin.focus();
}
/SCRIPT
A HREF='javascript:' onClick='popup(foo.gif,300,200)'Look at foo/A
L8r,
Rob
#!/usr/bin/perl -w
use Disclaimer qw/:standard/;
Re: PerlModule not updating %INC
Hello, I hate to keep banging this old drum, but since I was able to reproduce this problem (but not solve it), I figured I'd recycle it again. Perrin said earlier that this was fixed in 1.26, but I am indeed using 1.26 and the problem persists. Stas suggested upgrading perl to 5.6.1 -- I did so, recompiled mod_perl, and the problem persists. I didn't try upgrading the perl on my darwin box, but the fact that I get the same result there is telling. Can anyone tell me what the fix was from 1.25 to 1.26? Maybe there's a clue there. Thanks, David I'm still having this problem, and I've discovered that it is also happening on my darwin box. This is enough to lead me to believe the problem is bona fide. To recap: problem occurs on : Darwin (MacOS X) Perl 5.6.0 / Apache 1.3.20 / mod_perl 1.26 Red-Hat Linux (7.1) Perl 5.6.0 / Apache 1.3.20 / mod_perl 1.26 Red-Hat Linux (7.1) Perl 5.6.1 / Apache 1.3.20 / mod_perl 1.26 Problem : PerlModule does not cause %INC to be updated, but 'use' does Symptoms : Apache::StatINC does not work for said modules. Said modules do not appear in Apache::Status loaded modules page, but do appear in the Inheritance tree. Ideas? Thanks, David Date: Thu, 18 Oct 2001 12:57:27 -0800 To: Stas Bekman [EMAIL PROTECTED] From: David Pisoni [EMAIL PROTECTED] Subject: Re: PerlModule not updating %INC Cc: Perrin Harkins [EMAIL PROTECTED], [EMAIL PROTECTED] Bcc: X-Attachments: At 1.13 +0800 10/17/2001, Stas Bekman wrote: David Pisoni wrote: At 18.23 -0400 10/11/2001, Perrin Harkins wrote: At 18.07 -0400 10/11/2001, Perrin Harkins wrote: We are using perl 5.6.0 for Apache 1.3/20, with mod_perl 1.26. Are you sure? There was a problem with %INC and PerlModule, but I thought it was fixed in 1.26. - Perrin Indeed, like I said, I tested it by dumping %INC myself -- the modules are indeed missing when loaded with PerlModule. No, I meant are you sure you're running 1.26? Please doublecheck it, since this sounds so much like the bug from the previous release. - Perrin Indeed, here's the signature from Apache::Status : Embedded Perl version v5.6.0 for Apache/1.3.20 (Unix) (Red-Hat/Linux) mod_perl/1.26 Apache.pm shows v1.27 (that's a little weird, but I assume unimportant.) Thanks, David So... any ideas on this one? have you tried 5.6.1? 5.6.0 is very buggy. Just tried it. Fresh build of 5.6.1, and mod_perl 1.26 against it. The problem persists -- %INC is incomplete vs. my actual loaded modules, missing what was loaded with PerlModule directives. What should I try next. :-) David Original Message : Hello, We are using perl 5.6.0 for Apache 1.3/20, with mod_perl 1.26. We are running these on a RedHat Linux 7.1, kernel v2.4.2 system. We have been doing development using mod_perl, but finding that Apache::StatINC was not working as expected (i.e., we needed to restart the web server in order to see our module changes in effect.) Our apache config files preload all necessary modules at start time using the 'PerlModule' directive. When I started peeking through Apache::Status I found that although all of our loaded modules appear in the Inheritance Tree and the ISA Tree, most of them did not appear in the Loaded Modules section. (I also did a test handler with a dump of the contents of %INC, and said modules were missing.) The only modules of ours which DID appear were those which were ALSO called for with 'use' calls by other modules. Out of curiosity, I took our configuration file and changed all the 'PerlModule' directives to 'use' calls (inside a Perl block), and lo and behold, they all appeared in %INC. I could not find any documentation suggesting that the PerlModule directive would successfully load a module while circumventing %INC, nor do I recall in my previous projects developed using mod_perl having this problem. (Although I've been away awhile -- maybe I forget.) Any guidance? Thanks,
Re: PerlModule not updating %INC
At 2:31 PM -0800 11/20/01, David Pisoni wrote: We have been doing development using mod_perl, but finding that Apache::StatINC was not working as expected (i.e., we needed to restart the web server in order to see our module changes in effect.) Our apache config files preload all necessary modules at start time using the 'PerlModule' directive. When I started peeking through Apache::Status I found that although all of our loaded modules appear in the Inheritance Tree and the ISA Tree, most of them did not appear in the Loaded Modules section. (I also did a test handler with a dump of the contents of %INC, and said modules were missing.) The only modules of ours which DID appear were those which were ALSO called for with 'use' calls by other modules. I just reread your original post... I think I may know what the problem is (maybe). Are you using Location handlers? Location /whatever SetHandler perl-script PerlModule My::Special::Module PerlHandler My::Special::Module /Location If that is the case, My::Special::Module won't be loaded and compiled until the very first time that someone hits /whatever. This explains the missing modules in %INC (I think), but it does not explain the problem with Apache::StatINC. Out of curiosity, I took our configuration file and changed all the 'PerlModule' directives to 'use' calls (inside a Perl block), and lo and behold, they all appeared in %INC. And did this fix your problem with Apache::StatINC too? Rob -- Only two things are infinite: The universe, and human stupidity. And I'm not sure about the former. --Albert Einstein
Re: PerlModule not updating %INC
At 18.02 -0500 11/20/2001, Robert Landrum wrote: At 2:31 PM -0800 11/20/01, David Pisoni wrote: We have been doing development using mod_perl, but finding that Apache::StatINC was not working as expected (i.e., we needed to restart the web server in order to see our module changes in effect.) Our apache config files preload all necessary modules at start time using the 'PerlModule' directive. When I started peeking through Apache::Status I found that although all of our loaded modules appear in the Inheritance Tree and the ISA Tree, most of them did not appear in the Loaded Modules section. (I also did a test handler with a dump of the contents of %INC, and said modules were missing.) The only modules of ours which DID appear were those which were ALSO called for with 'use' calls by other modules. I just reread your original post... I think I may know what the problem is (maybe). Are you using Location handlers? Location /whatever SetHandler perl-script PerlModule My::Special::Module PerlHandler My::Special::Module /Location If that is the case, My::Special::Module won't be loaded and compiled until the very first time that someone hits /whatever. Just about EVERY module we use has a 'PerlModule' call to it, outside any enclosing blocks. Although I do have 'PerlHandler' directives in Location and Files blocks, the modules they use are preloaded prior to the enclosing block. We're hip to shared memory :-) This explains the missing modules in %INC (I think), but it does not explain the problem with Apache::StatINC. Out of curiosity, I took our configuration file and changed all the 'PerlModule' directives to 'use' calls (inside a Perl block), and lo and behold, they all appeared in %INC. And did this fix your problem with Apache::StatINC too? Rob Yes. StatINC indeed uses %INC to do its magic. StatINC's success or failure in this situation is merely a symptom though, not the real problem. We could simply set our configuration files as I've described here, but I'm interested in mod_perl working correctly for everyone, hence I continue to beat this drum. :-) I don't assume that the problem is unique to us -- rather I assume that we're the only ones experiencing it who both realize it and are doing something about it. Thanks, David
Re: PerlModule not updating %INC
If that is the case, My::Special::Module won't be loaded and compiled until the very first time that someone hits /whatever. Just about EVERY module we use has a 'PerlModule' call to it, outside any enclosing blocks. Although I do have 'PerlHandler' directives in Location and Files blocks, the modules they use are preloaded prior to the enclosing block. We're hip to shared memory :-) It just hit me That is why Apache::StatINC isn't working. We use Apache::StatINC on our development server, but we never preload any modules... We just use Location /whatever SetHandler perl-script PerlHandler My::Special::Module /Location and Apache::StatINC works. If you preload, It's not going to put the module into %INC. Otherwise Apache::StatINC would intentionally overwrite that shared memory and destroy the purpose for using PerlModule in the first place. I could be wrong... but I think that the answer is that It's not a bug, it's a feature, and that the behavior is actually correct. Rob -- Only two things are infinite: The universe, and human stupidity. And I'm not sure about the former. --Albert Einstein
Re: PerlModule not updating %INC
At 18.32 -0500 11/20/2001, Robert Landrum wrote: If that is the case, My::Special::Module won't be loaded and compiled until the very first time that someone hits /whatever. Just about EVERY module we use has a 'PerlModule' call to it, outside any enclosing blocks. Although I do have 'PerlHandler' directives in Location and Files blocks, the modules they use are preloaded prior to the enclosing block. We're hip to shared memory :-) It just hit me That is why Apache::StatINC isn't working. We use Apache::StatINC on our development server, but we never preload any modules... We just use Location /whatever SetHandler perl-script PerlHandler My::Special::Module /Location and Apache::StatINC works. If you preload, It's not going to put the module into %INC. Otherwise Apache::StatINC would intentionally overwrite that shared memory and destroy the purpose for using PerlModule in the first place. If this is true, it is a change from prior behavior. (And a bit distressing.) I for one would not complain of Apache::StatINC dirtying memory pages -- I'm really only concerned with shared memory on a production server, and I wouldn't run StatINC outside of the development environment. Besides, I'm assuming that if I do my trick of calling 'use' in a Perl block (which DOES update %INC) that the module code pages are still shared. What is more distressing though is that StatINC may not be the only consumer of %INC. (e.g., Apache::Status does not report these modules in Loaded Modules) The real trouble is that it is deviating from Doing the Right ThingĀ by perl. I could be wrong... but I think that the answer is that It's not a bug, it's a feature, and that the behavior is actually correct. For the above reasons, I hope you are wrong. :-) But you may be right! David
Re: Documentation patch for mod_perl//win32
On Tue, 20 Nov 2001, Alessandro Forghieri wrote: Greetings. [...] This documentation patch addresses the single thread snafu on Win32. Comments, corrections and additions (even subtractions) welcome. (Also on the hot topic of the day: where in the doc does this fit?) Nice, but please repost it inlined. Otherwise people won't be able to comment on your words. [...] hhh I see - attachment stripping. So here it comes - brace. That's great that you thought this out and put it together; a few comments below appear below ... -SNIP---SNIP---SNIP---(sigh, the good ole days) =head1 OS caveats: multithreading on Windows NT =head2 The problem mod_Perl's multithreading capability is severely limited on Win32 platforms (WinNT and Win2K). It is in fact limited to the point of non-existence: mod_perl on Win32 is single threaded. A single instance of the interpreter is created, and it is protected with a server-wide lock, that prevents more than one thread to be using the interpreter at any one time. It is actually a little worse than that, as not only does the interpreter lock prevents parallel processing of perl requests, it also prevents Bany request to proceed (yes, this means that static content requests will also be blocked). This rather unfortunate situation is supposed to change when Apache 2.0 and mod_perl 2.0 will be officially released: in the 2 series, with full multithreading support, apache will be managing an interpreter pool whose dimensions (among other parameter) will be tunable, as documented in http://perl.apache.org/~dougm/modperl_2.0.html The above, and a couple places below, come off to me as being quite down on Win32 mod_perl, especially as an introduction. Although in general one shouldn't generalize, I think it's fair to say that many mod_perl Win32 users use it for exploration and/or development, and this intro might raise needless concern. What about the following: =head2 The problem On Win32, mod_perl is effectively single threaded. What this means is that a single instance of the interpreter is created, and this is then protected by a server-wide lock that prevents more than one thread from using the interpreter at any one time. The fact that this will prevent parallel processing of requests, including static requests, can have serious implications for production servers that often must handle concurrent or long-running requests. This situation will change with Apache/mod_perl 2.0, which is based on a multi-process/multi-thread approach using a native Win32 threads implementation. See http://perl.apache.org/~dougm/modperl_2.0.html for details. The 2.0 release is still some time away unfortunately, which means that users of 1.3.x are stuck in single threaded world. For those affected, it's probably a good idea to be a bit more specific; how about *** At the time of writing, Apache-2.0 is in a beta stage of development. mod_perl-2.0 is being actively developed, including the Win32 port; if you would like a preview and/or would like to contribute to the development process, see the documents on obtaining mod_perl-2.0 by cvs. *** =head2 Does it really matter? How serious is this? For some people and application classes it may be a non-problem, assuming the static material issue is handled differently. It's also not a problem for low traffic sites and for people using Win32 for single-user development ... If your application is CPU bound, and all requests take roughly the same time to complete, then having more processing thread than processors (CPUs) will actually slow things down, because of the context switching overhead. Note that even in this case, the current state of mod_perl will bar owners of multiprocessor Win32 machines from gaining a load balancing advantage from their superior hardware. On the other hand, applications dealing with a large service times spread - say ranging from fractions of a second to a minute and above - stand to lose a great deal of responsiveness from being single threaded. The reason is that short requests that happen to be queued after long ones will be delayed for the entire duration of the jobs that precede them in the queue; with multitasking they would get a chance to complete much earlier. As a real life example, think a manufacturing application where, most of the time, users are navigating a Bill Of Material - a hierarchical structure. The requests generated by this usage pattern have a rather short service time, when moving from a component (node) of the BOM to one of its children or siblings. Now and then, however, a new Bill Of Material is requested, an operation that may require up to 25 seconds to
PerlSendHeader
I need mod_perl to not send the Content-type header when a program is run. Despite the Off value of the PerlSendHeader variable in httpd.conf, the header is still being sent. This test program still sends an extraneous Content-type header: print Content-type: text/html\n\n; print h1Hello World/h1\n; Here's the relevant portion of the httpd.conf: # mod_perl initialization PerlRequire /usr/local/apache-dev/ultraform-lib/startup.pl PerlModule Apache::DBI DBD::mysql #PerlSetEnv key value PerlTaintCheck Off PerlWarn On PerlFreshRestart On PerlSetVar UndefOnReload On PerlSendHeader Off Directory /usr/local/apache-dev/cgi-bin AllowOverride None Options ExecCGI Order allow,deny Allow from all SetHandler perl-script PerlHandler Apache::Registry PerlSendHeader Off /Directory -- Gregor Mosheh, B.S. http://www.blackangel.net/ As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. -- Benjamin Franklin
[OT] Re: How to create a browser popup window
On Tue, 20 Nov 2001, Rob Bloodgood wrote:
You must include code to deal with the fact that you may have already
opened a popup window. Something like this:
That is simply not true. window.open() with a named window ('popupwin', in
your example) ALWAYS reuses that window, on every browser I've ever been
able to test.
I didn't say duplicate windows was the problem. The problems are:
1) If the window exists it may have lost focus.
2) If the window exists you cannot resize it (eg for displaying full-size
images from thumbnails, etc.)
A corrected version of your sample script follows. It's much simpler now...
So simple it only does half of what it did :)
/THREAD ?
- nick
Re: PerlSendHeader
Thanks, Tom. Yep, this does the job just fine and allows me to send
the Content-type later:
print HTTP/1.1 OK\n;
Is ignoring PerlSendHeader considered a feature? ;)
-gm
On Tue, 20 Nov 2001, Tom Mornini wrote:
This took me a LONG time to deal with when I was new to mod_perl...
Apache::Registry tries to be smart regardless of PerlSendHeader.
If it doesn't see HTTP/1.x OK first, out come the headers.
Two options:
$r-response(200);
$r-send_http_header('text/html')
or print the HTTP line...
On Tuesday, November 20, 2001, at 04:17 PM, Gregor Mosheh wrote:
I need mod_perl to not send the Content-type header when a program is
run. Despite the Off value of the PerlSendHeader variable in
httpd.conf, the header is still being sent.
This test program still sends an extraneous Content-type header:
print Content-type: text/html\n\n;
print h1Hello World/h1\n;
Here's the relevant portion of the httpd.conf:
# mod_perl initialization
PerlRequire /usr/local/apache-dev/ultraform-lib/startup.pl
PerlModule Apache::DBI DBD::mysql
#PerlSetEnv key value
PerlTaintCheck Off
PerlWarn On
PerlFreshRestart On
PerlSetVar UndefOnReload On
PerlSendHeader Off
Directory /usr/local/apache-dev/cgi-bin
AllowOverride None
Options ExecCGI
Order allow,deny
Allow from all
SetHandler perl-script
PerlHandler Apache::Registry
PerlSendHeader Off
/Directory
--
Gregor Mosheh, B.S. http://www.blackangel.net/
As we enjoy great advantages from inventions of others, we
should be glad of an opportunity to serve others by any
invention of ours; and this we should do freely and generously.
-- Benjamin Franklin
--
-- Tom Mornini
-- InfoMania Printing Prepress
--
Gregor Mosheh, B.S. http://www.blackangel.net/
As we enjoy great advantages from inventions of others, we
should be glad of an opportunity to serve others by any
invention of ours; and this we should do freely and generously.
-- Benjamin Franklin
[ANNOUNCE] Apache::ASP v2.29
Hey,
Apache::ASP v2.29 has been released, CHANGES below, and you can
get it in your local CPAN, or:
http://www.perl.com/CPAN-local/modules/by-module/Apache/
There are some major bugs fixed in this release, that stem
from new work in the 2.25 release. These bugs are about empty
$Sessions not getting garbage collected POST requests over
fast LAN connections sometimes returning an empty web response
of 0 bytes.
There were other optimizations, features bugfixes this
release. Some big features are XML::LibXSLT support for
XSLT rendering and support for running under PerlTaintCheck On
security config.
--Josh
_
Joshua Chamas Chamas Enterprises Inc.
NodeWorks Founder Huntington Beach, CA USA
http://www.nodeworks.com1-714-625-4051
CHANGES:
+Added some extra help text to the ./cgi/asp --help message
to clarify how to pass arguments to a script from the command line.
+When using $Server-Mail() API, if Content-Type header is set,
and MIME-Version is not, then a MIME-Version: 1.0 header will be sent
for the email. This is correct according to RFC 1521 which specifies
for the first time the Content-Type: header for email documents.
Thanks to Philip Mak for pointing out this correct behavior.
+Made dependent on MLDBM::Sync version .25 to pass the taint_check.t test
+Improved server_mail.t test to work with mail servers were relaying is denied
+Added htmlbody tags to MailErrorsTo email
--Fixed SessionCount / Session_OnEnd bug, where these things were not
working for $Sessions that never had anything written to them.
This bug was introduced in 2.23/2.25 release.
There was an optimization in 2.23/2.25 where a $Session that was never
used does not write its state lock file dbm files to disk, only if
it gets written too like $Session-{MARK}++. Tracking of these NULL $Sessions
then is handled solely in the internal database. For $Session garbage
collection though which would fire Session_OnEnd events and update
SessionCount, the Apache::ASP::State-GroupMembers() function was just
looking for state files on disk ... now it looks in the internal database
too for SessionID records for garbage collection.
Added a test at ./t/session_events.t for these things.
+Some optimizations for $Session API use.
+Added support for XSLT via XML::LibXSLT, patch courtesy of Michael Buschauer
-Got rid of an warning when recompiling changing includes under perl 5.6.1...
undef($code) method did not work for this perl version, rather undef($code) does.
Stopped using using Apache::Symbol for this when available.
-Make Apache::ASP script run under perl taint checking -T for perl 5.6.1...
$code =~ tr///; does not work to untaint here, so much use the slower:
$code =~ /^(.*)$/s; $code = $1; method to untaint.
-Check for inline includes changing, included in a dynamic included
loaded at runtime via $Response-Include(). Added test case for
this at t/include_change.t. If an inline include of a dynamic include
changes, the dynamic include should get recompiled now.
-Make OK to use again with PerlTaintCheck On, with MLDBM::Sync 2.25.
Fixed in ASP.pm, t/global.asa, and created new t/taint_check.t test script
+Load more modules when Apache::ASP is loaded so parent will share more
with children httpd:
Apache::Symbol
Devel::Symdump
Config
lib
MLDBM::Sync::SDBM_File
+When FileUploadMax bytes is exceeded for a file upload, there will not
be an odd error anymore resulting from $CGI::POST_MAX being triggered,
instead the file upload input will simply be ignored via $CGI::DISABLE_UPLOADS.
This gives the developer the opportunity to tell the user the the file upload
was too big, as demonstrated by the ./site/eg/file_upload.asp example.
To not let the web client POST a lot of data to your scripts as a form
of a denial of service attack use the apache config LimitRequestBody for the
max limits. You can think of PerlSetVar FileUploadMax as a soft limit, and
apache's LimitRequestBody as a hard limit.
--Under certain circumstances with file upload, it seems that IsClientConnected()
would return an aborted client value from $r-connection-aborted, so
the buffer output data would not be flushed to the client, and
the HTML page would return to the browser empty. This would be under
normal file upload use. One work-around was to make sure to initialize
the $Request object before $Response-IsClientConnected is called,
then $r-connection-aborted returns the right value.
This problem was probably introduced with IsClientConnected() code changes
starting in the 2.25 release.
ANNOUNCE: Apache::SessionX 2.00b3
The URL ftp://ftp.dev.ecos.de/pub/perl/session/Apache-SessionX-2.00b3.tar.gz has entered CPAN as file: $CPAN/authors/id/G/GR/GRICHTER/Apache-SessionX-2.00b3.tar.gz size: 11701 bytes md5: c3998900a065c1f7a87c40bcf6169ef1 Apache::SessionX extents Apache::Session. It was initialy written to use Apache::Session from inside of HTML::Embperl, but is seems to be usefull outside of Embperl as well, so here is it as standalone module. Apache::Session is a persistence framework which is particularly useful for tracking session data between httpd requests. Apache::Session is designed to work with Apache and mod_perl, but it should work under CGI and other web servers, and it also works outside of a web server alltogether. Addtionaly to Apache::Session, Apache::SessionX provides the following possibilites: - Configuration: Makefile.PL checks which componemnts are installed on the system and interactivly builds a set of configuration, including a default one. This configurations are saved and can be used by name later on. The default configuration is used, if no parameters are given to Apache::SessionX. This simplifies the configuration and usage. - Lazy operation: Apache::SessionX supports lazy operation, that means that the actual data access only takes place if the session data is needed, so you are able to setup the session object, without worrying about performance in case you don't access the session data. - Specifing the ID: Apache::SessionX can use a given ID instead of creating it's own one. You can also give an string which is used to generate the ID - Genrate unique ID: Apache::SessionX is able to save the session with an new ID every time data is modified. This make it possible to keep an history. - Addtionaly methods are provided to get the ID, the inital ID, the modified status and to close a session, without destroying the session object itself. Additional features like session expiration are planned. Enjoy Gerald - Gerald Richterecos electronic communication services gmbh Internetconnect * Webserver/-design/-datenbanken * Consulting Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925131 WWW:http://www.ecos.de Fax: +49 6133 925152 -
ANNOUNCE: Embperl 2.0b4
The URL
ftp://ftp.dev.ecos.de/pub/perl/embperl/HTML-Embperl-2.0b4.tar.gz
has entered CPAN as
file: $CPAN/authors/id/G/GR/GRICHTER/HTML-Embperl-2.0b4.tar.gz
size: 507965 bytes
md5: 03f8ca074b7588fa11ecb8002d4b50bd
Main new feature since 2.0b3 is the beginning support for XML, namely using
libxslt or Xalan to do XSLT transformations and the implementing of recipes,
which allows you to tell Embperl how to cook the result of a request by
pluging modules which provides different transformations together. Together
with the recipe handling the cacheing architecture has been enhanced to
properly support recipes and not only be able to cache resulting pages, but
any intermediate state.
NOTE: Embperl now use Apache::SessionX per default, see below how you can
use it with your old session config
Embperl is a system for building dynamic websites with Perl.
It gives you the power to embed Perl code in your HTML documents
and the ability to build your Web site out of small reusable objects in
an object-oriented style. You can also take advantage of all the
usual Perl modules, (including DBI for database access) use their
functionality and easily include their output in your web pages.
Embperl has several features which are especially useful for creating
HTML, including dynamic tables, form field processing, URL
escaping/unescaping, session handling, and more.
With 2.0 this feature are extented to use XML/XSLT, extent the Embperl's
syntax, build taglibs, cacheing and more.
See http://perl.apache.org/embperl/ (english) or
http://www.ecos.de/embperl/ (german) for more information.
For a list of all changes since 2.0b3 see the end of the mail.
For all Embperl 1.x users here is a sumary of the difference of Embperl 2.0:
Hints for using Embperl 2.x
---
Debugging
-
Starting with 2.0b2 Embperl files can debugged via the interavtive debugger.
The debugger shows the Embperl page source along with the correct
linenumbers.
You can do anything you can do inside a normal Perl programm via the
debugger,
e.g. show variables, modify variables, single step, set breakpoints etc.
You can use the Perl interacive command line debugger via
perl -d embpexec.pl file.epl
or if you prefer a graphical debugger, try ddd
(http://www.gnu.org/software/ddd/)
it's a great tool, also for debugging any other perl script:
ddd --debugger 'perl -d embpexec.pl file.epl'
NOTE: embpexec.pl could be found in the Embperl source directory
If you want to debug your pages, while running under mod_perl, Apache::DB is
the
right thing. Apache::DB is available from CPAN.
The following difference to Embperl 1.x apply:
--
- The following options can currently only set from the httpd.conf:
optRawInput, optKeepSpaces
- The following options are currently not supported:
optDisableHtmlScan, optDisableTableScan,
optDisableInputScan, optDisableMetaScan
optDisableHtmlScan can be replaced by switching the syntax e.g.
[$syntax EmbperlBlocks $] # same as [- $optDisableHtmlScan = 1 -]
here goes your code, Embperl will not interpret any html tags here
[$syntax Embperl $]# same as [- $optDisableHtmlScan = 0 -]
- Nesting must be properly. I.e. you cannot put a table tag (for an
dynamic table) inside an if and the /table inside another if.
(That still works for static tables)
- optUndefToEmptyValue is always set and cannot be disabled.
- [$ foreach $x (@x) $] requires now the brackets around the
array (like Perl)
- [+ +] blocks must now contain a valid Perl expression. Embperl 1.x
allows you to put multiple statements into such a block. For performance
reasons this is not possible anymore. Also the expression must _not_
terminated with a semikolon. To let old code work, just wrap it into a do
e.g. [+ do { my $a = $b + 5 ; $a } +]
The following things are not fully tested/working yet:
--
- [- exit -]
- safe namespaces
- print to OUT does not work correctly inside of loops
Embperl 1.x compatibility flag
--
If you don't have a separate computer to make the test setup, you can
include
PerlSetEnv EMBPERL_EP1COMPAT 1
at the top level of your httpd.conf, then Embperl will behave just the same
like Embperl 1.3b7. In the directories where you make your tests, you
include a
PerlSetEnv EMBPERL_EP1COMPAT 0
to enable the new engine.
but _DON'T_ use this one a production machine. While this compatibility mode
is tested and shows no problems for me, it's not so hard tested as 1.3b7
itself!
Addtional Config directives
---
Caching parameter
-
execute parameter / httpd.conf environment variable / name inside page (must
set inside [! !])
cache_key / EMBPERL_CACHE_KEY / $CACHE_KEY
literal string that is appended to the cache key
cache_key_options / EMBPERL_CACHE_KEY_OPTIONS /
cvs commit: modperl-2.0/lib/ModPerl BuildOptions.pm
dougm 01/11/20 18:13:00 Modified:lib/ModPerl BuildOptions.pm Log: add missing LIBNAME option to the table Revision ChangesPath 1.12 +1 -0 modperl-2.0/lib/ModPerl/BuildOptions.pm Index: BuildOptions.pm === RCS file: /home/cvs/modperl-2.0/lib/ModPerl/BuildOptions.pm,v retrieving revision 1.11 retrieving revision 1.12 diff -u -r1.11 -r1.12 --- BuildOptions.pm 2001/10/20 18:59:28 1.11 +++ BuildOptions.pm 2001/11/21 02:13:00 1.12 @@ -164,3 +164,4 @@ XS_GLUE_DIR Directories containing extension glue INCLUDE_DIR Add directories to search for header files GENERATE_XS Generate XS code based on httpd version +LIBNAME Name of the modperl dso library (default is libmodperl)
cvs commit: modperl-2.0/lib/Apache Build.pm
stas01/11/20 18:35:33
Modified:lib/Apache Build.pm
Log:
- add the rebuild() function that allows to reuse the build opts to build
a new mod_perl
Revision ChangesPath
1.73 +26 -0 modperl-2.0/lib/Apache/Build.pm
Index: Build.pm
===
RCS file: /home/cvs/modperl-2.0/lib/Apache/Build.pm,v
retrieving revision 1.72
retrieving revision 1.73
diff -u -r1.72 -r1.73
--- Build.pm 2001/11/02 17:59:05 1.72
+++ Build.pm 2001/11/21 02:35:33 1.73
@@ -455,6 +455,16 @@
close $fh or die failed to write $file: $!;
}
+sub rebuild {
+my $self = __PACKAGE__-build_config;
+my @opts = map { qq[$_='$self-{$_}'] } sort grep /^MP_/, keys %$self;
+my $command = perl Makefile.PL @opts;
+print Running: $command\n;
+system $command;
+}
+# % perl -MApache::Build -erebuild
+*main::rebuild = \rebuild if $0 eq '-e';
+
#--- attribute access ---
sub is_dynamic {
@@ -1028,10 +1038,26 @@
use Apache::Build ();
my $build = Apache::Build-new;
+ # rebuild mod_perl with build opts from the previous build
+ % cd modperl-2.0
+ % perl -MApache::Build -erebuild
+
=head1 DESCRIPTION
This module provides methods for locating and parsing bits of Apache
source code.
+
+Since mod_perl remembers what build options were used to build it, you
+can use this knowledge to rebuild it using the same options. Simply
+chdir to the mod_perl source directory and run:
+
+ % cd modperl-2.0
+ % perl -MApache::Build -erebuild
+
+If you want to rebuild not yet installed, but already built mod_perl,
+run from its root directory:
+
+ % perl -Ilib -MApache::Build -erebuild
=head1 METHODS
cvs commit: modperl-2.0 Makefile.PL
stas01/11/20 18:39:45
Modified:.Makefile.PL
Log:
s/generate_xs/xs_generate/ to be consistent with make target and
build/xs_generate.pl
Revision ChangesPath
1.54 +2 -2 modperl-2.0/Makefile.PL
Index: Makefile.PL
===
RCS file: /home/cvs/modperl-2.0/Makefile.PL,v
retrieving revision 1.53
retrieving revision 1.54
diff -u -r1.53 -r1.54
--- Makefile.PL 2001/11/02 17:59:05 1.53
+++ Makefile.PL 2001/11/21 02:39:45 1.54
@@ -113,7 +113,7 @@
if ($build-{MP_GENERATE_XS}) {
print generating XS code using $tables_dir...\n;
-generate_xs($httpd_version);
+xs_generate($httpd_version);
}
}
@@ -148,7 +148,7 @@
my $tables_dir = xs/tables/$tables_version;
}
-sub generate_xs {
+sub xs_generate {
require ModPerl::WrapXS;
my $xs = ModPerl::WrapXS-new;
