My autoresponder
All who have recently posted on this list: You have been receiving my auto-responder, which I set up to make sure any of my customer's knew why they weren't getting a response. In a very hurriedly and obviously clueless manner I forgot to exclude this list, or even temporarily un-subscribe. I'm genuinely sorry for everyone receiving spam after spam from me. -- Ryan Parr (aka [EMAIL PROTECTED])
Re: Apache->server_root_relative(); not found
m31 wrote: > I think we've narrowed it down to three choices, but why would my @INC > list one thing from the terminal and another from mod_perl? Are they two > seperate @INC's? mod_perl adds a few dirs to @INC on its own, but I still cannot understand what is your problem. Let's say you want to add '/Library/www/lib' to @INC. So inside startup.pl you do: use lib qw(/Library/www/lib); and that's it! Remember that you cannot affect @INC for the whole server from your handlers/scripts, as it gets reset after each request to the value it had after startup, so you can only change it during startup. -- __ 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
Re: Apache->server_root_relative(); not found
Per Einar Ellefsen wrote:
> At 13:30 04.06.2002, m31 wrote:
>
>> Well, I printed out my @INC to screen, and now I have directories
>> that do not exist in it from putting the wrong path in the
>> server_root_relative method, can any-one tell me how to remove this
>> dir from @INC? I treid a few ways but to no sucess.
>
>
> Restart your server? "use lib" doesn't make any permanent changes to
> @INC, these only persist across the httpd mod_perl run. If you restart
> (with the correct code this time), it should be set to the correct value.
>
Per Einar,
Yes, I restarted it. I have @INC printed out to the screen in one of my
test modules, and after a restart the dir's are still there so I opened
up a terminal window and did a:
perl -le 'print join "\n", @INC'
and the dir's I would like to pop off @INC aren't listed but they are
listed in my browser from the module? I now realize that I can't change
my ServerRoot in httpd.conf because then apache won't be able to load
any of its modules at startup (in /usr/libexec/httpd).
So I have three choices
1.) Get the Apache source, compile and install where I need it. Instead
of the using one that comes with OSX.
2.) move the modules I build for mod_perl somewhere under the /usr
directory. (my doc root is /Library/www/docs Apple sets this up in two
totaly diff tree's)
3.) keep the modules where they are and just push(@INC,
'/Library/www/lib'); instead of using use lib
Apache->server_root_relative('lib/perl'); (actually returns
/usr/lib/perl in stead of what I need, /Library/www/lib/perl)
Well, I'm not sure what I'll do yet, its only a developement machine for
educational purposes thankx for the help
-Justin
Stas Beckman,
Thankx for your help also.
Stas wrote:
Please be more specific. What have you done to @INC so it includes
non-existing dirs? You must have added them. A *short * code fragment is
the best so we can reproduce the problem.
The code snippet for the startup file I used is on one of the other
emails/replies.
I think we've narrowed it down to three choices, but why would my @INC
list one thing from the terminal and another from mod_perl? Are they two
seperate @INC's?
Re: eating memory ... // RE: Porting to OS X
On Wed, 5 Jun 2002, Alvar Freude wrote: > probably it's the same as on FreeBSD: if you use a DSO mod_perl, for each > restart (apachectl graceful or apachectl restart) it eats all the memory > your mod_perl modules use. Try to build it statically; at least on FreeBSD > it helps, and OSX is FreeBSD ... :-) > > But my newest test was with Apache 1.3.23 and mod_perl 1.26; perhaps it's > fixed in 1.27?!? dso should be fine with 1.26 or 1.27, provided you are using Perl 5.6.1 or higher. 5.005_03 still has leakage.
Re: PATCH modperl_bucket.c
On Tue, 4 Jun 2002, Mladen Turk wrote: > Hi, > > Enables compilation witch current CVS. fix applied to cvs, thanks.
Re: rfc Apache::Dynagzip
Dear Valerio, Alvar, and Igor,
Thank you very much for your attention to Apache::Dynagzip.
It is on CPAN now:
The uploaded file Apache-Dynagzip-0.04.tar.gz has entered CPAN as
file: $CPAN/authors/id/S/SL/SLAVA/Apache-Dynagzip-0.04.tar.gz
size: 24939 bytes
md5: 586610ffdd35cd1ceceaba4796fd6212
I've just fixed a few typos and updated README for this version.
Now I'm back in our discussion.
I believe the questions, which we began to discuss yesterday with Valerio
privately should go public being helpful for others too. Especially, seeing
that they are similar to Alvar's interests.
I feel this discussion very important, but this time it is not about the
Dynagzip itself. Indeed, it is about the implementation of gzip compression
in most common view.
You know, there are 6 open source modules/packages for the web content
compression available in the World (in alphabetic order):
·Apache::Compress
·Apache::Dynagzip
·Apache::Gzip
·Apache::GzipChain
·mod_deflate
·mod_gzip
And (I guess) many specific commercial modules were written around. These
days even Microsoft has own gzip DLL for IIS.
You know advantages of the web content compression. It's easy to explain to
any executive how good it is for him to compress his web traffic.
On other hand, you know of-course, that the compression is used rarely in
practice to date. My own observations show that there are only few content
providers, who compress their traffic. I would mention Oracle as the leader,
which covers a significant percent of its on-line documentation with gzip
compression (looks like a static approach). On Yahoo there are few pages
gzipped only. Even the US governmental sites do not use gzip. Why?
Because it is not that simple to implement the web compression to date. The
success of the compression implementation depends on quality of client side
software. I would not consider the efforts of browser vendors sufficient
these days. We know many bugs. Others are still hidden. We can't fix them.
To adjust a web server appropriately is a common problem for any of
mentioned compression modules.
That's why I believe it is better to have one simple common rule in all
compression modules (like an Accept-Encoding header), and a flexible FixUp
handler, which should control the $r->header_in('Accept-Encoding') prior to
compression handler.
I don't know should it be a kitchen of every system administrator, or
somebody could volunteer to serve the public web site about the current
conditions of different web clients and recommended masks?.. I can't host it
on my devl4, because it is a development machine. That would be better to
find some stable place, like mod_perl, or apache project ;-).
Any suggestions?
Thanks,
Slava
eating memory ... // RE: Porting to OS X
Hi, -- Michael Robinton <[EMAIL PROTECTED]> wrote: > application, which runs on an aging 486 with 64 megs in our shop and uses > about 4 megs including mod_perl enhanced apache, took 40 megs on OSX and > was very slow. This was on a G4 with 500 megs of memory. probably it's the same as on FreeBSD: if you use a DSO mod_perl, for each restart (apachectl graceful or apachectl restart) it eats all the memory your mod_perl modules use. Try to build it statically; at least on FreeBSD it helps, and OSX is FreeBSD ... :-) But my newest test was with Apache 1.3.23 and mod_perl 1.26; perhaps it's fixed in 1.27?!? But nevertheless 4 MB is very small; my frontend Apache 1.3.23 without mod_perl takes 3 MB; my frontend Apache 2.0.36 on developing system >4 MB without mod_perl ... Ciao Alvar -- // Unterschreiben! http://www.odem.org/informationsfreiheit/ // Internet am Telefon: http://www.teletrust.info/ // Das freieste Medium? http://www.odem.org/insert_coin/ // Blaster: http://www.assoziations-blaster.de/
Re: Porting to OS X
David Wheeler wrote: >On 6/4/02 10:54 AM, "Vuillemot, Ward W" <[EMAIL PROTECTED]> >claimed: > >>I think it is relatively an easy move, IMHO. Just beaware that the Mac OS >>filesystem is NOT case-sensitive. Which can cause problems with certain >>applications. . .and we hope (Apple, you listening?) that they will fix this >>gross over-sight. >> > >I don't think that Apple is likely to change this. However, you can install >OS X on a case-sensitive partition (UFS?) if you really want to. > >Regards, > >David > Yes, Apples HFS volumes is not case sensitive and you can partition a drive for UFS, but, Apple provides a case-sensitivity module for Apache. Its called "mod_hfs_apple.so" and comes with the install, you can find it with all of Apache's other modules in /usr/libexec/httpd. Whether this is good enough for case-sensitivity or not I thought it may be of help. -Justin
PATCH modperl_bucket.c
Hi,
Enables compilation witch current CVS.
Index: modperl_bucket.c
===
RCS file:
/home/cvspublic/modperl-2.0/src/modules/perl/modperl_bucket.c,v
retrieving revision 1.7
diff -u -r1.7 modperl_bucket.c
--- modperl_bucket.c24 Sep 2001 03:32:55 - 1.7
+++ modperl_bucket.c4 Jun 2002 18:36:29 -
@@ -48,7 +48,11 @@
}
static const apr_bucket_type_t modperl_bucket_sv_type = {
+#if MODULE_MAGIC_NUMBER < 20020602
"mod_perl SV bucket", 4,
+#else
+"mod_perl SV bucket", 4, APR_BUCKET_DATA,
+#endif
modperl_bucket_sv_destroy,
modperl_bucket_sv_read,
apr_bucket_setaside_notimpl,
MT.
Re: Apache.pm failed to load!
Hi,
thanks to all for the help I found the
answer. I ran strace against httpd and found it was loading an old version
of Apache.pm from /usr/lib/perl5/site_perl/5.6.1 not sure how it got
there. Removed it and all worked.
thanks
James
- Original Message -
From:
James
Kirkland
To: [EMAIL PROTECTED]
Sent: Tuesday, June 04, 2002 11:09
Subject: Apache.pm failed to load!
Hi,
I am getting the "Apache.pm failed to load!" error. I need help to
resolve:
[root@fisher mysql]# perl -MApache -e 1
Can't load
'/usr/lib/perl5/site_perl/5.6.1/i386-linux/auto/Slash/Apache/Apache.so'
for module Slash::Apache:
/usr/lib/perl5/site_perl/5.6.1/i386-linux/auto/Slash/Apache/Apache.so:
undefined symbol: perl_cmd_perl_TAKE1 at
/usr/lib/perl5/5.6.1/i386-linux/DynaLoader.pm line 206. at -e
line 0Compilation failed in require.BEGIN failed--compilation
aborted.
the end of the strace output is:
read(5,
"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\*\0\000"..., 1024) =
1024fstat64(5, {st_mode=S_IFREG|0755, st_size=41994, ...}) =
0brk(0x87ed000)
= 0x87ed000old_mmap(NULL, 37492, PROT_READ|PROT_EXEC, MAP_PRIVATE, 5, 0) =
0x40b32000mprotect(0x40b3a000, 4724, PROT_NONE) =
0old_mmap(0x40b3a000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED, 5, 0x7000) =
0x40b3a000close(5)
= 0open("/usr/lib/mysql/i686/mmx/libmysqlclient.so.10", O_RDONLY) = -1
ENOENT (No such file or directory)stat64("/usr/lib/mysql/i686/mmx",
0xbfffef30) = -1 ENOENT (No such file or
directory)open("/usr/lib/mysql/i686/libmysqlclient.so.10", O_RDONLY) = -1
ENOENT (No such file or directory)stat64("/usr/lib/mysql/i686",
0xbfffef30) = -1 ENOENT (No such file or
directory)open("/usr/lib/mysql/mmx/libmysqlclient.so.10", O_RDONLY) = -1
ENOENT (No such file or directory)stat64("/usr/lib/mysql/mmx",
0xbfffef30) = -1 ENOENT (No such file or
directory)open("/usr/lib/mysql/libmysqlclient.so.10", O_RDONLY) =
5read(5, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\220\200"...,
1024) = 1024fstat64(5, {st_mode=S_IFREG|0755, st_size=251027, ...}) =
0old_mmap(NULL, 216960, PROT_READ|PROT_EXEC, MAP_PRIVATE, 5, 0) =
0x40b84000mprotect(0x40ba1000, 98176, PROT_NONE) =
0old_mmap(0x40ba1000, 98304, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED, 5, 0x1d000) =
0x40ba1000close(5)
=
0brk(0x87ee000)
=
0x87ee000brk(0x87ef000)
=
0x87ef000brk(0x87f)
= 0x87frt_sigprocmask(SIG_BLOCK, NULL, [RTMIN], 8) = 0write(2,
"Apache.pm failed to load!.\n", 27) = 27_exit(2)
[root@fisher mysql]# rpm -qa |grep
perlperl-SGMLSpm-1.03ii-4perl-DB_File-1.75-34.99.6groff-perl-1.17.2-12perl-libxml-enno-1.02-15perl-libwww-perl-5.63-9perl-libxml-perl-0.07-14perl-5.6.1-34.99.6perl-CPAN-1.59_54-34.99.6perl-NDBM_File-1.75-34.99.6perl-DateManip-5.40-15perl-Digest-MD5-2.16-15perl-Parse-Yapp-1.05-15perl-URI-1.17-16perl-XML-Encoding-1.01-9perl-XML-Parser-2.30-15perl-XML-Dumper-0.4-12perl-Crypt-SSLeay-0.35-15perl-Frontier-RPC-0.06-14perl-suidperl-5.6.1-34.99.6perl-TimeDate-1.10-14mod_perl-1.26-5perl-CGI-2.752-34.99.6perl-Storable-1.0.14-15perl-XML-Grove-0.46alpha-11perl-XML-Twig-2.02-9perl-Devel-Symdump-2.01-15perl-Time-HiRes-1.20-14
thanksJames
Re: Apache.pm failed to load!
Hi,
For more information I get that error when I
run:
httpd -f conf/httpd.conf
-DHAVE_PERL
thanks
James
- Original Message -
From:
James
Kirkland
To: [EMAIL PROTECTED]
Sent: Tuesday, June 04, 2002 11:09
Subject: Apache.pm failed to load!
Hi,
I am getting the "Apache.pm failed to load!" error. I need help to
resolve:
[root@fisher mysql]# perl -MApache -e 1
Can't load
'/usr/lib/perl5/site_perl/5.6.1/i386-linux/auto/Slash/Apache/Apache.so'
for module Slash::Apache:
/usr/lib/perl5/site_perl/5.6.1/i386-linux/auto/Slash/Apache/Apache.so:
undefined symbol: perl_cmd_perl_TAKE1 at
/usr/lib/perl5/5.6.1/i386-linux/DynaLoader.pm line 206. at -e
line 0Compilation failed in require.BEGIN failed--compilation
aborted.
the end of the strace output is:
read(5,
"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\*\0\000"..., 1024) =
1024fstat64(5, {st_mode=S_IFREG|0755, st_size=41994, ...}) =
0brk(0x87ed000)
= 0x87ed000old_mmap(NULL, 37492, PROT_READ|PROT_EXEC, MAP_PRIVATE, 5, 0) =
0x40b32000mprotect(0x40b3a000, 4724, PROT_NONE) =
0old_mmap(0x40b3a000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED, 5, 0x7000) =
0x40b3a000close(5)
= 0open("/usr/lib/mysql/i686/mmx/libmysqlclient.so.10", O_RDONLY) = -1
ENOENT (No such file or directory)stat64("/usr/lib/mysql/i686/mmx",
0xbfffef30) = -1 ENOENT (No such file or
directory)open("/usr/lib/mysql/i686/libmysqlclient.so.10", O_RDONLY) = -1
ENOENT (No such file or directory)stat64("/usr/lib/mysql/i686",
0xbfffef30) = -1 ENOENT (No such file or
directory)open("/usr/lib/mysql/mmx/libmysqlclient.so.10", O_RDONLY) = -1
ENOENT (No such file or directory)stat64("/usr/lib/mysql/mmx",
0xbfffef30) = -1 ENOENT (No such file or
directory)open("/usr/lib/mysql/libmysqlclient.so.10", O_RDONLY) =
5read(5, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\220\200"...,
1024) = 1024fstat64(5, {st_mode=S_IFREG|0755, st_size=251027, ...}) =
0old_mmap(NULL, 216960, PROT_READ|PROT_EXEC, MAP_PRIVATE, 5, 0) =
0x40b84000mprotect(0x40ba1000, 98176, PROT_NONE) =
0old_mmap(0x40ba1000, 98304, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED, 5, 0x1d000) =
0x40ba1000close(5)
=
0brk(0x87ee000)
=
0x87ee000brk(0x87ef000)
=
0x87ef000brk(0x87f)
= 0x87frt_sigprocmask(SIG_BLOCK, NULL, [RTMIN], 8) = 0write(2,
"Apache.pm failed to load!.\n", 27) = 27_exit(2)
[root@fisher mysql]# rpm -qa |grep
perlperl-SGMLSpm-1.03ii-4perl-DB_File-1.75-34.99.6groff-perl-1.17.2-12perl-libxml-enno-1.02-15perl-libwww-perl-5.63-9perl-libxml-perl-0.07-14perl-5.6.1-34.99.6perl-CPAN-1.59_54-34.99.6perl-NDBM_File-1.75-34.99.6perl-DateManip-5.40-15perl-Digest-MD5-2.16-15perl-Parse-Yapp-1.05-15perl-URI-1.17-16perl-XML-Encoding-1.01-9perl-XML-Parser-2.30-15perl-XML-Dumper-0.4-12perl-Crypt-SSLeay-0.35-15perl-Frontier-RPC-0.06-14perl-suidperl-5.6.1-34.99.6perl-TimeDate-1.10-14mod_perl-1.26-5perl-CGI-2.752-34.99.6perl-Storable-1.0.14-15perl-XML-Grove-0.46alpha-11perl-XML-Twig-2.02-9perl-Devel-Symdump-2.01-15perl-Time-HiRes-1.20-14
thanksJames
Re: Porting to OS X
> "David" == David Wheeler <[EMAIL PROTECTED]> writes: >> I think it is relatively an easy move, IMHO. Just beaware that the Mac OS >> filesystem is NOT case-sensitive. Which can cause problems with certain >> applications. . .and we hope (Apple, you listening?) that they will fix this >> gross over-sight. David> I don't think that Apple is likely to change this. However, you David> can install OS X on a case-sensitive partition (UFS?) if you David> really want to. My / has been UFS since day 1 of using OSX for me. I have a separate HFS+ partition for Classic Apps. The downside is that some of the files are not accessible to Classic apps, but as more and more stuff gets at least Carbonized, I'm not really that worried. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
RE: Porting to OS X
At 11:27 AM 6/4/02 -0700, Michael Robinton wrote: >I'd be very interested in how this progresses. I recently helped a >collegue to get a cgi program running under apache using standard perl on >OSX -- I found that the perl distribution that comes with OSX is the >original 5.6 rather than more up to date versions IIRC, the latest OS update upgrades perl to 5.6.1. == Drew Taylor | Freelance web development using http://www.drewtaylor.com/ | perl/mod_perl/MySQL/postgresql/DBI mailto:[EMAIL PROTECTED] | Email jobs at drewtaylor.com -- Speakeasy.net: A DSL provider with a clue. Sign up today. http://www.speakeasy.net/refer/29655 ==
RE: Porting to OS X
From: "Noam Solomon" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Subject: Porting to OS X Date sent:Tue, 4 Jun 2002 13:43:11 -0400 >[ Double-click this line for list subscription options ] > >Can anyone give me a rough idea how much time it would take to move a >server serving >mod_perl websites from UNIX to OS X? It uses Apache::Session, >DBI::Mysql, >HTML::Mason, CGI, >and Apache::OpenIndex, among others, and uses both AuthHandlers and >AuthzHandlers. > >I know it's difficult to estimate without knowing how big the websites >are, what kind of >functions they call, etc., but if you could give me an idea of what kind >of problems I can >expect to encounter and how difficult they are to work around, I can give >a quote to my >client. > >Thanks, >Noam Solomon I'd be very interested in how this progresses. I recently helped a collegue to get a cgi program running under apache using standard perl on OSX -- I found that the perl distribution that comes with OSX is the original 5.6 rather than more up to date versions AND that the application, which runs on an aging 486 with 64 megs in our shop and uses about 4 megs including mod_perl enhanced apache, took 40 megs on OSX and was very slow. This was on a G4 with 500 megs of memory. Michael
Re: Porting to OS X [OT] OS X
>> I think it is relatively an easy move, IMHO. Just beaware that the >> Mac OS filesystem is NOT case-sensitive. Which can cause problems >> with certain applications. . .and we hope (Apple, you listening?) that >> they will fix this gross over-sight. I agree it's a problem, and it's caused me some heartache, but Apple, and many of my Apple zealot friends definitely consider it a feature, not a bug. Another annoying thing that may happen while migrating directory structures is: if you have two directorie with /dir_this/dir_that/[lotsof.pl] /dir_dir/dir_this/dir_the_other/[lotsmore.pl] and you're in / cp|mv dir_this dir_dir will cp|mv dir_that to /dir_dir/dir_this/dir_that BUT dir_the_other will be gone. Another "feature" Dvaid
Re: Porting to OS X
On 6/4/02 10:54 AM, "Vuillemot, Ward W" <[EMAIL PROTECTED]> claimed: > I think it is relatively an easy move, IMHO. Just beaware that the Mac OS > filesystem is NOT case-sensitive. Which can cause problems with certain > applications. . .and we hope (Apple, you listening?) that they will fix this > gross over-sight. I don't think that Apple is likely to change this. However, you can install OS X on a case-sensitive partition (UFS?) if you really want to. Regards, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
RE: Porting to OS X
This is going OT, but the case insensitivity problem is only for the Mac filesystems. I've that all you need to do is switch the filesystem to ufs (the bsd version) and the problem is solved. Of course, if you can't switch fs types I don't know of a workaround. :-) Drew At 10:54 AM 6/4/02 -0700, Vuillemot, Ward W wrote: > >I think it is relatively an easy move, IMHO. Just beaware that the Mac OS >filesystem is NOT case-sensitive. Which can cause problems with certain >applications. . .and we hope (Apple, you listening?) that they will fix >this gross over-sight. == Drew Taylor | Freelance web development using http://www.drewtaylor.com/ | perl/mod_perl/MySQL/postgresql/DBI mailto:[EMAIL PROTECTED] | Email jobs at drewtaylor.com -- Speakeasy.net: A DSL provider with a clue. Sign up today. http://www.speakeasy.net/refer/29655 ==
RE: Porting to OS X
Wheeler's site provides a lot of great information. When I get to my other computer, I can send you some other useful URLs for setting up UNIX apps on the OS X if you want. I found it took about an evening to install all the software. Another evening to get mod_perl apps up and running, but I had to install XML-related software, too. . .mysql is a snap, too. And I am NOT a sysadmin...not even close. I think it is relatively an easy move, IMHO. Just beaware that the Mac OS filesystem is NOT case-sensitive. Which can cause problems with certain applications. . .and we hope (Apple, you listening?) that they will fix this gross over-sight. Cheers, Ward -Original Message-From: Noam Solomon [mailto:[EMAIL PROTECTED]]Sent: Tuesday, June 04, 2002 10:43 AMTo: [EMAIL PROTECTED]Subject: Porting to OS X Can anyone give me a rough idea how much time it would take to move a server serving mod_perl websites from UNIX to OS X? It uses Apache::Session, DBI::Mysql, HTML::Mason, CGI, and Apache::OpenIndex, among others, and uses both AuthHandlers and AuthzHandlers. I know it's difficult to estimate without knowing how big the websites are, what kind of functions they call, etc., but if you could give me an idea of what kind of problems I can expect to encounter and how difficult they are to work around, I can give a quote to my client. Thanks, Noam Solomon
Re: Porting to OS X
On 6/4/02 10:43 AM, "Noam Solomon" <[EMAIL PROTECTED]> claimed: > Can anyone give me a rough idea how much time it would take to move a server > serving mod_perl websites > from UNIX to OS X? It uses Apache::Session, DBI::Mysql, HTML::Mason, CGI, and > Apache::OpenIndex, > among others, and uses both AuthHandlers and AuthzHandlers. It depends on how good a Sysadmin you are, but I would say a couple of days. I document how to install most of this stuff on my site: http://david.wheeler.net/osx.html I don't cover MySQL, but there's a link to an Apple article on how to install it in the section where I cover installing PostgreSQL. HTH, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Porting to OS X
Can anyone give me a rough idea how much time it would take to move a server serving mod_perl websites from UNIX to OS X? It uses Apache::Session, DBI::Mysql, HTML::Mason, CGI, and Apache::OpenIndex, among others, and uses both AuthHandlers and AuthzHandlers. I know it's difficult to estimate without knowing how big the websites are, what kind of functions they call, etc., but if you could give me an idea of what kind of problems I can expect to encounter and how difficult they are to work around, I can give a quote to my client. Thanks, Noam Solomon
Re: separating C from V in MVC
On 6/4/02 12:32 PM, Perrin Harkins wrote:
> The thing that worries me about a widget approach is that I would have
> the same problem I had with CGI.pm's HTML widgets way back: the
> designers can't change the HTML easilly. Getting perl developers out of
> the HTML business is my main reason for using templating.
My approach uses an intentionally limited subset of Mason as my "templating"
language. It looks something like this:
* Model: Regular Perl classes and objects.
* Controller: Regular Perl classes and objects, trivially wrapped in Mason
components to control access location (i.e. URL), object caching, and so on.
* View: Mason components that receive "widget"-like objects as well as
simple strings and other params.
To try to solve the "designers don't know Perl" problem, I just constrain
the API usage of the widget objects for designers. Example:
<% $form->field('name')->html_label %>
<% $form->field('name')->html_field %>
As concerned as I initially was by this syntax, the fact is that 99% of all
view objects have a series of exactly the same calls. Designers have no
clue what they do internally, but the fact is that the only part that really
changes is the field name. And there are very few, simple method names to
know: html_field, html_label, html_error, etc. In the simplest case,
there's even a few places where this works:
<% $form->field('name')->html %>
And handles the label (if any), field, and field-tied error message all in
one block. I guess the moral is that comfort != understanding. Designers
can get comfortable with even "ugly" syntax like the above very quickly
since it is repeated so often.
Yes, this means that all the nuts and bolts of what gets printed by those
calls is handled by the controller object (which produces the widgets,
populating them according to the data form the model objects), and therefore
the programmer. But IMO this is as it should be. The programmer flags
which form fields are "required", what HTML surrounds "error messages"
(usually just ) and so on. The designers change the
contents of the style sheets, make the graphics, and arrange the widgets on
the page.
And in a pinch, the programmer does have the full range of Mason features
available. IMO, it's not much harder for designers to learn some small
subset of a larger syntax (like Mason/Perl-Widget-API) than it is for them
to learn an equal size subset (or entirety) of a "little language" like
template toolkit.
-John
Re: DBI Bug
Perrin Harkins wrote: > Udlei Nattis wrote: > >> hi, sorry my english ;) >> >> when i add this line in httpd.conf >> >> PerlModule DBI >> >> or >> >> use DBI(); in startup.conf >> >> apache dont start, i receive this error: >> >> /usr/local/apache-2.0/bin/apachectl: line 192: 12547 Segmentation >> fault $HTTPD >> /usr/local/apache-2.0/bin/apachectl start: httpd could not be started >> >> i test it in >> Apache 2.0/Perl 5.8.0RC1/Modperl 1.99.02/03 >> Apache 2.0/Perl 5.7.3/Modperl 1.99.02/03 >> Apache 2.0/Perl 5.6.1/Modperl 1.99.02/03 >> Apache 2.0-cvs/All Perls/All Modperls > > > It definitely works with the Apache 1.x/mod_perl 1.x/perl 5.6.1 combo. > Maybe someone else can verify that they've run DBI under mod_perl 2? Works for me with 1.99, but see below. > You might need to use the pre-fork MPM when using DBI, depending on how > well your database driver works with threads. You should also make sure > you compile all of these with the same compiler, to ensure compatibility > between libraries. Folks, when you see a question like this, don't waste your time guessing in the dark without having the so needed details posted first. Just point them here: http://perl.apache.org/release/docs/2.0/user/help/help.html#Reporting_Problems You don't have to search for this item, it's in the shortcuts menu on the left. __ 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
Re: DBI Bug
Udlei Nattis wrote: > hi, sorry my english ;) > > when i add this line in httpd.conf > > PerlModule DBI > > or > > use DBI(); in startup.conf > > apache dont start, i receive this error: > > /usr/local/apache-2.0/bin/apachectl: line 192: 12547 Segmentation > fault $HTTPD > /usr/local/apache-2.0/bin/apachectl start: httpd could not be started > > i test it in > Apache 2.0/Perl 5.8.0RC1/Modperl 1.99.02/03 > Apache 2.0/Perl 5.7.3/Modperl 1.99.02/03 > Apache 2.0/Perl 5.6.1/Modperl 1.99.02/03 > Apache 2.0-cvs/All Perls/All Modperls It definitely works with the Apache 1.x/mod_perl 1.x/perl 5.6.1 combo. Maybe someone else can verify that they've run DBI under mod_perl 2? You might need to use the pre-fork MPM when using DBI, depending on how well your database driver works with threads. You should also make sure you compile all of these with the same compiler, to ensure compatibility between libraries. - Perrin
Re: separating C from V in MVC
Rob Nagler wrote:
> The way I understand how plugins work is that they are arbitrary
> classes. But how do you share behavior?
I probably wouldn't use a plugin for something that needed to output
HTML, because that would prevent the designers from editing it. A macro
(basically a mini-template) could be broken down into smaller shared
templates, but there is a practical limit to that approach.
> FILTER does not shared behavior, but is a pipe mechanism.
Yes. I think it would be a good way to do the FONT trick you mentioned
though.
> There is no protocol for communicating between these various
> components except well-known global variables.
That's correct. A template can call macros which are parameterized
(e.g. a macro for making large text headlines which accepts the text as
a parameter), but that's not exactly the same thing. If you find that
you really need to have stateful widgets that share data beyond whatever
model data was passed to the view, then templating is probably not an
appropriate solution.
> For example,
> if a Link is not executable by the current user, it won't render as a
> link (and possibly be completely blank depending on the circumstance
> and configuration).
That's easy to do, but not easy to share between multiple templates with
different appearances.
> Another concern I have about Template Toolkit (and other template
> languages) is that it has its own syntax and semantics for data and
> control structures distinct from Perl. Why isn't Perl good enough?
The syntax for accessing complex data structures in perl is non-trivial
and possibly too confusing for designers.
Here's the perl version:
foreach my $account ( @{$model_data->{'user'}->{'accounts'}} ) {
and in TT:
[% FOREACH account = user.accounts %]
or with localized loop variables, like HTML::Template:
[% FOREACH user.accounts %]
> My experience with "little languages" is that they take on a life of
> their own
That can happen, and I've seen some people do appalling things with
templating tools, but these people tend to be programmers working by
themselves with no separate designer. The place where these tools
really pay off is when you're working with a separate design group. My
experience has been that designers have no trouble grasping the basic
ideas of templating, and don't feel the need to try and wedge in stuff
that doesn't belong there.
The thing that worries me about a widget approach is that I would have
the same problem I had with CGI.pm's HTML widgets way back: the
designers can't change the HTML easilly. Getting perl developers out of
the HTML business is my main reason for using templating.
- Perrin
Re: Apache.pm failed to load!
[Please make sure to reply to the list on follow-ups, and not to the person who has answered your question. Thank you!] James Kirkland wrote: > Hi, > > Thanks for replying. I continue to get the errors when adding that line to > httpd.conf. Is there any specific point in the file to place it? When do you get this error >>James Kirkland wrote: >> >>>Hi, >>> >>>I am getting the "Apache.pm failed to load!" error. I need help to >>>resolve: >>> >>>[root@fisher mysql]# perl -MApache -e 1 >> >> >>You shouldn't be testing mod_perl modules from the command line. it >>won't work. >> >>If it happens under mod_perl, see: >> > > >http://perl.apache.org/release/docs/1.0/guide/troubleshooting.html#_Apache_pm_failed_to_load__ __ 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
modperl2 crashes under load (Win32)
Greetings.
I am hitting a complex Registry application with a number of almost
simultaneous, long running requests
(WinNT SP6 - VC++6 SP3 - perl5.8.0 RC1 - latest dev snapshot for modperl -
httpd-2.0_20020530041218.tar.gz for apache - everything built debug - a few
date.t tests fail on nmake test).
The crash happens in perllib.c at:
EXTERN_C PerlInterpreter *
perl_clone_host(PerlInterpreter* proto_perl, UV flags) {
dTHX;
CPerlHost *h;
h = new CPerlHost(*(CPerlHost*)PL_sys_intern.internal_host); //<==
BLAAAMM!
proto_perl = perl_clone_using(proto_perl, flags,
h->m_pHostperlMem,
h->m_pHostperlMemShared,
h->m_pHostperlMemParse,
h->m_pHostperlEnv,
h->m_pHostperlStdIO,
h->m_pHostperlLIO,
h->m_pHostperlDir,
h->m_pHostperlSock,
h->m_pHostperlProc
);
[...]
Coming from modperl_interp_new.
I have not been able to reproduce this on simpler applications, so far (but
I will try).
I can also crash the same app under normal usage, however, but not
reproducibly so: a constant factor in the crashes (not in the one described
above, though) appears to be the appearance of "bad header" warnigns in
error.log: the crash follows shortly.
Note that the same app runs fine (no warnings whatsoever under modperl1).
I suspect that the threading code is to blame on all these crash counts: my
app has 3 frames, all hitting the same URL in rapid succession and this
appears to be brushing modperl the wrong way.
All of the above happens with the default intepreter pool settings: if I try
to
tune it, the application goes southwest immediately, only misteriously so -
it just spins, without warnings or anything.
Cheers,
alf
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache.pm failed to load!
James Kirkland wrote: > > Hi, > > I am getting the "Apache.pm failed to load!" error. I need help to > resolve: > > [root@fisher mysql]# perl -MApache -e 1 You shouldn't be testing mod_perl modules from the command line. it won't work. If it happens under mod_perl, see: http://perl.apache.org/release/docs/1.0/guide/troubleshooting.html#_Apache_pm_failed_to_load__ -- __ 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
Apache.pm failed to load!
Hi,
I am getting the "Apache.pm failed to load!" error. I need help to
resolve:
[root@fisher mysql]# perl -MApache -e 1
Can't load
'/usr/lib/perl5/site_perl/5.6.1/i386-linux/auto/Slash/Apache/Apache.so' for
module Slash::Apache:
/usr/lib/perl5/site_perl/5.6.1/i386-linux/auto/Slash/Apache/Apache.so:
undefined symbol: perl_cmd_perl_TAKE1 at
/usr/lib/perl5/5.6.1/i386-linux/DynaLoader.pm line 206. at -e line
0Compilation failed in require.BEGIN failed--compilation aborted.
the end of the strace output is:
read(5, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\*\0\000"...,
1024) = 1024fstat64(5, {st_mode=S_IFREG|0755, st_size=41994, ...}) =
0brk(0x87ed000)
= 0x87ed000old_mmap(NULL, 37492, PROT_READ|PROT_EXEC, MAP_PRIVATE, 5, 0) =
0x40b32000mprotect(0x40b3a000, 4724, PROT_NONE) =
0old_mmap(0x40b3a000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED,
5, 0x7000) =
0x40b3a000close(5)
= 0open("/usr/lib/mysql/i686/mmx/libmysqlclient.so.10", O_RDONLY) = -1
ENOENT (No such file or directory)stat64("/usr/lib/mysql/i686/mmx",
0xbfffef30) = -1 ENOENT (No such file or
directory)open("/usr/lib/mysql/i686/libmysqlclient.so.10", O_RDONLY) = -1
ENOENT (No such file or directory)stat64("/usr/lib/mysql/i686",
0xbfffef30) = -1 ENOENT (No such file or
directory)open("/usr/lib/mysql/mmx/libmysqlclient.so.10", O_RDONLY) = -1
ENOENT (No such file or directory)stat64("/usr/lib/mysql/mmx",
0xbfffef30) = -1 ENOENT (No such file or
directory)open("/usr/lib/mysql/libmysqlclient.so.10", O_RDONLY) =
5read(5, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\220\200"...,
1024) = 1024fstat64(5, {st_mode=S_IFREG|0755, st_size=251027, ...}) =
0old_mmap(NULL, 216960, PROT_READ|PROT_EXEC, MAP_PRIVATE, 5, 0) =
0x40b84000mprotect(0x40ba1000, 98176, PROT_NONE) =
0old_mmap(0x40ba1000, 98304, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED, 5, 0x1d000) =
0x40ba1000close(5)
=
0brk(0x87ee000)
=
0x87ee000brk(0x87ef000)
=
0x87ef000brk(0x87f)
= 0x87frt_sigprocmask(SIG_BLOCK, NULL, [RTMIN], 8) = 0write(2,
"Apache.pm failed to load!.\n", 27) = 27_exit(2)
[root@fisher mysql]# rpm -qa |grep
perlperl-SGMLSpm-1.03ii-4perl-DB_File-1.75-34.99.6groff-perl-1.17.2-12perl-libxml-enno-1.02-15perl-libwww-perl-5.63-9perl-libxml-perl-0.07-14perl-5.6.1-34.99.6perl-CPAN-1.59_54-34.99.6perl-NDBM_File-1.75-34.99.6perl-DateManip-5.40-15perl-Digest-MD5-2.16-15perl-Parse-Yapp-1.05-15perl-URI-1.17-16perl-XML-Encoding-1.01-9perl-XML-Parser-2.30-15perl-XML-Dumper-0.4-12perl-Crypt-SSLeay-0.35-15perl-Frontier-RPC-0.06-14perl-suidperl-5.6.1-34.99.6perl-TimeDate-1.10-14mod_perl-1.26-5perl-CGI-2.752-34.99.6perl-Storable-1.0.14-15perl-XML-Grove-0.46alpha-11perl-XML-Twig-2.02-9perl-Devel-Symdump-2.01-15perl-Time-HiRes-1.20-14
thanksJames
Re: Re: Apache->server_root_relative(); not found
At 13:30 04.06.2002, m31 wrote: >Well, I printed out my @INC to screen, and now I have directories that do >not exist in it from putting the wrong path in the server_root_relative >method, can any-one tell me how to remove this dir from @INC? I treid a >few ways but to no sucess. Restart your server? "use lib" doesn't make any permanent changes to @INC, these only persist across the httpd mod_perl run. If you restart (with the correct code this time), it should be set to the correct value. -- Per Einar Ellefsen [EMAIL PROTECTED]
Re: Apache->server_root_relative(); not found
m31 wrote: > Thank you all for your help. You are correct, I didn't dawn on me that > my ServerRoot is somewhat different than my document root. I was > expecting it to return my documenrt root. > (embarasment...hence SERVER_ROOT_relative()) > Well, I printed out my @INC to screen, and now I have directories that > do not exist in it from putting the wrong path in the > server_root_relative method, can any-one tell me how to remove this dir > from @INC? I treid a few ways but to no sucess. Please be more specific. What have you done to @INC so it includes non-existing dirs? You must have added them. A *short* code fragment is the best so we can reproduce the problem. > Please be patient with idiocracy, I'm just a student trying to get ahead. Don't worry :) Just try to provide more details in first place, so there will be less ping-pong emails here. __ 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
Re: rfc Apache::Dynagzip
On Tue, 4 Jun 2002, Alvar Freude wrote:
> >> Also compressed output does not work on IE, if the request was POSTed
> >> (only tested with older version, I gess 4.0, of IE).
> >
> > I did not know about IE4 and POSTs, at least I did not received
> > mod_deflate bug reports about it.
>
> I realized this on http://www.a-blast.org/ when posting some texts. As I
> remember this was very strange, because sometimes it works but mostly not.
>
>
> > I know two IE4 gzip bugs. They
> > described in http://sysoev.ru/mod_deflate/readme.html#browsers (sorry,
> > Russian only).
>
> hmm, Don't understand Russion ;) -- perhaps it's a siede effect of one of
> this bugs?
I think these bugs unrelated.
1. MSIE 4.x can not handle gzipped response if its URL without "http://";
prefix is bigger then 253 bytes.
2. MSIE 4.x has bug with gzipped response and byte-range request (I found
this bug while testing mod_deflate and it should never occured under usual
conditions).
> >># Important: we change output
> >># according to this headers
> >>$r->header_out('Vary', 'Accept-Encoding, User-Agent');
> >
> > It's not good idea - it disables caching in MSIE.
>
> really?
> hrmpf!
>
> I tested it now with MSIE 5.5; sometimes it fetched the file, sometimes it
> came from cache. I also remember, that at another project i set for testing
> purpose the expire time +100 seconds. And forgot it to remove after
> testing. AARRGH! ==> MSIE cached the page even if there was a hard reload,
> the old page remains in cache. It was a hard to find bug ;-)
>
> But "Vary" there was also set, so it seems that at least under some
> circumstances MSIE caches data with vary.
In my tests MSIE did not cache responses with any "Vary" header.
> I included it because a proxy server may get an request from a browser
> which understands gzip; and some seconds later from one who doesn't
> understand it (i.e. MSIE Mac). So, if the proxy forwards the compressed
> data to the second browser this will fail.
>
> What experiences do you have with this?
By default mod_deflate does not gzip responses to proxied requests (that
have "Via" header) and HTTP/1.0 requests. It can be overridden.
> >># don't forget Content-Length!
> >># it enables keepalive and
> >># disables some Netscape bugs
> >>$r->header_out('Content-Length', length(${ $out->{document} }));
> >
> > I'm not sure that sending Content-Length with gzipped content is good
> > idea. MSIE understands chunked transfer and can keep alive connection.
> > For NN4 we should close connection.
>
> i mostly closed connection , because keep alive blocked a bug Apache (on
> http://www.a-blast.org/ each httpd is about 38-42 MB, but mostly shared);
> but now i moved to frontend and backend apache, so there are not too much
> memory consumption thrown away for static requests or requests to my other
> Vhosts.
>
> I had several really *hard* problems without Content-Length and NN4:
>
> If in the page is some document.write JavaScript and there is no
> Content-Length, NN4 writes some of the document.write-Code into a random
> part of the HTML file. :-( This often destroys the hole page, e.g. if it
> overwrites closing -Tags.
> Several weeks i searched for this ugly bug, because sometimes it destoys
> the page and sometimes not. If destoying, Netscape does also not realise
> that the connection is already closed and the stars are moving, indicating
> further loading. But when the content-length is correctly set, it works.
>
> I guess that NN4 gets confused with the end of the page and when he should
> start with running of the JavaScript.
I usually disable javascript in my NN4 (it's so buggy) so I did not see
this problem.
Igor Sysoev
http://sysoev.ru
Re: rfc Apache::Dynagzip
Hi,
-- Igor Sysoev <[EMAIL PROTECTED]> wrote:
> NN4 for Windows does not decompress gzipped Flash. NN4 for Unix does.
aah, OK, I only checked it on Windows and then stopped compüressing
everything else then text/html with NN4.
> But no one browser decompress gzipped response that is fetched via
> Flash's loadVariables() and XML.load() functions.
yes, for this reason I disabled compression for all NN4 when the
content-type isn't text/html.
>> Also compressed output does not work on IE, if the request was POSTed
>> (only tested with older version, I gess 4.0, of IE).
>
> I did not know about IE4 and POSTs, at least I did not received
> mod_deflate bug reports about it.
I realized this on http://www.a-blast.org/ when posting some texts. As I
remember this was very strange, because sometimes it works but mostly not.
> I know two IE4 gzip bugs. They
> described in http://sysoev.ru/mod_deflate/readme.html#browsers (sorry,
> Russian only).
hmm, Don't understand Russion ;) -- perhaps it's a siede effect of one of
this bugs?
> All NN4.5+ say "Accept-Encoding: gzip". NN4.0x for Unix and PPC Mac do
> not say but understand it but they too rare now so you can ignore them.
ah, OK. I'd stolen this part of the code from the GzipChain module.
> NN4 also does not undresatnd gzipped application/x-javascript and ext/css:
> http://sysoev.ru/mod_deflate/readme.html#types
yes; therefor it's sure to only compress text/html on NN4 -- if not
explicitly tested that it works.
>># Important: we change output
>># according to this headers
>>$r->header_out('Vary', 'Accept-Encoding, User-Agent');
>
> It's not good idea - it disables caching in MSIE.
really?
hrmpf!
I tested it now with MSIE 5.5; sometimes it fetched the file, sometimes it
came from cache. I also remember, that at another project i set for testing
purpose the expire time +100 seconds. And forgot it to remove after
testing. AARRGH! ==> MSIE cached the page even if there was a hard reload,
the old page remains in cache. It was a hard to find bug ;-)
But "Vary" there was also set, so it seems that at least under some
circumstances MSIE caches data with vary.
I included it because a proxy server may get an request from a browser
which understands gzip; and some seconds later from one who doesn't
understand it (i.e. MSIE Mac). So, if the proxy forwards the compressed
data to the second browser this will fail.
What experiences do you have with this?
>># don't forget Content-Length!
>># it enables keepalive and
>># disables some Netscape bugs
>>$r->header_out('Content-Length', length(${ $out->{document} }));
>
> I'm not sure that sending Content-Length with gzipped content is good
> idea. MSIE understands chunked transfer and can keep alive connection.
> For NN4 we should close connection.
i mostly closed connection , because keep alive blocked a bug Apache (on
http://www.a-blast.org/ each httpd is about 38-42 MB, but mostly shared);
but now i moved to frontend and backend apache, so there are not too much
memory consumption thrown away for static requests or requests to my other
Vhosts.
I had several really *hard* problems without Content-Length and NN4:
If in the page is some document.write JavaScript and there is no
Content-Length, NN4 writes some of the document.write-Code into a random
part of the HTML file. :-( This often destroys the hole page, e.g. if it
overwrites closing -Tags.
Several weeks i searched for this ugly bug, because sometimes it destoys
the page and sometimes not. If destoying, Netscape does also not realise
that the connection is already closed and the stars are moving, indicating
further loading. But when the content-length is correctly set, it works.
I guess that NN4 gets confused with the end of the page and when he should
start with running of the JavaScript.
Ciao
Alvar
--
// Unterschreiben! http://www.odem.org/informationsfreiheit/
// Internet am Telefon: http://www.teletrust.info/
// Das freieste Medium? http://www.odem.org/insert_coin/
// Blaster: http://www.assoziations-blaster.de/
Re: Re: Apache->server_root_relative(); not found
Stas Bekman wrote:
>On Mon, 3 Jun 2002, m31 wrote:
>
>>Yes, I'm running it under mod_perl/1.27 which I compiled as a DSO with
>>apxs. This also gave me errors under 1.25, I just pushed @INC to solve
>>it but I would like to use server_root_relative. I have it in a startup
>>script, the one from the eagle book. It goes like:
>>#! /usr/bin/perl
>>
>>BEGIN {
>>use Apache ();
>>use lib Apache->server_root_relative('lib/perl');
>>}
>>
>>use Apache::Registry ();
>>use Apache::Constants ();
>>use CGI qw(-compile :all);
>>use CGI::Carp ();
>>use DBI ();
>>1;
>>
>>Which I had it to change to: push(@INC, '/Library/www/lib/perl');
>>because the server_root_relative gave me errors. I read some where that
>>in order to test with startup scripts you need to use the
>>Apache::FakeRequest? Even if so, if I ignore the errors and just restart
>>apache, it wont find 'lib/perl', so I have to push @INC manually then do
>>a graceful restart for it to work. I am running OSX 10.1.4/Darwin. Dont
>>think that has anything to do with it though.
>>
>
>There are two separate issues here:
>
>1. you try to test perl code which only runs under mod_perl. but according
>to your report you don't have a problem calling server_root_relative()
>when you start the server. So this is not a problem, right?
>
>2. your problem is that Apache->server_root_relative('lib/perl') doesn't
>return what you expect. Is your ServerRoot set to '/Library/www'?
>
>
>__
>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
>
>
Thank you all for your help. You are correct, I didn't dawn on me that
my ServerRoot is somewhat different than my document root. I was
expecting it to return my documenrt root.
(embarasment...hence SERVER_ROOT_relative())
Well, I printed out my @INC to screen, and now I have directories that
do not exist in it from putting the wrong path in the
server_root_relative method, can any-one tell me how to remove this dir
from @INC? I treid a few ways but to no sucess.
Please be patient with idiocracy, I'm just a student trying to get ahead.
Re: mod_perl netscape problem
Hi, -- Iyengar Yoga Resources <[EMAIL PROTECTED]> wrote: > Pages that go through the mod_perl server have 'strange' strings at the > top and the bottom, when you view them with Netscape 4.x (any OS, it > seems). Also, the page does not stop loading. This does not happen with > other browsers (Mozilla 1RC2, IE 5, Opera 6). An example can be found at beside the already described Proxy bug i realized another Bug in Netscape: If you didn't print out the Content-Length header, Netscape 4.x destroys the page, if there are some JavaScripts (at least with "document.write") inside. Including Content-Length in the headers fixes this. Ciao Alvar -- // Unterschreiben! http://www.odem.org/informationsfreiheit/ // Internet am Telefon: http://www.teletrust.info/ // Das freieste Medium? http://www.odem.org/insert_coin/ // Blaster: http://www.assoziations-blaster.de/
Failure on modules and core tests for 5.8.0RC1
[ Recipients of this message are either subscribers to the modperl or
perlporters lists,
or listed as authors of theinvolved modules]
> -Original Message-
> From: [mailto:[EMAIL PROTECTED]]
> Sent: Monday, June 03, 2002 9:38 PM
> To: Alessandro Forghieri
> Cc: [EMAIL PROTECTED]
> Subject: Re: [2.x] test fails on win32 version 1.99_02
>
>
> On Monday, 2002-06-03 at 18:32:54 +0200, Alessandro Forghieri wrote:
>
> > reetings.
>
> :-)
>
> > I have been trying 5.8RC1 and I tried to compile/install
> several modules
> > that I have
> > on 5.6.1 - CPAN, not PPM.
> > At least the following do not build and/or test right (not
> exhaustive, as I
> > got tired after a while):
>
>
> > Posted in the hope it may help somebody...
>
[EMAIL PROTECTED] Wrote:
> Can you please send a detailed report to the perl5porters list?
> [EMAIL PROTECTED]
> and the module authors? Please include the version numbers
> and all error messages.
>
And so it goes... I am changing the subject, to make it more descriptive, as
this does not
really relate to modperl.
Machine is wintel NTSP6, VC++6 SP3.
1) Besides failures on various modules, I also witnessed (today) a SEGFAULT
on the tests while building a debug version (curiously, the stack trace ends
up in msvcrt - I would've expected msvcrtd).
The crash happens during:
../lib/Tie/File/t/12_longfetch_rs..
It appears to wedge in Perl_NEWFOROP:
#ifdef PL_OP_SLAB_ALLOC
{
LOOP *tmp;
NewOp(1234,tmp,1,LOOP);
Copy(loop,tmp,1,LOOP);//op_nextop and
loop->op_lastop both show up as expression that "Cannot be evaluated" by the
debugger (but maybe that's normal). As far as I remember, this did not
happen on a previous release build.
All other tests complete sucessfully.
2) and now on to the modules failures. I trid to reapply my 5.6.1 AS630
bundle and I had several failures. I tracked three of them more closely. Two
(Tk and Archive::Tar) are described below in a message I posted to perlmonks
yesterday. The third - MLDBM is described in what follows.
MLDBM-2.000 fails the first test of each suite. I debugged the first failure
(dumper.t) and
it fails a comparison on two would-be equal structures:
DB<3> p $first
$a = [
1,
{
c => [
\'c'
],
a => $a,
b => $a->[1]
},
$a->[1]{c}
];
$b = {
c => [
\'c'
],
a => [
1,
$b,
$b->{c}
],
b => $b
};
$c = [
\'c'
];
DB<4> p $second
$a = [
1,
{
a => $a,
b => $a->[1],
c => [
\'c'
]
},
$a->[1]{c}
];
$b = {
a => [
1,
$b,
[
\'c'
]
],
b => $b,
c => $b->{a}[2]
};
$c = [
\'c'
];
So this is pretty serious - given the above interpreter error in a 'tie'
test, some relation among the two can be inferred.
I also had uninvestigated failures in the following modules - all at their
latest CPAN versions:
o) Devel::TraceLoad 0.08 # Test Failure
t\allFAILED test 1
Failed 1/5 tests, 80.00% okay
Failed Test Stat Wstat Total Fail Failed List of Failed
---
t\all.t51 20.00% 1
Failed 1/1 test scripts, 0.00% okay. 1/5 subtests failed, 80.00% okay.
o) Module::Info 0.12# Several test errors
Test returned status 16 (wstat 4096, 0x1000) DIED. FAILED tests 10-15,
40-47, 50-51
Failed 16/51 tests, 68.63% okay
Failed Test Stat Wstat Total Fail Failed List of Failed
---
t\Module-Info.t 16 409651 16 31.37% 10-15 40-47 50-51
Failed 1/1 test scripts, 0.00% okay. 16/51 subtests failed, 68.63% okay.
o) Win32::API 0.20 #C diagnostic
API.c
API.xs(155) : error C2065: 'na' : undeclared identifier
API.xs(237) : warning C4244: '=' : conversion from 'double ' to 'float ',
possib
le loss of data
o) libxml-perl 0.07 # Fails test
D:\perl58\bin\perl.exe "-MExtUtils::Command::MM" "-e"
"test_harness(0, '
blib\lib', 'blib\arch')" t\amsterdam.t t\canon_xml_writer.t t\schema.t
t\stream.
t t\subs.t t\xp_sax.t
t\amsterdam...ok
t\canon_xml_writerok
t\schema..ok
t\stream..FAILED test 11
Failed 1/11 tests, 90.91% okay
t\subsok
t\xp_sax..ok
Failed Test Stat Wstat Total Fail Failed List of Failed
---
t\stream.t111 9.09% 11
Failed 1/6 test scripts, 83.33% oka
Re: rfc Apache::Dynagzip
On Tue, 4 Jun 2002, Alvar Freude wrote:
> The last years I experimented a lot with gzipped output and wrote my own
> gzipping output function (but without chunked encoding :-) ). I realized a
> lot of bugs with some different browsers under some environments or
> situations. I found no remarks according this in your documentation, so
> perhaps you missed something?
> (if I missed something, feel free to write ;-) )
>
> So, e.g. I created a website with a big server generated flash movie (with
> Flash generator, mod_perl, Postgres; yep, Flash sucks!), and Netscape
> doesn't decompress the output, but claims to understand gzip. AARRGH!
NN4 for Windows does not decompress gzipped Flash. NN4 for Unix does.
But no one browser decompress gzipped response that is fetched via
Flash's loadVariables() and XML.load() functions.
> Also compressed output does not work on IE, if the request was POSTed (only
> tested with older version, I gess 4.0, of IE).
I did not know about IE4 and POSTs, at least I did not received mod_deflate
bug reports about it. I know two IE4 gzip bugs. They described in
http://sysoev.ru/mod_deflate/readme.html#browsers (sorry, Russian only).
> gzip compression is enabled when:
>
>- browser acceps gzip
>- or browser is an Bugscape 4.x on X11 or Mac
All NN4.5+ say "Accept-Encoding: gzip". NN4.0x for Unix and PPC Mac do
not say but understand it but they too rare now so you can ignore them.
> but gzip is DISABLED when:
>
>- method is not GET:
> at least on some versions of IE (4.x), compressed pages didn't work
> together with POST!
I did not know this bug. I will check.
>- every image/* content type needs no gzip (at least GIF and JPEG ...)
>
>- browser is not "compatible" and Content-Type is not text/html,
> even if browser said that he understand gzip
> At least Bugscape 4.x didn't decompress embedded objects like
> flash movies
NN4 also does not undresatnd gzipped application/x-javascript and ext/css:
http://sysoev.ru/mod_deflate/readme.html#types
># Important: we change output
># according to this headers
>$r->header_out('Vary', 'Accept-Encoding, User-Agent');
It's not good idea - it disables caching in MSIE.
># don't forget Content-Length!
># it enables keepalive and disables
># some Netscape bugs
>$r->header_out('Content-Length', length(${ $out->{document} }));
I'm not sure that sending Content-Length with gzipped content is good
idea. MSIE understands chunked transfer and can keep alive connection.
For NN4 we should close connection.
Igor Sysoev
http://sysoev.ru
Re: rfc Apache::Dynagzip
On Mon, 3 Jun 2002, Slava Bizyayev wrote: > Finally, I'm going to upload the Apache::Dynagzip 0.03 to CPAN by the evening of >June 4-th. I'm not sure about the quality of my documentation yet. It's available now >at http://devl4.outlook.net/devdoc/Dynagzip/Dynagzip.html for preview. I would >appreciate any comments in order to fix something important before the first upload. I can not see http://devl4.outlook.net/devdoc/Dynagzip/Dynagzip.html in NN 4.78. It show message box "A commmunication error occured". I think this is due to "Transfer-Encoding: chunked" and "Content-Encoding: gzip". NN 4.78 does not understand chunked response but can show it (with strange numbers of course) if there were no gzip encoding. Igor Sysoev http://sysoev.ru
