Problem installing Apache::Request
I got this email address from the README file in libapreq-1.0.tar.gz and I desperately need help to fix a problem that I am having when I try to install Apache::Request. I have sucessfully installed all the mod_perl components, but, every time I try to install Apache::Request I get the following error: apache_request.h:5:19: httpd.h: No such file or directory apache_request.h:6:25: http_config.h: No such file or directory apache_request.h:7:23: http_core.h: No such file or directory apache_request.h:8:22: http_log.h: No such file or directory apache_request.h:8:22: http_log.h: No such file or directory apache_request.h:9:23: http_main.h: No such file or directory apache_request.h:10:27: http_protocol.h: No such file or directory apache_request.h:11:25: util_script.h: No such file or directory apache_request.h:9:23: http_main.h: No such file or directory apache_request.h:10:27: http_protocol.h: No such file or directory apache_request.h:11:25: util_script.h: No such file or directory And the Module will not install. Any help that you may provide would be greatly appreciated. If you are not the correct person to contact can you let me know who I would need to speak with to get this resolved. Thanks. _ Join the worlds largest e-mail service with MSN Hotmail. http://www.hotmail.com
RE: mod_perl training companies?
Title: RE: mod_perl training companies? On that note, does anyone have any reviews of gbdirect.co.uk? Would you recommend them as trainers? Has anyone had courses from them before? Thanks, Michelle -Original Message- From: Stas Bekman [mailto:[EMAIL PROTECTED]] Sent: Monday, March 04, 2002 8:11 PM To: modperl list Subject: mod_perl training companies? I'm compiling a list of companies giving mod_perl training for our new mod_perl site. Currently I have only: http://training.gbdirect.co.uk/courses/linux/customized_and_bespoke.html If you know of other companies please send me the URL of the page advertising the mod_perl courses. Thanks. _ 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: Blank pages
Ged Haywood writes:
> Hi there,
>
> On Fri, 1 Mar 2002, Axel Andersson wrote:
>
>> I run a mod_perl/mysql site, which works fine most of the time. Some
>> pages, however, come out completely blank. Reload.. and hey presto,
> [snip]
>> Well, it's a longshot, but thanks anyway.
>
> Another long shot, do you always specify full paths to files in your code?
>
> If you don't get anywhere with that then I'd suggest looking at the debugging
> section of the Guide: http://prel.apache.org/guide and/or peppering your code
> at strategic places with 'print STDERR "$something_useful\n"' statements.
>
> 73,
> Ged.
>
I have been getting the same problems with the same setup ( Mod_Perl /
MySQL). But I am having a little fun with this setup. I populated a small
table in the 'test' DB in MySQL withe the contents of
'/usr/local/share/dict/propernames'. I then have the script to randomly
chose an id from the DB table and then to select a row of info. I will post
the scipt contents and some debugging data to give some more info on the
internal processes.
The Script is :
1 package DBNE;
2
3 use strict;
4 use vars qw($DBH);
5 use Apache;
6 #use Apache::File;
7 use DBI();
8
9 sub handler {
10 $DBH = DBI->connect("DBI:mysql:test","webuser","mult1scan")
|| die $DBH->errstr;
11 my $r = shift;
12 my $h = $DBH->trace(5,"/tmp/DBI.log");
13
14 $r->send_http_header;
15 my $sth = $DBH->prepare("SELECT MAX(id) FROM webtest");
16 $sth->execute;
17 my ($id) = $sth->fetchrow;
18
19 my $sth = $DBH->prepare("SELECT * FROM webtest WHERE id =
ROUND( (RAND() * $id) + 1)");
20 $sth->execute;
21
22 my ($id,$name,$last,$town) = $sth->fetchrow;
23 $r->print("$id\t\t $name\t\t $last\t\t $town \n");
24 $sth->finish;
25
26 }
27
28 1;
The debuging info is:
<- DESTROY= undef at /home/mcalvo/ModPerl/DBNE.pm line 11
DBI::db=HASH(0x81faf3c) trace level set to 5 in DBI 1.20-nothread
Note: perl is running without the recommended perl -w option
-> prepare for DBD::mysql::db (DBI::db=HASH(0x81e90e4)~0x81faf3c 'SELECT
MAX(id) FROM webtest')
dbih_setup_handle(DBI::st=HASH(0x8156390)=>DBI::st=HASH(0x81e90d8),
DBD::mysql::st, 81faef4, Null!)
dbih_make_com(DBI::db=HASH(0x81faf3c), DBD::mysql::st, 204)
dbih_setup_attrib(DBI::st=HASH(0x81e90d8), Err, DBI::db=HASH(0x81faf3c))
SCALAR(0x818bc78) (already defined)
dbih_setup_attrib(DBI::st=HASH(0x81e90d8), State,
DBI::db=HASH(0x81faf3c)) SCALAR(0x81aef9c) (already defined)
dbih_setup_attrib(DBI::st=HASH(0x81e90d8), Errstr,
DBI::db=HASH(0x81faf3c)) SCALAR(0x818bc54) (already defined)
dbih_setup_attrib(DBI::st=HASH(0x81e90d8), Handlers,
DBI::db=HASH(0x81faf3c)) ARRAY(0x81e90b4) (already defined)
dbih_setup_attrib(DBI::st=HASH(0x81e90d8), Debug,
DBI::db=HASH(0x81faf3c)) 5 (already defined)
dbih_setup_attrib(DBI::st=HASH(0x81e90d8), FetchHashKeyName,
DBI::db=HASH(0x81faf3c)) 'NAME' (already defined)
Setting mysql_use_result to 0
<- prepare= DBI::st=HASH(0x8156390) at /home/mcalvo/ModPerl/DBNE.pm line
15
-> execute for DBD::mysql::st (DBI::st=HASH(0x8156390)~0x81e90d8)
-> dbd_st_execute for 081fac90
<- dbd_st_execute 1 rows
<- execute= 1 at /home/mcalvo/ModPerl/DBNE.pm line 16
-> fetchrow for DBD::mysql::st (DBI::st=HASH(0x8156390)~0x81e90d8)
-> dbd_st_fetch for 081fac90, chopblanks 0
dbih_setup_fbav for 1 fields => 0x8135854
Storing row 0 (1323) in 081fae64
<- dbd_st_fetch, 1 cols
<- fetchrow= ( '1323' ) [1 items] row1 at /home/mcalvo/ModPerl/DBNE.pm
line 17
-> prepare for DBD::mysql::db (DBI::db=HASH(0x81e90e4)~0x81faf3c 'SELECT
* FROM webtest WHERE id = ROUND( (RAND() * 1323) + 1)')
dbih_setup_handle(DBI::st=HASH(0x81faf90)=>DBI::st=HASH(0x81faf24),
DBD::mysql::st, 81faf78, Null!)
dbih_make_com(DBI::db=HASH(0x81faf3c), DBD::mysql::st, 204)
dbih_setup_attrib(DBI::st=HASH(0x81faf24), Err, DBI::db=HASH(0x81faf3c))
SCALAR(0x818bc78) (already defined)
dbih_setup_attrib(DBI::st=HASH(0x81faf24), State,
DBI::db=HASH(0x81faf3c)) SCALAR(0x81aef9c) (already defined)
dbih_setup_attrib(DBI::st=HASH(0x81faf24), Errstr,
DBI::db=HASH(0x81faf3c)) SCALAR(0x818bc54) (already defined)
dbih_setup_attrib(DBI::st=HASH(0x81faf24), Handlers,
DBI::db=HASH(0x81faf3c)) ARRAY(0x81e90b4) (already defined)
dbih_setup_attrib(DBI::st=HASH(0x81faf24), Debug,
DBI::db=HASH(0x81faf3c)) 5 (already defined)
dbih_setup_attrib(DBI::st=HASH(0x81faf24), FetchHashKeyName,
DBI::db=HASH(0x81faf3c)) 'NAME' (already defined)
Setting mysql_use_result to 0
<- prepare= DBI::st=HASH(0x81faf90) at /home/mcalvo/ModPerl/DBNE.pm line
19
-> execute for DBD::mysql::st (DBI::st=HASH(0x81faf90)~0x81faf24)
-> dbd_st_execute for 081e9084
<- dbd_st_execute 0 rows
<- execute= '0E0' at /home/mcalvo/ModPerl/D
mod_perl training companies?
I'm compiling a list of companies giving mod_perl training for our new mod_perl site. Currently I have only: http://training.gbdirect.co.uk/courses/linux/customized_and_bespoke.html If you know of other companies please send me the URL of the page advertising the mod_perl courses. Thanks. _ 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: Apache::DB patch
Enrico Sorcinelli wrote:
> On Fri, 01 Mar 2002 11:16:15 +0800
> Stas Bekman <[EMAIL PROTECTED]> wrote:
>
>
>>Enrico Sorcinelli wrote:
>>
>>>Hi all,
>>>I started to use Apache::DB (0.06) to interactively debug under mod_perl using
>ptkdb. I see that is necessary to modify Apache/DB.pm but, after this, the debugger
>will be run always under ptkdb. The little patch I propose to Apache/DB.pm is to
>improve Apache to dinamically switch from command line to GUI (ptkdb) interface by
>configuring this in httpd.conf.
>>>
>>Hi Enrico,
>>
>>Does it actually work for you? My previous experience with it wasn't so
>>good. I was manually loading Devel/ptkdb.pm instead of Apache/perl5db.pl
>>and it'll work for the first request, but then will hang. I see that
>>ptkdb hasn't changed since the last time I've tried it. May be it's a
>>newer perlTk that works better now?
>>
>>
>
> Dear Stas,
> I know the hang problem (I've started to hack the ptkdb code but it is enough
>complex...)
> However I find the GUI debugger useful. My TEMPORARY workaround is:
>
> 1) Initially (and if possible) I've used a brutal 'kill 9 $$' code in cleanup handler
>
> if (ref $r) {
> $SIG{INT} = \&DB::catch;
> $r->register_cleanup(sub {
> $SIG{INT} = \&DB::ApacheSIGINT();
>
kill 9, $$ if $ptkdb;
> });
> }
Yup, tried that, but I didn't like that approach.
> then now
>
> 2) I use the ptkdb 'File' menu command "Close Window and Run" (but I've added this
>in the button bar) instead of "Run". In this case at the end of code, the debugger
>won't hang and the window will closed. Note that if there are breakpoint, the window
>will be closed and re-opened and all breakpoint are maintained (it is more convenient
>to use 'Close Window and Run' only after last breakpoint).
Cool! Any chance you can submit a patch to the author of ptkdb so we can
all benefit from this trick? CC'ing mod_perl list will be useful too.
I wish someone with perl/Tk knowledge could solve the hanging problem.
Thanks Enrico!
--
_
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: ANNOUNCE: Apache::GTopLimit v1.0
Cahill, Earl wrote: > Looks like this will do the limit by CPU or memory used. Guess I should > read my whole inbox before I start to respond. Only memory, see Apache::Resource for CPU as Perrin has already replied to you ;) > Thanks, > Earl > > >>-Original Message- >>From: Stas Bekman [mailto:[EMAIL PROTECTED]] >>Sent: Thursday, February 28, 2002 8:40 PM >>To: modperl list >>Subject: ANNOUNCE: Apache::GTopLimit v1.0 >> >> >>The uploaded file >> >> Apache-GTopLimit-1.0.tar.gz >> >>has entered CPAN as >> >> file: $CPAN/authors/id/S/ST/STAS/Apache-GTopLimit-1.0.tar.gz >> size: 5117 bytes >>md5: d1847eecbf8584ae04f9c0081e22897f >> >>=head1 ver 1.0 Wed Feb 20 11:54:23 SGT 2002 >> >>* making the DEBUG a constant variable, settable via PerlSetVar >> >>* A few code style changes and doc fixes >> >>* this module has spent enough time in alpha/beta incubator >>=> going 1.0. >> >> >>_ >>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/ >> >> -- _ 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: mod_auth_mysql usage/documentation
all- I think I found it. Can someone take a gander at http://www.cgi101.com/class/password/mod_auth_mysql.html and let me know if this is current/correct? thanks. Grant Babb Email: [EMAIL PROTECTED] Data Junction Corporation Phone: (512) 459-1308 2201 Northland Dr. Fax: (512) 459-1309 Austin, TX 78756-1117 Web: http://www.datajunction.com
documentation for mod_auth_mysql
all- i am having no luck locating the documentation for mod_auth_mysql. any help would be greatly appreciated. thanks in advance- grant Grant Babb Email: [EMAIL PROTECTED] Data Junction Corporation Phone: (512) 459-1308 2201 Northland Dr. Fax: (512) 459-1309 Austin, TX 78756-1117 Web: http://www.datajunction.com
Re: Blank pages
John E. Leon Guerrero wrote: > in my case, we had a number of scripts that would change > STDOUT in some fashion (usually so they could set $|) but then die due to > some error before resetting STDOUT back. Interesting. One safety measure to prevent this would be to install a cleanup handler that resets STDOUT. This is a similar concept to the rollback that Apache::DBI issues in a cleanup handler. - Perrin
RE: Blank pages
i ran into a number of similar problems that did not seem to be documented anywhere else. in my case, we had a number of scripts that would change STDOUT in some fashion (usually so they could set $|) but then die due to some error before resetting STDOUT back. then any mod-perl script that the child would serve would produce a blank page while static files would continue to be served cleanly. when that child died, the problem would go away. if a user refreshed and got another child, then it would appear as if the problem went away. i added the PID to the access logs and watched for any HTTP 200's with zero length body sizes and traced backwards to see who the common culprit was. the only caveat was that apache would sometimes log HTTP 200 when in fact the return code was HTTP 302 (redirect). it is natural to have a zero length body size for a redirect. good luck, John E. Leon Guerrero > -Original Message- > From: Axel Andersson [mailto:[EMAIL PROTECTED]] > Sent: Friday, March 01, 2002 5:40 AM > To: [EMAIL PROTECTED] > Subject: Blank pages > > > Hi, > I run a mod_perl/mysql site, which works fine most of the time. Some > pages, however, come out completely blank. Reload.. and hey presto, it > works. Now, I realize this could be practically anything, so I'm just > asking if anyone has come across something similar. > > I use Apache::DBI 0.88 for database connections, Apache 1.3.23 and > mod_perl/1.2. Strange thing is, nothing shows up in the error log, even > using -w. > > Well, it's a longshot, but thanks anyway. > > Axel Andersson > > -- > [EMAIL PROTECTED] > http://www.animanga.nu/morris/ > > 31. With intagible breath in center of forehead, as this reaches heart at > the moment of sleep, have direction over dreams and over death itself. >
segfaulting upon request
hi, I've installed and used mod_perl with great sucess before, but I'm having trouble with the latest version of mod_perl and apache. (version 1.26 with apache 1.3.23) upon startup there's a segmentation fault upon any http request. i'd be grateful for any assistance. here's what the make test says: # make test TEST_VERBOSE=1 make[1]: Entering directory `/root/src/mod_perl-1.26/Apache' make[1]: Leaving directory `/root/src/mod_perl-1.26/Apache' make[1]: Entering directory `/root/src/mod_perl-1.26/Connection' make[1]: Leaving directory `/root/src/mod_perl-1.26/Connection' make[1]: Entering directory `/root/src/mod_perl-1.26/Constants' make[1]: Leaving directory `/root/src/mod_perl-1.26/Constants' make[1]: Entering directory `/root/src/mod_perl-1.26/File' make[1]: Leaving directory `/root/src/mod_perl-1.26/File' make[1]: Entering directory `/root/src/mod_perl-1.26/Leak' make[1]: Leaving directory `/root/src/mod_perl-1.26/Leak' make[1]: Entering directory `/root/src/mod_perl-1.26/Log' make[1]: Leaving directory `/root/src/mod_perl-1.26/Log' make[1]: Entering directory `/root/src/mod_perl-1.26/ModuleConfig' make[1]: Leaving directory `/root/src/mod_perl-1.26/ModuleConfig' make[1]: Entering directory `/root/src/mod_perl-1.26/PerlRunXS' make[1]: Leaving directory `/root/src/mod_perl-1.26/PerlRunXS' make[1]: Entering directory `/root/src/mod_perl-1.26/Server' make[1]: Leaving directory `/root/src/mod_perl-1.26/Server' make[1]: Entering directory `/root/src/mod_perl-1.26/Symbol' make[1]: Leaving directory `/root/src/mod_perl-1.26/Symbol' make[1]: Entering directory `/root/src/mod_perl-1.26/Table' make[1]: Leaving directory `/root/src/mod_perl-1.26/Table' make[1]: Entering directory `/root/src/mod_perl-1.26/URI' make[1]: Leaving directory `/root/src/mod_perl-1.26/URI' make[1]: Entering directory `/root/src/mod_perl-1.26/Util' make[1]: Leaving directory `/root/src/mod_perl-1.26/Util' cp t/conf/mod_perl_srm.conf t/conf/srm.conf ./apaci/load_modules.pl ../apache_1.3.23/src ../apache_1.3.23/src/httpd -f `pwd`/t/conf/httpd.conf -X -d `pwd`/t & httpd listening on port 8529 will write error_log to: t/logs/error_log letting apache warm up...\c done /usr/local/bin/perl t/TEST 1 still waiting for server to warm up...not ok server failed to start! (please examine t/logs/error_log) at t/TEST line 95. make: *** [run_tests] Error 111 i built modperl and apache like this: perl Makefile.PL APACHE_SRC=../apache_1.3.23/ NO_HTTPD=1 USE_APACI=1 PREP_HTTPD=1 EVERYTHING=1 USE_DSO=1 make make install build apache: ./configure --prefix=/etc/httpd-perl \ --activate-module=src/modules/perl/libperl.a --enable-shared=max \ --enable-module=all --verbose --disable-module=auth_db \ --enable-shared=perl make make install here's details of the machine: on redhat 7.0 linux i686, kernel 2.2.19-7.0.1smp perl -V Summary of my perl5 (revision 5.0 version 6 subversion 1) configuration: Platform: osname=linux, osvers=2.2.16-22smp, archname=i686-linux uname='linux apparelizer.scribble.com 2.2.16-22smp #1 smp tue aug 22 16:39:21 edt 2000 i686 unknown ' config_args='' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=undef d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef Compiler: cc='cc', ccflags ='-fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-O2', cppflags='-fno-strict-aliasing' ccversion='', gccversion='2.96 2731 (Red Hat Linux 7.0)', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=4, usemymalloc=n, prototype=define Linker and Libraries: ld='cc', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-lnsl -lgdbm -ldl -lm -lc -lcrypt -lutil perllibs=-lnsl -ldl -lm -lc -lcrypt -lutil libc=/lib/libc-2.1.92.so, so=so, useshrplib=false, libperl=libperl.a Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic' cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: USE_LARGE_FILES Built under linux Compiled at Apr 13 2001 14:29:10 @INC: /usr/local/lib/perl5/5.6.1/i686-linux /usr/local/lib/perl5/5.6.1 /usr/local/lib/perl5/site_perl/5.6.1/i686-linux /usr/local/lib/perl5/site_perl/5.6.1 /usr/local/lib/perl5/site_perl thanx! smh Steev Hise, Information Engineer [EMAIL PROTECTED] http://www.datamassage.com - "Getting programmers to write documentation is almost as hard as getting them to wear ties" -Larry Wall, et.al, 'Programming Perl' --
RE: ANNOUNCE: Apache::GTopLimit v1.0
Looks like this will do the limit by CPU or memory used. Guess I should read my whole inbox before I start to respond. Thanks, Earl > -Original Message- > From: Stas Bekman [mailto:[EMAIL PROTECTED]] > Sent: Thursday, February 28, 2002 8:40 PM > To: modperl list > Subject: ANNOUNCE: Apache::GTopLimit v1.0 > > > The uploaded file > > Apache-GTopLimit-1.0.tar.gz > > has entered CPAN as > >file: $CPAN/authors/id/S/ST/STAS/Apache-GTopLimit-1.0.tar.gz >size: 5117 bytes > md5: d1847eecbf8584ae04f9c0081e22897f > > =head1 ver 1.0 Wed Feb 20 11:54:23 SGT 2002 > > * making the DEBUG a constant variable, settable via PerlSetVar > > * A few code style changes and doc fixes > > * this module has spent enough time in alpha/beta incubator > => going 1.0. > > > _ > 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: ANNOUNCE: Apache::Watchdog::RunAway v0.3
Cahill, Earl wrote: > Any chance of being able to define a "runaway" script based on percent of > CPU or percent of memory used as well as time in seconds? This would be > great for us. Every so often we get a script that just starts choking on > memory, and gets every process on the box swapping, which kills our load. You should use Apache::SizeLimit and Apache::Resource to handle this. - Perrin
RE: ANNOUNCE: Apache::Watchdog::RunAway v0.3
Any chance of being able to define a "runaway" script based on percent of CPU or percent of memory used as well as time in seconds? This would be great for us. Every so often we get a script that just starts choking on memory, and gets every process on the box swapping, which kills our load. Earl > -Original Message- > From: Stas Bekman [mailto:[EMAIL PROTECTED]] > Sent: Thursday, February 28, 2002 8:39 PM > To: modperl list > Subject: ANNOUNCE: Apache::Watchdog::RunAway v0.3 > > > > The uploaded file > > Apache-Watchdog-RunAway-0.3.tar.gz > > has entered CPAN as > >file: $CPAN/authors/id/S/ST/STAS/Apache-Watchdog-RunAway-0.3.tar.gz >size: 7722 bytes > md5: 701b7a99fe658c5b895191e5f03fff34 > > Changes: > > =head1 ver 1.0 Wed Feb 20 11:54:23 SGT 2002 > > * making the DEBUG a constant variable, settable via PerlSetVar > > * A few code style changes and doc fixes > > * this module has spent enough time in alpha/beta incubator > => going 1.0. > > _ > 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: [ANNOUNCE] mod_perl logo
On Mon, 2002-03-04 at 08:26, Jonathan M. Hollin wrote: > Friends, > > The time has now come to cast your vote(s) for the new mod_perl logo (to > accompany the new mod_perl website which is now almost complete). You > can select your preferred logo at > http://www.tohubohu.net/cgi/mpchallenge.; You can vote for a new logo, > or button or both. You can also vote to keep the existing logo/button. > If a new logo is chosen, then a banner (or banners) will be designed > around the chosen logo. Didn't we do this a couple years back? I thought this time camels and feathers were discouraged ...
Re: Apache::DB patch
On Fri, 01 Mar 2002 11:16:15 +0800
Stas Bekman <[EMAIL PROTECTED]> wrote:
> Enrico Sorcinelli wrote:
> > Hi all,
> > I started to use Apache::DB (0.06) to interactively debug under mod_perl using
>ptkdb. I see that is necessary to modify Apache/DB.pm but, after this, the debugger
>will be run always under ptkdb. The little patch I propose to Apache/DB.pm is to
>improve Apache to dinamically switch from command line to GUI (ptkdb) interface by
>configuring this in httpd.conf.
>
> Hi Enrico,
>
> Does it actually work for you? My previous experience with it wasn't so
> good. I was manually loading Devel/ptkdb.pm instead of Apache/perl5db.pl
> and it'll work for the first request, but then will hang. I see that
> ptkdb hasn't changed since the last time I've tried it. May be it's a
> newer perlTk that works better now?
>
Dear Stas,
I know the hang problem (I've started to hack the ptkdb code but it is enough
complex...)
However I find the GUI debugger useful. My TEMPORARY workaround is:
1) Initially (and if possible) I've used a brutal 'kill 9 $$' code in cleanup handler
if (ref $r) {
$SIG{INT} = \&DB::catch;
$r->register_cleanup(sub {
$SIG{INT} = \&DB::ApacheSIGINT();
>>> kill 9, $$ if $ptkdb;
});
}
then now
2) I use the ptkdb 'File' menu command "Close Window and Run" (but I've added this in
the button bar) instead of "Run". In this case at the end of code, the debugger won't
hang and the window will closed. Note that if there are breakpoint, the window will be
closed and re-opened and all breakpoint are maintained (it is more convenient to use
'Close Window and Run' only after last breakpoint).
Enrico
=
Enrico Sorcinelli - Gruppo E-Comm - Italia On Line S.p.a.
E-Mail: [EMAIL PROTECTED] - [EMAIL PROTECTED]
=
Re: problems with $r->status('OK')
you'll want to do
use Apache::Constants qw(OK);
and change that to
$r->status(OK);
as OK is actually defined as a constant function
sub OK { 0 }
END
--
Philip M. Gollucci (p6m7g8) [EMAIL PROTECTED] 301.314.3118
Science, Discovery, & the Universe (UMCP)
Webmaster & Webship Teacher
URL: http://www.sdu.umd.edu
EJPress.com
Database/PERL Programmer & System Admin
URL : http://www.ejournalpress.com
Resume : http://p6m7g8.com/Work/index.html
On Mon, 4 Mar 2002, clayton cottingham wrote:
> hello:
>
> im using Apache/1.3.12
> and
> mod_perl/1.24
>
> every time i use
> the $r->status('OK');
>
> it gives me this error
>
> Argument "OK" isn't numeric in subroutine entry
>
> has anyone come accross this before?
>
> thanks
>
Re: webmail for mod_perl?
will trillich wrote: > > On Thu, Feb 28, 2002 at 03:59:05PM -0800, Wim Kerkhoff wrote: > > will trillich wrote: > > > > > > is there a sane implementation of webmail-style mod_perl > > > modules for apache? > > > > Are you needing any specific functionality? > > > > sparkle (a rewrite of acmemail) works as a mod_perl handler, under > > Apache::Registry, and of course as a normal CGI. Works with various IMAP > > servers via Mail::Cclient. Uses Template Toolkit for > > themes/templates/skins. > > > > It's quite peppy once you add all the modules into startup.pl. > > this looks like what we need. cool. thanks! > > and now for some evidence that i saw the documentation... There isn't much for sparkle. I suppose one could follow the older acmemail docs, then: - edit Acmemail::Config to suit - use CPAN to install whatever modules that are required to get it to run :-) Wim
Re: problems with $r->status('OK')
Hans Juergen von Lengerke wrote:
>
> clayton cottingham <[EMAIL PROTECTED]> on Mar 4, 2002:
>
> > every time i use
> > the $r->status('OK');
>
> "OK" in this context is not a string, but a constant that is defined in
> Apache::Constants. Modify your code like this:
>
> use Apache::Constants qw(:common);
> ...
> $r->status(OK); # No quotes, it's a constant
>
> HTH, Hans
hmm,
ok did that before but i needed a restart !
sheesh!!
thanks for the quick reply!
Re: problems with $r->status('OK')
clayton cottingham <[EMAIL PROTECTED]> on Mar 4, 2002:
> every time i use
> the $r->status('OK');
"OK" in this context is not a string, but a constant that is defined in
Apache::Constants. Modify your code like this:
use Apache::Constants qw(:common);
...
$r->status(OK); # No quotes, it's a constant
HTH, Hans
problems with $r->status('OK')
hello:
im using Apache/1.3.12
and
mod_perl/1.24
every time i use
the $r->status('OK');
it gives me this error
Argument "OK" isn't numeric in subroutine entry
has anyone come accross this before?
thanks
Re: [WOT] Opcode/ Safe
Ok, forget my post, her's the answer:
#!/usr/bin/perl -w
use Safe;
my $page = new Safe ("huhu");
my $opset = Opcode::opset qw(:base_io :base_orig :base_thread
:filesys_read :sys_db
:filesys_open :filesys_write :subprocess :ownprocess
:still_to_be_decided :dangerous);
$page->deny(Opcode::opset_to_ops($opset));
$page->permit qw(print ref );
$page->deny (qw(rand srand));
$page->reval ("eval \" print 'huhu' \"");
print $@."\n";
Martin Haase-Thomas wrote:
> Hi all,
>
> maybe this is really far WOT, but one shouldn't give up hope, as we
> all know...
> Does anyone have experience with Opcode and Safe? The thing is that I
> have to create my own secure namespace
> for some reasons - and don't know how to do.
>
> What does not work is the following:
>
> #!/usr/bin/perl -w
> use Safe;
> my $page = new Safe ("huhu");
> $page->deny qw(:base_io :base_orig :base_thread :filesys_read :sys_db
> :filesys_open :filesys_write :subprocess :ownprocess
> :still_to_be_decided :dangerous);
> $page->permit qw(print ref entereval);
> $page->deny qw(rand srand);
> $page->reval ("sysopen '/bla/blub.html' || kill 15, 1906");
>
> Anyone with an idea? btw: funny things will happen if you type 1
> instead of 1906 ... :)
>
> regards
> Martin
>
--
http://www.meome.de
---
Martin Haase-Thomas | Tel.: 030 43730-558
meOme AG| Fax.: 030 43730-555
Software Development| [EMAIL PROTECTED]
---
[WOT] Opcode/ Safe
Hi all,
maybe this is really far WOT, but one shouldn't give up hope, as we all
know...
Does anyone have experience with Opcode and Safe? The thing is that I
have to create my own secure namespace
for some reasons - and don't know how to do.
What does not work is the following:
#!/usr/bin/perl -w
use Safe;
my $page = new Safe ("huhu");
$page->deny qw(:base_io :base_orig :base_thread :filesys_read :sys_db
:filesys_open :filesys_write :subprocess :ownprocess
:still_to_be_decided :dangerous);
$page->permit qw(print ref entereval);
$page->deny qw(rand srand);
$page->reval ("sysopen '/bla/blub.html' || kill 15, 1906");
Anyone with an idea? btw: funny things will happen if you type 1 instead
of 1906 ... :)
regards
Martin
--
http://www.meome.de
---
Martin Haase-Thomas | Tel.: 030 43730-558
meOme AG| Fax.: 030 43730-555
Software Development| [EMAIL PROTECTED]
---
Re: Apache::MP3 requires "PerlSetupEnv on", patch to convert to Apache::Request
Eric Hammond wrote:
> Lincoln:
>
> After a day of adding debug statements into Apache::MP3 and CGI.pm
> I finally tracked down why my streaming was not working. I had
> listened to http://perl.apache.org/guide/performance.html#PerlSetupEnv_Off
> which caused $ENV{QUERY_STRING} to not be set which broke CGI.pm.
The guide does say:
Scripts using the CGI.pm module require PerlSetupEnv On
because that module relies on a properly populated CGI
environment table.
But I realize that a user of Apache::MP3 may not realize that the latter
uses CGI.pm under the hood.
Can CGI.pm detect that 'PerlSetupEnv Off' is in effect and die if that's
the case? for example by testing some env var that most likely should be
set with 'PerlSetupEnv On'? e.g.:
#check that we aren't running under PerlSetupEnv Off
if ($ENV{MOD_PERL} && !ENV{SCRIPT_FILENAME}) {
die "CGI.pm cannot run under 'PerlSetupEnv Off' setting";
}
> To save others the agony, you might want to add a note to the Apache::MP3
> docs that it requires "PerlSetupEnv on"
>
> Alternatively, you might consider rewriting Apache::MP3 to use
> Apache::Request instead of CGI.pm (though I understand you may have
> a fondness for the latter).
>
> I've included a patch to convert Apache::MP3 to use Apache::Request
> for parameters. More work would be required to convert the other uses
> of CGI.pm, but if you'd like, I'd be willing to tackle that, too, as
> it would be nice to not require the large size of CGI.pm.
>
_
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/
