Re: [preview] Search engine for the Guide
Hi all, On Thu, 18 May 2000, Randy Kobes wrote: The :: are stripped on the fly, since these cannot be used in index, so when you look for Foo::Bar you are actually looking for 'Foo Bar'. That's a limitation of swish-e - you can configure it to index characters like $, !, ... as part of a "word", but the characters , , *, and : cannot be so indexed. If you use swish++4.4 then you can change this in "config.h" // Characters that are permissible in words: letters must be lower // case and upper case letters would be redundant. // char const Word_Chars[] = "'-0123456789abcdefghijklmnopqrstuvwxyz_"; // Characters that may be in a word. Note that '' is here so // acronyms like "ATT" are treated as one word. Unlike SWISH-E, // ';' does not need to be here to recognize and convert character // entity references. 73, Ged.
Re: [preview] Search engine for the Guide
On Thu, 18 May 2000, Randy Kobes wrote: Another thing that was configured in is that words have to be at least 3 characters long, which seems reasonable, and also there's some stopwords that don't get indexed, as they're too common. This list of stopwords is built by hand - so far it only includes 'perl' and 'modperl'. Also, the maximum number of hits is set at 30. It should also index $/, etc. So limiting to 2char words is another broken aspect... But I'm not complaining! It's 100% better than it was. Maybe someone would like my code for a db backed search engine and fix that up to something that could work? It's all built in perl so you're free to add and remove stopwords or change the min word length as you like. -- Matt/ Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org http://xml.sergeant.org
(pas d'objet)
-- Raphaël Grandjean FI SYSTEM Tél:0147615331
New Module (was Re: RFC: Apache::Request::Forms (or something similar))
I have my own module for doing this job, sorry I missed many
posts of this thread but here is what I do:
- The target is automatically : add , update, select data
from a table reading data typed by the user.
- I didn't want to use the Apache api, so it even can be
used out of apache, so I called it : Persistence::DBI
thought I don't like this name much.
In This example I work with HTML::Mason, but as
I said before it can be used from whatever thingie, even
out of the web.
I'm using currently this in production sites and it saves
me a lot of work.
EXAMPLE OF CODE:
It's a little harder than this but you'll get the idea:
##customer.html###3
%init
# Make the object
my $customer=Persistence::DBI-open(
table = 'customers',
field_id = 'idCustomer'
field_data = \%ARGS
);
if (defined $_delete) {
$customer-delete;
}
/%init
## The html form is this way:
form
input type="text" name="name" value="% $customer-name %"
input type="text" name="phone" value="% $customer-phone %"
input type="submit" name="_save" value="save"
% if (defined $customer-idCustomer) {
input type="hidden" name="idCustomer"
value="% $customer-idCustomer %"
input type="submit" name="_delete" value="delete"
% }
/form
It works this way:
- if you supply the value of the id field it does a select
- if you supply all the fields but the id, it does an insert
- if you supply id and fields it does an update
Before calling the object you can check the values supplied
by the user to verify the values are correct.
If you modify values of the object it updates the data.
I'll accept name changes and I'll send the module to
whoever wants it. I checked it with MySQL and SQL server.
The module come with pods and it installs fine like any
other module.It needs the field_id be auto increment.
--
- frankie -
Re: [preview] Search engine for the Guide
On Thu, 18 May 2000, Randy Kobes wrote: On Fri, 19 May 2000, Stas Bekman wrote: On Thu, 18 May 2000, Vivek Khera wrote: looks good... one minor issue with the stickyness of the next search feature: type "lexical file handles" in your original search. the "es" at the end is lost in the next search box on the result page. Yup, broken :( Hi, But fixable ...:) As I just mentioned, we can turn stemming off, or at least make it optional, so the full word only is searched for. I've found stemming useful, but that's perhaps just the way I do searches - should I turn it off by default to see if that's preferable? And make it then a configurable option? Yup, turn it off. And have an option to turn it on. Thanks! _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://perl.org http://stason.org/TULARC http://singlesheaven.com http://perlmonth.com http://sourcegarden.org
Re: [preview] Search engine for the Guide
On Fri, 19 May 2000, Ged Haywood wrote: Hi all, On Thu, 18 May 2000, Randy Kobes wrote: The :: are stripped on the fly, since these cannot be used in index, so when you look for Foo::Bar you are actually looking for 'Foo Bar'. That's a limitation of swish-e - you can configure it to index characters like $, !, ... as part of a "word", but the characters , , *, and : cannot be so indexed. If you use swish++4.4 then you can change this in "config.h" // Characters that are permissible in words: letters must be lower // case and upper case letters would be redundant. // char const Word_Chars[] = "'-0123456789abcdefghijklmnopqrstuvwxyz_"; // Characters that may be in a word. Note that '' is here so // acronyms like "ATT" are treated as one word. Unlike SWISH-E, // ';' does not need to be here to recognize and convert character // entity references. Interesting, Randy what version did you use? Thanks Ged! _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://perl.org http://stason.org/TULARC http://singlesheaven.com http://perlmonth.com http://sourcegarden.org
Re: [preview] Search engine for the Guide
On Fri, 19 May 2000, Matt Sergeant wrote: On Thu, 18 May 2000, Randy Kobes wrote: Another thing that was configured in is that words have to be at least 3 characters long, which seems reasonable, and also there's some stopwords that don't get indexed, as they're too common. This list of stopwords is built by hand - so far it only includes 'perl' and 'modperl'. Also, the maximum number of hits is set at 30. It should also index $/, etc. So limiting to 2char words is another broken aspect... Seems like for Perl documentation there should be no limiting at all, or may be one character is the only option... But I'm not complaining! It's 100% better than it was. Maybe someone would like my code for a db backed search engine and fix that up to something that could work? It's all built in perl so you're free to add and remove stopwords or change the min word length as you like. That would be nice to see. I'm afraid I'll continue on working on guide. So if there anyone with a few free minutes on his hands, he/she might like to contribute something back to community ;) Ideally, when we complete the tuning of the search engine, we will be able to have the whole site, apache::asp and embperl pages searchable as well. (with Perl style documentation in mind). _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://perl.org http://stason.org/TULARC http://singlesheaven.com http://perlmonth.com http://sourcegarden.org
RE: [preview] Search engine for the Guide
That would be nice to see. I'm afraid I'll continue on working on guide. So if there anyone with a few free minutes on his hands, he/she might like to contribute something back to community ;) Ideally, when we complete the tuning of the search engine, we will be able to have the whole site, apache::asp and embperl pages searchable as well. (with Perl style documentation in mind). Stas, there is already a search frontend for the apache sites, at http://www.apache.org/search.html which is also able to search under perl.apache.org, but if you enter mod_perl, doesn't find anything :-(. Don't know if this is of any use and who is maintaining (or not maintaining) this page. Gerald
RE: [preview] Search engine for the Guide
That would be nice to see. I'm afraid I'll continue on working on guide. So if there anyone with a few free minutes on his hands, he/she might like to contribute something back to community ;) Ideally, when we complete the tuning of the search engine, we will be able to have the whole site, apache::asp and embperl pages searchable as well. (with Perl style documentation in mind). Stas, there is already a search frontend for the apache sites, at http://www.apache.org/search.html which is also able to search under perl.apache.org, but if you enter mod_perl, doesn't find anything :-(. Don't know if this is of any use and who is maintaining (or not maintaining) this page. Heh, look at the bottom of the http://perl.apache.org/guide/index.html -- the search box from http://www.apache.org/search.html is there since the day the guide is online. But as you said -- it's useless, as it's not good for the kind of documentation we have. I've posted a request for comments about the apache.org search engine to the asf members list but it was ignored :( _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://perl.org http://stason.org/TULARC http://singlesheaven.com http://perlmonth.com http://sourcegarden.org
Re: passing Apache::File to XS code that expects FILE *?
On Thu, 18 May 2000, Vivek Khera wrote:
"DM" == Doug MacEachern [EMAIL PROTECTED] writes:
DM On Wed, 17 May 2000, Matt Sergeant wrote:
Well, this may be true, but if you load IO::File before startup then it's
not too big a deal...
DM but it still adds a great deal of bloat to the server. and it's oo
DM interface, while very slick, adds quite a bit of runtime overhead, turn
DM the sugar sour imo.
In an embedded environment like mod_perl, then how do you suggest to
deal with the dangling file handles problem? That is, I'm processing
a file or two, and some error occurs. In a normal perl program, I'd
exit or return out and then when the program terminates, it
automagically closes all the files. In mod_perl, the auto-close
doesn't happen until much later. With the OO interface, when the
handle goes out of scope, such as a function call return, the file is
implicitly closed.
What other mechanism do you propose to handle this situation other
than IO::File? I use it all the time myself.
in addition to stas' hints, even local *FH does the job, e.g.:
#/dev/null so strace output is more readable
open my $fh, "/dev/null";
select $fh;
$| = 1;
{
print "enter";
local *FH;
open FH, $0;
print "leave"
}
print "done";
% strace ~/test/io.pl
write(3, "enter", 5)= 5
- open("/home/dougm/test/io.pl", O_RDONLY) = 4
fstat(4, {st_mode=S_ISGID|S_ISVTX|0401, st_size=0, ...}) = 0
fcntl(4, F_SETFD, FD_CLOEXEC) = 0
write(3, "leave", 5)= 5
- close(4)= 0
write(3, "done", 4) = 4
Re: RFC: Apache::Request::Forms (or something similar)
i do think that doug's separation of responsibilities into classes is the right one. your widget toolkit probably shouldn't be named Apache::HTML tho, unless it's actually using the apache api in some fashion. one reason i was thinking Apache::HTML is so we can use ap_pool for allocations.
Re: writing code that works on machines with or without mod_perl
On Thu, 18 May 2000, Matt Sergeant wrote:
On Thu, 18 May 2000, Kenneth Lee wrote:
modperlers,
does it make sense if i put some mod_perl specific codes inside
an eval() so that the code runs on machines that have or haven't
mod_perl installed?
eval 'MOD_PERL_CODE' if $ENV{MOD_PERL};
use Apache ();
my $r = Apache-request;
...
MOD_PERL_CODE
Better still:
eval {
die unless $ENV{MOD_PERL};
require Apache;
my $r = $Apache-request;
...
};
Then you've got no (at least much less than the above) run-time overhead.
better still:
use constant IS_MODPERL = $ENV{MOD_PERL};
BEGIN {
import Apache::Constants qw(OK) if IS_MODPERL;
}
if (IS_MODPERL) {
my $r = Apache-request;
}
_zero_ runtime overhead, since IS_MODPERL is constant folded, that block
is optimized away at compile time outside of mod_perl.
you shouldn't need to 'use Apache ()', mod_perl does that for you, along
with Apache::Constants. in any case, have your startup script require any
Apache:: modules you need and import in a BEGIN block if needed.
Re: RFC: Apache::Request::Forms (or something similar)
On Thu, 18 May 2000, Autarch wrote: C seems like serious overkill for something to simply generate plain text output. How slow is making a string in perl compared to doing it in C? I can't imagine there's to much of a difference. more like Perl is serious overkill :) SV's are BIG, notice the $unused variable and the B::TerseSize output (from Apache::Status) below, even before a string is copied into it, there's 48 bytes eaten. my $r = shift; $r-send_http_header; my $unused; my $string = "hi"; print $string; Totals: 1455 bytes | 23 OPs PADLIST summary: 0: undef [AV 116 bytes] MAX = 3 1: $r [RV52 bytes] 0x891b9b4 2: undef [GV81 bytes] 3: undef [NULL 24 bytes] 0x891ba44 4: undef [NULL 24 bytes] 0x891ba5c 5: $unused [NULL 48 bytes] 0x891ba50 6: $string [PV63 bytes] hi now let's look at CGI::start_html: Totals: 15595 bytes | 330 OPs PADLIST summary: 8:$title [PV78 bytes] Untitled Document 35: undef [PV 140 bytes] !DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd" 40: undef [PV56 bytes] HTMLHEADTITLE 46: undef [PV81 bytes] HTMLHEADTITLEUntitled Document/TITLE 48: undef [PV65 bytes] LINK REV=MADE HREF="mailto: 59: undef [PV49 bytes] BASE HREF=" 77: undef [PV48 bytes] NOSCRIPT 94: undef [PV49 bytes] /HEADBODY 96: undef [PV50 bytes] /HEADBODY 100: undef [PV45 bytes] /TITLE 101: undef [PV 199 bytes] !DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd" HTMLHEADTITLEUntitled Document/TITLE /HEADBODY i've omitted all but the string variables, notice the additional copies, which are a result of concatination. Perl copies *everything* and these copies add up to alot. this is why i would like to see an html generator written in c, it would result in a much smaller footprint, no matter what the Perl implementation may be.
Re: Want to work at a Game company?
On Thu, 18 May 2000, ___cliff rayman___ wrote: legitimate job offers from a reputable company are never spam. especially if your salary is not more than ~$150-$200 per month :"( sorry for the off-topic iVAN [EMAIL PROTECTED]
Re: RFC: Apache::Request::Forms (or something similar)
On Thu, 18 May 2000, brian moseley wrote:
On Thu, 18 May 2000, Jeffrey W. Baker wrote:
.= concatenation is way faster
i don't have any results to back up my claim. therefore,
my words are eaten :)
i was convinced tho, even way back before you came to cp. i
wonder what convinced me!
that was probably me :) but, i don't recall suggesting join.
but i do recall pushing away from concat when print()-ing, this benchmark
also illustrates why i made Apache::print dereference references to
strings. 5.005_03 does seem todo better with the array benchmark than
5.006, oh well. there's tradeoffs both ways, i don't think there's a
clear winner.
Benchmark: timing 3 iterations of array, concat, ref_array...
array: 8 wallclock secs ( 6.90 usr + 0.27 sys = 7.17 CPU) @4184.10/s (n=3)
concat: 7 wallclock secs ( 5.98 usr + 0.16 sys = 6.14 CPU) @4885.99/s (n=3)
ref_array: 5 wallclock secs ( 4.59 usr + 0.16 sys = 4.75 CPU) @6315.79/s (n=3)
use Benchmark;
open my $fh, "/dev/null" or die;
my($one, $two, $three) = map { $_ x 4096 } 'a'..'c';
timethese(30_000, {
'ref_array' = sub {
my @a;
push @a, \($one, $two, $three);
my_print(@a);
},
'array' = sub {
my @a;
push @a, $one, $two, $three;
my_print(@a);
},
'concat' = sub {
my $s;
$s .= $one;
$s .= $two;
$s .= $three;
my_print($s);
},
});
sub my_print {
for (@_) {
print $fh ref($_) ? $$_ : $_;
}
}
Re: RFC: Apache::Request::Forms (or something similar)
On Fri, 19 May 2000, Gunther Birznieks wrote: eg I think there was a thread on this list way back about OO method calls versus direct package references... and people said that OO method calls have a lot of overhead, but I think in later versions of Perl, OO method call paths are cached(?) and so method calls no longer have the same overhead as they used to. there has always been a method cache, but even with that, methods are still a bit more expensive. the only improvement in 5.6.0 related to method calls (that i know of ) is that: $obj-method; #where method name is constant, know at compile time is now faster than: $obj-$method; #where $method isn't known until runtime
Re: [preview] Search engine for the Guide
hi, very interesting. Search for : "statinc" returns nothing and the box get filled with "tatinc" instead "statinc" ?!?!:") this under KDE viewer, now will try netscape ...!!
Re: Prb: Apache::DB plus Perl 5.6 doesn't break
i hadn't tried Apache::DB with newer Perl since 5.005_6x-ish, there was a fix that went into version 0.06 for that, are you using 0.06? i am able to set breakpoints no problem with 5.6.0 (perl-current, actually). i would suggest stripping back your Perl config to something simple (i tested with b Apache::Status::handler) and make sure require Apache::DB/Apache::DB-init is the first piece of Perl code to run.
Re: [preview] Search engine for the Guide
On Fri, 19 May 2000, raptor wrote: hi, very interesting. Search for : "statinc" returns nothing and the box get filled with "tatinc" instead "statinc" ?!?!:") this under KDE viewer, now will try netscape ...!! it's not the client -- it's a bug. This happened after Randy has made non-stemming as a default. When you turn the stemming on you get it right. Randy, ideas? _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://perl.org http://stason.org/TULARC http://singlesheaven.com http://perlmonth.com http://sourcegarden.org
Re: Prb: Apache::DB plus Perl 5.6 doesn't break
i am able to set breakpoints no problem with 5.6.0 (perl-current, actually). i would suggest stripping back your Perl config to something simple (i tested with b Apache::Status::handler) and make sure require Apache::DB/Apache::DB-init is the first piece of Perl code to run. Thanks heaps, Doug--moving require Apache::DB/Apache::DB-init to the top fixed it! Previously I had 'use Apache' 1st, which worked fine under the "old" version... It's funny the things that change between versions, isn't it? In fact, Apache::DB is now working better than before--I used to have some subs outside of modules that wouldn't break properly... now they work fine! Is anyone aware of any specific reason not to switch to 5.6.0 with mod_perl for production machines (other than just 'in case')? -- Jeremy Howard [EMAIL PROTECTED]
Re: Prb: Apache::DB plus Perl 5.6 doesn't break
On Fri, 19 May 2000, Jeremy Howard wrote: Thanks heaps, Doug--moving require Apache::DB/Apache::DB-init to the top fixed it! kool! Previously I had 'use Apache' 1st, which worked fine under the "old" version... It's funny the things that change between versions, isn't it? In fact, Apache::DB is now working better than before--I used to have some subs outside of modules that wouldn't break properly... now they work fine! right, because Perl decides at compile time if a subroutine call should be dispatched to the debugger, which it won't do unless Apache::DB-init has been called (similar to what -d switch does on the command line) Is anyone aware of any specific reason not to switch to 5.6.0 with mod_perl for production machines (other than just 'in case')? we've hit a few problems, but 1.24 should have them ironed out. can't promise there won't be more though.
PerlFreshRestart Question/Problem
Greetings, [i sent this once, but think it got hung up at the mail server... my apologies if this already went through] I've run into some interesting behaviors with the PerlFreshRestart directive. If I understand correctly, this directive is supposed to force modules to reload when you execute `apachectl restart`, but should otherwise have no effect on performance. On our work servers, enabling "PerlFreshRestart On" in our main conf file caused absolutely incredible and unbearable slow downs. The performance hit was amazing. Pages that normally take 15 seconds or so to load (very large pulls out of a networked Oracle database) took 3 to 4 minutes. Smaller pages that normally come up instantly (still database driven) take 15 to 20 seconds. My home machine did not experience any performance hits, but did experience strange but reproducible problems loading modules on startup. If the module hadn't changed, it wouldn't reload, but change the module and things work again. Stopping the server completely and restarting it didn't help, only changing the module did. Both sites are made up of several modules, and several cgi's running under Apache::Registry with Apache::StatINC enabled. I'm sure I'm missing something that you need to know, so feel free to ask... it was a long night last night... David Veatch - [EMAIL PROTECTED] "Many people would sooner die than think. In fact, they do." - Bertrand Russell
Re: [preview] Search engine for the Guide
On Fri, 19 May 2000, Stas Bekman wrote:
On Fri, 19 May 2000, raptor wrote:
hi,
very interesting. Search for : "statinc" returns nothing and the box get filled
with "tatinc" instead "statinc" ?!?!:")
this under KDE viewer, now will try netscape ...!!
it's not the client -- it's a bug.
This happened after Randy has made non-stemming as a default. When you
turn the stemming on you get it right. Randy, ideas?
Hi,
This was a bug, which was just fixed - 'statinc' now returns
reasonable results. Also, I fixed it so a search term of
$SIG{__DIE__}, for example, also returns some results.
best regards,
randy
Re: RFC: Apache::Request::Forms (or something similar)
On Fri, 19 May 2000, Doug MacEachern wrote: C seems like serious overkill for something to simply generate plain text output. How slow is making a string in perl compared to doing it in C? I can't imagine there's to much of a difference. more like Perl is serious overkill :) SV's are BIG, notice the $unused variable and the B::TerseSize output (from Apache::Status) below, even before a string is copied into it, there's 48 bytes eaten. Well, my point was that the decision to code something in C should be done because it offers an overwhelming (orders of magnitude) improvement, preferably on more than one front (speed, memory, ease of maintenance (haha) ). Really, if you feel that Perl is too memory hungry and slow for even simple text output, then why use Perl at all? My bias is against C because I don't like it and I think it makes the module less accessible to people and therefore less likely to get improved by the community at large, and more likely to only get worked on by 1 person. -dave /*== www.urth.org We await the New Sun ==*/
Re: RFC: Apache::Request::Forms (or something similar)
On Fri, 19 May 2000, Autarch wrote: Well, my point was that the decision to code something in C should be done because it offers an overwhelming (orders of magnitude) improvement, preferably on more than one front (speed, memory, ease of maintenance (haha) ). small savings here and there can add up to big savings in the end. did you look at the size of CGI::start_html? 16k. and that's a small subroutine, these things add up quick. Really, if you feel that Perl is too memory hungry and slow for even simple text output, then why use Perl at all? i never said that. i'm just trying to point out that it's worth considering the savings. My bias is against C because I don't like it and I think it makes the module less accessible to people and therefore less likely to get improved by the community at large, and more likely to only get worked on by 1 person. personally, i like to have generic things written in c, things that won't change much or at all after they are first implemented (not including bug shaking). e.g. Apache::Request. both c and Perl are great languages and blend very well together. both have pros and cons, i try to use the right combo of both to balance these out. c is smaller. c is faster. Perl is much easier to code than c, so i like to save it for things that are difficult to code. generating html is not difficult. is it really worth the time to implement this in c? i'm not convinced yet either, but it is worth thinking about. we need to consider these things if we want to see the Apache/Perl combo improve as a development platform. think big picture.
Re: RFC: Apache::Request::Forms (or something similar)
On Fri, 19 May 2000, Doug MacEachern wrote: personally, i like to have generic things written in c, things that won't change much or at all after they are first implemented (not including bug shaking). e.g. Apache::Request. both c and Perl are great languages and blend very well together. both have pros and cons, i try to use the right combo of both to balance these out. c is smaller. c is faster. Perl is much easier to code than c, so i like to save it for things that are difficult to code. generating html is not difficult. is it really worth the time to implement this in c? i'm not convinced yet either, but it is worth thinking about. we need to consider these things if we want to see the Apache/Perl combo improve as a development platform. think big picture. I would say that the bigger picture is definitely not generating HTML with functions - use templates or stylesheets. just my 2p. -- Matt/ Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org http://xml.sergeant.org
Re: RFC: Apache::Request::Forms (or something similar)
"MS" == Matt Sergeant [EMAIL PROTECTED] writes: MS I would say that the bigger picture is definitely not generating HTML with MS functions - use templates or stylesheets. Templates (especially ones that let you iterate over arrays) are the way to go, in my book, for generating regular HTML. The only problem is with making a template that has sticky forms with non-text fields. Making a sticky menu select object ain't easy in templated-HTML, in my experience. I prefer to do forms (at least the menus and such) using functions for this reason. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D.Khera Communications, Inc. Internet: [EMAIL PROTECTED] Rockville, MD +1-301-545-6996 GPG MIME spoken herehttp://www.khera.org/~vivek/
RE: PerlFreshRestart Question/Problem
-Original Message- From: David Veatch [mailto:[EMAIL PROTECTED]] Sent: Friday, May 19, 2000 11:48 AM To: [EMAIL PROTECTED] Subject: PerlFreshRestart Question/Problem Greetings, [i sent this once, but think it got hung up at the mail server... my apologies if this already went through] I've run into some interesting behaviors with the PerlFreshRestart directive. If I understand correctly, this directive is supposed to force modules to reload when you execute `apachectl restart`, but should otherwise have no effect on performance. On our work servers, enabling "PerlFreshRestart On" in our main conf file caused absolutely incredible and unbearable slow downs. The performance hit was amazing. Pages that normally take 15 seconds or so to load (very large pulls out of a networked Oracle database) took 3 to 4 minutes. Smaller pages that normally come up instantly (still database driven) take 15 to 20 seconds. My home machine did not experience any performance hits, but did experience strange but reproducible problems loading modules on startup. If the module hadn't changed, it wouldn't reload, but change the module and things work again. Stopping the server completely and restarting it didn't help, only changing the module did. I think the title says it best: http://perl.apache.org/guide/troubleshooting.html#Evil_things_might_happen_w hen_us Both sites are made up of several modules, and several cgi's running under Apache::Registry with Apache::StatINC enabled. you're killing yourself with StatINC in production. http://perl.apache.org/guide/porting.html#Configuration_Files_Writing_Dy HTH --Geoff I'm sure I'm missing something that you need to know, so feel free to ask... it was a long night last night... David Veatch - [EMAIL PROTECTED] "Many people would sooner die than think. In fact, they do." - Bertrand Russell
Re: RFC: Apache::Request::Forms (or something similar)
On Fri, May 19, 2000 at 06:08:41PM +0100, Matt Sergeant wrote:
I would say that the bigger picture is definitely not generating HTML with
functions - use templates or stylesheets.
At the very moment, I have a problem to find arguments to persuate my
colleagues to accept this vision. Do you have some arguments that
could be used?
For example, some of our code currently looks like
$display_help = $q-get_preferences_from_db('display_help');
...
show_help('If you want to do that, do it this way ...')
if $display_help;
and show_help touches some global settings (updated per request) to see
if it should print the text with FONT SIZE="-1" or FONT
COLOR="grey", so the logic is in the functions (or methods) that are
called throughout the code or the script/handler.
I'd much better just do something like
push @out, 'HELPIf you want to do that, do it this way .../HELP';
or even generate it with template, and then postprocess this with
stylesheet, and change the color setting or remove the help text
completely, if the user has the $display_help = 0 set because he's an
advanced user. The main objection I hear to this is that you'd need to
parse and substitute something that you could have gotten right in the
first place, and you can do the design changes in the functions as
you'd do in the stylesheet.
Can you help me with some points that I could use to persuate
templates and/or stylesheet for this application?
--
Honza Pazdziora | [EMAIL PROTECTED] | http://www.fi.muni.cz/~adelton/
.project: Perl, DBI, Oracle, MySQL, auth. WWW servers, MTB, Spain.
RE: PerlFreshRestart Question/Problem
At 01:22 PM 5/19/00 -0400, Geoffrey Young wrote: I think the title says it best: http://perl.apache.org/guide/troubleshooting.html#Evil_things_might_happen _when_us Sweet. Thanks. So the problem is probably any number of weak module issues. That's enough for me right now... turning it off certainly fixed it. you're killing yourself with StatINC in production. http://perl.apache.org/guide/porting.html#Configuration_Files_Writing_Dy We really haven't noticed any performance hit... nothing dramatic enough to detect anyway. Our database calls are far more expensive than checking the modules in %INC so far... and we've optimized our use of connections and selects quite a bit. It is certainly a concern that we're keeping in mind, though. David Veatch - [EMAIL PROTECTED] "Many people would sooner die than think. In fact, they do." - Bertrand Russell
Re: RFC: Apache::Request::Forms (or something similar)
Matt, All I'm looking for is the fastest way to print sticky form elements. I already use HTML::Template for the page templating engine (and it works very well!). I need to take a look at CGI v.3 beta to see if it answers some of my concerns about memory usage. Matt Sergeant wrote: On Fri, 19 May 2000, Doug MacEachern wrote: personally, i like to have generic things written in c, things that won't change much or at all after they are first implemented (not including bug shaking). e.g. Apache::Request. both c and Perl are great languages and blend very well together. both have pros and cons, i try to use the right combo of both to balance these out. c is smaller. c is faster. Perl is much easier to code than c, so i like to save it for things that are difficult to code. generating html is not difficult. is it really worth the time to implement this in c? i'm not convinced yet either, but it is worth thinking about. we need to consider these things if we want to see the Apache/Perl combo improve as a development platform. think big picture. I would say that the bigger picture is definitely not generating HTML with functions - use templates or stylesheets. -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
RE: PerlFreshRestart Question/Problem
At 01:22 PM 5/19/00 -0400, Geoffrey Young wrote: I think the title says it best: http://perl.apache.org/guide/troubleshooting.html#Evil_things_might_happen _when_us Sweet. Thanks. So the problem is probably any number of weak module issues. That's enough for me right now... turning it off certainly fixed it. Huh? Wasn't the mod_perl 1.23 supposed to fix this problem with DSO? I thought to remove this item from the Guide. Are there still problems with DSO? If I remember correctly the problem was of broken internal pointers when the DSO code was reloaded. you're killing yourself with StatINC in production. http://perl.apache.org/guide/porting.html#Configuration_Files_Writing_Dy We really haven't noticed any performance hit... nothing dramatic enough to detect anyway. Our database calls are far more expensive than checking the modules in %INC so far... and we've optimized our use of connections and selects quite a bit. It is certainly a concern that we're keeping in mind, though. Attach to one of the servers with 'strace' and see how many stat calls it does with StatINC turned on. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://perl.org http://stason.org/TULARC http://singlesheaven.com http://perlmonth.com http://sourcegarden.org
RE: PerlFreshRestart Question/Problem
"SB" == Stas Bekman [EMAIL PROTECTED] writes: SB Huh? Wasn't the mod_perl 1.23 supposed to fix this problem with DSO? I SB thought to remove this item from the Guide. Are there still problems with SB DSO? DSO works great for me now with the fixes in place of mod_perl 1.23. However, note that PerlFreshRestart is meaningless with DSO -- the whole perl interpreter is torn down and restarted when you have DSO and you restart Apache. The value of PerlFreshRestart is irrelevent at this point. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D.Khera Communications, Inc. Internet: [EMAIL PROTECTED] Rockville, MD +1-301-545-6996 GPG MIME spoken herehttp://www.khera.org/~vivek/
RE: PerlFreshRestart Question/Problem
On Fri, 19 May 2000, Stas Bekman wrote: Huh? Wasn't the mod_perl 1.23 supposed to fix this problem with DSO? I thought to remove this item from the Guide. Are there still problems with DSO? If I remember correctly the problem was of broken internal pointers when the DSO code was reloaded. not quite, the bogus pointers problem was triggered by: LoadModule perl_module libmodperl.so being called twice. not by PerlFreshRestart. any how, dso issues are not 100% ironed out, see Makefile.PL:malloc_check() for example.
RE: PerlFreshRestart Question/Problem
On Fri, 19 May 2000, Doug MacEachern wrote: On Fri, 19 May 2000, Stas Bekman wrote: Huh? Wasn't the mod_perl 1.23 supposed to fix this problem with DSO? I thought to remove this item from the Guide. Are there still problems with DSO? If I remember correctly the problem was of broken internal pointers when the DSO code was reloaded. not quite, the bogus pointers problem was triggered by: LoadModule perl_module libmodperl.so being called twice. Ouch, that's right. not by PerlFreshRestart. any how, dso issues are not 100% ironed out, see Makefile.PL:malloc_check() for example. So the PerlFreshRestart is still an issue. I thought it was resolved as well. The problem was of modules not standing the reload. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://perl.org http://stason.org/TULARC http://singlesheaven.com http://perlmonth.com http://sourcegarden.org
Re: RFC: Apache::Request::Forms (or something similar)
On Fri, 19 May 2000, Matt Sergeant wrote: Damn - forgot smiley. Sorry :-) doh. your reponse combined with my jetlag == foncusion :-)
RE: PerlFreshRestart Question/Problem
I work with David... and figured you guys might like to see what version's we're running... (which is already partially explained by the 1.23 comment below) (Apache) Server Version: Stronghold/2.4.2 Apache/1.3.6 C2NetEU/2410 (Unix) mod_perl/1.21 ApacheJServ/1.0 (Perl) Summary of my perl5 (5.0 patchlevel 5 subversion 3) configuration: Platform: osname=solaris, osvers=2.6, archname=sun4-solaris uname='sunos 5.6 generic_105181-06 sun4u sparc sunw,ultra-1 ' hint=recommended, useposix=true, d_sigaction=define usethreads=undef useperlio=undef d_sfio=undef Compiler: cc='gcc', optimize='-O', gccversion=2.8.1 cppflags='-I/usr/local/include' ccflags ='-I/usr/local/include' stdchar='unsigned char', d_stdstdio=define, usevfork=false intsize=4, longsize=4, ptrsize=4, doublesize=8 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 alignbytes=8, usemymalloc=y, prototype=define Linker and Libraries: ld='gcc', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib /usr/ccs/lib libs=-lsocket -lnsl -ldb -ldl -lm -lc -lcrypt libc=/lib/libc.so, so=so, useshrplib=false, libperl=libperl.a Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' ' cccdlflags='-fPIC', lddlflags='-G -L/usr/local/lib' -Original Message- From: Stas Bekman [mailto:[EMAIL PROTECTED]] Sent: Friday, May 19, 2000 1:07 PM To: David Veatch Cc: Geoffrey Young; [EMAIL PROTECTED] Subject: RE: PerlFreshRestart Question/Problem At 01:22 PM 5/19/00 -0400, Geoffrey Young wrote: I think the title says it best: http://perl.apache.org/guide/troubleshooting.html#Evil_things_might_happen _when_us Sweet. Thanks. So the problem is probably any number of weak module issues. That's enough for me right now... turning it off certainly fixed it. Huh? Wasn't the mod_perl 1.23 supposed to fix this problem with DSO? I thought to remove this item from the Guide. Are there still problems with DSO? If I remember correctly the problem was of broken internal pointers when the DSO code was reloaded. you're killing yourself with StatINC in production. http://perl.apache.org/guide/porting.html#Configuration_Files_Writing_Dy We really haven't noticed any performance hit... nothing dramatic enough to detect anyway. Our database calls are far more expensive than checking the modules in %INC so far... and we've optimized our use of connections and selects quite a bit. It is certainly a concern that we're keeping in mind, though. Attach to one of the servers with 'strace' and see how many stat calls it does with StatINC turned on. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://perl.org http://stason.org/TULARC http://singlesheaven.com http://perlmonth.com http://sourcegarden.org
question - can asp be run as cgi???
Hey dudes, new poster here. I've got a project which the client has said 'no mod perl' but only cgi and perl. They've got a really powerful machine, but are 'afraid' of using mod_perl (because of memory issues, administration etc). Performance should not be an issue. I also have an employee who knows ASP and some perl. I know that if the person writes the web module from scratch (using CGI.pm and perl only), it will take about twice as long as it would with Apache::ASP. So I need to know if I can run the ASP environment without using mod_perl. I've checked out historical postings and noticed that some people (Lincoln Stein - seemingly a lively poster) have questioned the use of ASP and cgi at all - we'll that's exactly my situation. I've also found alot of leads in the right direction, but no final answer (or mysterious ASP.pl program). I've been unable to nail down an answer to the question: Is there a way to run ASP as a cgi program (interchangably). What are the steps involved to do that? Thanks alot for the help, Charles Dalsass www.neptuneweb.com
[ANNOUNCE] AxKit 0.65
This release of AxKit adds XSP support. XSP is a script embedded XML language that is language and output agnostic. All big words, translated to: You can write XSP pages in Perl, Java or Javascript (*). http://xml.sergeant.org/axkit/ Details on XSP: http://xml.apache.org/cocoon/xsp.html (*) Perl supported in AxKit, Java and Javascript supported in Cocoon. -- Matt/ Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org http://xml.sergeant.org
Re: question - can asp be run as cgi???
Charles Dalsass wrote: Hey dudes, new poster here. I've got a project which the client has said 'no mod perl' but only cgi and perl. They've got a really powerful machine, but are 'afraid' of using mod_perl (because of memory issues, administration etc). Performance should not be an issue. I also have an employee who knows ASP and some perl. I know that if the person writes the web module from scratch (using CGI.pm and perl only), it will take about twice as long as it would with Apache::ASP. So I need to know if I can run the ASP environment without using mod_perl. The cgi/asp script in the asp distribution may be your start here, which you may be able to use like: #!/usr/bin/perl asp at the top of your cgi scripts. You could hack it up to set all the special config info you need for your installation. Also you can try putting at the top of a cgi script: use Apache::ASP; Apache::ASP::CGI::do_self; __END__ % ASP script here% This is how the test scripts at t/* work in the dist. Note that I never got Apache::ASP fully working in a cgi environment, so you may have to patch it up. I think grabbing POST or QUERY input wasn't quite there, thus killing the $Request object. Good luck. --Joshua _ Joshua Chamas Chamas Enterprises Inc. NodeWorks free web link monitoring Huntington Beach, CA USA http://www.nodeworks.com1-714-625-4051 I've checked out historical postings and noticed that some people (Lincoln Stein - seemingly a lively poster) have questioned the use of ASP and cgi at all - we'll that's exactly my situation. I've also found alot of leads in the right direction, but no final answer (or mysterious ASP.pl program). I've been unable to nail down an answer to the question: Is there a way to run ASP as a cgi program (interchangably). What are the steps involved to do that? Thanks alot for the help, Charles Dalsass www.neptuneweb.com
Re: LARGE PERL footprint
On Fri, 19 May 2000, David Larkin wrote:
Can anyone help explain why PERL gives such a large memory
footprint advise how to get around it.
Running the simple script below, I get a footprint of 63 MB
about 22 bytes per int.
The C program only 11748 K ... 4 bytes per int
#!/usr/local/bin/perl
for ( $i=0 ; $i 300 ; $i++ )
{
$X[$i]=int(1);
}
main()
{
int x[300];
sleep(60);
}
I guess I'm paying the price for PERL not being strongly typed,
a feature I really like ( until now ;-) )
I require a large array of ints in a real application, just stripped
problem down to bear bones for demo.
I'd be grateful for any advice
When you really need the C/C++ slimness use XS to glue C/C++ code for your
Perl code, don't just switch to C, which can be not development speed
wise.
A great XS tutorial (especially for simple things like your example):
http://perlmonth.com/columns/modules/modules.html?issue=6
http://perlmonth.com/columns/modules/modules.html?issue=7
http://perlmonth.com/columns/modules/modules.html?issue=8
http://perlmonth.com/columns/modules/modules.html?issue=9
http://perlmonth.com/columns/modules/modules.html?issue=10
Enjoy! And encourage Steven McDougall (the author) to write more of this
great stuff :)
_
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://perl.org http://stason.org/TULARC
http://singlesheaven.com http://perlmonth.com http://sourcegarden.org
Re: LARGE PERL footprint
On Fri, 19 May 2000, David Larkin wrote: Can anyone help explain why PERL gives such a large memory footprint advise how to get around it. Your array might be smaller if you pre-extend it to the size you need (see perldata). You could also look at some of the sneaky bit vector modules on CPAN if your data is appropriate for this. And you could try switching between perl's malloc and your system's malloc, though this requires you to build a new version of perl. - Perrin
Re: Questions about Apache::Session
"Edgardo" == Edgardo Szulsztein [EMAIL PROTECTED] writes: Edgardo Then, I tried to use FileStore, and it worked Edgardo fine. However, it stores the sessions files in the /tmp Edgardo directory. How could I change the location of the sessions Edgardo file in the httpd.conf file? Good move. Get it working via FileStore, then get the database version of your session handling going. As for the session file storage, set the SESSION_FILE_DIRECTORY variable, and/or use a 'EMBPERL_SESSION_ARGS "Directory=/web/sessions"'. I threw both into my httpd.conf, which looks like this by the way: PerlSetEnv EMBPERL_SESSION_CLASS Embperl PerlSetEnv SESSION_FILE_DIRECTORY /web/sessions PerlSetEnv EMBPERL_SESSION_CLASSES "FileStore NullLocker" PerlSetEnv EMBPERL_SESSION_ARGS "Directory=/web/sessions" PerlSetEnv EMBPERL_COOKIE_PATH "/" FilesMatch ".*\.e(pl|html)$" PerlSetEnv EMBPERL_OPTIONS 16535 SetHandler perl-script PerlHandler HTML::Embperl Options ExecCGI PerlSendHeader Off /FilesMatch YMMV. Peace.
mod_perl 1.24, nmake test causes Apache Win32 to crash.
hi, I've run into some oddities.. running nmake test causes to seriously crash at "internal/table" while the same test with 1.22 passes fine. Test "internal/api" FAILS for both 1.22 / 1.24 Both are compiled with identical setups using VC6 / WinNT with the 1.3.12 / 5.00503 libs . suggestions, anyone ?? Thomas.
Re: mod_perl 1.24, nmake test causes Apache Win32 to crash.
On Sat, 20 May 2000, Thomas wrote: hi, I've run into some oddities.. running nmake test causes to seriously crash at "internal/table" while the same test with 1.22 passes fine. Test "internal/api" FAILS for both 1.22 / 1.24 Both are compiled with identical setups using VC6 / WinNT with the 1.3.12 / 5.00503 libs . suggestions, anyone ?? Hi, With VC6/Win98, Apache_1.3.12 and Perl-5.6.0, I get the internal/api.t tests passing, but internal/table.t fails. This seems related to one of the changes in Table.xs, as simply using Table.xs from mod_perl-1.23 allows all tests to pass. Running the tests with TEST_VERBOSE=1, which tests fail for you in internal/api.t? best regards, randy kobes
cvs commit: modperl Changes
cholet 00/05/19 09:01:24
Modified:.Changes
Log:
document the fact that I fixed what I'd just broken
Revision ChangesPath
1.488 +3 -0 modperl/Changes
Index: Changes
===
RCS file: /home/cvs/modperl/Changes,v
retrieving revision 1.487
retrieving revision 1.488
diff -u -r1.487 -r1.488
--- Changes 2000/05/19 10:06:04 1.487
+++ Changes 2000/05/19 16:01:22 1.488
@@ -10,6 +10,9 @@
=item 1.24_01-dev
+fix broken Win32 build (unresolved external symbol _ap_configtestonly)
+[Eric Cholet [EMAIL PROTECTED]]
+
=item 1.24 - May 16, 2000
'sub handler : method {}' is now treated as a method handler
