Re: perl xml api's
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Saturday 22 June 2002 12:57 am, [EMAIL PROTECTED] wrote: Hi, My Mission(must accept it) is to retrieve xml-formatted mail, parse thru char-sets in msg-body, if chars out of ascii range: generate err msg. While I wade thru the apis could any one suggest which modules would fit this task? Will XML::Parser retrieve a doc from a url or must the doc be retrived and handed to it? tips appreciated. md An XML parser will croak anyway if the chars are out of range. XML::LibXML has a built in ftp and http client for retrieving external URLs. Just pass a URI to the parse_file() method. - -- :-get a SMart net/:- -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9FCB2VBc71ct6OywRAl7mAKDPXzPGGOlCmIkTSYKArMfYuDnVaQCglGkM 5QlI1xWhyUJUl+BGW3ZYa90= =QNP1 -END PGP SIGNATURE-
perl xml api's
thanks matt, i'll get it(XML::LibXML) andgiveit a go. __ Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/ Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/
Re: perl xml api's
Hi guys, On Sat, 22 Jun 2002 [EMAIL PROTECTED] wrote: thanks matt, i'll get it(XML::LibXML) andgiveit a go. The subject line for this message was missing the RE: tag. Just a reminder to anyone new to the List that there are packages (and people:) which (who) might be confused by this... 73, Ged.
Re: [JOB] Crack OOP Perl whitebox tester wanted
Hi all, On Fri, 21 Jun 2002, Zac Morris wrote: Old fashioned is right, Can we decide whether this kind of post is or is not welcome on the List? My 0.02 is that if someone has decided on the terms of reference for an offer of employment which he is making then if it's legal, that's the way it has to be and we don't need to discuss it here - especially not at such length. 73, Ged.
Re: apache 1.3.24 mod_perl 1.27 perl 5.6.1 segv
Hi there, On Fri, 21 Jun 2002, John Saylor wrote: Try as I might, I cannot get apache to run. It just keeps segv-ing. Did you compile everything yourself? Did you see the document in mod_perl-1.27/SUPPORT ? 73, Ged.
Re: [JOB] Crack OOP Perl whitebox tester wanted
At 11:46 22.06.2002, Ged Haywood wrote: Hi all, On Fri, 21 Jun 2002, Zac Morris wrote: Old fashioned is right, Can we decide whether this kind of post is or is not welcome on the List? My 0.02 is that if someone has decided on the terms of reference for an offer of employment which he is making then if it's legal, that's the way it has to be and we don't need to discuss it here - especially not at such length. I agree with you Ged; Job announcements are ok, any discussion is way OT. -- Per Einar Ellefsen [EMAIL PROTECTED]
RE: [JOB] Crack OOP Perl whitebox tester wanted
Old fashioned is right, Can we decide whether this kind of post is or is not welcome on the List? Hang on Ged, I'm thinking that there might be a community opportunity to develop a library of tools that will solve the obvious problem here. Would it be possible to provide a solution for visionless, stuck in the 80's management practices with mod_perl? If the answer to this question is yes then we can view this thread as a requirements doc. S
Re: Fascinating segfault at Apache startup
Come to think of it, this is exactly what I did on my RedHat 7.2 system -- grabbed a Perl 5.6.1 RPM without noticing that it was for RedHat 7.3. It installed fine, and Perl worked okay, so why not? Thanks for straightening this up, Eric -- as Chip said, everything should have worked fine with the Perl RPM if I had done it correctly. Thanks. :) Jeremy Weatherford [EMAIL PROTECTED] http://xidus.net On Fri, 21 Jun 2002, E Kolve wrote: I got this error and spent a bit of time trying to figure it out. The reason I was getting it was that I had started with a RedHat 7.2 system which comes with Perl 5.6.0 and upgraded to 5.6.1 using RH 7.3 RPMS. I then compiled mod_perl against 5.6.1. Each time I started up I got the absurdfork error. I found 5.6.1 RPMS for RH 7.2 and everything worked fine. --eric
OT Job discussion, was Re: [JOB] Crack OOP Perl whitebox tester wanted
On Saturday, June 22, 2002, at 02:46 AM, Ged Haywood wrote: On Fri, 21 Jun 2002, Zac Morris wrote: Old fashioned is right, Can we decide whether this kind of post is or is not welcome on the List? For what it's worth, my inclusion of the list address on my reply was entirely accidental. When I saw my reply come back on the list, I was very surprised. I apologize for making such a silly mistake. I agree that posting my response to the list was severely off topic and completely inappropriate. -- -- Tom Mornini -- InfoMania Printing and Prepress -- -- ICQ: 113526784, AOL, Yahoo, MSN and Jabber: tmornini
Re: Apache::DBI with mod_perl 2.0 (was Re: [ANNOUNCE] Apache::DBI 0.89)
At 06:41 PM 6/21/02 +0200, Per Einar Ellefsen ([EMAIL PROTECTED]) wrote: As Apache::DBI hasn't been tested with mod_perl 2.0 yet, you will need to: 1) make sure you are using the prefork MPM for Apache (as Stas said, Apache::DBI can only work with that one) 2) You will probably need to run mod_perl 2.0 in compat mode: put PerlModule Apache::compat in your httpd.conf, before loading other modules (like Apache::DBI). I didn't expect Apache::DBI to work under mod_perl 2.0, at least not well, but was quite surprised. Today, I got it to work with this server: Server Version: Apache/2.0.36 (Unix) mod_perl/1.99_03-dev Perl/v5.6.1 DAV/2 Using Per Ellesfsen's suggests, and also pre-loading the following startup.pl script (for compat.pm): #!/usr/bin/perl -w use strict; use Apache2(); use Apache::compat; 1; Rudimentary benchmarks, using a MySQL server, and very simple query, shows that Apache::DBI significantly reduces user response time, and increases the throughput of the server (a very limited single P200 MX system, with only 64MB RAM running RH 7.3): Table 8.2: Benchmarking Results Using Database Connection Sharing CGImod_perl Server Hostname192.168.1.1192.168.1.1 Server Port8080 Document Path/cgi-bin/zipcodes.cgi?zip=35801/perl/zipcodes.cgi?zip=35801 Concurrency Level1010 Elapsed Time258.722seconds63.691 seconds Complete Requests200200 Failed Requests00 Total Transferred127000 bytes131843 bytes HTML Transferred89200 bytes90200 bytes Requests per Second0.773.20 Median Connection Times 12518 ms424 ms Transfer Rate0.48Kbps received2.05Kbps received --- Charles Aulds, MCSE, MCP+I Voice: (256) 931-5593 Fax: (240) 352-8290 http://hiwaay.net/~caulds
Re: Apache::DBI with mod_perl 2.0 (was Re: [ANNOUNCE] Apache::DBI 0.89)
At 06:41 PM 6/21/02 +0200, Per Einar Ellefsen ([EMAIL PROTECTED]) wrote: As Apache::DBI hasn't been tested with mod_perl 2.0 yet, you will need to: 1) make sure you are using the prefork MPM for Apache (as Stas said, Apache::DBI can only work with that one) 2) You will probably need to run mod_perl 2.0 in compat mode: put PerlModule Apache::compat in your httpd.conf, before loading other modules (like Apache::DBI). I didn't expect Apache::DBI to work under mod_perl 2.0, at least not well, but was quite surprised. Today, I got it to work with this server: Server Version: Apache/2.0.36 (Unix) mod_perl/1.99_03-dev Perl/v5.6.1 DAV/2 Using Per Ellesfsen's suggests, and also pre-loading the following startup.pl script (for compat.pm): #!/usr/bin/perl -w use strict; use Apache2(); use Apache::compat; 1; Rudimentary benchmarks, using a MySQL server, and very simple query, shows that Apache::DBI significantly reduces user response time, and increases the throughput of the server (a very limited single P200 MX system, with only 64MB RAM running RH 7.3): CGImod_perl Server Hostname192.168.1.1192.168.1.1 Server Port8080 Document Path/cgi-bin/zipcodes.cg /perl/zipcodes.cgi? zip=35801 zip=35801 Concurrency Level1010 Elapsed Time258.722seconds63.691 seconds Complete Requests200200 Failed Requests00 Total Transferred127000 bytes131843 bytes HTML Transferred89200 bytes90200 bytes Requests per Second0.773.20 Median Connection Times 12518 ms424 ms Transfer Rate0.48Kbps received2.05Kbps received --- Charles Aulds, MCSE, MCP+I Voice: (256) 931-5593 Fax: (240) 352-8290 http://hiwaay.net/~caulds
Re: Fascinating segfault at Apache startup
Zac Morris [EMAIL PROTECTED] writes:
Honestly though Chip I have to pipe up here.
I was a gung ho RedHat supporter when I first got involved in the
linux world, and I still believe with it's RPMs and GUI tools it's
still the best for both new users and corporate environments, but
man, if you wanna do something that not the EXACT OS version-RPM
based software version, (hmmm, like DEVELOPMENT) you are SERIOUSLY
screwed with RPM more times than not.
It depends. Usually it isn't RPM that is the problem, it's the
-other- software you've installed with RPM. Dependencies tend to be
an all-or-nothing affair, though, which makes the situation more
complicated.
So I have spent the last FIVE full days about 10 hours a day setting
up redhat 7.3 (sans as many of the RPMs as I could possible get away
with). Now granted perl 5.6.1 was one of the RPMs I *did* install,
as was sendmail (since Redhat has REALLY whacked that one up with
the assumed workstation mode, but I at least know how to FIX
that), but my apache, mod_perl, java, tomcat, etc I built entirely
from source utilizing my /opt/{appname} everything all together
strategy.
I now have a pretty swank lil server setup here. I just
successfully tested my perl/DBD::Pg connections and i'll confirm
jdbc to Pg tomorrow and I'll be set for some major develpment
efforts.
I'm not familiar with tomcat, so I can't really comment on it
specifically. But, before I came to Red Hat, I was a compile from
source guy, even on production servers. Lots of reasons, but one was
that I didn't know RPM. It seemed like a hassle to deal with it for
little things, etc... so I didn't.
My personal suggestion would be to try to work with the default OS
instead of against it. Sometimes this is impossible, but sometimes it
isn't so bad. For instance, instead of compiling straight from
source, you could take our RPMs, modify them (such as making apache
live in /opt), maybe throw in a more recent version, and see how it
works. Likewise, building tomcat, java, etc, as RPMs may save you
time later when you need to rebuild a box, or clone the system, or
should disaster strike. Recompiling, checking dependencies by hand,
etc, really is time consuming. But, of course, so is learning RPM :)
It definitely is a difficult road. Having travelled it myself,
though, I find it to be tremendously better than how I used to do
things. It depends on your own personal preferences, though, as well
as company policies, your peers' skillsets, etc. No one answer fits
everything, but I really do think that package management of some kind
(RPMs, debian, etc) offers many superiorities over recompiling from
source. YMMV :) There's no one single answer (too much context), but
in general, whatever OS you use, it usually is easier to work with it
and the tools it provides than against it.
When it comes to perl and mod_perl, we've been working to try to make
sure it works reliably from RPMs. RH 7.3 should work well out of the
box, as should 7.2, once all errata applied. The rest of this thread
points out a few issues, though, but I think that tends to be issues
with other perl modules that have shared library components. If you
(or anyone else!) have specific failures or test cases you've seen,
though, I'll look into it and see if it is something we can fix.
Cheers,
Chip
--
Chip Turner [EMAIL PROTECTED]
Red Hat, Inc.
Re: Problems with PerlModule
Nikolaus Rath wrote: Hallo! Is it possible that PerlModule doesn't modify %INC? With PerlModule CGI in the Apache configuration, all scripts with use CGI produce warnings like: Subroutine put redefined at /usr/lib/perl5/5.6.1/CGI.pm line 517. Subroutine print redefined at /usr/lib/perl5/5.6.1/CGI.pm line 523. Subroutine cgi_error redefined at /usr/lib/perl5/5.6.1/CGI.pm line 529. Subroutine save_request redefined at /usr/lib/perl5/5.6.1/CGI.pm line [..] in the server log. (use strict and use warnings are active). Without PerlModule, all scripts run without warnings. And even with Perl use CGI; /Perl everything works fine. The CGI module is only an example. I have similar problems with several other modules. When reporting problems you *must* provide the information about your environment and used version as explained here: http://perl.apache.org/release/docs/1.0/guide/help.html#How_to_Report_Problems I believe that this particular problem has been solved in the recent mod_perl versions. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
