Re: Can't create custom configuration directives
I've snipped the lengthy explanation. Here's a few things you can check: There's no old version of your module in the ordinary perl lib directory, rather than the i386-foo/ directory. That you use DynaLoader. That you define $VERSION before the bootstrap line. -- Matt/ Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org http://xml.sergeant.org
Where can I find MOD_PERL for win32 ?
Hello, I am looking for the MOD_PERL module for Win32 systems. The link to the ftp provided on the apache.org website doesn't seem to contain the file in question. I hope someone can help. Sincerely, Walter
Re: Where can I find MOD_PERL for win32 ?
Walter Hissink wrote: I am looking for the MOD_PERL module for Win32 systems. The link to the ftp provided on the apache.org website doesn't seem to contain the file in ftp://theoryx5.uwinnipeg.ca/pub/other/ or http://www.robert.cz/misc/
RE: non-DSO mod_perl, Embperl, and AIX not working
Embperl 1.3b3 and mod_perl 1.24 should work on AIX, but I don't have any knowledge about AIX. I send a copy to Jens Uwe, who has made the patches for Embperl to work on AIX, maybe he can help Gerald I am using IBM's C complier (cc) under AIX 4.3.3 with Apache 1.3.12, mod_perl 1.24 (statically linked, not DSO), perl 5.00503, and Embperl 1.3b3. The "offline", "execute function", and "cgi mode" Embperl tests are all successful. In the "mod_perl" mode, even the simple "ascii" test fails. It fails with a seg. fault and a dbx stack trace that looks like this: ap_palloc() at 0xd1179d98 EMBPERL__malloc() at 0xd1178b98 EMBPERL_SetupFileData() at 0xd1177118 EMBPERL_SetupRequest() at 0xd1177764 XS_HTML__Embperl_SetupRequest() at 0xd116fcb8 .() at 0x1004a344 .() at 0x100536f0 .() at 0x1002ff98 perl_call_handler(??, ??, ??) at 0x10113f70 perl_run_stacked_handlers(??, ??, ??) at 0x10113160 perl_handler(??) at 0x10111d38 ap_invoke_handler(0x2011f1f0) at 0x100c42bc process_request_internal(0x2011f1f0) at 0x100f4d6c ap_process_request(0x2011f1f0) at 0x100f648c child_main(0x0) at 0x10002d24 make_child(0x200498e0, 0x0, 0x39363aa3) at 0x100025a0 startup_children(0x2) at 0x1000248c standalone_main(0x4, 0x2ff228c8) at 0x10001928 main(0x4, 0x2ff228c8) at 0x100014b0 To get Embperl.so to successfully build I added "-b erok" to LDDLFLAGS. I also tried '-G' with similar results. Without the modification to LDDLFLAGS I got several "unresolved symbol" errors. I also get similar results with Embperl 1.2b9, Apache 1.3.9, and mod_perl 1.23. BTW, I did not personally compile my perl executable, it is straight from a fileset on the AIX 4.3.3 CD. I have, however, upgraded several modules to their most recent CPAN version. My 'perl -V' output looks like this: Summary of my perl5 (5.0 patchlevel 5 subversion 3) configuration: Platform: osname=aix, osvers=4.3.3.0, archname=aix uname='aix funny 3 4 01716600 ' hint=recommended, useposix=true, d_sigaction=define usethreads=undef useperlio=undef d_sfio=undef Compiler: cc='cc', optimize='-O', gccversion= cppflags='-D_ALL_SOURCE -D_ANSI_C_SOURCE -D_POSIX_SOURCE - qmaxmem=16384' ccflags ='-D_ALL_SOURCE -D_ANSI_C_SOURCE -D_POSIX_SOURCE - qmaxmem=16384' stdchar='unsigned char', d_stdstdio=define, usevfork=false intsize=4, longsize=4, ptrsize=4, doublesize=8 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=8 alignbytes=8, usemymalloc=n, prototype=define Linker and Libraries: ld='ld', ldflags ='-s' libpth=/lib /usr/lib /usr/ccs/lib libs=-lnsl -ldbm -ldl -lld -lm -lc -lcrypt -lbsd -lPW -lC_r libc=/lib/libc.a, so=a, useshrplib=false, libperl=libperl.a Dynamic Linking: dlsrc=dl_aix.xs, dlext=so, d_dlsymun=undef, ccdlflags='- bE:perl.exp' cccdlflags=' ', lddlflags='-bhalt:4 -bM:SRE - bI:$(PERL_INC)/perl.exp -bE:$(B ASEEXT).exp -b noentry -lc' Characteristics of this binary (from libperl): Built under aix Compiled at Aug 14 1999 08:59:55 @INC: /usr/opt/perl5/lib/5.00503/aix /usr/opt/perl5/lib/5.00503 /usr/opt/perl5/lib/site_perl/5.005/aix /usr/opt/perl5/lib/site_perl/5.005 . -- Greg Estep [EMAIL PROTECTED] - 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 925151 WWW:http://www.ecos.de Fax: +49 6133 925152 -
Re: mod_perl, mod_rewrite, package namespace
Hi, I just wanted to let you know that (once again) re-RTFM the manual *twice* solved my muliple compilation problem. The solution is adding [PT] to the RewriteRule. RewriteRule ^/query/(.*) /query.pl?$1 [PT] -- http://www.apache.org/docs/mod/mod_rewrite.html: 'passthrough|PT' (pass through to next handler) This flag forces the rewriting engine to set the uri field of the internal request_rec structure to the value of the filename field. This flag is just a hack to be able to post-process the output of RewriteRule directives by Alias, ScriptAlias, Redirect, etc. directives from other URI-to-filename translators. A trivial example to show the semantics: If you want to rewrite /abc to /def via the rewriting engine of mod_rewrite and then /def to /ghi with mod_alias: RewriteRule ^/abc(.*) /def$1 [PT] Alias /def /ghi If you omit the PT flag then mod_rewrite will do its job fine, i.e., it rewrites uri=/abc/... to filename=/def/... as a full API-compliant URI-to-filename translator should do. Then mod_alias comes and tries to do a URI-to-filename transition which will not work. Note: You have to use this flag if you want to intermix directives of different modules which contain URL-to-filename translators. The typical example is the use of mod_alias and mod_rewrite..
RE: Embperl struggles
2. requrire'ing a file that defines some functions sometimes gives me
an error that the functions in that file are _not_ defined...
I append you a mail I write last month that should explain what happens...
3. I have a hard time understanding when to use [- -] and when to use
[! !] or [* *]. Most of what I've done so far uses [- -] and
[$ $] (which I so far have no trouble with). The scoping and
execution time issues are not that clear to me.
Don't use [* *] (only if you need recursions), because it is still
experminetal in the current version and has some problems. Use [! !] to
define Perl-subroutines, in all other cases use [- -].
For scoping read:
http://perl.apache.org/embperl/Embperl.pod.5.html#Variable_scope_and_cleanup
Last but not least I'd like some kind of pretty printer since my
Emacs won't help me here. I tried the two things mentioned on the
web, but to no avail (one requiring Xemacs instead of Emacs, too).
I don't use Emacs, so I can't help you on this issuse, but I am happy to put
anything up on the web, if available.
Gerald
P.S. Support for Embperl is now on the Embperl Mailing list
([EMAIL PROTECTED])
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of
Gerald Richter
Sent: Friday, April 21, 2000 9:10 PM
To: Ulrike Schepp; Steven D. Arnold
Cc: Embperl Mailingliste
Subject: RE: use module in Embperl (was: problem solved, but still
weird!)
Standard workaround here is now "apachectl restart" after the change of
modules :-/ weird but it really works!
Nothing weird here. Everything is well defined. Just let us try to
understand how Perl, mod_perl and Embperl works together:
"perldoc -f use" tells us:
Imports some semantics into the current package from the named module,
generally by aliasing certain subroutine or variable names into your
package. It is exactly equivalent to
BEGIN { require Module; import Module LIST; }
except that Module must be a bareword.
So what's important here for us is, that use executes a require
and this is
always done before any other code is executed.
"perldoc -f require" says (among other things):
..., demands that a library file be included if it hasn't already
been included.
and
Note that the file will not be included twice under the same specified
name.
So now we know (or should know) that mod_perl starts the Perl interpreter
once when Apache is started and the Perl interpreter is only
terminated when
Apache is terminated. Out of these two things follows, that a
module that is
loaded via use or require is only loaded once and will never be reloaded,
regardless if the source changes or not.
So far this is just standard Perl. Things get's a little bit more
difficult
when running under mod_perl (only Unix), because Apache forks a
set of child
processes as neccessary and from the moment they are forked, they run on
their own and don't know of each other. So if a module is loaded at server
startup time (before the fork), it is loaded in all childs (this
can be used
to save memory, because the code will actually only reside once
in memory),
but when the modul is loaded inside the child and the source changes, it
could be happen, that one child has loaded an ealier version and another
child has loaded a later version of that module, depending on the time the
module is actualy loaded by the child.
That explains, why sometimes it works and sometimes it doesn't, simply
because different childs has loaded different versions of the same module
and when you reload your page you hit different childs of Apache!
Now there is one point that is special to Embperl to add. Since Embperl
compiles every page in a different namespace, a module that
doesn't contains
a "package foo" statement is compiled in the namespace of the
page where it
is first loaded. Because Perl will not load the module a second
time, every
other page will not see subs and vars that are defined in the
loaded module.
This could be simply avoided by giving every module that should be loaded
via use/require an explicit namespace via the package statement.
So what can we do?
- If a module change, simply restart Apache. That's works always.
- use Apache::StatInc. This will do a stat on every loaded module and
compare the modification time. If the source has changed the module is
reloaded. This works most times (but not all modules can be cleanly
reloaded) and as the number of loaded modules increase, your
sever will slow
down, because of the stat it has to do for every module.
- Use "do" instead of "require". do will execute your file everytime it is
used. This also adds overhead, but this may be accpetable for
small files or
in a debugging environement. (NOTE: Be sure to check $@ after a
do, because
do works like eval)
I hope now it's seem a little bit less weird..
Gerald
Re: Can't create custom configuration directives
Matt Sergeant wrote:
On Sun, 4 Jun 2000, Rob Tanner wrote:
That you define $VERSION before the bootstrap line.
As below:
$VERSION = '0.9b';
if ( $ENV{'MOD_PERL'} ) {
no strict;
@ISA = qw(DynaLoader);
__PACKAGE__-bootstrap($VERSION);
}
That might represent a problem. $VERSION is supposed to be a real
number. Perl uses internal numeric comparison operators on them.
Matt,
Thanks for your suggestions.
I got my hopes up, changed it to '0.9' but no go :-( Even tried '1.0'
in case doesn't like number below one. Same thing. :-(
Shucks and golly! Is it possible that there is some apache or mod_perl
compile time parameter that needed to be set and wasn't, and if so, what
might that be? Since the process of adding these directives is pretty
much automated there's not much I can do to mess it up, and then I would
expect it to be glaring -- i.e., apache fails to start with an exit code
other than '0', but that's not the case. And I know that apache invokes
the callback routine because I stuck a print statement in could see it.
What's left?
Signed,
One Frustrated Dude
-- Rob
_ _ _ _ __ _ _ _ _
/\_\_\_\_\/\_\ /\_\_\_\_\_\
/\/_/_/_/_/ /\/_/ \/_/_/_/_/_/ QUIDQUID LATINE DICTUM SIT,
/\/_/__\/_/ __/\/_//\/_/ PROFUNDUM VIDITUR
/\/_/_/_/_/ /\_\ /\/_//\/_/
/\/_/ \/_/ /\/_/_/\/_//\/_/ (Whatever is said in Latin
\/_/ \/_/ \/_/_/_/_/ \/_/ appears profound)
Rob Tanner
McMinnville, Oregon
[EMAIL PROTECTED]
Re: [benchmark] DBI/preload (was Re: [RFC] improving memory mapping thru code exercising)
On Sat, Jun 03, 2000 at 02:49:47AM +0300, Stas Bekman wrote:
On Fri, 2 Jun 2000, Perrin Harkins wrote:
On Sat, 3 Jun 2000, Stas Bekman wrote:
* install_driver (2):
DBI-install_driver("mysql");
I've never seen that before,
There is always a first time :)
and it isn't in the DBI perldoc.
Where do you think I've found it :) It is mentioned in DBI manpage:
DBI-connect automatically installs the driver if it
has not been installed yet. Driver installation always
returns a valid driver handle or it dies with an error
message which includes the string 'install_driver' and
the underlying problem. So, DBI-connect will die on a
driver installation failure and will only return undef
on a connect failure, for which $DBI::errstr will hold
the error.
I've been meaning to document it properly for the last couple of
years, since I knew people were using it for mod_perl.
but actualy it's the DBD:: method.
Nope. A DBI-method.
Is it safer than "use DBD::mysql;"?
"safer" is the wrong question. It's always used by DBI, but when you call
it at the server startup you get a few more K shared, compared with only
preloading of DBD::mysql.
Yes, and the semantics of install_driver are that it'll die if the driver
can't be installed, just like 'use'.
Apache::DBI-connect_on_init('DBI:mysql:test::localhost', [...]
or DBI-disconnect("Cannot connect to database: $DBI::errstr\n");
There's no such method as DBI-disconnect.
Tim.
Re: [benchmark] DBI/preload (was Re: [RFC] improving memory mapping thru code exercising)
On Sun, 4 Jun 2000, Tim Bunce wrote:
On Sat, Jun 03, 2000 at 02:49:47AM +0300, Stas Bekman wrote:
On Fri, 2 Jun 2000, Perrin Harkins wrote:
On Sat, 3 Jun 2000, Stas Bekman wrote:
* install_driver (2):
DBI-install_driver("mysql");
I've never seen that before,
There is always a first time :)
and it isn't in the DBI perldoc.
Where do you think I've found it :) It is mentioned in DBI manpage:
DBI-connect automatically installs the driver if it
has not been installed yet. Driver installation always
returns a valid driver handle or it dies with an error
message which includes the string 'install_driver' and
the underlying problem. So, DBI-connect will die on a
driver installation failure and will only return undef
on a connect failure, for which $DBI::errstr will hold
the error.
I've been meaning to document it properly for the last couple of
years, since I knew people were using it for mod_perl.
I guess most of the mod_perl folks don't use it, since they don't
know about it. I have discovered it following the Vivek's reply.
but actualy it's the DBD:: method.
Nope. A DBI-method.
Ok
Is it safer than "use DBD::mysql;"?
"safer" is the wrong question. It's always used by DBI, but when you call
it at the server startup you get a few more K shared, compared with only
preloading of DBD::mysql.
Yes, and the semantics of install_driver are that it'll die if the driver
can't be installed, just like 'use'.
Apache::DBI-connect_on_init('DBI:mysql:test::localhost', [...]
or DBI-disconnect("Cannot connect to database: $DBI::errstr\n");
There's no such method as DBI-disconnect.
Ouch, you are right. But the first part has never failed for me, so I copy
and paste this old error for years :) Thanks for telling me!
_
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:Apache::Session and Postgres (was: Embperl Session ID problem with %udat and postgres)
I don't have tried Apache::Session and Postgres. I forward your message to the mod_perl list, where Apache::Session is supported Gerald -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Florian Dorrer Sent: Thursday, June 01, 2000 5:37 PM To: [EMAIL PROTECTED] Subject: Embperl Session ID problem with %udat and postgres Hi, my configuration looks like: Suse Linux 6.3 Apache_1.3.12 Apache-Session-1.04 mod_perl-1.22 HTML-embperl-1_3b3 postgres-6.5.3 DBD-Pg-0.93 On an EPL-Site I post data into %udat, when I try to acess the data on another EPL-Site I get the error-message: Error in Perl code: DBD::Pg::st execute failed: ERROR: Cannont insert a duplicate key into a unique index The database field "Session_id" has a unique index. If I remove the index from that field, EmbPerl puts for each %udat call an entry into the database with equal session_ids. It looks like there is never an update to the db_entry, but always an insert. The cookie is set and received sucessfully (says the logfile). Can anybody help me?! Florian Dorrer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - 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 925151 WWW:http://www.ecos.de Fax: +49 6133 925152 -
Re: [RFC: performance] Initializing DBI.pm
On Sat, Jun 03, 2000 at 03:54:37AM +0300, Stas Bekman wrote:
Here is a complete version. comments are very welcome before it enters the
guide:
The first example is the CDBI module. As you know CDBI works with
many database drivers falling into the CDBD:: category,
e.g. CDBD::mysql. It's not enough to preload CDBI, you should
initialize CDBI with driver(s) that you are going to use (usually a
single driver is used).
... if you want to minimize memory use after forking.
I'd rather not create the impression that people "should" initialize
drivers in other circumstances.
You probably know already that under mod_perl you should use the
CApache::DBI module to get the connection persistence, unless you
open a separate connection for each user--in this case you should not
use this module. CApache::DBI automatically loads CDBI and
overrides all it's methods, so you should continue coding like there
is only a CDBI module.
s/all it's methods/some of its methods/.
=item option 4
Tell Apache::DBI to connect to the database when the child process
starts (ChildInitHandler), no driver is preload before the child gets
spawned!
Apache::DBI-connect_on_init('DBI:mysql:test::localhost',
"",
"",
{
PrintError = 1, # warn() on errors
RaiseError = 0, # don't die on error
AutoCommit = 1, # commit executes
# immediately
}
)
or DBI-disconnect("Cannot connect to database: $DBI::errstr\n");
There's no DBI-disconnect method. Just die().
Thanks for doing all this work Stas. Much appreciated.
Tim.
Re: [RFC: performance] Initializing DBI.pm
On Sun, 4 Jun 2000, Tim Bunce wrote:
On Sat, Jun 03, 2000 at 03:54:37AM +0300, Stas Bekman wrote:
Here is a complete version. comments are very welcome before it enters the
guide:
The first example is the CDBI module. As you know CDBI works with
many database drivers falling into the CDBD:: category,
e.g. CDBD::mysql. It's not enough to preload CDBI, you should
initialize CDBI with driver(s) that you are going to use (usually a
single driver is used).
... if you want to minimize memory use after forking.
I'd rather not create the impression that people "should" initialize
drivers in other circumstances.
Perfect! Will correct this. Thanks!
You probably know already that under mod_perl you should use the
CApache::DBI module to get the connection persistence, unless you
open a separate connection for each user--in this case you should not
use this module. CApache::DBI automatically loads CDBI and
overrides all it's methods, so you should continue coding like there
is only a CDBI module.
s/all it's methods/some of its methods/.
right!
=item option 4
Tell Apache::DBI to connect to the database when the child process
starts (ChildInitHandler), no driver is preload before the child gets
spawned!
Apache::DBI-connect_on_init('DBI:mysql:test::localhost',
"",
"",
{
PrintError = 1, # warn() on errors
RaiseError = 0, # don't die on error
AutoCommit = 1, # commit executes
# immediately
}
)
or DBI-disconnect("Cannot connect to database: $DBI::errstr\n");
There's no DBI-disconnect method. Just die().
ok
Thanks for doing all this work Stas. Much appreciated.
Thanks :)
This all won't be possible without you and other great folks writing and
maintaining this amaizing software... So the biggest thanks goes to you :)
_
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: [RFC: performance] Initializing DBI.pm
On Sun, Jun 04, 2000 at 10:57:57PM +0300, Stas Bekman wrote: This all won't be possible without you and other great folks writing and maintaining this amaizing software... So the biggest thanks goes to you :) I've not done much of either this last year, however, I'm hoping to get a new beta DBI release out this week. Maybe... Tim.
Re: Warning about guide exceptions docs...
On Sat, 3 Jun 2000, Matt Sergeant wrote: Just a "heads up" about the exceptions section of the guide. Don't try and create more than one generic exception handler on your server. As I've just discovered it really confuses things. Create one class and one class only for handling exceptions globally. Matt, will you please send me an update? I still didn't get a chance to dig into your exceptions guide. Maybe I should put out a CPAN release: SimpleException.pm or something? Sounds good! Will you really do it? _ 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
Apache::ASP
I ran the example ASP script but had such errors. Which expert can explain it? Thanks. [Sun Jun 4 15:15:11 2000] [error] [asp] [937] [debug] RUN ASP (v0.18) for /usr/local/apache/http/webhome/eg/index.html [Sun Jun 4 15:15:11 2000] [error] [asp] [937] [debug] GlobalASA package Apache::ASP::Demo [Sun Jun 4 15:15:11 2000] [error] [asp] [937] [debug] compiling global.asa Apache::ASP::Demo [Sun Jun 4 15:15:12 2000] [error] [asp] [937] [debug] global.asa routines - Application_OnEnd: 1; Application_OnStart: 1; Script_OnEnd: 1; Script_OnStart: 1; Session_OnEnd: 1; Session_OnStart: 1; [Sun Jun 4 15:15:12 2000] [error] [asp] [937] [debug] ASP object created - GlobalASA: Apache::ASP::GlobalASA=HASH(0x8f6add4); Request: Apache::ASP::Request=HASH(0x8f6caa0); Response: Apache::ASP::Response=HASH(0x8f93a0c); Server: Apache::ASP::Server=HASH(0x8f93910); basename: index.html; compile_includes: 1; dbg: 2; debugs_output: ARRAY(0x8f6c92c); filename: /usr/local/apache/http/webhome/eg/index.html; global: /usr/local/apache/http/webhome/eg//.; global_package: Apache::ASP::Demo; id: NoCache; includes_dir: ; init_packages: ARRAY(0x8f9388c); no_cache: 1; no_state: 1; package: Apache::ASP::Demo; pod_comments: 1; r: Apache=SCALAR(0x8f668d0); sig_warn: ; stat_inc: ; stat_inc_match: ; stat_scripts: 1; unique_packages: ; use_strict: ; [Sun Jun 4 15:15:12 2000] [error] [asp] [937] [debug] parsing index.html [Sun Jun 4 15:15:12 2000] [error] [asp] [937] [debug] runtime exec of dynamic include header.inc args () [Sun Jun 4 15:15:12 2000] [error] [asp] [937] [debug] parsing header.inc [Sun Jun 4 15:15:12 2000] [error] [asp] [937] [debug] loaded module Apache::Symbol [Sun Jun 4 15:15:12 2000] [error] [asp] [937] [debug] active undefing sub Apache::ASP::Demo::_usr_local_apache_http_webhome_egheader_inc code CODE(0x8f97c98) [Sun Jun 4 15:15:12 2000] [error] Undefined subroutine Apache::Symbol::undef called at /usr/lib/perl5/site_perl/5.005/Apache/ASP.pm line 1103. [Sun Jun 4 15:15:12 2000] [error] [asp] [937] [debug] destroying - asp: Apache::ASP=HASH(0x8f6c8e4); Eric He
Apache::ASP
I ran the example ASP script but had such errors. Which expert can explain it? Thanks. [Sun Jun 4 15:15:11 2000] [error] [asp] [937] [debug] RUN ASP (v0.18) for /usr/local/apache/http/webhome/eg/index.html [Sun Jun 4 15:15:11 2000] [error] [asp] [937] [debug] GlobalASA package Apache::ASP::Demo [Sun Jun 4 15:15:11 2000] [error] [asp] [937] [debug] compiling global.asa Apache::ASP::Demo [Sun Jun 4 15:15:12 2000] [error] [asp] [937] [debug] global.asa routines - Application_OnEnd: 1; Application_OnStart: 1; Script_OnEnd: 1; Script_OnStart: 1; Session_OnEnd: 1; Session_OnStart: 1; [Sun Jun 4 15:15:12 2000] [error] [asp] [937] [debug] ASP object created - GlobalASA: Apache::ASP::GlobalASA=HASH(0x8f6add4); Request: Apache::ASP::Request=HASH(0x8f6caa0); Response: Apache::ASP::Response=HASH(0x8f93a0c); Server: Apache::ASP::Server=HASH(0x8f93910); basename: index.html; compile_includes: 1; dbg: 2; debugs_output: ARRAY(0x8f6c92c); filename: /usr/local/apache/http/webhome/eg/index.html; global: /usr/local/apache/http/webhome/eg//.; global_package: Apache::ASP::Demo; id: NoCache; includes_dir: ; init_packages: ARRAY(0x8f9388c); no_cache: 1; no_state: 1; package: Apache::ASP::Demo; pod_comments: 1; r: Apache=SCALAR(0x8f668d0); sig_warn: ; stat_inc: ; stat_inc_match: ; stat_scripts: 1; unique_packages: ; use_strict: ; [Sun Jun 4 15:15:12 2000] [error] [asp] [937] [debug] parsing index.html [Sun Jun 4 15:15:12 2000] [error] [asp] [937] [debug] runtime exec of dynamic include header.inc args () [Sun Jun 4 15:15:12 2000] [error] [asp] [937] [debug] parsing header.inc [Sun Jun 4 15:15:12 2000] [error] [asp] [937] [debug] loaded module Apache::Symbol [Sun Jun 4 15:15:12 2000] [error] [asp] [937] [debug] active undefing sub Apache::ASP::Demo::_usr_local_apache_http_webhome_egheader_inc code CODE(0x8f97c98) [Sun Jun 4 15:15:12 2000] [error] Undefined subroutine Apache::Symbol::undef called at /usr/lib/perl5/site_perl/5.005/Apache/ASP.pm line 1103. [Sun Jun 4 15:15:12 2000] [error] [asp] [937] [debug] destroying - asp: Apache::ASP=HASH(0x8f6c8e4); Eric He
Re: Wierd user agent strings
Good question, we have a database for browser usage analysis. It currently
holds roughly 55.000 unique tags. A good 4000 of em are bogus strings like
posted below. So I love to hear some theories too!
Oh fyi, May's score was 80% MSIE, 18% NS..
Cheers,
-Renzo
Does anyone know what User-Agent strings like these may mean:
(r\177xx\303\203x0\226H
(r\177xx\303\203xT\365G
(r\177xx\303\203xt]D
(r\210xP\223G
(r\210x\354\250D
(r\210xx\303\214xH?E
(r\210xx\303\214xP+E
(r\210xx\303\214xXCE
(r\210xx\303\214x\$EE
(r\210xx\303\214x\204VF
(r\210xx\303\214x\204yG
(r\210xx\303\214x\20\256E
(where \210 etc are octal character values).
Tim.
...
__... __
... ...
.. .. Renzo Toma http://www.veronica.nl
Veronica Digitaal B.V. unix.modperl.apache.sql.mason
... _
.
Subroutine redefined?
Greetings. I'm running Apache/1.3.12 with mod_perl/1.24 and mod_ssl/2.6.4 on a Debian
system.
(I know mod_ssl and mod_perl on the same server is begging for trouble, but that's the
way the
site was designed, well before I got there...) We recently recompiled the server with
mod_perl's EVERYTHING=1 to support some code I'm working on which uses stacked
handlers.
We use Apache::DBI (via PerlModule) to cache connections to a MySQL database. For some
reason,
when a PerlHandler runs that accesses the database (or perhaps on ChildInit), we get
several
dozen warnings of the following type dumped to the log:
Subroutine dump_results redefined at /usr/lib/perl5/5.005/i386-linux/DBI.pm
line 1100,
FILE chunk 13.
The warnings all seem to be coming from DBI.pm. It was also doing this with CGI.pm on
server
load, but that's Gone Away, for reasons unclear. We get this errors with
PerlFreshRestart
either On or Off. Obviously turning PerlWarn Off makes them stop, but it also makes
code
testing difficult. Everything seems to run fine in spite of the warnings, but they
make the
logs unreadable.
Currently, the best solution I have is the following, shamelessly borrowed from slash:
Perl
$SIG{__WARN__} = sub { warn @_ unless $_[0] =~ /Subroutine [\w:]+
redefined/io };
/Perl
However, that's a band-aid, not a fix. I checked for multiple installations of DBI
just in case
-- no luck. I have RTFM, twice. I searched through the list archives and have not
found discussion of this particular problem. What I'd like to know is what's causing
these warnings and how to make them stop (not just how to keep them from being dummped
to the log).
Information on our perl and apache installations follows. Any suggestions would be
appreciated. Thanks.
SDE
---
perl -V
---
Summary of my perl5 (5.0 patchlevel 5 subversion 3) configuration:
Platform:
osname=linux, osvers=2.2.15pre14, archname=i386-linux
uname='linux them 2.2.15pre14 #2 smp mon mar 13 14:29:00 est 2000 i686 unknown '
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef useperlio=undef d_sfio=undef
Compiler:
cc='cc', optimize='-O2 ', gccversion=2.95.2 2313 (Debian GNU/Linux)
cppflags='-Dbool=char -DHAS_BOOL -D_REENTRANT -DDEBIAN -I/usr/local/include'
ccflags ='-Dbool=char -DHAS_BOOL -D_REENTRANT -DDEBIAN -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 -lndbm -lgdbm -ldbm -ldb -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 Apr 30 2000 12:08:38
@INC:
/usr/lib/perl5/5.005/i386-linux
/usr/lib/perl5/5.005
/usr/local/lib/site_perl/i386-linux
/usr/local/lib/site_perl
/usr/lib/perl5
.
httpd -V
Server version: Apache/1.3.12 (Unix)
Server built: Jun 2 2000 22:20:19
Server's Module Magic Number: 19990320:7
Server compiled with
-D EAPI
-D HAVE_MMAP
-D HAVE_SHMGET
-D USE_SHMGET_SCOREBOARD
-D USE_MMAP_FILES
-D USE_FCNTL_SERIALIZED_ACCEPT
-D HTTPD_ROOT="/usr/local/apache"
-D SUEXEC_BIN="/usr/local/apache/bin/suexec"
-D DEFAULT_PIDLOG="logs/httpd.pid"
-D DEFAULT_SCOREBOARD="logs/httpd.scoreboard"
-D DEFAULT_LOCKFILE="logs/httpd.lock"
-D DEFAULT_XFERLOG="logs/access_log"
-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"
Re: [RFC: performance] Initializing DBI.pm
On Sun, Jun 04, 2000 at 08:58:11PM +0100, Tim Bunce wrote: On Sun, Jun 04, 2000 at 10:57:57PM +0300, Stas Bekman wrote: This all won't be possible without you and other great folks writing and maintaining this amaizing software... So the biggest thanks goes to you :) I've not done much of either this last year, however, I'm hoping to get a new beta DBI release out this week. Maybe... Tim I hope you plan to integrate Doug's patch which makes it possible to use DBI with Perl 5.6 -Dusethreads. Thanks! Tim. -- Eric Cholet
