Re: modperl success story
Barb and Tim wrote: full honesty. The language itself is hard enough to swallow. How is Perl hard to swallow? Perl is so easy and flexible. Stephen
Re: modperl success story
On Fri, 14 Jan 2000, Barb and Tim wrote: It could really enhance your integrity if you also presented honest evaluations of the downsides of Perl. The promotion of Perl on this site is so ubiquitous and one sided, and Perl has such a bad reputation in many ways, that somebody like me has a hard time swallowing the sunny prognostications and finally diving in, unless I see full honesty. The language itself is hard enough to swallow. This is not an advocacy group. Problems with mod_perl and (more rarely) perl (the standard imlementation) and Perl (the language as an abstract definition) do show up here, if you wait long enough. This group is for people who are trying to implement, use and improve mod_perl. I think you'll find that many of the people on the list have gone through some exhaustive searching BEFORE stumbling upon mod_perl. Many, if not most, have significant backgrounds in many other development (web and other) systems and languages. I like perl, Perl, and mod_perl. I think most of the people on this list do, as well. You're not likely to get a bunch of apologies for that. If you don't like something about any of the 3 parts, please try and help fix it. Or just find something else that you do like. Perhaps you'll find that other systems are better suited to what you do. Perhaps not, and you'll end up back here again. I'm sure that would be fine with anyone on the list. -- -- Tom Mornini -- InfoMania Printing and Prepress
Re: how come httpd doesn't start even though startup.pl is fine?
You're going to love this... your startup.pl file is fine... almost. You're forgetting a key part of the script... issue this shell command and it'll work: echo "1;" startup.pl The startup script needs to return true from its eval. :) --SC -- Sean Chittenden [EMAIL PROTECTED] What you don't know won't help you much either. -- D. Bennett On Thu, 13 Jan 2000, Ricardo Kleemann wrote: Date: Thu, 13 Jan 2000 16:47:35 -0800 (PST) From: Ricardo Kleemann [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: how come httpd doesn't start even though startup.pl is fine? Hi everyone, I don't know what's causing this, and there are no errors being logged in my error_log. I'm running apache 1.3.9, mod_perl 1.21, linux 6.1 I have a startup.pl with a bunch of modules in it. If I run the startup.pl by itself it is fine, does not report errors... however, if I run httpd it dies, never gets off the ground. If I go thru my list of modules and remove some of them, then everything starts up fine... Here's my list: the ones commented out will cause httpd to not startup... IF I leave the list as is, it starts up fine. If I uncomment any one of these, httpd doesn't complain, doesn't log anything, but never starts up correctly use CGI (); #use Fcntl; #use IO::ScalarArray; use Time::Zone; #use MD5; use LWP::Simple; #use LWP::UserAgent; use Date::Parse; #use MIME::Head; #use MIME::Body; #use MIME::Entity; #use MIME::Parser; #use Data::Dumper; use Mail::Address; #use HTML::Parse; #use Net::SMTP;
Re: modperl success story
So, present us all with a detailed analysis of all Perl's failings and
its bad reputation compaired the competition, so that we may see the
light and turn to the true path. Until then we'll all stagger along
happily in the darkness.
Even better, write your own language like Larry did and see how many
disciples you attract.
Rod Butcher
Barb and Tim wrote:
It could really enhance your integrity if you also
presented honest evaluations of the downsides of Perl.
The promotion of Perl on this site is so ubiquitous and
one sided, and Perl has such a bad reputation in many ways,
that somebody like me has a hard time swallowing the sunny
prognostications and finally diving in, unless I see
full honesty. The language itself is hard enough to swallow.
Just a suggestion.
--
Rod Butcher | "... I gaze at the beauty of the world,
Hyena Holdings Internet | its wonders and its miracles and out of
Programming | sheer joy I laugh even as the day laughs.
("it's us or the vultures") | And then the people of the jungle say,
[EMAIL PROTECTED] | 'It is but the laughter of a hyena'".
|Kahlil Gibran.. The Wanderer
Re: modperl success story
It could really enhance your integrity if you also presented honest evaluations of the downsides of Perl. The promotion of Perl on this site is so ubiquitous and one sided, and Perl has such a bad reputation in many ways, that somebody like me has a hard time swallowing the sunny prognostications and finally diving in, unless I see full honesty. The language itself is hard enough to swallow. Just a suggestion. You are not the first to say this, we've discussed this already, no need to do this again. Adam Pisoni has summarized this thread in his wonderful "Popular Perl Complaints and Myths" document. Please read it at: http://perl.apache.org/perl_myth.html Please move the thread to [EMAIL PROTECTED] Have a nice Perl :) ___ Stas Bekmanmailto:[EMAIL PROTECTED] http://www.stason.org/stas Perl,CGI,Apache,Linux,Web,Java,PC http://www.stason.org/stas/TULARC perl.apache.orgmodperl.sourcegarden.org perlmonth.comperl.org single o- + single o-+ = singlesheavenhttp://www.singlesheaven.com
Re: how come httpd doesn't start even though startup.pl is fine? (fwd)
Ricardo Kleemann [EMAIL PROTECTED] writes: Hi everyone, I don't know what's causing this, and there are no errors being logged in my error_log. I'm running apache 1.3.9, mod_perl 1.21, linux 6.1 I have a startup.pl with a bunch of modules in it. If I run the startup.pl by itself it is fine, does not report errors... however, if I run httpd it dies, never gets off the ground. try runninng 'httpd -X' under gdb. If I go thru my list of modules and remove some of them, then everything starts up fine... Without having checked your list, I'll wager that the "good" modules are all pure perl and the "bad" ones use machine-language XS extensions. You will need to link mod_perl statically to apache or wait for a resolution to this problem -- see the thread "Apache 1.3.9 + mod_perl 1.21 + Solaris 2.7 dumps core". -- Frank Cringle, [EMAIL PROTECTED] voice: (+49 2304) 467101; fax: 943357
Re: perl parser for CC/PP information
Hi there, On Fri, 14 Jan 2000, CAMERON, CRAIG wrote: I'm about to write a parser for CC/PP http://www.w3.org/TR/NOTE-CCPP/ (Composite Capability/Preference Profiles) as a perl module for apache. Basically the information is stored in rdf http://www.w3.org/TR/PR-rdf-schema which is the W3c's way of describing meta-data and I want to pull the information from custom headers fields in the HTTP/1.1 request and then use it to deliver custom html. Has anybody done this already? Don't know. don't know perl at all but languages like Java seem like overkill I'm interested in the meta-data topic, if you'd like to send me some pseudocode I can turn it into pseudoPerl for you. I only have about a week to do it so complex solutions are physically impossible to implement Good, limits my exposure:) (learning perl is probably easier) There's a school of thought that says you should be doing that anyway. It grieves when I think how much time I wasted processing text with compiled C when I should have been reading about Perl... 73 Ged.
$r-notes()...
If I use $r-notes in a mod_perl handler, is it accessible via the
core apache request object in other non-perl modules?
$r-notes('foo','bar');
Is the value of notes stored in the core apache process and if so,
is it accessible by other modules by their similar r-notes methods (ie,
mod_java or some custom C module)? If not, why not? I wouldn't expect to
be able to store hashes, etc (use a global var, such as
$sitename::globalvar for that), but strings?
My question being stemmed from the possibility of having to use
mod_java and mod_perl on the same server and getting the two to talk to
each other in a friendly manner. Anyone have any experience w/ this or
tips w/ regards to the best way of going about this kind of a setup?
--
Sean Chittenden [EMAIL PROTECTED]
VMS, n:
The world's foremost multi-user adventure game.
Re: Embperl + Apache::Session
On Fri, Jan 14, 2000 at 07:00:13AM +0100, Gerald Richter wrote: You need to setup session handling at all, e.g. PerlSetEnv EMBPERL_SESSION_CLASSES "FileStore SysVSemaphoreLocker" That is PerlSetEnv EMBPERL_SESSION_CLASSES "FileStore NullLocker" in my httpd.conf When you restart your apache, you should see a message about EMbperl Session management enabled. Without this message it won't work You talk about this one, don't you? -- root@linbec31:/download/Perl/HTML-Embperl-1.2.1 # /etc/rc.d/init.d/httpd start [1392]SES: Embperl Session management enabled (1.xx) /etc/rc.d/init.d/httpd start: httpd started -- I saw that message every time since I started playing around with session handling, but despite the message it does not work You will only get the cookie header if you write to the %udat hash inside your page I have done this, using the sample page implementing a counter posted yesterday on this list. As I explained session management works as far as generating the id and saving it into %udat, but it simply does not set the cookie Since this happens on two machines with at least slightly different Linux distributions (one is Mandrake 6.0, the other a Redhat 5.2) I think it is a configuration problem... so if someone could please email me her complete configuration files I'd have more means to test Andre
RE: Embperl + Apache::Session
Since this happens on two machines with at least slightly different Linux distributions (one is Mandrake 6.0, the other a Redhat 5.2) I think it is a configuration problem... so if someone could please email me her complete configuration files I'd have more means to test What you describe looks good to me. There is one other issue, that is dynamlic linking mod_perl. How comes mod_perl into your Apache? Is it dynamicly loaded at runtime (i.e. by a LoadModule in your httpd.conf) or is it staticly loaded? If the first is true, look if Embperl is loaded somewhere in your httpd.conf (either by a PerlModule or by a file that is loaded with PerlRequire). Remove this. In case of dynamicly linking Embperl must not loaded at startup time. (mod_perl will do this at request time for you) Gerald - Gerald Richterecos electronic communication services gmbh Internetconnect * Webserver/-design/-datenbanken * Consulting Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925151 WWW:http://www.ecos.de Fax: +49 6133 925152 -
Re: $r-notes()...
[EMAIL PROTECTED] (Sean Chittenden) wrote:
If I use $r-notes in a mod_perl handler, is it accessible via the
core apache request object in other non-perl modules?
$r-notes('foo','bar');
Yup, it's stored in the regular Apache notes table. That's why it has to be
flattened to a string, so it can't store arbitrary data structures (without
some work).
I've never passed values to a non-Perl module myself, but it seems like one of
the main purposes for $r-notes.
------
Ken Williams Last Bastion of Euclidity
[EMAIL PROTECTED]The Math Forum
RE: $r-notes()...
Sean Chittenden wrote:
If I use $r-notes in a mod_perl handler, is it accessible via the
core apache request object in other non-perl modules?
$r-notes('foo','bar');
Is the value of notes stored in the core apache process and if so,
is it accessible by other modules by their similar r-notes methods (ie,
mod_java or some custom C module)? If not, why not? I wouldn't expect to
be able to store hashes, etc (use a global var, such as
$sitename::globalvar for that), but strings?
My question being stemmed from the possibility of having to use
mod_java and mod_perl on the same server and getting the two to talk to
each other in a friendly manner. Anyone have any experience w/ this or
tips w/ regards to the best way of going about this kind of a setup?
I've got this working. I'm passing notes between mod_pop3 and mod_perl, and
it's really handy.
First, I've got a mod_perl fixup handler that tosses some info in the
environment which is later read by mod_pop3. (I could have done this with
notes, but I chose env.) Then, the PHP application sometimes calls the
mod_perl app, by marking up a bunch of notes in its own request and then
issuing a sub-request to a mod_perl page. The mod_perl request handler that
gets this internal sub-request reads those notes and writes its replies in
the same place.
I read setup this request with:
if (isset($user) substr($user,0,1) == "+") {
apache_note("imp_euser", substr($user,1));
virtual("/internal/getquota");
$quota = apache_note("imp_quota");
$quota_pp = apache_note("imp_quota_pp");
$usage_pp = apache_note("imp_usage_pp");
$percent_pp = apache_note("imp_percent_pp");
if ($quota)
$message .= " | Using $percent_pp% of $quota_pp limit";
}
and then read and write the notes with $r-main-notes from mod_perl.
- David Harris
Principal Engineer, DRH Internet Services
RE: Embperl + Apache::Session
PerlModule HTML::Embperl This line loads Embperl at startup, remove it! I could also build embperl staticly, maybe that helps. This will surly solve a lot of problems. But a quick try some minutes ago with just recompiling mod_perl with USE_DSO=0 and configuring apache with --disable_shared=perl was not successful. The configure script told me of mod_perl buildtype being OBJ, but I could not start the server afterwards because it complained about not knowing those PerlSetEnv and PerlModule lines above. Any ideas about that? Try to run Makefile.PL with the following parameters (change the directories of course): APACHE_SRC=/usr/src/packages/apache_1.3.9_mp/src USE_APACI=1 DO_HTTPD=1 APACHE_PREFIX=/usr/local/apache then type make and make install and you should have a new httpd in /usr/local/apache/bin Gerald
Re: oracle : The lowdown
David Harris wrote: Jeff Warner wrote: We were a mySQL shop. We replaced mySQL with Oracle8i/mod_perl and and Apache::DBI. Works great, once it is all setup. Our overall processing is faster with Oracle too. The lack of transactions and views put an immediate end of mySQL once we got into the details of my project. Oracle is overkill for smaller task but you don't have to worry about outgrowing it. What about PostgreSQL (www.postgresql.org)? It looks like it has transaction management (commit, rollback) with the whole concurrency control thing. I don't know if has views. I've got a small project that I am figuring on using PostgreSQL for, so I'm curious to hear what people might have to say about it. Another option to look at is Solid (www.solidtech.com). They just quoted me their Solid Embedded Server (their name for a database server) for $2,000 per CPU. I used their database server a few years ago and it was very nice. Back then it cost only $200, too... :-) Has anyone tried this (especially on other distributions/kernel/libc versions): http://www.interbase.com/downloads/summaries/19.html I'd be most interested in your experiences. Of course, InterBase is going open-source, soon. :-)
Re: DSO slows things down?
On Fri, Jan 14, 2000 at 06:31:50PM +0200, Stas Bekman wrote: Just read the mod_ssl vs. apache_ssl thread at /.org: http://slashdot.org/apache/99/12/22/1711203.shtml jimjag claims that DSO is slower than static builds at the runtime: QUOTE Q: Why has using DSOs anything to do with run-time performance? I always thought using DSOs just slows down the startup. A: Not at all. The code produced with DSOs, as well as the way modules are implemented, is less optimal than the non-DSO alternative. If you need best performance, avoid DSO. This is covered in the Apache performance docs. /QUOTE What do DSO benefactors have to say :) This depends on the machine architecture in question - DSO's require that the machine code produced is relocatable. This is so that a shared object can be loaded at varying virtual addresses in different processes. On some register starved machine architectures like x86 this causes more pressure to load and store registers in memory as one has to reserve an additional register for getting at your global data. Other architecures like SGI with MIPS processors or AIX with POWER/PowerPC processors do not even make the distinction, all code is always relocatable in their runtime model. I am not 100% familar with the GCC x86 code generator, but isn't the penalty mostly for accesses to global data and absolute function calls outside the module? I would suspect that in a well programmed module the globals should be very rare, and time critical functions are either local or called via function pointers, where the penalty does not apply. One additional point is that all the system libraries are normally used as shared libraries which also use relocatable code. There are few people that do really statically link in the system libraries into their programs (if that is possible at all on the machine in question). -- Jens-Uwe Mager HELIOS Software GmbH Steinriede 3 30827 Garbsen Germany Phone: +49 5131 709320 FAX:+49 5131 709325 Internet: [EMAIL PROTECTED]
Re: how come httpd doesn't start even though startup.pl is fine? (fwd)
Ricardo Kleemann [EMAIL PROTECTED] writes: Hmmm :-( On 14 Jan 2000, Frank D. Cringle wrote: Without having checked your list, I'll wager that the "good" modules are all pure perl and the "bad" ones use machine-language XS extensions. So typical modules like MD5 and MIME::Body are "bad" modules? There is nothing wrong with the modules, that's why I put "bad" in inverted commas. They are only "bad" in the sense that they trigger a bug in dynamically-linked mod_perl. -- Frank Cringle, [EMAIL PROTECTED] voice: (+49 2304) 467101; fax: 943357
Re: modperl success story
Barb and Tim wrote: It could really enhance your integrity if you also presented honest evaluations of the downsides of Perl. WHy don't you start. -jwb
Re: modperl success story
According to Barb and Tim: It could really enhance your integrity if you also presented honest evaluations of the downsides of Perl. Perl has two downsides. One is the start-up time for the program and mod_perl solves this for web pages. The promotion of Perl on this site is so ubiquitous and one sided, and Perl has such a bad reputation in many ways, that somebody like me has a hard time swallowing the sunny prognostications and finally diving in, unless I see full honesty. The language itself is hard enough to swallow. Just a suggestion. The other down side is that it is fast and easy to write working programs that are difficult for someone else to understand. That is, it accepts an individual's style instead of forcing something universal. I guess everyone here is willing to accept that tradeoff. Les Mikesell [EMAIL PROTECTED]
Apache::ASP: crash when placed in startup.pl
Hi, I'm trying to preload and precompile all ASP scripts by including Apache::ASP in the startup.pl. However, when I do so, httpd core dumps with a segmentation fault in SDBM_File: Program received signal SIGSEGV, Segmentation fault. 0x403dfe27 in boot_SDBM_File () from /usr/lib/perl5/5.00503/i386-linux/auto/SDBM_File/SDBM_File.so (gdb) Quite frankly, I have no idea where to go from here. Any suggestions? Thanks Dmitry Beransky
Re: Apache::ASP: crash when placed in startup.pl
Doh! I forgot to say what I'm running: Apache::ASP v. 0.17 SDMB_File v. 1.0 mod_perl v. 1.21 Apache v. 1.39 RedHat 6.1 on Linux 2.2.12 x86 At 11:30 AM 1/14/00 , you wrote: Hi, I'm trying to preload and precompile all ASP scripts by including Apache::ASP in the startup.pl. However, when I do so, httpd core dumps with a segmentation fault in SDBM_File: Program received signal SIGSEGV, Segmentation fault. 0x403dfe27 in boot_SDBM_File () from /usr/lib/perl5/5.00503/i386-linux/auto/SDBM_File/SDBM_File.so (gdb) Quite frankly, I have no idea where to go from here. Any suggestions? Thanks Dmitry Beransky
Re: modperl success story
The troll vanisheth! - Transcript of session follows - ... while talking to mc5.law5.hotmail.com.: RCPT To:[EMAIL PROTECTED] 550 Requested action not taken:user account inactive 550 [EMAIL PROTECTED]... User unknown
Re: how come httpd doesn't start even though startup.pl is fine?
Drat... I was kinda hoping that would've been it. Oh
well Alright, how about this:
1) Set your logging level to debug (is it right now? I bet not)
2) Wrap your startup.pl file in some perl tags in your
httpd.conf file and eval the code. See if it sets $@. If so, then print
the result. Another thing you could do is install a signal handler for
$SIG{DIE} and print a stack trace using Carp::Croak. I've had to do the
latter more times than I care to admit, but it works really well in
catching errors.
I'd try #1, personally (much easier). --SC
--
Sean Chittenden [EMAIL PROTECTED]
Don't buy a landslide. I don't want to have to pay for one more vote
than I have to.
-- Joseph P. Kennedy, on JFK's election strategy.
On Fri, 14 Jan 2000, Ricardo Kleemann wrote:
Date: Fri, 14 Jan 2000 07:59:39 -0800 (PST)
From: Ricardo Kleemann [EMAIL PROTECTED]
To: Sean Chittenden [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: how come httpd doesn't start even though startup.pl is fine?
Thanks but unfortunately that's not it... :-(
I only put in a snippet of the startup.pl. My file does indeed have a 1;
at the bottom...
Ricardo
On Fri, 14 Jan 2000, Sean Chittenden wrote:
You're going to love this... your startup.pl file is
fine... almost. You're forgetting a key part of the script... issue this
shell command and it'll work:
echo "1;" startup.pl
The startup script needs to return true from its
eval. :)
--SC
--
Sean Chittenden [EMAIL PROTECTED]
What you don't know won't help you much either.
-- D. Bennett
On Thu, 13 Jan 2000, Ricardo Kleemann wrote:
Date: Thu, 13 Jan 2000 16:47:35 -0800 (PST)
From: Ricardo Kleemann [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: how come httpd doesn't start even though startup.pl is fine?
Hi everyone,
I don't know what's causing this, and there are no errors being logged in
my error_log.
I'm running apache 1.3.9, mod_perl 1.21, linux 6.1
I have a startup.pl with a bunch of modules in it. If I run the startup.pl
by itself it is fine, does not report errors... however, if I run httpd it
dies, never gets off the ground. If I go thru my list of modules and
remove some of them, then everything starts up fine...
Here's my list: the ones commented out will cause httpd to not startup...
IF I leave the list as is, it starts up fine. If I uncomment any one of
these, httpd doesn't complain, doesn't log anything, but never starts up
correctly
use CGI ();
#use Fcntl;
#use IO::ScalarArray;
use Time::Zone;
#use MD5;
use LWP::Simple;
#use LWP::UserAgent;
use Date::Parse;
#use MIME::Head;
#use MIME::Body;
#use MIME::Entity;
#use MIME::Parser;
#use Data::Dumper;
use Mail::Address;
#use HTML::Parse;
#use Net::SMTP;
Re: modperl success story
The troll vanisheth! ha! Reminds me of the Zen story of an old fisherman in a boat on a lake in a heavy can't see your hands fog. He bumps into another boat, and shouts at the other guy, "Look where you're going would you! You almost knocked me over." He pulls up beside the boat and is about to give the other guy a piece of his mind, but when he looks in the other boat, he discovers that no one else is there. Flame trolls on mailing lists are virtual empty boats, whose only value is the sometimes humorous apoplexy elicited in the old sea salts on the list. Ed
Apache::StatINC not quite working on NT
I've just started using mod_perl, for a project that will deploy on both
Solaris and NT. The initial development was done on Solaris, and I've just
moved things over to NT to verify that they work there too. My modules all
run on NT, but StatINC doesn't seem to pick up changes that I make to
non-mod_perl modules.
For example, I have a module Apache::Project::Main that is the PerlHandler
for urls beginning /main. Apache::Project::Main in turn calls
Project::Home, which is responsible for printing out some of the html. Both
modules are under {server root}/lib/perl/. On the Solaris box, changes to
Apache::Project::Main and Project::Home would be immediately picked up. On
the NT box, though, only changes to Apache::Project::Main are noticed; if I
want to modify Project::Home, I have to restart apache! Directory structure
and config files are the same on both boxes (except for differences in
unix/nt paths).
Neither the guide, Apache::StatINC pod, or searching the mailing list
archives has given me any clues as to whether I'm dealing with a bug or just
have misconfigured things.
part of httpd.conf (any other spots that might be affecting things?):
---
IfModule mod_perl.c
Include conf/perl.conf
/IfModule
Location /main
SetHandler perl-script
PerlHandler Apache::Project::Main
PerlInitHandler Apache::StatINC
PerlSetVar StatINCDebug on
/Location
---
perl.conf:
---
PerlRequire conf/startup.pl
PerlWarn on
PerlFreshRestart On
---
startup.pl:
---
#!/Perl/5.00503/bin/MSWin32-x86/perl -w
use strict;
BEGIN {
use Apache ();
use lib Apache-server_root_relative('lib/perl');
}
# commonly used modules
use Apache::StatINC ();
use Apache::Status ();
use Apache::Constants ();
use CGI qw(-compile :all);
use CGI::Carp ();
use Apache::DBI ();
1;
Re: how come httpd doesn't start even though startup.pl is fine?
Hi there, On Fri, 14 Jan 2000, Ricardo Kleemann wrote: unfortunately that's not it... :-( If it's any help, mail me your config files and I'll fire it up on my development server (Slackware Linux 2.0.34/Apache 1.3.9/mod_perl 1.21) to see what happens. Have you got the latest greatest of all your modules? Probably I'd have to download and compile a couple of things. Here's what I have, most are installed, even if I don't actually use them yet... CGI.pm 2.56 Crypt:SSLeay0.14 Digest-MD5 2.09 HTML-Pager 0.01 HTML-Parser 2.23 HTML-Template 0.96 HTML-Validator 0.12 - never got this past `make test', not installed IO-Socket_SSL 0.73 MIME-Base64 2.11 Net::SSLeay 1.05 OpenSSL 0.9.4 URI.pm 1.04 libnet 1.0607 libwww 5.45 73, Ged.
Re: Apache::ASP XML Extension
On Thu, 13 Jan 2000, Joshua Chamas wrote:
Hey,
A possible XML extension for Apache::ASP came up when
Paul Linder created an internal mapping for msg$string/msg
to translate to Locale::PGetText::gettext($string), for
internationalization, and only for his version of the module.
I think that it would be good to extend this mechanism
in general, such that any tag/tag, or just tag args
could be mapped to a subroutine, thus implementing
generic XML extentions for the module.
Here's my try at this... a generic XML tag set seems to
look like tag %args[$string/tag] where the part in
brackets is optional ... maybe if XMLSubs is set to
some tag names, these tags would then have their namesake
function called.
First off, it's tag %args[$string]/tag or tag %args/ - the syntax is
extremely strict and I'll come down on you like a ton of bricks if you
don't stick to it :)
A valid regexp for ascii and Latin-1 only XML parsing is:
while ($contents =~ /([^]*)(\/)?([^]+)/) {
But then you have to do a bit more to determine whether you've gotten a PI,
DOCTYPE, CDATA or ELEMENT - but you can probably ignore that!
So Paul would set XMLSubs to msg, then define the msg()
function in global.asa which would then be called. $string
would get set to $_, and args would be passed in as %args,
so internally this would happen:
$_ = $string; msg(%args);
I thought about passing %args in as a hash ref msg({%args}),
but think that this might slow things down for the common
use, with less %args, with the overhead of creating the
hash ref, also the @_ for sub msg{} would be easier to
work with as just my %args = @_;
So then for Paul, he would have defined in his global.asa
sub msg { Locale::PGetText::gettext($_) }
for his msg$string/msg XMLSubs mapping. The return
output would be inserted into the final HTML.
What about embeded XML tags you ask? Good question. Its
really an implementation nightmare for me to solve, but
I would have to keep breaking up $_ into smaller parts,
resolving the deepest tag first, allowing tags to operate
on the output of embedded tags, like
msg
msg2$string/msg2
/msg
where the output from msg2 would be set to $_ for msg.
Matt, I have also CC'd you here, since you are the
XML pro in these parts.
Any suggestions or feedback ? Thanks.
Well, overall I think it's a bad idea. Sorry. I've just had (like 10
minutes ago) this discussion on Perl-XML. I think that you shouldn't be
extending a perfectly good system with this cruft - not only do you have to
parse % % (easy) but now have to look out for all sorts of special tags?
My personal preference would perhaps be a separate module that processed an
XML based CFML type page - in that system you could implement this - go for
your life, but I don't think it works particularly well as part of the
design of ASP.
Hope I haven't put you off.
Also, I don't see the benefit between what you've proposed and:
%= msg($string) %
That seems far more logical to me.
Keep the declarative stuff in declaritive languages and keep ASP procedural.
If someone wants to see an interesting XML based little language written in
about 200 lines of code give me a shout.
--
Matt/
Details: FastNet Software Ltd - XML, Perl, Databases.
Tagline: High Performance Web Solutions
Web Sites: http://come.to/fastnet http://sergeant.org
Available for Consultancy, Contracts and Training.
Re: modperl success story
On Fri, 14 Jan 2000, Barb and Tim wrote: It could really enhance your integrity if you also presented honest evaluations of the downsides of Perl. The promotion of Perl on this site is so ubiquitous and one sided, and Perl has such a bad reputation in many ways, that somebody like me has a hard time swallowing the sunny prognostications and finally diving in, unless I see full honesty. The language itself is hard enough to swallow. Just a suggestion. I would venture to suggest that the problems of mod_perl are as follows: - Non-trivial to build and install (judging by the number of questions here regarding problems in this area - not by personal experience). - Still some wierd bugs. - A number of special considerations have to be made when building your program, such as taking care of persistent variables, etc. - All of perl's irritations (and there are quite a few - like the definition of truth). - Documentation still isn't fantastic - although the guide has made great inroads into changing that, and the book is awsome. - Some modules are still a bit cryptic (e.g. some people expect things like Apache::Session to do everything for them, whereas it's really a session management toolkit). - mod_perl is still really in its infancy, and hasn't taken off as fast as other systems such as php and Zope. I think this is due to the complexity issues outlined above, and the fact that ISP's don't like mod_perl. - Oh yeah - and mod_perl uses lots of RAM. That's probably the main reason ISP's don't like it. -- Matt/ Details: FastNet Software Ltd - XML, Perl, Databases. Tagline: High Performance Web Solutions Web Sites: http://come.to/fastnet http://sergeant.org Available for Consultancy, Contracts and Training.
Re: modperl success story
On Fri, Jan 14, 2000 at 12:34:00PM -0800, Ed Phillips wrote: The troll vanisheth! ha! Reminds me of the Zen story of an old fisherman in a boat on a lake in a heavy can't see your hands fog. He bumps into another boat, and shouts at the other guy, "Look where you're going would you! You almost knocked me over." He pulls up beside the boat and is about to give the other guy a piece of his mind, but when he looks in the other boat, he discovers that no one else is there. Flame trolls on mailing lists are virtual empty boats, whose only value is the sometimes humorous apoplexy elicited in the old sea salts on the list. Wow, what a story. But poor man probably just didn't realize that this list is not for sucess stories sharing. But for problems discussion :) Andrei --
Re: how come httpd doesn't start even though startup.pl is fine?
ok, i think if you mean redhat 6.1 as opposed to linux6.1 i have the same prob, i have never been able to insert anything into the startup.pl besides Apache CGI CGI::Carp . if i try to add any third parties it dies i did a quick search on the mail list and the red hat updates and found that they both pointed to the fact that apache is not compiled right to use dso's noteable i think it was with apxs go to ftp://ftp.redhat.com/pub/redhat/updates/6.1/i386/ for the new apache i havent yet tried this please if anyone else has any info please let me know i know apache dso w modperl works fine, i compiled em mysef on stampede! ttfn
Re: modperl success story
Hey, aren't we decided to use the advocacy list for this kind of threads? You are funny folks, when you don't want us to discuss something here, you tell go talk about this somewhere else, so we did. Please follow your own suggestions. This current thread was split into 2, one discussed here and the other at the proper "advocacy" list! The subscribing info is: A new mailing list for mod_perl advocacy issues, discussions about site and etc. Subscribe by sending a mail to [EMAIL PROTECTED] The list address is [EMAIL PROTECTED] The archive: http://www.mail-archive.com/advocacy%40perl.apache.org/ Thank you very much! ___ Stas Bekmanmailto:[EMAIL PROTECTED] http://www.stason.org/stas Perl,CGI,Apache,Linux,Web,Java,PC http://www.stason.org/stas/TULARC perl.apache.orgmodperl.sourcegarden.org perlmonth.comperl.org single o- + single o-+ = singlesheavenhttp://www.singlesheaven.com
Re: Apache::ASP: crash when placed in startup.pl
Dmitry Beransky wrote: Doh! I forgot to say what I'm running: Apache::ASP v. 0.17 SDMB_File v. 1.0 mod_perl v. 1.21 Apache v. 1.39 RedHat 6.1 on Linux 2.2.12 x86 This might be yet another RedHat problem ... have you tried rebuilding your perl / mod_perl from scratch. Out of curiosity really, because I think you should still rebuild stuff, does SDBM_File load fine, if not being preloaded ? -- Joshua _ Joshua Chamas Chamas Enterprises Inc. NodeWorks free web link monitoring Huntington Beach, CA USA http://www.nodeworks.com1-714-625-4051
Re: Apache::ASP: crash when placed in startup.pl
Yep, everything runs just fine if I don't preload Apache::ASP. My apache/mod_perl are rebuilt, but I'm still using Perl off the original RedHat distribution (totally forgot about his). I can try recompiling it...I'll be back with the result shortly. Thanks Dmitry At 01:26 PM 1/14/00 , Joshua Chamas wrote: This might be yet another RedHat problem ... have you tried rebuilding your perl / mod_perl from scratch. Out of curiosity really, because I think you should still rebuild stuff, does SDBM_File load fine, if not being preloaded ? Dmitry Beransky wrote: Doh! I forgot to say what I'm running: Apache::ASP v. 0.17 SDMB_File v. 1.0 mod_perl v. 1.21 Apache v. 1.39 RedHat 6.1 on Linux 2.2.12 x86
Re: Embperl + Apache::Session
On Fri, Jan 14, 2000 at 01:31:17PM +0100, Gerald Richter wrote: What you describe looks good to me. There is one other issue, that is dynamlic linking mod_perl. How comes mod_perl into your Apache? Is it dynamicly loaded at runtime (i.e. by a LoadModule in your httpd.conf) or is it staticly loaded? If the first is true, look if Embperl is loaded somewhere in your httpd.conf (either by a PerlModule or by a file that is loaded with PerlRequire). Remove this. In case of dynamicly linking Embperl must not loaded at startup time. (mod_perl will do this at request time for you) I made a further test by now, with staticly linked mod_perl and without preloading HTML::Embperl in httpd.conf. Doing a "tail -f /var/log/apache/error.log" I see "[11159]SES: Embperl Session management enabled (1.xx)" (with the number in brackets changing of course) every time I reload my testpage. But I can also still see the session-id changing with every reload, and no cookie is set, just like before. Does the changing id not indicate that sessionmanagement is basically working and there is just something terribly wrong with the cookie part? Maybe I did not install some package from CPAN correctly (although I cannot remember seeing any error during installation)? Andre PGP signature
Re: Apache::ASP: crash when placed in startup.pl
This might be yet another RedHat problem ... have you tried rebuilding your perl / mod_perl from scratch. Out of curiosity really, because I think you should still rebuild stuff, does SDBM_File load fine, if not being preloaded ? Well, I just finished recompiling perl and mod_perl, but the problem is still there. Is there any way to verify that mod_perl is using the new perl? Thanks Dmitry
Re: APACHE_ROOT
God, I love this list. :) ($APACHE_ROOT = $APACHE_SRC) =~ s,/src/?$,,; last if $NO_HTTPD; # or $USE_APACI; I'm thinking maybe it's a problem with the 5.005_57 I have installed. I'll back out to 5.005_03 and see what happens. Thanks again, -Bill
Re: APACHE_ROOT
Hi there, On 14 Jan 2000, William P. McGonigle wrote: Can someone explain what APACHE_ROOT is meant to be? I'm assuming it's somehow different thatn APACHE_SRC (which I'm defining). The expression ($APACHE_ROOT = $APACHE_SRC) =~ s,/src/?$,,; sets the scalar $APACHE_ROOT to be equal to the scalar $APACHE_SRC and then chops off any "/src" or "/src/" from the end of it. Beware if you haven't got /src on the end of your source directory! The =~ binding operator (p27) tells perl to do the substitution s,/src/?$,, to the thing on left hand side of its expression. The parentheses (p77) mean the thing in them is a term, which has the highest precedence in perl so the assignment has to be done first. The substitution then has to be done on the result, $APACHE_ROOT and not $APACHE_SRC, er, obviously. The three commas are quotes (p41) for a substitution, presumably chosen because they can't easily appear in a filename. The pattern to match is /src/?$ The question mark is a quantifier (p63), it says we can have 0 or 1 trailing slash in the pattern we match - it's trailing at the end of a string because of the $ (p62). If our string matches, the matching bit is replaced with the bit between the second and third commas. There's nothing between the second and third commas, so it's replaced with nothing. Have a look at pages 72 to 74 especially for more about the s/// construct. The page numbers are from the Camel Book, second edition. I keep it on my desk at all times, it stops my papers blowing around. You will help yourself a lot with these things if you read chapters one and two five or six times this year as a kind of a penance. So if $APACHE_SRC eq "/usr/local/apache/src/" or $APACHE_SRC eq "/usr/local/apache/src" then $APACHE_ROOT eq "/usr/local/apache" after the substitution. I just *love* Perl's pattern matching! 73, Ged.
A year of accumulated patches
Hi, I'm your neighborhood Debian package maintainer for mod_perl...
I made the mistake of getting off this list a while back, and I've
accumulated a bit of a collection of patches since then. Most in the
last few days. So I figured now that I was actively working on
mod_perl again, I would submit them back where they belong.
First of all, in CVS I see this:
fix $ENV{PATH} corruption, thanks to help from Chip Turner,
Oleg Bartunov and Tomasz Przygoda
I'm still seeing some $ENV{PATH} corruption built as a DSO, though.
I'll look in to it later tonight.
The first really important one is a fix for the crashes I've been
seeing in boot_DBI. I can't find the exact message in the archive now,
but anyone who reported that a problem was fixed by setting
PERL_STARTUP_DONE_CHECK=1 in the environment probably wants this patch
instead. The problem was that a library (in this case libpg.so) called
putenv() after perl was initialized but before perl's my_setenv got
called. Thus environ[] never got copied to malloc()'d memory, and
trying to overwrite $ENV{TZ} caused a bogus free(). That's
environment-mod_perl.c.
A pair of small perl patches, from Roderick Schertler [EMAIL PROTECTED]:
- Apache.pm: send_cgi_header was modifying the string in $_.
Fixed in local-underscore-Apache.pm.
- There was a precedence problem in StatINC.pm. Fixed in
precedence-StatINC.pm.
And a trivial fix for mod_perl.c - one of the status messages had
"...ok" instead of "...". Fixed in message-cleanup-mod_perl.c.
Makefile.PL would not handle PERL_DEBUG=1 if USE_DSO, because the code
was stuck in a loop over available apache source trees. I just moved
it outside of the loop. Fixed in PERL_DEBUG-Makefile.PL.
And now the doozy. This one is not like the others; it is a stopgap,
EVIL hack and should not be included in the source. It's included only
for observation purposes. I worked around the ongoing bug involving
the DSO not liking being reloaded. From what I could tell the former
hack, mp_dso_unload, was somehow never getting called; if it had gotten
called, it would have caused a segfault at dlclose(0), which I found
out the hard way. The patch 'hideous-hack-mod_perl.c' actually walks
the cleanup tree and removes all module unloads - removing our own did
not suffice to fix the problem, oddly. I can think of a dozen better
ways to do this cleanly, involving small apache patches; I am also
fully aware that this is a symptom, not a problem, that I am fixing.
But it -does- suffice to make the DSO work. For now.
Be warned, the patch might reverses the meaning of PERL_DSO_UNLOAD.
I couldn't quite tell what it was supposed to accomplish before as I
could not even get that code to trigger.
I saw the message about the cyclic .init sections... I don't think that
is truly the problem, although I'm sure it's a problem. I'm using
libperl.a instead of libperl.so on this platform, and thus there is no
.init section. Right? Certainly none showed up in the linker debug
logs, although this is the linux dynamic loader, which does not do
cyclic dependency checking far as I can tell, or at least can't print a
message about it.
LD_PRELOAD'ing the module DOES work to prevent the bug, however. I
can't see why, and I can't get a good debugging dump. I'll look at it
more later.
Dan
/\ /\
| Daniel Jacobowitz|__|SCS Class of 2002 |
| Debian GNU/Linux Developer__Carnegie Mellon University |
| [EMAIL PROTECTED] | | [EMAIL PROTECTED] |
\/ \/
precedence-StatINC.pm
PERL_DEBUG-Makefile.PL
--- libapache-mod-perl-1.21.orig/src/modules/perl/mod_perl.c
+++ libapache-mod-perl-1.21/src/modules/perl/mod_perl.c
@@ -659,6 +655,16 @@
}
MP_TRACE_g(fprintf(stderr, "ok\n"));
+/* Force the environment to be copied out of its original location
+ above argv[]. This fixes a crash caused when a module called putenv()
+ before any Perl modified the environment - environ would change to a
+ new value, and the check in my_setenv() to duplicate the environment
+ would fail, and then setting some environment value which had a previous
+ value would cause perl to try to free() something from the original env.
+ This crashed free(). */
+my_setenv("MODPERL_BROKEN_ENV", "0");
+my_setenv("MODPERL_BROKEN_ENV", NULL);
+
{
dTHR;
TAINT_NOT; /* At this time all is safe */
local-underscore-Apache.pm
--- libapache-mod-perl-1.21.orig/src/modules/perl/mod_perl.c
+++ libapache-mod-perl-1.21/src/modules/perl/mod_perl.c
@@ -607,7 +603,7 @@
}
MP_TRACE_g(fprintf(stderr, "ok\n"));
-MP_TRACE_g(fprintf(stderr, "constructing perl interpreter...ok\n"));
+MP_TRACE_g(fprintf(stderr, "constructing perl interpreter..."));
perl_construct(perl);
status = perl_parse(perl,
Re: APACHE_ROOT
Ged, You are very entertaining. The code in question is also known as a combined copy and substitution. Beware if you haven't got /src on the end of your source directory! If you don't have a match with the string or regexp , you'll just get a straight copy. Ed X-Authentication-Warning: C2H5OH.jubileegroup.co.uk: ged owned process doing -bs Date: Sat, 15 Jan 2000 00:00:37 + (GMT) From: "G.W. Haywood" [EMAIL PROTECTED] Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: [EMAIL PROTECTED] Precedence: bulk Hi there, On 14 Jan 2000, William P. McGonigle wrote: Can someone explain what APACHE_ROOT is meant to be? I'm assuming it's somehow different thatn APACHE_SRC (which I'm defining). The expression ($APACHE_ROOT = $APACHE_SRC) =~ s,/src/?$,,; sets the scalar $APACHE_ROOT to be equal to the scalar $APACHE_SRC and then chops off any "/src" or "/src/" from the end of it. The =~ binding operator (p27) tells perl to do the substitution s,/src/?$,, to the thing on left hand side of its expression. The parentheses (p77) mean the thing in them is a term, which has the highest precedence in perl so the assignment has to be done first. The substitution then has to be done on the result, $APACHE_ROOT and not $APACHE_SRC, er, obviously. The three commas are quotes (p41) for a substitution, presumably chosen because they can't easily appear in a filename. The pattern to match is /src/?$ The question mark is a quantifier (p63), it says we can have 0 or 1 trailing slash in the pattern we match - it's trailing at the end of a string because of the $ (p62). If our string matches, the matching bit is replaced with the bit between the second and third commas. There's nothing between the second and third commas, so it's replaced with nothing. Have a look at pages 72 to 74 especially for more about the s/// construct. The page numbers are from the Camel Book, second edition. I keep it on my desk at all times, it stops my papers blowing around. You will help yourself a lot with these things if you read chapters one and two five or six times this year as a kind of a penance. So if $APACHE_SRC eq "/usr/local/apache/src/" or $APACHE_SRC eq "/usr/local/apache/src" then $APACHE_ROOT eq "/usr/local/apache" after the substitution. I just *love* Perl's pattern matching! 73, Ged.
Re: A year of accumulated patches
On Fri, Jan 14, 2000 at 07:28:22PM -0500, Daniel Jacobowitz wrote:
The first really important one is a fix for the crashes I've been
seeing in boot_DBI. I can't find the exact message in the archive now,
but anyone who reported that a problem was fixed by setting
PERL_STARTUP_DONE_CHECK=1 in the environment probably wants this patch
instead. The problem was that a library (in this case libpg.so) called
putenv() after perl was initialized but before perl's my_setenv got
called. Thus environ[] never got copied to malloc()'d memory, and
trying to overwrite $ENV{TZ} caused a bogus free(). That's
environment-mod_perl.c.
I've never looked at the mod_perl source code, but does it call
perl_parse() with a NULL for the env arg? If not it should.
Tim.
Re: Apache::ASP: crash when placed in startup.pl
Dmitry Beransky wrote: This might be yet another RedHat problem ... have you tried rebuilding your perl / mod_perl from scratch. Out of curiosity really, because I think you should still rebuild stuff, does SDBM_File load fine, if not being preloaded ? Well, I just finished recompiling perl and mod_perl, but the problem is still there. Is there any way to verify that mod_perl is using the new perl? I don't know about this, are you sure you copied over your new modperl httpd to /usr/local/apache after the build, and did a full stop / start, this is a common step overlooked by the best of us. Beyond this, I think it would be a shame if you couldn't preload Apache::ASP because of SDBM_File, you might want to research the archives a bit on other preload problems people have had, as they are likely related. I do my UNIX work on Solaris and have not ever dealt with this problem personally, so can't really pursue it for you. Maybe someone else has some insight? -- Joshua _ Joshua Chamas Chamas Enterprises Inc. NodeWorks free web link monitoring Huntington Beach, CA USA http://www.nodeworks.com1-714-625-4051
Re: A year of accumulated patches
On Sat, Jan 15, 2000 at 12:55:47AM +, Tim Bunce wrote:
On Fri, Jan 14, 2000 at 07:28:22PM -0500, Daniel Jacobowitz wrote:
The first really important one is a fix for the crashes I've been
seeing in boot_DBI. I can't find the exact message in the archive now,
but anyone who reported that a problem was fixed by setting
PERL_STARTUP_DONE_CHECK=1 in the environment probably wants this patch
instead. The problem was that a library (in this case libpg.so) called
putenv() after perl was initialized but before perl's my_setenv got
called. Thus environ[] never got copied to malloc()'d memory, and
trying to overwrite $ENV{TZ} caused a bogus free(). That's
environment-mod_perl.c.
I've never looked at the mod_perl source code, but does it call
perl_parse() with a NULL for the env arg? If not it should.
Yes, it does.
Dan
/\ /\
| Daniel Jacobowitz|__|SCS Class of 2002 |
| Debian GNU/Linux Developer__Carnegie Mellon University |
| [EMAIL PROTECTED] | | [EMAIL PROTECTED] |
\/ \/
Re: Apache::ASP XML Extension
Matt Sergeant wrote:
First off, it's tag %args[$string]/tag or tag %args/ - the syntax is
extremely strict and I'll come down on you like a ton of bricks if you
don't stick to it :)
A valid regexp for ascii and Latin-1 only XML parsing is:
while ($contents =~ /([^]*)(\/)?([^]+)/) {
Thanks, that would have been bad to get wrong.
Well, overall I think it's a bad idea. Sorry. I've just had (like 10
minutes ago) this discussion on Perl-XML. I think that you shouldn't be
extending a perfectly good system with this cruft - not only do you have to
parse % % (easy) but now have to look out for all sorts of special tags?
My personal preference would perhaps be a separate module that processed an
XML based CFML type page - in that system you could implement this - go for
your life, but I don't think it works particularly well as part of the
design of ASP.
There would be no performance hit for current users, just
if someone defined some config like XMLSubs would this extra
compilation parsing be used.
Since compile time is is amortized over the running of the
pre-compiled scripts, it shouldn't be that big a hit for
those who wanted to use the feature, and should be as
fast to compile as any other embedded template language,
like HTML::Template or CFML.
Hope I haven't put you off.
No, but your +++ would have made me more eager to get
busy on it.
Also, I don't see the benefit between what you've proposed and:
%= msg($string) %
%=msg('hey')%
msghey/msg
%=msg('hey')%
msghey/msg
hmmm... I like typing msghey/msg more, but that's just
me, a plain text old school HTML coder. Paul Linder made
the point that graphics designers don't like %= x('y') % constructs
because they feel like programming, which I think is the
same argument made for using HTML::Template.
That seems far more logical to me.
Keep the declarative stuff in declaritive languages and keep ASP procedural.
If someone wants to see an interesting XML based little language written in
about 200 lines of code give me a shout.
Why not evolve Apache::ASP? Even if you wouldn't use it, seems like
"There is more than one way to do it" is in keeping with the whole
perl ideology, and it makes sense to me to extend Apache::ASP over
time to be a better enabler, not just sticking to whatever platform
Microsoft proposed a few years ago. I have been trying to figure
out how XML makes sense in the context of Apache::ASP, and think
this would be good start.
Thanks for your feedback, and I appreciate your honest discourse.
-- Joshua
_
Joshua Chamas Chamas Enterprises Inc.
NodeWorks free web link monitoring Huntington Beach, CA USA
http://www.nodeworks.com1-714-625-4051
Re: Apache::ASP: crash when placed in startup.pl
I don't know about this, are you sure you copied over your
new modperl httpd to /usr/local/apache after the build,
and did a full stop / start, this is a common step overlooked
by the best of us.
Yes, I'm using the new build. I've compiled perl with debugging turned on
and now gdb shows exactly where the problem occurs: line 267 of SDBM_File.c
262 #ifdef __cplusplus
263 extern "C"
264 #endif
265 XS(boot_SDBM_File)
266 {
267 dXSARGS;
268 char* file = __FILE__;
269
270 XS_VERSION_BOOTCHECK ;
I guess at this point I got to go to a bookstore, get a book on GDB and get
my hands dirty with some debugging :).
Thanks
Dmitry
This might be yet another RedHat problem ... have you tried
rebuilding your perl / mod_perl from scratch. Out of curiosity
really, because I think you should still rebuild stuff,
does SDBM_File load fine, if not being preloaded ?
Well, I just finished recompiling perl and mod_perl, but the problem is
still there. Is there any way to verify that mod_perl is using the new
perl?
Re: Apache::ASP: crash when placed in startup.pl
This sounds like the same corruption problem that I talked about in my
last message - could you try exporting LD_PRELOAD=/path/to/modperl.so?
(I'm guessing from context that you're using a DSO - apologies for the
non-sequitor if I'm wrong, I just got back on the list).
On Fri, Jan 14, 2000 at 05:57:49PM -0800, Dmitry Beransky wrote:
I don't know about this, are you sure you copied over your
new modperl httpd to /usr/local/apache after the build,
and did a full stop / start, this is a common step overlooked
by the best of us.
Yes, I'm using the new build. I've compiled perl with debugging turned on
and now gdb shows exactly where the problem occurs: line 267 of SDBM_File.c
262 #ifdef __cplusplus
263 extern "C"
264 #endif
265 XS(boot_SDBM_File)
266 {
267 dXSARGS;
268 char* file = __FILE__;
269
270 XS_VERSION_BOOTCHECK ;
I guess at this point I got to go to a bookstore, get a book on GDB and get
my hands dirty with some debugging :).
Thanks
Dmitry
This might be yet another RedHat problem ... have you tried
rebuilding your perl / mod_perl from scratch. Out of curiosity
really, because I think you should still rebuild stuff,
does SDBM_File load fine, if not being preloaded ?
Well, I just finished recompiling perl and mod_perl, but the problem is
still there. Is there any way to verify that mod_perl is using the new
perl?
Dan
/\ /\
| Daniel Jacobowitz|__|SCS Class of 2002 |
| Debian GNU/Linux Developer__Carnegie Mellon University |
| [EMAIL PROTECTED] | | [EMAIL PROTECTED] |
\/ \/
Re: Apache::ASP: crash when placed in startup.pl
Yep, I am using DSO, but LD_PRELOAD didn't help [dmitry@bio-york ~]# set LD_PRELOAD=/usr/lib/apache/libperl.so [dmitry@bio-york ~]# gdb httpd GNU gdb 4.18 This GDB was configured as "i386-redhat-linux"... (gdb) run -X Starting program: /usr/sbin/httpd -X [Fri Jan 14 18:34:03 2000] [error] [asp] [3483] loaded 12 scripts Program received signal SIGSEGV, Segmentation fault. 0x4043180b in boot_SDBM_File (cv=0x8aef3e8) at SDBM_File.c:267 267 dXSARGS; Cheers Dmitry At 06:17 PM 1/14/00 , Daniel Jacobowitz wrote: This sounds like the same corruption problem that I talked about in my last message - could you try exporting LD_PRELOAD=/path/to/modperl.so? (I'm guessing from context that you're using a DSO - apologies for the non-sequitor if I'm wrong, I just got back on the list). On Fri, Jan 14, 2000 at 05:57:49PM -0800, Dmitry Beransky wrote: I don't know about this, are you sure you copied over your new modperl httpd to /usr/local/apache after the build, and did a full stop / start, this is a common step overlooked by the best of us. Yes, I'm using the new build. I've compiled perl with debugging turned on and now gdb shows exactly where the problem occurs: line 267 of SDBM_File.c
Eagle Book: navbar
Sorry if this seems perl and not mod_perl, but its from the
mod_perl book n all. On page 115, in Lincoln's navbar code
he writes a loop as:
local $/ = "";
while ($fh) {
s:(/BODY):$navbar$1:i;
s:(BODY.*?):$1$navbar:i;
} continue {
$r-print($_);
}
Is there some reason he is using a continue block? Isn't
continue only interesting in the presence of next and last?
My guess is that this example code was trimmed down from s
something fancier and this is a palimpsest fragment.
(Just checking my sanity)
-j
Re: Eagle Book: navbar
"John" == John M Vinopal [EMAIL PROTECTED] writes: John My guess is that this example code was trimmed down from s John something fancier and this is a palimpsest fragment. I occasionally have "vestigial code" left in my column programs as well. Durn this writing thing! barbie"Writing is hard!"/barbie -- 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!
