Re: [OT] Re: back-tracking
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tuesday 28 May 2002 12:51 am, Andrew McNaughton wrote: See: Combinatorial Algorithms Nijenhuis and Wilf Academic Press 0-12-519260-6 (1975) P 240 I've got a different problem. I want to auto-link phrases which appear in a dictionary, but I need to do some pre-processing on candidate phrases before checking for them in the dictionary (removing line breaks and punctuation, doing stemming, etc.) If i get a match i want to put an A tag around the phrase. Seems like it shouldn't be too hard, but which ever way I go at it it feels like a messy kludge. Any suggestions? Is the book referenced above going to help with this one? Probably this is off topic. Reply to me personally, and I'll forward to anyone who asks for it. One of the best books for this kind of thing is Mastering Algorithms with Perl. It's got some excellent sections on string matching, stemming, and the like. Details at http://www.oreilly.com/catalog/maperl/ - -- :-get a SMart net/:- -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE88ykxVBc71ct6OywRAie/AKCFypNHvtr8V37FFJX5w7ipuFaw0gCg5nCZ n3twYWvDWrseBOsuSAk2dlM= =u9KU -END PGP SIGNATURE-
RE: Configuring mod_perl on Debian
From: Andrew McNaughton [mailto:[EMAIL PROTECTED]] Sent: 27 May 2002 21:02 To: Ian D. Stewart ... You miss most of the advantage of debian's package management if you start building core components independently. Debian looks after you pretty well, but it's a bit of an all or nothing affair. ie it's worth a little effort to stick with the debian packages if you can. I agree with Andrew - getting Apache, Mod_SSL, PHP4 and mod_perl with PHP4/MySQL and mod_perl/mySQL all co-operating is a relative doddle with Debian packaging. Especially in view of the volume of the 'I cant build...' comments on the mod_perl mailing lists. We usually wget the .debs we want installed as a set, into a dir e.g. /usr/local/deb/build date and then do a dpkg -i *.deb apt-get check FYI, these are SOME of the installed packages on our Dev server yes - it's a bit messy, but it's potato flavoured, with woody extras, and we don't seem to have any issues. - apache 1.3.23-1Versatile, high-performance HTTP server apache-common 1.3.23-1Support files for all Apache webservers libapache-mod-ssl 2.8.7-1 Strong cryptography (HTTPS support) libssl0.9.60.9.6c-1SSL shared libraries mysql-client 3.23.46-2 mysql database client binaries mysql-common 3.23.46-2 mysql database common files libmysqlclient 3.23.38-2 mysql database client library perl 5.6.1-7 Larry Wall's Practical Extraction and libperl5.6 5.6.1-7 Shared Perl library. libapache-dbi-perl 0.88-5 Connect apache server to database via libapache-mod-perl 1.26-2 Integration of perl with the Apache web libapache-reload-perl 0.07-1 Reload changed modules in a mod_perl libapache-request-perl 0.33-1 Generic Apache Request Library libapache-session-perl 1.54-1 Perl modules for keeping persistent libapache-ssi-perl 2.16-1 perl Apache::SSI - Implement Server Side libdbd-mysql-perl 1.2216-2 mySQL database interface for Perl libdbi-perl1.21-2 The Perl5 Database Interface by Tim Bunce php4 4.1.2-1 A server-side, HTML-embedded scripting php4-mysql 4.1.2-1 MySQL module for php4 php4-pear 4.1.2-1 PEAR - PHP Extension Application Reposit -
Re: [RFC] Apache::DigestAPI
ok... after talking things over with Andrew a bit more, Apache::DigestAPI has become Apache::AuthDigest. the package should actually compile and work now, too :) The latest version can be grabbed here: http://www.modperlcookbook.org/~geoff/modules/Apache-AuthDigest-0.01.tar.gz Apache::AuthDigest is a suite of applications for using Digest authentication with mod_perl. It contains: Apache::AuthDigest - re-implementation of the authentication part of mod_digest.c in Perl Apache::AuthzDigest - pick up the authorization pieces of mod_digest Apache::AuthDigest::API - mod_perl API for Digest authentication a la mod_digest Apache::AuthDigest::API::Full - fully RFC 2617 compliant Digest API (not yet implemented) Apache::AuthDigest::API::Session - experimental session API any comments or feedback is welcome, as the look and feel of the suite is still evolving. --Geoff
Re: Configuring mod_perl on Debian
On 2002.05.28 04:03 Jeff A wrote: From: Andrew McNaughton [mailto:[EMAIL PROTECTED]] Sent: 27 May 2002 21:02 To: Ian D. Stewart ... You miss most of the advantage of debian's package management if you start building core components independently. Debian looks after you pretty well, but it's a bit of an all or nothing affair. ie it's worth a little effort to stick with the debian packages if you can. I agree with Andrew - getting Apache, Mod_SSL, PHP4 and mod_perl with PHP4/MySQL and mod_perl/mySQL all co-operating is a relative doddle with Debian packaging. Especially in view of the volume of the 'I cant build...' comments on the mod_perl mailing lists. We usually wget the .debs we want installed as a set, into a dir e.g. /usr/local/deb/build date and then do a dpkg -i *.deb apt-get check FYI, these are SOME of the installed packages on our Dev server yes - it's a bit messy, but it's potato flavoured, with woody extras, and we don't seem to have any issues. - apache 1.3.23-1Versatile, high-performance HTTP server apache-common 1.3.23-1Support files for all Apache webservers libapache-mod-ssl 2.8.7-1 Strong cryptography (HTTPS support) libssl0.9.60.9.6c-1SSL shared libraries mysql-client 3.23.46-2 mysql database client binaries mysql-common 3.23.46-2 mysql database common files libmysqlclient 3.23.38-2 mysql database client library perl 5.6.1-7 Larry Wall's Practical Extraction and libperl5.6 5.6.1-7 Shared Perl library. libapache-dbi-perl 0.88-5 Connect apache server to database via libapache-mod-perl 1.26-2 Integration of perl with the Apache web libapache-reload-perl 0.07-1 Reload changed modules in a mod_perl libapache-request-perl 0.33-1 Generic Apache Request Library libapache-session-perl 1.54-1 Perl modules for keeping persistent libapache-ssi-perl 2.16-1 perl Apache::SSI - Implement Server Side libdbd-mysql-perl 1.2216-2 mySQL database interface for Perl libdbi-perl1.21-2 The Perl5 Database Interface by Tim Bunce php4 4.1.2-1 A server-side, HTML-embedded scripting php4-mysql 4.1.2-1 MySQL module for php4 php4-pear 4.1.2-1 PEAR - PHP Extension Application Reposit - Ok. I'll give it a another go. Interestingly, I have not seen a lot of I can't build this messages on modperl, but have seen a fair number of why isn't this working messages on debian-user. Ian
ANNOUNCE -- CGI::Application 2.4
Version 2.4 of CGI::Application is now available via CPAN! Download site for CGI::Application: http://www.cpan.org/authors/id/J/JE/JERLBAUM/ CHANGES SINCE VERSION 2.1: - Added new module CGI::Application::Mailform as both an example of how to use CGI::Application and a useful (albeit simple) reusable web-based application. - CGI::Application::Mailform allows the contents of data submitted through HTML forms to be easily sent via email to a specified recipient. This application is intended to be very easy to reuse, yet secure and functional enough to replace some of the most onerous mailform scripts which have been floating around the Internet for ages. - Added cgiapp_prerun() hook, for adding global behaviors before the run-mode method is called. The cgiapp_prerun() gets the name of the run-mode as a parameter. This would allow the user to perform some action based on the current run-mode. - Fixed minor bug in build system for older Perl versions. - Modified tmpl_path() to propagate to HTML::Template's PATH parameter. This provides much more useful and intuitive behavior. Thanks to Sam Tregar for the patch! - Added prerun_mode() method to allow the run-mode to be dynamically changed inside the cgiapp_prerun() method. Thanks to Steve Comrie for the suggestion of using a method call for this function. Thanks to many other list members for further refining this idea. - Refactored some test cases, general code clean-up. - Refactored POD a bit to make it less intimidating for new users. Read the recent Using CGI::Application article on Perl.com for an overview of this module and its usage: http://www.perl.com/pub/a/2001/06/05/cgi.html CGI::Application is intended to make it easier to create sophisticated, reusable web-based applications. This module implements a methodology which, if followed, will make your web software easier to design, easier to document, easier to write, and easier to evolve. CGI::Application builds on standard, non-proprietary technologies and techniques, such as the Common Gateway Interface and Lincoln D. Stein's excellent CGI.pm module. CGI::Application judiciously avoids employing technologies and techniques which would bind a developer to any one set of tools, operating system or web server. The guiding philosophy behind CGI::Application is that a web-based application can be organized into a specific set of Run-Modes. Each Run-Mode is roughly analogous to a single screen (a form, some output, etc). All the Run-Modes are managed by a single Application Module which is a Perl module. In your web server's document space there is an Instance Script which is called by the web server as a CGI (or an Apache::Registry script if you're using Apache + mod_perl). CGI::Application is an Object-Oriented Perl module which implements an Abstract Class. It is not intended that this package be instantiated directly. Instead, it is intended that your Application Module will be implemented as a Sub-Class of CGI::Application. If you have any questions, comments, bug reports or feature suggestions, post them to the support mailing list! To join the mailing list, simply send a blank message to [EMAIL PROTECTED].
Re: Patch to mod_perl 1.26: error-notes support
Doug MacEachern wrote:
thanks, i've applied a variation of your patch to cvs and will be in 1.27
if anybody wants to work up a similar patch for Apache::PerlRun, that'd be
nice too.
this seems to work ok as PerlRun and RegistryNG.
--Geoff
--- lib/Apache/PerlRun.pm 25 Mar 2002 01:59:02 - 1.38
+++ lib/Apache/PerlRun.pm 28 May 2002 14:38:03 -
-28,6 +28,12
return bless {r=$r}, $class;
}
+sub xlog_error {
+my($r, $msg) = _;
+$r-log_error($msg);
+$r-notes('error-notes', $msg);
+}
+
sub can_compile {
my($pr) = _;
my $r = $pr-{r};
-52,7 +58,7
$pr-{'mtime'} = -M _;
return wantarray ? (OK, $pr-{'mtime'}) : OK;
}
-$r-log_error($filename not found or unable to stat);
+xlog_error($r, $filename not found or unable to stat);
return NOT_FOUND;
}
-139,7 +145,7
}
if($errsv) {
- $r-log_error($errsv);
+ xlog_error($r, $errsv);
return SERVER_ERROR;
}
-211,6 +217,7
my $pr = shift;
if ($ and substr($,0,4) ne at ) {
$pr-{r}-log_error(PerlRun: `$');
+ $pr-{r}-notes('error-notes', $);
$@{$pr-{r}-uri} = $;
$ = ''; #XXX fix me, if we don't do this Apache::exit() breaks
return SERVER_ERROR;
mod-perl_2.0
Greetings, Have been using modperl successfully now for a couple of years solely as an accelerator for cgi scripts using Apache::Registry (know it can do much more!) ala Stas Beckman's approach using heavy and light webservers with Squid on top. Setting up new Linux webservers and wanted to upgrade to the newest versions of Apache 2.0.36 and found your modperl-2.0 Found mod-perl_1.99 at http://perl.apache.org/dist/ Doug MacEachern's installation instructions were excellent and it seemed as though mod-perl built, tested and installed fine, actually installing mod-perl_2.0 Now my question. In the older version,(126) mod-perl created a larger (heavy) webserver. I could then add a startup.pl file to its http.conf file which used Apache::Registry to load perl and my modules. I don't see how this works in the new version of mod-perl, because I don't see a larger version of the httpd server anywhere. When I did the install it just seemed to load into the Perl 5.6.1 libraries. So how does this work now? If it doesn't or it would take too much time to explain it, I certainly can understand and will simply load and continue to use Apache 1.3.24 and mod-perl 1.26 Did notice in the overview The details of these optimizations from the most part are hidden from mod_perl users, the exception being that some will only be turned on with configuration directives. A few of which include: * Inlined Apache::*.xs calls But not sure how to use it. Thank you for all your hard work on this project, John Kent Webmaster Naval Research Laboratory Monterey California http://kauai.nrlmry.navy.mil/tc-bin/tc_home ~
Re: mod-perl_2.0
On Tue, 28 May 2002, Kent, Mr. John wrote: So how does this work now? If it doesn't or it would take too much time to explain it, I certainly can understand and will simply load and continue to use Apache 1.3.24 and mod-perl 1.26 Things may have changed, in which case someone will gainsay me, but my understanding is that modperl with apache 2 is not reccomended for production use. My guess is that while there will be early adopters, apache 2 will take at least a year to become the standard. A lot has changed, and for most users there's no compelling reason to update. Andrew
Re: Configuring mod_perl on Debian
On Tue, 28 May 2002, Ian D. Stewart wrote: Date: Tue, 28 May 2002 08:14:26 -0400 From: Ian D. Stewart [EMAIL PROTECTED] To: Jeff A [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: Configuring mod_perl on Debian On 2002.05.28 04:03 Jeff A wrote: From: Andrew McNaughton [mailto:[EMAIL PROTECTED]] Sent: 27 May 2002 21:02 To: Ian D. Stewart ... You miss most of the advantage of debian's package management if you start building core components independently. Debian looks after you pretty well, but it's a bit of an all or nothing affair. ie it's worth a little effort to stick with the debian packages if you can. I agree with Andrew - getting Apache, Mod_SSL, PHP4 and mod_perl with PHP4/MySQL and mod_perl/mySQL all co-operating is a relative doddle with Debian packaging. Especially in view of the volume of the 'I cant build...' comments on the mod_perl mailing lists. We usually wget the .debs we want installed as a set, into a dir e.g. /usr/local/deb/build date and then do a dpkg -i *.deb apt-get check FYI, these are SOME of the installed packages on our Dev server yes - it's a bit messy, but it's potato flavoured, with woody extras, and we don't seem to have any issues. - apache 1.3.23-1Versatile, high-performance HTTP server apache-common 1.3.23-1Support files for all Apache webservers libapache-mod-ssl 2.8.7-1 Strong cryptography (HTTPS support) libssl0.9.60.9.6c-1SSL shared libraries mysql-client 3.23.46-2 mysql database client binaries mysql-common 3.23.46-2 mysql database common files libmysqlclient 3.23.38-2 mysql database client library perl 5.6.1-7 Larry Wall's Practical Extraction and libperl5.6 5.6.1-7 Shared Perl library. libapache-dbi-perl 0.88-5 Connect apache server to database via libapache-mod-perl 1.26-2 Integration of perl with the Apache web libapache-reload-perl 0.07-1 Reload changed modules in a mod_perl libapache-request-perl 0.33-1 Generic Apache Request Library libapache-session-perl 1.54-1 Perl modules for keeping persistent libapache-ssi-perl 2.16-1 perl Apache::SSI - Implement Server Side libdbd-mysql-perl 1.2216-2 mySQL database interface for Perl libdbi-perl1.21-2 The Perl5 Database Interface by Tim Bunce php4 4.1.2-1 A server-side, HTML-embedded scripting php4-mysql 4.1.2-1 MySQL module for php4 php4-pear 4.1.2-1 PEAR - PHP Extension Application Reposit - Ok. I'll give it a another go. Interestingly, I have not seen a lot of I can't build this messages on modperl, but have seen a fair number of why isn't this working messages on debian-user. It's not just about ease of getting started, it's about ease of maintenance over time. debian makes it very easy to keep your software up to date (though you shouldn't even think about letting debian's package configuration mess with your httpd.conf once you get going) Also, if you want to install any debian package that depends on apache, then debian is going to want a debian apache installation, and you have to start jumping through hoops to keep it happy, or installing all the other packages from source, which then also lose out on debian's tools for keeping them up to date. Andrew
Invoke PHP scripts?
Hi there, Apologies if this has been asked 2^32 times, but I couldn't seem to find anything in the archives or on the web which would solve my problem. I'm developing a large-ish web site in which I would like to use a combination of mod_perl (90%) and PHP (10%). I have run into a roadblock trying to include the output of a PHP script from a mod_perl script. This would do fine: my $r = Apache-request(); return $r-lookup_uri($url)-run; But (and I am familiar with why this happens) run() dumps the results to STDOUT, so the final HTML does not come through in the correct order. I tried to use Apache::SSI in this manner: my $r = Apache-request(); my $ssi = Apache::SSI-new($contents, $r); return $ssi-get_output(); (Where $contents is the raw PHP source), but, possibly because of some Content-type mixup, the output is returned as expected (i.e., not dumped to stdout), but the PHP source is not interpreted. So, in short, I need another way to invoke a PHP script from my mod_perl application... exactly what !--#include virtual=... -- would do. Help..? :-) - Ryan -- Ryan Thompson [EMAIL PROTECTED] SaskNow Technologies - http://www.sasknow.com 901 1st Avenue North - Saskatoon, SK - S7K 1Y4 Tel: 306-664-3600 Fax: 306-664-3630 Saskatoon Toll-Free: 877-727-5669 (877-SASKNOW) North America
