subroutine redefined
Hi,
I tried using ModPerl::Registry with this piece of CGI code:
#!/usr/bin/perl -w
use CGI;
use strict;
my $cgi = CGI::-new;
print $cgi-header;
our $count = 0;
for (1 .. 5) {
increase_count();
}
sub increase_count {
our $count;
$count++;
print $count . br\n;
}
It gave me this error:
Subroutine increase_count redefined at /var/www/perl/test.pl line 12.
What is the problem?
Re: UTF-8 support [was : (Re: [mp2] make test fails with 1.99_10-devsources on redhat)]
Perrin Harkins wrote: Mithun Bhattacharya wrote: If perl's UTF-8 support is broken in 5.8.0 doesnt that mean it will break any mod_perl application which is handling XML's or UTF-8 data ? I didn't say it was broken. I don't really know if it is. What I do know is that some documents, including CPAN modules, are not UTF8 compliant, and opening them as UTF8 gives mysterious errors and test failures. Remember, this locale setting is a recent change. I doubt that chaning it back to what it was in Red Hat 7.3 will impact XML parsing. To second Perrin, 5.8.0's UTF8 support is not broken. From what I was following on the p5p, 5.8.0 had some minor issues, but 5.8.1 which will be released really soon now (my guess: July at OSCon) have them (all?) sorted out. You may want to browse p5p archives and rt.perl.org to see what UTF8 problems were if any and whether they were resolved. If you find something that would be of interest to other readers, please post a summary 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: handler($$) unreliability
Frank Maas wrote:
Are you using 'lookup_uri' or another form of subrequest somewhere
in your handlers? Try tracing your request and see where it goes
wrong. I had similar problems and it pointed out to be an error in
a subrequest. Consult the mailinglist archive if you want.
--Frank
I have handler that looks like this:
sub handler ($$) {
my ($class, $apache) =3D @_;
Apache::request($apache);
$apache-status(200); # Default
#.
}
The vast majority of the time, this works fine. Every now
and then, usually after the apache server has been up
Besides, you really, really want to move to perl 5.6.1.
__
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: subroutine redefined
On Sat, 14 Jun 2003 16:40:15 +0900 Batara Kesuma [EMAIL PROTECTED] wrote: What is the problem? Ok, I just figured out that the error went away if I restarted the httpd server.
Re: How practical is that Practical mod_perl?
Slava, In my understanding you would better rewrite p.401-402 from the scratch for the next edition (which is not supposed to happen very soon, isn't it?). Otherwise, you will have to rewrite Apache::GzipChain appropriately. Whatever you decide, I would be more than happy to help you in that work. Just let me know. I will be waiting around. There is no need to wait for the next edition. Almost every technical book nowadays has an errata which keeps on growing, since the technology advance makes chunks of the book obsolete. We all know that and people are used to refer to the errata list which provides the updates and corrections if any. When the next edition comes, these updates normally get merged into the book. I think the simplest possible thing to do is this: Make sure that the tutorial on compression: http://perl.apache.org/docs/tutorials/client/compression/compression.html is up-to-date and everybody is happy with it. We will link to that document from the errata page, so all those interested in the compression state of art will read it before using it. When the time for a new edition comes, we will make sure that the link to the most up-to-date tutorial will be in the book. If you think that some of the compression-related material provided in the book is erroneous, I'd be more than happy to fix it, hopefully with a help of experts like yourself.please submit any corrections to [EMAIL PROTECTED] and we will put them online at http://modperlbook.org/. I think it's a time to start a new thread on how to improve: http://perl.apache.org/docs/tutorials/client/compression/compression.html __ 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: How practical is that Practical mod_perl?
Stas Bekman wrote: Slava, [chomp] I think it's a time to start a new thread on how to improve: http://perl.apache.org/docs/tutorials/client/compression/compression.html For starters, apache2/mp2 coverage. As I understand it, and my logs seem to indicate, mod_deflate compresses everything thrown at it, dynamic or otherwise :)
Re: apache::request parse() doesn't capture abort error
Hector Pizarro [EMAIL PROTECTED] writes:
[...]
If the user closes the popup in the middle of an upload, Apache::Request
parse() isn't throwing any error, and all the following code in my module
savesthe file incomplete in the system, which of course is garbage data.
Is this a bug, an incomplete feature, or is my configuration?
It's probably a bug in c/apache_multipart_buffer.c. We may not
do error-checking well enough on fill_buffer().
If parse is supposed to return an error code, which one is that? 206 =
HTTP_PARTIAL_CONTENT?
No, that's not an error code. Since the error here seems
to arise from ap_get_client_block, $r-status should probably
be -1.
Ok, now let's suppose that this error is fixed.
With a patch, I hope ;-).
I want to do several uploads fromthe same popup at once, so I have 5
file boxes in the form. If the user closesthe popup before the process
ends, i'd like to save only the completed files, how could I check
which files are correctly uploaded, and which ones are incomplete?
You could just ignore the final upload object, which has no - next
pointer:
for (my $u = $req-upload; $u $u-next; $u = $u-next) {
# do something with $u
}
--
Joe Schaefer
Re: How practical is that Practical mod_perl?
From: Ged Haywood [EMAIL PROTECTED] Sent: Friday, June 13, 2003 6:30 AM Subject: Re: How practical is that Practical mod_perl? It is unrealistic (and perhaps a little Oriental?) to refuse to accept that we make mistakes, and that we will continue to make them. It is far more constructive to prepare for them - usually one would try to minimise their impact; to acknowledge them, and if necessary to own up to them :) when they are made; and to take whatever corrective action might be called for in a timely fashion. Yes Ged, we are on the same page here. Just different words. In all the above, for several years Stas has set us a fine example. Personally I fail to understand: Why would I hesitate to ask list for a help being ordered to write (or review) things in which I feel not quite expert? Of course, it is not mandatory to do when you feel strong enough to take full responsibility for the result... I don't know if I fully understand what you're saying here. When, here on this List and on numerous occasions, Stas begged us for reviews of the text of his book, did you respond? I didn't even hear about that. Hm... I have TOTALLY missed the thread... So, what it looks like? In fact, it was stupid me who missed the call, failed to respond and to help guys timely, and is now barking like a dog, shaming others for the own fault?.. Looks like a moment of truth. I feel really sorry for the fault to help timely. I apologize especially to Stas and Eric for the hurtful words... Slava
Need help again
Hi, Thx for help, finally installing Apache 1.3 put mod_perl to work. I have another question. Now I have Apache configured to interpret in perl all files in particular directory. But Iwant perl to be accessible on whole site and just files with particular extensions should be interpreted in perl. Is it possible to do it? Oskar
Re: How practical is that Practical mod_perl?
gzip problem in IE6 http://support.microsoft.com/default.aspx?scid=kb;en-us;Q312496 is over since 1. M$ provides a free patch; 2. those lazy users (who usually don't care to apply patches) are not able to report problems anymore. Personally, I would recommend not to deal with deflate when possible. Thanks, Slava - Original Message - From: David Dick [EMAIL PROTECTED] To: Slava Bizyayev [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, June 13, 2003 6:46 AM Subject: Re: How practical is that Practical mod_perl? ok, i thought you might have been referred to problems that early versions of IE6 seemed to have with gzip, or with deflate problems in mozilla/n6. Slava Bizyayev wrote: NN-4.X sends HTTP header Accept-Encoding: gzip requesting any web content. Unfortunately NN-4.X fails to ungzip css files and JavaScript libraries. It is pretty old and well-known bug in NN-4.X. To work around this bug mod_gzip uses internal procedures for recognition of NN-4.X. The similar approach is used in mod_deflate. Apache::GzipChain does not have internal resources to work around this bug. You can find on CPAN http://search.cpan.org/author/SLAVA/Apache-CompressClientFixup-0.06/ which is supposed to serve any mod_perl compressor including Apache::GzipChain, but this handler is missed in example on p.402. # From: [EMAIL PROTECTED] # To: [EMAIL PROTECTED] # Date: Wed, 15 Jan 2003 20:05:06 +0200 # # ... Our customers still include 17% Netscape 4 users, sigh ... # Thanks, Slava - Original Message - From: David Dick [EMAIL PROTECTED] To: Slava Bizyayev [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, June 12, 2003 4:41 PM Subject: Re: How practical is that Practical mod_perl? The direct implementation of the example configuration p.402 is supposed to lead you to about 15% of unsatisfied clients recently. Can we have some more information about what in the implementation leads to the unsatisfied clients?
Re: How practical is that Practical mod_perl?
Hi Slava, On Sat, 14 Jun 2003, Slava Bizyayev wrote: So, what it looks like? http://groups.yahoo.com/group/modperl/message/34174 Looks like a moment of truth. Yup. :) 73, Ged.
Re: problem building libapreq on Solaris
Hi there, On Fri, 13 Jun 2003, Xavier Noria wrote: Hello, I've just compiled Apache 1.3.27 with mod_perl 1.27 from their tarballs on Solaris. perl is 5.8.0 packaged for Solaris. The installation of libapreq with cpan(1) stops here: [snip] t/httpd -f `pwd`/t/httpd.conf /bin/sh: t/httpd: not found [snip] Looks like it's taking t/httpd instead of /usr/local/apache/bin/httpd, Don't know if there's anyone who actually knows what's going on here but I thought you'd just like to hear from somebody. :) This is a wild stab in the dark. Guessing that the libapreq installation scripts are assuming that you're building a new Apache/mod_perl, you might in that case be expected to have a copy of the a httpd in the t directory. When you run 'make test' during an Apache build that's where the binary will be, temporarily. You could try a soft link from there to the real httpd - I have no idea if something else will then fail. You know that your mod_perl and your Perl should really be compiled with the same compiler? I always think it's best to build it yourself to be sure. 73, Ged.
Maintainers of Apache::*LDAP packages...?
Hi! I have just finished porting Apache::AuthNetLDAP to work with both modperl 1 and 2. I have been looking at some of the other packages that are lurking in this same arena, (ie Apache::AuthPerLDAP, Apache::AuthzLDAP, Apache::AuthzNetLDAP, Apache::AuthenLDAP, etc.), and was wondering what the general thoughts were about porting these as well...? Or, since they are all similar, should I focus on subsuming all of the modules into the more appropriately named Apache::AuthenLDAP and Apache::AuthzLDAP? Thanks, -- Shannon Eric Peevey - speeves Computer Systems Manager UNT - Central Web Support (940)369-8876 - This mail sent through IMP: http://horde.org/imp/
Re: Need help again
On Sat, 14 Jun 2003, Oskar wrote: Hi, Thx for help, finally installing Apache 1.3 put mod_perl to work. I have another question. Now I have Apache configured to interpret in perl all files in particular directory. But I want perl to be accessible on whole site and just files with particular extensions should be interpreted in perl. Is it possible to do it? Oskar http://httpd.apache.org/docs/howto/cgi.html descibes various ways of configuring Apache to permit CGI execution. -- best regards, randy kobes
Re: mod_perl slower than expected?
Is there anything I may be missing about the general configuration or environment of mod_perl which may be causing this strange situation? Try profiling... Some time ago I found my modperl app to be fairly slow because I turned on use Carp (and was carping errors and warnings). After disabling carping it was almost 10 times faster. I have also found that SWIG generated interface to some C++ library is very inefficient in some places (especially destructing a lot of objects) and manually written XS module happened to be a few times faster (it was the case with a lot of small objects). I think there are also other similar potential problems... -- ( Marcin Kasperski | Most of the bad things that can happen to a project ) ( http://www.mk.w.pl | are the result of miscommunication. (Booch) ) () ( Porady dla programisty Oracle: http://www.mk.w.pl/porady/porady_oracle )
each considered harmful?
Hmm, probably well known but ... I have not met any direct warning of
this problem so far.
our %SOME_CONFIG = (
a = 1,
b = 2,
c = 3,
);
...
while (my($k,$v) = each %SOME_CONFIG) {
if( ... ) {
return; # or last, or throw exception
}
}
You probably see the problem - when this code is re-executed (next
request), the loop iterates just over 'the rest' of the hash.
Does there exist some way to protect before this problem (some kind of
auto-destructor, finally, whatever which would automatically rewind
the hash internal iterator while leaving the context)?
Re: each considered harmful?
On Sat, Jun 14, 2003 at 11:33:17PM +0200, Marcin Kasperski wrote:
Hmm, probably well known but ... I have not met any direct warning of
this problem so far.
our %SOME_CONFIG = (
a = 1,
b = 2,
c = 3,
);
...
while (my($k,$v) = each %SOME_CONFIG) {
if( ... ) {
return; # or last, or throw exception
}
}
You probably see the problem - when this code is re-executed (next
request), the loop iterates just over 'the rest' of the hash.
Does there exist some way to protect before this problem (some kind of
auto-destructor, finally, whatever which would automatically rewind
the hash internal iterator while leaving the context)?
Not really a mod_perl problem, but you can read about the solution in
the docs for each.
There is a single iterator for each hash, shared by all each,
keys, and values function calls in the program; it can be reset
by reading all the elements from the hash, or by evaluating keys
HASH or values HASH.
perldoc -f each
--
Paul Johnson - [EMAIL PROTECTED]
http://www.pjcj.net
Re: How practical is that Practical mod_perl?
or, as a bugfix for future versions of mod_perl compression modules, before compressing the page, the module should provide the option of adding 2048 bytes of spaces to the beginning of the page, which according to my quick calculations, gzips down to 46 bytes? only for ie6 of course. :) Slava Bizyayev wrote: gzip problem in IE6 http://support.microsoft.com/default.aspx?scid=kb;en-us;Q312496 is over since 1. M$ provides a free patch; 2. those lazy users (who usually don't care to apply patches) are not able to report problems anymore. Personally, I would recommend not to deal with deflate when possible. Thanks, Slava - Original Message - From: David Dick [EMAIL PROTECTED] To: Slava Bizyayev [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, June 13, 2003 6:46 AM Subject: Re: How practical is that Practical mod_perl? ok, i thought you might have been referred to problems that early versions of IE6 seemed to have with gzip, or with deflate problems in mozilla/n6. Slava Bizyayev wrote: NN-4.X sends HTTP header Accept-Encoding: gzip requesting any web content. Unfortunately NN-4.X fails to ungzip css files and JavaScript libraries. It is pretty old and well-known bug in NN-4.X. To work around this bug mod_gzip uses internal procedures for recognition of NN-4.X. The similar approach is used in mod_deflate. Apache::GzipChain does not have internal resources to work around this bug. You can find on CPAN http://search.cpan.org/author/SLAVA/Apache-CompressClientFixup-0.06/ which is supposed to serve any mod_perl compressor including Apache::GzipChain, but this handler is missed in example on p.402. # From: [EMAIL PROTECTED] # To: [EMAIL PROTECTED] # Date: Wed, 15 Jan 2003 20:05:06 +0200 # # ... Our customers still include 17% Netscape 4 users, sigh ... # Thanks, Slava - Original Message - From: David Dick [EMAIL PROTECTED] To: Slava Bizyayev [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, June 12, 2003 4:41 PM Subject: Re: How practical is that Practical mod_perl? The direct implementation of the example configuration p.402 is supposed to lead you to about 15% of unsatisfied clients recently. Can we have some more information about what in the implementation leads to the unsatisfied clients?
Re: problem building libapreq on Solaris
On Saturday 14 June 2003 20:54, Ged Haywood wrote: Don't know if there's anyone who actually knows what's going on here but I thought you'd just like to hear from somebody. :) Sure, thank you :-). This is a wild stab in the dark. Guessing that the libapreq installation scripts are assuming that you're building a new Apache/mod_perl, you might in that case be expected to have a copy of the a httpd in the t directory. When you run 'make test' during an Apache build that's where the binary will be, temporarily. You could try a soft link from there to the real httpd - I have no idea if something else will then fail. OK. I will try to install libapreq-1.2 next Monday at work. If it does not work will try the soft link. In any case I'll say something here to let you know how it went. You know that your mod_perl and your Perl should really be compiled with the same compiler? I always think it's best to build it yourself to be sure. Hm... I didn't remember that. I installed perl using its package for Solaris. Maybe I'd better get the tarball to be sure. Thank you! -- fxn -- fxn
