[28916] in Perl-Users-Digest
Perl-Users Digest, Issue: 160 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Feb 21 18:09:58 2007
Date: Wed, 21 Feb 2007 15:09:20 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Wed, 21 Feb 2007 Volume: 11 Number: 160
Today's topics:
Re: fork()-ing questions <jurgenex@hotmail.com>
Re: fork()-ing questions <ddunham@redwood.taos.com>
Re: fork()-ing questions <dale.schmitz@offutt.af.mil>
Re: fork()-ing questions <jurgenex@hotmail.com>
Re: fork()-ing questions <jgibson@mail.arc.nasa.gov>
Re: fork()-ing questions <ddunham@redwood.taos.com>
new method to test Perl code dnikolayev@gmail.com
Re: new method to test Perl code <uri@stemsystems.com>
Re: new method to test Perl code dnikolayev@gmail.com
Re: Subclassing CGI::Pretty dies instantly in ->new , b <jeremy@chaos.org.uk>
Re: Subclassing CGI::Pretty dies instantly in ->new , b <uri@stemsystems.com>
Re: Subclassing CGI::Pretty dies instantly in ->new , b <1usa@llenroc.ude.invalid>
Re: Subclassing CGI::Pretty dies instantly in ->new , b <jeremy@chaos.org.uk>
Re: Subclassing CGI::Pretty dies instantly in ->new , b anno4000@radom.zrz.tu-berlin.de
Unable to install Math::BigInt::GMP on Solaris 10 sumitbee@gmail.com
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 21 Feb 2007 21:19:38 GMT
From: "Jürgen Exner" <jurgenex@hotmail.com>
Subject: Re: fork()-ing questions
Message-Id: <KH2Dh.4078$_O1.587@trndny04>
Monty wrote:
> Secondly, I see a code snippet out there that confuses me and I'd just
> like clarification of what it's saying. The following line:
>
> unless ($pid = fork()) {
> # Do something as the child process
> }
>
> 'unless' is, as I understand it, used to loop when a condition is
> false. False, in Perl, is the value 0 (along with undef and the empty
> string). What is this the result of this fork()
Depends. In the parent process it is the PID of the child and guaranteed to
be be different from 0. In the child process it is 0.
> and it's effect on
> the 'unless' statement?
Because only for the child process the condition ever evaluates to false the
body is only executed for the child process.
> If the fork() produces a child process, then
> doesn't the result of the entire '$pid = fork()' statement produce a
> true value, as in the call to fork() executed correctly?
But that is not what fork() returns. Did you check the documentation of
fork().
jue
------------------------------
Date: Wed, 21 Feb 2007 21:20:48 GMT
From: Darren Dunham <ddunham@redwood.taos.com>
Subject: Re: fork()-ing questions
Message-Id: <QI2Dh.22$BE2.21@newssvr27.news.prodigy.net>
Monty <dale.schmitz@offutt.af.mil> wrote:
>> $ perldoc -f fork
>> fork Does a fork(2) system call to create a new process running the
>> same program at the same point. It returns the child pid to
>> the parent process, 0 to the child process, or "undef" if the
>> fork is unsuccessful.
> My second question is still foggy, and I may not have asked it
> correctly. Considering the statment 'unless ($pid = fork())', if the
> fork is successful, then the entire '$pid = fork()' statement is
> evaluated as true and the loop code gets skipped--which is ok in the
> parent process. Then, if the perldoc is to be taken at its word, the
> child process that gets forked only consists of the code following the
> fork() statement, which in this case is the loop code. I see the
> benefit of coding exits in child process code.
Nope. Reread it again. fork() returns 0 to the child process. 0 is
not true. The unless gets the result of the assignment (0) in that case
and executes the conditional code.
That code is not testing for a successful fork (it would need to check
for definedness). Instead it is assuming a successful fork and checking
for parent or child.
--
Darren Dunham ddunham@taos.com
Senior Technical Consultant TAOS http://www.taos.com/
Got some Dr Pepper? San Francisco, CA bay area
< This line left intentionally blank to confuse you. >
------------------------------
Date: 21 Feb 2007 13:30:27 -0800
From: "Monty" <dale.schmitz@offutt.af.mil>
Subject: Re: fork()-ing questions
Message-Id: <1172093424.575039.128370@j27g2000cwj.googlegroups.com>
On Feb 21, 3:00 pm, Jim Gibson <jgib...@mail.arc.nasa.gov> wrote:
> In article <1172090025.578027.306...@j27g2000cwj.googlegroups.com>,
>
> Monty <dale.schm...@offutt.af.mil> wrote:
>
> [program using fork snipped]
>
> > My second question is still foggy, and I may not have asked it
> > correctly. Considering the statment 'unless ($pid = fork())', if the
> > fork is successful, then the entire '$pid = fork()' statement is
> > evaluated as true and the loop code gets skipped--which is ok in the
> > parent process. Then, if the perldoc is to be taken at its word, the
> > child process that gets forked only consists of the code following the
> > fork() statement, which in this case is the loop code. I see the
> > benefit of coding exits in child process code.
>
> > How am I doing so far?
>
> You seem not to grasp that the call to fork(), if successful, will
> return two values: one to the parent and one the child. The parent
> value will be non-zero and therefore true, but the child's value will
> be zero and false. Therefore, the code in the unless block will be only
> executed by the child. Also, "unless" does not start a loop (you may be
> thinking of "until"). It is a one-time conditional, equivalent to "if
> not".
>
> The "child code" consists of everything inside the "unless" block, plus
> everything that follows that block unless and until the child executes
> an exit. The "child code" is the _same_ as the "parent code". It is up
> to your program to make each of them behave in an appropriate manner,
> using the return value from fork() to distinguish between them.
>
> Posted Via Usenet.com Premium Usenet Newsgroup Services
> ----------------------------------------------------------
> ** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
> ----------------------------------------------------------
> http://www.usenet.com
Believe it or not, I think I'm getting this. Thanks for to all for 1)
correcting me on understanding of 'unless'...it is not a loop
(somehow, I knew that, but I kept seeing a loop structure for some
reason), and 2) pointing me to perldoc (I've got those priorities
backwards, but I hope you get the drift).
I don't mean to belabor the point, but allow me to interpret that
whole 'unless' structure, one last time.
unless ($pid = fork()) {
# Child process code here
exit(0);
}
# Parent process code here
fork() spawns a new process consisting of code following the 'unless'
statement. The $pid variable gets populated with the child PID for
the parent version of $pid and populated with 0 for the child
(spawned) version of $pid (I thought I read that variables get copied
in a forked process). Since the fork was successful (assume success,
failure is a whole different matter), the statement '$pid = fork'
returns a non-zero value and is evaluated by the 'unless' statement as
true and does not execute the child process code. Terrific, that's
what was wanted. The child process executes the snippet of code
follwing the 'unless' statement until it hits the exit() statement. I
presume the child process attempts to return a value to the parent
process, but that's a matter better left for another conversation.
Without too much attention to detail, am I getting it?
------------------------------
Date: Wed, 21 Feb 2007 21:42:57 GMT
From: "Jürgen Exner" <jurgenex@hotmail.com>
Subject: Re: fork()-ing questions
Message-Id: <B13Dh.19628$2w.10821@trndny09>
Monty wrote:
> unless ($pid = fork()) {
> # Child process code here
> exit(0);
> }
> # Parent process code here
>
> fork() spawns a new process consisting of code following the 'unless'
> statement.
No. The spawned process consists of exactly the same code as the parent
process.
> The $pid variable gets populated with the child PID for
> the parent version of $pid and populated with 0 for the child
> (spawned) version of $pid
Correct.
> (I thought I read that variables get copied
> in a forked process).
That is correct, too. However, those variables in the parent and child
process are totally independant of each other once the fork() is done. And
only at that moment does $pid is being assigned a value and this value
happens to be different for parent and child.
> Since the fork was successful (assume success,
> failure is a whole different matter), the statement '$pid = fork'
> returns a non-zero value
Correct for the parent, wrong for the child
> and is evaluated by the 'unless' statement as
> true and does not execute the child process code. Terrific, that's
> what was wanted. The child process executes the snippet of code
> follwing the 'unless' statement until it hits the exit() statement. I
Correct.
> presume the child process attempts to return a value to the parent
> process, but that's a matter better left for another conversation.
???
jue
------------------------------
Date: Wed, 21 Feb 2007 14:25:19 -0800
From: Jim Gibson <jgibson@mail.arc.nasa.gov>
Subject: Re: fork()-ing questions
Message-Id: <210220071425190770%jgibson@mail.arc.nasa.gov>
In article <1172093424.575039.128370@j27g2000cwj.googlegroups.com>,
Monty <dale.schmitz@offutt.af.mil> wrote:
> Believe it or not, I think I'm getting this. Thanks for to all for 1)
> correcting me on understanding of 'unless'...it is not a loop
> (somehow, I knew that, but I kept seeing a loop structure for some
> reason), and 2) pointing me to perldoc (I've got those priorities
> backwards, but I hope you get the drift).
>
> I don't mean to belabor the point, but allow me to interpret that
> whole 'unless' structure, one last time.
>
> unless ($pid = fork()) {
> # Child process code here
> exit(0);
> }
I suggest that since you are still having trouble grasping the cloning
process initiated by fork, you are better off coding the above as
follows (untested):
my $ret = fork();
print "In process $$, fork has returned $ret\n";
if( $ret ) {
print "parent process has spawned child process $ret\n";
my $pid = waitpid($ret);
print "child $pid has terminated with status $?\n";
}elsif( defined $ret ) {
print "child processing now executing as process PID $$\n";
# child processing goes here
exit(0);
}else{
die("fork failed: $!");
}
And the child doesn't return a value to the parent, but the exit status
of the child, normally zero, is captured by the system and may be
fetched by the parent as above. See 'perldoc -f waitpid' for details.
Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------
** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------
http://www.usenet.com
------------------------------
Date: Wed, 21 Feb 2007 22:39:52 GMT
From: Darren Dunham <ddunham@redwood.taos.com>
Subject: Re: fork()-ing questions
Message-Id: <YS3Dh.71$m85.28@newssvr29.news.prodigy.net>
Monty <dale.schmitz@offutt.af.mil> wrote:
> I don't mean to belabor the point, but allow me to interpret that
> whole 'unless' structure, one last time.
> unless ($pid = fork()) {
> # Child process code here
> exit(0);
> }
> # Parent process code here
> fork() spawns a new process consisting of code following the 'unless'
> statement.
I wouldn't say that. It spawns a new process that is identical (except
for the return of the fork call). So all code is duplicated, not just
the unless.
> The $pid variable gets populated with the child PID for
> the parent version of $pid and populated with 0 for the child
> (spawned) version of $pid (I thought I read that variables get copied
> in a forked process).
Variables are copied. Prior to the fork, the $pid wasn't assigned, so
it would have been 'undef'. So it is 'undef' in both (in some sense)
when the OS makes the copy. However immediately after the copy starts
running, it assigns the value of the fork() call to $pid.
So it is copied, but immediately overwritten afterward.
> Since the fork was successful (assume success,
> failure is a whole different matter), the statement '$pid = fork'
> returns a non-zero value and is evaluated by the 'unless' statement as
> true and does not execute the child process code.
$pid=fork returns a non-zero value if fork returns a non-zero value,
which is true in the parent only. This causes the parent to not execute
the code within the unless block. The child will execute the code in
the unless block.
While I do use unless in many situations in my code, it might be clearer
for you use additional statements and 'if' instead.
$pid = fork();
if ($pid == 0) {
# Child process code here
[...]
That might be clearer when you're trying to remember what fork returns
and reverse the sense of the if because it's an unless...
> Terrific, that's
> what was wanted. The child process executes the snippet of code
> follwing the 'unless' statement until it hits the exit() statement. I
Right.
> presume the child process attempts to return a value to the parent
> process, but that's a matter better left for another conversation.
The child doesn't attempt to do anything that's not in code.
However, I suggest you examine the 'wait' function if you're interested
in simple messages from the child to the parent.
> Without too much attention to detail, am I getting it?
Unfortunately, the computer is all about detail. :-)
--
Darren Dunham ddunham@taos.com
Senior Technical Consultant TAOS http://www.taos.com/
Got some Dr Pepper? San Francisco, CA bay area
< This line left intentionally blank to confuse you. >
------------------------------
Date: 21 Feb 2007 14:02:21 -0800
From: dnikolayev@gmail.com
Subject: new method to test Perl code
Message-Id: <1172095341.707191.237040@h3g2000cwc.googlegroups.com>
Here is the method to test perl program when you have no machine with
perl: http://www.codeide.com
You can do this in IDE mode in the site or run in CGI mode on your own
home page like here: http://nick.codeide.com/hello.cgi?name=Visitor
------------------------------
Date: Wed, 21 Feb 2007 17:21:05 -0500
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: new method to test Perl code
Message-Id: <x7r6sjkv8u.fsf@mail.sysarch.com>
>>>>> "d" == dnikolayev <dnikolayev@gmail.com> writes:
d> Here is the method to test perl program when you have no machine with
d> perl: http://www.codeide.com
d> You can do this in IDE mode in the site or run in CGI mode on your own
d> home page like here: http://nick.codeide.com/hello.cgi?name=Visitor
why would you want to test perl code on a machine without perl? and do
you trust people to run any perl code on that box? i wouldn't go near
your box under any circumstances nor would i recommend anyone do so. it
isn't safe for your or their code.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
------------------------------
Date: 21 Feb 2007 14:58:31 -0800
From: dnikolayev@gmail.com
Subject: Re: new method to test Perl code
Message-Id: <1172098711.092992.101230@v45g2000cwv.googlegroups.com>
On Feb 22, 12:21 am, Uri Guttman <u...@stemsystems.com> wrote:
> >>>>> "d" == dnikolayev <dnikola...@gmail.com> writes:
>
> d> Here is the method to test perl program when you have no machine with
> d> perl:http://www.codeide.com
> d> You can do this in IDE mode in the site or run in CGI mode on your own
> d> home page like here:http://nick.codeide.com/hello.cgi?name=Visitor
>
> why would you want to test perl code on a machine without perl? and do
> you trust people to run any perl code on that box? i wouldn't go near
> your box under any circumstances nor would i recommend anyone do so. it
> isn't safe for your or their code.
>
> uri
>
> --
> Uri Guttman ------ u...@stemsystems.com --------http://www.stemsystems.com
> --Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
> Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
Just to test some regexp or something, for instance..
Some regexp or so on..
Show other one some abilities of perl,.. learn language, give your
children ability to test, etc..
There is a lof of reasons to use..
Of course big applications wil not work as needed.. This resource is
for testing, learning and so on.
------------------------------
Date: Wed, 21 Feb 2007 15:46:58 -0600
From: Jeremy Henty <jeremy@chaos.org.uk>
Subject: Re: Subclassing CGI::Pretty dies instantly in ->new , bug?
Message-Id: <slrnetpfd8.4er.jeremy@omphalos.onepoint>
On 2007-02-21, Uri Guttman <uri@stemsystems.com> wrote:
>>>>>> "JH" == Jeremy Henty <jeremy@chaos.org.uk> writes:
> JH> I'm following up to myself to explain further: the reason why
> JH> this is so surprising is that CGI::Pretty is just a subclass
> JH> of CGI that modifies a few methods to produce nicer HTML output.
> JH> If I rewrite my CGI script to use CGI::Pretty directly then it
> JH> works.
>
> well, for one thing since you don't seem to do anything special in
> Jeremy::CGI why do you need that module?
I wanted to inherit from CGI::Pretty to refactor some code and when I
did so it promptly broke. I'm giving you a stripped-down example to
spare you the irrelevant details. (That's good practice, right?)
> ... try using the use base idea i mentioned. it does exactly what
> you want and it means only one place needs to be changed from CGI to
> CGI::Pretty. maybe that will fix it or help isolate the problem.
It did not fix it (though I appreciate you telling me about it)! Here
are the *exact* files I am now using (modulo indentation for clarity)
The CGI script:
#!/usr/bin/perl
use strict;
use warnings;
use lib qw( /home/jeremy/Personal/Geeky/Perl/Lib );
use Jeremy::CGI;
my $query = Jeremy::CGI->new;
print
$query->header,
$query->start_html("Hi!"),
$query->p("boink"),
$query->ul($query->li("foo"),
$query->li("bar"),);
$query->end_html,
;
Jeremy/CGI.pm :
use strict;
use warnings;
package Jeremy::CGI;
use base 'CGI::Pretty';
1; # success
And the result is:
Undefined subroutine Jeremy::CGI::delete
at /data/www-jeremy/cgi-bin/cgi-jeremy line 9
If I replace "my $query = Jeremy::CGI->new;" with "my $query =
CGI::Pretty->new;", it works. If I replace "use base 'CGI::Pretty';"
with "use base 'CGI';", it works. But as it stands, it's broken. It
seems clear that subclassing CGI::Pretty just doesn't work.
> ... to make your life easier for testing you can run this directly
> and not under a web server.
I am running it directly. (Believe me, I do read the docs and I am
trying not to waste your time or mine.)
> ... if you think (and can prove) this is a real error in CGI::Pretty
> then you should report it to the author
I was hoping someone could tell me whether subclassing CGI::Pretty was
supported before I hassled the author.
> ... (but not until you can show serious evidence on your side).
I've given you the exact files and output, and a quote from "perldoc
perltoot" that says a properly written module should not do this. If
that's not serious evidence I don't know what is!
Regards,
Jeremy Henty
------------------------------
Date: Wed, 21 Feb 2007 17:10:12 -0500
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: Subclassing CGI::Pretty dies instantly in ->new , bug?
Message-Id: <x7zm77kvqz.fsf@mail.sysarch.com>
>>>>> "JH" == Jeremy Henty <jeremy@chaos.org.uk> writes:
JH> On 2007-02-21, Uri Guttman <uri@stemsystems.com> wrote:
JH> The CGI script:
JH> use lib qw( /home/jeremy/Personal/Geeky/Perl/Lib );
JH> use Jeremy::CGI;
JH> my $query = Jeremy::CGI->new;
JH> Jeremy/CGI.pm :
JH> use strict;
JH> use warnings;
JH> package Jeremy::CGI;
JH> use base 'CGI::Pretty';
JH> And the result is:
JH> Undefined subroutine Jeremy::CGI::delete
JH> at /data/www-jeremy/cgi-bin/cgi-jeremy line 9
JH> If I replace "my $query = Jeremy::CGI->new;" with "my $query =
JH> CGI::Pretty->new;", it works. If I replace "use base 'CGI::Pretty';"
JH> with "use base 'CGI';", it works. But as it stands, it's broken. It
JH> seems clear that subclassing CGI::Pretty just doesn't work.
i would call that pretty good evidence. not much you can do but write
the author and send him all of this.
JH> I was hoping someone could tell me whether subclassing CGI::Pretty was
JH> supported before I hassled the author.
well, no one seems to have tried it before you did (i don't use ::Pretty
and don't do much CGI in general).
>> ... (but not until you can show serious evidence on your side).
JH> I've given you the exact files and output, and a quote from "perldoc
JH> perltoot" that says a properly written module should not do this. If
JH> that's not serious evidence I don't know what is!
like i said, now you have to write to lincoln stein and show him
this. if you were to even find the fix (something in CGI::Pretty) he
would likely update it quickly. he is know for reasonable response
times. also you can try reporting the bug with rt.cpan.org which may be
more effective. he should get all bug reports from that on his modules.
as i said, i looked at the CGI::Pretty code and couldn't see anything
obvious as to why it wouldn't work. there is one possible issue i can
think of. CGI is noted for doing dynamic loading of many of its
functions/methods and it does its own wierd way. maybe GGI::Pretty is
doing something that needs to be done in your module too to force
loading of the delete method? i see this line in CGI::Pretty and maybe
it will be a clue for you.
$CGI::Pretty::AutoloadClass = 'CGI';
also look into calling SUPER::new() instead of new() in your
module. CGI::Pretty does that and it might also help. calling SUPER:: is
common when inheriting constructors.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
------------------------------
Date: Wed, 21 Feb 2007 22:46:52 GMT
From: "A. Sinan Unur" <1usa@llenroc.ude.invalid>
Subject: Re: Subclassing CGI::Pretty dies instantly in ->new , bug?
Message-Id: <Xns98DEB4E5FE3B6asu1cornelledu@127.0.0.1>
Jeremy Henty <jeremy@chaos.org.uk> wrote in
news:slrnetpfd8.4er.jeremy@omphalos.onepoint:
> On 2007-02-21, Uri Guttman <uri@stemsystems.com> wrote:
>>>>>>> "JH" == Jeremy Henty <jeremy@chaos.org.uk> writes:
>
>> JH> I'm following up to myself to explain further: the reason why
>> JH> this is so surprising is that CGI::Pretty is just a subclass
>> JH> of CGI that modifies a few methods to produce nicer HTML output.
>> JH> If I rewrite my CGI script to use CGI::Pretty directly then it
>> JH> works.
>>
>> well, for one thing since you don't seem to do anything special in
>> Jeremy::CGI why do you need that module?
>
> I wanted to inherit from CGI::Pretty to refactor some code and when I
> did so it promptly broke. I'm giving you a stripped-down example to
> spare you the irrelevant details. (That's good practice, right?)
>
...
> And the result is:
>
> Undefined subroutine Jeremy::CGI::delete
> at /data/www-jeremy/cgi-bin/cgi-jeremy line 9
I can replicate this and it should not happen.
However. CGI did not start life as a purely OO module and there is a lot
of stuff in there that can go wrong. Upon looking at the source code for
CGI::Pretty, a couple of variables jumped out at me. One of them held
the key to a solution:
The following works:
package T::Pretty;
use base 'CGI::Pretty';
$T::Pretty::AutoloadClass = 'CGI';
1;
#!/usr/bin/perl
use lib '.';
use T::Pretty;
my $t = T::Pretty->new;
print $t->header;
__END__
D:\Dload\test> t
Content-Type: text/html; charset=ISO-8859-1
HTH,
Sinan
--
A. Sinan Unur <1usa@llenroc.ude.invalid>
(remove .invalid and reverse each component for email address)
comp.lang.perl.misc guidelines on the WWW:
http://augustmail.com/~tadmc/clpmisc/clpmisc_guidelines.html
------------------------------
Date: Wed, 21 Feb 2007 16:52:57 -0600
From: Jeremy Henty <jeremy@chaos.org.uk>
Subject: Re: Subclassing CGI::Pretty dies instantly in ->new , bug?
Message-Id: <slrnetpj7l.2cq.jeremy@omphalos.onepoint>
> ... you can try reporting the bug with rt.cpan.org which may be more
> effective.
I will. Thanks for the pointer.
> I see this line in CGI::Pretty and maybe it will be a clue for you.
>
> $CGI::Pretty::AutoloadClass = 'CGI';
>
> also look into calling SUPER::new() instead of new() in your
> module. CGI::Pretty does that and it might also help. calling
> SUPER:: is common when inheriting constructors.
I did actually try copying stuff from the CGI::Pretty constructor into
mine but nothing I tried worked. Eventually I decided to stop
tinkering and ask for help. Maybe the author can tell me the right
combination of magic.
Thanks again for your comments,
Jeremy Henty
------------------------------
Date: 21 Feb 2007 22:57:41 GMT
From: anno4000@radom.zrz.tu-berlin.de
Subject: Re: Subclassing CGI::Pretty dies instantly in ->new , bug?
Message-Id: <544135F1utgflU1@mid.dfncis.de>
Uri Guttman <uri@stemsystems.com> wrote in comp.lang.perl.misc:
> >>>>> "JH" == Jeremy Henty <jeremy@chaos.org.uk> writes:
>
> JH> On 2007-02-21, Uri Guttman <uri@stemsystems.com> wrote:
>
> JH> The CGI script:
>
> JH> use lib qw( /home/jeremy/Personal/Geeky/Perl/Lib );
> JH> use Jeremy::CGI;
>
> JH> my $query = Jeremy::CGI->new;
>
> JH> Jeremy/CGI.pm :
>
> JH> use strict;
> JH> use warnings;
>
> JH> package Jeremy::CGI;
> JH> use base 'CGI::Pretty';
>
> JH> And the result is:
>
> JH> Undefined subroutine Jeremy::CGI::delete
> JH> at /data/www-jeremy/cgi-bin/cgi-jeremy line 9
>
> JH> If I replace "my $query = Jeremy::CGI->new;" with "my $query =
> JH> CGI::Pretty->new;", it works. If I replace "use base 'CGI::Pretty';"
> JH> with "use base 'CGI';", it works. But as it stands, it's broken. It
> JH> seems clear that subclassing CGI::Pretty just doesn't work.
>
> i would call that pretty good evidence. not much you can do but write
> the author and send him all of this.
>
> JH> I was hoping someone could tell me whether subclassing CGI::Pretty was
> JH> supported before I hassled the author.
>
> well, no one seems to have tried it before you did (i don't use ::Pretty
> and don't do much CGI in general).
>
> >> ... (but not until you can show serious evidence on your side).
>
> JH> I've given you the exact files and output, and a quote from "perldoc
> JH> perltoot" that says a properly written module should not do this. If
> JH> that's not serious evidence I don't know what is!
>
> like i said, now you have to write to lincoln stein and show him
> this. if you were to even find the fix (something in CGI::Pretty) he
> would likely update it quickly. he is know for reasonable response
> times. also you can try reporting the bug with rt.cpan.org which may be
> more effective. he should get all bug reports from that on his modules.
>
> as i said, i looked at the CGI::Pretty code and couldn't see anything
> obvious as to why it wouldn't work. there is one possible issue i can
> think of. CGI is noted for doing dynamic loading of many of its
> functions/methods and it does its own wierd way. maybe GGI::Pretty is
> doing something that needs to be done in your module too to force
> loading of the delete method? i see this line in CGI::Pretty and maybe
> it will be a clue for you.
Your hunch is right about helping a class along to load its methods.
This is a workaround: In .../Jeremy/CLI.pm do
package Jeremy::CGI;
use base 'CGI::Pretty';
CGI::Pretty->can( $_) for qw( delete header cache);
1; # success
The ->can query has the effect that later calls to the methods
actually succeed. I don't know what exactly happens, just
noticed the effect while looking into this.
> $CGI::Pretty::AutoloadClass = 'CGI';
> also look into calling SUPER::new() instead of new() in your
> module. CGI::Pretty does that and it might also help. calling SUPER:: is
> common when inheriting constructors.
No, it's common when you override the constructor with your own. If
you inherit the constructor, there's no need (and no way) to use
SUPER::.
Anno
------------------------------
Date: 21 Feb 2007 15:03:55 -0800
From: sumitbee@gmail.com
Subject: Unable to install Math::BigInt::GMP on Solaris 10
Message-Id: <1172099035.415391.12700@p10g2000cwp.googlegroups.com>
Hello Guru's:
Make fails on both version 1.18 and 1.19. I am trying to install this
to speed up Net::SSH::Perl, since that is unbearably slow with the
pure perl libraries, or even Math::BigInt::Pari, or
Math::BigInt::FastCalc. here is what I get when I run make:
--------------------------------------------------------------------------------------------------------------------
bash-3.00# perl Makefile.PL
Note (probably harmless): No library found for -lgmp
YAML not installed, make dist will not override metafile at
Makefile.PL line 8.
Writing Makefile for Math::BigInt::GMP
bash-3.00# make
cp lib/Math/BigInt/GMP.pm blib/lib/Math/BigInt/GMP.pm
/usr/bin/perl /usr/perl5/5.8.4/lib/ExtUtils/xsubpp -typemap /usr/
perl5/5.8.4/lib/ExtUtils/typemap -typemap typemap GMP.xs > GMP.xsc &&
mv GMP.xsc GMP.c
cc -c -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -xarch=v8 -
D_TS_ERRNO -xO3 -xspace -xildoff -DVERSION=\"1.19\" -DXS_VERSION=
\"1.19\" -KPIC "-I/usr/perl5/5.8.4/lib/sun4-solaris-64int/CORE"
GMP.c
"GMP.xs", line 4: cannot find include file: "gmp.h"
"GMP.c", line 40: undefined symbol: mpz_t
"GMP.c", line 40: undefined symbol: RETVAL
"GMP.xs", line 34: warning: improper pointer/integer combination: op
"="
"GMP.xs", line 35: warning: implicit function declaration:
mpz_init_set_str
"GMP.xs", line 35: cannot dereference non-pointer type
"GMP.c", line 59: undefined symbol: mpz_t
"GMP.c", line 59: undefined symbol: RETVAL
"GMP.xs", line 47: warning: improper pointer/integer combination: op
"="
"GMP.xs", line 48: cannot dereference non-pointer type
"GMP.c", line 78: undefined symbol: mpz_t
"GMP.c", line 78: undefined symbol: RETVAL
"GMP.xs", line 60: warning: improper pointer/integer combination: op
"="
"GMP.xs", line 61: cannot dereference non-pointer type
"GMP.c", line 97: undefined symbol: mpz_t
"GMP.c", line 97: undefined symbol: RETVAL
"GMP.xs", line 73: warning: improper pointer/integer combination: op
"="
"GMP.xs", line 74: cannot dereference non-pointer type
"GMP.c", line 115: undefined symbol: mpz_t
"GMP.c", line 115: undefined symbol: RETVAL
"GMP.xs", line 85: warning: improper pointer/integer combination: op
"="
"GMP.xs", line 86: warning: implicit function declaration:
mpz_init_set_ui
"GMP.xs", line 86: cannot dereference non-pointer type
"GMP.c", line 133: undefined symbol: mpz_t
"GMP.c", line 133: undefined symbol: RETVAL
"GMP.xs", line 97: warning: improper pointer/integer combination: op
"="
"GMP.xs", line 98: cannot dereference non-pointer type
"GMP.c", line 151: undefined symbol: mpz_t
"GMP.c", line 151: undefined symbol: RETVAL
"GMP.xs", line 109: warning: improper pointer/integer combination: op
"="
"GMP.xs", line 110: cannot dereference non-pointer type
"GMP.c", line 169: undefined symbol: mpz_t
"GMP.c", line 169: undefined symbol: RETVAL
"GMP.xs", line 121: warning: improper pointer/integer combination: op
"="
"GMP.xs", line 122: cannot dereference non-pointer type
"GMP.c", line 188: undefined symbol: mpz_t
"GMP.c", line 188: undefined symbol: n
"GMP.c", line 192: syntax error before or at: )
"GMP.xs", line 135: warning: implicit function declaration: mpz_clear
"GMP.xs", line 135: cannot dereference non-pointer type
"GMP.xs", line 136: warning: improper pointer/integer combination: arg
#1
"GMP.c", line 212: undefined symbol: mpz_t
"GMP.c", line 212: undefined symbol: n
"GMP.c", line 223: syntax error before or at: )
"GMP.xs", line 151: warning: implicit function declaration:
mpz_sizeinbase
"GMP.xs", line 151: cannot dereference non-pointer type
"GMP.xs", line 156: warning: implicit function declaration:
mpz_get_str
"GMP.xs", line 156: cannot dereference non-pointer type
"GMP.c", line 254: undefined symbol: mpz_t
"GMP.c", line 254: undefined symbol: n
"GMP.c", line 267: syntax error before or at: )
"GMP.xs", line 184: warning: implicit function declaration: mpz_tstbit
"GMP.xs", line 184: cannot dereference non-pointer type
"GMP.xs", line 189: cannot dereference non-pointer type
"GMP.xs", line 194: cannot dereference non-pointer type
"GMP.c", line 316: undefined symbol: mpz_t
"GMP.c", line 316: undefined symbol: n
"GMP.c", line 326: syntax error before or at: )
"GMP.xs", line 230: cannot dereference non-pointer type
"GMP.xs", line 235: cannot dereference non-pointer type
"GMP.c", line 353: undefined symbol: mpz_t
"GMP.c", line 353: undefined symbol: n
"GMP.c", line 363: syntax error before or at: )
"GMP.xs", line 253: cannot dereference non-pointer type
"GMP.xs", line 258: cannot dereference non-pointer type
"GMP.c", line 390: undefined symbol: mpz_t
"GMP.c", line 390: undefined symbol: n
"GMP.c", line 400: syntax error before or at: )
"GMP.xs", line 276: cannot dereference non-pointer type
"GMP.xs", line 281: cannot dereference non-pointer type
"GMP.c", line 427: undefined symbol: mpz_t
"GMP.c", line 427: undefined symbol: n
"GMP.c", line 428: operands must have arithmetic type: op "*"
"GMP.c", line 429: undefined symbol: mod
"GMP.c", line 430: undefined symbol: RETVAL
"GMP.c", line 434: syntax error before or at: )
"GMP.c", line 441: syntax error before or at: )
"GMP.c", line 448: syntax error before or at: )
"GMP.xs", line 296: warning: improper pointer/integer combination: op
"="
"GMP.xs", line 296: warning: implicit function declaration: mpz_init
"GMP.xs", line 296: cannot dereference non-pointer type
"GMP.xs", line 297: warning: implicit function declaration: mpz_powm
"GMP.xs", line 297: cannot dereference non-pointer type
"GMP.xs", line 297: cannot dereference non-pointer type
"GMP.xs", line 297: cannot dereference non-pointer type
"GMP.c", line 460: cannot recover from previous errors
cc: acomp failed for GMP.c
*** Error code 2
make: Fatal error: Command failed for target `GMP.o'
bash-3.00#
--------------------------------------------------------------------------------------------------------------------
Version 1.18 gives similar errors. Any suggestions/advice would be
much appreciated!
Sumit
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 160
**************************************
