Re: each considered harmful?
> "Marcin" == Marcin Kasperski <[EMAIL PROTECTED]> writes: Marcin> You probably see the problem - when this code is re-executed (next Marcin> request), the loop iterates just over 'the rest' of the hash. This is similar to the problem that shows up when you use glob in a scalar context... it also has lexically-attached state. And now that I think about it, so does the flip-flop scalar dot-dot operator. These are all examples of where it is non-trivial to take a CGI-based script and just "drop it in" as Apache::Registry. There's really nothing A::R can do about it. You must still use your Branes. -- 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: each considered harmful?
> > 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". I found this note before asking, believe me... But it seems to me that this solution is not satisfactory - calling 'keys' or 'values' is inefficient and destroys most gains from iterating over the hash using each... -- ( Marcin Kasperski | Communication takes place between people, documents ) ( http://www.mk.w.pl |are secondary. (Booch) ) () ( Porady dla twórców serwisów WWW: http://www.mk.w.pl/porady/porady_www )
Re: each considered harmful?
On Sun, Jun 15, 2003 at 09:35:38PM +0200, Marcin Kasperski wrote: > > > 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". > > I found this note before asking, believe me... > But it seems to me that this solution is not satisfactory - calling > 'keys' or 'values' is inefficient and destroys most gains from > iterating over the hash using each... Calling keys() (or values()) in void context is quite efficient. Whether or not you appreciate the aesthetics is perhaps quite another matter. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: each considered harmful?
Paul Johnson wrote:
On Sun, Jun 15, 2003 at 09:35:38PM +0200, Marcin Kasperski wrote:
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".
I found this note before asking, believe me...
But it seems to me that this solution is not satisfactory - calling
'keys' or 'values' is inefficient and destroys most gains from
iterating over the hash using each...
Calling keys() (or values()) in void context is quite efficient.
Whether or not you appreciate the aesthetics is perhaps quite another
matter.
I think the point that Marcin is trying to make is that under normal
circumstances (a script is run once) this problem doesn't occur. However under
mod_perl the code persists and therefore doesn't DWIM, till you start thinking
in mod_perl terms and not one-time run script terms.
The problem can be classified into "the global variables usage under mod_perl"
category.
Consider:
#!/usr/bin/perl -T
our %hash;
%hash = map {$_ => 1 } 'a'..'c' unless %hash;
print "Content-type: text/plain\n\n";
for (my ($k, $v) = each %hash) {
print "$k $v\n";
last;
}
that script prints different values on the first 3 invocations and prints
nothing on the 4th, and then repeats the loop. (when you run with httpd -X).
there are 3 hash key/value pairs in that example.
As Paul has suggested you need to reset the iterator as documented for the
operator each(). So adding:
keys %has;
does the trick for the above example.
p.s. I've shown an example, so we can have this issue documented together with
other mod_perl gotchas. It's interesting that I don't remember this issue
being reported earlier.
__
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: problem building libapreq on Solaris
Ged Haywood wrote: 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. :) Apache::test works by creating a symlink from the real location of the httpd binary to t/httpd. For some reason the symlink wasn't created, hence the error. Apache::Test (notice the case difference) doesn't create this link and works directly with the real executable. You could try a soft link from there to the real httpd - I have no idea if something else will then fail. Right on. __ 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
Batara Kesuma wrote:
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 . "\n";
}
It gave me this error:
Subroutine increase_count redefined at /var/www/perl/test.pl line 12.
What is the problem?
You must have changed the script, Registry.pm has recompiled it, which has
redefined the subroutine, and you've received the appropriate warning. If you
don't wish this to happen, you can say:
no warnings 'redefine';
at the top of your script.
Normally I start my code with:
use strict;
use warnings;
no warnings 'redefine'; # to be remove in production
__
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
ANNOUNCE: Gestinanna::POF 0.02
Gestinanna::POF is a collection of modules providing an abstract
persistant object framework intended for use by the Gestinanna
application framework though it may be used outside of that framework.
Gestinanna::POF currently supports Alzabo, MLDBM, LDAP (limited
testing), and aggregations of objects. Security is supported on an
attribute basis instead of object basis, providing finer granularity
than most other persistant object frameworks. A rudimentary, abstract
locking protocol is supported. Transaction support is still in
development.
Gestinanna::POF tries to stress security over performance, so it may
not perform as well as other frameworks. If you do not need attribute-
level security, you will probably want to look at one of the more
mature frameworks available on CPAN.
-
This version adds basic search functionality, e.g.:
$cursor = $factory -> find( user => (
where => [ balance_due => qw(> 10) ]
) );
while($id = $cursor -> next_id) { ... }
The balance_due could be in an LDAP directory (though the LDAP code
is still severely alpha quality), an MLDBM file, or an RDBMS table,
or any combination of them.
A new security attribute is used to manage searching ability: `search'.
This version also fixes this module's author's misunderstanding/misreading
of the Alzabo documentation (I hope).
-
Gestinanna-POF-0.02.tar.gz
has entered CPAN as
file: $CPAN/authors/id/J/JS/JSMITH/Gestinanna-POF-0.02.tar.gz
size: 35610 bytes
md5: 1223ccb17ee1a7b4e77989a876066d12
--
James Smith <[EMAIL PROTECTED]>, 979-862-3725
Senior Software Applications Developer,
Texas A&M CIS Operating Systems Group, Unix
mod_perl on Solaris notes..
Long time lurker (2 years on list I think), first time poster.. I dealt with mod_perl on Solaris during the creation of the Chicago Police Department's mug shot database (running on twin E6800's / Oracle 9i). I was the primary author of this beast, and getting mod_perl to play nicely with everything else that was running on the box wasn't easy.. The copy of perl that comes default with Solaris is compiled with their Forte C compiler. It of course costs money, and is used by many other parts of the system. One of my sun engineers disagreed with me to uninstall all traces of this rogue copy of perl and instead forced me to work with to complete installations on one system at the same time.. Ugh. Forte is incapable of building libapreq as far as I am concerned, later versions that I did get to build weren't terribly stable (trying it right now on my old dev box shows a few tests still fail).. Besides, do you really want to pay for their compiler? It all of course can be done. Instead of getting a gcc compiled package of Perl from somewhere like sunfreeware.com, I decided it would be best to build everything from scratch. I went with Sun's package of GCC, and from there compiled Perl using the SRPM from Redhat as notes on how to build a stable instance of Perl. The main things to be concerned about with Solaris is the overall system configuration (at least, it was for me, processor affinity, shared memory, heck, we even tinkered with process priority [TS:ts_maxupri and TS:ts_maxkmdpri]...) DBD::Oracle seemed a little tricky for us at first (strange lag times, but I think veritas was getting in the way), we had a few issues early on with Apache::DBI, but once we got the "on startup" connection issues worked out things ended up being ridiculously stable (they haven't rebooted since last February I'm told).. Make sure you have the latest Oracle (or any DB for that matter) client libraries before you even download the DBD source.. (sorry, that may seem infantile to mention, but we lost a week due to an older build being loaded once..) To assist my cohorts on future builds (heh, a police joke, sorry), I wrote a simple korn shell script that would go out and install all of this stuff for them. I should probably release this, as it's fairly useful for people interested in getting mod_perl up and walking with Solaris.. Thankfully, we now have a book like "Practical mod_perl" to guide us through some of the insanity of building and installing mod_perl. Thanks Mr. Bekman. (I'm a big fan of mod_perl cookbook as well, if anyone is looking for other good reading material).. In the end, do not trust Sun to package anything related to free software correctly. Most of the time it is not build for an enterprise environment, or just has really weird default path's compiled into the binary. To anyone who thinks the compiler does not matter between apache, perl, mod_perl, or ANY of the modules used by the result, they are mistaken. Symbol tables won't match, untraceable core dumps will occur at random, with incomprehensible errors. Thank the guys at Red Hat for putting the time to build decent SRPM's, so you can just copy off of their hard work ;-) .. (hmm, at the time I think I still had a copy of their internal "apache-heavy" SRPM that used as a reference, thanks Paul and Tom!) -Ryan Dietrich intelligent software solutions www.iswsolutions.com
Re: mod_perl on Solaris notes..
Ryan Dietrich wrote: Long time lurker (2 years on list I think), first time poster.. I dealt with mod_perl on Solaris during the creation of the Chicago Police Department's mug shot database (running on twin E6800's / Oracle 9i). I was the primary author of this beast, and getting mod_perl to play nicely with everything else that was running on the box wasn't easy.. The copy of perl that comes default with Solaris is compiled with their Forte C compiler. It of course costs money, and is used by many other parts of the system. One of my sun engineers disagreed with me to uninstall all traces of this rogue copy of perl and instead forced me to work with to complete installations on one system at the same time.. Ugh. Forte is incapable of building libapreq as far as I am concerned, later versions that I did get to build weren't terribly stable (trying it right now on my old dev box shows a few tests still fail).. Besides, do you really want to pay for their compiler? It all of course can be done. Instead of getting a gcc compiled package of Perl from somewhere like sunfreeware.com, I decided it would be best to build everything from scratch. I went with Sun's package of GCC, and from there compiled Perl using the SRPM from Redhat as notes on how to build a stable instance of Perl. The main things to be concerned about with Solaris is the overall system configuration (at least, it was for me, processor affinity, shared memory, heck, we even tinkered with process priority [TS:ts_maxupri and TS:ts_maxkmdpri]...) DBD::Oracle seemed a little tricky for us at first (strange lag times, but I think veritas was getting in the way), we had a few issues early on with Apache::DBI, but once we got the "on startup" connection issues worked out things ended up being ridiculously stable (they haven't rebooted since last February I'm told).. Make sure you have the latest Oracle (or any DB for that matter) client libraries before you even download the DBD source.. (sorry, that may seem infantile to mention, but we lost a week due to an older build being loaded once..) To assist my cohorts on future builds (heh, a police joke, sorry), I wrote a simple korn shell script that would go out and install all of this stuff for them. I should probably release this, as it's fairly useful for people interested in getting mod_perl up and walking with Solaris.. Thankfully, we now have a book like "Practical mod_perl" to guide us through some of the insanity of building and installing mod_perl. Thanks Mr. Bekman. (I'm a big fan of mod_perl cookbook as well, if anyone is looking for other good reading material).. In the end, do not trust Sun to package anything related to free software correctly. Most of the time it is not build for an enterprise environment, or just has really weird default path's compiled into the binary. To anyone who thinks the compiler does not matter between apache, perl, mod_perl, or ANY of the modules used by the result, they are mistaken. Symbol tables won't match, untraceable core dumps will occur at random, with incomprehensible errors. Thank the guys at Red Hat for putting the time to build decent SRPM's, so you can just copy off of their hard work ;-) .. (hmm, at the time I think I still had a copy of their internal "apache-heavy" SRPM that used as a reference, thanks Paul and Tom!) Thanks for the notes, Ryan. If you can write a Solaris-specific section for http://perl.apache.org/docs/1.0/guide/install.html, it'd make a great addition to our ever-growing knowledge base. You can download the source file (in pod), by clicking on the [src] icon on that page. __ 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
