Apache::RegistryBB patch for 'use strict'
Apache::RegistryBB from mod_perl-1.24.tar.gz needs a small patch for 'use strict'. diff Apache/RegistryBB.pm.orig Apache/RegistryBB.pm 5c5 use Apache::Constants qw(NOT_FOUND FORBIDDEN OK); --- use Apache::Constants qw(NOT_FOUND FORBIDDEN OK DECLINED); -- Mike
Forms.
hi,
I am interested in knowing the best way to generate forms w/ mod_perl. At
the moment I use CGI.pm in combination w/ mod_perl. But I am not sure I
am using it correctly or if it's the best way.
Perhaps I should just use a HTML::Template?
Here is a bit of the output code from my prg:
$r-content_type("text/html");
$r-send_http_header;
print start_form();
$r-print ("What is the domain name: ", textfield("domain"), "\n");
$r-print ("br");
$r-print ("What would you like done?:\n");
$r-print ("br");
$r-print (checkbox(-name='email',
-checked='checked',
-value='ON',
-label='Virtual Mail/Exim'));
$r-print ("br");
$r-print (checkbox(-name='bind',
-checked='checked',
-value='ON',
-label='DNS/Bind'));
$r-print ("br");
$r-print (checkbox(-name='apache',
-checked='checked',
-value='ON',
-label='Virtual Web/Apache'));
$r-print ("br");
print submit(-NAME = ".State", -VALUE = "Next");
print print end_form(), hr();
print end_html();
Thanks.
J.
Re: Apache::RegistryBB patch for 'use strict'
Apache::RegistryBB from mod_perl-1.24.tar.gz needs a small patch for 'use strict'. diff Apache/RegistryBB.pm.orig Apache/RegistryBB.pm 5c5 use Apache::Constants qw(NOT_FOUND FORBIDDEN OK); --- use Apache::Constants qw(NOT_FOUND FORBIDDEN OK DECLINED); Committed, thanks for the patch! -- Eric
patch for Apache::Session::Store::Postgres
Patch for Apache::Session::Store::Postgres, from
Apache-Session-1.51.tar.gz, to resolve problems with
prepare_cached(SELECT a_session FROM sessions WHERE id = ? FOR
UPDATE) statement handle DBI::st=HASH(0x369a2c) is still active
after a transient error. The solution is to call sth-finish()
whether the SELECT was successful or not.
diff Store/Postgres.pm.orig Store/Postgres.pm
78a79,81
# success or failure, don't leave FOR UPDATE lying around
$self-{materialize_sth}-finish;
83,84d85
$self-{materialize_sth}-finish;
-- Mike
Re: Microsoft SQL 7.0 interface
You might use DBD::ODBC with DBD::Proxy as well; should be easier to setup, but probably less efficient than FreeTDS. Kee Hinckley wrote: At 5:45 PM -0500 5/26/00, Wang, Pin-Chieh wrote: Any body knows how to access Microsoft SQL/on NT from Apache on Linux ? Our data base is running on NT/SQL , but web server is running Apache/Linux DBD::Sybase and FreeTDS will work (http://www.freetds.org/). - -- Kee Hinckley - Somewhere Consulting Group - Cyberspace Architects(rm) I'm not sure which upsets me more: that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's. -BEGIN PGP SIGNATURE- Version: PGPfreeware 6.5.2 for non-commercial use http://www.pgp.com iQA/AwUBOTH5aiZsPfdw+r2CEQKZ/ACdHfmeg1fmSfLlj5CiapCHXWF5vy8AoP7s nVY5U4aLCjUjbnib0uNRYSJ3 =73+t -END PGP SIGNATURE-
[RFC] improving memory mapping thru code exercising
A while ago, a few people have mentioned that it's possible to improve the way Perl data structures get mapped in memory pages, by exercising the code before the child processes have been spawned, i.e. running the code and not just pre-compiling it. Did anyone try this at home :) Any satisfactionary results on this direction or what it just a crazy idea? If my explanation wasn't good enough, the aim was to improve the sharing of the memory pages and reduce the unsharing during the child life to minimum. 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://perl.org http://stason.org/TULARC http://singlesheaven.com http://perlmonth.com http://sourcegarden.org
Re: PerlSetupEnv bug?
I can't seem to get PerlSetupEnv to affect my perl-bin anyplace other than
in the perl-bin Location tag
that is:
PerlSetupEnv Off
Alias /perl-bin/ /usr/local/apache/perl-bin/
Location /perl-bin
SetHandler perl-script
PerlHandler Apache::Registry
Options +ExecCGI
Order Allow,Deny
Allow from All
# PerlSetupEnv Off
/Location
still gives me a cgi-populated %ENV for a normal Registry script. If I swap
the directives, all is ok. According to mod/mod_perl.html the directive
should be able to go anywhere
can anyone else verify this? or am I missing something...
Sure, here comes:
I don't know what's the right behavior should be but, I've tested my
setup: 1.24/1.3.12/5.005_03/rh6.2 and here is what I saw:
Env.pm
--
package Env;
use strict;
use Apache::Constants qw(:common);
sub handler{
shift-send_http_header('text/plain');
print map {"$_ = $ENV{$_}\n"} keys %ENV;
return OK;
}
1;
The following sets %ENV OFF
Location /env
SetHandler perl-script
PerlHandler +Env
PerlSetupEnv Off
/Location
The following doesn't set %ENV OFF
Location /env
SetHandler perl-script
PerlHandler +Env
PerlSetupEnv Off
/Location
I've tried the same with Apache::Registry, no matter where I put the
PerlSetupEnv directive, the %ENV is ON all the time. I guess the
enviroment is being enforced in Registry XS code, no matter what settings
is.
_
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://perl.org http://stason.org/TULARC
http://singlesheaven.com http://perlmonth.com http://sourcegarden.org
Re: Please HELP, Thanks.
On Mon, May 29, 2000 at 08:05:08AM -0500, Hui Zhu wrote: Hi ALL: I have a module called samplemod.pm. It used to work fine. After modifying something, i got errors from a perl script (use samplemod;) saying: samplemod.pm did not return a true value at /home/httpd/perl/test.pl line 12. BEGIN failed--compilation aborted at /home/httpd/perl/test.pl line 12. Any hints, Thank you very much. Steven. End of code: 1; Every module has to return a true value at the end of it you could probably do 1000; at the end, but 1 is convention. Thanks, Shane.
Re: Please HELP, Thanks.
You could try putting a 1; at the end of the module, if you don't already have one. Leaving this out is a common mistake. Mike -Original Message- From: Hui Zhu [EMAIL PROTECTED] Cc: Modperl Mailing List [EMAIL PROTECTED] Date: 29 May 2000 14:00 Subject: Please HELP, Thanks. Hi ALL: I have a module called samplemod.pm. It used to work fine. After modifying something, i got errors from a perl script (use samplemod;) saying: samplemod.pm did not return a true value at /home/httpd/perl/test.pl line 12. BEGIN failed--compilation aborted at /home/httpd/perl/test.pl line 12. Any hints, Thank you very much. Steven. Jim Winstead wrote: On May 25, Jeff Stuart wrote: That's a GOOD question. Is there anyone at the moment using perl 5.6.0 in production? Is it ready for production yet? We have one site in production with it, and a number of others going into production soon. We've been using is exclusively in our development environment for all new development since shortly after 5.6.0 came out. It has been rock-solid for us. (The basic setup is Apache 1.3.12, mod_perl 1.24, perl 5.6.0, and FreeBSD 3.4.) Jim
Strange thing about CGI::Cookie?
I see this line in my error_log, (offline mode: enter name=value pairs on standard input) And I sure it is caused by CGI::Cookie-parse (or fetch). Any idea why this would happen? Kenneth
Re: Please HELP, Thanks.
Not really a mod_perl question here,, but anyway if you include a file with "use" or "require" that file need to return a true value. return 1; or just: 1; you have probebly removed this line from samplemod.pm check samplemod.pm and make shure it returns a true value. Best regards Christian On Mon, 29 May 2000, you wrote: Hi ALL: I have a module called samplemod.pm. It used to work fine. After modifying something, i got errors from a perl script (use samplemod;) saying: samplemod.pm did not return a true value at /home/httpd/perl/test.pl line 12. BEGIN failed--compilation aborted at /home/httpd/perl/test.pl line 12. Any hints, Thank you very much. Steven
Re: Strange thing about CGI::Cookie?
On Mon, 29 May 2000, Kenneth Lee wrote: I see this line in my error_log, (offline mode: enter name=value pairs on standard input) And I sure it is caused by CGI::Cookie-parse (or fetch). Any idea why this would happen? Looks like CGI.pm's command line debug mode somehow gets triggered. In all my code that uses CGI.pm I have: use CGI; $CGI::NO_DEBUG = 1; I guess it's the same thing with CGI::Cookie _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://perl.org http://stason.org/TULARC http://singlesheaven.com http://perlmonth.com http://sourcegarden.org
Re: Strange thing about CGI::Cookie?
I had no clue either, but using the Apache Cookie module instead fixed it. Arnold On Mon, 29 May 2000, Kenneth Lee wrote: I see this line in my error_log, (offline mode: enter name=value pairs on standard input) And I sure it is caused by CGI::Cookie-parse (or fetch). Any idea why this would happen? Kenneth
Re: patch for Apache::Session::Store::Postgres
On Mon, 29 May 2000, Michael Blakeley wrote:
Patch for Apache::Session::Store::Postgres, from
Apache-Session-1.51.tar.gz, to resolve problems with
prepare_cached(SELECT a_session FROM sessions WHERE id = ? FOR
UPDATE) statement handle DBI::st=HASH(0x369a2c) is still active
after a transient error. The solution is to call sth-finish()
whether the SELECT was successful or not.
diff Store/Postgres.pm.orig Store/Postgres.pm
78a79,81
# success or failure, don't leave FOR UPDATE lying around
$self-{materialize_sth}-finish;
83,84d85
$self-{materialize_sth}-finish;
Hrmm, I'm not really an expert here. If I do a SELECT ... FOR UPDATE on a
row that doesn't exist, shouldn't that just do nothing?
To squash this warning, we could just as easily use the allow_active flag
in the prepare method.
-jwb
Re: [RFC] improving memory mapping thru code exercising
"SB" == Stas Bekman [EMAIL PROTECTED] writes: SB A while ago, a few people have mentioned that it's possible to improve the SB way Perl data structures get mapped in memory pages, by exercising the SB code before the child processes have been spawned, i.e. running the code SB and not just pre-compiling it. Did anyone try this at home :) Any SB satisfactionary results on this direction or what it just a crazy idea? This is extremely important for DBI, since the DBD layer is not loaded until needed. Thus, unless you exercise your Connect in DBI, the DBD is not loaded until each child is spawned. I'm sure other modules do some sort of initialization as well which could break sharing since perl code and data pages are the same as far as the OS is concerned. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D.Khera Communications, Inc. Internet: [EMAIL PROTECTED] Rockville, MD +1-301-545-6996 GPG MIME spoken herehttp://www.khera.org/~vivek/
[segfault] with diagnostics and DProf
It seems that Devel::Dprof and diagnostics can't live together. I wanted to profile the code that uses diagnostics from within mod_perl, but it segfaults with no core dumped and no error messages, so here is the gdb trace. The code runs Ok from the command line and produce the right dump file used by dprofpp. Oh, when I run it without -X I get this in the error_log: Argument "diagnostics::unescape" isn't numeric in entersub at /usr/lib/perl5/5.00503/diagnostics.pm line 290, POD_DIAG chunk 2688. Consider this code: use diagnostics; print "Content-type: text/html\n\n"; print "Ok"; Now: % setenv PERL5OPT -d:DProf % gdb /usr/local/apache/bin/httpd (gdb) set args -X (gdb) run Starting program: /usr/local/apache/bin/httpd -X Now issuing the request to the above code: Program received signal SIGSEGV, Segmentation fault. 0x400cd4af in _IO_fflush (fp=0x816fb78) at iofflush.c:41 41 iofflush.c: No such file or directory. (gdb) where #0 0x400cd4af in _IO_fflush (fp=0x81727e0) at iofflush.c:41 #1 0x400150fb in prof_dump_until () from /usr/lib/perl5/site_perl/5.005/i386-linux/auto/Devel/DProf/DProf.so #2 0x4001549c in prof_mark () from /usr/lib/perl5/site_perl/5.005/i386-linux/auto/Devel/DProf/DProf.so #3 0x400159d9 in XS_DB_sub () from /usr/lib/perl5/site_perl/5.005/i386-linux/auto/Devel/DProf/DProf.so #4 0x80ee5b6 in Perl_pp_entersub () #5 0x811855d in Perl_runops_standard () #6 0x81069b1 in Perl_pp_exit () #7 0x8107982 in Perl_pp_require () #8 0x811855d in Perl_runops_standard () #9 0x80c09a1 in perl_call_sv () #10 0x400159cf in XS_DB_sub () from /usr/lib/perl5/site_perl/5.005/i386-linux/auto/Devel/DProf/DProf.so #11 0x80ee5b6 in Perl_pp_entersub () #12 0x80c098c in perl_call_sv () #13 0x80c2ce9 in Perl_call_list () #14 0x80db80f in Perl_newSUB () #15 0x80d9340 in Perl_utilize () #16 0x80d5014 in Perl_yyparse () #17 0x8106f06 in Perl_sv_compile_2op () #18 0x8107c75 in Perl_pp_entereval () #19 0x811855d in Perl_runops_standard () #20 0x80c09a1 in perl_call_sv () #21 0x400159cf in XS_DB_sub () from /usr/lib/perl5/site_perl/5.005/i386-linux/auto/Devel/DProf/DProf.so #22 0x80ee5b6 in Perl_pp_entersub () #23 0x811855d in Perl_runops_standard () #24 0x80c09a1 in perl_call_sv () #25 0x400159cf in XS_DB_sub () from /usr/lib/perl5/site_perl/5.005/i386-linux/auto/Devel/DProf/DProf.so #26 0x80ee5b6 in Perl_pp_entersub () #27 0x80c098c in perl_call_sv () #28 0x807d7cb in perl_call_handler () #29 0x807cfdb in perl_run_stacked_handlers () #30 0x807b55d in perl_handler () #31 0x80966e3 in ap_invoke_handler () #32 0x80a9bb9 in ap_some_auth_required () #33 0x80a9c1c in ap_process_request () #34 0x80a150e in ap_child_terminate () #35 0x80a169c in ap_child_terminate () #36 0x80a17f9 in ap_child_terminate () #37 0x80a1e26 in ap_child_terminate () #38 0x80a25b3 in main () #39 0x400941eb in __libc_start_main (main=0x80a226c main, argc=2, argv=0xbba4, init=0x80600b4 _init, fini=0x811863c _fini, rtld_fini=0x4000a610 _dl_fini, stack_end=0xbb9c) at ../sysdeps/generic/libc-start.c:90 perl -V: Summary of my perl5 (5.0 patchlevel 5 subversion 3) configuration: Platform: osname=linux, osvers=2.2.5-22smp, archname=i386-linux uname='linux porky.devel.redhat.com 2.2.5-22smp #1 smp wed jun 2 09:11:51 edt 1999 i686 unknown ' hint=recommended, useposix=true, d_sigaction=define usethreads=undef useperlio=undef d_sfio=undef Compiler: cc='cc', optimize='-O2', gccversion=egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) cppflags='-Dbool=char -DHAS_BOOL -I/usr/local/include' ccflags ='-Dbool=char -DHAS_BOOL -I/usr/local/include' stdchar='char', d_stdstdio=undef, usevfork=false intsize=4, longsize=4, ptrsize=4, doublesize=8 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 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 -ldl -lm -lc -lposix -lcrypt libc=, 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): Built under linux Compiled at Aug 30 1999 23:09:51 %ENV: PERL5DB="use Devel::DProf;" PERL5OPT="-d:DProf" @INC: /usr/lib/perl5/5.00503/i386-linux /usr/lib/perl5/5.00503 /usr/lib/perl5/site_perl/5.005/i386-linux /usr/lib/perl5/site_perl/5.005 . Makefile options: perl Makefile.PL PERL_DEBUG=1 APACHE_SRC=../apache_1.3.12/src \ DO_HTTPD=1 USE_APACI=1 PERL_MARK_WHERE=1 EVERYTHING=1 \ APACI_ARGS=--enable-module=info mod_perl 1.24 / apache 1.3.12 Ideas? _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide
Re: patch for Apache::Session::Store::Postgres
At 9:10 AM -0700 5/29/2000, Jeffrey W. Baker wrote:
On Mon, 29 May 2000, Michael Blakeley wrote:
Patch for Apache::Session::Store::Postgres, from
Apache-Session-1.51.tar.gz, to resolve problems with
prepare_cached(SELECT a_session FROM sessions WHERE id = ? FOR
UPDATE) statement handle DBI::st=HASH(0x369a2c) is still active
after a transient error. The solution is to call sth-finish()
whether the SELECT was successful or not.
diff Store/Postgres.pm.orig Store/Postgres.pm
78a79,81
# success or failure, don't leave FOR UPDATE lying around
$self-{materialize_sth}-finish;
83,84d85
$self-{materialize_sth}-finish;
Hrmm, I'm not really an expert here. If I do a SELECT ... FOR UPDATE on a
row that doesn't exist, shouldn't that just do nothing?
I'm no expert either - but I believe that the problem is the
"unfinished" sth hanging around in DBI or DBD::Pg, rather than any
results or lack thereof. Note that the error comes from
DBI::prepare_cached(), not from the postgres backend. One _could_
regard this as a DBD::Pg bug, if it's not present in other DBD
modules... but what's wrong with the fix above?
According to perldoc DBD::Pg, the prepare/execute thing is fairly
pointless in Postgres anyway. PG doesn't know prepared statements
from /dev/null, so you might as well just selectall_arrayref every
time. I've done some benchmarks that show a very slight improvement
in some cases (possibly due to state maintained by DBD::Pg), but it's
less than 10%.
To squash this warning, we could just as easily use the allow_active flag
in the prepare method.
True, but the above seems cleaner to me. Isn't dying and leaving
unfinished statement handles a bit untidy, like leaving unclosed
database handles, or unclosed file handles? It's a potential memory
leak as well, isn't it?
It's not a warning, BTW - for my Apache::Session application, it's
fatal. I've had to patch all previous versions of Apache::Session in
a similar way (somewhere you may have an older email from me on this
subject). The fix originally came from someone else, but I can't find
my notes at the moment to give proper credit.
-- Mike
RE: does mod_perl with USE_DSO=1 require perl built with -Duseshrplib ?
I use it with USE_DSO=1 without having built Perl with -Duseshrplib. I have all the Apache modules built as DSO's. By the way, what is Apache 1.3.14? The latest version on the Apache site is 1.3.12. -Paul -Original Message- From: Benedict Lofstedt [mailto:[EMAIL PROTECTED]] Sent: Friday, May 26, 2000 7:57 AM To: [EMAIL PROTECTED] Subject: does mod_perl with USE_DSO=1 require perl built with -Duseshrplib ? I have a number of apache servers on various hosts, not all of them are to be mod_perl enabled. So, I tried to build apache with mod_perl as a DSO in order to enable mod_perl via the httpd.conf file if needed. I tried building mod_perl-1.24 as a DSO for apache-1.3.14 on my Irix platform. Building went well, I got a libperl.so etc. However, the resulting httpd failed during make test, with a message about not being able to find PL_curpad when loading IO.so - similar to what is described in mod_perl_traps.pod. The unsatisfied symbol is in libperl.a. This looks like mod_perl as DSO *requires* perl to be built with -Duseshrplib . Is this correct? I like the improvements in mod_perl Makefile.PL which checks consistency between perl and apache regarding -D_LARGEFILE_SOURCE. If USE_DSO=1 requires a perl built with -Duseshrplib, perhaps mod_perl Makefile.PL could be modified to check this as well? --- benedict -- Benedict Lofstedt [EMAIL PROTECTED] University of Aarhus, Department of Computer Science Fax: + 45 8942 3255 Building 540, Ny Munkegade, DK-8000 Aarhus C, Denmark.Phone: + 45 8942 3222
1.2.1 installs ok, but ENV{MOD_PERL} returns false...
Hi,
I compiled modperl in the usual way:
in modperl 1.21 source: perl Makefile.PL EVERYTHING=1
apache 1.3.12 is at the same level. I ran make and make install and
then make install in the apache source. All goes in ok. httpd -l
shows:
root@latin:/usr/local/apache/bin# ./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_access.c
mod_auth.c
mod_setenvif.c
mod_perl.c
the http.conf has AddModule mod_perl.c among others. (do I need to call
it?)
I also have
# If the perl module is installed, this will be enabled.
PerlFreshRestart On
IfModule mod_perl.c
Alias /mp/ /home/paul/pubhtml/mod_perl/
Location /usr/local/apache/htdocs/perl
AllowOverride None
SetHandler perl-script
PerlHandler Apache::Registry
PerlSendHeader On
Options ExecCGI FollowSymLinks
/Location
/IfModule
in there. However, ENV{MOD_PERL} returns false all the time, and mod
perl doesn't seem to be running. Is there another test to see if it is
running? can I trust the ENV var? Any help offered will be
appreciated. I need to get AxKit up and running to serve xml. Thanks
