Re: clones and parents (bug report)
Randy Kobes wrote: [..] Just to verify, I also get this with ActivePerl 806, Apache/2.0.47, and the current mod_perl cvs version. Here's some partial debug information: PERL58! 28083490() PERL58! 280648b5() and what are these two perl calls? modperl_perl_destruct(interpreter * 0x0089c794): line 130 + 9 bytes: modperl_perl.c Perhaps the interpreter struct is corrupt? modperl_interp_destroy(modperl_interp_t * 0x008a47c8): line 128 + 12 bytes: modperl_interp.c modperl_interp_pool_destroy(void * 0x00869b78): line 184 + 12 bytes: modperl_interp.c run_cleanups(cleanup_t * * 0x0089a7a8): line 1980: httpd-2.0.47\srclib\apr\memory\unix\apr_pools.c apr_pool_destroy(apr_pool_t * 0x00401585): line 758: httpd-2.0.47\srclib\apr\memory\unix\apr_pools.c main(int 0x00401d82, const char * const * 0x0001) line 619 APACHE! mainCRTStartup + 227 bytes KERNEL32! 77e7eb69() === -- __ 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: does pnotes() work at all in 1.27?
James Hartling wrote: I use pnotes all over the place in 1.27, and haven't noticed any problems. I just stepped through some code and everything looks good between the Init phase and the content handling phase. I'm using Apache::Request-instance everywhere so I'm dealing with the same request object, but even if you're using Apache::Request-new I'd still expect that to work. Apache::Request-instance is probably the magic pill for Mark ;) __ 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: DDD and mod_perl handler
Pablo Velasquez wrote:
Hello,
I've been searching for guidance on using DDD with mod_perl. (DDD is
fantastic)
[...]
I've been reading online for the answer and there are some hints:
Debugging mod_perl C Internals
http://perl.apache.org/docs/2.0/devel/debug/c.html
This document explains how to debug C internals, not perl.
I've done some googling and found a post from Gerald answering a similar
question for embperl. To debug mod_perl handlers under ddd, you need to
configure Apache::DB normally, and next instead of starting httpd -x, you need
to do:
ddd --debugger '/home/httpd/httpd_perl/bin/httpd -f
/home/httpd/httpd_perl/conf/httpd.conf -X -DPERLDB' --perl
(adjust the paths)
Now when you issue a request ddd will give you an interactive shell, just like
you get with perl -d. It won't open the source file for you, since it doesn't
know what that source file is. You have to open it manually via menu item
'Open Source' and finish the first execution in the interactive shell window.
Only on the next request you will be able to step through with the source window.
Moreover you won't be able to step through using the source window for
registry scripts. This is because registry scripts aren't executed as files,
but evaled as a string.
Here is an example:
httpd.conf:
IfDefine PERLDB
Perl
use Apache::DB ();
Apache::DB-init;
/Perl
Location /
PerlFixupHandler Apache::DB
#PerlFixupHandler Apache::SmallProf
/Location
/IfDefine
Location /hello-world
SetHandler perl-script
PerlHandler Apache::HelloWorld
/Location
#file:Apache/HelloWorld.pm
package Apache::HelloWorld;
use strict;
sub handler {
my $r = shift;
$r-send_http_header('text/plain');
print Hello ;
print world\n
return 0;
}
1;
1) start ddd:
ddd --debugger '/home/httpd/httpd_perl/bin/httpd -f
/home/httpd/httpd_perl/conf/httpd.conf -X -DPERLDB' --perl
2) using the menu 'open source' for Apache/HelloWorld.pm.
3) issue a request:
lynx --dump http://localhost:8000/hello-world
using the DDD commands menu do 'finish' (sometimes twice). At this point all
the output will go to the interactive shell console and not the client.
4) issue the request second time (this time in browser if wanted):
lynx --dump http://localhost:8000/hello-world
now you can step through the source code with ddd's commands menu, and even
look at the contents of the variables in the 'Data' window.
The pain is that you have to manually open the source file. If you can find
how to make it programmatically please share with us.
__
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: does pnotes() work at all in 1.27?
Hi Stas, Thanks for the input. Tried that and no luck. I tried using -instance() instead of -new() in both handlers, and it didn't work. Just for kicks I tried using a few combinations of new() and instance() and no go there either. I also checked that I had the main request using is_main just to be safe after retreiving the existing Apache::Request instance. I'm going to upgrade to 1.28 in a coupla days so hopefully that'll solve it. wierd that noone seems to have reported this. The server I'm using is a stock RH 8.0 server - I dont run redcarpet or anything like that, and I've only upgraded the minimum to keep it secure. I'm no C developer, just a perl geek, but I was wondering where pnotes() stores it's data. In an Apache::Table object? Is there a way for me to manually access the store somehow at various phases to figure out where the data gets deleted? Any suggestions would help. Mark. On Fri, 2003-07-18 at 23:40, Stas Bekman wrote: James Hartling wrote: I use pnotes all over the place in 1.27, and haven't noticed any problems. I just stepped through some code and everything looks good between the Init phase and the content handling phase. I'm using Apache::Request-instance everywhere so I'm dealing with the same request object, but even if you're using Apache::Request-new I'd still expect that to work. Apache::Request-instance is probably the magic pill for Mark ;) __ 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 -- Mark Maunder [EMAIL PROTECTED] ZipTree Inc.
RE: templating system opinions
Hey Ken -- Search the guide: http://perl.apache.org/search/swish.cgi?query=templatesbm=submit=sear ch I'm deeply amused that there are nearly as many articles about templating systems on perl.apache.org (30) as there are templating modules on CPAN! TTYL, -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226
Re: [mp2 Patch] BUG with mod_deflate and $|=1 (20014:Error string not specified)
May I see your client side HTTP log of the request-response transaction through mod_cgi vs. mod_perl? Thanks, Slava - Original Message - From: Bill Marrs [EMAIL PROTECTED] To: Slava Bizyayev [EMAIL PROTECTED]; Stas Bekman [EMAIL PROTECTED]; Philippe M. Chiasson [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Saturday, July 19, 2003 7:01 AM Subject: Re: [mp2 Patch] BUG with mod_deflate and $|=1 (20014:Error string not specified) At 07:16 PM 7/18/2003, Slava Bizyayev wrote: In my understanding _it is_ a problem of mod_deflate. The error does not occur if I run the same test script under mod_cgi instead of mod_perl. This suggests that the problem is in mod_perl not mod_deflate. right?
Re: Getting list of all cookies available?
Is there a way to get the list of available cookies from Apache::ASP
or mod_perl?
Now I am not the most expert at mod_perl, still a newbie myself
Here's how i have done i when i needed to see the whole list to find out what was
going on with a cookie not working
use Apache::Cookie;
my %allcookies = Apache::Cookie-fetch;
This will give you all the cookies the browser sends for the URL.
You can get the list through 'keys %allcookies', test for the presence of a cookie
with 'exists $allcookies{'somestring'}'
Apache::Cookie comes with Apache::Request in libapreq, if i recall correctly (someone
will correct me if i am wrong)
-- Iphigenie, [EMAIL PROTECTED] on 19/07/2003
RE: templating system opinions
Hi Patrick -- I gotta have something to counter PHP people with too ;) Dave is right: CPAN is a very compelling argument. OTOH, it you've already cast your lot with using a server page system (a la Mason, ASP, JSP, ColdFusion), PHP is a pretty compelling choice. It's new, sexy, lightweight, more or less capable, and has lots of buzz. However: Another compelling argument in favor of Perl (against PHP) is an argument in favor of using an controller-based system instead of a server page system. A controller-based system (such as CGI::Application or mod_perl handlers) combined with a true templating system, such as TT or HTML::Template, makes the templates subservient to the application logic. This is the opposite of server page systems which put the template in change of choosing functionality. In the latter, an HTTP request goes to a template which controls execution. If the template in this system decides that a different template should be displayed, chaos erupts -- redirect city, snarls of spaghetti code. In a controller-based system, the HTTP request goes to a controller which runs the logic and then chooses a template. This is a more rational chain of events, allowing the form to *follow* function -- literally. The controller can naturally choose which template without having to twist itself in a pretzel to do so. Add to that the fact that in spite of the claim that it is possible to separate code from HTML in a server page system, in reality it is too difficult and nobody does it. OTOH, if you can't fight the PHP wave, here's an alternative: Offer to prototype the system in Perl, and migrate it to PHP! It so happens that a fellow named Tomas Styblo ([EMAIL PROTECTED]) wrote a version of HTML::Template for PHP: http://htmltmpl.sourceforge.net/ This means that you could quickly, and cheaply get a system up and running with Perl and HTML::Template, and migrate it eventually to PHP. (If the prototype happens to be so good that it takes the wind out of the sails of migration, so be it.) TTYL, -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226
Re: templating system opinions - Mason recommendation
Stas == Stas Bekman [EMAIL PROTECTED] writes: Stas While Andy is working on it, you can read a TT for mod_perl chapter in Stas Practical mod_perl, written by Andy as well! (http://modperlbook.org) Man, that guy is *everywhere*! :-) -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: templating system opinions
Jesse Erlbaum wrote: The big players are Template::Toolkit and HTML::Template. It's no secret that I'm a fan of HTML::Template -- Sam and I worked together when he wrote it, and my module, CGI::Application, uses it out of the box (although it does support TT). I use HTML::Template because designers can't be trusted to set variables. Boolean logic is about all their simple minds can handle. Anything which doesn't look like HTML is likely to cause them to have a stroke. Yes, I'm a programmer-snob and a fascist, and I like to take sharp objects away from the gentle creative types. Aside from the fact that HTML::Template uses less RAM and is faster than TT, this is the foremost reason I continue to use it. I used to use HTML::Template for projects, but I moved to Template::Toolkit because I felt the former's syntax was just too limited. I know we want to separate code and logic, but H::T keeps me from even referencing the attribute of an object. You can't say TMPL_VAR NAME=user.name and pass in a user object with the attribute (method) or even a hash key called name. You have to either treating it like a loop with one item (because loops use arrayrefs of hashrefs) or flatten it into variable names in your code. In a good OO system with objects representing the data model, I found it exhausting to use H::T when I could just to this in TT: [% user.name %] Am I just being stupid, or are there better ways of doing these things in H::T? -- Barry Hoggard Tristan Media LLC e: [EMAIL PROTECTED] w: www.tristanmedia.com aim: hoggardb
Re: IPC::Run
On Fri, Jul 18, 2003 at 02:33:11PM -0400, Barrie Slaymaker wrote: On Fri, Jul 18, 2003 at 01:18:12PM -0500, Cameron B. Prince wrote: Hi Barrie, I dug out an old note from you and started trying IPC::Run. Here's what I have so far: [...] I'd do a use BFD; [EMAIL PROTECTED]; Years ago, I wrote System2 to also run commands in the background specifically to avoid lots of 'sh' invokations, and gather input. No 'timeout' feature, but I still use it regularly. May be useful... Check CPAN... - Barrie -- Brian 'you Bastard' Reichert[EMAIL PROTECTED] 37 Crystal Ave. #303Daytime number: (603) 434-6842 Derry NH 03038-1713 USA BSD admin/developer at large
Re: Content compression FAQ
Thanks Stas! Full POD file is available now at http://devl4.outlook.net/devdoc/FAQ/compression.pod Slava - Original Message - From: Stas Bekman [EMAIL PROTECTED] Sent: Monday, July 14, 2003 12:42 AM Subject: Re: Content compression FAQ Great work, Slava. Please send the diff (or probably just the whole thing), or the URL where we can download it from and we'll update http://perl.apache.org/docs/tutorials/client/compression/compression.html
Re: does pnotes() work at all in 1.27?
Hi. This is a rather comprehensive (read 'cathartic') message, so if you
have something productive to go and do, then you'd probably be better
off doing that. For all other interested parties, read on
I've done a few more tests and isolated this to my production server
only. pnotes() works fine on my workstation. And the problems described
below apply to notes() too. So it's something to do with my
apache/mod_perl installation. Take a look at this:
I've cut down the production server to a bare bones httpd.conf with the
following virtual hosts section:
VirtualHost *
DocumentRoot /home/mark/lib
ServerName localhost
Location /
PerlFixupHandler Handler1
PerlHandler Handler2
PerlLogHandler Handler3
/Location
/Virtualhost
my startup.pl looks like this:
#!/usr/bin/perl
require '/home/mark/lib/Test.pl';
1;
And Test.pl looks like this:
package Handler1;
sub handler {
my $r = shift @_;
$r-pnotes('note1', 'msg1');
warn HANDLER1 says: . $r-pnotes('note1');
return OK;
}
package Handler2;
sub handler {
my $r = shift @_;
$r-pnotes('note2', 'msg2');
warn HANDLER2 says: . $r-pnotes('note2');
warn HANDLER2 got: . $r-pnotes('note1');
$r-send_http_header('text/html');
$r-print(Hello World!\n);
return OK;
}
package Handler3;
sub handler {
my $r = shift @_;
warn HANDLER3 got: . $r-pnotes('note1') .
' and ' . $r-pnotes('note2');
return OK;
}
1;
This gives an output in error_log of the following:
HANDLER1 says: msg1 at /home/mark/lib/Test.pl line 5.
HANDLER1 says: msg1 at /home/mark/lib/Test.pl line 5.
HANDLER1 says: msg1 at /home/mark/lib/Test.pl line 5.
HANDLER2 says: msg2 at /home/mark/lib/Test.pl line 12.
HANDLER2 got: msg1 at /home/mark/lib/Test.pl line 13.
HANDLER3 got: msg1 and at /home/mark/lib/Test.pl line 21.
Which shows that pnotes can pass data from the Fixup handler to the
Response handler, but anything the Response handler sets is lost by the
time the Logging handler is called. Although the data that the Fixup
handler sets is still there.
Question: Why is the Fixup handler being called 3 times? If you look at
the sniffer output I've included, you'll see there's a single request
and response. I checked the URI that was being called and it's '/' in
all three cases.
Just to be sure, I added this to Handler2 (the Response handler)
if($r-is_main())
{
$r-print('You are in main');
}
And it prints out the string. So it is the main request.
Here is some more info:
When I did this test, I stripped out everything from httpd.conf (relying
heavily on vim's undo feature because this server will be live in 48
hours, pnotes or no pnotes!).
Here is the output from httpd -l
Compiled-in modules:
http_core.c
mod_env.c
mod_log_config.c
mod_mime.c
mod_negotiation.c
mod_status.c
mod_include.c
mod_autoindex.c
mod_dir.c
mod_cgi.c
mod_asis.c
mod_imap.c
mod_actions.c
mod_userdir.c
mod_alias.c
mod_rewrite.c
mod_access.c
mod_auth.c
mod_proxy.c
mod_headers.c
mod_setenvif.c
mod_gzip.c
mod_perl.c
suexec: disabled; invalid wrapper /usr/local/apache/bin/suexec
Here is the output from httpd -V:
Server version: ZipTree (Unix)
Server built: Jul 8 2003 12:56:03
Server's Module Magic Number: 19990320:13
Server compiled with
-D HAVE_MMAP
-D HAVE_SHMGET
-D USE_SHMGET_SCOREBOARD
-D USE_MMAP_FILES
-D HAVE_FCNTL_SERIALIZED_ACCEPT
-D HAVE_SYSVSEM_SERIALIZED_ACCEPT
-D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
-D HARD_SERVER_LIMIT=256
-D HTTPD_ROOT=/usr/local/apache
-D SUEXEC_BIN=/usr/local/apache/bin/suexec
-D DEFAULT_PIDLOG=logs/httpd.pid
-D DEFAULT_SCOREBOARD=logs/apache_runtime_status
-D DEFAULT_LOCKFILE=logs/accept.lock
-D DEFAULT_ERRORLOG=logs/error_log
-D TYPES_CONFIG_FILE=conf/mime.types
-D SERVER_CONFIG_FILE=conf/httpd.conf
-D ACCESS_CONFIG_FILE=conf/access.conf
-D RESOURCE_CONFIG_FILE=conf/srm.conf
Got a sniffer on the wire too and the output looks like this. The
request is:
GET / HTTP/1.1
Host: testserver
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1)
Gecko/20021003
Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,video/x-mng,image/png,image/jpeg,image/gif;q=0.2,text/css,*/*;q=0.1
Accept-Language: en-us, en;q=0.50
Accept-Encoding: gzip, deflate, compress;q=0.9
Accept-Charset: ISO-8859-1, utf-8;q=0.66, *;q=0.66
Keep-Alive: 300
Connection: keep-alive
Cache-Control: max-age=0
And the response is:
HTTP/1.1 200 OK
Date: Sat, 19 Jul 2003 20:17:05 GMT
Server: ZipTree
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html
1c
Hello World!
You are in main
0
On Sat, 2003-07-19 at 07:34, James Hartling wrote:
I think Mark had tried it without Apache::Request. Also, it was obvious at
some point that he wasn't in a subrequest ($r-is_main returned true, but no
pnote).
Re: Content compression FAQ
Slava Bizyayev wrote: Thanks Stas! Full POD file is available now at http://devl4.outlook.net/devdoc/FAQ/compression.pod Forbidden You don't have permission to access /devdoc/FAQ/compression.pod on this server. Slava - Original Message - From: Stas Bekman [EMAIL PROTECTED] Sent: Monday, July 14, 2003 12:42 AM Subject: Re: Content compression FAQ Great work, Slava. Please send the diff (or probably just the whole thing), or the URL where we can download it from and we'll update http://perl.apache.org/docs/tutorials/client/compression/compression.html -- __ 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: templating system opinions
Jesse Erlbaum wrote: Hey Ken -- Search the guide: http://perl.apache.org/search/swish.cgi?query=templatesbm=submit=sear ch I'm deeply amused that there are nearly as many articles about templating systems on perl.apache.org (30) as there are templating modules on CPAN! The search shows matching sections, not articles. Most of these matches belong to a single tutorial: http://perl.apache.org/docs/tutorials/tmpl/comparison/comparison.html __ 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: Content compression FAQ
Oops, sorry for that. It should be OK now. ;-( Slava - Original Message - From: Stas Bekman [EMAIL PROTECTED] To: Slava Bizyayev [EMAIL PROTECTED] Cc: mod_perl Mailing List [EMAIL PROTECTED] Sent: Saturday, July 19, 2003 3:29 PM Subject: Re: Content compression FAQ Slava Bizyayev wrote: Thanks Stas! Full POD file is available now at http://devl4.outlook.net/devdoc/FAQ/compression.pod Forbidden You don't have permission to access /devdoc/FAQ/compression.pod on this server. Slava - Original Message - From: Stas Bekman [EMAIL PROTECTED] Sent: Monday, July 14, 2003 12:42 AM Subject: Re: Content compression FAQ Great work, Slava. Please send the diff (or probably just the whole thing), or the URL where we can download it from and we'll update http://perl.apache.org/docs/tutorials/client/compression/compression.html -- __ 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
[mp2] BEGIN blocks
I seem to be having some trouble that I think may be associated with BEGIN blocks. To make sure I'm not jumping at shadows, could someone tell me what the expected behavior of BEGIN blocks in use()d modules is? How many times are they called (during server startup and/or restarts of any type) and when? Thanks, Issac
[ANNOUNCE] Apache::App::Mercury (new module)
This is a new application for mod_perl - just released. Apache::App::Mercury is a customizable, extensible customer to customer, store and forward messaging application for Apache mod_perl (1.x). It uses a relational database (accessed via DBI) to store and retrieve messages, and uses CGI.pm to display them in standard HTML. It's design closely resembles a MVC design pattern, and it handles all message box navigation, message composition, sending, replying, etc. In short, it is a complete web (intra server) messaging application for your Apache mod_perl server, which can be customized to fit your specific needs (e.g. private labelling). At the moment, installation has quite a few steps. Sorry about that. I tried to make it as simple and straightforward as possible, but the complexity is necessary since it needs to tie into your existing mod_perl app. Cheers, -Adi -- The URL http://adiraj.org/sw/Apache-App-Mercury/Apache-App-Mercury-0.80.tar.gz has entered CPAN as file: $CPAN/authors/id/A/AD/ADIRAJ/Apache-App-Mercury-0.80.tar.gz size: 38372 bytes md5: 96d5369bf2ad83168ce00829c0102357 No action is required on your part Request entered by: ADIRAJ (Adi Fairbank) Request entered on: Sun, 20 Jul 2003 04:31:15 GMT Request completed: Sun, 20 Jul 2003 04:32:58 GMT
