Re: Eagle Book: navbar

[Randal L. Schwartz]

> "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!  "Writing is hard!"

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

Re: A year of accumulated patches

[Daniel Jacobowitz]

On Fri, Jan 14, 2000 at 07:28:22PM -0500, Daniel Jacobowitz wrote:
> 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.

Scratch that, it's gone now.  Must have had a stale copy running.


Dan

/\  /\
|   Daniel Jacobowitz|__|SCS Class of 2002   |
|   Debian GNU/Linux Developer__Carnegie Mellon University   |
| [EMAIL PROTECTED] |  |   [EMAIL PROTECTED]  |
\/  \/

Eagle Book: navbar

[John M Vinopal]

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:():$navbar$1:i;
s:():$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: Apache::ASP: crash when placed in startup.pl

[Dmitry Beransky]

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
> >

Re: Apache::ASP: crash when placed in startup.pl

[Daniel Jacobowitz]

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

[Dmitry Beransky]

>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 XML Extension

[Joshua Chamas]

Matt Sergeant wrote:
> 
> First off, it's [$string] or  - 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')%>
  hey
  <%=msg('hey')%>
  hey

hmmm... I like typing hey 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: A year of accumulated patches

[Daniel Jacobowitz]

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: crash when placed in startup.pl

[Joshua Chamas]

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

After OpenSSL upgrade, mod_perl handlers give 403

[dave-mlist]

Version info:  apache_1.3.9, mod_perl-1.21, mod_ssl-2.4.9-1.3.9, openssl-0.9.4.

I recently upgraded my mod_perl installation with SSL by following the
OpenSSL and mod_perl HOWTO.  Now, all of my mod_perl handlers give me
a 403 and the following error:

[Fri Jan 14 10:03:24 2000] [error] [client 207.168.228.68] Directory index forbidden 
by rule: /home/httpd/wuertele.com/html/test/

For example, I have one directory called
"/home/httpd/wuertele.com/html/photos/" that contained the following
.htaccess file:

SetHandler perl-script
PerlHandler Stonehenge::Pictures
PerlSendHeader On

This photo album handler worked fine before the upgrade, but now I get
the 403 and the "Directory forbidden by rule" error.

My perl config looks as follows:

### Section Dave: mod_perl
AddModule mod_perl.c

# startup.perl loads all functions that we want to use within mod_perl
Perlrequire /usr/local/apache/conf/startup.pl

Alias /perl/  /home/httpd/perl/

PerlSetEnv PERLDB_OPTS "NonStop=1 LineInfo=/tmp/db.out AutoTrace=1 frame=2"
PerlModule Apache::Registry Apache::DB CGI Apache::StatINC Apache::DBI
PerlInitHandler Apache::StatINC


  PerlFixupHandler Apache::DB
  SetHandler perl-script
  PerlHandler Apache::Registry
  Options ExecCGI
  PerlSendHeader On
  PerlInitHandler Apache::StatINC
  PerlSetVar StatINCDebug On


PerlTaintCheck On


  SetHandler perl-script
  PerlHandler Apache::Status
  order deny,allow
  deny from all
  #allow from 


The perl modules are readable and executable by nobody:

[root@grave Stonehenge]# pwd
/home/httpd/perl/lib/Stonehenge
[root@grave Stonehenge]# ls -l
total 24
-rwxr-xr-x   1 root nobody  10628 Jan  5 07:55 Pictures.pm
[root@grave Stonehenge]# 

Any clues for sale?
Dave

Re: A year of accumulated patches

[Tim Bunce]

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_ROOT

[Ed Phillips]

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.

A year of accumulated patches

[Daniel Jacobowitz]

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, xs

Re: APACHE_ROOT

[G.W. Haywood]

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.

Re: APACHE_ROOT

[William P. McGonigle]

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::ASP: crash when placed in startup.pl

[Dmitry Beransky]

>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::ASP: crash when placed in startup.pl

[Dmitry Beransky]

>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

[Cliff Rayman]

i believe the APACHE_SRC is the location
of the actual source tree.
the perl code is taking this APACHE_SRC variable
and stripping the /src from the end to get the
directory APACHE_ROOT.  The APACHE_ROOT
is the directory that you unpacked the archive into. It contains
some config info and stuff that is not a part of the source 'proper'.

i.e. on my system
APACHE_SRC is /usr/local/src/apache_1.3.3/src
APACHE_ROOT is /usr/local/src/apache_1.3.3

hope this helps,

cliff rayman
genwax.com

"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).
>
> I found this in Makefile.PL:
>
> ($APACHE_ROOT = $APACHE_SRC) =~ s,/src/?$,,;
> last if $NO_HTTPD; # or $USE_APACI;
>
> But although I code alot of perl, I'm abyssmal at trying to figure out these
> constructs, and my books are at home...
>
> Anyway, it's getting set to blank when I run Makefile.PL.
>
> Thanks,
> -Bill

APACHE_ROOT

[William P. McGonigle]

Can someone explain what APACHE_ROOT is meant to be?  I'm assuming it's somehow
different thatn APACHE_SRC (which I'm defining).
  
I found this in Makefile.PL:

($APACHE_ROOT = $APACHE_SRC) =~ s,/src/?$,,;
last if $NO_HTTPD; # or $USE_APACI;

But although I code alot of perl, I'm abyssmal at trying to figure out these
constructs, and my books are at home...

Anyway, it's getting set to blank when I run Makefile.PL.

Thanks,
-Bill

Proxy example in eagle book does not work

[Jason Bodnar]

A line in the proxy example of the eagle book on page 380 does not seem to work
(entirely):

The line:

$r->headers_in->do(sub {$request->header(@_);});

works for almost every request but when I post data with a form that is encoded
with the multipart type the content does not get sent.

But, if I change that line to:

$req->header($r->headers_in);

The data gets posted but for some very strange reason, images take forever like
(20 secs) to load.

I've tried using checking the content type and if it's an image use one line
and use the other for non-images but that doesn't work.


---
Jason Bodnar + [EMAIL PROTECTED] + Tivoli Systems

I swear I'd forget my own head if it wasn't up my ass. -- Jason Bodnar

Re: how come httpd doesn't start even though startup.pl is fine?

[Sean Chittenden]

Something is tickling the back of my mind regarding this.  I think
it's because Red Hat includes a botched perl build (ie different install
options).  A while back I took to rebuilding perl by hand and haven't had
this problem in a _long_ time.  I'd try going that route if your problems
persist.

This still strikes me as a work around and not necessarily a
solution, but I haven't spent the time to figure out the specific prob w/
Red Hat's build, so workarounds are legit.  ::grin::  Plus, depending on
your needs, the build flag -O6 always helps too  ;)

-- 
Sean Chittenden  <[EMAIL PROTECTED]>

I may be getting older, but I refuse to grow up!

On Fri, 14 Jan 2000, Clayton Cottingham wrote:

> Date: Fri, 14 Jan 2000 19:58:35 +
> From: Clayton Cottingham <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: 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: Embperl + Apache::Session

[Andre Landwehr]

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

[Dmitry Beransky]

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: Apache::ASP: crash when placed in startup.pl

[Joshua Chamas]

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: modperl success story

[Stas Bekman]

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: how come httpd doesn't start even though startup.pl is fine?

[Clayton Cottingham]

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

[Andrei A. Voropaev]

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: modperl success story

[Matt Sergeant]

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.

-- 


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: Apache::ASP XML Extension

[Matt Sergeant]

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 $string 
> 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 , or just 
> 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 [$string] 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 [$string] or  - 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 $string 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 
> 
>  
>   $string
>  
> 
> 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.

-- 


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: how come httpd doesn't start even though startup.pl is fine?

[G.W. Haywood]

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.

Apache::StatINC not quite working on NT

[Slag, Joe]

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?):
---


  Include conf/perl.conf



  SetHandler perl-script
  PerlHandler Apache::Project::Main
  PerlInitHandler Apache::StatINC
  PerlSetVar StatINCDebug on


---
  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: modperl success story

[Ed Phillips]

>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

Re: how come httpd doesn't start even though startup.pl is fine?

[Sean Chittenden]

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  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

[Eric Strovink]

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: Apache::ASP: crash when placed in startup.pl

[Dmitry Beransky]

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
>

Apache::ASP: crash when placed in startup.pl

[Dmitry Beransky]

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: DSO slows things down?

[Frank D. Cringle]

Stas Bekman <[EMAIL PROTECTED]> writes:
> 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:
> 
> 
> 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. 
> 
> 
> 
> What do DSO benefactors have to say :)

I'm not a DSO advocate, but I think they would say that DSOs simplify
software distribution.  If each contributed Apache mod_whatever only
worked when statically linked, what would RedHat distribute?  The same 
argument applies in webhosting server farms where different customers
have different requirements.

-- 
Frank Cringle,  [EMAIL PROTECTED]
voice: (+49 2304) 467101; fax: 943357

Re: modperl success story

[Leslie Mikesell]

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]

Re: modperl success story

[Jeffrey W. Baker]

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: how come httpd doesn't start even though startup.pl is fine? (fwd)

[Frank D. Cringle]

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: how come httpd doesn't start even though startup.pl is fine?

[Ricardo Kleemann]

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: DSO slows things down?

[Jens-Uwe Mager]

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:
> 
> 
> 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. 
> 
> 
> 
> 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: oracle : The lowdown

[Keith G. Murphy]

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.  :-)

DSO slows things down?

[Stas Bekman]

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:


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. 



What do DSO benefactors have to say :)

The rest of the thread includes some interesting notes too, for those
running mod_perl in bundle with some SSL module... Unfortunately the
thread isn't formatted as thread and thus it's hard to read...

___
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: mod_perl mixing up scripts?

[addyd]

mod_perl sages...

Thanks for the responses to my original question. I am working to
understand the issues involved and wrap my head around what mod_perl is
actually doing.


But from mod_perl's perspective, isn't:
/perl/news/framecal/framecal.pl
a completely different script than:
/perl/cal/framecal/framecal.pl


If each script has it's own .conf file that sets variables (using the same
names) is it possible for mod_perl to store variables set for the one
script in one path with a completely different copy (of the same script,
with the same variable names) on another path? Because THAT is what I am
experiencing.

Darren Addy
University of Nebraska at Kearney

RE: Embperl + Apache::Session

[Gerald Richter]

> 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: $r->notes()...

[David Harris]

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: $r->notes()...

[Ken Williams]

[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: Embperl + Apache::Session

[Gerald Richter]

>
> 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: Embperl + Apache::Session

[Andre Landwehr]

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: modperl success story

[Rod Butcher]

Gunther's right, my apologies to all. I shall now disembowel myself with
my IBM flowcharting template if I can find it. (Joke, really, a joke,
not more sarcasm...).
Rgds.
Rod Butcher


Gunther Birznieks wrote:
> 
> Sarcastic responses do not help, regardless of how you feel about the
> original poster's thesis.
> 
> On Fri, 14 Jan 2000, Rod Butcher wrote:
> 
> > 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
> >

-- 
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

$r->notes()...

[Sean Chittenden]

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: perl parser for CC/PP information

[G.W. Haywood]

Hi there,

On Fri, 14 Jan 2000, CAMERON, CRAIG wrote:

>   I'm about to write a parser for CC/PP
>  (Composite Capability/Preference Profiles)
> as a perl module for apache.  Basically the information is stored in rdf
>  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.

Re: modperl success story

[G.W. Haywood]

Hi there,

On Fri, 14 Jan 2000, Barb and Tim wrote:

> honest evaluations of the downsides of Perl

Thanks for the note, and welcome.  I'm not sure the mod_perl list is
quite the place for this as a topic, so you other list readers might
want to hit `D' now.  The list is primarily for discussions about the
application of the Perl extensions to the Apache web sever.  You seem
to be having trouble with Perl itself, which you really need to get
under your belt before you address the quite separate topic of Perl
embedded in Apache.  The mod_perl list is kind of a mish-mash of
sub-topics leading on from there.

> It could really enhance your integrity

Hmmm.  I don't know about integrity, but I have to say that I really
wish I had taken the time to learn about Perl many years before I
actually did.  I do a lot of text processing in my work and AFAIK
there is nothing that gets even close to Perl for concise expression
and fast development of what I do.  I use Perl by itself and Perl in
Apache as well.  One of my sites has over 25,000 products that can be
ordered on line and I honestly don't know how I'd cope with it on my
own without Perl.

> The promotion of Perl on this site is so ubiquitous and one sided

That may be true (not if you've read _all_ my posts:) but then it's
hardly surprising either.  People who don't like it or can't hack it
usually just walk away.  I came close myself, for different reasons.

> Perl has such a bad reputation in many ways,

I don't know what you mean.  Bad reputation for what?  If people are
trying to use it for something it's not good at, then I can understand
why they'd be unhappy with the results.  If I need to do something
that's better in C or assembler, then that's what I use.  I've used
Fortran since 1971, Assemblers since 1975, C since 1977, Pascal, Ada,
RTL/2 (always my favourite), several shells, an assortment of DBase
type things and a whole bunch of others not really worth mentioning.
Although I've used Perl only for the last two years or so, for a quick
hack I still tend to go for Perl first.  The way you can mix and match
bits of Perl and Unix is hard to beat.  Er, you're not using Windows,
are you?

> The language itself is hard enough to swallow.

Well, I agree that the _syntax_ may be a little odd.  But the language
itself really isn't very difficult to grasp.  Coming after 25 years of
C I found the trickiest bits were remembering the differences between
C and Perl (sometimes remembering which language I was using at the
time!) and coping with the fact that you've really only got three data
types.  For me one great thing about the language is the very powerful
pattern matching and substitution, and the interpreter itself is by a
very long way the best of any I've used.  The warnings you get with
`perl -w' and `use strict' far exceed any reasonable expectations and
continue to amaze me with the mistakes they pick up.

> full honesty

I think you're getting honesty from the people on the list.  Don't
forget that some may be relatively inexperienced (and perhaps a little
in awe of some of the high powered talent that lurks around here) but
for the most part they like what they're doing and only occasionally
tear all their hair out.  Which you will see mentioned on the list...

> somebody like me has a hard time swallowing the sunny
> prognostications and finally diving in

Well, don't swallow, just put a toe in the water.  Nobody's forcing
you.  What kinds of things are you thinking of doing with Perl?

73,
Ged.

Re: how come httpd doesn't start even though startup.pl is fine? (fwd)

[Frank D. Cringle]

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: Apache 1.3.9 + mod_perl 1.21 + Solaris 2.7 dumps core

[Frank D. Cringle]

Alan Burlison <[EMAIL PROTECTED]> writes:
> $ LD_PRELOAD='/home2/web/apache_1.3.9/libexec/libperl.so \
> /home1/software/perl/debug/lib/5.00503/sun4-solaris/CORE/libperl.so'
> ./httpd
> $
> 
> hey presto!  A working httpd.

Excellent!

>  Obviously this is just a workaround - the
> real fix is to identify the cyclic dependencies and fix them properly.

Yep.  The same thing probably happens on linux, but the man-pages
don't mention LD_PRELOAD there, so a different workaround or fix is
required.

-- 
Frank Cringle,  [EMAIL PROTECTED]
voice: (+49 2304) 467101; fax: 943357

Re: modperl success story

[Stas Bekman]

> 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: modperl success story

[Rod Butcher]

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: how come httpd doesn't start even though startup.pl is fine?

[Sean Chittenden]

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

[Tom Mornini]

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: modperl success story

[stephen]

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