RE: Highly optimized mod_perl ?

[G.W. Haywood]

Hi there,

On Sat, 17 Jun 2000 [EMAIL PROTECTED] wrote:

> Saved memory means less swaping,

You don't want _any_ swapping on a mod_perl host.

73,
Ged.

Re: mod_perl caches compiled quotes?

[G.W. Haywood]

Hi there,

On Sat, 17 Jun 2000, Steve Smith wrote:

> Sorry if this is a FAQ, but I haven't seen anything discussing this.

Then you haven't read the Guide:

http://perl.apache.org/guide

It's also in several other documents (the Eagle Book for one, and the
mod_perl Home page for another).

All of which you must also read.

Soon.

73,
Ged.

Segfault Apache1.3.12/mod_perl1.24/Solaris2.6

[G.W. Haywood]

Hi all, 

Sorry, this is a bit long.

I'm working on a bunch of machines running Solaris 2.6 on which I have
installed Apache+mod_perl static.  The machines are set up for just a
couple of virtual hosts at present for testing, eventually they will
be load-balanced with mod_perl on separate machines and will host many
sites.  I downloaded & compiled new sources for the latest (not CVS)
versions of Apache 1.3.12, mod_perl 1.24, mod_macro 1.1.1 and Perl
5.005_03.  The compiler is gcc 2.91.66 and was used for all the
compilations.

I set up a plain/mod_perl Apache pair on one of the machines.  The
proxying worked fine and I could get server-info and server-status OK
from the mod_perl Apache.  I left it at that and went on to other
things.  Unfortunately when the development department started working
on the scripting a couple of days later (yesterday, Friday) the
mod_perl Apache started segfaulting as soon as they tried to get it to
serve a request from their test handler.  Here's the error_log message:

[Fri Jun 16 17:20:21 2000] [notice] \
child pid 22310 exit signal Segmentation Fault (11)

There is no core dump and the same thing happens with the -X switch.
The first Perl had thread support and dynamic linking, so I recompiled
it twice, once with no thread support and once without dynamic linking
but the same thing happened.  Below are the makepl_args.mod_perl, the
output of perl -V, httpd_perl -l, perl.conf, startup.pl and test.pm
which I just noticed contains a call to Apache::Request->new() and I
don't know why.  I don't think that should make Apache segfault...

I searched the archives and there are some Solaris segfaults but
nothing seems to fit this simple case.  I don't have access to the
machines at the weekend so I've posted this hoping it might ring some
bells somewhere before I try again next week maybe with the CVS
version of mod_perl 1.24 and maybe even with 1.21 and 1.3.9 just to
see what happens.  I'll also get rid of that Apache::Request call and
try things like Apache::Registry scripts to see what happens there.

Any input gratefully received.  Especially by Leo, who gets it in the
neck if the machines aren't ready to go live next Friday...

73,
Ged.

==
makepl_args.mod_perl
--
USE_APACI=1
APACHE_PREFIX=/usr/local/apache/httpd_perl
APACHE_SRC=../apache_1.3.12/src
DO_HTTPD=1
EVERYTHING=1
ALL_HOOKS=1
PERL_SSI=1
PERL_SECTIONS=1
APACI_ARGS=--sbindir=/usr/local/sbin/httpd_perl
APACI_ARGS=--sysconfdir=/usr/local/apache/httpd_perl/conf
APACI_ARGS=--runtimedir=/usr/local/apache/httpd_perl/run
APACI_ARGS=--logfiledir=/usr/local/apache/httpd_perl/logs
APACI_ARGS=--localstatedir=/usr/local/apache/httpd_perl/stat
APACI_ARGS=--proxycachedir=/usr/local/apache/httpd_perl/proxy
APACI_ARGS=--enable-module=rewrite
APACI_ARGS=--enable-module=include
APACI_ARGS=--enable-module=info
APACI_ARGS=--activate-module=src/modules/extra/mod_macro.c
==
Output of perl -V:
--
Summary of my perl5 (5.0 patchlevel 5 subversion 3) configuration:
  Platform:
osname=solaris, osvers=2.6, archname=sun4-solaris
uname='sunos emap-sun-07.whoc.theplanet.co.uk 5.6 generic_105181-21 sun4u sparc '
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef useperlio=undef d_sfio=undef
  Compiler:
cc='cc -B/usr/ccs/bin/ -B/usr/ccs/bin/', optimize='-O', gccversion=egcs-2.91.66 
19990314 (egcs-1.1.2 release)
cppflags='-I/usr/local/include'
ccflags ='-I/usr/local/include'
stdchar='unsigned char', d_stdstdio=define, usevfork=false
intsize=4, longsize=4, ptrsize=4, doublesize=8
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
alignbytes=8, usemymalloc=y, prototype=define
  Linker and Libraries:
ld='ld', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib /usr/ccs/lib
libs=-lsocket -lnsl -lgdbm -ldl -lm -lc -lcrypt
libc=/lib/libc.so, so=so, useshrplib=false, libperl=libperl.a
  Dynamic Linking:
dlsrc=dl_none.xs, dlext=none, d_dlsymun=undef, ccdlflags=''
cccdlflags='', lddlflags=''


Characteristics of this binary (from libperl): 
  Built under solaris
  Compiled at Jun 16 2000 17:02:50
  @INC:
/usr/local/lib/perl5/5.00503/sun4-solaris
/usr/local/lib/perl5/5.00503
/usr/local/lib/perl5/site_perl/5.005/sun4-solaris
/usr/local/lib/perl5/site_perl/5.005
.
==
httpd_perl -l
--
Compiled-in modules:
  http_core.c
  mod_env.c
  mod_log_config.c
  mod_mime.c
  mod_negotiation.c
  mod_status.c
  mod_info.c
  mod_include.c
  mod_autoindex.c
  mod_dir.c
  mod_cgi.c
  mod_asis.c
  mod_imap.c
  mod_actions.c
  mod_userdir.c
  mod_

Re: [DESPERATE] Problems with apache-php3perl SRPM

[G.W. Haywood]

Hi again,

On Sat, 10 Jun 2000, Ian C. Sison wrote:

> 
> omigod...!   
> 
> It worked!   



> Ok now, i've commented out the ClearModuleList directive , apache loaded
> ok. Would there be any side effects to the directive, as it seemed to be
> there for a purpose...

Well not side-effects exactly...  the most usual reason for this
directive is to get rid of a module which has effects that you don't
want but which happens to be compiled in.  Trouble is then you have to
put AddModule/LoadModule directives into the configuration to get back
the modules you _do_ want because ClearModuleList, er, Clears Apache's
Module List.  So you can either recompile Apache with just the modules
you want, or (horrors!) use DSO and only pull in the ones you want, or
carry on as you are if it works OK as it is.  The httpd processes will
be a little bigger than necessary if it has modules compiled in that
you don't need.  No matter.

> Thanks for your help!

Aw, shucks.

73,
Ged.

Re: frontend proxy really useful?

[G.W. Haywood]

Hi again,

On Sun, 21 May 2000, Chris Nokleberg wrote:

> On Sun, 21 May 2000, G.W. Haywood wrote:
> 
> > It might take a couple of minutes if the client is on a slow line.
>
> But the guide seems to be saying that the speed of the client isn't 
> an issue--the process (proxy _or_ mod_perl) is released as soon as it
> finishes putting the outputted page into the OS socket buffer. I assume
> "released" means it can go and serve another request. Am I reading it
> wrong?

No.

But what happens if the socket is still full of data from the previous
request when the child attached to that socket gets another request
for another socket-buffer-full?  That's when you run into the problem.

73,
Ged.

Re: frontend proxy really useful?

[G.W. Haywood]

Hi there,

On Sat, 20 May 2000, Chris Nokleberg wrote:

> I was rereading
> 
>   http://perl.apache.org/guide/scenario.html#Buffering_Feature
> 
> does it make the light frontend buffering proxy technique useless as
> long as your pages fit in the socket buffer size (256K on Solaris)?
> (assuming the proxy is just a dumb passthrough to one backend
> server)

You might think that it serves little purpose for a light Apache
server simply to pass all requests from a socket through to a heavy
mod_perl server, only then to receive the reply and pass it back to
the socket.

But you don't usually know what is the other side of the socket, and
so you don't know how fast the buffer will be emptied.  It might take
a couple of minutes if the client is on a slow line.

Your processes could all be waiting for the socket buffers to be
emptied by slow clients, so there may be no free child to serve an
incoming request.  In that case Apache will just keep spawning new
ones (if it's allowed) for any new incoming requests.  You could build
up a big heap of waiting processes.  You will have far less resources
consumed by the waiting processes if they are plain Apache children
than you will if they are Apache+mod_perl children.  So you will be
able to spawn more processes, and so serve more incoming requests.

It depends of course on the profiles of your users, the resources
requested, etc.etc...  You can make measurements, or calculations, or
guesses, or you can just wing it.  But you don't want to let Apache
spawn so many children that you get into swapping, nor do you want to
force your clients to wait unnecessarily.

73,
Ged.

Re: LARGE PERL footprint

[G.W. Haywood]

Hi there,

On Fri, 19 May 2000, David Larkin wrote:

> Can anyone help explain why PERL gives such a large memory
> footprint & advise how to get around it.

In addition to the other suggestions, you might want to try

use integer;

in the bits of your Perl code that manipulate integers.

> I guess I'm paying the price for PERL not being strongly typed,
> a feature I really like ( until now ;-) )

Hmmm.

> I require a large array of ints in a real application

Er, real (as opposed to floating point:) ?

73,
Ged.

Re: Virtual servers mixing up "require"d scripts

[G.W. Haywood]

Hi all,

On Sun, 14 May 2000, Uri Bernstein wrote:

> Geoffrey Young wrote:
>> http://perl.apache.org/guide/control.html#Starting_a_Personal_Server_for_E
>> Ged Haywood wrote:
>>> You shold use one real server per developer.  Make them listen on
>>> different ports (>1024).  You won't lose much on memory.

> - Is this a known bug, or an unavoidable by-product of the way
>   mod_perl works?

The latter.

> - Is it related to the fact I'm using Apache::Registry? Would
>   switching to the native Apache API fix it?

> - Is it related to the fact I'm using "require", with ".pl" files?
>   Would switching to "use" (with .pm modules) fix it?

I guess the previous answer answers all these too.

73,
Ged.

Re: speed up/load balancing of session-based sites

[G.W. Haywood]

Hi there,

On Tue, 9 May 2000, Leslie Mikesell wrote:

> I'm more concerned about dealing with large numbers of simultaneous
> clients (say 20,000 who all hit at 10 AM) and I've run into problems
> with both dbm and mysql where at a certain point of write activity
> you basically can't keep up.  These problems may be solvable but
> timings just below the problem threshold don't give you much warning
> about what is going to happen when your locks begin to overlap. 

Can you use a RAMdisk?

73,
Ged.

Re: apache1.3.12, modperl1.23, perl5.6, ApacheJServ1.1, OpenSSL0.9.4, modssl

[G.W. Haywood]

Hi there,

On Mon, 8 May 2000 [EMAIL PROTECTED] wrote:

> I've expirienced similar problems on Solaris (2.6).  After a weeks
> worth of hours I feel confidant saying that the instability is from
> perl 5.6.0 NOT from mod_perl(1.23)
[snip]
> IMHO Solaris(2.6)Perl(5.6) just isn't fully cooked yet.

>From what I've seen Solaris is not much worse than any other OS for
bugs.  But Stas and I both reacted in the same way when 'perl -MCPAN'
tried to upgrade Perl 5.005_03 to 5.6.0 on our development machines.

We stopped it immediately.

It's just too new.  People who like being on the bleeding edge have a
lot of fun testing things so that the more pedestrian of us can have
more reliable products.  I like it that way, and I thank them.
 
There are no secrets about any of this.

I think you were brave indeed to jump into 5.6.0 so soon.  I'll leave
it for at least several months, and then I'll run it on a development
machine to start with.

> I'd just like to say that in this regard I didn't find Open Source
> very Open.  In fact things seemed quite corporate with the
> newsgroups and mailing lists saying "off topic for here" or even
> failing to post legitimate questions.

I can't agree with this.  You have to do a lot of homework if you are
to avoid wasting a lot of very valuable time that you have no right to
waste, and you can't blame people who tell you things for telling you
again if you didn't listen the first time.  But if you do the homework
and try your best to stick to the conventions you'll find tremendously
valuable resources.  Free.

> These products are getting so intertwined the definition of what
> topic belongs where begins to get mighty grey.

I _can_ agree with this.  And if you spend time reading this List you
will see, I'm sure, that its readers take a fairly relaxed view about
[OT] posts.  But you *do* have to do a bit of work if you are to earn
respect - anywhere.  I think it was Graucho Marx who said he didn't
want to join any club that would have him as a member...

> Then again maybe I just didn't read enough FAQs to ask the question
> the right way. I'm not wanting to start a flame war, just reporting
> it as I see it.

Don't sweat it, I'm sure no-one will be offended:)

73,
Ged.

Re: [excitement :)] mod_perl rocks!

[G.W. Haywood]

Hi Stas,

On Mon, 8 May 2000, Stas Bekman wrote:

> Take a look at the updated graph of the mod_perl growth:
> 
> http://perl.apache.org/netcraft/
> 
> Pay attention to the ramp!
> 
> BTW, Apache holds 61.53% of the server market share!!!

So it's gone down a bit then??

73,
Ged.




> http://www.netcraft.co.uk/survey/

Re: Memory usage on reload and graceful -- still broken?

[G.W. Haywood]

Hi all,

On Thu, 20 Apr 2000, Doug MacEachern wrote:

> > I have a static Solaris compilation, and have the same problems 
> > where the parent seems to grow by 1M each HUP.
> 
> that's strange, do you have PerlFreshRestart On or some  sections?
> otherwise, kill -HUP with a static modperl is a noop.

I was going to get into this at some stage before family illness took
me almost completely away from work, but since this thread has cropped
up I might as well mention it.  Dunno if it's relevant, but it's
suspicious.

When I do apachectl restart on Linux 2.0.34/libc5/1.3.9/1.21/5.005_03
(static build!) I noticed that for each restart @INC appeared to have
an extra copy of the same element, which is set in the BEGIN block in
startup.pl by a line like `use lib sever_root_relative("lib/perl");'.

Unfortunately this is on my development machine and I am away from my
office because of the family problems so I can't give you much more
than that at present.  I expect to visit my office sometime within the
next week so if you think there is anything that I can send to help
pin this down please let me know and I'll try to oblige.  It's no
sweat to me at all, of course.  I'm not even sure I'm getting @INC
correctly - it's well down on my priorities to check it at present.

73,
Ged.

Re: Problem Compiling with Perl 5.6.0

[G.W. Haywood]

Hi there,

On Thu, 30 Mar 2000, Steve Hay wrote:

> Since I had no reply to my previous problem (re-directing STDOUT in
> system() calls), 

This is probably because you're talking about NT.  Don't take it
personally.

> I thought I would try using Perl 5.6.0 instead of > 5.005_03

Brave chap.

> (probably a good idea anyway)

No, I don't think so, not on NT, not yet.  Come to think of it, NT
probably wasn't the best idea you ever had either.

> Unfortunately, now I can't get (the Apache side of) mod_perl to
> compile.

You aren't alone.  You really are on the bleeding edge with that lot.
My advice would be ro try Linux, and stick with Perl 5.005_03 and
mod_perl 1.21/Apache 1.3.11 (or .12) for a few weeks.

73,
Ged.
PS: Horrible mail problems here just now, reply only to mod_perl List.

Re: Problem Compiling with Perl 5.6.0

[G.W. Haywood]

Hi there,

On Thu, 30 Mar 2000, Steve Hay wrote:

> seems a shame I can't get it to go with Perl 5.6.0.  I just wondered
> if anyone out there new of any more hacks to help...

Search the mod_perl List archive for 5.6.0?  Most of it will be about
it not working with something or other.  After all, it's hardly been
out a week yet...

73,
Ged.

Re: [asp] $Response->{FontFace} ?

[G.W. Haywood]

Hi Joshua,

On Mon, 27 Mar 2000, Joshua Chamas wrote:

> I have a huge site that I want to apply a generic font face to with
> Apache::ASP.  Has anyone here ever been bothered before that you
> can't just wrap the body doc with a default font and have that be
> it.  No CSS please.  But what about those pesky s that seem
> to break it all?

Yeah, I've bothered.  I really don't care about the font face, but I
want to talk about the SIZE.  But it *has* to be configurable per
client.  When you get to my age, the fine print on the majority of Web
sites is completely illegible with the default browser text sizes.
Young whipper-snappers writing HTML don't realize what a problem that
can be.  So I want my older users (they have more money...) to be able
to read my sites.

There are millions of visually impaired people (ten percent of males
are red/green colour blind) who would bless you if they knew you had
done a little something to make the Web more accessible to them.  They
could choose their own colours as well as text size and font.

So please, Joshua, do it, or I'll have to invent my own tags.  I was
thinking of something like a chained Apache::Footer with some sort of

s//<$FONT_TAG_per_client_session_or_maybe_loginid>/;

construct in it so that users could click on

Bigger Text

or

Smaller Text

but I'm well aware that this would be a crude implementation of what
could be a really nifty feature.

> {FontFace}> at the start of a 
> Script_OnFlush hook,

Don't have any strong feelings on the implementation.  I would use
extra path info, probably with handlers to strip out the mush, but I
suppose you'd want to make it cookie based?

73,
Ged.

Re: $r->print delay?

[G.W. Haywood]

Hi there,

On Thu, 10 Feb 2000, Ed Loehr wrote:

> Fairly certain it's waiting there.  I cut my debug timestamps out for
> ease on your eyes in my earlier post, but here's one output (of many
> like it) when I had the print sandwiched...
> 
> Thu Feb 10 14:41:59.053 2000 [v1.3.7.1 2227:1 ed:1]  INFO : Sending
> 120453 bytes to client...
> Thu Feb 10 14:42:14.463 2000 [v1.3.7.1 2227:1 ed:1]  INFO : Send of
> 120453 bytes completed.
> 
> Re send_fd(), it's all dynamically generated data, so that's not an
> option...

So write a file...?

I take it you've tried telnet/lynx?  Sorry if you said earlier and I
missed it, I haven't read this entire thread.

73,
Ged.

Re: [SITE] possible structure suggestion

[G.W. Haywood]

Hi all,

On Thu, 10 Feb 2000, Stas Bekman wrote:

> > >text
> >   - this is much easier obviously, however I've often heard people say
> > they thought text-navigation was easier with the navbar at the top
> > and bottom of the page. I'd like to have opinions on this, but
> > please let's avoid religion wars on this subject.
> 
> I think what you wanted/need to write here is a lynx compatibility for
> the impared folks and those who prefer text mode browsing.

For speed, I like to use Lynx but it's a pain with sites that have
navbars at the *top*.  Unless they have thought about it carefully
they are often not navigable with Lynx.

73,
Ged.

Re: Problems with configuration

[G.W. Haywood]

Hi there.

On Sun, 6 Feb 2000, al wrote:

> I'm having the following problems:

>   i) Occasionally, for not reason at all, I get 'The Document
> contained no data, try again later' errors on Netscape, and pressing
> reload usually gets rid of this. Also, nothing is logged in the
> error logs when this happens. Is there any way to get rid of this
> tempementality?

My guess is that it's your code that's tempermental.  See

http://perl.apache.org/guide

and look at (for example) "Sometimes it works, sometimes it doesn't".

>   ii) When I use 'print "Location: some_page.cgi\n\n";', it
> usually prints this on the screen. I have PerlSendHeader set to On,
> though I assumed this would parse existing headers appropriately.

Can you explain to me what you are trying to do here?

>   iii) Sometimes a dynamical script gets cached, though even
> when values that the script relies on change in the database, the
> page displayed doesn't report these changes.

Sound like you're not asking the database for the new values.  Time to
do some debugging.  It's in the Guide.

> I'm running mod_perl 1.19 and Apache 1.3.4.
> Does anyone have any idea if I'm doing something wrong?

I'd think about upgrading both, maybe after the 2 Feb CERT patch for
1.3.11 (or 1.3.12?) comes out.  How far away is 2.0.0, anybody?

73,
Ged.

Re: Commercial app demo

[G.W. Haywood]

Hi there,

On Thu, 10 Feb 2000, Fabrice Scemama wrote:

> There's another way. We can't build pre-compiled modules easily,
> but even when you code in C or Java, desassemblers can extract
> some source from the binaries you deliver. As far as perl scripts are
> concerned, a workaround consists in trivially removing all comments
> and \n from the source, which makes it as hard to understand as
> raw C desassembled code.

Perl is only *semi* free-format.  Removing \n will break much Perl
code, for example because of the use of the print <

Re: .makepl_args.mod_perl

[G.W. Haywood]

Hi there,

More topical:

Well I think we've done that one.  It seems that if not actually an
error the documents conspire to confuse.  Certainly one for the errata
even if it's not really wrong.  I have a couple of dozen other notes
about the Eagle Book, is there a CVS snapshot of the errata somewhere?
Or something like that?  I'd be glad to contribute/modify/whatever.

Less topical:

On Fri, 4 Feb 2000, Bakki Kudva wrote:

> the word hyphen (according to Webster) from Greek hyph'hen meaning
> "under one" would seem to mean the underscore while the punctuation
> mark for hyphen is '-'.

Would this be an electronic Webster?  It's a little short on content.

The word `hyphen' is late latin.  Its first recorded use in English
seems to be about 1620 [OED].  It means in Latin exactly what we mean
by it today.  The simliar Greek word of the four (er, Greek) letters
upsilon-phi-epsilon-nu means a symbol like the one which is used with
the phonetic alphabet (at least in England) to denote a short vowel
such as both `a's in `amoeba'.  It looks like an upside-down curved
cicumflex or an opening parthenthesis rotated anti-clockwise through
90 degrees.  It is always placed over the vowel.

Sorry, nohow do we get anything you could call an underscore.

73,
Ged.

PS: Stas, erratum = one of them.  Er, it.
  errata = more than one of them:)

Re: Problems during Apache mod_perl and ASP installation

[G.W. Haywood]

Hi there,

On Fri, 4 Feb 2000, Diego Gomez wrote:

>  sh: ./Configure: File or directory not exist

Look in the Guide, in the files `install.pod' and `scenario.pod'.

I think you will find everything you need is there on the first page
or so of each.

73,
Ged.

Re: .makepl_args.mod_perl

[G.W. Haywood]

Hi there,

It looks like you have all your questions answered now, but I have one
or two.

On Fri, 4 Feb 2000, Bakki Kudva wrote:

> I read the guide and there is no mention of this. Also I noted that
> in the guide most paramters are listed in the blue boxes as PERL-*
> instead of PERL_*.

Stas is right, there is no instance of PERL- in his Guide.  And what's
this about blue boxes?  Don't forget that some of us worry so much
about x-rays and our eyes (or are so old-fashioned) that we still use
monochrome screens for the serious stuff...

So where did you get this `guide' and what referred you to it?  We
should find it and try to prevent other people being led astray by it.

73,
Ged.

Re: [Rare Modules] Apache::RegistryNG

[G.W. Haywood]

Hi there,

On Fri, 4 Feb 2000, Stas Bekman wrote:

> C inherits from C, but the
> handler() is overriden.

Does this have any implications for users of `dirty' scripts?

Obviously such scripts will be `legacy' code, of course...

73,
Ged.

Re: RareModules

[G.W. Haywood]

Hi all,

On Fri, 4 Feb 2000, Stas Bekman wrote:

> I suggest to open a series of posts whose goal to make the
> introduction of new and old modules [snip] What do you think?

Good idea!

Let's do Apache::VMonitor - I read in the docs that it needs GTop
so I read the GTop docs and that needs...

Don't you just hate it when that happens?

Can I run Apache::VMonitor on my libc5 systems?

73,
Ged.

Re: DSO build questions

[G.W. Haywood]

Hi there,

On Thu, 3 Feb 2000, Wang, Pin-Chieh wrote:

> Ged,
> Thanks much for your help, Please tell me if I asked too many
> questions, If you don't I'll keep on ask you questions.  After I
> said that, here is another question.

You aren't asking too many questions, but please forgive me if I can't
get to them to answer them as quickly as you would like.

> I am building an Apache with Mod_perl under DSO. I thought I did
> right, I am using the following parameters for Makefile.PL under
> mod_perl-1.21 directory
> 
> APACHE_SRC=../apache_1.3.11/src USE_APACI=1 DO_HTTPD=1 \ 
> ADD_MODULE=rewrite,so,status,info \
> APACHE_PREFIX=/usr/local/apache_dso \
> PERL_MARK_WHERE=1 EVERYTHING=1 
> 
> I then
> Make
> Su
> Make install
> 
> I then 
> cd ../apache_1.3.11
> ./configure -enable-module=so -enable-module=info
> -prefix=/usr/local/apache_dso
> make
> su
> make install

When you write USE_APACI=1, after you have done 'make install' in the
mod_perl directory you do not have to build in the Apache directory,
mod_perl does it for you.  Watch the output of the scripts and the
compiler as they run, and you will see what is happening if you are
quick.  Use control-s to stop the output if you are not quick, then
use control-q to restart it.

You need to read some more.  Have a look especially at `scenario.pod'
in the Guide.  It builds mod_perl in several different ways, which you
can probably manipulate to suit your own needs.  Unfortunately I have
been ill with 'flu' so my rewrite of this section of the Guide is only
just finished today.  I can't send it to you because Stas needs to
look at it now to make sure I haven't completely screwed it up.  All
the technical information you need is in the existing version (which I
am assuming you now have!), it's just slightly better English after my
rewrite.  I hope.  When we've attended to the English, there will be
some more reorganizing.  Sorry for the inconvenience...

To get mod_perl's Makefile.PL to add your modules you can add lines
like this to your Makefile.PL argument list:

  % /usr/local/bin/perl Makefile.PL \
  APACHE_SRC=../apache_1.3.11/src USE_APACI=1 DO_HTTPD=1 USE_DSO=1 \ 
  APACHE_PREFIX=/usr/local/apache_dso \
  PERL_MARK_WHERE=1 EVERYTHING=1 \
  APACI_ARGS= --enable-module=so, \
  --enable-module=info

The line in your command to perl Makefile.PL which reads:

> APACHE_SRC=../apache_1.3.11/src USE_APACI=1 DO_HTTPD=1 \ 

tells Makefile.PL to make Apache as well as mod_perl but it does not
tell mod_perl to make a DSO binary, that's why I put USE_DSO=1 in my
version above.  You won't save as much memory as you might think using
DSO, and I'd avoid it until there are fewer questions about it.  The
line in your command which reads:

> ./configure -enable-module=so -enable-module=info

should I think read:

./configure --enable-module=so --enable-module=info

which tells Apache that it is to be linked with the mod_info module
and it is to be built ready to load modules dynamically (at run-time,
instead of linking them at compile-time) but it does not mean build
mod_perl itself as a Dynamically Shared Object.

Remember to do 'make clean' in both the mod_perl and the Apache
directories before you start again.

Read the Guide!

Hope this helps.

73,
Ged.

Re: RFD: comp.infosystems.www.modperl

[G.W. Haywood]

Hi all,

On Thu, 3 Feb 2000, Tim Peoples wrote:

> Yet, strangely, *this* thread seems to have threaded nicely (at
> least in 'mutt').

Well, sort of.

I use pine and the inbox default sort is as received.  Which means
that I seem to see most of the answers before I see the questions.

Entertaining, though.

73,
Ged.

Re: lookup_uri and access checks

[G.W. Haywood]

Hi there,

On Thu, 3 Feb 2000, Paul J. Lucas wrote:

> > Are you checking the status of the subrequest?
> No.  Intentionally.  As I wrote, I don't care what Apache says about
> the accessibility of the file.  I *will* read it.  All I want to do
> is suppress the "client denied by server request" messages in the
> log.

I suppose you could take over the logging process entirely (e.g. Eagle
Book pp 360-367, 669, CPAN, and if you're into C 684).  Then you could
do what you like with the error messages, including throw them away on
a selective (hopefully a very selective) basis.

But I'd urge caution in throwing away any log information, whatever it
is, before a sentient being has had a look at it.

Hope this helps.

73,
Ged.

Re: New Bloke question - modifying canned footer (Eagle book)

[G.W. Haywood]

Hi there,

On Thu, 3 Feb 2000, Oliver Holmes ITS 1999 wrote:

> I've got the canned footer (Eagle book chapter 4) up and running,
> and it edits html files on the local host fine using the  "\.html$">... directive.  I was wondering how to implement the
> footer so that it appeared on all html files (ie. external files),
> and not just local html files.

Do you mean that you want your server to act as a proxy?

73,
Ged.

Re: lookup_uri and access checks

[G.W. Haywood]

Hi there,

On Wed, 2 Feb 2000, Paul J. Lucas wrote:

>   I have code that contains the line:
>   $r->lookup_uri( $r->param( 'pm_uri' ) )->filename;
>[snip] 
>   However, if I have an access restriction that forbids access to
>   files ending in a .pm extension and the URI maps to such a
>   filename, then I get a "client denied by server confiruation"
>   message in the error log.

Are you checking the status of the subrequest?  (Eagle book, p453).

my $subr = $r->lookup_uri( inaccessible_file );
my $status = $subr->status;
unless( $status == HTTP_OK ) { dont_access_the_file(); }

73,
Ged.

Re: make test fails

[G.W. Haywood]

Hi there,

On Thu, 27 Jan 2000, Jeff Beard wrote:

> running make test fails and produces the errors listed at the end of
> this message.  I searched the list archives and found a posting that
> suggested rebuilding Perl with the same compiler and tools that I
> use for apache and mod_perl. So I did but it didn't fix the
> problem. I did in fact build Perl the first time with gcc 2.8.1,
> then built gcc 2.95.2 from source. But I rebuilt Perl with the new
> compiler and get the same results.

I think the bit about using the same compiler means don't use gcc and
ztcpp, you ought to get away with 2.8 and 2.95, but it's good advice.

You're obviously comfortable with compiling your tools, so you could
try a few more recompilations.  My first try would be a static build.
It seems dynamic linking is responsible for all kinds of problems.  I
built mySQL for a customer yesterday and the Perl interface wouldn't
run with dynamic linking of Msql-Mysql-modules, no matter what I did.
No problems at all with --static.

If that fails I'd try with a minimum set of modules (just mod_perl to
start with, leave out php/mod_ssl) and work up from there to see what
(if anything) triggers it.  There have been questions about Apache
1.3.11 with mod_perl.  Try Apache 1.3.9?

There are several other possibilities.  Where is apache_1.3.11?  I
found I had to put both the mod_perl and Apache directories in
/usr/local, i.e. /usr/local/apache_1.3.9 and /usr/local/mod_perl-1.21.
Did you delete everything before recompiling?  You should.  Have you
tried `make distclean'?

Let me know how you get on.

73,
Ged.


> The environment, etc. is:
> 
> Solaris 2.6 on an Ultra 1
> gcc 2.95.2
> Sun's build tools (ld, nm, ar, etc.)
> Perl 5.005_03
> apache 1.3.11
> mod_perl 1.21
> 
> Other "3rd party" mods I'm including:
> php 4.0b3
> mod_ssl 2.5.0-1.3.11
> 
> Appended are perl -V output and the errors from make test
> 
> Thanks for your help.
> 
> --Jeff
> 
> Perl Version:
> 
> Summary of my perl5 (5.0 patchlevel 5 subversion 3) configuration:
>Platform:
>  osname=solaris, osvers=2.6, archname=sun4-solaris
>  uname='sunos wiggy 5.6 generic sun4u sparc sunw,ultra-1 '
>  hint=recommended, useposix=true, d_sigaction=define
>  usethreads=undef useperlio=undef d_sfio=undef
>Compiler:
>  cc='gcc -B/usr/ccs/bin/ -B/usr/ccs/bin/', optimize='-O', 
> gccversion=2.95.2 19991024 (release)
>  cppflags='-I/usr/local/include'
>  ccflags ='-I/usr/local/include'
>  stdchar='unsigned char', d_stdstdio=define, usevfork=false
>  intsize=4, longsize=4, ptrsize=4, doublesize=8
>  d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
>  alignbytes=8, usemymalloc=y, prototype=define
>Linker and Libraries:
>  ld='gcc -B/usr/ccs/bin/ -B/usr/ccs/bin/', ldflags =' -L/usr/local/lib'
>  libpth=/usr/local/lib /lib /usr/lib /usr/ccs/lib
>  libs=-lsocket -lnsl -ldl -lm -lc -lcrypt
>  libc=, so=so, useshrplib=false, libperl=libperl.a
>Dynamic Linking:
>  dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' '
>  cccdlflags='-fPIC', lddlflags='-G -L/usr/local/lib'
> 
> 
> Characteristics of this binary (from libperl):
>Built under solaris
>Compiled at Jan 23 2000 14:15:33
>@INC:
>  /usr/local/lib/perl5/5.00503/sun4-solaris
>  /usr/local/lib/perl5/5.00503
>  /usr/local/lib/perl5/site_perl/5.005/sun4-solaris
>  /usr/local/lib/perl5/site_perl/5.005
> 
> 
> make test errors:
> 
> [Thu Jan 27 13:51:41 2000] [error] Can't load 
> '/usr/local/lib/perl5/5.00503/sun4-solaris/auto/IO/IO.so' for module IO: 
> ld.so.1: ../apache_1.3.11/src/httpd: fatal: relocation error: file 
> /usr/local/lib/perl5/5.00503/sun4-solaris/auto/IO/IO.so: symbol main: 
> referenced symbol not found at 
> /usr/local/lib/perl5/5.00503/sun4-solaris/DynaLoader.pm line 169.
> 
> 
> 
> Jeff Beard
> ___
> Web:  www.cyberxape.com
> Phone:303.443.9339
> Location: Boulder, CO, USA
> 

Re: I give up... I'm just going to follow the instructions....

[G.W. Haywood]

Hi there,

On Thu, 27 Jan 2000, Richard Ayres wrote:

> Rather than trying to manhandle it all into RedHat's directory
> structure *I* would rebuild apache & perl etc. either into
> /usr/local or their own subdirectory under /opt. That way you get to
> keep all the RedHat cruft, and keep it happy with its own perl - but
> you also have your own copies for apache.

I second that.

73,
Ged.

Re: loading mod_perl DSO on a per-virtualhost basis?

[G.W. Haywood]

Hi Thomas,

On Wed, 26 Jan 2000, James G Smith wrote:
> Thomas Corte <[EMAIL PROTECTED]> wrote:
>>So, if I switch to DSOs for (at least) mod_ssl and mod_perl, can I expect
>>to decrease top's values above significantly?
>
> I don't think so.  My understanding of DSOs in Apache was to allow
> inclusion of code without recompiling the whole thing.  This allows
> for third-party proprietary modules.  The DSOs can, in general,
> share code across binaries, not processes.  All processes sharing a
> binary don't have separate copies of the binary, or shouldn't.
> However static libraries cannot be shared between binaries.  Only
> DSOs.  Your biggest savings could come from making the perl core a
> DSO so the perl binary and Apache share the same core perl
> interpreter code.

James is quite right, but I'm told that even making the perl core a
DSO won't give the savings that I think you are hoping for.

In a mod_perl box, as far as memory consumption is concerned, the
processes of concern are usually the Apache children.  They are fairly
big, and there can be a lot of them.  Because of the way that Apache
tries to preempt incoming requests by pre-forking a pool of children
`just in case', you may not always know how many!  They share a good
chunk of their memory when they are forked, but then as a result of
copy-on-write (two or more processes share a page of memory, one wants
to change it, the others don't, so a copy has to be made just for that
process) the memory gradually (or otherwise) becomes unshared.  When
they grab some memory to store a large object, the children have a
habit of hanging on to it until they die.  In addition there have been
memory leakage and similar problems which have sometimes caused the
Apache children to do antisocial things like growing without bound and
refusing to die.  Some of these problems are being dealt with as new
releases come out and I'm sure that a lot of us have high hopes for
mod_perl 1.22.

Running a second server (a `proxy', not mod_perl enabled, and which
listens normally on port 80 but always on a _different_ port from the
mod_perl enabled server) to serve static documents, tweaking the
server configuration variables such as MaxRequestsPerChild to limit
child growth, the use of modules designed to limit the processes'
resource consumption, and faster networks, clients and servers can all
offer partial solutions, but I feel that memory footprint is going to
remain an issue with mod_perl until memory is much cheaper per byte
(happening as we write) or until Doug and friends make it use less, or
until something unthinkable happens - like the technology becoming
obsolete overnight because of a breakthrough elsewhere.

In the meantime, some people are using Gigabytes of RAM to cope with
their mod_perl children.

I hope this isn't too depressing:)

73,
Ged.

Re: Apache problem with mod_example

[G.W. Haywood]

Hi there,

Mail to your address keeps coming back with fatal errors, so I'm
sending this to the mod_perl List in the hope that we have more luck.

73,
Ged.

On Wed, 26 Jan 2000, Mail Delivery Subsystem wrote:

> The original message was received at Wed, 26 Jan 2000 08:59:57 GMT
> from ged@localhost
> 
>- The following addresses had permanent fatal errors -
> <[EMAIL PROTECTED]>
> 
>- Transcript of session follows -
> ... while talking to zmamail03.zma.compaq.com.:
> >>> RCPT To:<[EMAIL PROTECTED]>
> <<< 554 Service unavailable; [212.1.144.72] blocked using dul.maps.vix.com
> 554 <[EMAIL PROTECTED]>... Service unavailable
> 

On Tue, 25 Jan 2000, Wang, Pin-Chieh wrote:

> Hi Mr. Haywood,

Please, call me `Ged'.  People are less formal on the Web, I think.

> It turn's out the apache and mod_perl is working after all.

I was sure that Apache was running OK.  That's great!

> when I called 
> //localhost:8080/hello/world everything starts working now.

> But, when I called 
> //localhost:8080/server-info
> I got permission denied. Do you know how can I grant my permission?
> Or just ask for username password?

I took this from your file `Configuration'.  Have you uncommented
the statement and recompiled Apache?  mod_info is required before
you can get server-info.

# AddModule modules/standard/mod_info.o

I also took this from your file `httpd.conf'

# Allow remote server configuration reports, with the URL of
#  http://servername/server-info (requires that mod_info.c be loaded).
# Change the ".your_domain.com" to match your domain to enable.
#
#
#SetHandler server-info
#Order deny,allow
#Deny from all
#Allow from .your_domain.com
#

You have to edit this part of the file to give yourself permission
to get server-info.

Hope this helps.

73,
Ged.

Re: PLEASE HELP - ERROR Linking Apache with mod_perl

[G.W. Haywood]

Hi there,

On Thu, 20 Jan 2000, Asghar Nafarieh wrote:

> cd mod_perl-1.21
> perl Makefile.PL PREP_HTTPD=1

I took this from the Guide:

  % cd /usr/src
  % lwp-download http://www.apache.org/dist/apache_x.x.x.tar.gz
  % lwp-download http://perl.apache.org/dist/mod_perl-x.xx.tar.gz
  % tar zvxf apache_x.x.x.tar.gz
  % tar zvxf mod_perl-x.xx.tar.gz
  % cd mod_perl-x.xx
  % perl Makefile.PL APACHE_SRC=../apache_x.x.x/src \
DO_HTTPD=1 USE_APACI=1 PERL_MARK_WHERE=1 EVERYTHING=1
  % make && make test && make install
  % cd ../apache_x.x.x
  % make install

What happens if you try it this way?

Re: Apache::AuthCookie takeover?

[G.W. Haywood]

Hi there,

On Sat, 22 Jan 2000, Ken Williams wrote:

> should I
> 
>   * make a new module with a new name, since some of my changes have changed 
> the interface, or
>   * usurp the Apache::AuthCookie module and provide a clear stepwise migration 
> path?  Doug said he'd be willing to make me the maintainer.

I think the last thing we need is *another* AuthModuleName.

Just my 0.02p worth.

73,
Ged.

Re: problem with example 4-9 eagle book

[G.W. Haywood]

Hi there,

On 21 Jan 2000, Fernando Rowies wrote:

> first: trying example 4-9 from eagle book the result is an unvarying
> behavior. Running for first time it display the banner randomly,
> then, when i reload the page, take another randomly, but the third
> or fourth reload, no more pick_randomly_the_image, it display the
> last, the last, last, last, last... what happen?

I think maybe you need to check your typing carefully.  If you mail
your code I can check it for you very quickly.

> second: same example with the two last lines from the handler()
> subroutine replaced with the code suggested in the book (to suppress
> the "bad performance bottleneck" in the original example), no more
> images at all, just broken image icons. again, what happen?

I think the book has some mistakes.  Try `lookup_file()' instead of
`lookup_uri()' in the first line of the code on page 128 and put

return OK if $r->header_only;

instead of

return OK unless $r->header_only;

at the fourth line, the same as in the fragment of code lower down
on that same page.

When you get to the second code fragment, don't forget to import
DOCUMENT_FOLLOWS by adding it at the top of the file:

use Apache::Constants qw(:common REDIRECT DOCUMENT_FOLLOWS);
  
73,
Ged.

RE: Why does Apache do this braindamaged dlclose/dlopen stuff?

[G.W. Haywood]

Hi there,

On Fri, 21 Jan 2000, Stephen  Anderson wrote:

> > So in the longer term, is there a reason the parent has to contain the
> > interpreter at all?  Can't it just do a system call when it needs one?
> 
> Well, remember that the interpreter itself will remain shared
> throughout, so there's no real disadvantage in having in the parent.

I thought that if the parent was light it could replace its proxy,
which would save a lot of messing about.

> I think the thing to do here is fix the memory leaks 8-)

Can't argue with that.

73,
Ged.

Re: oracle : The lowdown

[G.W. Haywood]

Hi there,

On Thu, 20 Jan 2000, Perrin Harkins wrote:

> We're veering WAY off-topic here

Maybe.  But I for one am happy for the diversion.  A lot of mod-perl
sites are doing just this kind of thing - after all, mod-perl is just
a link in a chain, it's of no use intrinsically without some things to
link together!  Greg has given me some valuable insights.

> you can't guarantee your data will be in a consistent state without
> transactions or some other way to do atomic updates
[snip]
> (e.g. you're running a message board and who cares if a post gets
> lost somewhere) then transactions might be considered unnecessary

Might be?  Having worked with a BTREE/ISAM package written in C and
assembler for the last 15 years or so, I wouldn't dream of using a DB
for some of this stuff.  It would just get in the way and be 100 times
slower than my C code.  I lock records as necessary so the data will
*always* be consistent and a whole bunch of gotchas simply evaporates.
For a lot of things on the Web, you can even get away with just the
operating system and flat files half the time.

I've got to admit that the way machine performance is going there may
come a time when it's just not worth the extra effort of tinkering in
the guts but we aren't nearly there yet.  Why do so many people seem
to insist on using a sledgehammer to crack a nut?  Horses for courses,
as we join our metaphors around here.

Just my 0.02p...

73,
Ged.

Re: Apache::ASP Debugging

[G.W. Haywood]

Hi there,

On Thu, 20 Jan 2000, suresh gopal wrote:

> since the eval of the program puts some of the errors to STDERR -
> which goes to log file ( i hope this explaniation is correct). Is
> there a way to display these infomation to the browser output??

I don't think I'd want to do that.  What's the reason for asking?

73,
Ged.
 

RE: Why does Apache do this braindamaged dlclose/dlopen stuff?

[G.W. Haywood]

Hi all,

On Wed, 19 Jan 2000, Gerald Richter wrote:

> in the long term, the solution that you have prefered in previous
> mail, not to unload modperl at all, maybe the better one

As I understand it with Apache/mod_perl:

1.  The parent (contains the Perl interpreter) fires up, initialises
things and launches some children.  Any memory it leaks stays
leaked until restart.  That could be weeks away.  Apart from
making copies of it, most of the time it doesn't do much with the
interpreter.  More waste.

2.  The children occasionally get the coup de grace, so we recover
any memory they leaked.  They do lots with the interpreter.

3.  When the parent fork()s a new child it can fork some leaked memory
too, which gradually will become unshared, so the longer this goes
on the closer we get to bringing the whole system to its knees.

So in the longer term, is there a reason the parent has to contain the
interpreter at all?  Can't it just do a system call when it needs one?
It seems a bit excessive to put aside a couple of megabytes of system
memory just to run startup.pl.  If one could get around any process
communication difficulties, the children could be just the same as
they are now, but exec()ed instead of fork()ed by a (smaller) child
process which has never leaked any memory.  The exec() latency isn't
an issue because of the way that Apache preforks a pool of processes
and the overhead will be minimal if the children live long enough.

Please tell me if I have got this all around my neck.

73,
Ged.

Re: How do I package my DBI subroutines?

[G.W. Haywood]

Hi there,

On Wed, 19 Jan 2000, Keith Kwiatek wrote:

> We have recently installed a new machine with Apache/1.3.9
> mod_perl/1.21 mod_ssl/2.4.10 OpenSSL/0.9.4 perl 5.004_04 configured

> A perl transaction handler that works fine on Apache/1.3.6
> mod_perl/1.21 5.00503 is now intermittantly dying on the new box
> with the following error;

> Can't call method "register_cleanup" on an undefined value at
> /usr/lib/perl5/5.00503/CGI.pm at line 263

Did you get a reply yet?

Your installation is apparently out of order.  You claim to have
configured perl 5.004_04 on the new box yet the error message says:

/usr/lib/perl5/5.00503/CGI.pm at line 263
   ^^^
which is the wrong version of Perl.  This doesn't seem like a good
idea to me.  I'd delete the lot and reinstall everything from scratch.

> I have some dbi subroutines that I want my mod_perl program to
> use. how do I go about packaging these (or whatever the correct
> terminology is)

I think you'll find everything you need for this in Stas' Guide.

73,
Ged.

Re: redhat apache and modperl oh my!

[G.W. Haywood]

Hi there,

> I compiled everything from source, no rpms.  It went together without a
> hitch.  Are people having problems with 6.1?

[EMAIL PROTECTED] was having problems earlier as well.

I didn't see anyone reply to him yet.

73,
Ged.

RE: Off Topic Questions

[G.W. Haywood]

Hi all,

On Mon, 17 Jan 2000, Stas Bekman wrote:

> Please try to keep it clean and not encourage off-topic questions. 

Sorry, Stas, you're quite right.  I often do reply privately to the
off-topic questions, and I suppose even that might be construed as
encouraging them.  I do however also try to point out gently that it
*is* off topic, and so shouldn't be here on the List, and also when
you should press `D'.  Er, now.

It's not always easy to know where to draw the line.  And unlike many,
I like the prickly feeling I get at the back of my neck when I think
that the likes of the Camel Book's authors are probably disecting my
replies and will blow me out of the water without mercy if I get it
wrong.  It's kind of like doing homework exercises, and it's amazing
what you learn when you try to explain something to someone else.  I
guess I'll lose some of these joys if I don't reply to the completely
off-topic questions that go to the List.  But that's OK.

For the record, I'm happy to answer Perl-specific questions if mailed
to me privately.  I can't guarantee to cope with the demand, even if
there's only one question in my mailbox.  And it has to be said that
if you have to ask me (and if I can answer it:) then it's probably a
dumb question.  But that's OK, too.

As for keeping it clean, well I suppose it was a racist joke...

73,
Ged.

Re: squid performance

[G.W. Haywood]

Hi there,

On Mon, 17 Jan 2000, Ask Bjoern Hansen wrote:

> At ValueClick we can't use the caching for obvious reasons so we're using
> a bunch of apache/mod_proxy processes in front of the apache/mod_perl
> processes to save memory.
> 
> Even with our average <1KB per request we can keep hundreds of mod_proxy
> childs busy with very few active mod_perl childs.

Would it be breaching any confidences to tell us how many
kilobyterequests per memorymegabyte or some other equally daft
dimensionless numbers?

73,
Ged.

Re: squid performance

[G.W. Haywood]

Hi there,

On Mon, 17 Jan 2000, Joshua Chamas wrote:

> On Solaris, default seems to be 256K ...

As I remember, that's what Linux defalts to.  Don't take may word for
it, I can't remember exactly where or when I read it - but I think it
was in this List some time during the last couple of months!

> I needed to buffer up to 3M files, which I did by dynamically 
> allocating space in ap_proxy_send_fb.

For such large transfers between proxy and server, is there any reason
why one shouldn't just dump it into a tempfile in a ramdisk for the
proxy to deal with at its leisure, and let the OS take care of all the
virtual and sharing stuff?  After all, that's what it's for...

73
Ged.

Re: Program very slow

[G.W. Haywood]

Hi there,

An Englishman asked an Irishman for directions to a place some
distance away.  The Irishman replied, "T'be sure, if oi was going
there, oi wouldn't start from here!".

This *is* a bit off-topic, but the guy needs help.
Press `D' if you're bored already.

On Sun, 16 Jan 2000, Kader Ben wrote:

> I want to check if @rec contains the string "Unknown" but when I do
> so the program is very very slow (this process 6M file into @rec
> array). Is there any other away to rewrite this code?

> for ($i = 0; $i < scalar(@rec); $i++) { $rec[$i] = '"'.$rec[$i].'"'; }
> if($rec[16] eq '"Unknown"') { Alert_Unknown_ChannelID($rec[0]); }
> else { my $out = join(',', @rec) . "\n"; print (G $out); }
> }

I'd really need more to go on than you've given, so I'll make some
wild assumptions, and here goes...

It's horribly inefficient to read a big file into an array with a
large number of elements only to process it with things like:

$rec[$i] = '"'.$rec[$i].'"';

Think about what you're asking.  Each element has to grow by a couple
of bytes...

Maybe you can manipulate smaller chunks of the file?  If you must add
the quotes, do it before the pieces go into the array.  If you don't
need to do any more processing on the array, just put the first 16
elements into it (I assume they're relatively small), something like
the code below.  Process the 16 element array as you do now, but deal
with the remaining input on the fly, without putting it in an array.
Try to use $_ wherever you can.

I take it you *are* using the `-w' switch and `use strict;'?

73,
Ged.

#!/usr/bin/perl -w
# Read a file, put quotes around all the lines.
# You can probably tell I'm really a `C' programmer.

use strict;

my @rec=();# Small array, big file
my $fileName = "/home/ged/website/input/create/data/input/catalogue.srt";

open(FD,$fileName);

# Read first bit of file
my $i=0;
while( $rec[$i++]= ) { last if $i==16; }

# My file has newlines so chop 'em off before wrapping with quotes.
# More efficient to print this inside the body of the while() above,
# maybe you don't need the array at all...
for( $i=0; $i<=$#rec; ) { chop($rec[$i]); print "\"$rec[$i++]\"\n"; }

# Announce
print "* Here we are at line 16. *\n";

# Add quotes on the fly.  O'course we don't have to do it at all...
if( 1 ) { while(  ) { chop; print "\"$_\"\n"; } }

close(FD);

# EOF: ged.pl

Re: Missed a taint check

[G.W. Haywood]

Hi there,

On Sun, 16 Jan 2000, Gunther Birznieks wrote:

> if you do "<$page" for the file to open for reading instead of $page
> by itself, adding a pipe to $page will also no longer work.

> The < overrides the intention of any pipes in the filename strings.

If it's the *first* character in the string.  Camel Book, p192.

73,
Ged.

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

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

[G.W. Haywood]

Hi all,

On Tue, Jan 11, 2000 at 01:20:21PM -0800, Jeffrey W. Baker wrote:

> Unfortunately, Oracle support is an ongoing criminal enterprise.
> Unless you have the most expensive of all of their support
> contracts, and a former Oracle VP on your staff, you will not get
> any support period.  If you mention Perl, you can forget about
> getting bugs fixed, even when the bugs are clearly in the RDBMS and
> not the client.  You have been warned.

Er, the opinions expressed herein are not necessarily...

73
Ged.

Re: perl -V ??

[G.W. Haywood]

Hi there,

On Tue, 11 Jan 2000, Dave Reinhardt wrote:

> perl -V got me the following, BUT how do I tell if Perl modules: Digest::MD5, 
>Crypt::DES, Crypt::CBC
> are installed?

Have a look at the http://perl.apache.org.guide.

Amongst other things, `perl.pod' (part of the Guide) mentions the use
of eval to test things without fatal errors.

73
Ged.

PS: What does SeaPortNet do?

Re: VirtualSellers.com TAME patent

[G.W. Haywood]

Hi there,

On Mon, 10 Jan 2000, Cliff Rayman wrote:

> 
> These patents scare me since the patent granters seem not to understand
> software very well - and it seems like it is diametrically opposed
> to what the open software movement stands for.
> 

Then come to the United Kingdom, where you can't patent software!

And no, that's right, you can't patent _anything_ if it's already been
published.  The most famous case is the ball-point pen.  Big mistake.

73
Ged.

RE: Cryptic errors -simple Apache::Registry script ??? (newbie)

[G.W. Haywood]

Hi there

On Mon, 10 Jan 2000, Eric Cholet wrote:

> > Apache 1.3.9 (with mod_perl 1.21/perl5.005_03) doesn't let me use a
> >  section in a  section.
> 
> Really? That's quite odd. What is the error message?

Looks like I was wrong about this.  Either my memory was playing
tricks on me, or it's different on my development server.  The former
is at least three orders of magnitude more likely than the latter.

I didn't want to try to restart my live server with a deliberately
broken config, so I duplicated it on my development server and got
this message output to stderr:

Syntax error on line 941 of /usr/local/apache/conf/httpd.conf:
 cannot occur within  section
../src/support/apachectl start: httpd could not be started

Here is the (only) difference between the failing config and the one
currently on the live server.  This is in a  section:

940,943c940,945
<   
< SetHandler  perl-script
< PerlHandler Apache::Footer
<   
---
>   
> 
>   SetHandler  perl-script
>   PerlHandler Apache::Footer
> 
>   

What seems to have confused me was that to repair the config I removed
the  directive.  Sorry if this confused anyone else.

73
Ged.

Re: Trouble installing mod_perl

[G.W. Haywood]

Hi there,

On Sun, 9 Jan 2000, gnielson wrote:

> I am encountering some errors when trying to get an existing Apache
> server to support mod_perl.
>
> I am running Server version Apache/1.2.4 and perl, version
> 5.004_01. Is the fact that I have not yet ungraded to 5.004_04
> giving me these problems?

Didn't I read somewhere that mod_perl (at least v1.2 and later) no
longer support Apache 1.2.x?

Perhaps you should think about upgrading.  Some of the add-on-goodies
on CPAN need at least Perl 5.005_03, but I think you would want to go
for a later version than that in any case.

73
Ged.

Re: Cryptic errors -simple Apache::Registry script ??? (newbie)

[G.W. Haywood]

Hi there,

On Sun, 9 Jan 2000, John Walker wrote:

> This is in a virtual host section, could that be a problem?

Apache 1.3.9 (with mod_perl 1.21/perl5.005_03) doesn't let me use a
 section in a  section.

73
Ged.

Re: strange error message when reloading a script many times

[G.W. Haywood]

Hi there,

On Sun, 9 Jan 2000, Alan wrote:

> Running a simple test script that does nothing more than print out stock html
> and "Test" works fine till I hit reload a few times quickly in succession. 

Can you mail me your configuration files?

73
Ged.

Re: Caching with $r->no_cache(1)

[G.W. Haywood]

Hi there,

On Fri, 7 Jan 2000, Randy Harmon wrote:

> Does anybody have experience detecting such a condition, perhaps through one
> of the client headers?  I haven't had a chance to dump them - many hats.

No idea - ditto.

> In any case, I could use some Javascript to package up the machine's
> current time and send it back to the server, for instance at the
> same point where I check whether a cookie was accepted.  That'd
> indicate their "Javscript-OK"-ness too.  I think I'm willing to
> assume that someone clueful enough to turn off Javascript is clueful
> enough to have the correct time.

You might want to look at the excellent ntpd documentation which talks
about things like network delays.  I think your Javascript idea is as
good a solution as you're going to get until the Web Comes Of Age.
Don't know what you're going to do when I visit with Lynx though...
Well, at least my clock _will_ be right, I run a level 3 timeserver.

Somebody's probably going to tell us we've strayed off topic now...

73
Ged.

Re: Weird message from make test

[G.W. Haywood]

Hi there,

On Sat, 8 Jan 2000, Nancy Lin wrote:

> If it's not the test script that's bad, then it would have to be
> CGI.pm, no?

No.

73
Ged.

Re: Caching with $r->no_cache(1)

[G.W. Haywood]

Hi there,

On Fri, 7 Jan 2000, Randy Harmon wrote:

> Currently, I'm experiencing the problem with Netscape 4.7, although I seem
> to recall the same problem in earlier releases, in the case where the target
> browser's clock is slow.
> 
> [snip] can be corrected by explicitly setting an Expires header that's in
> the past.  How far in the past depends on how lenient you wish to be with
> browsers with slow clocks.
> 
> Something between 5 and 30 minutes seems reasonable to me, but discussion
> may demonstrate a different approach and/or timeframe.
> 
> Thoughts?

Well, quite a lot of computers now fire up with the clock saying some
time around 4 Jan 1980.  Just how far do you let this go?  My view is
that if he suspects that it may cause a problem, one should tell his
user to make sure the clock is right.  Caveat browsor.  I feel sure
that deliberately lying about the time is a dangerous path to tread.
Of course we can't (yet) expect everyone to be running ntpd, and five
minutes doesn't initially seem unreasonable, but we could then expect
biennial fun and games when daylight savings time kicks in and out, or
not, as the case often may be.  The software industry has a bad enough
reputation as it is, without yet another kind of periodic Y2k bug.

Maybe a Request For Comment?

Or a word in someone's ear at the browser development labs?

73
Ged.

Re: Footer.pm - eagle book

[G.W. Haywood]

Hi there,

On 3 Jan 2000, Fernando Rowies wrote:

> >From example 4.1 of the eagle book.
> I don't understand in which directory I need to put the file Footer.pm and the
> html files that where affected by this module. I configured httpd.conf with:
> 
>   SetHandler  perl-script
>   PerlHandler Apache::Footer
> 

Your configuration file tells Apache to process files in the directory
`footer' and its subdirectories with the handler in Apache/Footer.pm.

The directory `footer' is in your document root directory, so if your
document root is

  /usr/local/apache/htdocs

then your `footer' directory is

  /usr/local/apache/htdocs/footer

Footer.pm can be in a directory which contains your other Apache::
files (the convention is that Apache::Footer means Apache/Footer.pm)
so if you have them in

  /usr/local/Apache/lib/perl/Apache

and so you will have put

  use lib Apache->server_root_relative('lib/perl');

in startup.pl as shown on page 28 of the Eagle book, then you can put
Footer.pm in that directory,

  /usr/local/Apache/lib/perl/Apache/Footer.pm

It can be anywhere else, all that matters is that it can be found when
it is needed by reference to the paths in @INC.  If the Footer module
cannot be found your error_log will have a listing of @INC.  Put
Footer.pm in a directory called `Apache' in one of those directories.
Make its permissions 644.

Don't forget that you have to restart Apache (`apachectl restart')
after you make changes to modules (and to your configuration) for them
to become effective.

In my copy of the Eagle book (first edition, March 1999) in example
4-1 there seems to be a superfluous '>' character after the first
double-quote character on line 4 of page 93.

73
Ged.

Re: Apache::Scoreboard - problem compiling

[G.W. Haywood]

Hi there,

On Sun, 19 Dec 1999, Dmitry Beransky wrote:

> I'll try compiling within Apache's source tree tomorrow.

When I did that it caused `make test' to fail.  I had Apache in
/usr/local/apache and mod_perl in /usr/local/apache/mod_perl.

Linux 2.0.34 on PentiumII PC, Perl 5.005_03, libc5, static.

After a month I gave up and did a completely clean reinstall of
everything, including the operating system, on a new machine.  I put
mod_perl at the same level as Apache, with soft links (which seems to
be the Slackware Linux culture).

/usr/local/apache   -> /usr/local/apache_1.3.9
/usr/local/mod_perl -> /usr/local/mod_perl-1.21

It worked first time.  Gr.

A couple of people later said they saw no reason for using soft links
in the way that I did, and [EMAIL PROTECTED] said he'd had problems
until he used hard links.  I'm still running with the above setup and
I've seen no problems.

Hope this helps.  If you succeed, please let me know.

73
Ged.

Re: Holding files open and locking

[G.W. Haywood]

Hi Bill,

On Sun, 19 Dec 1999, Bill Moseley wrote:

> Can anyone recommend a good method to archive a log file 

There's loads of stuff for managing logfiles knocking about.

I know you said you'd looked at the Guide, but what was the version
you last downloaded?  There's a bit in control.pod about Log Rotation.
Once you've rotated the live file out you can tell cron to gzip it (or
whatever) with complete confidence.

What you're doing sounds a bit scary to me, are you really desperate
to save CPU cycles?

73
Ged.

Re: PerlChildInitHandler called twice for a child?

[G.W. Haywood]

Hi there,

On Fri, 17 Dec 1999 08:43:43 -0700 Owen Stenseth mentioned:

> On my server startup (under httpd -X as well) I see two calls to
> it. I have wrapped my code so it does not do the initailization
> twice now but this kind of caught me by suprise.

Now it's funny you should say that.

What version of Perl are you using?

73
Ged.

RE: How Embperl sub routine retun value?

[G.W. Haywood]

Hi there,

On Mon, 13 Dec 1999, Albert Liu wrote:

> It works, but I never thought i can use this way to pass parameter. Indeed
> i never read this in "Programming Perl" book. Perhaps it is at some where
> it the book

Second edition, pages 111 to 121 inclusive.

73
Ged.

Re: Managing session state over multiple servers

[G.W. Haywood]

Hi there,

On Fri, 17 Dec 1999, Robert Locke wrote:

> If you use Apache::DBI, make sure that you call "connect" with the
> same arguments as above in your other scripts or you will find
> yourself with more than one connection/process to the database, which
> may not be your intention.

See the Guide, `Opening a connection with different parameters'.

73
Ged.

Re: Problems building

[G.W. Haywood]

Hi there,

Good to hear from you again.

On Wed, 15 Dec 1999, Eric Cholet wrote:

> I'm strongly opposed to this suggestion. I have always built
> mod_perl + apache in one single step (perl Makefile.PL EVERYTHING=1
> DO_HTTPD=1 && make install), I like the fact that I install just the
> binary httpd wherever I feel like, I don't want it to go away.

Perhaps I should have snipped the message to which I was replying a
little.  I have no problem with that, in fact I do the same thing now.

> If you're concerned about the two different ways to build, hop on
> over to Apache-land, they started it :-)

I'm only concerned that some people seem to be getting in a muddle!  I
might be talking through my hat but it seems that a lot of troubles at
build time are caused by dependencies on the directory structure that
haven't been ironed out yet.

73
Ged.

Re: Problems building

[G.W. Haywood]

Hi all,

On 14 Dec 1999, Greg Stark wrote:

> I think the interdependence with the apache tree and the mod_perl
> tree just makes things too complicated. I'm not unfamiliar with
> complicated building software -- even fairly complex software, but
> mod_perl just plain won that weekend, I conceded defeat.
> 
> It doesn't help that there are at least two completely different
> ways to build each. I would suggest narrowing it down to just one
> right way to build apache.  If the shared module can't be made rock
> solid then I suppose one way for shared module and one for compiling
> statically into apache. But I would suggest throwing out the
> PREP_HTTPD and DO_HTTPD stuff and the option to not use apaci.

Hear, hear.
Is there an echo in here?

73
Ged.

Re: Error in make test

[G.W. Haywood]

Greetings,

On Thu, 9 Dec 1999, Sakuji Toyama wrote:

> I have compiled mod_perl-1.21 with apache_1.3.9 under Solaris2.5 machine.
> ...
> "--prefix=/usr/local/etc/httpd" 

I think this is your problem.  Something similar happened to me.

Try putting everything in   /usr/local/apache_1.3.9
with a soft link/usr/local/apache -> /usr/local/apache_1.3.9
and use --prefix=/usr/local/apache
put mod_perl in /usr/local/mod_perl-1.21
with a soft link/usr/local/mod_perl -> /usr/local/mod_perl-1.21

Delete the original apache installation and start again with a fresh
set of files from the distribution.

Please tell me if this works for you.

Kind regards,
Ged Haywood.

Re: where is HTTP_MULTIPLE_CHOICES?

[G.W. Haywood]

On Wed, 8 Dec 1999, Dmitry Beransky wrote:

> I'm sorry, this is probably a stupid question, but I've search everything I 
> could think of and still can figure out where HTTP_MULTIPLE_CHOICES 
> constant is defined.  It's definitely not in Apache::Constants::Exports Any 
> thoughts, did I miss something?

Try Midnight Commander (`mc').  It's very easy to use.  It found this
from the top of the Apache tree in about 20 seconds on my desktop PC.

/usr/local/apache/src/include/httpd.h line 471:
#define HTTP_MULTIPLE_CHOICES  300

/usr/local/apache/src/include/httpd.h line 511:
#define MULTIPLE_CHOICESHTTP_MULTIPLE_CHOICES

73
Ged.

Re: simple xml parsing within html

[G.W. Haywood]

Hi all,

On Wed, 8 Dec 1999, Alex Menendez wrote in the mod_perl list:

> I currently have developed a dynamic content engine in mod_perl
> I initially tried to do this by subclassing HTML::Parser and over-riding
> the usual methods. However, this was painfully slow
> 
> any suggestions on making HTML::Parser work faster

Performance is a real issue in mod_perl systems, so I've put some work
into this.  Maybe it will spawn a thread.

Here are a couple of suggestions for speeding up HTML::Parser.

Apparently the author is looking at this at present too.  He will know
a lot more about what the code is doing that I do.

My background is in engineering, mostly real-time instrumentation and
control.  I have never used these methods in text processing but the
principles are the same.  I guess you have some leeway here to decide
if it's worth all the effort - it can be a lot of effort.  Controlling
machines, there often isn't a choice in the matter.  These techniques
need careful thought in their application and they also need to be
followed up by testing in `real' conditions.  Without testing, you may
find that they do serious damage rather than improve performance.

Please also note that you asked for _suggestions_ and that's what 
these are.  I haven't

(a) considered all the options and consequences,
(b) tried it in practice in this case and
(c) perhaps most importantly, heard what the mod_perl group in general
and what Christiansen, Schwartz, Wall et al. in particular will
say if they see this.  I am especially aware of my own limitations
as an inexperienced Perl user.  Holds breath in anticipation.

I have attached a copy of HTML::Parser with which I have taken great
liberties.  For that I apologize unreservedly to the author.  I do not
mean to imply that there is any bad practice in its construction.  In
fact I haven't any idea what most of it does.  However, I can see some
similarities in the constructs which may possibly allow the code to be
made a little quicker.  This will be at the expense of some elegance,
a few extra bytes of compiled code and possibly some complication in
maintenance.

Tradeoffs abound.

Hopefully the formatting of the attachment will make clear what it is
I'm trying to do.  Of course Perl itself might do a better job of some
or all of this.  That's one reason for testing.  It depends how well
any optimizers do their bit, and crucially what assumptions they make.
For example, few optimizers make the kind of guesses that I am about
to make in [B] below.  Or if they do, I won't be happy using them.

To apply the methods below I rely to some extent on the fact that Perl
(or C, or Pascal, whatever) is to a first approximation a free format
language.  Even if it were not, you could do most of what follows and
simply trust your expertise in the language to avoid altering the
effective logic.

[A] [A1] Remove as many comments as feels comfortable.  In this case
 I was comfortable without any comments.  Single line Perl `#' 
 comments _must_ be removed from within blocks at [A3] below!
[A2] Reformat the code by hand so that firstly if..elsif...else
 clauses are stacked as per the attachment and secondly loops
 and especially nested loops are clearly visible.
[A3] As far as possible format entire blocks into one-liners, but
 be aware that blocks within blocks may need special attention.
 The one liners may be very long lines but that's unimportant.
[A4] Make sure that the code in this format is identical with the 
 old, if that's what you want.  Compiling to objects is good,
 Perl to C might help here for example.

Depending on the complexity of the code, some of the above may not
be necessary.  Simple inspection may do it for you.  I like to make
the whole thing as dense as possible, and sometimes I print it out
to get a clearer overall picture.

[B] Make some plausible assumptions about the input.  For example in
this case I am assuming that the input is to some degree under the
control of the person running the code, and that it is more likely
that a snippet of HTML which looks something like this:

<...variable="value"...>

will usually be written exactly like that, or in this way:

<...variable = "value"...>

than with some arbitrary amount of embedded arbitrary white space.

[C] Add a few statements which will not change the results (!) but
which will result in fewer (and possibly quicker) tests being
made.  Where there are several different and complex tests which
share some common and readily disprovable feature, a simple test
for that feature first may entirely avoid the need for the others.
In this case we can short-circuit some tests containing relatively
complex REGULAR EXPRESSIONS in which the first character is the
equals sign by making a couple of tests for simple two-character
STRINGS which we think are the most 

Re: System calls to return data via STDOUT

[G.W. Haywood]

Hi again,

On Wed, 8 Dec 1999, hamid khoshnevis wrote:

> Thanks, Ged.
>
> No you are right on.  I do glimpseindex off-line and want to search using 
> glimpse.  So I call glimpse and get the result set which I am able to pull 
> into regular perl with no problem but as soon as I take the working solution 
> to modperl, no result set comes back to the browser.  I am now trying the 
> solutions others have recommended, but so far no luck.

Hmmm.  Typical cgi -> modperl scenario?

I'm a bit clearer, now, how far you've got.  When you say that you are
able to pull the result set into perl, do you mean into an Apache cgi
script written in perl or into a perl script running at a terminal?

If you haven't yet made it work with plain Apache/cgi then I think it
would be a good idea to do that before mod_perl clouds the issue.

>From your previous posts it seemed like you were designing the system
but now it seems more like you're into debugging.  If you get to the
bottom of it from the others' suggestions, let me know.  If not, come
back to me and we'll do some more investigation.

73
Ged.

Re: Apache::ASP Debugging

[G.W. Haywood]

Hi all,

On Tue, 7 Dec 1999, Joshua Chamas wrote:

> I'm thinking its best if internal debugging not be turned on by
> default, that only user level debugging be what Debug levels 1 & 2
> refer to.  Unless there are any protests, Debug will have to be set
> to a negative like -1 or -2 to enable internal Apache::ASP
> debugging.  The latter can be useful to the developer who is working
> on application performance and is tweaking config settings, seeing
> how it affects Apache::ASP.

I'm strongly in favour of flexibility in debug output.  But you don't
have to go completely mad like sendmail...

73
Ged.

Re: @INC and make test

[G.W. Haywood]

Hi all,

On Wed, 8 Dec 1999, Ruben I Safir wrote:

> Syntax error on line 198 of /usr/local/apache/conf/httpd.conf:
> Can't locate loadable object for module Apache::Util in @INC (@INC

> ls -al /usr/lib/perl5/site_perl/5.005/i386-linux/Apache
> -rwxrwxrwx   1 root root 2444 Feb  1  1999 Util.pm

Is this a soft link?  Big byte count!
Is that OK?  Didn't work for me:(

If it isn't, a link, why can _everybody_ write it?

73
Ged.

Associative arrays don't work (!)

[G.W. Haywood]

Hi all,

On Tue, 7 Dec 1999, Joshua Chamas wrote:
> Cedric Avena wrote:
> > Do associative arrays work with modperl ?

That's a bit like saying do floats work in Fortran, isn't it?

> If you want to catch subtle errors in your programming, try putting
> "use strict" at the top of your code

And use the -w flag!

See the Camel book, chapters 1, 2, 3, 4, 5, 6, 7, 8 and 9.
Why they didn't put it in the Preface, I'll never understand.

73
Ged.

System calls to return data via STDOUT

[G.W. Haywood]

Hi all,

On Sun, 5 Dec 1999, hamid khoshnevis <[EMAIL PROTECTED]> wrote:

> I am a newbie modperl'er 

Welcome to the club.

> I am tyring to get system calls to return data to modperl (via stdout).

The idea of mod_perl is to get things to go faster by avoiding as much
as possible the (time consuming) launching of new processes and things
like that.  Are your system calls launching new processes?  If so, you
may not be getting the benefits of mod_perl but you'll be getting the
disadvantages (huge memory consumption to name but a few).

What is making the system calls and why?
Is There More Than One Way To Do It?

73
Ged.

Re: Name / brand - decision?

[G.W. Haywood]

Hi all,

On Mon, 6 Dec 1999, Victor Zamouline wrote:

> I will willingly continue summarizing this thread as soon as I
> understand whether we have decided to continue these discussions 

A running summary of any thread, such as the one provided by Victor is
tremendously helpful.  There is also great value in the non-technical
threads and they are clearly very popular.  For those reasons I would
not wish to see them die.

Because some of the people here have tremendous time pressures, I tend
to agree with those who would keep this list to the technical topics.

There was a suggestion that they would be better placed on a separate
list and that gets my vote, but if we were to agree on a standard for
the `subject' line to allow easy sifting of mail for those that need
it, then that would be as easy to deal with.  We're almost there now.

After some milliseconds of thought I decided that `NT' is the obvious
way to flag a message on non-technical matters.  There may be dissent.

Stas has also tried to get us to be brief.  Sorry, Stas, I'll try.

- Thoroughly non-technical bit follows, press D if you wish. -

On the subject of copyright, I'd say that when a suitable image and/or
association is decided, if Stas and Eric are planning to use it then
they or the designer should immediately either put it in the public
domain or establish copyright by publishing it.  Probably the GNU
`copyleft' will do it, but I'm no IP lawyer.

73
Ged.

  

Re: Mailing list size

[G.W. Haywood]

On Sun, 5 Dec 1999, Anthony Gardner wrote:

> Have to be honest and say that compared to other mailing lists I'm on, this 
> one is the most professional and personal I've seen.

Thank you.  From all of us, I'm sure.

On a technical (if not topical) point it would ease network traffic
and the pressure on my left middle finger (the one that types `d')
if we could all try to avoid double-shotting the people we know are
on the list.  There's no point me sending mail to Stas and copying 
it to the mod-perl list as well, I know he'll get a copy if I just 
send it to the list.

Point two, some of the emails seem to have heaps of HTML and other
baggage hanging onto them.  These usually double the size of the
message and often they dwarf it.  Please check that your MUA isn't
sending things unnecessarily.  I hope mine isn't...

73
Ged Haywood.

Re: mod_perl Programmers demand is going up...

[G.W. Haywood]

Hi all,

On Sat, 4 Dec 1999, Gunther Birznieks wrote:

> Just putting in use strict and -w doesn't cut it. There's a load of
> gotchas that people just have to understand and learn on top of Perl
> skills.

Too true.  This is a topic in its own right.  I believe that mod_perl
could be made into an almost indispensable part of any Apache setup if
only it were not so easy to fall into the traps it sets for you.  As it 
is I think many people will simply walk away from it because it's about 
as programmer-friendly as a cornered rat.

Come to think of it, Stas, how about a rat?

73:)
Ged.

Re: mod_perl Programmers demand is going up...

[G.W. Haywood]

Hi again, all,

On Sun, 5 Dec 1999, Victor Zamouline wrote:

> So, a company hiring VB developers knows that these are humble and
> obedient guys who will make the application work, even if an extra
> semicolon will ruin the whole program. And that is perfectly OK with
> such companies because they sell the product and the MAINTENANCE behind
> it (they call it "maintenance", but it actually means re-writing the
> whole program when the client only needs an extra semicolon).

C'est la vie.  Caveat emptor.  Bummer.

> But a good Perl programmer is more often uncontrollable, he writes a
> perfect program, but no one else understands it,

H.

> So when I spread the mod_perl word, I make sure I don't make my client
> hire another bunch of VB programmers after what I told them about
> mod_perl during the training. :)))

Hang on, fellas, isn't this getting a bit unnecessarily evangelist?
Tools like mod_perl are just that.  Tools.  I'd no more want to 
`spread the word' aobut mod_perl than I would about my welding set.

But if I saw somebody struggling to join two bits of HR40 together,
drilling holes in it and messing about with nuts and bolts,  I'd say
`Hey, have you seen how easy it is to do it this way, and what a
good job it does?'.  Then I'd go on to explain that he needs to get
acquainted with a whole raft of things like hydrogen embrittlement, 
position, stress relief, non-destructive testing, and any number of 
health hazards.  When he's done that he will be able to choose the 
best tool to do the job he has in front of him.  It might be a drill.

It will have been for his benefit, so he can get the job done better,
not to make me feel good about another convert.

73
Ged.

RE: migrating perl.apache.org to *.modperl.org

[G.W. Haywood]

Hi all,

On Sat, 4 Dec 1999, Gerald Richter wrote:

> I don't see any benefit on having so a set of hostnames/subdomains over
> using subdirectories, execpt that subdomains harder to administer (they have
> to go into the dns)

There may possibly be a benefit if traffic were high.
The different domain names could more easily be pointed 
to different IP addresses to relieve network congestion 
or a single overloaded machine/interface/sysadmin.

It's no big deal to administer a small zone like this.

73
Ged.

Re: mod_perl Programmers demand is going up...

[G.W. Haywood]

Hi all,

On Sat, 4 Dec 1999, Robin Berjon wrote:

> I can do graphics but I'm no good at drawing. If anyone has the opposite
> skills configuration, I'm willing to take care of the (web-)graphic part.

I have neither skill in any great measure.  But I _can_ probably find some 
images of hedgehogs & eagles.  I was thinking of an Osprey (a fish-eating 
eagle found here in the UK), partly because of the copyright business but 
mostly because it's a bit closer to Doug's ancestral roots.

73
Ged.

RE: PerlFreshRestart and %INC

[G.W. Haywood]

Hi there,

On Fri, 3 Dec 1999, Young, Geoffrey S. wrote:

> here's the code from the guide:
> 
> while (my($k,$v) = each %INC) {
>   delete $INC{$k};
>   require $k;
> }

I don't know what you'd do about that then.

Whatever you do, you're bound to break _something_.

73
Ged.

Re: PerlFreshRestart and %INC

[G.W. Haywood]

On 3 Dec 1999, Randal L. Schwartz wrote:

> I've always thought the "must load Apache::DBI before DBI" thing was a
> bit weird anyway.

With you all the way on that one.

> Can't you just make it a flag that DBI looks at that Apache::DBI sets?

Yeulk.

I'd like to see a lot more attention paid to some of these pitfalls,
with the pious intent to fill a few in so that people don't keep on
disappearing down them.

Don't know who's going to pay all this attention, though.

73
Ged.

Re: mod_perl Programmers demand is going up...

[G.W. Haywood]

On Fri, 3 Dec 1999, Stas Bekman wrote:

> I was thinking about hedgehog as one that protected from everything,
> exactly like mod_perl... 

Now why didn't _I_ think of that?

73
Ged.

Re: migrating perl.apache.org to *.modperl.org

[G.W. Haywood]

On Fri, 3 Dec 1999, Stas Bekman wrote:

> suggested the following layout (I've added a bit):
> 
>  www.modperl.org
> jobs.modperl.org
> dist.modperl.org
> docs.modperl.org
> search.modperl.org
> books.modperl.org
> conference.modperl.org (I'll talk about this one next time)
> 
> vs. a basic domain www.modperl.org and all the above subdomains as
> subdirectories (which is how it'll be physically located anyway)

Does it matter?
But the parent domain should be modperl.org not www.modperl.org, surely?

73
Ged.

Re: mod_perl Programmers demand is going up...

[G.W. Haywood]

On Fri, 3 Dec 1999, Robin Berjon wrote:

> >That takes a strong logo and... possibly a more artistic name for mod_perl?
> The Eagle book doesn't have it on it's cover though,

Well, actually, it does... on the first line, but who cares?

> so it might be possible if anyone's got some good suggestion

How about ``Eagle''?

73
Ged.

RE: PerlFreshRestart and %INC

[G.W. Haywood]

Hi there,

On Fri, 3 Dec 1999, Young, Geoffrey S. wrote:

> maybe it has to do with the order in which stuff is held in %INC - that is,
> Apache::DBI needs to be loaded before DBI, but PerlFreshRestart may require
> them in the improper order because of the hash order?

Is there a `hash order'?
Hashes can do strange things with the order of their contents.

Does the code do a foreach (sort keys %INC) or just foreach (%INC) ?

73
Ged.

Re: LWP vs Netscape

[G.W. Haywood]

On Fri, 3 Dec 1999, Robert Locke wrote:

> To make a long story short, my advice would be to use POST and not
> GET.  I think that might work.

Then you get something in access_log too.

73
Ged.

Re: Can't load /..../Fcntl.so

[G.W. Haywood]

Hi there,

On Thu, 2 Dec 1999, Bruce A. Johnson wrote:

> I just rebuilt my Apache server (1.3.6) last week.  I enabled the
> cern_meta module, the usertrack module, and the expires module,
> and I upgraded mod_perl from 1.19 to 1.21.  I did a clean build
> from the distribution tar-balls.

Did you have to do all that all at once?

How long did you leave it between the five ways of breaking your
server above and the one way of finding out below?

> so I put it into production.

AFAICT it was less than a week.  That was asking for it.  I'm a great
fan of incremental development.  This was definitely not incremental
development.  Take it easier, if you can.

Kind regards,
Ged Haywood.

Re: Happy Birthday mod_perl Guide

[G.W. Haywood]

Hi there,

On Fri, 3 Dec 1999, Robin Berjon wrote:

> the Guide was first announced on 03/12/1998 so it makes a year now ! 
> Wonder how big it'll be in a year...

Stas says we can stop calling it the `mini' guide now...

Kind regards,
Ged.

Re: Happy Birthday mod_perl Guide

[G.W. Haywood]

On Fri, 3 Dec 1999, Stas Bekman wrote:

> I wish people use more one liner answers

OK.

73
Ged

Re: mod_perl Programmers demand is going up...

[G.W. Haywood]

Hi there,

On Fri, 3 Dec 1999, Stas Bekman wrote:

> You wouldn't beleive but I receive a great deal of mod_perl job offers.

I believe it.

> Which makes me thinking that we are too few and the demand is growing
> (which is good for us :), but from the other side it's bad for mod_perl,

Speaking as a supplier, when demand is high and supply is scarce...

I LIKE it!!!

73
Ged.

Re: Modperl script doesn't increment access log

[G.W. Haywood]

Hi there,

On Tue, 30 Nov 1999, Jim Goodwin wrote:

> Because of the nature of mod perl, we only get one 'hit' in the
> Stronghold access logs when the .pl scripts are run. 

Yup, that's right, unless the script doesn't exist, in which case my
acces_log looks like this for example:

[30/Nov/1999:15:31:53 +] "GET /cgi-bin/JOSvisitlog.pl HTTP/1.0" 404 225

or unless the request is POST in which case I get for example

[30/Nov/1999:18:59:23 +] "POST /cgi-bin/JOSplaceorder.pl HTTP/1.0" 200 2629

It says in the Eagle book (page 360) that there are a number of log 
handlers on CPAN including Apache::DBILogger and Apache::Traffic.

It says also (page 364) that you should look at Apache::DBILog and
Apache::DBILogConfig ``before rolling your own''.

Any use?

Kind regards,
Ged Haywood.

PS: I sell the Eagle Book.  And all the others.

Re: Limitations of DBI::ProxyServer (was: pool of DB connections?)

[G.W. Haywood]

Hi there,

On Mon, 29 Nov 1999, Tim Bunce wrote:

> I'd like to see a mode added to DBI::ProxyServer whereby a single
> server process serviced multiple clients in a round-robin manner.
> Obviously in this mode there's a risk of slow queries cloging up
> (blocking) the proxy, but for many applications it would still be
> very useful. Most significantly it would enable connect_cached to
> be used to implement a (kind-of) connection pool.
> 
> I'm sure there must be someone out there willing to have a go at
> implementing it. It can't be that hard.

If it's not that hard, I volunteer to _have a look_ at it.  It looks
like the sort of thing I'm going to need to do if my plans don't kill
me in the execution.  But time is short, I'm new to mod_perl, I never 
did get very on with object orientation and I've never written an SQL
query.  Having said that, I'm completely comfortable with assembler, 
C and C++, perl, Btree/ISAM, screwing around in Unix and so on, so I 
can give it a go.

All I need is a reading list.

And - because I'm an Englishman - some time.

Kind regards,
Ged Haywood.

RE: Please Help

[G.W. Haywood]

Hi there, Thang,

On Mon, 29 Nov 1999, Thang Nguyen wrote:

> Yes I've followed your step, but I still got the same problem as before
> my dir structure is
> /usr/local/apache   linked to /usr/local/apache_1.3.9 and
> /usr/local/mod_perl linked to /usr/local/apache_1.3.9

Is this really what you have for the mod_perl directory?

I don't think that will work.  You need to have another
directory called /usr/local/mod_perl-1.21 
and a soft link  /usr/local/mod_perl

The mod_perl stuff goes in /usr/local/mod_perl-1.21 
not in /usr/local/apache_1.3.9

If you have put everything into /usr/local/apache then I think
you should start again, by deleting the entire directory tree.

That's probably a good idea at this stage in any case.  Is it
easy for you to get new copies of the distribution files?  If 
so do that, to make sure you are starting with the right stuff.

Here are the distribution files I used:
=

-rw-r--r--   1 ged  users 1514725 Oct 23 13:43 apache_1.3.9.tar.gz
-rw-r--r--   1 ged  users  327633 Oct 17 17:40 mod_perl-1.21.tar.gz

-rw-r--r--   1 ged  users  161352 Oct 17 17:57 CGI.pm-2.56.tar.gz
-rw-r--r--   1 ged  users   11099 Oct 17 19:29 Crypt-SSLeay-0.14.tar.gz
-rw-r--r--   1 ged  users   90875 Oct 17 19:31 Digest-MD5-2.09.tar.gz
-rw-r--r--   1 ged  users   13456 Oct 17 18:29 HTML-Pager-0.01.tar.gz
-rw-r--r--   1 ged  users   24205 Oct 17 17:58 HTML-Parser-2.23.tar.gz
-rw-r--r--   1 ged  users   31799 Oct 23 15:39 HTML-Template-0.96.tar.gz
-rw-r--r--   1 ged  users   18495 Oct 23 15:40 HTML-Validator-0.12.tar.gz
-rw-r--r--   1 ged  users   29286 Oct 17 19:34 IO-Socket-SSL-0.73.tar.gz
-rw-r--r--   1 ged  users   10682 Oct 17 18:26 MIME-Base64-2.11.tar.gz
-rw-r--r--   1 ged  users   38637 Oct 23 15:04 Net_SSLeay.pm-1.05.tar.gz
-rw-r--r--   1 ged  users   77886 Oct 17 18:24 URI-1.04.tar.gz
-rw-r--r--   1 ged  users   61041 Oct 17 20:03 libnet-1.0607.tar.gz
-rw-r--r--   1 ged  users  143058 Oct 17 18:10 libwww-perl-5.45.tar.gz
-rw-r--r--   1 ged  users 1569702 Oct 23 15:12 openssl-0.9.4.tar.gz
-rw-r--r--   1 ged  users 286 Oct 23 15:12 openssl-0.9.4.tar.gz.asc
-rw-r--r--   1 ged  users  60 Oct 23 15:13 openssl-0.9.4.tar.gz.md5
-rw-r--r--   1 ged  users 1211410 Oct 23 19:16 sgml-lib.tar.gz
-rw-r--r--   1 ged  users   62847 Oct 23 19:19 xhtml1.tgz
=

Here is the directory structure I used:

The permissions on many of the directories in this list are 
NOT SUITABLE for a server attached to the network.

=
/usr/local/

drwxr-xr-x   2 root root 1024 Nov 24  1993 etc/
drwxr-xr-x   2 root bin  1024 Nov 24  1993 sbin/
drwxr-xr-x  22 root root 1024 Jun  2  1994 man/
drwxr-xr-x   3 root root 1024 Apr  8  1999 doc/
drwxr-xr-x   2 root root 1024 Aug 18 16:57 src/
drwxr-xr-x   8 root root 1024 Oct 13 20:27 lib/
drwxr-xr-x   2 root root 1024 Oct 13 20:27 include/
drwxr-xr-x   2 root bin  2048 Oct 22 22:23 bin/
drwxr-xr-x   2 root root 1024 Oct 22 22:23 info/
drwxr-xr-x   4 root root 1024 Oct 22 22:23 share/
drwxr-xr-x  10 161  20   1024 Nov 25 22:03 apache_1.3.9/
drwxr-xr-x  25 ged  users1024 Nov 26 15:00 mod_perl-1.21/
drwxr-xr-x   8 root root 1024 Nov 25 19:04 ssl/
-rw-r--r--   1 ged  users 1514725 Oct 23 13:43 apache_1.3.9.tar.gz
lrwxrwxrwx   1 root root   12 Nov 25 18:16 apache -> apache_1.3.9/
lrwxrwxrwx   1 root root   13 Nov 25 18:18 mod_perl -> mod_perl-1.21/

/usr/local/apache_1.3.9
-rw-r--r--   1 root root26414 Aug 13 07:58 Makefile.tmpl
drwxr-xr-x  20 root root 1024 Nov 25 18:51 apache_perl_modules/
drwxr-xr-x   3 ged  nogroup  1024 Nov 29 18:50 cgi-bin/
drwxr-xr-x   2 root nogroup  1024 Nov 27 17:34 conf/
-rw-r--r--   1 root root 4701 Jul 29 19:12 config.layout
-rwx--   1 root root52983 Aug 14 09:29 configure*
drwxr-xr-x   3 root root 1024 Nov 25 21:42 docs/
drwxr-xr-x   3 ged  users1024 Nov 25 21:46 htdocs/
drwxr-xr-x   3 ged  users2048 Aug 16 19:28 icons/
drwxr-xr-x   2 root nogroup  1024 Nov 29 12:48 logs/
drwxr-xr-x  11 ged  users1024 Nov 25 20:48 src/

/usr/local/mod_perl_1.21
drwxr-xr-x   2 ged  users1024 Nov 25 20:47 Apache/
-rw-r--r--   1 ged  users   10894 Dec 22  1998 CREDITS
-rw-r--r--   1 ged  users  111251 Jul  3 00:33 Changes
drwxr-xr-x   2 ged  users1024 Nov 25 20:47 Connection/
drwxr-xr-x   2 ged  users1024 Nov 25 20:47 Constants/
drwxr-xr-x   2 ged  users1024

Re: Embperl and header output

[G.W. Haywood]

Hi there,

On Mon, 29 Nov 1999, Erich L. Markert wrote:

> skeleton copy of the code below.
> 
> [-
> use Apache;
> use Apache::Constants qw(REDIRECT);
> 
> error checking and form validation going on here...
> 
> $new_applicant and $errors are set appropriately here...
> -]
> 
> 
> Untitled Document
> 
> 
> [$ if( ( $new_applicant ) || ( $errors ) ) $]
> [+ $application->display_errors_as_html() if( ($errors) || ($application->errors()) 
>); +]
> [+ $student->display_errors_as_html() if( $student->errors()); +]
> 
> http://$ENV{SERVER_NAME}/Nactel/new-application.epl! +]" 
>ENCTYPE="application/x-www-form-urlencoded">
> 
> 
> [$ else $]
> [-
> use Apache;
> use Apache::Constants qw(REDIRECT);
> 
> $req_rec->header_out("Location" => 
>qq!http://$ENV{SERVER_NAME}/Nactel/common/contact-info.epl?application_id=$fdat{'application_id'}&form_name=$fdat{'form_name'}!);
> $req_rec->status(REDIRECT);
> -]
> [$ endif $]
> 
> 
> 
> 

The nesting in this example looks a bit strange to me.
Have you taken this from your working (failing) code?

Kind regards,
Ged.

Re: Eagle Book, Camel Book :)

[G.W. Haywood]

Hi all,

On Tue, 30 Nov 1999, Ofer Inbar wrote:

>  "This may seem a bit weird, but that's okay, because it is weird."
> -- Larry Wall in perlref(1) man page, Perl 5.001

also Camel Book, 2nd edition, p. 37.

Kind regards,
Ged Haywood.

Re: How to (not) get help (was: make test fails (modules/src.t) with Error 29)

[G.W. Haywood]

Hi there,

The subject line you gave this was a very good idea, so I've tried
to throw in some of my experiences in the hope that this will be a
useful document for those who stumble along after me.  Take heart,
weary traveller!  There is light at the end of the tunnel (if you
look in the right direction:).

On Fri, 26 Nov 1999, Ask Bjoern Hansen wrote:

> "Why questions go unanswered".
>   http://www.plover.com/~mjd/perl/Questions.html

Thanks for the pointer, I'll grab it and do what you said.

> It was an awful long mail to go through.

Sorry.  Do you think that was why I didn't get any replies?  I 
thought I'd done what it said I should do in the documentation. :(

> You also forgot to send us the Makefile.PL parameters you used.

Apparently I left a bit out, so it should have been even longer. :(

> You could also have done a better job at marking out what of the 33kb you
> sent was important or relevant.

Nobody said that to me before.  I had no idea what was important or 
relevant, or I would have done just that!  As I said in the mail, it 
was my first attempt at mod_perl, and I tried my best to do what it
said in the SUPPORT document.  When you're new to it all, and you've 
just unpacked 8,705 source files into a directory tree, knowing what 
is important and what is not does not happen quickly.  The prospects 
of finding a single error in a reasonable time, alone, look bleak.

If you ask people who know me personally they will tell you that I am 
a very self-sufficient type.  I like to do things for people but to ask 
for help goes against the grain with me.  I probably need more practice.

> Apache::src seems to not work when you have your mod_perl tree in a
> subdirectory to your apache tree. How you got it to compile is mysterious
> to me though, you must have been doing something funky. When I try that
> it both screams and yells at me that it can't find the apache src.

I didn't think I knew enough about this stuff to do anything ``funky''!

I thought maybe it shouldn't have compiled, as well.  The day before 
yesterday I finally threw out everything (including the machine) and 
started again with a different box.  To my further and great irritation 
it worked first time.  As it happens, this time I put the mod_perl and
Apache directories at the same level in the tree.  After it had worked, 
I thought this might have been the problem but I have no evidence.  It
does suggest a structure like that in the Eagle Book but it says ``you 
might want to follow the suggestions given here for convenience'' so I
didn't follow them the first time because I was comfortable with using
directory structures and it wasn't convenient to do it that way.

I think that maybe some people have inadvertently produced build scripts
or code which depend upon the directory layout (or environment) to work, 
yet they neither check nor enforce it.  I seem to have tripped over that.

I think that I'm sticking my neck out a little by saying this, but my 
ego isn't as delicate as some, so go ahead and shout at me.  As I said, 
I have no evidence so it's only a guess.  As long as everything gets 
better in the end it doesn't matter if I'm criticized.   [Para. A]

There are several other things that seemed to me to be not quite right. 
I made notes in my `lab book' as I went along, and I'll be glad to list 
my thoughts about them if anybody is interested.  See Para. A above.

> PS. Flaming people who try to help you have never done any good.

It had reached the stage where I was spending time I could not afford,
getting nowhere, slowly, so I asked for help.  I was disappointed by
the zero response I got but even more disappointed with the non-zero 
response that some others were getting.

I skipper a yacht.  Out at sea, we say ``ask silly questions''.  If 
you're 100 miles from land, and somebody was afraid to ask a question 
because it might be a silly one, everbody might die.  For that reason
we are patient with questions that to the more experienced of us seem
to have obvious answers.

I see people asking easy questions, still do, which even I can answer.
I answer them, but usually they are not really mod_perl topics so I 
send private mail.  The thing that shocked me was that often in the 
thank-you replies I get, people mention that they have had sarcastic
comments from others on the list telling them not to ask non-mod-perl
questions, and things like that.  I was angry with those people who
are so clever that they can afford to make disparaging remarks about
others when it would be a lot easier just to answer the question in
a private message.  For example, one person wanted to know how to
unsubscribe, so I told him.  He said that lots of people had told him
to RTFM and junk like that.  He knew what to do, he'd just lost the 
exact wording for unsubscribing.  Another asked something about Perl 
(for his friend, not for himself) and he said that he was very sorry 
he'd ever posted his question because he'd had almost no