date:20000519


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.
> 
> Running the simple script below, I get a footprint of 63 MB
> about 22 bytes per int.
> 
> The C program only 11748 K ... 4 bytes per int
> 
> 
> #!/usr/local/bin/perl
> for ( $i=0 ; $i< 300 ; $i++ )
> {
> $X[$i]=int(1);
> }
> 
> 
> main()
> {
> int x[300];
> sleep(60);
> }
> 
> I guess I'm paying the price for PERL not being strongly typed,
> a feature I really like ( until now ;-) )
> 
> I require a large array of ints in a real application, just stripped
> problem down to bear bones for demo.
> 
> I'd be grateful for any advice

When you really need the C/C++ slimness use XS to glue C/C++ code for your
Perl code, don't just switch to C, which can be not development speed
wise.

A great XS tutorial (especially for simple things like your example):

http://perlmonth.com/columns/modules/modules.html?issue=6
http://perlmonth.com/columns/modules/modules.html?issue=7
http://perlmonth.com/columns/modules/modules.html?issue=8
http://perlmonth.com/columns/modules/modules.html?issue=9
http://perlmonth.com/columns/modules/modules.html?issue=10

Enjoy! And encourage Steven McDougall (the author) to write more of this
great stuff :)

_
Stas Bekman  JAm_pH --   Just Another mod_perl Hacker
http://stason.org/   mod_perl Guide  http://perl.apache.org/guide 
mailto:[EMAIL PROTECTED]   http://perl.org http://stason.org/TULARC
http://singlesheaven.com http://perlmonth.com http://sourcegarden.org

LARGE PERL footprint

2000-05-19 Thread David Larkin


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

Running the simple script below, I get a footprint of 63 MB
about 22 bytes per int.

The C program only 11748 K ... 4 bytes per int


#!/usr/local/bin/perl
for ( $i=0 ; $i< 300 ; $i++ )
{
$X[$i]=int(1);
}


main()
{
int x[300];
sleep(60);
}

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

I require a large array of ints in a real application, just stripped
problem down to bear bones for demo.

I'd be grateful for any advice

Thanks in Advance
Dave

Re: question - can asp be run as cgi???

2000-05-19 Thread Joshua Chamas


Charles Dalsass wrote:
> 
> Hey dudes, new poster here.
> 
> I've got a project which the client has said 'no mod perl' but only cgi
> and perl. They've got a really powerful machine, but are 'afraid' of
> using mod_perl (because of memory issues, administration etc).
> Performance should not be an issue.
> 
> I also have an employee who knows ASP and some perl. I know that if the
> person writes the web module from scratch (using CGI.pm and perl only),
> it will take about twice as long as it would with Apache::ASP. So I need
> to know if I can run the ASP environment without using mod_perl.
> 

The cgi/asp script in the asp distribution may be
your start here, which you may be able to use 
like: #!/usr/bin/perl asp

at the top of your cgi scripts.  You could hack
it up to set all the special config info you need
for your installation.

Also you can try putting at the top of a cgi script:

use Apache::ASP;
Apache::ASP::CGI::do_self;
__END__

<% ASP script here%>

This is how the test scripts at t/* work in the dist.

Note that I never got Apache::ASP fully working in 
a cgi environment, so you may have to patch it up.  I think
grabbing POST or QUERY input wasn't quite there, thus 
killing the $Request object.

Good luck.

--Joshua
_
Joshua Chamas   Chamas Enterprises Inc.
NodeWorks >> free web link monitoring   Huntington Beach, CA  USA 
http://www.nodeworks.com1-714-625-4051

> I've checked out historical postings and noticed that some people
> (Lincoln Stein - seemingly a lively poster) have questioned the use of
> ASP and cgi at all - we'll that's exactly my situation. I've also found
> alot of leads in the right direction, but no final answer (or mysterious
> ASP.pl program).
> 
> I've been unable to nail down an answer to the question:
> 
> Is there a way to run ASP as a cgi program (interchangably).
> 
> What are the steps involved to do that?
> 
> Thanks alot for the help,
> 
> Charles Dalsass
> www.neptuneweb.com

mod_perl on HP-UX ?

2000-05-19 Thread Andy Johnson


Are there any gotchas to using mod_perl on HP-UX?   I seem to remember
somewhere in the Apache documentation something about HP-UX implemented
shared memory in a weird way...

question - can asp be run as cgi???

2000-05-19 Thread Charles Dalsass


Hey dudes, new poster here.

I've got a project which the client has said 'no mod perl' but only cgi
and perl. They've got a really powerful machine, but are 'afraid' of
using mod_perl (because of memory issues, administration etc).
Performance should not be an issue.

I also have an employee who knows ASP and some perl. I know that if the
person writes the web module from scratch (using CGI.pm and perl only),
it will take about twice as long as it would with Apache::ASP. So I need
to know if I can run the ASP environment without using mod_perl.

I've checked out historical postings and noticed that some people
(Lincoln Stein - seemingly a lively poster) have questioned the use of
ASP and cgi at all - we'll that's exactly my situation. I've also found
alot of leads in the right direction, but no final answer (or mysterious
ASP.pl program).

I've been unable to nail down an answer to the question:

Is there a way to run ASP as a cgi program (interchangably). 

What are the steps involved to do that?

Thanks alot for the help,

Charles Dalsass
www.neptuneweb.com

RE: PerlFreshRestart Question/Problem

2000-05-19 Thread Kreimendahl, Chad J


I work with David... and figured you guys might like to see what version's
we're running... (which is already partially explained by the 1.23 comment
below)

(Apache)
Server Version: Stronghold/2.4.2 Apache/1.3.6 C2NetEU/2410 (Unix)
mod_perl/1.21 ApacheJServ/1.0

(Perl)
Summary of my perl5 (5.0 patchlevel 5 subversion 3) configuration:
  Platform:
osname=solaris, osvers=2.6, archname=sun4-solaris
uname='sunos 5.6 generic_105181-06 sun4u sparc sunw,ultra-1 '
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef useperlio=undef d_sfio=undef
  Compiler:
cc='gcc', optimize='-O', gccversion=2.8.1
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', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib /usr/ccs/lib
libs=-lsocket -lnsl -ldb -ldl -lm -lc -lcrypt
libc=/lib/libc.so, 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'



-Original Message-
From: Stas Bekman [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 19, 2000 1:07 PM
To: David Veatch
Cc: Geoffrey Young; [EMAIL PROTECTED]
Subject: RE: PerlFreshRestart Question/Problem


> At 01:22 PM 5/19/00 -0400, Geoffrey Young wrote:
>  >I think the title says it best:
>
>http://perl.apache.org/guide/troubleshooting.html#Evil_things_might_happen 
> _when_us
> 
> Sweet.  Thanks.  So the problem is probably any number of weak module
> issues.  That's enough for me right now... turning it off certainly
> fixed it. 

Huh? Wasn't the mod_perl 1.23 supposed to fix this problem with DSO? I
thought to remove this item from the Guide. Are there still problems with
DSO? 

If I remember correctly the problem was of broken internal pointers when
the DSO code was reloaded.

>  >you're killing yourself with StatINC in production.
>  >
>  >http://perl.apache.org/guide/porting.html#Configuration_Files_Writing_Dy
> 
> We really haven't noticed any performance hit... nothing dramatic enough
> to detect anyway.  Our database calls are far more expensive than
> checking the modules in %INC so far... and we've optimized our use of
> connections and selects quite a bit.  It is certainly a concern that
> we're keeping in mind, though. 

Attach to one of the servers with 'strace' and see how many stat calls it
does with StatINC turned on.

_
Stas Bekman  JAm_pH --   Just Another mod_perl Hacker
http://stason.org/   mod_perl Guide  http://perl.apache.org/guide 
mailto:[EMAIL PROTECTED]   http://perl.org http://stason.org/TULARC
http://singlesheaven.com http://perlmonth.com http://sourcegarden.org

RE: PerlFreshRestart Question/Problem


> So the PerlFreshRestart is still an issue.

yep.

> I thought it was resolved as well.

one issue was resolved, that was triggered by MIME::foo messing with %INC
while mod_perl was iterating over it.

and, as vivek mentioned, dso mod_perl does a complete teardown
(perl_destruct), but it leaks a bit (far worse leak if perl_destruct is
not called), so static mod_perl still does not do the complete teardown.

RE: PerlFreshRestart Question/Problem


On Fri, 19 May 2000, Vivek Khera wrote:

> > "SB" == Stas Bekman <[EMAIL PROTECTED]> writes:
> 
> SB> Huh? Wasn't the mod_perl 1.23 supposed to fix this problem with DSO? I
> SB> thought to remove this item from the Guide. Are there still problems with
> SB> DSO? 
> 
> DSO works great for me now with the fixes in place of mod_perl 1.23.
> 
> However, note that PerlFreshRestart is meaningless with DSO -- the
> whole perl interpreter is torn down and restarted when you have DSO
> and you restart Apache.  The value of PerlFreshRestart is irrelevent
> at this point.

That's right. I've confused it with the fact the PerlFreshRestart forces
modules reload.

_
Stas Bekman  JAm_pH --   Just Another mod_perl Hacker
http://stason.org/   mod_perl Guide  http://perl.apache.org/guide 
mailto:[EMAIL PROTECTED]   http://perl.org http://stason.org/TULARC
http://singlesheaven.com http://perlmonth.com http://sourcegarden.org

Re: RFC: Apache::Request::Forms (or something similar)


On Fri, 19 May 2000, Matt Sergeant wrote:
> 
> Damn - forgot smiley. Sorry :-)

doh.  your reponse combined with my jetlag == foncusion :-)

RE: PerlFreshRestart Question/Problem


On Fri, 19 May 2000, Doug MacEachern wrote:

> On Fri, 19 May 2000, Stas Bekman wrote:
> 
> > Huh? Wasn't the mod_perl 1.23 supposed to fix this problem with DSO? I
> > thought to remove this item from the Guide. Are there still problems with
> > DSO? 
> >
> > If I remember correctly the problem was of broken internal pointers when
> > the DSO code was reloaded.
> 
> not quite, the bogus pointers problem was triggered by:
> LoadModule perl_module libmodperl.so
> 
> being called twice.

Ouch, that's right.

> not by PerlFreshRestart.
> 
> any how, dso issues are not 100% ironed out, see
> Makefile.PL:malloc_check() for example.

So the PerlFreshRestart is still an issue. I thought it was resolved as
well. The problem was of modules not standing the reload. 

_
Stas Bekman  JAm_pH --   Just Another mod_perl Hacker
http://stason.org/   mod_perl Guide  http://perl.apache.org/guide 
mailto:[EMAIL PROTECTED]   http://perl.org http://stason.org/TULARC
http://singlesheaven.com http://perlmonth.com http://sourcegarden.org

RE: PerlFreshRestart Question/Problem

On Fri, 19 May 2000, Stas Bekman wrote:

> Huh? Wasn't the mod_perl 1.23 supposed to fix this problem with DSO? I
> thought to remove this item from the Guide. Are there still problems with
> DSO? 
>
> If I remember correctly the problem was of broken internal pointers when
> the DSO code was reloaded.

not quite, the bogus pointers problem was triggered by:
LoadModule perl_module libmodperl.so

being called twice.

not by PerlFreshRestart.

any how, dso issues are not 100% ironed out, see
Makefile.PL:malloc_check() for example.

RE: PerlFreshRestart Question/Problem

2000-05-19 Thread Vivek Khera


> "SB" == Stas Bekman <[EMAIL PROTECTED]> writes:

SB> Huh? Wasn't the mod_perl 1.23 supposed to fix this problem with DSO? I
SB> thought to remove this item from the Guide. Are there still problems with
SB> DSO? 

DSO works great for me now with the fixes in place of mod_perl 1.23.

However, note that PerlFreshRestart is meaningless with DSO -- the
whole perl interpreter is torn down and restarted when you have DSO
and you restart Apache.  The value of PerlFreshRestart is irrelevent
at this point.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Vivek Khera, Ph.D.Khera Communications, Inc.
Internet: [EMAIL PROTECTED]   Rockville, MD   +1-301-545-6996
GPG & MIME spoken herehttp://www.khera.org/~vivek/

RE: PerlFreshRestart Question/Problem


> At 01:22 PM 5/19/00 -0400, Geoffrey Young wrote:
>  >I think the title says it best:
>  >http://perl.apache.org/guide/troubleshooting.html#Evil_things_might_happen 
> _when_us
> 
> Sweet.  Thanks.  So the problem is probably any number of weak module
> issues.  That's enough for me right now... turning it off certainly
> fixed it. 

Huh? Wasn't the mod_perl 1.23 supposed to fix this problem with DSO? I
thought to remove this item from the Guide. Are there still problems with
DSO? 

If I remember correctly the problem was of broken internal pointers when
the DSO code was reloaded.

>  >you're killing yourself with StatINC in production.
>  >
>  >http://perl.apache.org/guide/porting.html#Configuration_Files_Writing_Dy
> 
> We really haven't noticed any performance hit... nothing dramatic enough
> to detect anyway.  Our database calls are far more expensive than
> checking the modules in %INC so far... and we've optimized our use of
> connections and selects quite a bit.  It is certainly a concern that
> we're keeping in mind, though. 

Attach to one of the servers with 'strace' and see how many stat calls it
does with StatINC turned on.

_
Stas Bekman  JAm_pH --   Just Another mod_perl Hacker
http://stason.org/   mod_perl Guide  http://perl.apache.org/guide 
mailto:[EMAIL PROTECTED]   http://perl.org http://stason.org/TULARC
http://singlesheaven.com http://perlmonth.com http://sourcegarden.org

Re: RFC: Apache::Request::Forms (or something similar)

On Fri, 19 May 2000, Doug MacEachern wrote:

> > I would say that the bigger picture is definitely not generating HTML with
> > functions - use templates or stylesheets.
> 
> you're probably right.  but that's not what i was getting at.
> i was trying to make points about the bigger picture in general. trying
> to answer "why write something in c that's so simple to write in Perl?".

Damn - forgot smiley. Sorry :-)

-- 

Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org http://xml.sergeant.org

Re: RFC: Apache::Request::Forms (or something similar)

2000-05-19 Thread Drew Taylor


Matt,

All I'm looking for is the fastest way to print sticky form elements. I
already use HTML::Template for the page templating engine (and it works
very well!). I need to take a look at CGI v.3 beta to see if it answers
some of my concerns about memory usage.

Matt Sergeant wrote:
> 
> On Fri, 19 May 2000, Doug MacEachern wrote:
> 
> > personally, i like to have generic things written in c, things that won't
> > change much or at all after they are first implemented (not including bug
> > shaking).  e.g. Apache::Request.  both c and Perl are great languages and
> > blend very well together.  both have pros and cons, i try to use the
> > right combo of both to balance these out.  c is smaller.  c is faster.
> > Perl is much easier to code than c, so i like to save it for things that
> > are difficult to code.  generating html is not difficult.  is it really
> > worth the time to implement this in c?  i'm not convinced yet either, but
> > it is worth thinking about.  we need to consider these things if we want
> > to see the Apache/Perl combo improve as a development platform.
> > think big picture.
> 
> I would say that the bigger picture is definitely not generating HTML with
> functions - use templates or stylesheets.


-- 
Drew Taylor
Vialogix Communications, Inc.
501 N. College Street
Charlotte, NC 28202
704 370 0550
http://www.vialogix.com/

RE: PerlFreshRestart Question/Problem

2000-05-19 Thread David Veatch

At 01:22 PM 5/19/00 -0400, Geoffrey Young wrote:
 >I think the title says it best:
 >http://perl.apache.org/guide/troubleshooting.html#Evil_things_might_happen 
_when_us

Sweet.  Thanks.  So the problem is probably any number of weak module 
issues.  That's enough for me right now... turning it off certainly fixed it.

 >you're killing yourself with StatINC in production.
 >
 >http://perl.apache.org/guide/porting.html#Configuration_Files_Writing_Dy

We really haven't noticed any performance hit... nothing dramatic enough to 
detect anyway.  Our database calls are far more expensive than checking the 
modules in %INC so far... and we've optimized our use of connections and 
selects quite a bit.  It is certainly a concern that we're keeping in mind, 
though.

David Veatch - [EMAIL PROTECTED]

"Many people would sooner die than think.
In fact, they do." - Bertrand Russell

Re: RFC: Apache::Request::Forms (or something similar)

2000-05-19 Thread Honza Pazdziora

On Fri, May 19, 2000 at 06:08:41PM +0100, Matt Sergeant wrote:
>
> I would say that the bigger picture is definitely not generating HTML with
> functions - use templates or stylesheets.

At the very moment, I have a problem to find arguments to persuate my
colleagues to accept this vision. Do you have some arguments that
could be used?

For example, some of our code currently looks like

$display_help = $q->get_preferences_from_db('display_help');
...
show_help('If you want to do that, do it this way ...')
if $display_help;

and show_help touches some global settings (updated per request) to see
if it should print the text with or , so the logic is in the functions (or methods) that are
called throughout the code or the script/handler.

I'd much better just do something like

push @out, 'If you want to do that, do it this way ...';

or even generate it with template, and then postprocess this with
stylesheet, and change the color setting or remove the help text
completely, if the user has the $display_help = 0 set because he's an
advanced user. The main objection I hear to this is that you'd need to
parse and substitute something that you could have gotten right in the
first place, and you can do the design changes in the functions as
you'd do in the stylesheet.

Can you help me with some points that I could use to persuate
templates and/or stylesheet for this application?

Honza Pazdziora | [EMAIL PROTECTED] | http://www.fi.muni.cz/~adelton/
.project: Perl, DBI, Oracle, MySQL, auth. WWW servers, MTB, Spain.

Re: RFC: Apache::Request::Forms (or something similar)


> I would say that the bigger picture is definitely not generating HTML with
> functions - use templates or stylesheets.

you're probably right.  but that's not what i was getting at.
i was trying to make points about the bigger picture in general. trying
to answer "why write something in c that's so simple to write in Perl?".

RE: PerlFreshRestart Question/Problem

2000-05-19 Thread Geoffrey Young




> -Original Message-
> From: David Veatch [mailto:[EMAIL PROTECTED]]
> Sent: Friday, May 19, 2000 11:48 AM
> To: [EMAIL PROTECTED]
> Subject: PerlFreshRestart Question/Problem
> 
> 
> Greetings,
> 
> [i sent this once, but think it got hung up at the mail server... my 
> apologies if this already went through]
> 
> I've run into some interesting behaviors with the PerlFreshRestart 
> directive.  If I understand correctly, this directive is 
> supposed to force 
> modules to reload when you execute `apachectl restart`, but should 
> otherwise have no effect on performance.
> 
> On our work servers, enabling "PerlFreshRestart On" in our 
> main conf file 
> caused absolutely incredible and unbearable slow downs.  The 
> performance 
> hit was amazing.  Pages that normally take 15 seconds or so 
> to load (very 
> large pulls out of a networked Oracle database) took 3 to 4 
> minutes.  Smaller pages that normally come up instantly 
> (still database 
> driven) take 15 to 20 seconds.
> 
> My home machine did not experience any performance hits, but 
> did experience 
> strange but reproducible problems loading modules on startup.  If the 
> module hadn't changed, it wouldn't reload, but change the 
> module and things 
> work again.  Stopping the server completely and restarting it 
> didn't help, 
> only changing the module did.

I think the title says it best:
http://perl.apache.org/guide/troubleshooting.html#Evil_things_might_happen_w
hen_us

> 
> Both sites are made up of several modules, and several cgi's 
> running under 
> Apache::Registry with Apache::StatINC enabled.

you're killing yourself with StatINC in production.

http://perl.apache.org/guide/porting.html#Configuration_Files_Writing_Dy


HTH

--Geoff

> 
> I'm sure I'm missing something that you need to know, so feel free to 
> ask... it was a long night last night...
> 
> David Veatch - [EMAIL PROTECTED]
> 
> "Many people would sooner die than think.
> In fact, they do." - Bertrand Russell
>

Re: RFC: Apache::Request::Forms (or something similar)

2000-05-19 Thread Vivek Khera


> "MS" == Matt Sergeant <[EMAIL PROTECTED]> writes:

MS> I would say that the bigger picture is definitely not generating HTML with
MS> functions - use templates or stylesheets.

Templates (especially ones that let you iterate over arrays) are the
way to go, in my book, for generating regular HTML.

The only problem is with making a template that has sticky forms with
non-text fields.  Making a sticky menu select object ain't easy in
templated-HTML, in my experience.  I prefer to do forms (at least the
menus and such) using functions for this reason.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Vivek Khera, Ph.D.Khera Communications, Inc.
Internet: [EMAIL PROTECTED]   Rockville, MD   +1-301-545-6996
GPG & MIME spoken herehttp://www.khera.org/~vivek/

YAMPGSE (yet another mod_perl guide search engine)

2000-05-19 Thread Vivek Khera


I've been fooling around with the nextrieve engine for several sites I
maintain, and I figured I'd give it a whirl on the mod_perl guide.

Since the guide is a bunch of very large pages, this search also uses
the split-up version that Randy's search has.  Thanks to Randy for
providing the script that does the splitting.

I've put it up on a test location for people to pound on a bit.  So
far it has given decent results for everything posted to the list
about the other search engine.

Give it a whirl and lemme know what you think.  The result page is
just a template so can be spruced up and have logos and such attached
quite easily.

 http://thingy.kcilink.com/cgi-bin/modperlguide.cgi

The only issues it has is with searching for terms like $[ and $/ but
works well for most other queries.

Please note that this is a temporary location for this resource.
Should we decide that this will be the "official" search engine, it
will get a permanent home.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Vivek Khera, Ph.D.Khera Communications, Inc.
Internet: [EMAIL PROTECTED]   Rockville, MD   +1-301-545-6996
GPG & MIME spoken herehttp://www.khera.org/~vivek/

Re: RFC: Apache::Request::Forms (or something similar)

On Fri, 19 May 2000, Doug MacEachern wrote:

> personally, i like to have generic things written in c, things that won't
> change much or at all after they are first implemented (not including bug
> shaking).  e.g. Apache::Request.  both c and Perl are great languages and
> blend very well together.  both have pros and cons, i try to use the
> right combo of both to balance these out.  c is smaller.  c is faster.
> Perl is much easier to code than c, so i like to save it for things that
> are difficult to code.  generating html is not difficult.  is it really
> worth the time to implement this in c?  i'm not convinced yet either, but
> it is worth thinking about.  we need to consider these things if we want
> to see the Apache/Perl combo improve as a development platform.
> think big picture.

I would say that the bigger picture is definitely not generating HTML with
functions - use templates or stylesheets.

just my 2p.

-- 

Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org http://xml.sergeant.org

Re: RFC: Apache::Request::Forms (or something similar)

On Fri, 19 May 2000, Autarch wrote:

> Well, my point was that the decision to code something in C should be done
> because it offers an overwhelming (orders of magnitude) improvement,
> preferably on more than one front (speed, memory, ease of maintenance
> (haha) ).

small savings here and there can add up to big savings in the end.  did
you look at the size of CGI::start_html?  16k.  and that's a small
subroutine, these things add up quick.

> Really, if you feel that Perl is too memory hungry and slow for even
> simple text output, then why use Perl at all?

i never said that.  i'm just trying to point out that it's worth
considering the savings.

> My bias is against C because I don't like it and I think it makes the
> module less accessible to people and therefore less likely to get improved
> by the community at large, and more likely to only get worked on by 1
> person.

personally, i like to have generic things written in c, things that won't
change much or at all after they are first implemented (not including bug
shaking).  e.g. Apache::Request.  both c and Perl are great languages and
blend very well together.  both have pros and cons, i try to use the
right combo of both to balance these out.  c is smaller.  c is faster.
Perl is much easier to code than c, so i like to save it for things that
are difficult to code.  generating html is not difficult.  is it really
worth the time to implement this in c?  i'm not convinced yet either, but
it is worth thinking about.  we need to consider these things if we want
to see the Apache/Perl combo improve as a development platform.
think big picture.

[ANNOUNCE] AxKit 0.65


This release of AxKit adds XSP support. XSP is a script embedded XML
language that is language and output agnostic. All big words, translated
to: You can write XSP pages in Perl, Java or Javascript (*).

http://xml.sergeant.org/axkit/

Details on XSP: http://xml.apache.org/cocoon/xsp.html

(*) Perl supported in AxKit, Java and Javascript supported in Cocoon.

-- 


Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org http://xml.sergeant.org

Re: [preview] Search engine for the Guide


On Fri, 19 May 2000, Randy Kobes wrote:

> On Fri, 19 May 2000, Stas Bekman wrote:
> 
> > On Fri, 19 May 2000, raptor wrote:
> > 
> > > hi,
> > > 
> > > very interesting. Search for : "statinc" returns nothing and the box get filled
> > > with "tatinc" instead "statinc" ?!?!:")
> > > 
> > > this under KDE viewer, now will try netscape   ...!!
> > 
> > it's not the client -- it's a bug.
> > 
> > This happened after Randy has made non-stemming as a default. When you
> > turn the stemming on you get it right. Randy, ideas?
> 
> Hi,
> This was a bug, which was just fixed - 'statinc' now returns
> reasonable results. Also, I fixed it so a search term of
> $SIG{__DIE__}, for example, also returns some results.

Almost, when you search for it for the first time, it's Ok. But then you
append \ before $SIG{__DIE__} and it searchs for \\$SIG{__DIE__} which
yields nothing.

'VINC' gives nothing as well :(

Looks like a try and catch game...

_
Stas Bekman  JAm_pH --   Just Another mod_perl Hacker
http://stason.org/   mod_perl Guide  http://perl.apache.org/guide 
mailto:[EMAIL PROTECTED]   http://perl.org http://stason.org/TULARC
http://singlesheaven.com http://perlmonth.com http://sourcegarden.org

Re: RFC: Apache::Request::Forms (or something similar)

2000-05-19 Thread Autarch

On Fri, 19 May 2000, Doug MacEachern wrote:

> > C seems like serious overkill for something to simply generate plain text
> > output.  How slow is making a string in perl compared to doing it in C?  
> > I can't imagine there's to much of a difference.
> 
> more like Perl is serious overkill :)
> SV's are BIG, notice the $unused variable and the B::TerseSize output
> (from Apache::Status) below, even before a string is copied into it,
> there's 48 bytes eaten.

Well, my point was that the decision to code something in C should be done
because it offers an overwhelming (orders of magnitude) improvement,
preferably on more than one front (speed, memory, ease of maintenance
(haha) ).

Really, if you feel that Perl is too memory hungry and slow for even
simple text output, then why use Perl at all?

My bias is against C because I don't like it and I think it makes the
module less accessible to people and therefore less likely to get improved
by the community at large, and more likely to only get worked on by 1
person.

-dave

/*==
www.urth.org
We await the New Sun
==*/

Re: [preview] Search engine for the Guide

2000-05-19 Thread Randy Kobes

On Fri, 19 May 2000, Stas Bekman wrote:

> On Fri, 19 May 2000, raptor wrote:
> 
> > hi,
> > 
> > very interesting. Search for : "statinc" returns nothing and the box get filled
> > with "tatinc" instead "statinc" ?!?!:")
> > 
> > this under KDE viewer, now will try netscape   ...!!
> 
> it's not the client -- it's a bug.
> 
> This happened after Randy has made non-stemming as a default. When you
> turn the stemming on you get it right. Randy, ideas?

Hi,
This was a bug, which was just fixed - 'statinc' now returns
reasonable results. Also, I fixed it so a search term of
$SIG{__DIE__}, for example, also returns some results.

best regards,
randy

PerlFreshRestart Question/Problem

2000-05-19 Thread David Veatch


Greetings,

[i sent this once, but think it got hung up at the mail server... my 
apologies if this already went through]

I've run into some interesting behaviors with the PerlFreshRestart 
directive.  If I understand correctly, this directive is supposed to force 
modules to reload when you execute `apachectl restart`, but should 
otherwise have no effect on performance.

On our work servers, enabling "PerlFreshRestart On" in our main conf file 
caused absolutely incredible and unbearable slow downs.  The performance 
hit was amazing.  Pages that normally take 15 seconds or so to load (very 
large pulls out of a networked Oracle database) took 3 to 4 
minutes.  Smaller pages that normally come up instantly (still database 
driven) take 15 to 20 seconds.

My home machine did not experience any performance hits, but did experience 
strange but reproducible problems loading modules on startup.  If the 
module hadn't changed, it wouldn't reload, but change the module and things 
work again.  Stopping the server completely and restarting it didn't help, 
only changing the module did.

Both sites are made up of several modules, and several cgi's running under 
Apache::Registry with Apache::StatINC enabled.

I'm sure I'm missing something that you need to know, so feel free to 
ask... it was a long night last night...

David Veatch - [EMAIL PROTECTED]

"Many people would sooner die than think.
In fact, they do." - Bertrand Russell

Re: Prb: Apache::DB plus Perl 5.6 doesn't break


On Fri, 19 May 2000, Jeremy Howard wrote:

> Thanks heaps, Doug--moving require Apache::DB/Apache::DB->init to the
> top fixed it! 

kool!

> Previously I had 'use Apache' 1st, which worked fine under the "old"
> version... It's funny the things that change between versions, isn't it?
> In fact, Apache::DB is now working better than before--I used to have
> some subs outside of modules that wouldn't break properly... now they
> work fine!   

right, because Perl decides at compile time if a subroutine call should be
dispatched to the debugger, which it won't do unless Apache::DB->init has
been called (similar to what -d switch does on the command line)
 
> Is anyone aware of any specific reason not to switch to 5.6.0 with
> mod_perl for production machines (other than just 'in case')? 

we've hit a few problems, but 1.24 should have them ironed out. can't
promise there won't be more though.

Re: Prb: Apache::DB plus Perl 5.6 doesn't break

2000-05-19 Thread Jeremy Howard


> i am able to set breakpoints no problem with 5.6.0 (perl-current,
> actually).  i would suggest stripping back your Perl config to something
> simple (i tested with b Apache::Status::handler) and make sure
> require Apache::DB/Apache::DB->init is the first piece of Perl code to
> run.
> 
Thanks heaps, Doug--moving require Apache::DB/Apache::DB->init to the top fixed it!

Previously I had 'use Apache' 1st, which worked fine under the "old" version... It's 
funny the things that change between versions, isn't it? In fact, Apache::DB is now 
working better than before--I used to have some subs outside of modules that wouldn't 
break properly... now they work fine!

Is anyone aware of any specific reason not to switch to 5.6.0 with mod_perl for 
production machines (other than just 'in case')?

-- 
  Jeremy Howard
  [EMAIL PROTECTED]

Re: [preview] Search engine for the Guide


On Fri, 19 May 2000, raptor wrote:

> hi,
> 
> very interesting. Search for : "statinc" returns nothing and the box get filled
> with "tatinc" instead "statinc" ?!?!:")
> 
> this under KDE viewer, now will try netscape   ...!!

it's not the client -- it's a bug.

This happened after Randy has made non-stemming as a default. When you
turn the stemming on you get it right. Randy, ideas?


_
Stas Bekman  JAm_pH --   Just Another mod_perl Hacker
http://stason.org/   mod_perl Guide  http://perl.apache.org/guide 
mailto:[EMAIL PROTECTED]   http://perl.org http://stason.org/TULARC
http://singlesheaven.com http://perlmonth.com http://sourcegarden.org

Re: Prb: Apache::DB plus Perl 5.6 doesn't break


i hadn't tried Apache::DB with newer Perl since 5.005_6x-ish, there was a
fix that went into version 0.06 for that, are you using 0.06?

i am able to set breakpoints no problem with 5.6.0 (perl-current,
actually).  i would suggest stripping back your Perl config to something
simple (i tested with b Apache::Status::handler) and make sure
require Apache::DB/Apache::DB->init is the first piece of Perl code to
run.

Re: [preview] Search engine for the Guide

2000-05-19 Thread raptor


hi,

very interesting. Search for : "statinc" returns nothing and the box get filled
with "tatinc" instead "statinc" ?!?!:")

this under KDE viewer, now will try netscape   ...!!

Re: RFC: Apache::Request::Forms (or something similar)

On Fri, 19 May 2000, Gunther Birznieks wrote:

> eg I think there was a thread on this list way back about OO method calls 
> versus direct package references... and people said that OO method calls 
> have a lot of overhead, but I think in later versions of Perl, OO method 
> call paths are cached(?) and so method calls no longer have the same 
> overhead as they used to.

there has always been a method cache, but even with that, methods are
still a bit more expensive.  the only improvement in 5.6.0 related to
method calls (that i know of ) is that:

$obj->method; #where method name is constant, know at compile time

is now faster than:

$obj->$method; #where $method isn't known until runtime

Re: RFC: Apache::Request::Forms (or something similar)


On Thu, 18 May 2000, brian moseley wrote:

> On Thu, 18 May 2000, Jeffrey W. Baker wrote:
> 
> > .= concatenation is way faster
> 
> i don't have any results to back up my claim. therefore,
> my words are eaten :)
> 
> i was convinced tho, even way back before you came to cp. i
> wonder what convinced me!

that was probably me :)  but, i don't recall suggesting join.
but i do recall pushing away from concat when print()-ing, this benchmark
also illustrates why i made Apache::print dereference references to
strings.  5.005_03 does seem todo better with the array benchmark than
5.006, oh well.  there's tradeoffs both ways, i don't think there's a
clear winner.

Benchmark: timing 3 iterations of array, concat, ref_array...
 array:  8 wallclock secs ( 6.90 usr +  0.27 sys =  7.17 CPU) @4184.10/s (n=3)
concat:  7 wallclock secs ( 5.98 usr +  0.16 sys =  6.14 CPU) @4885.99/s (n=3)
 ref_array:  5 wallclock secs ( 4.59 usr +  0.16 sys =  4.75 CPU) @6315.79/s (n=3)

use Benchmark;

open my $fh, ">/dev/null" or die;

my($one, $two, $three) = map { $_ x 4096 } 'a'..'c';

timethese(30_000, {
  'ref_array' => sub {
  my @a;
  push @a, \($one, $two, $three);
  my_print(@a);
  },
  'array' => sub {
  my @a;
  push @a, $one, $two, $three;
  my_print(@a);
  },
  'concat' => sub {
  my $s;
  $s .= $one;
  $s .= $two;
  $s .= $three;
  my_print($s);
  },
 });

sub my_print {
for (@_) {
print $fh ref($_) ? $$_ : $_;
}
}

Re: Want to work at a Game company?

2000-05-19 Thread raptor


On Thu, 18 May 2000, ___cliff rayman___ wrote:
> legitimate job offers from a reputable company are never spam.
> 

especially if your salary is not more than ~$150-$200 per month :"(

sorry for the off-topic

iVAN
[EMAIL PROTECTED]

Re: RFC: Apache::Request::Forms (or something similar)

On Thu, 18 May 2000, Autarch wrote:

> C seems like serious overkill for something to simply generate plain text
> output.  How slow is making a string in perl compared to doing it in C?  
> I can't imagine there's to much of a difference.

more like Perl is serious overkill :)
SV's are BIG, notice the $unused variable and the B::TerseSize output
(from Apache::Status) below, even before a string is copied into it,
there's 48 bytes eaten.

my $r = shift;

$r->send_http_header;

my $unused;

my $string = "hi";

print $string;

Totals: 1455 bytes | 23 OPs

PADLIST summary:
0:   undef [AV   116 bytes] MAX => 3
1:  $r [RV52 bytes] 0x891b9b4
2:   undef [GV81 bytes] 
3:   undef [NULL  24 bytes] 0x891ba44
4:   undef [NULL  24 bytes] 0x891ba5c
5: $unused [NULL  48 bytes] 0x891ba50
6: $string [PV63 bytes] hi

now let's look at CGI::start_html:

Totals: 15595 bytes | 330 OPs

PADLIST summary:
  8:$title [PV78 bytes] Untitled Document
 35: undef [PV   140 bytes] http://www.w3.org/TR/html4/loose.dtd">
 40: undef [PV56 bytes] 
 46: undef [PV81 bytes] Untitled
Document
 48: undef [PV65 bytes] 
 94: undef [PV49 bytes] 
100: undef [PV45 bytes] 
101: undef [PV   199 bytes] http://www.w3.org/TR/html4/loose.dtd">
Untitled Document

i've omitted all but the string variables, notice the additional copies,
which are a result of concatination.  Perl copies *everything* and these
copies add up to alot.  this is why i would like to see an html
generator written in c, it would result in a much smaller footprint, no
matter what the Perl implementation may be.

Re: writing code that works on machines with or without mod_perl

On Thu, 18 May 2000, Matt Sergeant wrote:

> On Thu, 18 May 2000, Kenneth Lee wrote:
> 
> > modperlers,
> > 
> > does it make sense if i put some mod_perl specific codes inside 
> > an eval() so that the code runs on machines that have or haven't 
> > mod_perl installed?
> > 
> >   eval <<'MOD_PERL_CODE' if $ENV{MOD_PERL};
> > use Apache ();
> > my $r = Apache->request;
> > ...
> >   MOD_PERL_CODE
> 
> Better still:
> 
> eval {
>   die unless $ENV{MOD_PERL};
>   require Apache;
>   my $r = $Apache->request;
>   ...
> };
> 
> Then you've got no (at least much less than the above) run-time overhead.

better still:

use constant IS_MODPERL => $ENV{MOD_PERL};

BEGIN {
import Apache::Constants qw(OK) if IS_MODPERL;
}

if (IS_MODPERL) {
my $r = Apache->request;
}

_zero_ runtime overhead, since IS_MODPERL is constant folded, that block
is optimized away at compile time outside of mod_perl.

you shouldn't need to 'use Apache ()', mod_perl does that for you, along
with Apache::Constants.  in any case, have your startup script require any
Apache:: modules you need and import in a BEGIN block if needed.

Re: RFC: Apache::Request::Forms (or something similar)


> i do think that doug's separation of responsibilities into
> classes is the right one. your widget toolkit probably
> shouldn't be named Apache::HTML tho, unless it's actually
> using the apache api in some fashion.

one reason i was thinking Apache::HTML is so we can use ap_pool for
allocations.

Re: passing Apache::File to XS code that expects FILE *?


On Thu, 18 May 2000, Vivek Khera wrote:

> > "DM" == Doug MacEachern <[EMAIL PROTECTED]> writes:
> 
> DM> On Wed, 17 May 2000, Matt Sergeant wrote:
> >> Well, this may be true, but if you load IO::File before startup then it's
> >> not too big a deal...
> 
> DM> but it still adds a great deal of bloat to the server.  and it's oo
> DM> interface, while very slick, adds quite a bit of runtime overhead, turn
> DM> the sugar sour imo.
> 
> In an embedded environment like mod_perl, then how do you suggest to
> deal with the dangling file handles problem?  That is, I'm processing
> a file or two, and some error occurs.  In a normal perl program, I'd
> exit or return out and then when the program terminates, it
> automagically closes all the files.  In mod_perl, the auto-close
> doesn't happen until much later.  With the OO interface, when the
> handle goes out of scope, such as a function call return, the file is
> implicitly closed.
> 
> What other mechanism do you propose to handle this situation other
> than IO::File?  I use it all the time myself.

in addition to stas' hints, even local *FH does the job, e.g.:

#/dev/null so strace output is more readable
open my $fh, ">/dev/null";
select $fh;
$| = 1;

{
 print "enter";
 local *FH;
 open FH, $0;
 print "leave"
}

print "done";

% strace ~/test/io.pl
write(3, "enter", 5)= 5
-> open("/home/dougm/test/io.pl", O_RDONLY) = 4
fstat(4, {st_mode=S_ISGID|S_ISVTX|0401, st_size=0, ...}) = 0
fcntl(4, F_SETFD, FD_CLOEXEC)   = 0
write(3, "leave", 5)= 5
-> close(4)= 0
write(3, "done", 4) = 4

RE: [preview] Search engine for the Guide


> > That would be nice to see. I'm afraid I'll continue on working on guide.
> > So if there anyone with a few free minutes on his hands, he/she might like
> > to contribute something back to community ;)
> >
> > Ideally, when we complete the tuning of the search engine, we will be able
> > to have the whole site, apache::asp and embperl pages searchable as well.
> > (with Perl style documentation in mind).
> >
> 
> Stas,
> 
> there is already a search frontend for the apache sites, at
> http://www.apache.org/search.html which is also able to search under
> perl.apache.org, but if you enter mod_perl, doesn't find anything :-(. Don't
> know if this is of any use and who is maintaining (or not maintaining) this
> page.

Heh, look at the bottom of the http://perl.apache.org/guide/index.html --
the search box from http://www.apache.org/search.html is there since the
day the guide is online. But as you said -- it's useless, as it's not good
for the kind of documentation we have. 

I've posted a request for comments about the apache.org search engine to
the asf members list but it was ignored :(

_
Stas Bekman  JAm_pH --   Just Another mod_perl Hacker
http://stason.org/   mod_perl Guide  http://perl.apache.org/guide 
mailto:[EMAIL PROTECTED]   http://perl.org http://stason.org/TULARC
http://singlesheaven.com http://perlmonth.com http://sourcegarden.org

RE: [preview] Search engine for the Guide

2000-05-19 Thread Gerald Richter


>
> That would be nice to see. I'm afraid I'll continue on working on guide.
> So if there anyone with a few free minutes on his hands, he/she might like
> to contribute something back to community ;)
>
> Ideally, when we complete the tuning of the search engine, we will be able
> to have the whole site, apache::asp and embperl pages searchable as well.
> (with Perl style documentation in mind).
>

Stas,

there is already a search frontend for the apache sites, at
http://www.apache.org/search.html which is also able to search under
perl.apache.org, but if you enter mod_perl, doesn't find anything :-(. Don't
know if this is of any use and who is maintaining (or not maintaining) this
page.

Gerald

Re: [preview] Search engine for the Guide

On Fri, 19 May 2000, Matt Sergeant wrote:

> On Thu, 18 May 2000, Randy Kobes wrote:
> 
> > Another thing that was configured in is that words have
> > to be at least 3 characters long, which seems reasonable,
> > and also there's some stopwords that don't get indexed,
> > as they're too common. This list of stopwords is built
> > by hand - so far it only includes 'perl' and 'modperl'.
> > Also, the maximum number of hits is set at 30.
> 
> It should also index $/, etc. So limiting to >2char words is another
> broken aspect...

Seems like for Perl documentation there should be no limiting at all, or
may be one character is the only option...

> But I'm not complaining! It's 100% better than it was. Maybe someone
> would like my code for a db backed search engine and fix that up to
> something that could work? It's all built in perl so you're free to add
> and remove stopwords or change the min word length as you like. 

That would be nice to see. I'm afraid I'll continue on working on guide. 
So if there anyone with a few free minutes on his hands, he/she might like
to contribute something back to community ;) 

Ideally, when we complete the tuning of the search engine, we will be able
to have the whole site, apache::asp and embperl pages searchable as well.
(with Perl style documentation in mind).

_
Stas Bekman  JAm_pH --   Just Another mod_perl Hacker
http://stason.org/   mod_perl Guide  http://perl.apache.org/guide 
mailto:[EMAIL PROTECTED]   http://perl.org http://stason.org/TULARC
http://singlesheaven.com http://perlmonth.com http://sourcegarden.org

Re: [preview] Search engine for the Guide


On Fri, 19 May 2000, Ged Haywood wrote:

> Hi all,
> 
> On Thu, 18 May 2000, Randy Kobes wrote:
> 
> > > The :: are stripped on the fly, since these cannot be used in index, so
> > > when you look for Foo::Bar you are actually looking for 'Foo && Bar'.
> > 
> > That's a limitation of swish-e - you can configure it to
> > index characters like $, !, ... as part of a "word", but
> > the characters >, <, *, and : cannot be so indexed.
> 
> If you use swish++4.4 then you can change this in "config.h"
> 
> // Characters that are permissible in words: letters must be lower
> // case and upper case letters would be redundant.
> //
> char const Word_Chars[] = "&'-0123456789abcdefghijklmnopqrstuvwxyz_";
> // Characters that may be in a word.  Note that '&' is here so
> // acronyms like "AT&T" are treated as one word.  Unlike SWISH-E,
> // ';' does not need to be here to recognize and convert character
> // entity references.

Interesting, Randy what version did you use?

Thanks Ged!

_
Stas Bekman  JAm_pH --   Just Another mod_perl Hacker
http://stason.org/   mod_perl Guide  http://perl.apache.org/guide 
mailto:[EMAIL PROTECTED]   http://perl.org http://stason.org/TULARC
http://singlesheaven.com http://perlmonth.com http://sourcegarden.org

Re: [preview] Search engine for the Guide


On Thu, 18 May 2000, Randy Kobes wrote:

> On Fri, 19 May 2000, Stas Bekman wrote:
> 
> > On Thu, 18 May 2000, Vivek Khera wrote:
> > 
> > > looks good... one minor issue with the stickyness of the next search
> > > feature:
> > > 
> > > type "lexical file handles" in your original search.  the "es" at the
> > > end is lost in the next search box on the result page.
> > 
> > Yup, broken :(
> 
> Hi,
> But fixable ...:) As I just mentioned, we can turn stemming
> off, or at least make it optional, so the full word only is
> searched for. I've found stemming useful, but that's perhaps
> just the way I do searches - should I turn it off by default to see if
> that's preferable? And make it then a configurable option?

Yup, turn it off. And have an option to turn it on. 

Thanks!

_
Stas Bekman  JAm_pH --   Just Another mod_perl Hacker
http://stason.org/   mod_perl Guide  http://perl.apache.org/guide 
mailto:[EMAIL PROTECTED]   http://perl.org http://stason.org/TULARC
http://singlesheaven.com http://perlmonth.com http://sourcegarden.org

New Module (was Re: RFC: Apache::Request::Forms (or something similar))

2000-05-19 Thread Francesc Guasch


I have my own module for doing this job, sorry I missed many
posts of this thread but here is what I do:

- The target is automatically : add , update, select data
  from a table reading data typed by the user.

- I didn't want to use the Apache api, so it even can be
  used out of apache, so I called it : Persistence::DBI
  thought I don't like this name much.

In This example I work with HTML::Mason, but as
I said before it can be used from whatever thingie, even
out of the web.

I'm using currently this in production sites and it saves
me a lot of work.


EXAMPLE OF CODE:
It's a little harder than this but you'll get the idea:

##customer.html###3

<%init>
# Make the object
my $customer=Persistence::DBI->open(
table => 'customers',
field_id => 'idCustomer'
field_data => \%ARGS
);

if (defined $_delete) {
$customer->delete;
}




## The html form is this way:


  
  
  
% if (defined $customer->idCustomer) {


% }



It works this way:
- if you supply the value of the id field it does a select
- if you supply all the fields but the id, it does an insert
- if you supply id and fields it does an update

Before calling the object you can check the values supplied
by the user to verify the values are correct.

If you modify values of the object it updates the data.


I'll accept name changes and I'll send the module to 
whoever wants it. I checked it with MySQL and SQL server.
The module come with pods and it installs fine like any
other module.It needs the field_id be auto increment.

-- 
 - frankie -

(pas d'objet)

2000-05-19 Thread Raphaël Grandjean




--
Raphaël Grandjean
FI SYSTEM
Tél:0147615331

Re: [preview] Search engine for the Guide