RE: pseudo-hashes? was: Data structure question
And indeed, they ought to die. Or be reimplemented. Or something, but quite simply, don't use them. They'll break, they won't dwim, and chances are they won't play nice with future/past versions of Perl. Forget they even exist. Details? I'm using them with no problems in 5.005_03 (the real "last stable" version) with no problems. exists doesn't do what you think, that's the list of problems. -- John Hughes [EMAIL PROTECTED], CalvaEDI SA.Tel: +33-1-4313-3131 66 rue du Moulin de la Pointe, Fax: +33-1-4313-3139 75013 PARIS.
RE: pseudo-hashes? was: Data structure question
I had already reached the same conclusion after I saw that everyone would have to remember to say "my Dog $spot;" every time or the whole thing falls apart. Falls apart? How? If you want something reasonably close, you could do what a lot of the Template Toolkit code does and use arrays with constants for key names. Here's an example: Yes but then you get neither compile time (my Dog $spot) nor run time (my $spot) error checking. How are you going to debug the times you use a constant defined for one structure to index another? Have fun. Oh, do it all through accessor functions. That'll be nice and fast won't it. -- John Hughes [EMAIL PROTECTED], CalvaEDI SA.Tel: +33-1-4313-3131 66 rue du Moulin de la Pointe, Fax: +33-1-4313-3139 75013 PARIS.
Re: RegExp Parser with mod_perl
Andres Pedrera wrote: I need to make a file based parser that rightly run with mod_perl (think it's a generic perl trouble, but I want ensure it works with mod_perl). What I really need, is a parser which get parsing rules from an external file. Parse::RecDescent maybe - it is very powerful (though slow) Additionally, it have not just to parse and inform, but replace parts of the source text with new contents (using external parsing rules, of course). Somebody knows something to do this?.
RE: pseudo-hashes? was: Data structure question
On Tue, 23 Jan 2001, John Hughes wrote:
And indeed, they ought to die. Or be reimplemented. Or something,
but quite simply, don't use them. They'll break, they won't dwim,
and chances are they won't play nice with future/past versions of
Perl. Forget they even exist.
Details?
I'm using them with no problems in 5.005_03 (the real "last stable"
version) with no problems.
exists doesn't do what you think, that's the list of problems.
Neither does delete. And overloading doesn't really work properly. And
reloading modules with phashes doesn't work right. And sub-hashes doesn't
work right ($pseudo-{Hash}{SubHash}). And so on...
All they do is hide a multitude of sins, for very little real world
gain. Try it - convert your app back to non-pseudo hashes and see what
performance you lose. I'm willing to bet its not a lot.
The only gain might be in a large DOM tree where there may be thousands of
objects. But then you're really better off using an array based class
instead (as I found out).
--
Matt/
/||** Director and CTO **
//||** AxKit.com Ltd ** ** XML Application Serving **
// ||** http://axkit.org ** ** XSLT, XPathScript, XSP **
// \\| // ** Personal Web Site: http://sergeant.org/ **
\\//
//\\
// \\
RE: pseudo-hashes? was: Data structure question
On Tue, 23 Jan 2001, John Hughes wrote:
I had already reached the same conclusion after I saw that
everyone would have to remember to say "my Dog $spot;" every time or the
whole thing falls apart.
Falls apart? How?
Because you miss one out and its a very difficult to find bug in your
application, mostly because you don't get the compile warnings if you miss
one off, but also you end up wasting time looking for why your application
really isn't any faster (the hint here is that pseudo hashes really don't
make that much speed difference to your application).
Say you miss off a type declaration, and later decide to change your hash
key. All of the declarations with types will produce compile errors, so
you can/will fix them, but the one you missed it from will lie hidden,
never producing an error even when the code is called.
If you want something reasonably close, you could do what a lot of the
Template Toolkit code does and use arrays with constants for key
names. Here's an example:
Yes but then you get neither compile time (my Dog $spot) nor run time
(my $spot) error checking.
Why not?
Witness:
% perl -Mstrict
use constant FOO = 0;
my @array;
$array[FOD] = 3;
Bareword "FOD" not allowed while "strict subs" in use at - line 3.
Seems like compile time checking to me...
How are you going to debug the times you use a constant defined for
one structure to index another?
You use packages, and data hiding.
Oh, do it all through accessor functions. That'll be nice and
fast won't it.
Maybe faster than you think. Your bottleneck is elsewhere.
If you are really going:
my Dog $spot = Dog-new("spot");
print "My Dog's name is: ", $spot-{Name}, "\n";
Then I think many people here would think that is a very bad
technique. You should *never* be able to make assumptions about the
underlying data format of an object.
--
Matt/
/||** Director and CTO **
//||** AxKit.com Ltd ** ** XML Application Serving **
// ||** http://axkit.org ** ** XSLT, XPathScript, XSP **
// \\| // ** Personal Web Site: http://sergeant.org/ **
\\//
//\\
// \\
RE: pseudo-hashes? was: Data structure question
(exists doesn't work).
Neither does delete.
Ok. But what should it do? What does it do for an array?
And overloading doesn't really work properly.
Details?
And reloading modules with phashes doesn't work right.
I steer clear of reloading, almost anything screws up.
And sub-hashes doesn't work right ($pseudo-{Hash}{SubHash}).
Details? Works for me.
And so on...
All they do is hide a multitude of sins, for very little real world
gain. Try it - convert your app back to non-pseudo hashes and see what
performance you lose. I'm willing to bet its not a lot.
Well, obviously. Hashes aren't slow. But they are *BIG*.
--
John Hughes [EMAIL PROTECTED],
CalvaEDI SA.Tel: +33-1-4313-3131
66 rue du Moulin de la Pointe, Fax: +33-1-4313-3139
75013 PARIS.
RE: pseudo-hashes? was: Data structure question
On Tue, 23 Jan 2001, John Hughes wrote:
(exists doesn't work).
Neither does delete.
Ok. But what should it do? What does it do for an array?
But we're talking about hashes! At the very least it should make it so
that exists() returns false.
And overloading doesn't really work properly.
Details?
Overloading was the wrong word, FWIW... What I meant was, it doesn't work
right if you subclass a module using @ISA = (...) rather than use base. So
everybody has to *know* the underlying implementation of your class
anyway, so that breaks the very concept of OO/Data Hiding.
And reloading modules with phashes doesn't work right.
I steer clear of reloading, almost anything screws up.
Thats an overstatement in the extreme. Reloading works fine for a great
many people, and most modules.
And sub-hashes doesn't work right ($pseudo-{Hash}{SubHash}).
Details? Works for me.
SubHash isn't compile time checked! You need to do:
my SubH $subhash = $pseudo-{Hash};
$subhash-{SubHash};
to get the compile time checking.
All they do is hide a multitude of sins, for very little real world
gain. Try it - convert your app back to non-pseudo hashes and see what
performance you lose. I'm willing to bet its not a lot.
Well, obviously. Hashes aren't slow. But they are *BIG*.
??? How many keys are in your pseudo hashes? I'm willing to bet not that
many. The difference is probably less than you think to your particular
application. That is unless its a huge set of objects (thousands).
--
Matt/
/||** Director and CTO **
//||** AxKit.com Ltd ** ** XML Application Serving **
// ||** http://axkit.org ** ** XSLT, XPathScript, XSP **
// \\| // ** Personal Web Site: http://sergeant.org/ **
\\//
//\\
// \\
RE: pseudo-hashes? was: Data structure question
At 11:36 23/01/2001 +0100, John Hughes wrote:
Neither does delete.
Ok. But what should it do? What does it do for an array?
perldoc -f delete
"In the case of an array, if the array elements happen to be at the end,
the size of the array will shrink to the highest element that tests true
for exists() (or 0 if no such element exists)."
Pretty much what one would expect.
All they do is hide a multitude of sins, for very little real world
gain. Try it - convert your app back to non-pseudo hashes and see what
performance you lose. I'm willing to bet its not a lot.
Well, obviously. Hashes aren't slow. But they are *BIG*.
That's why arrays are so cool. And there are many tricks to make them work
pretty much the way you'd expect a hash to work, with very few limitations.
I also have a mind to try and play with use overload '%{}' on an array
based object to see if interesting stuff could be done there. It'll be
slower of course, but it could perhaps beat a tied hash (ties asre awfully
slow).
-- robin b.
We are born naked, wet and hungry . Then things get worse.
Re: pseudo-hashes? was: Data structure question
On Tue, Jan 23, 2001 at 10:06:13AM +, Matt Sergeant wrote: The only gain might be in a large DOM tree where there may be thousands of objects. But then you're really better off using an array based class instead (as I found out). This is getting a bit off-topic, but I'm empirically found that the DOM is not necessarily the best object model to use in a mod_perl environment. XML::DOM in particular has such a high overhead in terms of memory (and memory leaks) and performance, that it is sometimes inappropriate for a context that requires a small footprint, and generally fast throughput (like mod_perl). For example, in version 1 of the Avacet perl libraries, we were using XML::DOM for both our XML-RPC mechanism and as the underlying data structure for object manipulation. In version 2, however, we created an architecture that automatically converts between the language agnostic XML and native blessed objects using a custom engine built on the PerlSAX parser. This reduced our memory footprint dramatically, stopped up the memory leaks, and increased performance significantly. Moreover, the object model now exposed is based on native perl objects with an API geared toward property manipulation (i.e., get_foo, set_foo) which is easier to program directly to than the DOM. You can see this in action with the modules available in the Avacet::Core::Rpc::Xml namespace at www.avacet.com. Best regards, -DeWitt
RE: pseudo-hashes? was: Data structure question
On Tue, 23 Jan 2001, Robin Berjon wrote: At 11:36 23/01/2001 +0100, John Hughes wrote: Neither does delete. Ok. But what should it do? What does it do for an array? perldoc -f delete "In the case of an array, if the array elements happen to be at the end, the size of the array will shrink to the highest element that tests true for exists() (or 0 if no such element exists)." Pretty much what one would expect. Thats only 5.6+ though. So its only useful for internal applications (if at all). -- Matt/ /||** Director and CTO ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** Personal Web Site: http://sergeant.org/ ** \\// //\\ // \\
[OT] XML::DOM
On Tue, 23 Jan 2001, DeWitt Clinton wrote: On Tue, Jan 23, 2001 at 10:06:13AM +, Matt Sergeant wrote: The only gain might be in a large DOM tree where there may be thousands of objects. But then you're really better off using an array based class instead (as I found out). This is getting a bit off-topic, but I'm empirically found that the DOM is not necessarily the best object model to use in a mod_perl environment. XML::DOM in particular has such a high overhead in terms of memory (and memory leaks) and performance, that it is sometimes inappropriate for a context that requires a small footprint, and generally fast throughput (like mod_perl). I could have told you that for free :-) However its not all doom and gloom - XML::XPath implements the DOM API, and doesn't leak memory, and might be faster, and is certainly under more active development... But if performance is absolutely key in XML parsing/processing, then you really need to be looking towards Orchard, which we're co-developing with Ken MacLeod (author of the PerlSAX bindings and XML::Grove). Current tests reveal that its about 10 times faster at parsing than any Perl tree based parser and XPath resolution is about 6 times faster than current XML::XPath and XML::XQL. Plus it garbage collects automatically (and unlike Perl, really, truly, actually frees up its memory). -- Matt/ /||** Director and CTO ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** Personal Web Site: http://sergeant.org/ ** \\// //\\ // \\
RE: pseudo-hashes? was: Data structure question
At 12:50 23/01/2001 +, Matt Sergeant wrote: Thats only 5.6+ though. So its only useful for internal applications (if at all). True, but we've been using 5.6 (built from AS source) in production for quite a while now very happily. Also, I'm seeing more and more customers having it or ready to upgrade. Doesn't make delete @array that much more useful, but there's hope. -- robin b. Designing pages in HTML is like having sex in a bathtub. If you don't know anything about sex, it won't do you any good to know a lot about bathtubs.
Apache::ASP
Hello Help, I'd like to check my website and see why my test.asp is not working or showing up on the browser. http://www.technokia.com/test.asp I have installed everything and followed the instruction at http://www.apache-asp.org/ for my location this is what i have. Location /www/technokia/asp/ SetHandler perl-script PerlHandler Apache::ASP #PerlSetVar Global /tmp /Location please help me...:-) thank you, RM __ FREE Personalized Email at Mail.com Sign up at http://www.mail.com/?sr=signup
Apache::ASP
Hello Help, I'd like to check my website and see why my test.asp is not working or showing up on the browser. http://www.technokia.com/test.asp I have installed everything and followed the instruction at http://www.apache-asp.org/ for my location this is what i have. Location /www/technokia/html/asp/ SetHandler perl-script PerlHandler Apache::ASP #PerlSetVar Global /tmp /Location please help me...:-) thank you, RM __ FREE Personalized Email at Mail.com Sign up at http://www.mail.com/?sr=signup
[DIGEST] mod_perl digest 01/14/2001
-- mod_perl digest January 14, 2001 - January 20, 2001 -- Recent happenings in the mod_perl world... Features o mod_perl status o module announcements o mailing list highlights o links mod_perl status o mod_perl - stable: 1.24_01 (released October 10, 2000) [1] - development: 1.24_02-dev [2] o Apache - stable: 1.3.14 (released October 13, 2000) [3] - development: 1.3.15-dev [4] o Perl - stable: 5.6 (released March 23, 2000) [5] - development: 5.7 [6] module announcements o Apache::ProxyRewrite 0.11 - a reverse-proxy that will rewrite URLs embedded in HTML documents [7] o Apache::DBI 0.88 - persistent database connections [no reference] o AxKit 1.2 - XML Application Server for Apache. It provides on-the-fly conversion from XML to any format, such as HTML, WAP or text using either W3C standard techniques, or flexible custom code. [8] o mod_perm is on the prowl [9] mailing list highlights o Some thoughts on upgrading an installation in production [10] o Two useful non-mod_perl based modules were announced on the list: HTTP::GHTTP 1.06 - a very lightweight C/XS based HTTP downloader [11] MysqlTool 0.80 - a web interface for managing one or more mysql server installations [12] o If you are interested in a SpeedyCGI v. mod_perl debate, this one has been going on since December [13] [14] o There may be a bug in the way mod_perl handles STDIN and STDOUT in respect to fileno(). Nobody has commented on it yet [15] o More performance related stuff - this time related to how Apache manages MaxSpareServers internally [16] links o The Apache/Perl Integration Project [17] o mod_perl documentation [18] o mod_perl modules on CPAN [19] o mod_perl homepage [20] o mod_perl news and advocacy [21] o mod_perl list archives [22] [23] happy mod_perling... --Geoff [EMAIL PROTECTED] -- [1] http://perl.apache.org/dist/ [2] http://perl.apache.org/from-cvs/modperl/ [3] http://www.apache.org/dist/ [4] http://dev.apache.org/from-cvs/apache-1.3/ [5] http://www.perl.com/pub/language/info/software.html#stable [6] http://www.perl.com/pub/language/info/software.html#devel [7] http://forum.swarthmore.edu/epigone/modperl/wholsmimcloo [8] http://forum.swarthmore.edu/epigone/modperl/zhulhehrox [9] http://marc.theaimsgroup.com/?l=apache-modperlm=97978201810370w=2 [10] http://forum.swarthmore.edu/epigone/modperl/thaphexwon [11] http://forum.swarthmore.edu/epigone/modperl/joumimpverd [12] http://forum.swarthmore.edu/epigone/modperl/heemumclend [13] http://forum.swarthmore.edu/epigone/modperl/steldflerdflen [14] http://forum.swarthmore.edu/epigone/modperl/snangthelsen [15] http://forum.swarthmore.edu/epigone/modperl/dwoxmixsnen [16] http://forum.swarthmore.edu/epigone/modperl/spartwimptun [17] http://perl.apache.org [18] http://perl.apache.org/#docs [19] http://www.cpan.org/modules/by-module/Apache/ [20] http://www.modperl.com [21] http://www.take23.org [22] http://forum.swarthmore.edu/epigone/modperl/ [23] http://marc.theaimsgroup.com/?l=apache-modperlr=1w=2
RE: header_out/AUTH_REQUIRE
In my PerlAuthenHandler I need to send back the WWW-Authenticate-line.
I use $r-headers_out("WWW-Authenticate" = 'basic realm = "MyName"').
But if i returned from the Handler with "return AUTH_REQUIRED" , Apache
doesn't send this line in the header.
This is (one of) the relevant sections in *my* AuthenHandler:
unless (length $acctid) {
# no auth information
$r-note_basic_auth_failure;
$r-log_reason("no user provided", $r-filename);
return AUTH_REQUIRED;
}
It actually has several sections like that, for different criteria. But
what is important here is the Apache method call
$r-note_basic_auth_failure(). This is the method that is responsible for
setting the right WWW-Authenticate header. If your AuthHandler is for Basic
Auth (with the prompting from the browser), then the Realm should already be
configured in the httpd.conf, e.g.
Location /stats
AuthName "Stats"
AuthType Basic
PerlAuthenHandler +Stat::Auth
/Location
Just to pick a tiny nit, the header you are providing is incorrect:
WWW-Authenticate: basic realm = "MyName" # -- yours
WWW-Authenticate: Basic realm="Stats" # -- just pulled this off of a
server
Hope this helps!
L8r,
Rob
Re: [OT] XML::DOM
On Tue, 23 Jan 2001, Matt Sergeant wrote: But if performance is absolutely key in XML parsing/processing, then you really need to be looking towards Orchard, which we're co-developing with Ken MacLeod (author of the PerlSAX bindings and XML::Grove). Current tests reveal that its about 10 times faster at parsing than any Perl tree based parser ... FYI, I recently released my of XML::Tree. My benchmark tests against XML::Parser show mine to be 12 times faster. I wrote it as sort of a challenge (internal to my company). The code is based on my similar HTML::Tree. A current caveat of mine is that it's not a compliant parser. It doesn't currently handle Unicode, CDATA sections, ELEMENT declarations, and probably some other stuff. But, if you're processing straight-forward XML files, like config files, it certainly works, and fast. http://homepage.mac.com/pauljlucas/software/xml_tree/ - Paul
RE: pseudo-hashes? was: Data structure question
On Tue, 23 Jan 2001, John Hughes wrote:
I had already reached the same conclusion after I saw that
everyone would have to remember to say "my Dog $spot;" every time or the
whole thing falls apart.
Falls apart? How?
If you forget the "Dog" part somewhere, it's slower than a normal hash.
If you want something reasonably close, you could do what a lot of the
Template Toolkit code does and use arrays with constants for key
names. Here's an example:
Yes but then you get neither compile time (my Dog $spot) nor run time
(my $spot) error checking.
As Matt pointed out, you get compile time errors if you use an undefined
constant as a key.
You can also do this sort of thing with hashes, like this:
use strict;
my $bar = 'bar'
$foo{$bar};
If you type $foo{$barf} instead, you'll get an error.
How are you going to debug the times you use a constant defined for
one structure to index another?
Different classes would be in different packages.
Oh, do it all through accessor functions. That'll be nice and
fast won't it.
Well, I thought we were talking about data structures to use for objects.
A few months back, when making design decisions for a big project, I
benchmarked pseudo-hashes on 5.00503. They weren't significantly faster
than hashes, and only 15% smaller. I figured they were only worth the
trouble if we were going to be making thousands of small objects, which is
a bad idea in the first place. So, we opted for programmer efficiency and
code readability and wrote hashes when we meant hashes. Of course, since
this stuff is OO code, we could always go back and change the internal
implementation to pseudo-hashes if it looked like it would help.
If pseudo-hashes work for you, go ahead and use them. If it ain't
broke...
- Perrin
Problem with Apache::LogFile
I am currently writing a PerlLogHandler that will (hopefully) write request info to a rolling logfile in a pipe delimeted format for hourly loading via Oracle SQL*Load into a database (I know about Apache::LogDBI, but my DBA group will not let me do this). I wish to use Apache::LogFile to utilize the Apache logging mechanisms to allow all httpd children to write to a common file w/o having to worry about flocking or other methods to allow write access by many processes. The environment is Apache 1.3.12/mod_perl 1.21. Apache::LogFile seems to compile ok, but when I try to initialize the log handle in a startup.pl script, I get this error: Can't load '/opt/merc/perl/5.005_03/lib/site_perl/5.005/i686-linux/auto/Apache/LogFile/ Config/Config.so' for module Apache::LogFile::Config: /opt/merc/perl/5.005_03/lib/site_perl/5.005/i686-Linux/auto/Apache/LogFile/C onfig/Config.so: undefined symbol: perl_cmd_perl_TAKE2 at /opt/merc/perl/5.005_03/lib/5.00503/i686-linux/DynaLoader.pm line 169. I read about the args_how directive parsing stuff, and found this symbol in mod_perl.h and a few other places but really don't know what I am doing. Can anyone point me in the right direction for getting this module properly installed? Is there a special way that I need to build Apache/mod_perl? Help. Thanks, Scott
changing query string
Hello all, I'm trying to modify the query string from the client before sending it off again. I would like to do something like so: http://www.xyz.com?one=1 and modify the uri to http://www.xyz.com?one=2 the problem is I'm not sure how to reference values in the query string. I would like to be able to say queryArgs( 'one' ) = 2; Is there something in place to do this or should I parse the query string myself? Can someone point me in the right direction? thanks Vince
Errors
Hello I am running red hat 7.0 with apache version apache_1.3.14 trying to compile mod_perl-1.24 and keep getting the following error Creating Makefile in modules/standard EXTRA_CFLAGS: -DLINUX=2 -DUSE_HSREGEX -DUSE_EXPAT -I$(SRCDIR)/lib/expat-lite -DNO_DL_NEEDED * WARNING * Apache Version 1.3.0 required, aborting... * WARNING * Does any one have any idea where to go from here please help Thank you Neil -- Neil D Powers Director of Technology Zenplex Inc. 317 Madison Ave. suite 1500 New York New York (212)499-0668 Ext. 2515 http://www.zenplex.com http://www.zenplex.org http://www.tambora.org
file does not exist for server-info
I build Apache_1.3.14 with Mod_Perl-1.24_01 The complete build looks good and I can calling up page with http://hostname But when I calling http://hostname/Server-info I get "file does not exist" in the error_log file. but if I do a httpd -l I can see mod_info is included in the compile listing. Is there anything I can check? to get further? Thanks PC
Re: [OT] XML::DOM
On Tue, 23 Jan 2001, Paul J. Lucas wrote: On Tue, 23 Jan 2001, Matt Sergeant wrote: But if performance is absolutely key in XML parsing/processing, then you really need to be looking towards Orchard, which we're co-developing with Ken MacLeod (author of the PerlSAX bindings and XML::Grove). Current tests reveal that its about 10 times faster at parsing than any Perl tree based parser ... FYI, I recently released my of XML::Tree. My benchmark tests against XML::Parser show mine to be 12 times faster. I wrote it as sort of a challenge (internal to my company). The code is based on my similar HTML::Tree. A current caveat of mine is that it's not a compliant parser. It doesn't currently handle Unicode, CDATA sections, ELEMENT declarations, and probably some other stuff. But, if you're processing straight-forward XML files, like config files, it certainly works, and fast. http://homepage.mac.com/pauljlucas/software/xml_tree/ Aside from categorically *not* being an XML parser (if it doesn't parse XML 1.0 files then its not officially an XML parser), it doesn't compile on my stock Mandrake 7.0 laptop: make[1]: Entering directory `/tmp/XML_Tree-1.0/mod/XML/Tree' g++ -c -I../../.. -Dbool=char -DHAS_BOOL -I/usr/local/include -O3 -fomit-frame-pointer -fno-exceptions -fno-rtti -pipe -s -mpentium -mcpu=pentium -march=pentium -ffast-math -fexpensive-optimizations -DVERSION=\"1.0\" -DXS_VERSION=\"1.0\" -fpic -I/usr/lib/perl5/5.00503/i386-linux/CORE -Ubool Tree.c Tree.xs: In function `void XS_XML_Node_att(CV *)': Tree.xs:196: taking dynamic typeid of object with -fno-rtti Tree.xs:196: confused by earlier errors, bailing out -- Matt/ /||** Director and CTO ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** Personal Web Site: http://sergeant.org/ ** \\// //\\ // \\
Re: [OT] XML::DOM
On Tue, 23 Jan 2001, Matt Sergeant wrote: Aside from categorically *not* being an XML parser (if it doesn't parse XML 1.0 files then its not officially an XML parser) Whatever. It's still 12 times faster at parsing files that look very much like XML in a majority of real-world cases. (There: happy?) Also, as I stated, is is just version 1.0. it doesn't compile on my stock Mandrake 7.0 laptop: make[1]: Entering directory `/tmp/XML_Tree-1.0/mod/XML/Tree' g++ -c -I../../.. -Dbool=char -DHAS_BOOL -I/usr/local/include -O3 -fomit-frame-pointer -fno-exceptions -fno-rtti -pipe -s -mpentium -mcpu=pentium -march=pentium -ffast-math -fexpensive-optimizations -DVERSION=\"1.0\" -DXS_VERSION=\"1.0\" -fpic -I/usr/lib/perl5/5.00503/i386-linux/CORE -Ubool Tree.c Tree.xs: In function `void XS_XML_Node_att(CV *)': Tree.xs:196: taking dynamic typeid of object with -fno-rtti Tree.xs:196: confused by earlier errors, bailing out Your installation is outdated or broken or both: it should not be adding -fno-rtti. It's certainly not in the distributed makefiles. It requires an ANSI C++ compiler (supporting RTTI). If it doesn't compile ANSI C++ then it's not officially an ANSI C++ compiler. - Paul
difficulties compiling 1.24_01
I'm having great difficulty getting 1.24_01 to compile... Make test reports: ...make[1]: Leaving directory `/fs1/src/apache_1.3.14/src' kill `cat t/logs/httpd.pid` cat: t/logs/httpd.pid: No such file or directory rm -f t/logs/httpd.pid rm -f t/logs/error_log ../apache_1.3.14/src/httpd -f `pwd`/t/conf/httpd.conf -X -d `pwd`/t httpd listening on port 8529 will write error_log to: t/logs/error_log letting apache warm up...\c [Tue Jan 23 13:17:17 2001] [error] Can't locate loadable object for module Apache::Constants in @INC (@INC contains: /fs1/src/mod_perl-1.24_01/blib/lib /fs1/src/mod_perl-1.24_01/blib/arch /fs1/src/mod_perl-1.24_01/t/docs /fs1/src/mod_perl-1.24_01/blib/lib /fs1/src/mod_perl-1.24_01/blib/arch blib/arch blib/lib /usr/local/lib/perl5/5.00503/i686-linux /usr/local/lib/perl5/5.00503 /usr/local/lib/perl5/site_perl/5.005/i686-linux /usr/local/lib/perl5/site_perl/5.005 /fs1/src/mod_perl-1.24_01/t/ /fs1/src/mod_perl-1.24_01/t/lib/perl) at /fs1/src/mod_perl-1.24_01/blib/lib/mod_perl.pm line 16 BEGIN failed--compilation aborted at /fs1/src/mod_perl-1.24_01/blib/lib/Apache.pm line 6. BEGIN failed--compilation aborted at /fs1/src/mod_perl-1.24_01/t//docs/startup.pl line 37. Syntax error on line 62 of /fs1/src/mod_perl-1.24_01/t/conf/httpd.conf: Can't locate loadable object for module Apache::Constants in @INC (@INC contains: /fs1/src/mod_perl-1.24_01/blib/lib /fs1/src/mod_perl-1.24_01/blib/arch /fs1/src/mod_perl-1.24_01/t/docs /fs1/src/mod_perl-1.24_01/blib/lib /fs1/src/mod_perl-1.24_01/blib/arch blib/arch blib/lib /usr/local/lib/perl5/5.00503/i686-linux /usr/local/lib/perl5/5.00503 /usr/local/lib/perl5/site_perl/5.005/i686-linux /usr/local/lib/perl5/site_perl/5.005 /fs1/src/mod_perl-1.24_01/t/ /fs1/src/mod_perl-1.24_01/t/lib/perl) at /fs1/src/mod_perl-1.24_01/blib/lib/mod_perl.pm line 16 BEGIN failed--compilation aborted at /fs1/src/mod_perl-1.24_01/blib/lib/Apache.pm line 6. BEGIN failed--compilation aborted at /fs1/src/mod_perl-1.24_01/t//docs/startup.pl line 37. ...done Obviously I'm having trouble with Apache::Constants, but I'm at a loss as to why... Any tips? --Mark Stratasource, Inc. 30 Executive Park, Suite 260 Irvine, CA 92714 Phone:(949)260-0418 x505
checking available modules in test
Hi, I just did an install of modperl 1.24_01/apache 1.3.14 and I got a few failed tests. The tests that fail are actions, cgi, and include (in fact, I had to delete the line in the test conf that contained the Action directive in order to get the tests to run). And indeed, they should fail because I compiled without those respective mods. I think those tests should be skipped if those mods are not there. It should be fairly easy to do (I'd say just a matter of looking at what's been compiled in and adding IfModule directives). I'd be happy to submit a patch if that is seen as a sensible thing to do. -- robin b. Mathematicians often resort to something called Hilbert space, which is described as being n-dimensional. Like modern sex, any number can play. -- James Blish, the Quincunx of Time
Re: Errors
At 10:51 19/01/2001 -0500, Neil Powers wrote: Apache Version 1.3.0 required, aborting... You need modperl 1.24_01 to compile against apache 1.3.14. This is becoming a faq. Shouldn't we just remove 1.24 from the dist dir ? I just mecanically did exactly the same mistake. -- robin b. Work is the curse of the drinking class.
Re: Apache::ASP
Francis Mendoza wrote: Hello Help, I'd like to check my website and see why my test.asp is not working or showing up on the browser. http://www.technokia.com/test.asp This is a VBScript page, Apache::ASP only support perl scripting with ASP. I have installed everything and followed the instruction at http://www.apache-asp.org/ for my location this is what i have. Location /www/technokia/html/asp/ SetHandler perl-script PerlHandler Apache::ASP #PerlSetVar Global /tmp /Location As long as you have restarted your apache, and your files are in /www/technokia/html/asp/, then your ASP scripts should work fine. --Josh _ Joshua Chamas Chamas Enterprises Inc. NodeWorks free web link monitoring Huntington Beach, CA USA http://www.nodeworks.com1-714-625-4051
Compiling mod_perl 1.24 with the Sun Solaris C Compiler
This is a re-posting with a bit more information: I'm having trouble getting mod_perl 1.24 to compile using the Solaris compiler. Compiler Version is: Sun WorkShop 6 2000/04/07 C 5.1) OS is: Solaris 2.7 Details: For various reasons I'm using the Apache 1.3.12 source tree, and I can compile fine using gcc, but the Solaris compiler complains: /opt/SUNWspro/WS6/bin/cc -c -I../../os/unix -I../../include -DSOLARIS2=270 -DUSE_EXPAT -I../../lib/expat-lite `/export/home/matisse/devel/apache/apache_1.3.12/src/apaci` -I/usr/local/include -I/usr/local/lib/perl5/5.00503/sun4-solaris/CORE -I. -I../.. -DUSE_PERL_SSI -DMOD_PERL -KPIC -DSHARED_MODULE mod_include.c mv mod_include.o mod_include.lo "/usr/local/lib/perl5/5.00503/sun4-solaris/CORE/iperlsys.h", line 319: formal parameter lacks name: param #1 "/usr/local/lib/perl5/5.00503/sun4-solaris/CORE/iperlsys.h", line 319: formal parameter lacks name: param #2 "/usr/local/lib/perl5/5.00503/sun4-solaris/CORE/iperlsys.h", line 319: formal parameter lacks name: param #3 "/usr/local/lib/perl5/5.00503/sun4-solaris/CORE/iperlsys.h", line 319: syntax error before or at: __attribute__ "/usr/local/lib/perl5/5.00503/sun4-solaris/CORE/iperlsys.h", line 319: warning: syntax error: empty declaration "/usr/include/ctype.h", line 48: cannot recover from previous errors cc: acomp failed for mod_include.c Line 319 of /usr/local/lib/perl5/5.00503/sun4-solaris/CORE/iperlsys.h is: __attribute__((format (printf, 3, 4))); which is part of: #ifndef PerlIO_sprintf extern int PerlIO_sprintf _((char *, int, const char *,...)) __attribute__((format (printf, 3, 4))); #endif Steven Lembark [EMAIL PROTECTED] suggested: yup, a macro expansion. thou art getting bit by the way in which the compiler on Solaris is hacking up the token replacement in this C macro. Any ideas on how I can get this to compile with the Solaris compiler?? PS: I need to use this compiler because i want to compile in another module, mod_curl.c (StoryServer) which requires the Solaris compiler. -- --- Matisse Enzer TechTv Web Engineering [EMAIL PROTECTED] 415-355-4364 (desk) 415-225-6703 (cellphone)
Re: [OT] XML::DOM
On Tue, 23 Jan 2001, Paul J. Lucas wrote: On Tue, 23 Jan 2001, Matt Sergeant wrote: it doesn't compile on my stock Mandrake 7.0 laptop: make[1]: Entering directory `/tmp/XML_Tree-1.0/mod/XML/Tree' g++ -c -I../../.. -Dbool=char -DHAS_BOOL -I/usr/local/include -O3 -fomit-frame-pointer -fno-exceptions -fno-rtti -pipe -s -mpentium -mcpu=pentium -march=pentium -ffast-math -fexpensive-optimizations -DVERSION=\"1.0\" -DXS_VERSION=\"1.0\" -fpic -I/usr/lib/perl5/5.00503/i386-linux/CORE -Ubool Tree.c Tree.xs: In function `void XS_XML_Node_att(CV *)': Tree.xs:196: taking dynamic typeid of object with -fno-rtti Tree.xs:196: confused by earlier errors, bailing out Your installation is outdated or broken or both: it should not be adding -fno-rtti. It's certainly not in the distributed makefiles. It requires an ANSI C++ compiler (supporting RTTI). If it doesn't compile ANSI C++ then it's not officially an ANSI C++ compiler. From your INSTALL file: XML Tree has the following software as prerequisites: 1. A C++ compiler. XML Tree has been built using g++ 2.95 (earlier versions are untested). 2. A version of STL, the ANSI/ISO C++ Standard Template Library. If you are using g++ or egcs, then you also need (the matching version of) libstd++. $ gcc -v Reading specs from /usr/lib/gcc-lib/i586-mandrake-linux/2.95.2/specs gcc version 2.95.2 19991024 (release) $ rpm -q libstdc++ libstdc++-2.95.2-3mdk $ rpm -q libstdc++-devel libstdc++-devel-2.95.2-3mdk Its perl adding the -fno-rtti, FWIW, not your Makefiles. -- Matt/ /||** Director and CTO ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** Personal Web Site: http://sergeant.org/ ** \\// //\\ // \\
Re: Errors
Neil Powers wrote: Hello I am running red hat 7.0 with apache version apache_1.3.14 trying to compile mod_perl-1.24 and keep getting the following error Are you using the gcc "2.96" that shipped with RedHat 7? If so try using gcc 2.95.
Re: Errors
On Fri, 19 Jan 2001, Neil Powers wrote: I am running red hat 7.0 with apache version apache_1.3.14 trying to compile mod_perl-1.24 and keep getting the following error Creating Makefile in modules/standard EXTRA_CFLAGS: -DLINUX=2 -DUSE_HSREGEX -DUSE_EXPAT -I$(SRCDIR)/lib/expat-lite -DNO_DL_NEEDED * WARNING * Apache Version 1.3.0 required, aborting... * WARNING * Does any one have any idea where to go from here please help You need mod_perl-1.24_01. --Mark
Re: file does not exist for server-info
Try all lower case: http://hostname/server-info
(You had a capital S)
And make sure you have something like this in httpd.conf:
Location /server-status
SetHandler server-status
Order deny,allow
Deny from all
Allow from foo.org
/Location
or you could modify the above to add 'Server-status', 8^)
"Wang, Pin-Chieh" wrote:
I build Apache_1.3.14 with Mod_Perl-1.24_01
The complete build looks good and I can calling up page with http://hostname
But when I calling http://hostname/Server-info I get "file does not exist"
in the error_log file.
but if I do a httpd -l I can see mod_info is included in the compile
listing.
Is there anything I can check? to get further?
Thanks
PC
--
struct Programmer/Analyst 'Danny Rathjens' {this.place = "MyCity.com";}
I know you believe you understood what you think I said, but I
am not sure you realize that what you heard is not what I meant.
Re: [OT] XML::DOM
On Tue, 23 Jan 2001, Matt Sergeant wrote: Its perl adding the -fno-rtti, FWIW, not your Makefiles. Then there's something odd about your Perl installation. Perl shouldn't be giving the option. How does Perl "know" whether RTTI is needed or not? - Paul
File handles in mod_perl
Hi Folks,
I received some tips from an admin on a server where I am attempting
to get a program running under mod_perl using Apache::Registry
All was well for a few weeks, and then data files began to be corrupted
again... One of the items that was passed on to me was ( as below) regarding
global variables. I am confident that there are no evil globals left, but I don't
understand ( or don't want to believe ) what he told me about file handles.
#1. GLOBAL VARIABLES. Most perl programmers neglect to use my for
every variable type. And even if they can be broken of this bad habit they
continue to use global globs (as used with the open(FI, "blah"); function)
Solution? use the FileHandle module;
use FileHandle;
then convert code that looks like this:
open(FI, "/path/to/hitsfile");
my $line=FI;
close(FI);
to this:
my $fi = new FileHandle "/path/to/hitsfile";
$fi-getline(); # or $fi
$fi-close(); # or ignore it; PERL has garbage collection...
you SHOULD also be able to simply use:
my *FI;
but... that looks really silly...
I have read the following in the guide:
::Output of system, exec and open PIPE, "|program" calls will not be sent
::to the browser unless you Perl was configured with sfio.
I am not sending the output to the browser, but opening sendmail like so
open (MAIL, "|$mail_program") || die "Could Not Open Mail Program: $!"; is
not working. That I can work out. However, is this true about regular opens
on files?
I use a lot of basic file opens like so:
open(CUSTOMERS,"$c{globals}{root_dir}/admin/customers.txt") or die "Can't open the
customers list: $!";
Besides die being a bad thing, is this gentleman right to tell me
I have to loose my file opens and go with FileHandle ??
Any help would be Greatly appreciated.
Frustration is running high on this one.
Thanks,
Barry
New to mod perl help
After my earlier attempts to use mod perl I had little success, so I have alittle more time, so I thought I would try it again. I have a couple ofquestions. I have read through the documentation and some of it is unclearsometimes until you really know what you are doing.I understand about using strict and vars.I know that the modperl script has to go in the httpd/perl folder so thatapache will recognize it.I also have modperl installed and setup correctly. The test script runs fine. However, I have about 20 virtual host that each all have their own cgi-bins. If I move the scripts into the httpd/perl folder, if I just require themfrom the virtual cgi-bins, will they work and how do I pass variables tothese scripts. These are just regular cgi scripts. I just wanted to gain the effects of the embedded interpreter and start experimenting with the script. Ido have some scripts that would probably benefit from them anyway. I'm just trying to figure out howit all ties together. As an example, I have a script that runs via server side include. When ever someone hits the web page with this include, the script runs, it keeps the referer, and also routes the user based on this referer. I use the same script on about 40 sites and the imformation the script keeps is kept in a seperate folder for each relative to where the script iwas called from. I call the script with a require statement and would like to try and get this thing working with modperl to reduce server load.thanks in advance--John Michael
Re: New to mod perl help
On Tue, 23 Jan 2001, John Michael wrote: I know that the modperl script has to go in the httpd/perl folder so that apache will recognize it. You can put the script anywhere you please. You only have to make sure the directory is "use lib"'d. If I move the scripts into the httpd/perl folder, if I just require them from the virtual cgi-bins, will they work and how do I pass variables to these scripts. These are just regular cgi scripts. You pass them the same way you always have. I just wanted to gain the effects of the embedded interpreter and start experimenting with the script. You actually have to configure Apache::Registry to handle the scripts in said directories, of course. - Paul
Using KeepAlive with ProxyPass
Hi, This is probably more of an Apache question but here goes. I have 2 servers. One running a non-mod_perl apache and one running mod_perl. The non-mod_perl server handles static content and ProxyPasses any dynamic content to the mod_perl server. Now the question. Is there a way (KeepAlive?) to keep the connection between the two servers open, so that I eliminate the overhead of opening and closing a connection for each request? Has anyone done this and how? Thanks, Ben
