cvs commit: modperl-2.0/t/response/TestApache compat2.pm
dougm 02/04/07 14:41:33
Modified:t/response/TestApache compat2.pm
Log:
needs adjustment after fix to Apache::compat
Revision ChangesPath
1.4 +1 -1 modperl-2.0/t/response/TestApache/compat2.pm
Index: compat2.pm
===
RCS file: /home/cvs/modperl-2.0/t/response/TestApache/compat2.pm,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- compat2.pm7 Apr 2002 01:25:14 - 1.3
+++ compat2.pm7 Apr 2002 21:41:33 - 1.4
-18,7 +18,7
42 =1k,
42_000 = 41k,
42_000_000 = 40.1M,
-42_000_000_000 = 40054.3M,
+42_000_000_000 = 40054M,
);
sub handler {
Re: sun4-solaris polluted installation
Hi there, On Sat, 6 Apr 2002, Slava Bizyayev wrote: a lot of mess in common perl libraries. What of that could affect the installation? All sorts of things, but I'm still puzzled. To my mind you do not yet have enough evidence to point to a particular part of the system. If your production system were not using Perl in any way I would suggest that you delete the entire Perl installation and rebuild it from scratch with 5.6.1. (Actually I prefer 5.7.2 but I hesitate to suggest it for production use even though it seems fine to me. :) If it were my machine that is what I would do, production or not, because you really need to be able to rely on your Perl installation and at the moment evidently you cannot. Of course there is a risk that something would break, so you might prefer to rename the old Perl installation rather than delete it. You should of course make sure that the same compiler which built Perl also built mod_perl, for preference also using the same C libraries. Have you tried to run Perl's own 'make test' suite? 73, Ged.
Re: [announce] mod_perl-1.99_01
You might want to reconsider the use of VT escape codes in the build process. The red error message was cute, but there's a big potential downside (see attached screenshot). In the words of the W3C's CSS validator: You have no background-color with your color :) -John not-so-clever.gif Description: GIF image
[ANNOUNCE] Cache::Cache 1.0
Hi, The following is an announcement of Cache::Cache 1.0. Please read the summary below for more details. I want to ask a special favor of the modperl community (who tend to get a lot of mileage out of this code) -- I'm concerned with the use of Digest::MD5, particularly version 2.16, which is used by the code to generate unique filenames in the file-based cache. I've been seeing some pretty ugly bugs with the the MD5 code, and this has been confirmed on a few mailing lists and CPAN bug reports. Please let me know if you notice any weird behavior with your system after upgrading to version 1.0. (All unit test pass consistently, but under certain conditions, such as when XML::DOM is loaded, I think that Digest::MD5 may always return the same hash, no matter what the key.) Note that you can simply run Digest::MD5 2.12 and not 2.16 if you have any issues in production. So don't worry about upgrading to version 1.0 of Cache::Cache. I'm thinking of switching to Digest::SHA1 in version 1.01 to avoid this until a new version of Digest::MD5 is released. Does anyone know of a reason to avoid that? (SHA1 is slightly slower, but very little time in spent generating keys anyway, so it may not be a big deal.) For more information on the MD5 issue, please see: http://rt.cpan.org/NoAuth/Bug.html?id=362. Thanks to everyone for your help. Cheers, -DeWitt Summary: The Cache modules are designed to assist a developer in persisting data for a specified period of time. Often these modules are used in web applications to store data locally to save repeated and redundant expensive calls to remote machines or databases. People have also been known to use Cache::Cache for its straightforward interface in sharing data between runs of an application or invocations of a CGI-style script or simply as an easy to use abstraction of the filesystem or shared memory. Release Notes: Release of Cache::Cache version 1.0. This version fixes outstanding issues on Win32 platforms and other minor bug fixes. Project Homepage: http://perl-cache.sourceforge.net/ Tar/GZ: http://prdownloads.sourceforge.net/perl-cache/Cache-Cache-1.0.tar.gz http://www.cpan.org/authors/id/D/DC/DCLINTON/Cache-Cache-1.0.tar.gz Changelog: http://sourceforge.net/project/shownotes.php?release_id=83292 CVS tree (viewcvs): http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/perl-cache/ The following is the Cache-Cache-1.0 README file: Copyright (C) 2001 DeWitt Clinton All Rights Reserved You may distribute under the terms of either the GNU General Public License or the Artistic License, as specified in the Perl README file. NAME Cache::Cache DESCRIPTION The Cache modules are designed to assist a developer in persisting data for a specified period of time. Often these modules are used in web applications to store data locally to save repeated and redundant expensive calls to remote machines or databases. People have also been known to use Cache::Cache for its straightforward interface in sharing data between runs of an application or invocations of a CGI-style script or simply as an easy to use abstraction of the filesystem or shared memory. The Cache package provides Cache::Cache, a generic interface for creating persistent data stores. This interface is implemented by the Cache::MemoryCache, Cache::SharedMemoryCache, Cache::FileCache, Cache::SizeAwareFileCache, Cache::SizeAwareMemoryCache, and Cache::SizeAwareSharedMemoryCache classes. This work aggregates and extends the obsolete File::Cache and IPC::Cache projects. REQUIREMENTS Digest::MD5 Error File::Spec File::Path IPC::ShareLite Storable INSTALLATION perl Makefile.PL make make test make install USAGE First, choose the best type of cache implementation for your needs. The simplest cache is the MemoryCache, which is suitable for applications that are serving multiple sequential requests, and wish to avoid making redundant expensive queries, such as an Apache/mod_perl application talking to a database. If you wish to share that data between processes, then perhaps the SharedMemoryCache is appropriate, although its behavior is tightly bound to the underlying IPC mechanism, which varies from system to system, and is unsuitable for large objects or large numbers of objects. When the SharedMemoryCache is not acceptable, then FileCache offers all of the same functionality with similar performance metrics, and it is not limited in terms of the number of objects or their size. If you wish to maintain a strict limit on the size of a file system based cache, then the SizeAwareFileCache is the way to go. Similarly, the SizeAwareMemoryCache and the SizeAwareSharedMemoryCache add size management functionality to the MemoryCache and SharedMemoryCache classes respectively. Using a cache is simple. Here is some sample code for instantiating and using a file system
Re: PDF generation
On Sun, Apr 07, 2002 at 02:11:39AM +0200, Patrick wrote: On Wed, Apr 03, 2002 at 03:43:39PM -0500, Bill McCabe took time to write: I have a large number of mod_perl modules that connect to various databases and generate workflow performance reports for my organization. I give the users 3 output options: HTML, Excel (Spreadsheet::WriteExcel), and PDF. For PDF output I've been using PDF::Create, which has been at version .01 since 1999. It has worked flawlessly for my purposes for a couple of years, but is very limited. In fine form-follows-function fashion, the end users would now like the PDF output gussied up with graphics, etc. Does anyone have any strong (positive or negative) recommendations for which module(s) I should migrate to? I do not use Perl modules to do that, but LaTeX. As ugly as it may sound it enables to output very complex PDF files, exactly the way you want. More precisely I have LaTeX templates, I use CGI::FastTemplate to fill them in with dynamic data, run pdflatex, and then have a nice PDF file. Sounds like an interesting solution, but how long does it take to generate the pdf files? I need something that will insert data into PDF's at certain positions (they may change) and I was looking wheter it would be possible doing something like CGI::FastTemplate just for PDF's. The only requirement would be that you could use _any_ program that generates PDF's to generate these templates. So I built part of a PDF parser that would extract the text portions of a PDF, but then I found that a PDF generated by Adobe Distiller (just as an example) generates text sections that look something like: [(Kv)25.1(ar r)9.9(adioj mangxas la fla)20(v)24.8(a)] for the simple text of Kvar radioj mangxas la flava. Doesn't that just look hopeless to parse? I'm about to give up on this solution, any comments? -- Thomas Eibner http://thomas.eibner.dk/ DnsZone http://dnszone.org/ mod_pointer http://stderr.net/mod_pointer http://photos.eibner.dk/
Re: Ordering in %INC for PerlRestart
Hi there, On Tue, 2 Apr 2002, [iso-8859-1] Sreeji K Das wrote: I use PerlFreshRestart on to reload my modules. [snip] However, here my modules are getting loaded before the PerlRequire'd is loaded (since %INC is a hash). First, can some1 suggest a solution for this ? I always stop (with SIGTERM) and start my servers rather than using restart (SIGUSR1) as I find that there are fewer surprises. I think that Perrin will agree. There are very few systems that can't cope with a few seconds of downtime. 73, Ged.
Re: [ANNOUNCE] Cache::Cache 1.0
DeWitt Clinton wrote: [snip] I've actually meanty to ask this for a while: I'm curious as to the auto_purge functionality of Cache::Cache - especially under mod_perl... I tend to use it a lot, but from time to time, which is basically EVERY time I look at /tmp, I notice bunches of stale entries from Cache::FileCaches - and that's on the development server. So how exactly is the auto_purge meant to be used - the documentation is very hazy on that point (sure I can patch it - but you have to explain it to me first :)), and I just got lost when looknig at the module source. So: 1)What is it meat to do 2) How should it be used 3) What about constistancy issues between processes - when will perl forget what's in the cache and not clean it up? Thanks, Issac
mod_perl 1.99 and Apache::compat
Well, here be a bug report I compiled Apache 2.0.35 with mod_perl 1.99 as a DSO. The server will start just fine with that. I'm running on GNU/Linux with Perl 5.6.1. If I add this: PerlModule Apache2 PerlModule Apache::compat The server simply will not start. If I comment out all the 'use' statements, except for mod_perl and Symbol, from Apache/compat.pm, then the server starts. If I load all the modules I just commented out via PerlModule in the config file and I _don't_ load Apache::compat, the server starts. If I load all the modules I commented out and try to load Apache::compat (with those use statements still commented out), the server will not start. I also found a few tiny bugs in Apache::compat. - The read() call in send_fd_length needs to be CORE::read. - In the last elsif in size_string, the size variable is missing its dollar sign ($). -dave /*== www.urth.org we await the New Sun ==*/
Re: mod_perl 1.99 and Apache::compat
On Sun, 7 Apr 2002, Dave Rolsky wrote:
I also found a few tiny bugs in Apache::compat.
- The read() call in send_fd_length needs to be CORE::read.
- In the last elsif in size_string, the size variable is missing its
dollar sign ($).
Here's a patch:
--- compat.pm.~1.35.~ Sat Mar 23 20:38:01 2002
+++ compat.pm Sun Apr 7 14:19:46 2002
-259,7 +259,7
$len = IOBUFSIZE;
}
-while (read($fh, $buff, $len)) {
+while (CORE::read($fh, $buff, $len)) {
$total_bytes_sent += $r-puts($buff);
}
-369,7 +369,7
elsif ($size 1048576) {
$size = sprintf %4dk, ($size + 512) / 1024;
}
-elsif (size 103809024) {
+elsif ($size 103809024) {
$size = sprintf %4.1fM, $size / 1048576.0;
}
else {
Re: [ANNOUNCE] Cache::Cache 1.0
On Sun, Apr 07, 2002 at 08:52:59PM +0300, Issac Goldstand wrote: So how exactly is the auto_purge meant to be used - the documentation is very hazy on that point (sure I can patch it - but you have to explain it to me first :)), and I just got lost when looknig at the module source. The auto_purge functionality is designed to enable a cache to delete expired cache entries periodically. While user code could call the purge( ) method every time they access the cache, it would be rather inefficient and often completely unnecessary. Thus the auto_purge code automatically calls purge( ) after a user specified interval of time has elapsed. You set the amount of time between auto_purges by setting the 'auto_purge_interval' option when instantiating the cache. After setting the 'auto_purge_interval' the purge method will be called when a cache instance is created (via 'new') and the time interval has elapsed. Also, by setting 'auto_purge_on_set' to true, the cache will automatically call purge when the 'set' method is called and the time interval has elapsed. Respectively, by setting 'auto_purge_on_get' to true, the cache will automatically call purge when the 'get' method is called and the time interval has elapsed. If you tend to instantiate caches relatively frequently (such as during the initialization of a modperl process), you can probably get away with simply setting the 'auto_purge_interval'. However, if you processes run for a long time and you'd like to automatically call purge( ) more frequently, you can could consider using the 'auto_purge_on_set' option. I'd be surprised if people were using the 'auto_purge_on_get' functionality, as it would most likely be overkill. Also, keep in mind that if you hit the same keys over and over again, then it may be sufficient to rely on 'get' to delete expired entries when they are requested. Hope this helps clarify things! Cheers, -DeWitt
Re: mod_perl 1.99 and Apache::compat
On Sun, 7 Apr 2002, Dave Rolsky wrote: On Sun, 7 Apr 2002, Dave Rolsky wrote: I also found a few tiny bugs in Apache::compat. - The read() call in send_fd_length needs to be CORE::read. - In the last elsif in size_string, the size variable is missing its dollar sign ($). Here's a patch: thanks, applied. figures the 1 file we didn't have 'use strict' in. that's in there now too, which caught another bug in send_fd_length.
mod_perl-2 Win32 ppm package
I placed a Win32 ppm package of mod_perl-2, compiled against httpd-2.0.35 with ActivePerl 631, in our ppm repository. Installing it as ppm install \ http://theoryx5.uwinnipeg.ca/ppmpackages/mod_perl-2.ppd should also run a post-install script to install mod_perl.so in your Apache2 modules/ directory. If this doesn't work, you can download mod_perl-2.tar.gz from http://theoryx5.uwinnipeg.ca/ppmpackages/x86/ and extract mod_perl.so from there. This package was built so that the Apache Perl modules will be installed under an Apache2/ subdirectory; to use, you should place a 'PerlModule Apache2' in httpd.conf, or else 'use Apache2 ()' in a startup script. Some html docs on mod_perl-2 are included in the package which should be placed in your Perl html tree. best regards, randy kobes
Re: Leak error
Hi Nicolai, I had installed mod_perl w/ apache earlier. Problems arose whe I then tried to add php and/or ssl. At this point I am not sure what DSO is. I do know that when I compile Apache, the 1st thing it says is that DSO is installed. But then I don't know how to specifically install any of the modules as DSO. Any advice? Thanks. --- Nicolai Schlenzig [EMAIL PROTECTED] wrote: Maybe - but not likely... If you think it's mod_perl causing problems - why don't you drop ssl and php for now (as suggested earlier)? Well - maybe even a just basic Apache to start with. If that works - move on and get mod_perl installed. When you are satisfied with that you can start looking into ssl and php. My current install is with mod_perl, mod_php, and mod_ssl, it all as DSO - and I am very unhappy with mod_perl being a DSO. I had many problems installing ssl together with mod_perl, so for the being I choose to make it DSO just to have something running. When I get some time again I will built in mod_perl in my httpd and maybe even ssl. PHP will stay as DSO I think... maybe I will try compile it into my httpd as well. The bottom line is: don't take your mouth ful... Start with basics... then slowly move on... you have to crawl before you walk - and so on ;) Best of luck again // Nicolai - Original Message - From: John Kolvereid [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, April 06, 2002 7:08 PM Subject: Leak error Hello again, I have noticed that when I try to build mod_perl I get a bunch of parse errors when the 'make' is in the /Leak directory. Could this be the reason that I am unable to build mod_perl and ssl and php simultaneously. Please advise. Thanks. John Kolvereid __ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ __ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/
Disabling Perl*Handlers in .htaccess?
Hello!
How to enable only PerlSetVar/PerlAddVar directives in .htaccess files?
More specific:
We are building an multiuser environment with mod_perl to our
campus. Mod_perl handlers contain especially PerlHandlers configured in
httpd.conf. The .htaccess files are used for authorization (require
user/group) and some tailoring (PerlSetVar/PerlAddVar) allowed for all
users at their home directories.
However, the security risks are quite obvious when .htaccess contains
directives like PerlHandler:
PerlHandler sub {`touch /tmp/xxx`}
How to enable only PerlSetVar/PerlAddVar directives in .htaccess files?
--
Kari Nurmela,
[EMAIL PROTECTED], (02) 333 8847 / (0400) 786 547
