does anyone have a fix for this?
Hello all,
I'm new to the list and I'm hoping that someone could help me and explain
what I'm doing wrong or how to fix this
I recently compiled mod_perl-1.24 and it can run modules that I program.
However I get a segmentation fault (11) when I use a :: to describe where
the module is.
Example
This works fine -
SetHandler perl-script
PerlHandler hello
This causes the horrible [Wed Aug 2 22:34:30 2000] [notice] child pid 4433
exit signal Segmentation fault (11)
to rear its ugly head even though the module was moved to
/home/httpd/perl/app.
SetHandler perl-script
PerlHandler app::hello
to help here's a copy of my startup.pl - basic nothing special
#!/usr/bin/perl
BEGIN {
use Apache;
use lib '/home/httpd/perl';
}
1;
The help is much appreciated, I've lost half my hair tearing it out trying
to find the cause of this problem.
Thanks,
Jamie Krasnoo
Re: mod_perl configure
Sorry, I'm not a master. But I try to answer your question.
This is because your installation not successful. Try to install
mod_perl again with perl-5.6.0. I 've tried it and it worked good.
The script CGI you embedded is not running under mod_perl, but it run as a
common CGI.
The installation step like here
$ perl Makefile.PL EVERYTHING=1 DO_HTTPD=1 USE_APACI=1
APACHE_SRC=../apache_1.3.6/src APACHE_PREFIX=/usr/local/apache
$ make
$ make test TEST_VERBOSE=1
$ make install
then restart your apache
Thx.
On Thu, 3 Aug 2000, yusun wrote:
> I have installed the mod_perl and changed the httpd.conf as
>
> Alias /cgi-perl/ /usr/ns-home/cgi-bin/
>
> #AllowOverride None
> SetHandler perl-script
> PerlHandler Apache::PerlRun
> Options +ExecCGI
> allow from all
> PerlSendHeader On
> PerlSetVar PerlRunOnce On
>
>
> When I restarted httpd, there was no error reported.
> But when I used the following CGI to test whether the mod_perl was working
> or not.
> The report was no. Why?
>
> ###
> #!/usr/bin/perl
> print "Content-type: text/plain\n\n";
> print "Server's environment\n";
> foreach ( keys %ENV ) {
> print "$_\t$ENV{$_}\n";
> }
> #
>
> The result is
> :
> :
> GATEWAY_INTERFACE CGI/1.1
> :
>
> It means that I have configured this location to run under mod_cgi and not
> mod_perl.
> How can I configure the location to run under mod_perl?
> Thanks!
>
>
>
>
Re: Feature sets [was Re: Templating System]
On 2 Aug 2000, (Randal L. Schwartz) wrote: > > "Ron" == Ron Pero <[EMAIL PROTECTED]> writes: > > Ron> A few days ago I sent this suggestion to Drew Taylor, who is > Ron> preparing a web page comparing the templating systems. He said he > Ron> likes the idea. The Categorical "Congratulations: you wrote a > Ron> templating system!" web memorial. > > Wow, if making suggestions here gets that kind of immediate results, > let me also suggest I need a girlfriend who is travel-compatible and > email friendly. Maybe one will show up. :) Not with your dancing :-P > Or do you get only one wish per quarter? :) The genie is back in the bottle now :) -- Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org | AxKit: http://axkit.org
mod_perl configure
I have installed the mod_perl and changed the
httpd.conf as
Alias /cgi-perl/
/usr/ns-home/cgi-bin/
#AllowOverride None
SetHandler perl-script
PerlHandler Apache::PerlRun
Options +ExecCGI allow from
all PerlSendHeader
On PerlSetVar
PerlRunOnce On When I
restarted httpd, there was no error reported.But when I used the following CGI to test whether the mod_perl was
workingor not.The report was no. Why?
!/usr/bin/perlprint "Content-type:
text/plain\n\n"; print "Server's environment\n"; foreach (
keys %ENV ) { print
"$_\t$ENV{$_}\n"; }#The result
is :
:GATEWAY_INTERFACE CGI/1.1 :It means
that I have configured this location to run under mod_cgi and
notmod_perl.How can I configure the location to run under
mod_perl?Thanks!
Perlbug 20000330.041 status update
http://bugs.perl.org/perlbug.cgi?req=tid&tid=2330.041
---
Subject:Re: [PATCH 5.6.0] local $SIG{FOO} restoration
TicketID: 2330.041Patch Ids:
Created:2000-03-30 11:59:41 Status:closed
Version:5 Category: notabug
Fixed in: Severity: low
Os:
Admins: michaels
Sourceaddr: Tom Christiansen <[EMAIL PROTECTED]>
MessageIDs: 7392
NoteIDs:
Messageid Ticketid
---
73922330.041
Messagebody:
>i suppose the handler should not be restored if it was Perl's, something
>along the lines of (on top of take2 patch):
Exactly! this kind of thing is common in programs that do sigmasks
or tty mode masks. The typical mistake is
set noecho
do something
unset noecho
or
block sigfoo
do something
unblock sigfoo
In both cases the bug is the same: you shouldn't undo something that
was already undone to start with.
--tom
Re: Feature sets [was Re: Templating System]
[EMAIL PROTECTED] (Gunther Birznieks) wrote: >I am afraid that while I agree, a check system is really quite useful to >me. Some things do need more quantification, but that can be done later. > >eg lightweight vs heavyweight is subjective. But it can be broken up into >saying something like how much code needs to be loaded at start time (an >issue for CGI/Perl). eg I think people would agree that the startup of >CGI.pm is different from CGI::Lite which is different from cgi-lib.pl. Of >course, there are many other features that you get from them that can make >a difference in your program. > >Anyway, that is why this checklist is being designed by all of you and >handled by an independent 3rd party. It's not a marketing tool. So if you >complain about session support being a checkbox, I am sure that the feature >name could be refined. I agree. I came up with an initial set of checkboxes (posted here last week), but I'd have no qualms about some author wanting to ditch some of those. I think a useful comparison would use feature comparisons only as a means of revealing the comparitive philosophies of the systems. Gunther, has anyone found a good home for such a comparison to be hosted? It would be cool if it were at perl.apache.org, or even better at www.perl.com or something (since it's not mod_perl specific). As long as it's easily updatable by its maintainers (and who are they?).
Re: Feature sets [was Re: Templating System]
I am afraid that while I agree, a check system is really quite useful to me. Some things do need more quantification, but that can be done later. eg lightweight vs heavyweight is subjective. But it can be broken up into saying something like how much code needs to be loaded at start time (an issue for CGI/Perl). eg I think people would agree that the startup of CGI.pm is different from CGI::Lite which is different from cgi-lib.pl. Of course, there are many other features that you get from them that can make a difference in your program. Anyway, that is why this checklist is being designed by all of you and handled by an independent 3rd party. It's not a marketing tool. So if you complain about session support being a checkbox, I am sure that the feature name could be refined. Later, Gunther At 08:26 AM 8/2/00 -0700, Jonathan Swartz wrote: >Drew Taylor wrote: > >Ken Williams wrote: > >> > >> I suggest having not just a simple checkmark, but a 3-way check. A > >> system either supports a feature, or it doesn't, or it *optionally* > >> supports it (can be switched on and off). This is often very helpful to > >> know, and might let one get a good sense of the differences between > >> various systems at a glance. > >Another great idea! Should we go one farther and have a checkbox for > >"coming in next version", or is that going to far? I'm thinking it is > >too easy to get wrapped up in "forward looking statements" by having > >"coming soon". > >Although I feel that Mason would do adequately in a feature >comparison, I have to say that feature checklists scare me. The reason >that they're most often seen in ads and back-of-the-box marketing >blurbs is their potential for deception: > >(1) the set of features you choose, no matter how impartial, >bias the results >(2) a binary check value (even three or four check values) >conveys way too little information >(3) in software especially there is a fine distinction between a >feature being "built into" versus "supported by" a product > >Case in point: session handling. I grind my teeth everytime I hear that >"Mason doesn't have built-in session handling". Right, and it doesn't have >built-in arithmetic processing either. It relies on Apache::Session and the >Perl interpreter, respectively, for these features. > >Yet I've often been tempted, for marketing purposes, to add a >"use_session" option to Mason that simply brings in Apache::Session with >a few lines of glue code, so I could boast built-in session handling. If I >were selling a product I'm sure I'd do this. One of the reasons I like the >open source world is that I don't have to resort to this level of chicanery. > >I guess I'm just cautioning the makers of this feature list to choose >the display format carefully so as to minimize information loss. > >Maybe each template package should get one page with standardized >format and questions (what features do you have, what are your system >and memory requirements, what does a sample page look like, etc.). >That way people could flip back and forth through the pages and get a >sense of comparison, and the authors would get to focus on what they >consider most important. > >Jon >
Re: Apache::Session upgrade problems and Inheritance
You may need to add LockDataSource, LockUserName and LockPassword to your
$dbinfo hashref. This fixed the problem for us when we upgraded to the
later Apache::Session.
Dave
On Wed, Aug 02, 2000 at 12:17:57PM -0400, Ilia Lobsanov wrote:
> I just upgraded from Apache::Session 1.03 to 1.52, resulting in breaking all
> our dependent code.
>
> The problem is that we use our own package which inherits Apache::Session as
> follows:
>
> ---
> package MPL::NullSession;
>
> use strict;
> use vars qw(@ISA $VERSION);
>
> $VERSION = '1.00';
> @ISA = qw(Apache::Session::MySQL); # was Apache::Session
>
> use Apache::Session;
> use Apache::Session::NullLocker;
> use Apache::Session::MySQL; # was Apache::Session::DBIStore
>
> sub get_object_store {
> my $self = shift;
>
> return new Apache::Session::MySQL $self;
> # was Apache::Session::DBIStore
> }
>
> sub get_lock_manager {
> my $self = shift;
>
> return new Apache::Session::NullLocker $self;
> }
>
> # yay
> 1;
> ---
>
> We tie using:
> tie %session, 'MPL::NullSession', $self->{SESSION_ID}, $dbinfo
> -where $dbinfo is a hashref
>
> This no longer works and here's the error message from Apache:
>
> Can't connect( HASH(0x86e338c)), no database driver specified and DBI_DSN
> env var not set at
> /usr/lib/perl5/site_perl/5.005/Apache/Session/Lock/MySQL.pm line 36
>
> Any help is appreciated. Please reply to my email address as well.
>
> Thank you.
>
--
- Dave Baker : [EMAIL PROTECTED] : http://dsb3.com/ : AIM#duirwyrd -
GPG: 1024D/D7BCA55D / 09CD D148 57DE 711E 6708 B772 0DD4 51D5 D7BC A55D
PGP signature
Re: Why do variables not reinitialize when script changed?
The perl interpreter has a one global symbol table called the stash where all global variables are referenced by package and by variable name. Since the interpreter does not go away when a script is recompiled, neither does the stash or any of the items contained within it. Some programmers are probably using this as a feature, and therefore it is unlikely that it will change. This is really standard perl stuff and it has nothing to do with Apache::Registry in particular. It is just something the average perl programmer does not come across since we usually load the interpreter, load a program, run the program, exit the interpreter. check out: http://thingy.kcilink.com/modperlguide/porting/Global_Variables_Persistence.html hth, -- ___cliff [EMAIL PROTECTED]http://www.genwax.com/ "Keith G. Murphy" wrote: > This is probably a very basic question, understood by everyone but... > > Why, when I change a script loaded under Apache::Registry, and the > script (verifiably) reloads, do global variables not reinitialize? > > I'm running Apache 1.3.9, mod_perl 1.21 on a Debian GNU/Linux system. > > Am I the only one that finds it odd that the variables hang around > unchanged when the script that they pertain to is recompiled? > > Perhaps this is stated or implied in the documentation; I didn't see it.
disregard RE: Apache::Session upgrade problems and Inheritance
Please disgregard this problem as I have fixed it.
I apologise for any inconvenience.
ilia.
> -Original Message-
> From: Ilia Lobsanov [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, August 02, 2000 12:18 PM
> To: [EMAIL PROTECTED]
> Subject: Apache::Session upgrade problems and Inheritance
>
>
> I just upgraded from Apache::Session 1.03 to 1.52, resulting in
> breaking all our dependent code.
>
> The problem is that we use our own package which inherits
> Apache::Session as follows:
>
> ---
> package MPL::NullSession;
>
> use strict;
> use vars qw(@ISA $VERSION);
>
> $VERSION = '1.00';
> @ISA = qw(Apache::Session::MySQL); # was Apache::Session
>
> use Apache::Session;
> use Apache::Session::NullLocker;
> use Apache::Session::MySQL; # was Apache::Session::DBIStore
>
> sub get_object_store {
> my $self = shift;
>
> return new Apache::Session::MySQL $self;
> # was Apache::Session::DBIStore
> }
>
> sub get_lock_manager {
> my $self = shift;
>
> return new Apache::Session::NullLocker $self;
> }
>
> # yay
> 1;
> ---
>
> We tie using:
> tie %session, 'MPL::NullSession', $self->{SESSION_ID}, $dbinfo
> -where $dbinfo is a hashref
>
> This no longer works and here's the error message from Apache:
>
> Can't connect( HASH(0x86e338c)), no database driver specified
> and DBI_DSN env var not set at
> /usr/lib/perl5/site_perl/5.005/Apache/Session/Lock/MySQL.pm line 36
>
> Any help is appreciated. Please reply to my email address as well.
>
> Thank you.
Why do variables not reinitialize when script changed?
This is probably a very basic question, understood by everyone but... Why, when I change a script loaded under Apache::Registry, and the script (verifiably) reloads, do global variables not reinitialize? I'm running Apache 1.3.9, mod_perl 1.21 on a Debian GNU/Linux system. Am I the only one that finds it odd that the variables hang around unchanged when the script that they pertain to is recompiled? Perhaps this is stated or implied in the documentation; I didn't see it.
Re: Mason vs. Apache::Registry
[EMAIL PROTECTED] (Kelly White) wrote: >I am considering using either HTML::Mason or Apache::Registry for my CGI >scripts, but am not sure which is faster. Would the template/pages be cached >like the scripts are in Registry? Which would be faster? Obviously using >Mason would make cleaner code, but it wouldn't get compiled, would it? Any >help you can give is appreciated. Thanks, Under Mason: * Yes, the templates (components) are cached, both on disk and in memory. * Yes, components are pre-compiled into Perl subroutines. * In addition, there's a fairly comprehensive cache control system that lets you control caching of certain parts of the output based on whatever parameters you need. Mason can still be slower than Registry, but that's because Mason does more for you. It's a whole framework. It can also be faster than Registry if you take advantage of its advanced caching stuff (and if it would have been too much hassle to do something similar under Registry). Just like Perl can often be faster than C because writing the equivalent C can be too much hassle.
Re: Feature sets [was Re: Templating System]
Matt Sergeant wrote: > > On Tue, 1 Aug 2000, Drew Taylor wrote: > > > Bill Moseley wrote: > > > > > > It seems as if there needs to be a general templating mailing list... > > > > > > Here I have a comment about comparing template systems, and then I solicit > > > advice on which system to use... > > > > > > > Bill, > > > > After all the response the thread generated, I wonder if perhaps we > > (meaning the people who have control over those things :-) really > > _should_ setup another list. > > Look at the history of this list: it often gets very bursty and the quiet > again. I think setting up a perl-template mailing list would be initially > heavily trafficed, but be pretty much dead in a few weeks (or days even). I'd agree. The list tends to hit a raw never and trafic goes up alot and then its quite again. I would like to see discussion here as long as its relevant. Greg Cope > -- > > > Fastnet Software Ltd. High Performance Web Specialists > Providing mod_perl, XML, Sybase and Oracle solutions > Email for training and consultancy availability. > http://sergeant.org | AxKit: http://axkit.org
Re: Is there a module for getting / setting a Session-ID
[EMAIL PROTECTED] wrote: > > In a message dated 7/30/00 7:33:41 AM Eastern Daylight Time, > [EMAIL PROTECTED] writes: > > > > And, on top of that, I have emilinated session hijacking > > > (with a Back Button Breaking method). > > > > Can you enlighten me ? > > A security method that will redirect the user to a relogin page if, for > instance, > they hit the browser's back button and then use navigation on the old pages. > > Basically, while in a regular area, the links might be > http://192.168.1.100/cmp/about/about.html > and in the secure area there is a "?key=af65235cd773ae986" > tacked on the end. > Keys are transmitted over HTTPS only. > The key is transformed for each page request. > > Once the key is added to the links, it is mandatory to be returned. > If it isn't the user is directed to reenter their password. > > I've mapped out all the possibilites, and this method prevents any > serious bad effects from session hijacking, while leaving much of the site > free from slow HTTPS connections. > > However, just like anywhere, if someone steals your plaintext cookie > or you send them the link with your Url munge in it, they can add > things to your shopping cart. However, and importantly, while > the user is in the secure area, the shopping cart is locked down, so > unless they have your password also, you never have to buy any of it. Thanks for that. Greg
[Fwd: "5.6.0 broke all over" - please elaborate]
forwarding from p5p. i am not running 5.6.0, but i assume that 5.6.0 is stable with mod_perl 1.24? let me know and i will reply back to p5p. Michael Fowler wrote:. > The other problem was a mod_perl installation causing Apache children to > continually seg fault (this was a Slackware 7.1 machine); I'm not sure if it > was mod_perl 1.23, or Perl 5.6.0, an interaction between them, or an > interaction between them and any modules loaded into the system. -- ___cliff [EMAIL PROTECTED]http://www.genwax.com/
Mason vs. Apache::Registry
I am considering using either HTML::Mason or Apache::Registry for my CGI scripts, but am not sure which is faster. Would the template/pages be cached like the scripts are in Registry? Which would be faster? Obviously using Mason would make cleaner code, but it wouldn't get compiled, would it? Any help you can give is appreciated. Thanks, mckhendry __ Do You Yahoo!? Kick off your party with Yahoo! Invites. http://invites.yahoo.com/
RE: Client filehandle?
> -Original Message- > From: Douglas Wilson [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, August 02, 2000 3:24 PM > To: Todd Caine; mod_perl > Subject: RE: Client filehandle? > Maybe (and I mean MAYBE): > local *STDOUT = \*$r; And of course, that should have been (hey I'm making it up & learning as I go along): local *STDOUT = $r; HTH, Douglas Wilson
RE: Client filehandle?
> -Original Message-
> From: Todd Caine [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, August 02, 2000 1:30 PM
> To: mod_perl
> Subject: Client filehandle?
>
>
> I've got a Perl Module which has a function called
> RRDs::graph($args), that will only print to stdout. In my
> handler I write something similar to:
>
> sub handler {
> my $r = shift;
>
> # I want the output to go to the client, ($r->print()),
> but instead it will only go to STDOUT
> So I was trying something like:
>
> *STDOUT = \*r{IO};
Maybe (and I mean MAYBE):
local *STDOUT = \*$r;
HTH,
Douglas Wilson
Re: Feature sets [was Re: Templating System]
> "Ron" == Ron Pero <[EMAIL PROTECTED]> writes: Ron> A few days ago I sent this suggestion to Drew Taylor, who is Ron> preparing a web page comparing the templating systems. He said he Ron> likes the idea. The Categorical "Congratulations: you wrote a Ron> templating system!" web memorial. Wow, if making suggestions here gets that kind of immediate results, let me also suggest I need a girlfriend who is travel-compatible and email friendly. Maybe one will show up. :) Or do you get only one wish per quarter? :) -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: Client filehandle?
darren chamberlain wrote:
> Todd Caine ([EMAIL PROTECTED]) said something to this effect:
> > I've got a Perl Module which has a function called
> > RRDs::graph($args), that will only print to stdout. In my
> > handler I write something similar to:
>
> STDOUT is where $r->print goes under mod_perl; you should be OK.
The data that is printed out via $r->print is on the file descriptor that the
http request is set up on. If the HTTP request came in on file descriptor 3
then $r->print('foo') prints to file descriptor 3; not stdout(file descriptor
1, on my system).
>
>
> Failing this, does RRDs::graph print explicitly to STDOUT, or just to
> the currently selected filehandle? If the latter (it probably is),
> just select a a different filehandle, and then call &graph.
>
RRDs::graph is perl wrapper for the RRDTool utility written in C. It
explicitly prints to 'stdout'. I've tried selecting on a different file
descriptor like this:
my $c = $r->connection;
my $fd_num = $c->fileno(0);
select($fd_num);
And I get "The document contained no data".
The only way I can get part of gif to the browser was to do this:
my $c = $r->connection;
my $fd_num = $c->fileno(0);
open(STDOUT, ">&$fd_num");
RRDs::graph($args);
But the data is incomplete. Even when I autoflush the $fd_num.
There has got to be a better way.
Thanks for your thoughts,
Todd
>
> (darren)
>
> --
> Without deviation from the norm, 'progress' is not possible. -- Frank Zappa
--
--
--
Re: Client filehandle?
Todd Caine ([EMAIL PROTECTED]) said something to this effect: > I've got a Perl Module which has a function called > RRDs::graph($args), that will only print to stdout. In my > handler I write something similar to: STDOUT is where $r->print goes under mod_perl; you should be OK. Failing this, does RRDs::graph print explicitly to STDOUT, or just to the currently selected filehandle? If the latter (it probably is), just select a a different filehandle, and then call &graph. (darren) -- Without deviation from the norm, 'progress' is not possible. -- Frank Zappa
Client filehandle?
I've got a Perl Module which has a function called
RRDs::graph($args), that will only print to stdout. In my
handler I write something similar to:
sub handler {
my $r = shift;
# I want the output to go to the client, ($r->print()),
but instead it will only go to STDOUT
RRDs::graph($args);
return OK;
}
So I was trying something like:
*STDOUT = \*r{IO};
hoping that:
RRDs::graph would print to the socket instead of stdout.
Is there anyway to access the clients file descriptor?
Thanks in advance
Todd
--
--
--
Re: [OT]Expect Problem
hi, yes that is absolutely;-)) correct but it can bite back too. the guy that asked the expect question i was assumng did not know about that and might just delete something he shouldn't .. this is way OT but best bet is to ensure that you have aliased rm -f so that if you screwed up well no problem.. their in $HOME/mytemp or something like that.. with interact he can see exactly what the program is returning to expect_user per se. hmm.. last time i tried Expect.pm well it was still fairly new so i imagine lots more of the programs Expect has have been ported over to the perl module. b.t.w. what commands does Expect.pm provide now from Expect.. > You could probably just do 'rm -f ...', too. > That should override prompts Best Regards, [EMAIL PROTECTED]
mod_perl and the tied interface
hi, i'm using the Tie::DBI interface under some embperl/mod_perl modules, and, worried about the implications of tying under mod_perl, happily found Doug as one of the coders/authors of perltie. hopefully, Doug's reading and/or someone else can tame my fears. I'm tying a hash with Tie::DBI in a sub, and then returning a ref to that hash, so the tied thing can be used. I somehow expect the hash to be automagically untied when it goes out of scope, so as far as it doesn't get trapped inside any persistent var (such as a global or avar inside a closure) I won't be leaking memory nor keeping database connections open. I just want to sleep easy knowing I'm not doing something horribly wrong. Of course, I'm paying with cpu cycles and ram my terrible lazyness, I know that. But I won't trade no short term nap for nights awake because of a crashing/leaking server... as far as I can manage it of course. martin
Re: Expect Problem
--- dreamwvr <[EMAIL PROTECTED]> wrote: > hi Ron, > well here is one suggestion that i am not really certain > that > the expect.pm handles .. but if you can try to insert 'interact' to > see what prompts rm wants on the other side as remember that > you need to expect from process the prompt for y or no and then send > a reply.. > Best Regards, > [EMAIL PROTECTED] You could probably just do 'rm -f ...', too. That should override prompts __ Do You Yahoo!? Kick off your party with Yahoo! Invites. http://invites.yahoo.com/
RE: [ANNOUNCE] Apache::Dispatch-0.02
> > -Original Message-
> > From: Matt Sergeant [mailto:[EMAIL PROTECTED]]
> > Sent: Tuesday, August 01, 2000 9:46 AM
> > To: Geoffrey Young
> > Cc: '[EMAIL PROTECTED]'
> > Subject: Re: [ANNOUNCE] Apache::Dispatch-0.02
> >
> >
> >
> > You're gonna hate me for this...
> >
> > Can you add pre and post methods for the dispatching? It
> > would be really
> > useful to be able to (for example) save and restore
> $SIG{__DIE__}, and
> > maybe other things like that, rather than having to
> > explicitly remember to
> > call them yourself.
>
> ok, I'll work on adding pre_dispatch() and post_dispatch()
> (and possibly
> dispatch_error) calls to the existing framework and see what
> I can come up
> with...
>
> --Geoff
>
well, I wasn't able to get that functionality into the existing design, but
that's ok because I wasn't too happy with it anyway :)
http://morpheus.laserlink.net/~gyoung/modules/Apache-Dispatch-0.03.tar.gz
is the new version. I haven't uploaded it yet because I wanted to ask
anyone interested whether they are terribly upset that the API will be
changing and Apache::Dispatch won't support per-server handler calling.
Basically, you'll still need at least one , since in
order to get pre and post processing in, we had to move to PerlHandler from
PerlFixupHandler.
anyway, here's the new README. I think the code generally cleaner than what
came before, so I'll upload it later in the week if nobody speaks up and
objects :)
--Geoff
NAME
Apache::Dispatch - call PerlHandlers with the ease of CGI scripts
SYNOPSIS
httpd.conf:
PerlModule Apache::Dispatch
PerlModule Bar
SetHandler perl-script
PerlHandler Apache::Dispatch
DispatchPrefix Bar
DispatchExtras Pre Post Error
DESCRIPTION
Apache::Dispatch translates $r->uri into a class and method and runs
it as a PerlHandler. Basically, this allows you to call PerlHandlers
as you would CGI scripts - directly from the browser - without having
to load your httpd.conf with a slurry of tags.
EXAMPLE
in httpd.conf
PerlModule Apache::Dispatch
PerlModule Bar
SetHandler perl-script
PerlHandler Apache::Dispatch
DispatchPrefix Bar
DispatchExtras Pre Post Error
in browser:
http://localhost/Foo/baz
the results are the same as if your httpd.conf looked like:
SetHandler perl-script
PerlHandler Bar::dispatch_baz
This configuration offers additional security by protecting the
class from the browser and keeping the method name from being
called directly. Because any class under the Bar:: hierarchy can be
called, one directive is able to handle all the methods
of Bar, Bar::Baz, etc...
CONFIGURATION DIRECTIVES
DispatchPrefix
Applies on a per-location basis only. The base class to be
substituted for the $r->location part of the uri.
DispatchExtras
A list of extra processing to enable per-request. They may be
applied on a per-server or per-location basis. If the main
handler is not a valid method call, the request is declined prior
to the execution of any of the extra methods.
Pre - eval()s Foo->pre_dispatch() prior to dispatching the uri
uri. The $@ of the eval is not checked in any way.
Post - eval()s Foo->post_dispatch() prior to dispatching the
uri. The $@ of the eval is not checked.
Error - If the main handler returns other than OK then
Foo->error_dispatch() is called and return status of it
is returned instead. Without this feature, the return
status of your handler is returned.
SPECIAL CODING GUIDELINES
Apache::Dispatch uses object oriented calls behind the scenes. This
means that you either need to account for your handler to be called
as a method handler, such as
sub dispatch_bar {
my $class = shift; # your class
my $r = shift;
}
or get the Apache request object yourself via
sub dispatch_bar {
my $r = Apache->request;
}
NOTES
In addition to the special methods pre_dispatch(), post_dispatch(),
and error_dispatch(), if you define dispatch_index() it will be called
if the method is empty (eg, by /Foo or /Foo/).
There is no require()ing or use()ing of the packages or methods prior
to their use as a PerlHandler. This means that if you try to dispatch
a method without a PerlModule directive or use() entry in your
startup.pl you probably will not meet with much success. This adds a
bit of security and reminds us we should be pre-loading that code in
the parent process anyway...
If the uri can be dispatched but contains anything other than
[a-zA-Z0-9_/-] Apache::Dispatch declines to handle the request.
Like everything in perl, the package names are case sensitive.
Verbose debugging is enabled by setting $Apache::Dispatch::DEBUG=1.
Very verbose debugging is enabled at 2. To turn off all debug
information set your apache LogLevel directive above info level.
This is alpha
Re: Feature sets [was Re: Templating System]
>Maybe we should have a "Congratulations: you wrote a templating >system!" web memorial. :) > >One brief serious note: I think the fact that there are SO MANY is a >tribute to just how easy it is to process text in Perl. I don't think >there are 47 templating system for Java. :) > A few days ago I sent this suggestion to Drew Taylor, who is preparing a web page comparing the templating systems. He said he likes the idea. The Categorical "Congratulations: you wrote a templating system!" web memorial. * Place the templating systems into a spectrum of categories, from simplest to most complex/developed. It would look approximately like this (not attempting to be complete): -Level one, simplest * Simple tag/anchor replacement * Embedded code evaluation -Level two, complete templating, but templating only * HTML::Template * Template Toolkit * HTML - Tree (??) -Level three, templating plus (added features such as session management, database integration, etc.) * Apache::ASP * Embperl * HTML::Mason * AxKit Ron At 06:32 AM 08/02/00 -0700, Randal L. Schwartz wrote: >> "Eric" == Eric Cholet <[EMAIL PROTECTED]> writes: > >>> Hi there, >>> >>> I have a pure perl implementation of a simple templating system which is >>> (what I consider to be) relatively lightweight - it copes well in both >>> cgi-bin and mod_perl environments, at least for me. I've looked at various >>> other modules, and do believe mine brings an alternative slant to the >>> proceedings 8) > >[...] > >Eric> This looks very similar to HTML::Template: > >[...] > >I think it's a rite of passage to look at all the templating systems, >and decide "I can do better, along axis $X", and write your own. Then >you discover after a while that: > >a) writing templating systems is no fun the moment you let someone > else start using it, because they want feature $Y which you thought > nobody would need > >b) you understand why that other package was so fat > >:-) > >Maybe we should have a "Congratulations: you wrote a templating >system!" web memorial. :) > >One brief serious note: I think the fact that there are SO MANY is a >tribute to just how easy it is to process text in Perl. I don't think >there are 47 templating system for Java. :) > >-- >Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 ><[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/> >Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. >See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training! > >
Re: Storable.pm problem
BeerBong wrote:
>
> Hello Joshua!
>
> I returned from vacation and now see that you produced some new versions of
> Apache::ASP.
> As I understand main enchantments are XML stuff and now question - if I
> upgrade to version 2 on my production server this will cause to slow down of
> processing ? I don't have in plans use XML now.
>
Hey Sergey,
Sure, as long as you don't set XMLSubsMatch or XSLT, you won't
turn the XML features on, and there will be no performance hit.
> ---
> [Tue Aug 1 17:12:45 2000] [error] [asp] [7465] [error] cannot load Storable
> for StateSerializer: cannot load StateSerializer must be a valid serializing
> perl module for use with MLDBM such as Data::Dumper (default), or Storable;
> , /usr/local/lib/site_perl/Apache/ASP.pm line 2346
> [Tue Aug 1 17:12:45 2000] [error] deferred at
> /usr/local/lib/site_perl/MLDBM.pm line 30
>
> MLDBM::Serializer::deserialize('MLDBM::Serializer::Storable=HASH(0x8a756d0)'
> , undef) called at /usr/local/lib/site_perl/MLDBM.pm line 155
Also upgrade your Storable to the latest, which might help,
as it seems that your Storable does not have a deserializer
method. I just checked the latest Storable and it was working
just fine. This might have something to do with the library
not loading correctly, make sure that your perl & modperl
are the same that have Storable.
-- Joshua
_
Joshua Chamas Chamas Enterprises Inc.
NodeWorks >> free web link monitoring Huntington Beach, CA USA
http://www.nodeworks.com1-714-625-4051
RE: was Re: template kit..... - now session handling
On Wed, 2 Aug 2000, Jeffrey W. Baker wrote: > 2) The name change should happen. However, there is already a > Persistent:: set of classes, that is somewhat similar to Apache::Session. > For example, it implements LDAP, MySQL, Oracle, Sybase, mSQL, and File > storage. These classes use all object calls > e.g. $persistent->add_attribute(). So the chief difference seems to be > the flexibility of the tied interface of Apache::Session (also mine is > faster :) So how does Persistent::TiedHash sound? I was about to say Tie::Persistent, but that's taken too... Personally I use the object methods, but I think Persistent::TiedHash is fine. - Perrin
RE: Expect Problem
You've got the wrong mailing list. This list is for the discussion of the
mod_perl Apache module. You probably want to contact the module author or try
comp.lang.perl.misc or comp.lang.perl.modules or comp.lang.perl.moderated. Or
maybe even www.perlmonks.org.
On 02-Aug-2000 [EMAIL PROTECTED] wrote:
> I'm using the Expect module to perform some shell commands to automate some
> processing, but for some reason I'm not able to perform an "rm" function as
> I would from a shell prompt. All I want to do is to delete all of the files
> in the directory without a prompt or without using a recursive option. The
> command I would like to execute would be like the following shell command
> for a remove of all files starting with I*, i*, x*, y*, etc. The command
> that I would normally use would be rm /directory/[Iixy]* and this works. I
> have the same code included in my script, yet the "rm" doesn't seem to want
> to execute. Note that the before buffer contains the copy and the "rm".
>
> The files get copied without any problem and I can substitute the rm with
> another command and it seems to execute. Why is "rm" any different?
>
> Any suggestions, comments or other would be greatly appreciated.
>
>
>
> Sample Code:
> print "\n Start of the copy process $TFTPCopy --> $BackupDirectory \n\n";
> $command->debug(2); unless ($InvalidSwitch){ # Copy the files
> $CopyMembers=$TFTPCopy."[Iixyz]*";
> print $command "cp $CopyMembers $BackupDirectory\n";
> unless ($command->expect(undef,">>>")){ # Copy failed
>
> print " ** \">>>\" copy failed \n";
> print " BACKUP FAILED\n ";
> die "FATAL Error $TFTPServer";
> }
> }
> print "\n Delete All $CopyMembers in the $TFTPCopy directory \n ";
> print " execute the command rm $CopyMembers \r\n\r";
> unless ($InvalidSwitch){ # Copy the files
> print $command "rm $CopyMembers\n"; # Set the enable
> unless ($command->expect(undef,">>>")){ # Copy failed
>$PrintMsg1= "** Delete of members failed \n";
> $PrintMsg2= "Delete of the files in the $TFTPCopy Failed \n";
> PrintFailure(); # Print Failure Routine
>die "FATAL Error $TFTPServer";
> PrintFailure(); # Print Failure Routine
> }
> }
> PrintFailure(); # Print Failure Routine
> }
>
> "Killed after the delete \n";} # End of the CopyToBackup
>
>
> Diagnostic Display :
>
> shvop701>>>shvop701>>> Start of the copy process /home/tftpuser/ -->
> /tmp/tftpbackup Beginning expect from spawn id(5).
> Accumulator: 'shvop701>>>'
> Expect timeout time: unlimited seconds.
> expect: Pty=spawn id(5), time=965236546, loop_time=undef
> Matched pattern 1 ('>>>')!
> Before match string: 'shvop701'
> Match string: '>>>'
> After match string: ''
> Returning from expect successfully.
> Accumulator: ''
> Delete All /home/tftpuser/[Iixyz]* in the /home/tftpuser/ directory
> execute the command rm /home/tftpuser/[Iixyz]*
> Beginning expect from spawn id(5).
> Accumulator: ''
> Expect timeout time: unlimited seconds.
> expect: Pty=spawn id(5), time=965236546, loop_time=undef
> expect: handle spawn id(5) ready.
> expect: read 44 byte(s) from spawn id(5).
> cp /home/tftpuser/[Iixyz]* /tmp/tftpbackup
> expect: handle spawn id(5) ready.
> expect: read 28 byte(s) from spawn id(5).
> rm /home/tftpuser/[Iixyz]*
> expect: handle spawn id(5) ready.
> expect: read 11 byte(s) from spawn id(5).
> shvop701>>>Matched pattern 1 ('>>>')!
> Before match string: 'cp /home/tftpuser/[Iixyz]* /tmp/tftpbackup\r\nrm
> /home/tftpuser/[Iixyz]*\r\nshvop701'
> Match string: '>>>'
> After match string: ''
> Returning from expect successfully.
> Accumulator: ''
>
>
> **
> ++ FAILURE of EXPECT + **
> Values of the match(>>>)
>
> Before(cp /home/tftpuser/[Iixyz]* /tmp/tftpbackup
> rm /home/tftpuser/[Iixyz]*
> shvop701)
>
> After() **
>
> Killed before the delete
--
Jason Bodnar + [EMAIL PROTECTED] + Team Linux
Marge: Wow, you can't find this stuff anywhere. Seals and Crofts, Pablo
Cruise, Air Supply, oh, Loggins and Oates...and it's free!
Lisa: I've never heard of these bands, Mom, what kind of music do they
play?
Bart: Crap rock?
Marge: [thinking] No...
Homer: Wuss rock?
Marge: That's it!
Viva Ned Flanders
Re: Expect Problem
hi Ron, well here is one suggestion that i am not really certain that the expect.pm handles .. but if you can try to insert 'interact' to see what prompts rm wants on the other side as remember that you need to expect from process the prompt for y or no and then send a reply.. Best Regards, [EMAIL PROTECTED]
Expect Problem
I'm using the Expect module to perform some shell commands to automate some
processing, but for some reason I'm not able to perform an "rm" function as
I would from a shell prompt. All I want to do is to delete all of the files
in the directory without a prompt or without using a recursive option. The
command I would like to execute would be like the following shell command
for a remove of all files starting with I*, i*, x*, y*, etc. The command
that I would normally use would be rm /directory/[Iixy]* and this works. I
have the same code included in my script, yet the "rm" doesn't seem to want
to execute. Note that the before buffer contains the copy and the "rm".
The files get copied without any problem and I can substitute the rm with
another command and it seems to execute. Why is "rm" any different?
Any suggestions, comments or other would be greatly appreciated.
Sample Code:
print "\n Start of the copy process $TFTPCopy --> $BackupDirectory \n\n";
$command->debug(2); unless ($InvalidSwitch){ # Copy the files
$CopyMembers=$TFTPCopy."[Iixyz]*";
print $command "cp $CopyMembers $BackupDirectory\n";
unless ($command->expect(undef,">>>")){ # Copy failed
print " ** \">>>\" copy failed \n";
print " BACKUP FAILED\n ";
die "FATAL Error $TFTPServer";
}
}
print "\n Delete All $CopyMembers in the $TFTPCopy directory \n ";
print " execute the command rm $CopyMembers \r\n\r";
unless ($InvalidSwitch){ # Copy the files
print $command "rm $CopyMembers\n"; # Set the enable
unless ($command->expect(undef,">>>")){ # Copy failed
$PrintMsg1= "** Delete of members failed \n";
$PrintMsg2= "Delete of the files in the $TFTPCopy Failed \n";
PrintFailure(); # Print Failure Routine
die "FATAL Error $TFTPServer";
PrintFailure(); # Print Failure Routine
}
}
PrintFailure(); # Print Failure Routine
}
"Killed after the delete \n";} # End of the CopyToBackup
Diagnostic Display :
shvop701>>>shvop701>>> Start of the copy process /home/tftpuser/ -->
/tmp/tftpbackup Beginning expect from spawn id(5).
Accumulator: 'shvop701>>>'
Expect timeout time: unlimited seconds.
expect: Pty=spawn id(5), time=965236546, loop_time=undef
Matched pattern 1 ('>>>')!
Before match string: 'shvop701'
Match string: '>>>'
After match string: ''
Returning from expect successfully.
Accumulator: ''
Delete All /home/tftpuser/[Iixyz]* in the /home/tftpuser/ directory
execute the command rm /home/tftpuser/[Iixyz]*
Beginning expect from spawn id(5).
Accumulator: ''
Expect timeout time: unlimited seconds.
expect: Pty=spawn id(5), time=965236546, loop_time=undef
expect: handle spawn id(5) ready.
expect: read 44 byte(s) from spawn id(5).
cp /home/tftpuser/[Iixyz]* /tmp/tftpbackup
expect: handle spawn id(5) ready.
expect: read 28 byte(s) from spawn id(5).
rm /home/tftpuser/[Iixyz]*
expect: handle spawn id(5) ready.
expect: read 11 byte(s) from spawn id(5).
shvop701>>>Matched pattern 1 ('>>>')!
Before match string: 'cp /home/tftpuser/[Iixyz]* /tmp/tftpbackup\r\nrm
/home/tftpuser/[Iixyz]*\r\nshvop701'
Match string: '>>>'
After match string: ''
Returning from expect successfully.
Accumulator: ''
**
++ FAILURE of EXPECT + **
Values of the match(>>>)
Before(cp /home/tftpuser/[Iixyz]* /tmp/tftpbackup
rm /home/tftpuser/[Iixyz]*
shvop701)
After() **
Killed before the delete
Re: [OT] The $64K question/server hardware
I can vouch for that. We had a site running some distance ed software. The *nix version ran like a champ and would stay up and running for months. The NT version? Would require pre-emptive reboots to try and prevent unscheduled system downtimes. Also, the server would just crap out without rhyme or reason - nothing in the logs, no Dr. Watsons, nada. THe only way to bring it back to life would be a reboot because stopping/starting services was ineffective. Jauder Ho wrote: > > One thing to note is that IIS on NT4 leaks memory like mad on a high > volume site so you will have to keep rebooting the boxes. The solution put > in place required both Sun and NT machines and the Sun boxes were > infinitely more stable (even though they were using *ugh* Netscape > Enterprise Server). But IIS on Windows 2000 appears to be much better. >
Apache::Session upgrade problems and Inheritance
I just upgraded from Apache::Session 1.03 to 1.52, resulting in breaking all
our dependent code.
The problem is that we use our own package which inherits Apache::Session as
follows:
---
package MPL::NullSession;
use strict;
use vars qw(@ISA $VERSION);
$VERSION = '1.00';
@ISA = qw(Apache::Session::MySQL); # was Apache::Session
use Apache::Session;
use Apache::Session::NullLocker;
use Apache::Session::MySQL; # was Apache::Session::DBIStore
sub get_object_store {
my $self = shift;
return new Apache::Session::MySQL $self;
# was Apache::Session::DBIStore
}
sub get_lock_manager {
my $self = shift;
return new Apache::Session::NullLocker $self;
}
# yay
1;
---
We tie using:
tie %session, 'MPL::NullSession', $self->{SESSION_ID}, $dbinfo
-where $dbinfo is a hashref
This no longer works and here's the error message from Apache:
Can't connect( HASH(0x86e338c)), no database driver specified and DBI_DSN
env var not set at
/usr/lib/perl5/site_perl/5.005/Apache/Session/Lock/MySQL.pm line 36
Any help is appreciated. Please reply to my email address as well.
Thank you.
Re: [OT] The $64K question/server hardware
Heh, I put in a solution that was MUCH larger. 16 sun servers (14 E420R and 2 E6500s) just in the production environment. Total server count was somewhere in the 60s. One thing to note is that IIS on NT4 leaks memory like mad on a high volume site so you will have to keep rebooting the boxes. The solution put in place required both Sun and NT machines and the Sun boxes were infinitely more stable (even though they were using *ugh* Netscape Enterprise Server). But IIS on Windows 2000 appears to be much better. --Jauder On Wed, 2 Aug 2000 [EMAIL PROTECTED] wrote: > > Can we also include OS ? > > I'm particularly interested in performance figures of NT against *nix to > help my case to ditch NT in a project which has yet to go live. > > Simon Wilcox > Intranet Development Manager > Williams Lea Group > > > > From Ajit Deshpande <[EMAIL PROTECTED]>Date 22:43:28 1 August >2000 > > To: [EMAIL PROTECTED] > cc:(bcc: Simon Wilcox/BASE/WilliamsLea) > Fax to: > Subject: Re: [OT] The $64K question/server hardware > > > > On Tue, Aug 01, 2000 at 02:32:52PM -0700, ___cliff rayman___ wrote: > > [ .. snip .. ] > > Since this has potential for becoming another long thread with people > posting their stories and some other people flaming for not doing things > in a certain way, I have suggestions for this monster thread in the > making: > > 1. Everyone post information in the format at the end of this mail > 2. Send it in a private e-mail to me if confidentiality is a problem >(or pick someone you trust, more than me, and have them e-mail it > to me :) > 3. I will consolidate the information and dash it off to Ask or whoever >maintains the perl.apache.org > > What do ye think? > > Ajit > > Format for posting information: > > 1. Setup : >for example: >- Single modperl server on one host, apache 1.3.12, mod_proxy >- One modperl, one front-end proxy on one host, apache 1.3.12, > mod_perl 1.24 >- Multiple modperl and multiple hosts > > 2. Average hits/day . Peak hits/second. > > 3. CPU details >for example: >- Front end proxy on PII 333 >- Modperl-enabled httpd on PIII 550 >- MySql/Oracle DB on Quad Xeon PIII 550 (Wow! :) > > 4. Memory details: >for example: >- Front end proxy with 128 Mb >- Modperl-enabled httpd with 256 Mb >- MySql/Oracle DB with 2Gb > > 5. Storage details: >for example: >- 10,000 RPM Ultra-wide SCSI discs on all hosts >- Root partition for each server on 1.2 Gb IDE >- Session stuff on NFS mounted NetApp (!) >- D/B disk on EMC sub-system (!) > > 6. Kind of content: >- 70% dynamic, d/b driven, 20% static, 10% images >- All dynamic except images > > 7. Publication of the site: >- http://www.foo.com OR Author does not wish to divulge >- Intranet site, not accessible from public internet >- In production since Aug-99 >- Primary contact : [EMAIL PROTECTED] OR Author does not wish to divulge > > > > >
Re: Feature sets [was Re: Templating System]
Chris,
This sounds precisely like CGI::FastTemplate, which I have used heavily and
like a lot. My other favorite templating system is HTML::Template, but
CGI::FastTemplate is *very* lightweight.
- David
- Original Message -
From: Chris Carline <[EMAIL PROTECTED]>
To: Gunther Birznieks <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Wednesday, August 02, 2000 2:32 AM
Subject: RE: Feature sets [was Re: Templating System]
> Hi there,
>
> I have a pure perl implementation of a simple templating system which is
> (what I consider to be) relatively lightweight - it copes well in both
> cgi-bin and mod_perl environments, at least for me. I've looked at various
> other modules, and do believe mine brings an alternative slant to the
> proceedings 8)
>
> A simple example of it in action (if it were called My::Simple::Template)
> would be:
>
> use My::Simple::Template;
> my $template = new My::Simple::Template;
> $template->tags( { key1 => 'value1', key2 => 'value2' } );
> print $template->generate("/path/to/template.html");
>
> I've been thinking about releasing it for a while (I've just received
> permission from my employer to do so) under the GPL/Artistic license,
> although I'm pretty nervous about the quality of the code (primarily due
to
> having not released anything for public scrutiny before!). I know that
there
> are a few things that could do with a bit of tidying up, however 8)
>
> It's around 300 lines of code (plus docs) and has been tested with perl
> 5.005 (although it should work with earlier versions with a bit of
> fiddling), on under solaris, linux and windows, cgi-bin and mod_perl. I'll
> quite happily supply what I currently have to anyone who's interested.
>
> Synopsis of "main" features:
>
> * in-line insertions with name/value pairs (obviously)
> * loops
> * basic if/else constructs
> * template comments
> * file includes
> * file and database caching of preprocessed templates
> * "loose" expansion of tags
> * "template subroutines" (hard to explain in one line)
>
> Please mail me if you're interested in finding out more
>
> Chris
>
> -Original Message-
> From: Gunther Birznieks [mailto:[EMAIL PROTECTED]]
> Sent: 02 August 2000 09:20
> To: [EMAIL PROTECTED]
> Subject: RE: Feature sets [was Re: Templating System]
>
>
> I have to say that I am also interested in template kits myself.
>
> My requirements are almost identical to yours (minus a few advanced
things).
>
> Basically, I write open source web applications in Perl -- that means that
> they must be able to run reasonably fast on non-modperl systems and must
> run on a variety of ISPs (ie not dedicated servers where you control the
> version of Perl).
>
> Of course, mod_perl support is crucial for those that want to "scale", but
> normal CGI/Perl support is really a biggie that I haven't seen highlighted
> within the context of this thread.
>
> Here are my CGI/Perl requirements:
>
> 1) Must be 100% pure Perl or support pure-Perl alternatives if certain
libs
> arent compiled. Many people who download CGI scripts don't know how to
> compile stuff.
>
> 2) Must support Perl 5.004 and above. Ideal to support Perl 5.003. Enough
> ISPs and corporations around the world are still on 5.004 that only
> supporting the latest Perl version is not doable.
>
> 3) Must incur as minimal load-time as possible. CGI/Perl scripts are not
> cached like mod_perl scripts.
>
> So CGI/Perl people must have a template system that can choose to load a
> minimal amount of code if really advanced features aren't used. IE would
> rather not have a templating system as large as CGI.pm. Or rather it can
be
> as large as CGI.pm, but only if the extra code is loaded when advanced
> features are accessed -- normal CGI/Perl users should not be penalized.
>
> 4) Must have a license that supports redistribution in other scripts. I
> think most of the systems out there do that (maybe all the Perl ones do).
>
> CPAN is great for us, but again, most real-world web app users are not
CPAN
> savvy and don't have the rights to install global modules on their ISP nor
> the learning to install them locally. So an open source web app that takes
> advantage of a template system really should also contain that template
> system. The power users can remove it from the local dir if they have a
> globally installed version of the system.
>
> Anyway, I felt that I should state these feature requirements because this
> list is so mod_perl centric, I think sometimes we forget the "little"
> people. And there are many more of them out there than mod_perl servers
and
> Perl/CPAN savvy people.
>
> And please don't say that they should RTFM. Most users do
> not have time to RTFM. If they did, they would be us. :) These users are
> people who know their business and typically learn just enough tech to
> install something that will help their business -- they don't care or want
> a CS degree in the process.
>
> Later,
> Gunther
>
>
>
Help...
Hi all, A strange behaviour I don't undestand... When using OR requiring MIME::Parser in a mod_perl ( 1.24 ) enabled apache ( 1.3.12 ), I've got many error 'cause perl is looking for Mail::Field::date Mail::Field::attrlist There is errors on compilation, so the first call to the page failafter it works The same script works well in cgi. If I include MIME::Parser on startup of apache errors are, but it works Why perl is looking for date.pm and attrlist.pm instead of Date.pm and Attrlist.pm Can I use MIME::Parser, even if my error_log is dirty Thanks.
Re: (Fwd) Problem with Authen::Krb4 under mod_perl (fwd)
[forwarded just in case anyone else is having similar problems] -- Forwarded message -- Date: Wed, 2 Aug 2000 10:45:35 -0400 (EDT) From: Jeff Horwitz <[EMAIL PROTECTED]> To: Dave Edsall - The Tauminator <[EMAIL PROTECTED]> Subject: Re: (Fwd) Problem with Authen::Krb4 under mod_perl >First, thank you for responding and responding so quickly. The answer to > your question is yes, we are using open_ssl so that we can encrypt the > password being sent to the web server. But, if there are name clashes, why > would the script work under mod_cgi and not mod_perl? We use ssl in both cases. mod_cgi simply forks off separate processes. with mod_perl, the scripts are interpreted and run in a Perl interpreter within apache. Krb4.so is loaded just like any other shared library, and will conflict with apache if duplicate symbols exist. > Is there a way around the name clash problem? yes. build Authen::Krb4 with KTH Kerberos, available at http://www.pdc.kth.se/kth-krb. it's a bit cleaner wrt the DES library, and it's much easier to build as well! :) --- Jeff Horwitz E-mail: [EMAIL PROTECTED] Manager of Systems OperationsPhone: (610) 627-4575 LaserLink.Net, Covad Communications Web: http://www.laserlink.net On Wed, 2 Aug 2000, Dave Edsall - The Tauminator wrote: > > >are you using mod_ssl or SSL of any kind? there are name clashes between > >the kerberos DES libraries and the SSL DES libraries that can cause > >kerberos to fail. > > > > > > > Dave > > >
Re: Feature sets [was Re: Templating System]
Drew Taylor wrote: >Ken Williams wrote: >> >> I suggest having not just a simple checkmark, but a 3-way check. A >> system either supports a feature, or it doesn't, or it *optionally* >> supports it (can be switched on and off). This is often very helpful to >> know, and might let one get a good sense of the differences between >> various systems at a glance. >Another great idea! Should we go one farther and have a checkbox for >"coming in next version", or is that going to far? I'm thinking it is >too easy to get wrapped up in "forward looking statements" by having >"coming soon". Although I feel that Mason would do adequately in a feature comparison, I have to say that feature checklists scare me. The reason that they're most often seen in ads and back-of-the-box marketing blurbs is their potential for deception: (1) the set of features you choose, no matter how impartial, bias the results (2) a binary check value (even three or four check values) conveys way too little information (3) in software especially there is a fine distinction between a feature being "built into" versus "supported by" a product Case in point: session handling. I grind my teeth everytime I hear that "Mason doesn't have built-in session handling". Right, and it doesn't have built-in arithmetic processing either. It relies on Apache::Session and the Perl interpreter, respectively, for these features. Yet I've often been tempted, for marketing purposes, to add a "use_session" option to Mason that simply brings in Apache::Session with a few lines of glue code, so I could boast built-in session handling. If I were selling a product I'm sure I'd do this. One of the reasons I like the open source world is that I don't have to resort to this level of chicanery. I guess I'm just cautioning the makers of this feature list to choose the display format carefully so as to minimize information loss. Maybe each template package should get one page with standardized format and questions (what features do you have, what are your system and memory requirements, what does a sample page look like, etc.). That way people could flip back and forth through the pages and get a sense of comparison, and the authors would get to focus on what they consider most important. Jon
RE: was Re: template kit..... - now session handling
>2) The name change should happen. However, there is already a >Persistent:: set of classes, that is somewhat similar to >Apache::Session. >For example, it implements LDAP, MySQL, Oracle, Sybase, mSQL, and File >storage. These classes use all object calls >e.g. $persistent->add_attribute(). So the chief difference seems to be >the flexibility of the tied interface of Apache::Session (also mine is >faster :) So how does Persistent::TiedHash sound? Hooray! >3) The Apache::Session name whould be used for a module that actually >manages the interaction between mod_perl and the browser. The only >problem I can see is that this module would have to start out at 2.0 or >something, to avoid confusing CPAN. ALternately, it could be called >Apache::SessionManager instead. It could also be called Apache::Persistant ?
RE: was Re: template kit..... - now session handling
On Mon, 31 Jul 2000, brian moseley wrote: > On Mon, 31 Jul 2000, Perrin Harkins wrote: > > > Since it isn't really tied to HTTP or sessions, that > > would be kind of a misnomer as well. Jeff already > > suggested Persistent::Hash at once point, but changing > > namespace on CPAN always confuses some people. There > > are still people who get confused about the original > > Apache::Session module that was replaced by Jeff's. > > people who get confused by name changes should not be > catered to. I wasn't following this thread, because the subject was "template kit." Now I shall reply all in one shot. 1) A cookie/token management module will *not* be built into Apache::Session. The functionality is orthogonal. (i.e. Gerald is right). 2) The name change should happen. However, there is already a Persistent:: set of classes, that is somewhat similar to Apache::Session. For example, it implements LDAP, MySQL, Oracle, Sybase, mSQL, and File storage. These classes use all object calls e.g. $persistent->add_attribute(). So the chief difference seems to be the flexibility of the tied interface of Apache::Session (also mine is faster :) So how does Persistent::TiedHash sound? 3) The Apache::Session name whould be used for a module that actually manages the interaction between mod_perl and the browser. The only problem I can see is that this module would have to start out at 2.0 or something, to avoid confusing CPAN. ALternately, it could be called Apache::SessionManager instead. -jwb
Fwd: [Zope-Perl] zope-perl-0.1.a1.tar.gz
I thought this might interest some of you. >You should now be able to find the first alpha release of Perl for >Zope on ActiveState's ftp server. This server currently has some >problems with passive ftp. If you get "No route to host" errors, then >you need to use a client that can connect in active mode. I hope this >bug will go away soon. > >Anyway, the full URL to this release is: > > ftp://ftp.ActiveState.com/Zope-Perl/zope-perl-0.1.a1.tar.gz > >The perl/python glue code is released under the Perl licence. The >Zope products for enabling PerlExternalMethod and ZDBI_DA are derived >from Zope code and use the Zope licence. > >I have only built this release on Linux. Ports to other systems have >not been attempted yet. Reports on what works and what works not so >well welcomed. Patches that fix problems even more welcomed :-) > >Enjoy! > >Regards, >Gisle Aas > >___ >Zope-perl maillist - [EMAIL PROTECTED] >http://lists.zope.org/mailman/listinfo/zope-perl -- robin b. Don't try to outweird me, three-eyes. I get stranger things than you free with my breakfast cereal. -- Zaphod Beeblebrox
[crazy idea?] Re:Templating System
I hope you guys get the general idea of what I am about to say... Perl6 is (barely) underway. Perl is the ubiquituos and, some would say, premiere, web language. format (and format_top) are possibly going to be pushed out of the core. I imagine the reasons are that formats are much less utilized nowadays. Any chance in heck that the format could be re-written into a HTML templater? -JoshNarins __END__ Afterthoughts... obviously, $- is no longer needed, which is great, since I always had to hack around it anyway. It needs to support loops It should support external template files. I think caching should not be included. I think having this as part of the core of perl makes sense (because 90%[guess] of perl scripts are for the web). X(your letters here) support should be transparent(?) I think I'd feel great if I helped make this happen.
Re: Feature sets [was Re: Templating System]
Randal Schwartz <[EMAIL PROTECTED]> writes: >One brief serious note: I think the fact that there are SO MANY is a >tribute to just how easy it is to process text in Perl. I don't think >there are 47 templating system for Java. :) > Couldn't agree more. Sometimes Perl is too easy/powerful for its own good. It probably takes less time and effort for any decent Perl hacker to write his/her own simple customized templating system than to download, install, and understand an existing system, not to mention evaluate several systems. Obviously, we need to add strong typing or something to slow people down. :) Jon
Re: mod_perl success!
No, it is no problem.
I have run it.
You can test it.
- Original Message -
From: "Razvan Ionescu" <[EMAIL PROTECTED]>
To: "Razvan Ionescu" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, August 03, 2000 10:46 PM
Subject: Re: mod_perl success!
> ups again, i meant $key
>
> a working code for this "keys" loop would be
>
> foreach $key (sort(keys %ENV)) {
>
> print "$key = $ENV{$key}\n";
> }
>
> anyway you can write it shorter but you'll have problems when debuging.
>
> Razvan
>
> > - Original Message -
> > From: "yusun" <[EMAIL PROTECTED]>
> > To: "Andrew Chen" <[EMAIL PROTECTED]>
> > Cc: <[EMAIL PROTECTED]>
> > Sent: Wednesday, August 02, 2000 3:50 PM
> > Subject: Re: mod_perl success!
> >
> >
> > > I have installed the mod_perl and changed the httpd.conf as you said.
> > > But when I used the following CGI to test whether the mod_perl was
> working
> > > or not.
> > > The report was no. Why?
> > >
> > > #!/usr/bin/perl
> > > print "Content-type: text/plain\n\n";
> > > print "Server's environment\n";
> > > foreach ( keys %ENV ) {
> > > print "$_\t$ENV{$_}\n";
> > > }
> > > #
> > >
> > > The result is
> > > :
> > > :
> > > GATEWAY_INTERFACE CGI/1.1
> > > :
> > >
> > > It means that I have configured this location to run under mod_cgi and
> not
> > > mod_perl.
> > > How can I configure the location to run under mod_perl?
> > > Thanks!
> > >
> > >
> > > Yu Sun
> > > [EMAIL PROTECTED]
> > >
> > >
> > > - Original Message -
> > > From: "Andrew Chen" <[EMAIL PROTECTED]>
> > > To: "Pramod Sokke" <[EMAIL PROTECTED]>
> > > Cc: <[EMAIL PROTECTED]>
> > > Sent: Wednesday, August 02, 2000 8:18 AM
> > > Subject: Re: mod_perl success!
> > >
> > >
> > > > It's actually:
> > > >
> > > > PerlSetVar PerlRunOnce On
> > > >
> > > > (that's without the handler, of course. With it you want that off)
> > > >
> > > > Andrew Chen
> > > > Intern, Architecture
> > > > [EMAIL PROTECTED]
> > > > 206-219-8445
> > > > The Cobalt Group, Inc.
> > > >
> > > > On Tue, 1 Aug 2000, Pramod Sokke wrote:
> > > >
> > > > > Where did you set your PerlRunOnce option? I tried setting it in
> > > httpd.conf
> > > > > like this:
> > > > >
> > > > > Alias /cgi-perl/ /usr/ns-home/cgi-bin/
> > > > >
> > > > > #AllowOverride None
> > > > > SetHandler perl-script
> > > > > PerlHandler Apache::PerlRun
> > > > > Options +ExecCGI
> > > > > allow from all
> > > > > PerlSendHeader On
> > > > > PerlRunOnce On
> > > > >
> > > > >
> > > > > and I got this error:
> > > > >
> > > > > Invalid command 'PerlRunOnce', perhaps mis-spelled or defined by a
> > > module
> > > > > not included in the server configuration.
> > > > >
> > > > > -Pramod
> > > > >
> > > > > At 04:25 PM 7/25/00 -0700, Andrew Chen wrote:
> > > > > >On Tue, 25 Jul 2000, Pramod Sokke wrote:
> > > > > >
> > > > > >> Andrew,
> > > > > >> >From your discussion on the forum, I recall you mentioning the
> > > differences
> > > > > >> between PerlRunOnce being 'On' and 'Off'. Since our code is
> > extremely
> > > > > >> shabby and huge, will I be able to use it with 'Off'? If I
don't,
> > > will I be
> > > > > >> compromising on the speed?
> > > > > >>
> > > > > >> Thanks again for the great detailed write-up!
> > > > > >> -Pramod
> > > > > >
> > > > > >If PerlRunOnce is On, then you can use your code without any
> changes,
> > > even
> > > > > >if it is completely horrible. PerlRunOnce Off allows for bigger
> speed
> > > > > >increases, but then you have to write the handler.
> > > > > >
> > > > > >If you just want a really quick speed improvement, stick it on
> > PerlRun
> > > > > >with PerlRunOnce On and see if that's sufficient.
> > > > > >
> > > > > >If you feel like writing the handler (so that you can get a
really
> > big
> > > > > >speed boost) then you can run it with PerlRunOnce Off.
> > > > > >
> > > > > >Andrew
> > > > >
> > > >
> > >
> >
>
Re: mod_perl success!
ups again, i meant $key
a working code for this "keys" loop would be
foreach $key (sort(keys %ENV)) {
print "$key = $ENV{$key}\n";
}
anyway you can write it shorter but you'll have problems when debuging.
Razvan
> - Original Message -
> From: "yusun" <[EMAIL PROTECTED]>
> To: "Andrew Chen" <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>
> Sent: Wednesday, August 02, 2000 3:50 PM
> Subject: Re: mod_perl success!
>
>
> > I have installed the mod_perl and changed the httpd.conf as you said.
> > But when I used the following CGI to test whether the mod_perl was
working
> > or not.
> > The report was no. Why?
> >
> > #!/usr/bin/perl
> > print "Content-type: text/plain\n\n";
> > print "Server's environment\n";
> > foreach ( keys %ENV ) {
> > print "$_\t$ENV{$_}\n";
> > }
> > #
> >
> > The result is
> > :
> > :
> > GATEWAY_INTERFACE CGI/1.1
> > :
> >
> > It means that I have configured this location to run under mod_cgi and
not
> > mod_perl.
> > How can I configure the location to run under mod_perl?
> > Thanks!
> >
> >
> > Yu Sun
> > [EMAIL PROTECTED]
> >
> >
> > - Original Message -
> > From: "Andrew Chen" <[EMAIL PROTECTED]>
> > To: "Pramod Sokke" <[EMAIL PROTECTED]>
> > Cc: <[EMAIL PROTECTED]>
> > Sent: Wednesday, August 02, 2000 8:18 AM
> > Subject: Re: mod_perl success!
> >
> >
> > > It's actually:
> > >
> > > PerlSetVar PerlRunOnce On
> > >
> > > (that's without the handler, of course. With it you want that off)
> > >
> > > Andrew Chen
> > > Intern, Architecture
> > > [EMAIL PROTECTED]
> > > 206-219-8445
> > > The Cobalt Group, Inc.
> > >
> > > On Tue, 1 Aug 2000, Pramod Sokke wrote:
> > >
> > > > Where did you set your PerlRunOnce option? I tried setting it in
> > httpd.conf
> > > > like this:
> > > >
> > > > Alias /cgi-perl/ /usr/ns-home/cgi-bin/
> > > >
> > > > #AllowOverride None
> > > > SetHandler perl-script
> > > > PerlHandler Apache::PerlRun
> > > > Options +ExecCGI
> > > > allow from all
> > > > PerlSendHeader On
> > > > PerlRunOnce On
> > > >
> > > >
> > > > and I got this error:
> > > >
> > > > Invalid command 'PerlRunOnce', perhaps mis-spelled or defined by a
> > module
> > > > not included in the server configuration.
> > > >
> > > > -Pramod
> > > >
> > > > At 04:25 PM 7/25/00 -0700, Andrew Chen wrote:
> > > > >On Tue, 25 Jul 2000, Pramod Sokke wrote:
> > > > >
> > > > >> Andrew,
> > > > >> >From your discussion on the forum, I recall you mentioning the
> > differences
> > > > >> between PerlRunOnce being 'On' and 'Off'. Since our code is
> extremely
> > > > >> shabby and huge, will I be able to use it with 'Off'? If I don't,
> > will I be
> > > > >> compromising on the speed?
> > > > >>
> > > > >> Thanks again for the great detailed write-up!
> > > > >> -Pramod
> > > > >
> > > > >If PerlRunOnce is On, then you can use your code without any
changes,
> > even
> > > > >if it is completely horrible. PerlRunOnce Off allows for bigger
speed
> > > > >increases, but then you have to write the handler.
> > > > >
> > > > >If you just want a really quick speed improvement, stick it on
> PerlRun
> > > > >with PerlRunOnce On and see if that's sufficient.
> > > > >
> > > > >If you feel like writing the handler (so that you can get a really
> big
> > > > >speed boost) then you can run it with PerlRunOnce Off.
> > > > >
> > > > >Andrew
> > > >
> > >
> >
>
Re: mod_perl success!
it seems to me you should write $keys
Razvan
- Original Message -
From: "yusun" <[EMAIL PROTECTED]>
To: "Andrew Chen" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, August 02, 2000 3:50 PM
Subject: Re: mod_perl success!
> I have installed the mod_perl and changed the httpd.conf as you said.
> But when I used the following CGI to test whether the mod_perl was working
> or not.
> The report was no. Why?
>
> #!/usr/bin/perl
> print "Content-type: text/plain\n\n";
> print "Server's environment\n";
> foreach ( keys %ENV ) {
> print "$_\t$ENV{$_}\n";
> }
> #
>
> The result is
> :
> :
> GATEWAY_INTERFACE CGI/1.1
> :
>
> It means that I have configured this location to run under mod_cgi and not
> mod_perl.
> How can I configure the location to run under mod_perl?
> Thanks!
>
>
> Yu Sun
> [EMAIL PROTECTED]
>
>
> - Original Message -
> From: "Andrew Chen" <[EMAIL PROTECTED]>
> To: "Pramod Sokke" <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>
> Sent: Wednesday, August 02, 2000 8:18 AM
> Subject: Re: mod_perl success!
>
>
> > It's actually:
> >
> > PerlSetVar PerlRunOnce On
> >
> > (that's without the handler, of course. With it you want that off)
> >
> > Andrew Chen
> > Intern, Architecture
> > [EMAIL PROTECTED]
> > 206-219-8445
> > The Cobalt Group, Inc.
> >
> > On Tue, 1 Aug 2000, Pramod Sokke wrote:
> >
> > > Where did you set your PerlRunOnce option? I tried setting it in
> httpd.conf
> > > like this:
> > >
> > > Alias /cgi-perl/ /usr/ns-home/cgi-bin/
> > >
> > > #AllowOverride None
> > > SetHandler perl-script
> > > PerlHandler Apache::PerlRun
> > > Options +ExecCGI
> > > allow from all
> > > PerlSendHeader On
> > > PerlRunOnce On
> > >
> > >
> > > and I got this error:
> > >
> > > Invalid command 'PerlRunOnce', perhaps mis-spelled or defined by a
> module
> > > not included in the server configuration.
> > >
> > > -Pramod
> > >
> > > At 04:25 PM 7/25/00 -0700, Andrew Chen wrote:
> > > >On Tue, 25 Jul 2000, Pramod Sokke wrote:
> > > >
> > > >> Andrew,
> > > >> >From your discussion on the forum, I recall you mentioning the
> differences
> > > >> between PerlRunOnce being 'On' and 'Off'. Since our code is
extremely
> > > >> shabby and huge, will I be able to use it with 'Off'? If I don't,
> will I be
> > > >> compromising on the speed?
> > > >>
> > > >> Thanks again for the great detailed write-up!
> > > >> -Pramod
> > > >
> > > >If PerlRunOnce is On, then you can use your code without any changes,
> even
> > > >if it is completely horrible. PerlRunOnce Off allows for bigger speed
> > > >increases, but then you have to write the handler.
> > > >
> > > >If you just want a really quick speed improvement, stick it on
PerlRun
> > > >with PerlRunOnce On and see if that's sufficient.
> > > >
> > > >If you feel like writing the handler (so that you can get a really
big
> > > >speed boost) then you can run it with PerlRunOnce Off.
> > > >
> > > >Andrew
> > >
> >
>
Re: Feature sets [was Re: Templating System]
> "Eric" == Eric Cholet <[EMAIL PROTECTED]> writes: >> Hi there, >> >> I have a pure perl implementation of a simple templating system which is >> (what I consider to be) relatively lightweight - it copes well in both >> cgi-bin and mod_perl environments, at least for me. I've looked at various >> other modules, and do believe mine brings an alternative slant to the >> proceedings 8) [...] Eric> This looks very similar to HTML::Template: [...] I think it's a rite of passage to look at all the templating systems, and decide "I can do better, along axis $X", and write your own. Then you discover after a while that: a) writing templating systems is no fun the moment you let someone else start using it, because they want feature $Y which you thought nobody would need b) you understand why that other package was so fat :-) Maybe we should have a "Congratulations: you wrote a templating system!" web memorial. :) One brief serious note: I think the fact that there are SO MANY is a tribute to just how easy it is to process text in Perl. I don't think there are 47 templating system for Java. :) -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: mod_perl success!
I have installed the mod_perl and changed the httpd.conf as you said.
But when I used the following CGI to test whether the mod_perl was working
or not.
The report was no. Why?
#!/usr/bin/perl
print "Content-type: text/plain\n\n";
print "Server's environment\n";
foreach ( keys %ENV ) {
print "$_\t$ENV{$_}\n";
}
#
The result is
:
:
GATEWAY_INTERFACE CGI/1.1
:
It means that I have configured this location to run under mod_cgi and not
mod_perl.
How can I configure the location to run under mod_perl?
Thanks!
Yu Sun
[EMAIL PROTECTED]
- Original Message -
From: "Andrew Chen" <[EMAIL PROTECTED]>
To: "Pramod Sokke" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, August 02, 2000 8:18 AM
Subject: Re: mod_perl success!
> It's actually:
>
> PerlSetVar PerlRunOnce On
>
> (that's without the handler, of course. With it you want that off)
>
> Andrew Chen
> Intern, Architecture
> [EMAIL PROTECTED]
> 206-219-8445
> The Cobalt Group, Inc.
>
> On Tue, 1 Aug 2000, Pramod Sokke wrote:
>
> > Where did you set your PerlRunOnce option? I tried setting it in
httpd.conf
> > like this:
> >
> > Alias /cgi-perl/ /usr/ns-home/cgi-bin/
> >
> > #AllowOverride None
> > SetHandler perl-script
> > PerlHandler Apache::PerlRun
> > Options +ExecCGI
> > allow from all
> > PerlSendHeader On
> > PerlRunOnce On
> >
> >
> > and I got this error:
> >
> > Invalid command 'PerlRunOnce', perhaps mis-spelled or defined by a
module
> > not included in the server configuration.
> >
> > -Pramod
> >
> > At 04:25 PM 7/25/00 -0700, Andrew Chen wrote:
> > >On Tue, 25 Jul 2000, Pramod Sokke wrote:
> > >
> > >> Andrew,
> > >> >From your discussion on the forum, I recall you mentioning the
differences
> > >> between PerlRunOnce being 'On' and 'Off'. Since our code is extremely
> > >> shabby and huge, will I be able to use it with 'Off'? If I don't,
will I be
> > >> compromising on the speed?
> > >>
> > >> Thanks again for the great detailed write-up!
> > >> -Pramod
> > >
> > >If PerlRunOnce is On, then you can use your code without any changes,
even
> > >if it is completely horrible. PerlRunOnce Off allows for bigger speed
> > >increases, but then you have to write the handler.
> > >
> > >If you just want a really quick speed improvement, stick it on PerlRun
> > >with PerlRunOnce On and see if that's sufficient.
> > >
> > >If you feel like writing the handler (so that you can get a really big
> > >speed boost) then you can run it with PerlRunOnce Off.
> > >
> > >Andrew
> >
>
Re: [OT] The $64K question/server hardware
I've been using a dual processor, PIII 400+ Mhz Dell PowerEdge server that has 512MB RAM 2 9GB SCSI drives running Redhat Linux, Apache, mod_perl, HTML::Embperl and it's been working like a champ. Price tag: $8000 Not to plug Dell but they have some really nice server offerings and now fully support Linux as well... ___cliff rayman___ wrote: > > i am running a PII 350 w/128mg ram and SCSI-2 7200rpm harddrives. > i put out as many at 12K page views a day, nothing compared to Ask at Valueclick, > although my pages are kind of big - about 60K worth. > all of my pages have dynamic content rendered with mod_perl and Embperl and I > suppress browser caching anytime the customer has an active cart. only the gifs > and jpegs are static. > the checkout process is all SSL of course. > > i have not yet set-up the reverse proxying etc. on the tuits list. > > unless i am running some kind of maintenance (log analysis) etc., this system is > always over 90% idle and never uses the swap space. > > keystone was trying to sell me their monitoring and testing service and they > pounded on the machine for a couple of weeks, and it came through with flying > colors. always showing very small error rates and responses rates in the 90th > percentile. > > so, i intended this as a starter system, and i was expecting have to upgrade. > but, it looks like it will make another season before it becomes another > firewall, honeypot or internal server. > > -- > ___cliff [EMAIL PROTECTED]http://www.genwax.com/ > Bill Moseley wrote: > > > Hi, > > > > I'm not sure why, but someone asked me to review a bid they received for a > > server to run their site. That's where the $64,000 USD part comes from. > > Whew! > > > > This is not a commerce site (it's a .org), and unlikely to get slashdotted. > > 24/7 is nice, but it's not the end of the world if the server is down for > > 12 hours. The server is normally running about 1.5 hits/second with about > > 30 10MB mod_perl processes. Low database activity. So I imagine an $800 > > PC running linux could do the job -- saving $63,200 in the process ;). > > > > Anyway, I've read the Guide on this issue again, and I've looked over the > > High-Availability Linux Project, but I was wondering if anyone knew of > > links or had experience with building a nice small inexpensive and reliable > > server for running mod_perl. Frankly, A single CPU P550 running Linux with > > 1G RAM and a couple fast SCSI drives (and some decent ISP connectivity) > > would more than do the job. But what do I know! Do mod_perl programmers > > know hardware? > > > > So, I'm not looking for any specific advice, or do I want to discuss the > > maintenance issues, but just some basic ideas on hardware, or pointers to > > links you might have found useful. > > > > Like: "I'm running a P550 with 1G, ultra-wide SCSI and 10 hits/second and > > never see any load problem." > > > > or "Check out this link and see how to run two inexpensive boxes in > > parallel to maintain 100% uptime and you even don't have to worry about > > tape backup." > > > > or "No, it's worth running RAID with hot-swappable disks and power supplies." > > > > or "I'll set up that server for $64,000!!" (no, sorry, I'm first in line > > for that job...) > > > > Thanks, > > > > Bill Moseley > > mailto:[EMAIL PROTECTED] -- __ Mr. Erich L. Markert [EMAIL PROTECTED] Computer Learning Center TEL (914)422-4328 Pace University 1 Martine Ave White Plains, New York 10606-1932 Those who do not understand Unix are condemned to reinvent it, poorly. -- Henry Spencer
Re: [OT] The $64K question/server hardware
Can we also include OS ? I'm particularly interested in performance figures of NT against *nix to help my case to ditch NT in a project which has yet to go live. Simon Wilcox Intranet Development Manager Williams Lea Group >From Ajit Deshpande <[EMAIL PROTECTED]>Date 22:43:28 1 August 2000 To: [EMAIL PROTECTED] cc:(bcc: Simon Wilcox/BASE/WilliamsLea) Fax to: Subject: Re: [OT] The $64K question/server hardware On Tue, Aug 01, 2000 at 02:32:52PM -0700, ___cliff rayman___ wrote: > [ .. snip .. ] Since this has potential for becoming another long thread with people posting their stories and some other people flaming for not doing things in a certain way, I have suggestions for this monster thread in the making: 1. Everyone post information in the format at the end of this mail 2. Send it in a private e-mail to me if confidentiality is a problem (or pick someone you trust, more than me, and have them e-mail it to me :) 3. I will consolidate the information and dash it off to Ask or whoever maintains the perl.apache.org What do ye think? Ajit Format for posting information: 1. Setup : for example: - Single modperl server on one host, apache 1.3.12, mod_proxy - One modperl, one front-end proxy on one host, apache 1.3.12, mod_perl 1.24 - Multiple modperl and multiple hosts 2. Average hits/day . Peak hits/second. 3. CPU details for example: - Front end proxy on PII 333 - Modperl-enabled httpd on PIII 550 - MySql/Oracle DB on Quad Xeon PIII 550 (Wow! :) 4. Memory details: for example: - Front end proxy with 128 Mb - Modperl-enabled httpd with 256 Mb - MySql/Oracle DB with 2Gb 5. Storage details: for example: - 10,000 RPM Ultra-wide SCSI discs on all hosts - Root partition for each server on 1.2 Gb IDE - Session stuff on NFS mounted NetApp (!) - D/B disk on EMC sub-system (!) 6. Kind of content: - 70% dynamic, d/b driven, 20% static, 10% images - All dynamic except images 7. Publication of the site: - http://www.foo.com OR Author does not wish to divulge - Intranet site, not accessible from public internet - In production since Aug-99 - Primary contact : [EMAIL PROTECTED] OR Author does not wish to divulge
Re: Feature sets [was Re: Templating System]
> Hi there,
>
> I have a pure perl implementation of a simple templating system which is
> (what I consider to be) relatively lightweight - it copes well in both
> cgi-bin and mod_perl environments, at least for me. I've looked at various
> other modules, and do believe mine brings an alternative slant to the
> proceedings 8)
>
> A simple example of it in action (if it were called My::Simple::Template)
> would be:
>
> use My::Simple::Template;
> my $template = new My::Simple::Template;
> $template->tags( { key1 => 'value1', key2 => 'value2' } );
> print $template->generate("/path/to/template.html");
This looks very similar to HTML::Template:
use HTML::Template;
my $template = HTML::Template->new (filename => '/path/to/template');
$template->param( key1 => 'value1', key2 => 'value2' );
print $template->output;
How does your package differ ?
--
Eric
RE: Feature sets [was Re: Templating System]
Hi there,
I have a pure perl implementation of a simple templating system which is
(what I consider to be) relatively lightweight - it copes well in both
cgi-bin and mod_perl environments, at least for me. I've looked at various
other modules, and do believe mine brings an alternative slant to the
proceedings 8)
A simple example of it in action (if it were called My::Simple::Template)
would be:
use My::Simple::Template;
my $template = new My::Simple::Template;
$template->tags( { key1 => 'value1', key2 => 'value2' } );
print $template->generate("/path/to/template.html");
I've been thinking about releasing it for a while (I've just received
permission from my employer to do so) under the GPL/Artistic license,
although I'm pretty nervous about the quality of the code (primarily due to
having not released anything for public scrutiny before!). I know that there
are a few things that could do with a bit of tidying up, however 8)
It's around 300 lines of code (plus docs) and has been tested with perl
5.005 (although it should work with earlier versions with a bit of
fiddling), on under solaris, linux and windows, cgi-bin and mod_perl. I'll
quite happily supply what I currently have to anyone who's interested.
Synopsis of "main" features:
* in-line insertions with name/value pairs (obviously)
* loops
* basic if/else constructs
* template comments
* file includes
* file and database caching of preprocessed templates
* "loose" expansion of tags
* "template subroutines" (hard to explain in one line)
Please mail me if you're interested in finding out more
Chris
-Original Message-
From: Gunther Birznieks [mailto:[EMAIL PROTECTED]]
Sent: 02 August 2000 09:20
To: [EMAIL PROTECTED]
Subject: RE: Feature sets [was Re: Templating System]
I have to say that I am also interested in template kits myself.
My requirements are almost identical to yours (minus a few advanced things).
Basically, I write open source web applications in Perl -- that means that
they must be able to run reasonably fast on non-modperl systems and must
run on a variety of ISPs (ie not dedicated servers where you control the
version of Perl).
Of course, mod_perl support is crucial for those that want to "scale", but
normal CGI/Perl support is really a biggie that I haven't seen highlighted
within the context of this thread.
Here are my CGI/Perl requirements:
1) Must be 100% pure Perl or support pure-Perl alternatives if certain libs
arent compiled. Many people who download CGI scripts don't know how to
compile stuff.
2) Must support Perl 5.004 and above. Ideal to support Perl 5.003. Enough
ISPs and corporations around the world are still on 5.004 that only
supporting the latest Perl version is not doable.
3) Must incur as minimal load-time as possible. CGI/Perl scripts are not
cached like mod_perl scripts.
So CGI/Perl people must have a template system that can choose to load a
minimal amount of code if really advanced features aren't used. IE would
rather not have a templating system as large as CGI.pm. Or rather it can be
as large as CGI.pm, but only if the extra code is loaded when advanced
features are accessed -- normal CGI/Perl users should not be penalized.
4) Must have a license that supports redistribution in other scripts. I
think most of the systems out there do that (maybe all the Perl ones do).
CPAN is great for us, but again, most real-world web app users are not CPAN
savvy and don't have the rights to install global modules on their ISP nor
the learning to install them locally. So an open source web app that takes
advantage of a template system really should also contain that template
system. The power users can remove it from the local dir if they have a
globally installed version of the system.
Anyway, I felt that I should state these feature requirements because this
list is so mod_perl centric, I think sometimes we forget the "little"
people. And there are many more of them out there than mod_perl servers and
Perl/CPAN savvy people.
And please don't say that they should RTFM. Most users do
not have time to RTFM. If they did, they would be us. :) These users are
people who know their business and typically learn just enough tech to
install something that will help their business -- they don't care or want
a CS degree in the process.
Later,
Gunther
_
This message has been checked for all known viruses by UUNET delivered
through the MessageLabs Virus Control Centre. For further information visit
http://www.uk.uu.net/products/security/virus/
Re: template kit.....
On Aug 1, 12:58pm, Jonathan Swartz wrote: > Many Masonites have successfully used sessions with Mason. It takes about > five lines of code in the handler.pl to integrate with Apache::Session, > which will give you all the fancy session handling you need. Jonathon makes an important point here. The "Right Way To Do It", as far as template systems go, is to *not* re-invent every wheel, but to provide the mechanism for external modules to be loaded and used. This is where systems like Mason and TT (to name just 2) win big. If you want to add functionality like session management, database connectivity, custom XML parser, stateful form filling, and so on, then simply download the relevant module (Apache::Session, DBI, XML::*, HTML::StickyForms, etc) or write the functionality yourself and then plug it into the relevant templating system in just a few lines of code. Template systems shoulds be concerned with processing templates and not implementing every piece of application functionality that anyone could ever wish for. A -- Andy Wardley <[EMAIL PROTECTED]> Signature regenerating. Please remain seated. <[EMAIL PROTECTED]> For a good time: http://www.kfs.org/~abw/
Re: Feature sets [was Re: Templating System]
Gunther Birznieks wrote: > Of course, mod_perl support is crucial for those that want to "scale", but > normal CGI/Perl support is really a biggie that I haven't seen highlighted > within the context of this thread. Most of the popular template modules support CGI use. Almost everything except Apache::ASP claims to work, although I don't think you'd find anyone doing much with Mason through CGI. It sounds like you want more of a "just templates" solution anyway. The question is which ones perform well in a non-persistent environment. I would expect the simple regex type to beat the compile-to-perl-subs type in this scenario. At a guess, maybe HTML::Template and CGI::FastTemplate would be contenders here. Some of the small compile-to-perl-subs ones might work as well, like Text::Template. - Perrin
Re: XForms & ASP (was: The Template Toolkit )
Dmitry Beransky wrote:
>
> [Mon Jul 31 10:45:53 2000] (eval 76): String found where operator expected at
> (eval 76) line 50, at end of line
> [Mon Jul 31 10:45:53 2000] (eval 76): (Missing operator before ?)
> [Mon Jul 31 10:45:53 2000] [error] [asp] [605] [error] [Mon Jul 31 10:45:53 20
> 00] (eval 76): Can't find string terminator "'" anywhere before EOF at (eval 7
> 6) line 50. <--> , /usr/lib/perl5/site_perl/5.005/Apache/ASP.pm line 1740
>
> It doesn't look like I have any runaway strings, so any idea what gives?
>
The XMLSubsMatch parser is pretty aggressive, and found a
tag in your <% perl code %> that it tried parsing. If you
had debug 2 set, the output would give you more of a hint
as to what was going on. It doesn't only look for tags
in the HTML segments, though this is what it ought to do.
I would recommend using the Script_OnFlush event handler
to grab all of the data at once and process it with XML, or the
XSLT extension even. You can find the response buffer in
$Response->{BinaryRef} as a scalar reference. This member
is documented at:
http://www.apache-asp.org/objects.html
Only if you are looking to extend all forms with the
the xform might I implement this with XMLSubsMatch.
-- Joshua
_
Joshua Chamas Chamas Enterprises Inc.
NodeWorks >> free web link monitoring Huntington Beach, CA USA
http://www.nodeworks.com1-714-625-4051
RE: Feature sets [was Re: Templating System]
I have to say that I am also interested in template kits myself. My requirements are almost identical to yours (minus a few advanced things). Basically, I write open source web applications in Perl -- that means that they must be able to run reasonably fast on non-modperl systems and must run on a variety of ISPs (ie not dedicated servers where you control the version of Perl). Of course, mod_perl support is crucial for those that want to "scale", but normal CGI/Perl support is really a biggie that I haven't seen highlighted within the context of this thread. Here are my CGI/Perl requirements: 1) Must be 100% pure Perl or support pure-Perl alternatives if certain libs arent compiled. Many people who download CGI scripts don't know how to compile stuff. 2) Must support Perl 5.004 and above. Ideal to support Perl 5.003. Enough ISPs and corporations around the world are still on 5.004 that only supporting the latest Perl version is not doable. 3) Must incur as minimal load-time as possible. CGI/Perl scripts are not cached like mod_perl scripts. So CGI/Perl people must have a template system that can choose to load a minimal amount of code if really advanced features aren't used. IE would rather not have a templating system as large as CGI.pm. Or rather it can be as large as CGI.pm, but only if the extra code is loaded when advanced features are accessed -- normal CGI/Perl users should not be penalized. 4) Must have a license that supports redistribution in other scripts. I think most of the systems out there do that (maybe all the Perl ones do). CPAN is great for us, but again, most real-world web app users are not CPAN savvy and don't have the rights to install global modules on their ISP nor the learning to install them locally. So an open source web app that takes advantage of a template system really should also contain that template system. The power users can remove it from the local dir if they have a globally installed version of the system. Anyway, I felt that I should state these feature requirements because this list is so mod_perl centric, I think sometimes we forget the "little" people. And there are many more of them out there than mod_perl servers and Perl/CPAN savvy people. And please don't say that they should RTFM. Most users do not have time to RTFM. If they did, they would be us. :) These users are people who know their business and typically learn just enough tech to install something that will help their business -- they don't care or want a CS degree in the process. Later, Gunther At 09:45 AM 8/1/00 -0700, Bill Moseley wrote: >It seems as if there needs to be a general templating mailing list... > >Here I have a comment about comparing template systems, and then I solicit >advice on which system to use... > >The only reason I'm using my own templating system (besides the requirement >that everyone writes one) is because I realized it would take me less time >to code up a simple one than wade through all the available packages, >downloading, installing, and trying each out. And frankly, some are so >feature-rich that they scared me off - I wanted a template system in my >application, not the other way around. > >I really should leave the programming to The Experts, so having a nice >comparison of features would be a huge help, and it might have convinced me >to pick one of the available systems. > >In additions to a comparison of features, people (including me) might find >it useful to have a general overview and comparison of the different >templating _technologies_ and what type of applications work well with each >and why. > >In my mind, almost all my applications seem to fit a system where a my >application uses the templates, instead of the templates using my >application. In other words, URLs map to the application and not to pages. > I assume the likes of TT and HTML::Template fit this, but Embperl, Mason, >and ASP are more based on URLs mapping to templates. Maybe this is an >incorrect assumption? > >I'd also like to see and compare which ones are designed to work best with >mod_perl, and the benefits that mod_perl provides the system. > >It seems like each of the various templating web sites have great info, but >it would just be very helpful to see it in one place and see each compared >against the others. > > >Now, I think I have rather simple needs. I'm not sure which current system >best fits. The tricky part for me is when used with co-branding. Any >suggestions? > >Here is what I need: > >- Get HTML out of my code, but limit code in templates as non-perl people >will be editing the templates -- although I need ways to do some tricks in >the templates like changing the bgcolor of a row of a table if some >condition is met, or adding an additional column to every row if data in >one row meets some condition. > >- Shared template cache across server children, plus some smart way to >detect changed templates without doing
Re: User-Agent: contype
Alan Sparks writes: > My tests show that it often (can't be sure of always) occurs with a PDF > file. BUT, it doesn't happen with NS Communicator and Acrobat Reader... > only the combo of IE and Acroread. > > I've long suspected that it had something to do with IE sniffing the data > stream to figure out the data type. There's an old bug against IE that > mentioned that IE does sniff the data stream and use its own ideas in > deference to the stated MIME types and content dispositions sometimes. I've > always wondered if that ties into this. I would agree to this. I have also seen that for the Autodesk Whip! Viewer. You need to give MSIE using the PDF plugin a filename ending with .pdf whatsoever. It seems not sufficient to supply the content-type and leave the URL to something like /files?give_me_my_pdf (what I was doing with Apache::File). MSIE (or the PDF plugin, I don't know) then tries to find out the content type by itself using the agent 'contype' and then issues a third request. All that seems have nothing to do with Accept-Ranges and the like. It's really a drag... Dirk
