[28641] in Perl-Users-Digest
Perl-Users Digest, Issue: 10005 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sat Nov 25 00:05:55 2006
Date: Fri, 24 Nov 2006 21:05:06 -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 Fri, 24 Nov 2006 Volume: 10 Number: 10005
Today's topics:
Re: a short non-working Perl script <dr.mtarver@ukonline.co.uk>
Re: a short non-working Perl script <mritty@gmail.com>
Re: a short non-working Perl script <uri@stemsystems.com>
Re: ANNOUNCE: CGI::ContactForm 1.40 <noreply@gunnar.cc>
Re: ANNOUNCE: CGI::ContactForm 1.40 <noreply@gunnar.cc>
Re: ANNOUNCE: CGI::ContactForm 1.40 (Randal L. Schwartz)
Re: ANNOUNCE: CGI::ContactForm 1.40 <noreply@gunnar.cc>
Re: ANNOUNCE: CGI::ContactForm 1.40 (Randal L. Schwartz)
Re: die on "use of uninitialized value"? <spamtrap@dot-app.org>
Re: Do I *have* to use 'OOP' to use modules? <asandstrom@accesswave.ca>
Re: prevent further hash auto-vivification <tbmoore9@verizon.net>
Re: prevent further hash auto-vivification <DJStunks@gmail.com>
Re: prevent further hash auto-vivification <spamtrap@dot-app.org>
Re: prevent further hash auto-vivification <tbmoore9@verizon.net>
Re: prevent further hash auto-vivification <benmorrow@tiscali.co.uk>
Re: prevent further hash auto-vivification <uri@stemsystems.com>
Re: prevent further hash auto-vivification <uri@stemsystems.com>
Problem to compile Perl 5.8.8 <ar_nospam@free.fr>
Re: Problem to compile Perl 5.8.8 <antispam@randometry.com>
Re: Problem to compile Perl 5.8.8 <spamtrap@dot-app.org>
Re: what is the best choose fork or thread? <nalhawash@yahoo.ca>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 24 Nov 2006 16:09:06 -0800
From: "Mark Tarver" <dr.mtarver@ukonline.co.uk>
Subject: Re: a short non-working Perl script
Message-Id: <1164413346.872061.164050@f16g2000cwb.googlegroups.com>
> > $buffer = read(STDIN, $buffer, $ENV{'CONTENT_LENGTH'});
> Well, this is not what you want. From perldoc -f read:
>From tests I found that if I set the buffer to a fixed string then the
program worked perfectly. Ergo I expect that this was the line that
was fouling it up. What is the code for reading the forms output to
the $buffer - do you know?
Mark
------------------------------
Date: 24 Nov 2006 18:35:35 -0800
From: "Paul Lalli" <mritty@gmail.com>
Subject: Re: a short non-working Perl script
Message-Id: <1164422135.521178.5010@l39g2000cwd.googlegroups.com>
Mark Tarver wrote:
> > > $buffer = read(STDIN, $buffer, $ENV{'CONTENT_LENGTH'});
>
> > Well, this is not what you want. From perldoc -f read:
>
> >From tests I found that if I set the buffer to a fixed string then the
> program worked perfectly. Ergo I expect that this was the line that
> was fouling it up. What is the code for reading the forms output to
> the $buffer - do you know?
Are you *reading* any of these replies? You were given the correct way
to do this by several different people. If you want to continue to
ignore the right way, you were even quoted a part of the documentation
of the read() function that tells you what you did wrong. $buffer is
passed as the second argument to the function, and the function fills
that buffer. It then returns HOW MANY BYTES WERE READ, not the actual
text. Therefore, you're reading, for example, "Hello World", which
Perl is storing into $buffer automatically. But then you immediately
replace that string with the number 11, because you assigned the
$buffer variable to the return value of read(). Stop doing that.
Paul Lalli
------------------------------
Date: Fri, 24 Nov 2006 23:54:34 -0500
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: a short non-working Perl script
Message-Id: <x7bqmw5do5.fsf@mail.sysarch.com>
>>>>> "PL" == Paul Lalli <mritty@gmail.com> writes:
PL> Mark Tarver wrote:
>> > > $buffer = read(STDIN, $buffer, $ENV{'CONTENT_LENGTH'});
>>
>> > Well, this is not what you want. From perldoc -f read:
>>
>> >From tests I found that if I set the buffer to a fixed string then the
>> program worked perfectly. Ergo I expect that this was the line that
>> was fouling it up. What is the code for reading the forms output to
>> the $buffer - do you know?
PL> Are you *reading* any of these replies? You were given the correct way
PL> to do this by several different people. If you want to continue to
PL> ignore the right way, you were even quoted a part of the documentation
PL> of the read() function that tells you what you did wrong. $buffer is
PL> passed as the second argument to the function, and the function fills
PL> that buffer. It then returns HOW MANY BYTES WERE READ, not the actual
PL> text. Therefore, you're reading, for example, "Hello World", which
PL> Perl is storing into $buffer automatically. But then you immediately
PL> replace that string with the number 11, because you assigned the
PL> $buffer variable to the return value of read(). Stop doing that.
and to back this up, the OP's cgi parser is even worse than the classic
matt wright parser which did minimally work even if it was crappy code
with major holes in it.
so to the OP, use cgi.pm or don't code basic cgi scripts in perl. until
you get good enough to graduate to beyond cgi.pm (and use some other
higher level framework) don't stray away from it.
but if you continue to ignore the postings here (as paul stated) you
will lose most of us as we can't help those that won't help themselves.
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: Sat, 25 Nov 2006 03:22:17 +0100
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: ANNOUNCE: CGI::ContactForm 1.40
Message-Id: <4spnmtF10u4v1U1@mid.individual.net>
Ric wrote:
> Gunnar Hjalmarsson schrieb:
>>krakle@visto.com wrote:
>>>Gunnar Hjalmarsson wrote:
>>>>CGI::ContactForm is a module for generating web contact forms. It lets
>>>>you create an unlimited number of forms with a minimum of effort, and
>>>>makes it possible for e.g. web hosting providers to offer their
>>>>customers an easy way to set up a contact form.
>
> Woah, have you seen those powerful form designers for example from 1and1 ?
No, I must admit I haven't.
>>>>Version 1.40 includes a feature that makes automated submissions by spam
>>>>robots more difficult, without the inconvenience of CAPTCHA. Also, since
>>>>some people don't like that a copy is sent to the submitted sender
>>>>address, an option has been added to not send sender copies.
>>>
>>>Gunnar you of all people should know that comp.lang.perl.misc isn't a
>>>place to post announcements for crappy modules that noone will use...
>>
>>So you think it's crappy? Then I look forward to your insightsful code
>>criticism.
>
> Well the first thing I had in mind ->I can tell Contact Form to setup a
> form with certain fields that I name. But after having a quick look at
> the source I saw that this is not possible *LOL*.
You are right. CGI::ContactForm is only for establishing contact, more
or less a replacement for mailto links. There are other modules that are
much more flexible and hence much more complicated to use, e.g.
CGI::FormBuilder.
I tried to not re-invent the wheel, and to my knowledge there is no Perl
module for building forms that beats CGI::ContactForm as regards simplicity.
> This .pm is a great beginners tutorial, but that's it:-)
Tutorial? I don't know about that... Sure, the code is at a beginner
level, what else could you expect from a beginner level programmer? :)
The users I have in mind are those who appreciate the convenience of
CGI::ContactForm, irrespective of their programming skill.
Thanks for your comments, Ric!
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: Sat, 25 Nov 2006 03:22:32 +0100
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: ANNOUNCE: CGI::ContactForm 1.40
Message-Id: <4spnncF10u4v1U2@mid.individual.net>
Michele Dondi wrote:
> On 24 Nov 2006 11:34:11 -0800, krakle@visto.com wrote:
>>Gunnar you of all people should know that comp.lang.perl.misc isn't a
>>place to post announcements for crappy modules that noone will use...
>
> I would amend your claim that clpmisc
> is not a place to post announcements for modules at all, which makes
> some sense because on the one hand that would raise the traffic, and
> OTOH it would raise it too high. It would be better suited to
> occasionally post about some(one's own) module if it were for a RFC or
> if unsure about it, but that's only MHO...
I see your point, Michele. There is a group designated for
announcements, but unfortunately I'm not in a position to use it:
http://groups.google.com/group/comp.lang.perl.misc/msg/9da3b07a1dd62ee3
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: 24 Nov 2006 18:28:28 -0800
From: merlyn@stonehenge.com (Randal L. Schwartz)
Subject: Re: ANNOUNCE: CGI::ContactForm 1.40
Message-Id: <86vel4b6pf.fsf@blue.stonehenge.com>
>>>>> "Gunnar" == Gunnar Hjalmarsson <noreply@gunnar.cc> writes:
Gunnar> I see your point, Michele. There is a group designated for
Gunnar> announcements, but unfortunately I'm not in a position to use it:
Gunnar> http://groups.google.com/group/comp.lang.perl.misc/msg/9da3b07a1dd62ee3
Whine whine. All I ask is that you use an address for a posting that is a
valid email address that actually reaches a human. If you're not willing to
do that, you don't get to use the CLPA group. I have no sympathy for your
position on this.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL: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!
--
Posted via a free Usenet account from http://www.teranews.com
------------------------------
Date: Sat, 25 Nov 2006 04:26:06 +0100
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: ANNOUNCE: CGI::ContactForm 1.40
Message-Id: <4sprejF115650U1@mid.individual.net>
Randal L. Schwartz wrote:
>>>>>>"Gunnar" == Gunnar Hjalmarsson <noreply@gunnar.cc> writes:
> Gunnar> I see your point, Michele. There is a group designated for
> Gunnar> announcements, but unfortunately I'm not in a position to use it:
> Gunnar> http://groups.google.com/group/comp.lang.perl.misc/msg/9da3b07a1dd62ee3
>
> Whine whine. All I ask is that you use an address for a posting that is a
> valid email address that actually reaches a human.
Anybody who reads the (whole) message I linked to can see that that's
not true.
> If you're not willing to do that,
???
> you don't get to use the CLPA group. I have no sympathy for your position
> on this.
The latter is perfectly clear to me.
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: 24 Nov 2006 19:58:37 -0800
From: merlyn@stonehenge.com (Randal L. Schwartz)
Subject: Re: ANNOUNCE: CGI::ContactForm 1.40
Message-Id: <86hcwob2j6.fsf@blue.stonehenge.com>
>>>>> "Gunnar" == Gunnar Hjalmarsson <noreply@gunnar.cc> writes:
Gunnar> Randal L. Schwartz wrote:
>>>>>>> "Gunnar" == Gunnar Hjalmarsson <noreply@gunnar.cc> writes:
Gunnar> I see your point, Michele. There is a group designated for
Gunnar> announcements, but unfortunately I'm not in a position to use it:
Gunnar> http://groups.google.com/group/comp.lang.perl.misc/msg/9da3b07a1dd62ee3
>> Whine whine. All I ask is that you use an address for a posting that is a
>> valid email address that actually reaches a human.
Gunnar> Anybody who reads the (whole) message I linked to can see that that's not true.
What part of it isn't true? I just replied to your address
and got this:
<noreply@gunnar.cc> is not a posting address, so the message "Re: ANNOUNCE:
CGI::ContactForm 1.40" was deleted and not read by anybody.
To contact me, please go to
http://www.gunnar.cc/cgi-bin/contact.pl
The reason for this arrangement is to be spared spam to this publicly
displayed email address. Sorry for the inconvenience.
Gunnar Hjalmarsson
Therefore, there's no *human* at the address you wanted to use, then, or now.
And that's a violation of the CLPA policy.
Don't lie to the public.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL: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!
--
Posted via a free Usenet account from http://www.teranews.com
------------------------------
Date: Fri, 24 Nov 2006 18:54:46 -0500
From: Sherm Pendley <spamtrap@dot-app.org>
Subject: Re: die on "use of uninitialized value"?
Message-Id: <m2ejrs9z95.fsf@Sherm-Pendleys-Computer.local>
Michele Dondi <bik.mido@tiscalinet.it> writes:
> On 24 Nov 2006 11:26:28 -0800, "DJ Stunks" <DJStunks@gmail.com> wrote:
>
>> use warnings FATAL => qw{ uninitialized };
>
> Whoa! I was thinking about writing a die handler myself. I didn't know
> about this semantic. Thank you!!
Kind of odd that it isn't mentioned in 'perldoc warnings', isn't it?
Granted, there's a cross-ref to 'perldoc perllexwarn' in there, but I'd
think it would worth at least a mention in 'perldoc warnings'.
Yah, I know - tell it to p5p, accompanied with a patch. Will do. :-)
sherm--
--
Web Hosting by West Virginians, for West Virginians: http://wv-www.net
Cocoa programming in Perl: http://camelbones.sourceforge.net
------------------------------
Date: Sat, 25 Nov 2006 04:58:26 GMT
From: "Arved Sandstrom" <asandstrom@accesswave.ca>
Subject: Re: Do I *have* to use 'OOP' to use modules?
Message-Id: <S3Q9h.1409$uj6.322@edtnps89>
"Abigail" <abigail@abigail.be> wrote in message
news:slrnem9g0b.c8.abigail@alexandra.abigail.be...
> Arved Sandstrom (asandstrom@accesswave.ca) wrote on MMMMDCCCXXIX
> ,, > I'm just amazed that people call the absence of elementary construct
> ,, > (given that you've decided to support OO in the language) a
> *feature*.
> ,, > I've never heard anyone advocate Java or C for their lack of native
> ,, > support for regular expressions or hashes, but people keep
> considering
> ,, > the lack of support for object attributes as the best thing since
> sliced
> ,, > bread.
> ,,
> ,, I don't think Perl is that bad. I fall very strongly on the side of
> those
> ,, who say that it's a knowledgeable programmer who should follow a
> contract,
> ,, not the language that imposes the contract on him or her. Not only
> that, but
> ,, I expect knowledgeable user of my classes, provided that I document
> them.
> ,, There are enough, fairly simple, safeguards in Perl OOP to ensure that
> if a
> ,, user of an OOP module wants to do something that they oughtn't do,
> they put
> ,, some effort into discovering how to do what they shouldn't. And isn't
> that
> ,, really the basic issue?
>
> It's not about following contracts.
Well, it is. If you don't you get bitten, and if you do, well, you'll get
bitten less.
> Heh, if you follow contracts, memory management is easy too, and
> there won't be memory leaks. Should be then bemoan Perl doing
> memory management for us and robbing us from the freedom malloc
> and pointers give us?
Not at all - the bemoaning bit, I mean. I'm surely the better for having had
to worry about memory issues (not just pointers but tiny amounts of memory)
back when. Doesn't mean I want to spend quite as much time worrying about it
now (although I do when it's warranted).
> No, it turns out that for many programmers, memory management isn't
> easy. Having perl do the memory management for you not only reduces
> the number of memory management related bugs in the programs, it only
> reduces the amount of code a programmer has to write.
I'm an experienced (and I'd like to think a good) programmer - *I* don't
find memory management easy.
> If Larry hadn't decide to make OOP an exercise in minimalism and just
> had given us attributes, we wouldn't have had the problems we have
> now (no compile time checks, unintended clashes, etc), and we could
> be even more productive because we would have to write less code.
I will take your word for it re problems. I'm the only guy I personally
know who uses Perl, and I haven't had these problems. I'd already done OOP
in a couple of other languages before Perl 5 happened, and I suppose I used
Perl OOP carefully as a result. As a set of one I am probably not a good
example.
AHS
------------------------------
Date: Fri, 24 Nov 2006 23:06:52 GMT
From: boyd <tbmoore9@verizon.net>
Subject: Re: prevent further hash auto-vivification
Message-Id: <tbmoore9-C0D8DB.18065524112006@news.verizon.net>
In article <ogtem29b640vqt5pn30m130c3n2sufih5r@4ax.com>,
Michele Dondi <bik.mido@tiscalinet.it> wrote:
> On Fri, 24 Nov 2006 21:38:35 GMT, boyd <tbmoore9@verizon.net> wrote:
>
> >> > dear perl experts: how can I stop perl from auto-vivifying new keys in
> >> > a hash?
> >>
> >> Use exists() to check for their presence before accessing them.
> >>
> >> perldoc -f exists
> >>
> >> sherm--
> >
> >Not true. Exists will cause them to be vivified see the reference
> >quoted before:
> >http://www.perlarchive.com/articles/perl/ug0002.shtml
>
> Not true. Using "exist() to check for their presence before accessing
> them" yields a way to "stop perl from auto-vivifying new keys in a
> hash". That it won't prevent autovivification at some shallower levels
> when accessing a complex data structure is a whole another story and
> only means that you have to apply the same technique repeatedly and if
> you end up doing so quite often or otherwise find it convenient, then
> write some code that will factorize that apart, or find a module that
> addresses the issue.
>
>
> Michele
Sorry. I didn't read the question and/or article carefully enough. You
are correct. In other words: exists($ref->{a}) will not cause $ref->{a}
to be created, but exists($ref->{a}->{b}) will cause $ref->{a} to be
created as an empty hash. Right?
Thanks.
Boyd
------------------------------
Date: 24 Nov 2006 15:46:59 -0800
From: "DJ Stunks" <DJStunks@gmail.com>
Subject: Re: prevent further hash auto-vivification
Message-Id: <1164412019.779359.99050@m7g2000cwm.googlegroups.com>
boyd wrote:
> Sorry. I didn't read the question and/or article carefully enough. You
> are correct. In other words: exists($ref->{a}) will not cause $ref->{a}
> to be created, but exists($ref->{a}->{b}) will cause $ref->{a} to be
> created as an empty hash. Right?
don't ask, try! you could whip up a script to test that in about 4
lines
-jp
------------------------------
Date: Fri, 24 Nov 2006 18:48:17 -0500
From: Sherm Pendley <spamtrap@dot-app.org>
Subject: Re: prevent further hash auto-vivification
Message-Id: <m2irh49zjy.fsf@Sherm-Pendleys-Computer.local>
boyd <tbmoore9@verizon.net> writes:
> Sorry. I didn't read the question and/or article carefully enough. You
> are correct. In other words: exists($ref->{a}) will not cause $ref->{a}
> to be created, but exists($ref->{a}->{b}) will cause $ref->{a} to be
> created as an empty hash. Right?
Precisely.
sherm--
--
Web Hosting by West Virginians, for West Virginians: http://wv-www.net
Cocoa programming in Perl: http://camelbones.sourceforge.net
------------------------------
Date: Sat, 25 Nov 2006 00:03:49 GMT
From: boyd <tbmoore9@verizon.net>
Subject: Re: prevent further hash auto-vivification
Message-Id: <tbmoore9-6CD929.19035024112006@news.verizon.net>
In article <1164412019.779359.99050@m7g2000cwm.googlegroups.com>,
"DJ Stunks" <DJStunks@gmail.com> wrote:
> boyd wrote:
> > Sorry. I didn't read the question and/or article carefully enough. You
> > are correct. In other words: exists($ref->{a}) will not cause $ref->{a}
> > to be created, but exists($ref->{a}->{b}) will cause $ref->{a} to be
> > created as an empty hash. Right?
>
> don't ask, try! you could whip up a script to test that in about 4
> lines
>
> -jp
That's what I did. Except I did it within the debugger: perl -de1
I posted my question sort of rhetorically...
Thanks.
Boyd
------------------------------
Date: Sat, 25 Nov 2006 01:36:07 +0000
From: Ben Morrow <benmorrow@tiscali.co.uk>
Subject: Re: prevent further hash auto-vivification
Message-Id: <79jk34-s8n.ln1@osiris.mauzo.dyndns.org>
Quoth ivowel@gmail.com:
>
> dear perl experts: how can I stop perl from auto-vivifying new keys in
> a hash? this seems like something that everyone would want as an
> optional feature in an object oriented context, isn't it? sincerely,
As of 5.8.0 you can use Hash::Util::lock_keys to prevent new hash keys
from being added in any way (including autoviv). This feature was added
to support OOP, IIRC (it is a replacement for the deprecated pseudohash
semantics).
Ben
--
Raise your hand if you're invulnerable.
[benmorrow@tiscali.co.uk]
------------------------------
Date: Fri, 24 Nov 2006 23:46:05 -0500
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: prevent further hash auto-vivification
Message-Id: <x7k61k5e2a.fsf@mail.sysarch.com>
>>>>> "b" == boyd <tbmoore9@verizon.net> writes:
b> In article <1164412019.779359.99050@m7g2000cwm.googlegroups.com>,
b> "DJ Stunks" <DJStunks@gmail.com> wrote:
>> boyd wrote:
>> > Sorry. I didn't read the question and/or article carefully enough. You
>> > are correct. In other words: exists($ref->{a}) will not cause $ref->{a}
>> > to be created, but exists($ref->{a}->{b}) will cause $ref->{a} to be
>> > created as an empty hash. Right?
>>
>> don't ask, try! you could whip up a script to test that in about 4
>> lines
>>
>> -jp
b> That's what I did. Except I did it within the debugger: perl -de1
b> I posted my question sort of rhetorically...
and you could read the article mentioned. it covers autoviv, exists and
all related stuff. i should know. :)
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: Fri, 24 Nov 2006 23:49:17 -0500
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: prevent further hash auto-vivification
Message-Id: <x7fyc85dwy.fsf@mail.sysarch.com>
>>>>> "BM" == Ben Morrow <benmorrow@tiscali.co.uk> writes:
BM> Quoth ivowel@gmail.com:
>>
>> dear perl experts: how can I stop perl from auto-vivifying new keys in
>> a hash? this seems like something that everyone would want as an
>> optional feature in an object oriented context, isn't it? sincerely,
BM> As of 5.8.0 you can use Hash::Util::lock_keys to prevent new hash keys
BM> from being added in any way (including autoviv). This feature was added
BM> to support OOP, IIRC (it is a replacement for the deprecated pseudohash
BM> semantics).
i wouldn't say hash locking had anything to do with psuedo hashes.
psuedos were intended to be a fast way to do object and look up their
attributes. it was an unholy mess and was rightly ripped out of perl (i
think it was finally removed in 5.8 after being deprecated for years).
maybe the locked hashes are useful to various OO implementation styles
(inside out object don't need that AFAIK) but they aren't similar to
psuedo hashes in any way i can see.
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: Sat, 25 Nov 2006 00:38:19 +0100
From: ar81 <ar_nospam@free.fr>
Subject: Problem to compile Perl 5.8.8
Message-Id: <op.tjjnx5eh6hy138@pentium-d-830>
Hi all,
I'm new to perl. I'd like to install Perl 5.8.8. So I downloaded
stable.tar.gz and extracted the content to a temporary directory.
I executed : sh Configure -Dcc=gcc
When I execute "make", it fails with the following error :
/usr/bin/ar rcu libperl.a perl.o gv.o toke.o perly.o op.o pad.o regcomp.o
dump.o util.o mg.o reentr.o hv.o av.o run.o pp_hot.o sv.o pp.o scope.o
pp_ctl.o pp_sys.o doop.o doio.o regexec.o utf8.o taint.o deb.o universal.o
xsutils.o globals.o perlio.o perlapi.o numeric.o locale.o pp_pack.o
pp_sort.o
`sh cflags "optimize='-O2'" opmini.o` -DPERL_EXTERNAL_GLOB opmini.c
CCCMD = gcc -DPERL_CORE -c -fno-strict-aliasing -pipe
-Wdeclaration-after-statement -I/usr/local/include -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm -O2 -Wall
gcc -L/usr/local/lib -o miniperl \
miniperlmain.o opmini.o libperl.a
libperl.a(pp.o)(.text+0x272c): In function `Perl_pp_pow':
: undefined reference to `pow'
libperl.a(pp.o)(.text+0x346d): In function `Perl_pp_modulo':
: undefined reference to `floor'
libperl.a(pp.o)(.text+0x3495): In function `Perl_pp_modulo':
: undefined reference to `floor'
libperl.a(pp.o)(.text+0x355b): In function `Perl_pp_modulo':
: undefined reference to `fmod'
libperl.a(pp.o)(.text+0x7ce3): In function `Perl_pp_atan2':
: undefined reference to `atan2'
libperl.a(pp.o)(.text+0x7dc3): In function `Perl_pp_sin':
: undefined reference to `sin'
libperl.a(pp.o)(.text+0x7ee3): In function `Perl_pp_cos':
: undefined reference to `cos'
libperl.a(pp.o)(.text+0x8253): In function `Perl_pp_exp':
: undefined reference to `exp'
libperl.a(pp.o)(.text+0x83a5): In function `Perl_pp_log':
: undefined reference to `log'
libperl.a(pp.o)(.text+0x8577): In function `Perl_pp_sqrt':
: undefined reference to `sqrt'
libperl.a(pp.o)(.text+0x8728): In function `Perl_pp_int':
: undefined reference to `ceil'
libperl.a(pp.o)(.text+0x873e): In function `Perl_pp_int':
: undefined reference to `floor'
libperl.a(pp_pack.o)(.text+0x444c): In function `S_pack_rec':
: undefined reference to `floor'
libperl.a(pp_pack.o)(.text+0x4470): In function `S_pack_rec':
: undefined reference to `floor'
collect2: ld a retourné 1 code d'état d'exécution
make: *** [miniperl] Erreur 1
Does anybody have an idea on haow to figure this problem out ?
Regards
A. ROY
------------------------------
Date: Sat, 25 Nov 2006 00:54:37 +0100
From: Ric <antispam@randometry.com>
Subject: Re: Problem to compile Perl 5.8.8
Message-Id: <ek80o1$rtg$1@online.de>
ar81 schrieb:
>
> Hi all,
>
> I'm new to perl. I'd like to install Perl 5.8.8. So I downloaded
> stable.tar.gz and extracted the content to a temporary directory.
> I executed : sh Configure -Dcc=gcc
> When I execute "make", it fails with the following error :
>
> /usr/bin/ar rcu libperl.a perl.o gv.o toke.o perly.o op.o pad.o
> regcomp.o dump.o util.o mg.o reentr.o hv.o av.o run.o pp_hot.o sv.o pp.o
> scope.o pp_ctl.o pp_sys.o doop.o doio.o regexec.o utf8.o taint.o deb.o
> universal.o xsutils.o globals.o perlio.o perlapi.o numeric.o locale.o
> pp_pack.o pp_sort.o
> `sh cflags "optimize='-O2'" opmini.o` -DPERL_EXTERNAL_GLOB opmini.c
> CCCMD = gcc -DPERL_CORE -c -fno-strict-aliasing -pipe
> -Wdeclaration-after-statement -I/usr/local/include -D_LARGEFILE_SOURCE
> -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm -O2 -Wall
> gcc -L/usr/local/lib -o miniperl \
> miniperlmain.o opmini.o libperl.a
> libperl.a(pp.o)(.text+0x272c): In function `Perl_pp_pow':
> : undefined reference to `pow'
your c-stdlib is either not installed, or not in a different path than
"/usr/local/lib"
What distro, unix are you using?
> libperl.a(pp.o)(.text+0x346d): In function `Perl_pp_modulo':
> : undefined reference to `floor'
> libperl.a(pp.o)(.text+0x3495): In function `Perl_pp_modulo':
> : undefined reference to `floor'
> libperl.a(pp.o)(.text+0x355b): In function `Perl_pp_modulo':
> : undefined reference to `fmod'
> libperl.a(pp.o)(.text+0x7ce3): In function `Perl_pp_atan2':
> : undefined reference to `atan2'
> libperl.a(pp.o)(.text+0x7dc3): In function `Perl_pp_sin':
> : undefined reference to `sin'
> libperl.a(pp.o)(.text+0x7ee3): In function `Perl_pp_cos':
> : undefined reference to `cos'
> libperl.a(pp.o)(.text+0x8253): In function `Perl_pp_exp':
> : undefined reference to `exp'
> libperl.a(pp.o)(.text+0x83a5): In function `Perl_pp_log':
> : undefined reference to `log'
> libperl.a(pp.o)(.text+0x8577): In function `Perl_pp_sqrt':
> : undefined reference to `sqrt'
> libperl.a(pp.o)(.text+0x8728): In function `Perl_pp_int':
> : undefined reference to `ceil'
> libperl.a(pp.o)(.text+0x873e): In function `Perl_pp_int':
> : undefined reference to `floor'
> libperl.a(pp_pack.o)(.text+0x444c): In function `S_pack_rec':
> : undefined reference to `floor'
> libperl.a(pp_pack.o)(.text+0x4470): In function `S_pack_rec':
> : undefined reference to `floor'
> collect2: ld a retourné 1 code d'état d'exécution
> make: *** [miniperl] Erreur 1
>
>
> Does anybody have an idea on haow to figure this problem out ?
>
> Regards
> A. ROY
------------------------------
Date: Fri, 24 Nov 2006 18:56:49 -0500
From: Sherm Pendley <spamtrap@dot-app.org>
Subject: Re: Problem to compile Perl 5.8.8
Message-Id: <m2ac2g9z5q.fsf@Sherm-Pendleys-Computer.local>
ar81 <ar_nospam@free.fr> writes:
> I'm new to perl. I'd like to install Perl 5.8.8. So I downloaded
> stable.tar.gz and extracted the content to a temporary directory.
> I executed : sh Configure -Dcc=gcc
> When I execute "make", it fails with the following error :
>
> /usr/bin/ar rcu libperl.a perl.o gv.o toke.o perly.o op.o pad.o
> regcomp.o dump.o util.o mg.o reentr.o hv.o av.o run.o pp_hot.o sv.o
> pp.o scope.o pp_ctl.o pp_sys.o doop.o doio.o regexec.o utf8.o taint.o
> deb.o universal.o xsutils.o globals.o perlio.o perlapi.o numeric.o
> locale.o pp_pack.o pp_sort.o
> `sh cflags "optimize='-O2'" opmini.o` -DPERL_EXTERNAL_GLOB opmini.c
> CCCMD = gcc -DPERL_CORE -c -fno-strict-aliasing -pipe
> -Wdeclaration-after-statement -I/usr/local/include -D_LARGEFILE_SOURCE
> -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm -O2 -Wall
> gcc -L/usr/local/lib -o miniperl \
> miniperlmain.o opmini.o libperl.a
> libperl.a(pp.o)(.text+0x272c): In function `Perl_pp_pow':
> : undefined reference to `pow'
> libperl.a(pp.o)(.text+0x346d): In function `Perl_pp_modulo':
> : undefined reference to `floor'
> libperl.a(pp.o)(.text+0x3495): In function `Perl_pp_modulo':
> : undefined reference to `floor'
> libperl.a(pp.o)(.text+0x355b): In function `Perl_pp_modulo':
> : undefined reference to `fmod'
> libperl.a(pp.o)(.text+0x7ce3): In function `Perl_pp_atan2':
> : undefined reference to `atan2'
> libperl.a(pp.o)(.text+0x7dc3): In function `Perl_pp_sin':
> : undefined reference to `sin'
> libperl.a(pp.o)(.text+0x7ee3): In function `Perl_pp_cos':
> : undefined reference to `cos'
> libperl.a(pp.o)(.text+0x8253): In function `Perl_pp_exp':
> : undefined reference to `exp'
> libperl.a(pp.o)(.text+0x83a5): In function `Perl_pp_log':
> : undefined reference to `log'
> libperl.a(pp.o)(.text+0x8577): In function `Perl_pp_sqrt':
> : undefined reference to `sqrt'
> libperl.a(pp.o)(.text+0x8728): In function `Perl_pp_int':
> : undefined reference to `ceil'
> libperl.a(pp.o)(.text+0x873e): In function `Perl_pp_int':
> : undefined reference to `floor'
> libperl.a(pp_pack.o)(.text+0x444c): In function `S_pack_rec':
> : undefined reference to `floor'
> libperl.a(pp_pack.o)(.text+0x4470): In function `S_pack_rec':
> : undefined reference to `floor'
> collect2: ld a retourné 1 code d'état d'exécution
> make: *** [miniperl] Erreur 1
>
>
> Does anybody have an idea on haow to figure this problem out ?
Those are all math functions - try adding '-lm' to the default linker flags
suggested by Configure.
sherm--
--
Web Hosting by West Virginians, for West Virginians: http://wv-www.net
Cocoa programming in Perl: http://camelbones.sourceforge.net
------------------------------
Date: 24 Nov 2006 20:00:17 -0800
From: "nalhawash" <nalhawash@yahoo.ca>
Subject: Re: what is the best choose fork or thread?
Message-Id: <1164427217.720954.81760@45g2000cws.googlegroups.com>
thks
Nasser Alhawash
On Nov 24, 4:08 pm, xhos...@gmail.com wrote:
> Martijn Lievaart <m...@remove.this.part.rtij.nl> wrote:
> > On Thu, 23 Nov 2006 23:56:42 +0800, sonet wrote:
>
> > > I have a project must send a lot of file in win2k at the same time.
> > > But what is the best method in win32?
> > > Can the perl build-in function fork work in win32?
> > > Or the perl build-in thread is good solution
>
> > Besides Anno's answer, be aware that threads have severe limitations.
> > More to the point, threads and signals don't mix. So if you need timeouts
> > (in Perl) or any other signal handling, you are pretty much stuck on
> > forking.
>
> > Other than that, in general threads are faster than forks.Maybe in some languages, but in Perl they generally aren't.
>
> Xho
>
> --
> --------------------http://NewsReader.Com/--------------------
> Usenet Newsgroup Service $9.95/Month 30GB
------------------------------
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 V10 Issue 10005
****************************************
