ANNOUNCE: Apache::OpenIndex 1.03
OpenIndex provides a file manager for an Apache modperl web site from a web browser. OpenIndex also provides the same functionality as autoindex, therefore it can be used to both manage and navigate a web site. An Apache::OpenIndex (OpenIndex-1.03.tar.gz) update was uploaded to CPAN on 25 Oct 2001. The module can also be downloaded at: http://www.xorgate.com/Apache/OpenIndex/ OpenIndex now supports Cascading Style Sheets and individual HTML tab configurable attributes. For example, you can now add TAG attributes like: or add TAG text, like: text Two new directives were added to support this feature: IndexHtmlTagtagattributes IndexHtmlText tagtext The following tags have attribute support:
Re: Excellent article on Apache/mod_perl at eToys
I suppose I should point out that perl.com is always interested in mod_perl articles. If you've learned lessons that others could benefit from, contact the perl.com editor, Simon Cozens <[EMAIL PROTECTED]>. Nat
Sanity check: statically linking binary extensions like GD in to httpd
I'm seeking a sanity check on statically linked binary extensions in with httpd. I've built what I want, but the build is not easily automatable, and I'm hoping I missed an easy alternative somewhere. Background: we have a .png that we want to generate on the fly with up to several thousand filled circles, dots, lines etc., using GD.pm, so I've shoe horned it and libpng into the httpd to get a minor performance improvement (we want to put this image on almost every page, and caching can help, but we need to be able to draw it *fast*, and all those calls in to a dynamically linked library cause noticable overhead[1].) I'd also like to write this up. First, I tried to build GD as a static extension: perl Makefile.PL LINKTYPE=static make make test ...snip... cat /usr/local/lib/perl5/5.6.1/i686-linux/auto/DynaLoader/extralibs.ld >> blib/arch/auto/GD/extralibs.all cat /usr/local/lib/perl5/site_perl/5.6.1/i686-linux/auto/libapreq/extralibs.ld >> blib/arch/auto/GD/extralibs.all cat blib/arch/auto/GD/extralibs.ld >> blib/arch/auto/GD/extralibs.all cc -L/usr/local/lib -rdynamic -o perl -O2 ./perlmain.o GD.o blib/arch/auto/GD/GD.a /usr/local/lib/perl5/site_perl/5.6.1/i686-linux/auto/libapreq/libapreq.a /usr/local/lib/perl5/5.6.1/i686-linux/auto/DynaLoader/DynaLoader.a /usr/local/lib/perl5/5.6.1/i686-linux/CORE/libperl.a `cat blib/arch/auto/GD/extralibs.all` -lnsl -ldl -lm -lc -lposix -lcrypt -lutil ./perlmain.o: In function `xs_init': ./perlmain.o(.text+0x9f): undefined reference to `boot_libapreq' collect2: ld returned 1 exit status ...snip... Doing this attempts to build a static perl, which fails with the below error message. It seems that the LINKTYPE=static is forcing ExtUtils to think that *all* static-looking extensions in site_perl/ should be static, not just those mentioned in $Config{static_exts} (which is ' ' here). I'm assuming that libapreq isn't primed to be a static extension because I'm running a dynamic perl, but this may be a bug. Whether or not it's a bug, it seems like it's awkward. So I mved site_perl off to the side for a moment and it builds and installs fine. libapreq is not statically linked in to my perl binary because it's only needed for mod_perl use, and mod_perl links it (statically) in to the httpd. QUESTION 1: how can I build a static extension for use with mod_perl that you *don't* want in your normal perl, and how do I get it to ignore dynamic extension dependancies like the libapreq one? Building a perl by another name, like gdperl, works (after the mv site_perl), but doesn't build an equivalent libgdperl.a (see question 2, below). "gdperl" is a nice abbreviation though ;). Anyway, after getting GD.a installed in to site_perl (and giving up on gdperl, since no libgdperl.a was built) I configure mod_perl like so: perl Makefile.PL \ APACHE_SRC=../apache-1.3.22/src \ DO_HTTPD=1 \ USE_APACI=1 \ EVERYTHING=1 \ PERL_STATIC_EXTS="GD" \ APACHE_PREFIX=$HOME/gdwww \ PREFIX=$HOME/gdwww and the build fails because GD.a isn't being linked in, and libperl.a doesn't contain the object modules from GD.a. ** QUESTION 2: how to get libperl.a to contain the guts of GD? Or, alternatively, how do I tell mod_perl that I want GD.a linked in (without hacking apaci/perl.module)? Even when I do a make -f Makefile.aperl inst_perl, no new libperl.a is installed. I could do the old trick of cpio-ing GD in to the perl distro, but there must be a better way I'm not seeing. PERL So, I tweaked mod_perl's apaci/perl.module to have the line: LIBS="$LIBS /usr/local/lib/perl5/site_perl/5.6.1/i686-linux/auto/GD/GD.a -lgd -ljpeg -lpng" near the end and I get a nice, shiny statically linked httpd with all of the require libs. YAY! ** QUESTION 3: What is the recommended way to link in external .a and .o modules like libpng.a? Hopefully, there's a left turn in Albuquerque I should have taken that someone can point out to me... Thanks, Barrie [1] which means we may head to C for some of the core routines, but that just moves the linking issues up a level.
Re: [OT] excellent modperl/etoys article by Perrin revisited
> Perrin or others involved in the old eToys (or anyone in the new Toys) -- > does anyone know if this is the same mod_perl technology you guys wrote? I'm not involved in that anymore, so I don't have first-hand information. However, a brief look at the site makes me think they are not using any of what we wrote. The URL structures and query args (i.e. the public API of the site) are all very different. > I think it will make an interesting success story follow up if it is > successful because it would also show how easy it was for the intellectual > property written in mod_perl to be resold and reintegrated into another IT > infrastructure which would make VCs happy (ie they would think more about > being able to fund projects based on mod_perl if they know they could > always resell the IP). You have to remember that what we wrote was a specific application, not a generic store or application server. That code would only be useful if you wanted a store that did everything (data model, navigation, order processing) exactly the way we did. I very much doubt KB is that similar. Also, the documentation was great for an in-house project but not enough for a packaged commercial app. There was a basic shared knowledge assumed in most of it about the business goals and environment. Keep in mind that we wrote very little infrastructure code - no more than I would expect a J2EE project this large to write. The infrastructure came from CPAN, Apache, etc. and is known to be very portable. I suspect that KB has a team who supports their site and they chose to use the technologies they already have in place. People hate change, and looking at a foreign codebase, possibly in a language you don't know, is daunting. It would be the same thing if someone walked into an ASP shop with a bundle of WebLogic code and said "make it run, and work with our legacy systems, with these changes, by Christmas. And don't stop supporting our regular site. Oh, and we didn't hire any of the developers who wrote it or the business people who told them what to write, so you'll just have to read the source if you have questions that aren't in the documentation." Doesn't sound that appealing, does it? - Perrin
Re: [OT] excellent modperl/etoys article by Perrin revisited
At 12:26 PM 10/25/2001 +0800, Gunther Birznieks wrote: >I saw an article in today's ComputerWorld that indicates the technology et >al for eToys was bought by another toy firm (KB) and they plan to put it >up to sell toys for this holiday season again. > >http://www.computerworld.com/cwi/story/0,1199,NAV47_STO65008,00.html > >Perrin or others involved in the old eToys (or anyone in the new >eToys) -- does anyone know if this is the same mod_perl technology you >guys wrote? Well, I'm just talking off the top of my head, but my interpretation is that "the Web site relies on eToys software purchased at the bankruptcy auction and on KB Toys' existing IT infrastructure" means that it's the software Perrin et al. wrote, running on KB's hardware. I can't imagine that to mean that they rewrote the software. If so, that just validates the decisions the eToys design team made. Even more kudos Perrin! :-) Drew Taylor JA[P|m_p|SQL]H http://www.drewtaylor.com/ Just Another Perl|mod_perl|SQL Hacker mailto:[EMAIL PROTECTED] *** God bless America! *** ICQ: 135298242
Re: [OT] excellent modperl/etoys article by Perrin revisited
I was told over the weekend by one of my old eToys cow-orkers that the current incarnation of www.etoys.com isn't running our old code. Leave it to KB to buy all the code then not bother to use it. I understand that's also the reason they couldn't be bothered to migrate the old accounts over. Brian Nilsen [EMAIL PROTECTED] On Thu, 25 Oct 2001, Gunther Birznieks wrote: > I saw an article in today's ComputerWorld that indicates the technology et > al for eToys was bought by another toy firm (KB) and they plan to put it up > to sell toys for this holiday season again. > > http://www.computerworld.com/cwi/story/0,1199,NAV47_STO65008,00.html > > Perrin or others involved in the old eToys (or anyone in the new eToys) -- > does anyone know if this is the same mod_perl technology you guys wrote? > > I think it will make an interesting success story follow up if it is > successful because it would also show how easy it was for the intellectual > property written in mod_perl to be resold and reintegrated into another IT > infrastructure which would make VCs happy (ie they would think more about > being able to fund projects based on mod_perl if they know they could > always resell the IP). > > Thanks, > Gunther > > __ > Gunther Birznieks ([EMAIL PROTECTED]) > eXtropia - The Open Web Technology Company > http://www.eXtropia.com/ > >
Re: Excellent article on Apache/mod_perl at eToys
On Tue, 2001-10-23 at 12:31, Dave Hodgkinson wrote: > Nathan Torkington <[EMAIL PROTECTED]> writes: > Is there a nice graphicy map of what actually constitutes J2EE onto > which we can overlay the relevant perl bitz? Something like this: http://www.onjava.com/pub/a/onjava/api_map/ http://java.sun.com/j2ee/ I wonder if such a P2EE project should build on CORBA just as J2EE does? Is interoperability with J2EE a goal? The other approach is to get the Perl language ported to the JVM. I know some work has been put into that. In this case it's important to be able to access the Java API's as easily as it is in Java. I lean toward the second approach since it would give P2EE a faster start, building on already existent frameworks. Eg. you could begin writing EJB components in perl immediately. Matt -- pgp: http://www.geocities.com/matthewbk/pubkeyw.txt PGP signature
Re: problem with Apache::SSIChain
Yeah, sorry that was a typo in the email. It is actually Apache::SSIChain in the conf file. Len - Original Message - From: "Perrin Harkins" <[EMAIL PROTECTED]> To: "LPorcano" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Thursday, October 25, 2001 9:52 AM Subject: Re: problem with Apache::SSIChain > LPorcano wrote: > > > I am trying to set up a Apache::SSIChain to process the output from a > > cgi running under Apache::Registry > > > > > > > > I am using the following line in the conf file: > > > > > > > > PerlHandler Apache::OutputChain Apache::SSI Apache::Registry > > > Shouldn't that be > > PerlHandler Apache::OutputChain Apache::SSIChain Apache::Registry > > instead? > > >
Re: problem with Apache::SSIChain
LPorcano wrote: > I am trying to set up a Apache::SSIChain to process the output from a > cgi running under Apache::Registry > > > > I am using the following line in the conf file: > > > > PerlHandler Apache::OutputChain Apache::SSI Apache::Registry Shouldn't that be PerlHandler Apache::OutputChain Apache::SSIChain Apache::Registry instead?
Re: Apache::Compress - any caveats?
Ged Haywood wrote: > Hi there, > > On Wed, 24 Oct 2001, Mark Maunder wrote: > > > I noticed that there are very few sites out there using > > Content-Encoding: gzip - in fact yahoo was the only one I could > > find. Is there a reason for this > > I think because many browsers claim to accept gzip encoding and then > fail to cope with it. The only bug I have noticed is Netscape 4.7 which does not like anything other than HTML to be compressed. So the only thing I'm compressing is text/html. I dont know of any browsers that wont accept compressed html (so far).
Re: Apache::Compress - any caveats?
Hi there, On Wed, 24 Oct 2001, Mark Maunder wrote: > I noticed that there are very few sites out there using > Content-Encoding: gzip - in fact yahoo was the only one I could > find. Is there a reason for this I think because many browsers claim to accept gzip encoding and then fail to cope with it. 73, Ged.
Re: Again DSO-mod_perl and leaking on restart: FreeBSD
Hi, > It kinda feels like you didn't absorb any of the contents of my reply. > :-) ehm, ups sorry -- perhaps i misunderstand you ;) (oh yes, my english is bad :( ) > Let me try a different approach. What do you want me to do? it was mainly a message to the mod_perl mailinglist, CC to you because you maintain the ports and maybe heard about the problem. about two months ago in the list there was a discussion about building mod_perl as DSO and the result was, that on some platforms it leaks memory if build as DSO. Ciao Alvar
Re: Again DSO-mod_perl and leaking on restart: FreeBSD
Hi, > It would be interesting to hear whether you have the same results > with the stock Perl version distributed with FreeBSD (built without > PERL_THREADED defined, since that experimental stuff was removed from > FreeBSD with good reason). with perl 5.6.1 and my Perl isn't threaded :) > That's what the p5-apache port did. > I added the mod_perl port > _specifically_ to make mod_perl available to FreeBSD admins dynamically. but it's build as DSO and I guess this makes the troubles. i prefer DSO and ports too, but i guess that DSO is the problem. Also the standard perl of FreeBSD is 5.005 -- which is really leaking memory and not up to date ;=) so i want to use 5.6.1 -- on my test machine i replaced it with 5.6.1, on production server i installed a second perl because it seems that it was not the best idea to replace the standard perl version ... Ciao Alvar
Again DSO-mod_perl and leaking on restart: FreeBSD
Hi, some weeks ago here was the discussion about DSO-mod_perl and leaking; as far as I understand it the solution was, that on SOME platforms (solaris) mod_perl should be build as static. It seems that FreeBSD is such a platform ;-) I build Apache from the Ports-Collection with mod-ssl -- /usr/ports/www/apache13-modssl -- (with 1.3.20 and 1.3.22) and manually Perl 5.6.1 (NO mymalloc, no compatibility, with mymalloc also tested) and mod_perl 1.26 as DSO with APXS. My mod_perl-Application has a global and resident hash, about 18 MB, which is build in the startup-script. At normal startup, it seems that mod_perl requires TWICE the amount of this hash, and each restart (also graceful) it eats ~18 MB. 1 GB is fast full ;-) The mod_perl from Ports Collection is build also as DSO and has the same problem (with old Perl replaced by 5.6.1). Has someone mod_perl on FreeBSD WITH DSO and without leaking running? If not possible it might be good to include a warning in the Makefiles or mod_perl-Guide etc. I prefer to build Apache from the Ports collection, so at next I'll try to create a Port with static mod_perl ... Ciao Alvar PS: #perl -V Summary of my perl5 (revision 5.0 version 6 subversion 1) configuration: Platform: osname=freebsd, osvers=4.4-stable, archname=i386-freebsd uname='freebsd gnarzelwicht.delirium-arts.de 4.4-stable freebsd 4.4-stable #8: sat oct 6 13:55:41 cest 2001 [EMAIL PROTECTED]:usrobjusrsrcsysmykernel2 i386 ' config_args='' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=undef d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef Compiler: cc='cc', ccflags ='-fno-strict-aliasing -I/usr/local/include', optimize='-O3 -march=k6 -funroll-loops -fexpensive-optimizations -malign-double', cppflags='-fno-strict-aliasing -I/usr/local/include' ccversion='', gccversion='2.95.3 20010315 (release) [FreeBSD]', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, usemymalloc=n, prototype=define Linker and Libraries: ld='cc', ldflags ='-Wl,-E -L/usr/local/lib' libpth=/usr/lib /usr/local/lib libs=-lgdbm -ldb -lm -lc -lcrypt -liconv -lutil perllibs=-lm -lc -lcrypt -liconv -lutil libc=, so=so, useshrplib=false, libperl=libperl.a Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' ' cccdlflags='-DPIC -fpic', lddlflags='-shared -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: USE_LARGE_FILES Built under freebsd Compiled at Oct 23 2001 17:37:29 @INC: /usr/lib/perl5/5.6.1/i386-freebsd /usr/lib/perl5/5.6.1 /usr/lib/perl5/site_perl/5.6.1/i386-freebsd /usr/lib/perl5/site_perl/5.6.1 /usr/lib/perl5/site_perl .
Re: Odd problem with sections
On Wednesday, October 24, 2001, at 11:38 AM, Scott Lanning wrote: > On Wed, 24 Oct 2001, Tom Mornini wrote: >> 1 >> 2$ErrorLog = >> "|/home/tmornini/Source/ewingz/bin/spread_from_stdin.pl ERROR"; >> 3 >> >> 4 ErrorLog "|/home/tmornini/Source/ewingz/bin/spread_from_stdin.pl >> ERROR" > [snip] >> When I use the section (which I need to allow the path to >> spread_from_stdin.pl to be dynamic at runtime) I receive this error: >> >> [Wed Oct 24 09:52:25 2001] [error] : ErrorLog takes one argument, >> The filename of the error log > > On line 4, you passed one argument delimited by quotation marks. > On line 2, you passed two arguments: >1) |/home/tmornini/Source/ewingz/bin/spread_from_stdin.pl >2) ERROR > so it seems you need to escape the space between them somehow > (I guess by a backslash, or put single quotes around the double > quotes, but I didn't test it). Yes, you're the second person to mention it, but you said it more clearly... This will work... $ErrorLog = q["|/home/tmornini/Source/ewingz/bin/spread_from_stdin.pl ERROR"]; or qq[] if you need interpolation. (which I do) -- -- Tom Mornini -- InfoMania Printing & Prepress
Re: Excellent article on Apache/mod_perl at eToys
On Thu, 18 Oct 2001 19:11:04 -0700 (PDT) Andrew Ho <[EMAIL PROTECTED]> wrote: > 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 I've translated this article into Japanese, and you can get it on http://bulknews.net/lib/doc-ja/etoys.ja.html http://bulknews.net/lib/doc-ja/etoys.ja.pod Just wanted to let you know. Thanks for the excellent article, Perrin! -- Tatsuhiko Miyagawa <[EMAIL PROTECTED]>
Bit of an oddity configuring perl (fwd) (fwd)
Should be fairly simple: Configure a few locations w/in the section of httpd.conf. The code seems to run, exept that naming the first section "/cdr/Data" gives me the output from Cdr::Welcome, rather than the Cdr::Data module. Changing the name from "cdr/Data" to "cdr/Foo" in the config file fixes the problem; changing it to "cdr/Bar" breaks things again. Aside from server-status and server-info these are the only locations in the config file; the only dir's in the file are serverroot and htdocs -- which don't seem to cause any problem. The really annoying thing is that all I get back is a lack of error messages and the contents of the /cdr location when accessing the /cdr/Data (/cdr/Menu and /cdr work fine). Aside from gremlins or an easter egg for URI's named "Foo", anyone know of a decent reference for this? thanx, sl $Location{'/cdr/Data'} = { SetHandler => 'perl-script', SetEnvIf=> [ [ 'Cookie', 'Eastern', 'TZ=US/Eastern' ], [ 'Cookie', 'Central', 'TZ=US/Central' ], [ 'Cookie', 'Mountain', 'TZ=US/Mountain' ], [ 'Cookie', 'Pacific', 'TZ=US/Pacific' ], [ 'Referer', 'Central', 'TZ=US/Central' ], [ 'Referer', 'Eastern', 'TZ=US/Eastern' ], [ 'Referer', 'Mountain', 'TZ=US/Mountain' ], [ 'Referer', 'Pacific', 'TZ=US/Pacific' ], ], PerlHandler => 'Cdr::Data', }; # welcome screen, authentication is handled # here also via Apache::AuthNetLDAP which # is configured here. $Location{'/cdr'} = { SetHandler => 'perl-script', PerlSetEnv => "BASEURL http://$host:$Port/cdr";, PerlHandler => 'Cdr::Welcome', }; $Location{'/cdr/Top'} = { SetHandler => 'perl-script', PerlHandler => 'Cdr::Top', }; $Location{'/cdr/Menu'} = { SetHandler => 'perl-script', PerlHandler => 'Cdr::Menu', }; -- Steven Lembark 2930 W. Palmer Workhorse Computing Chicago, IL 60647 +1 800 762 1582
[OT] excellent modperl/etoys article by Perrin revisited
I saw an article in today's ComputerWorld that indicates the technology et al for eToys was bought by another toy firm (KB) and they plan to put it up to sell toys for this holiday season again. http://www.computerworld.com/cwi/story/0,1199,NAV47_STO65008,00.html Perrin or others involved in the old eToys (or anyone in the new eToys) -- does anyone know if this is the same mod_perl technology you guys wrote? I think it will make an interesting success story follow up if it is successful because it would also show how easy it was for the intellectual property written in mod_perl to be resold and reintegrated into another IT infrastructure which would make VCs happy (ie they would think more about being able to fund projects based on mod_perl if they know they could always resell the IP). Thanks, Gunther __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Open Web Technology Company http://www.eXtropia.com/
Re: namespace-troubles
Sorry if I came off sounding harsh. I spend a lot of my personal time answering newbie questions on this list, and it bothers me when people say that newbies don't get helped here. They generally get a lot of help here. If someone says "it's in the guide" and you can't find it, ask for a link to the relevant section. If you read that section and still don't get it, ask more questions. Sending people links to the proper docs in response to questions when possible is a simple matter of efficiency. - Perrin
Re: Odd problem with sections
On Wednesday, October 24, 2001, at 07:25 PM, Carolyn Hicks wrote: > On Wed, Oct 24, 2001 at 06:52:13PM -0700, Tom Mornini wrote: >> I don't believe that single quotes -vs- double quotes would make a >> difference. Both things end up a single scalar, and I seriously doubt >> that Apache can tell the difference... > > well, I meant single *and* double quotes - so the value of $Errorlog > is actually quoted itself, like it is in the non-perl-ified directive, > because it contains a space. This fixed the problem I was having with > LogFormat. But if it's working for you now, cool. Oh! I see now... :-) Thanks, that's very interesting. I completely misunderstood your first response, sorry about that! -- -- Tom Mornini -- InfoMania Printing & Prepress
Re: namespace-troubles
Not to beat a dead horse, because this subject is well over. Sorry, if I offended anyone. Anyway, I always get and often see others get: "You obviously have not read the documentation answer." And wanted to put in my perspective being new to this list and trying to learn mod_perl. I love perl and have more than 15 books on the subject. Here is my list. Programming Perl Programming the Perl DBI Writing Apache Modules Object Oriented Perl => Damian Conway Advanced Perl Programming Perl Cookbook Perl for System Administration Regular Expressions Network Programming with Perl =>Lincoln Stein's new book Perl in a Nutshell Web Client Programming Effective Perl Programming Mastering Aogorithms with Perl CGI Programming MySQL & mSWL Official Guide to Programming with CGI.pm Learning Perl Programming Web Graphics Perl Core Language Plus the APache Book and some books that cover Perl and PHP on MySql I think your name, Parrin is on or around those books somewhere. I have seen it before. I know I have seen Randalls several times. He is famous for the answer: "Stop limiting the limits." whenever you ask a question about limits on Apache. The answer doesn't tell you the answer to your problem. I know now not to use it though. I also have several links to perl sources and yes, the guide. I have read most of these and or something out of them and some of them more than once. I have also read the parts of the guide more than once. I have been doing this for around 3 or 4 years I guess. I tried to tackle mod_perl about a year ago, but with no success and am doing it again with moderate success. I think it is easy when you know something to write out an answer that you think everyone else will know. For instance, Once I had a file locking problem and some one said: Use a semephore file. A day later, I finally found out what a semephore file was. Often when I get an answer, I usually have to go back to the books to find out what it means or how to use it. The turnaround on problems can be days, trying every combination under the sun to see if it works. When I got the previous answer that said: Don't use -w and to use PerlWarn On, it took me about 30 minutes to figure out where to put it. I put it in the startup.pl file. Still hoping that was the right place. Still, when you run into problems with Mod_perl, there are really only a couple of places to look. And just because you have read something, doesn't mean that when a problem arises, the answer will hit you. I often find myself reading old material with more knowledge than when i previously read it and now understand things I didn't have a clue about before. Even though I have read and used a lot of this information, I can tell by the answers and talks you have on the list, that I am still pretty much an amateur. I think when people ask questions, they have not always just opened up an email and sent it out without thought. There is a great fear in that. You don't know what kind of answer you will get, whether you will understand it and have to ask another seemingly stupid question, or get flammed for doing so and never be able to ask a question again. I usually think about it for a couple of hours, try every combination I can think of, and look in every book I think will have something to do with it before tucking my tale and asking a list. Yes, sometimes I will ask before spending the time if I feel I don't have the time to try and find it myself, or have just spent 3 hours trying to solve another problem. Obviously, there are either too many sources or not enough. :) I can't tell. Too many places to look sometimes and not enough others. Sometimes it would be nice to be able to ask stupid questions and get answers instead of clever indirect put downs. Maybe, I just read too much into the emails because of my own insecurities with the language. IT is hard to get a feel for text based conversation. Anyway, I just wanted to put in my two cents and am thinking I might just get flammed for this as well. Should I send it? Sometimes I get this far on emails and just delete them. Cya and thanks John Michael > John Michael wrote: > > > I don't know if this will help. I know very litlle about mod perl, but most > > of the people on this list don't seem to answer questions from beginners. > > > Hmmm. You asked some questions that made it sound like you hadn't read > the documentation, and you stil got 3 answers in 24 hours. One thing > you should consider is that not everyone here is in the same time zone. > > > > I think you might try adding: > > use subs qw(main); > > in the top of your script. > > or instead of > > main() use &main() > > > That's probably not it. The difference between mail() and &main() is > that &main() circumvents prototypes, as documented in the perlsub man page. > > > > If that doesn't work, you will probably need to make the lib a package and > > import it into your fetch.pl program. > > > That probably *is* the answer,
Re: Odd problem with sections
On Wed, Oct 24, 2001 at 06:52:13PM -0700, Tom Mornini wrote: > I don't believe that single quotes -vs- double quotes would make a > difference. Both things end up a single scalar, and I seriously doubt > that Apache can tell the difference... well, I meant single *and* double quotes - so the value of $Errorlog is actually quoted itself, like it is in the non-perl-ified directive, because it contains a space. This fixed the problem I was having with LogFormat. But if it's working for you now, cool. -carolyn
Re: tracing memory usage for modules in mod_perl??
Andrei A. Voropaev wrote: > Hi! > > Just wanted to check if it is possible to trace memory usage of each > mod_perl modules. It's kind of does not look very realistic, but I do not know > the whole truth... Sure you can, arm yourself with B::TerseSize. Look at Apache::Status that uses it, so you can browse symbol tables and learn the size of each OP/datastructure. _ 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: Odd problem with sections
On Wednesday, October 24, 2001, at 06:38 PM, Carolyn wrote: > On Wed, Oct 24, 2001 at 03:01:25AM -0700, Tom Mornini wrote: >> in httpd.conf: >> >> 1 >> 2$ErrorLog = >> "|/home/tmornini/Source/ewingz/bin/spread_from_stdin.pl >> ERROR"; >> 3 >> >> 4 ErrorLog "|/home/tmornini/Source/ewingz/bin/spread_from_stdin.pl >> ERROR" >> >> Lines 1-3 and 4 should do the same thing. They don't. > > I was having this exact problem yesterday, with CustomLog and > LogFormat. I > think it's to do with quotes - try putting single quotes around your > $ErrorLog value, so apache will still see it as a quoted string. I too am setting CustomLog, and it takes two or three values. So I set @CustomLog and everything is fine. I set LogFormat outside the section and have no need to make it dynamic, so I can't comment here. I worked around this by removing the need for the extra argument for the program I wanted to pipe to, the 'ERROR' in the above example. I just wrapped spread_from_stdin.pl with a shell script, and everything is fine, but I really do suspect that this is a bug. I don't believe that single quotes -vs- double quotes would make a difference. Both things end up a single scalar, and I seriously doubt that Apache can tell the difference... -- -- Tom Mornini -- InfoMania Printing & Prepress
Re: Odd problem with sections
On Wed, Oct 24, 2001 at 03:01:25AM -0700, Tom Mornini wrote: > in httpd.conf: > > 1 > 2$ErrorLog = "|/home/tmornini/Source/ewingz/bin/spread_from_stdin.pl > ERROR"; > 3 > > 4 ErrorLog "|/home/tmornini/Source/ewingz/bin/spread_from_stdin.pl > ERROR" > > Lines 1-3 and 4 should do the same thing. They don't. I was having this exact problem yesterday, with CustomLog and LogFormat. I think it's to do with quotes - try putting single quotes around your $ErrorLog value, so apache will still see it as a quoted string. - carolyn
problem with Apache::SSIChain
I am trying to set up a Apache::SSIChain to process the output from a cgi running under Apache::Registry I am using the following line in the conf file: PerlHandler Apache::OutputChain Apache::SSI Apache::Registry The problem is that all of the includes are being inserted at the top of the page rather than where the include call is. So the content of the footer include ends up being inserted before the body. Has anyone seen something like this, or have an idea of what is going wrong? Thanks, Len