Re: search engine module?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 People have been talking about backend search engines, but when I saw the subject I was thinking more about front end classes. In particular, last time I looked there wasn't a standard class for integrating local search engines into your code. I ended up making a WWW::Search, but you kind of have to tweak the meaning of some values. If anyone is interested I ought to release it. It's a trivial example for very small web sites (it provides google-like search syntax, and backends it with grep). - -- Kee Hinckley - Somewhere.Com, LLC http://consulting.somewhere.com/ [EMAIL PROTECTED] (or ...!alice!nazgul for time travelers :-) I'm not sure which upsets me more: that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's. -BEGIN PGP SIGNATURE- Version: PGP Personal Security 7.0.3 iQA/AwUBO88CGCZsPfdw+r2CEQLj9ACfSqjkFgwvFR0iXWRRS9B2oM6EcZ8AoNSd 6jkha/LM8cS1ia4mYti8tiGW =yXL9 -END PGP SIGNATURE-
Re: search engine module?
Kee Hinckley wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 People have been talking about backend search engines, but when I saw the subject I was thinking more about front end classes. In particular, last time I looked there wasn't a standard class for integrating local search engines into your code. I ended up making a WWW::Search, but you kind of have to tweak the meaning of some values. If anyone is interested I ought to release it. It's a trivial example for very small web sites (it provides google-like search syntax, and backends it with grep). You should have checked CPAN first: There is a load of WWW::Search:: modules there. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: search engine module?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 At 12:56 AM +0800 10/19/01, Stas Bekman wrote: Kee Hinckley wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 People have been talking about backend search engines, but when I saw the subject I was thinking more about front end classes. In particular, last time I looked there wasn't a standard class for integrating local search engines into your code. I ended up making a WWW::Search, but you kind of have to tweak the meaning of some values. If anyone is interested I ought to release it. It's a trivial example for very small web sites (it provides google-like search syntax, and backends it with grep). You should have checked CPAN first: There is a load of WWW::Search:: modules there. Yes. But my point is that they are all *offsite* searches as far as I can tell. What I wanted was a standard interface to a local search engine. - -- Kee Hinckley - Somewhere.Com, LLC http://consulting.somewhere.com/ [EMAIL PROTECTED] (or ...!alice!nazgul for time travelers :-) I'm not sure which upsets me more: that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's. -BEGIN PGP SIGNATURE- Version: PGP Personal Security 7.0.3 iQA/AwUBO88W3yZsPfdw+r2CEQLQ8wCgrokvPCmktlUCSLPulsZsVwrBMdwAoMMQ V1vsViU2nutZioKmgwVnqV22 =03cp -END PGP SIGNATURE-
Re: PerlModule not updating %INC
At 1.13 +0800 10/17/2001, Stas Bekman wrote: David Pisoni wrote: At 18.23 -0400 10/11/2001, Perrin Harkins wrote: At 18.07 -0400 10/11/2001, Perrin Harkins wrote: We are using perl 5.6.0 for Apache 1.3/20, with mod_perl 1.26. Are you sure? There was a problem with %INC and PerlModule, but I thought it was fixed in 1.26. - Perrin Indeed, like I said, I tested it by dumping %INC myself -- the modules are indeed missing when loaded with PerlModule. No, I meant are you sure you're running 1.26? Please doublecheck it, since this sounds so much like the bug from the previous release. - Perrin Indeed, here's the signature from Apache::Status : Embedded Perl version v5.6.0 for Apache/1.3.20 (Unix) (Red-Hat/Linux) mod_perl/1.26 Apache.pm shows v1.27 (that's a little weird, but I assume unimportant.) Thanks, David So... any ideas on this one? have you tried 5.6.1? 5.6.0 is very buggy. Just tried it. Fresh build of 5.6.1, and mod_perl 1.26 against it. The problem persists -- %INC is incomplete vs. my actual loaded modules, missing what was loaded with PerlModule directives. What should I try next. :-) David
Problem using mod_perl-1.26 with perl 5.6.1 and XML::Parser
Hi gang, I am fairly new to mod_perl, but I would like to share my recent experience and hope someone might offer some insight into my troubles. Last week I whipped together a simple perl module that used XML::Simple ( a wrapper for XML::Parser) to parse some POST'd content. Once parsed the resulting data was munched a bit and then POST'd to another web server. Like everything perl it was quick to implement and ran quick as well. My problems came along when I moved my module to another server. All of sudden Apache would segfault in the Expat library code when my module parsed the content. I noticed that I had different versions of XML::Parser on the different machines (2.29 vs. 2.30). XML::Parser-2.29 was the one on the working instance so I downgraded the box that was segfaulting. When I down graded the segfaults went away but a nasty little problem showed up latter in the module where the data being sent in my module's post was getting corrupted. I narrowed down the problem to the call to running the XML parser being related to the data corruption. At this point I found this mail list and searched the archive. There were lots of references to the Expat problem where Apache itself uses a copy of Expat and a XML::Parser would use a different version of the Expat. There was discussion about required configuration parameters to mod perl, but more importantly there was a post mentioning that Apache 1.3.22 made the whole problem go away. Feeling inspired by my new found knowledge of the problem, I decided a clean install of the new apache was in order. To be safe, I reinstalled RedHat 7.1 without RedHat's apache. I uninstalled perl 5.6.0 that came with RH7.1 and installed perl 5.6.1. I followed the simple mod_perl install instructions that builds apache with perl statically linked. My resulting install didn't segfault, but my nasty bug was still there. At this point I went back and fully duplicated the working implementation: Apache 1.3.19, mod_perl 1.26 perl-5.005_3 and XML::Parser-2.29. The originally working system was on RH 6.2, and this configuration worked on my new machine using RH 7.1. This configuration was built with the following commands: tar zxf apache_1.3.19.tar.gz cd apache_1.3.19 ./configure --prefix=/lsurf/apache --enable-shared=max --enable-module=all make make install cd .. tar zxf mod_perl-1.26.tar.gz cd mod_perl-1.26 perl Makefile.PL USE_APXS=1 APACHE_PREFIX=/lsurf/apache EVERYTHING=1 make make install Now that I had something reproducible, I continued. I rebuilt using Apache 1.3.22 just like above, and everything continued to work. I upgraded to XML::Parser-2.30, and things continued to work. It was only when I went from perl 5.005_3 to 5.6.1 did my module break. As I said above I tried a statically linked apache. I also tried building Apache 1.3.22 as above with perl 5.6.1 and my code failed with both XML::Parser-2.29 and XML::Parser-2.30. Whatever way I tried using perl 5.6.1 I had my nasty problem. When configuring Apache 1.3.22 I noticed it said it was using the system's libexpat which was installed with RH. XML::Parser-2.29 uses its own copy of expat, but XML::Parser-2.30 uses the system libexpat. As I said with perl 5.005_3 I was able to use either version of XML::Parser. In the end I have a working implementation using perl-5.005_3, but I'd sure feel better using the latest stable perl, and it should work as far as I can tell. If anyone has some suggestions I'd be willing to give them a try. Thanks for your patience if you read this long winded post. Matthew
Excellent article on Apache/mod_perl at eToys
Hello, I checked the list archives and it didn't look like this had been posted yet. For those of you who haven't seen it yet... a great read on perl.com about the Apache/mod_perl setup at eToys, co-authored by our own mod_perl regular contributer Perrin Harkins. http://www.perl.com/pub/a/2001/10/17/etoys.html Humbly, Andrew -- Andrew Ho http://www.tellme.com/ [EMAIL PROTECTED] Engineer [EMAIL PROTECTED] Voice 650-930-9062 Tellme Networks, Inc. 1-800-555-TELLFax 650-930-9101 --
Re: search engine module?
Kee Hinckley wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 At 12:56 AM +0800 10/19/01, Stas Bekman wrote: Kee Hinckley wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 People have been talking about backend search engines, but when I saw the subject I was thinking more about front end classes. In particular, last time I looked there wasn't a standard class for integrating local search engines into your code. I ended up making a WWW::Search, but you kind of have to tweak the meaning of some values. If anyone is interested I ought to release it. It's a trivial example for very small web sites (it provides google-like search syntax, and backends it with grep). You should have checked CPAN first: There is a load of WWW::Search:: modules there. Yes. But my point is that they are all *offsite* searches as far as I can tell. What I wanted was a standard interface to a local search engine. Right, my point is that WWW::Search namespace is taken :) -- _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: search engine module?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
At 11:36 AM +0800 10/19/01, Stas Bekman wrote:
Right, my point is that WWW::Search namespace is taken :)
Ah. Sorry, my miscommunication. When I said that I ended up making
a WWW::Search I should have put an an instance of in there instead
of a. Basically WWW::Search provided a good interface, but
everything was remote, so I wrote this. If you stick to the
conventions provided here, it should be easy to make other variations
using other local search engines. I was just surprised that nobody
seemed to have done it before.
Grep(3)User Contributed Perl DocumentationGrep(3)
NAME
WWW::Search::Grep - class for searching a local web site
using grep
SYNOPSIS
require WWW::Search;
$search = new WWW::Search('Grep');
DESCRIPTION
This is a grep specialization of WWW::Search.
THis class exports no public interface; all interaction
should be done through WWW::Search objects.
OPTIONS
The default query syntax is: word word OR word
quoted phrase Blank separated words are implicitly
separated by AND. OR refers only to the word or phrases
directly to either side. The model is the same as that
used by Google (http://www.google.com/).
search_url
Specifies the directory to search. All .html and .htm
files in the specified directory and any
subdirectories will be searched. This is an absolute
pathname and is required. E.g.
/home/httpd/html/foo/searchdir/
base_path
This is this is the part of that pathname that should
be stripped off before prefixing the base_url. This
is required. E.g. /home/httpd/html/
base_url
This is prepended to the pathname after stripping the
base_path. This is optional, the default is none.
E.g. http://www.somewhere.com/ or /
search_debug,search_parse_debug
See WWW::Search
grep
Pathname to grep, default is /bin/egrep.
AUTHOR
Kee Hinckley, [EMAIL PROTECTED]
- --
Kee Hinckley - Somewhere.Com, LLC
http://consulting.somewhere.com/
[EMAIL PROTECTED] (or ...!alice!nazgul for time travelers :-)
I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.
-BEGIN PGP SIGNATURE-
Version: PGP Personal Security 7.0.3
iQA/AwUBO8+mtSZsPfdw+r2CEQI1+wCeI3s9JcPuXvaexrriahCWnjtTS/kAnjl3
v7uvLYWz4xxxc2weT/qU0f2n
=MXIA
-END PGP SIGNATURE-
cvs commit: modperl-2.0/ModPerl-Registry .cvsignore
stas01/10/18 20:00:15 Modified:ModPerl-Registry .cvsignore Log: ignore files Revision ChangesPath 1.2 +1 -0 modperl-2.0/ModPerl-Registry/.cvsignore Index: .cvsignore === RCS file: /home/cvs/modperl-2.0/ModPerl-Registry/.cvsignore,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- .cvsignore2001/10/18 04:25:12 1.1 +++ .cvsignore2001/10/19 03:00:15 1.2 @@ -1,2 +1,3 @@ Makefile pm_to_blib +blib
Re: perl.apache.org / apache.perl.org
Nathan Torkington wrote: Ken Williams writes: Not that I dislike them - the current colors let me look at the page for a few seconds, then shut off the monitor and read the text while staring at a blank white sheet of paper. man, that was so strong, I thought I've hit some wrong link :) I'm impressed that you suffered such intense retinal distress and never made the logical deduction that I'm colour-blind. (I am :-) In many ways the colours are the last-important part, but I like the idea of having something bright to catch attention. if you can define them in one place, like CSS, that's true, otherwise it's pain to maintain. Though I prefer mild colours, not shouting ones. I use the site all the time, and I don't need to be shouted at. May be we want a splash page just for some entrance page, which those who use the site daily don't have to see. I like the colours at use.perl.org and even more the ones used by http://freshmeat.net/. In any case, I like the organizational scheme you've got. Having everything on a single page was a pain in the butt. Glad to hear it. If nobody objects to the structure, we could put it into CVS and open it up for others to work on. If I'm the only one working on it, it'll take far too long. Does this sound the right time for CVS? cvs where? it has to stay at perl.apache.org I believe. Also what components framework have you used, is it Mason? Is it a static page or dynamic? Otherwise it's good to have someone to push for a change, I think I'll help with the content once we figure out the skeleton. But it'd be nice to give some good web-designer do some brushing, no offense Nat :) We can show it on the modperl list and ask for a better look and feel from those who know how. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
cvs commit: modperl-2.0/pod modperl_dev.pod
stas01/10/18 19:17:10 Modified:pod modperl_dev.pod Log: - document the existance of PerlInitHandler Revision ChangesPath 1.42 +2 -0 modperl-2.0/pod/modperl_dev.pod Index: modperl_dev.pod === RCS file: /home/cvs/modperl-2.0/pod/modperl_dev.pod,v retrieving revision 1.41 retrieving revision 1.42 diff -u -r1.41 -r1.42 --- modperl_dev.pod 2001/09/28 20:23:04 1.41 +++ modperl_dev.pod 2001/10/19 02:17:10 1.42 @@ -473,6 +473,8 @@ =item PerlPostReadRequestHandler +=item PerlInitHandler + =item PerlTransHandler =back
Re: perl.apache.org / apache.perl.org
Ask Bjoern Hansen writes: I'll chew on a new layout and give you something by the end of the week. Thanks, awesome! :-) I did have something by the end of last week, just not much. I'd hoped to find the time to plug the holes this week, but haven't been able to. So here it is, woefully incomplete. The URL is: http://c1853353-a.ftclns1.co.home.com/~gnat/modperl/ I've got: * Home page * About * Download done. My plan was to just go through perl.apache.org and move content into that framework (for instance, success stories and testimonials go as a page under 'About'). There are some web design To Do items: * ensure colors are part of the standard palette (right now they're just easy to type in hex :-) * contemplate CSS and enforcing standards like all links are in bold. Nat
Re: perl.apache.org / apache.perl.org
Nathan Torkington [EMAIL PROTECTED] wrote: There are some web design To Do items: * ensure colors are part of the standard palette (right now they're just easy to type in hex :-) Holy shit Nat, those colors are strong. =) You've really taken attention-getting into the twenty-first century! Not that I dislike them - the current colors let me look at the page for a few seconds, then shut off the monitor and read the text while staring at a blank white sheet of paper. In any case, I like the organizational scheme you've got. Having everything on a single page was a pain in the butt. -Ken
cvs commit: modperl-2.0/ModPerl-Registry/t TEST.PL
stas01/10/18 19:40:41
Modified:ModPerl-Registry/t TEST.PL
Log:
- allow 2 maxclients, since some tests generate two requests at the same
time (one from within the other)
Revision ChangesPath
1.2 +15 -8 modperl-2.0/ModPerl-Registry/t/TEST.PL
Index: TEST.PL
===
RCS file: /home/cvs/modperl-2.0/ModPerl-Registry/t/TEST.PL,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- TEST.PL 2001/10/09 12:47:38 1.1
+++ TEST.PL 2001/10/19 02:40:41 1.2
@@ -3,15 +3,22 @@
use strict;
use warnings FATAL = 'all';
-# XXX: fixme
-#use lib map { $_/Apache-Test/lib } qw(. ..);
-#use lib map { $_/blib/lib} qw(. .. ../..);
-#use lib map { $_/lib } qw(. .. ../..);
-#use blib map { $_ } qw(. .. ../..);
-
use lib map {(../blib/$_, ../../blib/$_)} qw(lib arch);
-#use blib qw(..);
use Apache::TestRunPerl ();
+
+package MyTest;
+
+our @ISA = qw(Apache::TestRunPerl);
+
+# subclass new_test_config to add some config vars which will be
+# replaced in generated httpd.conf
+sub new_test_config {
+my $self = shift;
+
+$self-{conf_opts}-{maxclients} = 2;
+
+return $self-SUPER::new_test_config;
+}
-Apache::TestRunPerl-new-run(@ARGV);
+MyTest-new-run(@ARGV);
cvs commit: modperl-2.0/ModPerl-Registry/t/conf .cvsignore
stas01/10/18 19:58:57 Modified:ModPerl-Registry/t/conf .cvsignore Log: ignore files Revision ChangesPath 1.2 +3 -0 modperl-2.0/ModPerl-Registry/t/conf/.cvsignore Index: .cvsignore === RCS file: /home/cvs/modperl-2.0/ModPerl-Registry/t/conf/.cvsignore,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- .cvsignore2001/10/09 12:47:38 1.1 +++ .cvsignore2001/10/19 02:58:57 1.2 @@ -1,3 +1,6 @@ extra.conf httpd.conf apache_test_config.pm +modperl_inc.pl +modperl_startup.pl +
