[30496] in Perl-Users-Digest
Perl-Users Digest, Issue: 1739 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue Jul 22 16:09:55 2008
Date: Tue, 22 Jul 2008 13:09:15 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Tue, 22 Jul 2008 Volume: 11 Number: 1739
Today's topics:
Re: C linked lists in Perl <hjp-usenet2@hjp.at>
Re: C linked lists in Perl <szrRE@szromanMO.comVE>
Re: C linked lists in Perl <szrRE@szromanMO.comVE>
Re: C linked lists in Perl <hjp-usenet2@hjp.at>
Re: C linked lists in Perl <joost@zeekat.nl>
Re: C linked lists in Perl <joost@zeekat.nl>
Re: C linked lists in Perl xhoster@gmail.com
Re: C linked lists in Perl xhoster@gmail.com
Re: comma puzzle <szrRE@szromanMO.comVE>
Re: FAQ 3.18 How can I free an array or hash so my prog <brian.d.foy@gmail.com>
Re: FAQ 4.2 Why is int() broken? <szrRE@szromanMO.comVE>
Re: FAQ 4.32 How do I strip blank space from the beginn <szrRE@szromanMO.comVE>
Re: how to create a hash whose key is a reference <szrRE@szromanMO.comVE>
Re: How to identify a 32 or 64 bit OS? <tzz@lifelogs.com>
Re: Mail::IMAPClient usage... <tzz@lifelogs.com>
Re: Mail::IMAPClient usage... <yogeshkagrawal@gmail.com>
Re: Mail::IMAPClient usage... <rfs9999@earthlink.net>
Re: Mail::IMAPClient usage... <glex_no-spam@qwest-spam-no.invalid>
Re: Mail::IMAPClient usage... <m@rtij.nl.invlalid>
Re: PostgreSQL 8.3 working driver for ActivePerl/win? <john@castleamber.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 22 Jul 2008 19:09:53 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: C linked lists in Perl
Message-Id: <slrng8c534.9ja.hjp-usenet2@hrunkner.hjp.at>
On 2008-07-21 10:16, Joost Diepenmaat <joost@zeekat.nl> wrote:
> "szr" <szrRE@szromanMO.comVE> writes:
>> Joost Diepenmaat wrote:
>>> But expect perl's garbage collector to get in your face if you create
>>> giant linked lists. Not that you'd want to do that, anyway.
>>
>> Why would the GC get in the way? In a nutshell, it doesn't free
>> something until no one is referring to it anymore (the ref-count is
>> zero), so I'd imagine there would be no problem, or have you run into
>> issue in certain circumstances?
>
> The problem is that perl's CG is buggy
Define "buggy".
> and relatively slow for large linked lists (or any kind of deeply
> nested structure):
That program doesn't demonstrate that it is "relatively slow". You would
have to compare it to something else relative to which it is slow.
> #!/usr/local/bin/perl -w
> use strict;
> $|=1;
>
> sub test {
> print "Building list\n";
> my $head = [];
> my $tail = $head;
> for (0 .. 1000000) {
> $tail = ($tail->[1] = [$_]);
> }
> print "Exiting sub\n";
> }
>
> test();
> print "Exiting program\n";
>
> ouput:
>
> Building list
> Exiting sub
> Segmentation fault
That seems to be related to the stack size (if I reduce the stack size
the crash occurs with smaller lists). So without looking at the code I'd
guess that the GC calls itself recursively on all referenced objects
after freeing an object. Since on most OSs the stack is relatively small
(e.g., 8 MB on Linux/x86), you run out of stack space after a few 10000
nesting levels. Should be relatively simple to fix, but who in his right
mind builds datastructures with 100000 nesting levels?
hp
------------------------------
Date: Tue, 22 Jul 2008 10:17:51 -0700
From: "szr" <szrRE@szromanMO.comVE>
Subject: Re: C linked lists in Perl
Message-Id: <g654nv0771@news4.newsguy.com>
Ted Zlatanov wrote:
> On Fri, 18 Jul 2008 14:10:44 -0700 "szr" <szrRE@szromanMO.comVE>
> wrote:
>
> s> Ted Zlatanov wrote:
>>> On Thu, 17 Jul 2008 17:26:58 GMT Uri Guttman <uri@stemsystems.com>
>>> wrote:
> s> [...]
>>> I really don't know how much more "built-in" linked lists can be
>>> than what you find in Lisp, considering that code and data both are
>>> lists and treated as such by the language, and you can construct
>>> either dynamically. At this point you're arguing that with Lisp
>>> you have an assembled band saw (vs. Perl's Swiss Army knife or
>>> Java's diesel-powered hammer-screwdriver) but you can't use it
>>> until you plug it in. Well, yeah, but that is not an argument
>>> worth having.
>
> s> You forgot PHP's nuclear-powered 10,000 piece rachet set. :-)
>
> I tried to resist but you made me do it...
>
> Emacs Lisp = the band saw everyone has lost a fingertip to
> C = a club dotted with razor blades dipped in iodine "for better
> lubrication" C++ = machine gun that shoots dandellions
> Python = a Swedish Army knife
> COBOL = enough rubber bands WILL shoot you to the moon, apparently
> Fortran = a calculator embedded in a rock
> HTML/CSS/Javascript = a flail that keeps flinging back at you
> APL = a unicorn horn
> Ruby = Lisp's band saw and Perl's army knife used to decorate a
> princess birthday cake ("so cute!")
This is just priceless :-)
--
szr
------------------------------
Date: Tue, 22 Jul 2008 10:25:22 -0700
From: "szr" <szrRE@szromanMO.comVE>
Subject: Re: C linked lists in Perl
Message-Id: <g6556207kp@news4.newsguy.com>
Joost Diepenmaat wrote:
> "szr" <szrRE@szromanMO.comVE> writes:
>
>> Joost Diepenmaat wrote:
>>> But expect perl's garbage collector to get in your face if you
>>> create giant linked lists. Not that you'd want to do that, anyway.
>>
>> Why would the GC get in the way? In a nutshell, it doesn't free
>> something until no one is referring to it anymore (the ref-count is
>> zero), so I'd imagine there would be no problem, or have you run into
>> issue in certain circumstances?
>
> The problem is that perl's CG is buggy and relatively slow for large
> linked lists (or any kind of deeply nested structure):
>
> #!/usr/local/bin/perl -w
> use strict;
> $|=1;
>
> sub test {
> print "Building list\n";
> my $head = [];
> my $tail = $head;
> for (0 .. 1000000) {
> $tail = ($tail->[1] = [$_]);
^^^^^^^^^^^^^^^^^^^^^
Is it any surprise that it segfaults when you're using a construct with
undefined behavior?
> }
> print "Exiting sub\n";
> }
>
> test();
> print "Exiting program\n";
>
> ouput:
>
> Building list
> Exiting sub
> Segmentation fault
>
> This is perl, v5.10.0 built for i686-linux-thread-multi
--
szr
------------------------------
Date: Tue, 22 Jul 2008 20:00:14 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: C linked lists in Perl
Message-Id: <slrng8c81f.j44.hjp-usenet2@hrunkner.hjp.at>
On 2008-07-22 17:25, szr <szrRE@szromanMO.comVE> wrote:
> Joost Diepenmaat wrote:
>> #!/usr/local/bin/perl -w
>> use strict;
>> $|=1;
>>
>> sub test {
>> print "Building list\n";
>> my $head = [];
>> my $tail = $head;
>> for (0 .. 1000000) {
>> $tail = ($tail->[1] = [$_]);
> ^^^^^^^^^^^^^^^^^^^^^
>
> Is it any surprise that it segfaults when you're using a construct with
> undefined behavior?
It also crashes when the construct is replaced with one with defined
behaviour.
The crash occurs when $head goes out of scope, because the garbage
collector recursively frees the deeply nested data structure.
hp
------------------------------
Date: Tue, 22 Jul 2008 20:07:00 +0200
From: Joost Diepenmaat <joost@zeekat.nl>
Subject: Re: C linked lists in Perl
Message-Id: <874p6hrdx7.fsf@zeekat.nl>
"szr" <szrRE@szromanMO.comVE> writes:
>> $tail = ($tail->[1] = [$_]);
> ^^^^^^^^^^^^^^^^^^^^^
>
> Is it any surprise that it segfaults when you're using a construct with
> undefined behavior?
how is that behaviour undefined?
Also note that it's not this construct that causes the crash. It's the
refcounting GC that causes a stack overflow when collecting the
structure (as someone else already pointed out).
--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
------------------------------
Date: Tue, 22 Jul 2008 20:15:14 +0200
From: Joost Diepenmaat <joost@zeekat.nl>
Subject: Re: C linked lists in Perl
Message-Id: <87zlo9pyz1.fsf@zeekat.nl>
"Peter J. Holzer" <hjp-usenet2@hjp.at> writes:
> On 2008-07-21 10:16, Joost Diepenmaat <joost@zeekat.nl> wrote:
>> "szr" <szrRE@szromanMO.comVE> writes:
>>> Joost Diepenmaat wrote:
>>>> But expect perl's garbage collector to get in your face if you create
>>>> giant linked lists. Not that you'd want to do that, anyway.
>>>
>>> Why would the GC get in the way? In a nutshell, it doesn't free
>>> something until no one is referring to it anymore (the ref-count is
>>> zero), so I'd imagine there would be no problem, or have you run into
>>> issue in certain circumstances?
>>
>> The problem is that perl's CG is buggy
>
> Define "buggy".
See below.
>> and relatively slow for large linked lists (or any kind of deeply
>> nested structure):
>
> That program doesn't demonstrate that it is "relatively slow". You would
> have to compare it to something else relative to which it is slow.
True. I don't have a good comparison ready at the moment, and I think
I confused the refcounting GC with the "general GC" at END time (which
*is* a lot slower than the refcounting GC). Please ignore it.
>> #!/usr/local/bin/perl -w
>> use strict;
>> $|=1;
>>
>> sub test {
>> print "Building list\n";
>> my $head = [];
>> my $tail = $head;
>> for (0 .. 1000000) {
>> $tail = ($tail->[1] = [$_]);
>> }
>> print "Exiting sub\n";
>> }
>>
>> test();
>> print "Exiting program\n";
>>
>> ouput:
>>
>> Building list
>> Exiting sub
>> Segmentation fault
>
> That seems to be related to the stack size (if I reduce the stack size
> the crash occurs with smaller lists). So without looking at the code I'd
> guess that the GC calls itself recursively on all referenced objects
> after freeing an object. Since on most OSs the stack is relatively small
> (e.g., 8 MB on Linux/x86), you run out of stack space after a few 10000
> nesting levels. Should be relatively simple to fix, but who in his right
> mind builds datastructures with 100000 nesting levels?
I think you're correct that the problem is probably related to the
stack use during GC, but IMHO it's hardly good behaviour that GC'ing a
large linked structure causes a segfault. Of course it's possible to
break up the list yourself to prevent this, but IMHO the programmer
shouldn't have to.
--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
------------------------------
Date: 22 Jul 2008 18:14:58 GMT
From: xhoster@gmail.com
Subject: Re: C linked lists in Perl
Message-Id: <20080722141500.274$rH@newsreader.com>
"szr" <szrRE@szromanMO.comVE> wrote:
> Joost Diepenmaat wrote:
> > sub test {
> > print "Building list\n";
> > my $head = [];
> > my $tail = $head;
> > for (0 .. 1000000) {
> > $tail = ($tail->[1] = [$_]);
> ^^^^^^^^^^^^^^^^^^^^^
>
> Is it any surprise that it segfaults when you're using a construct with
> undefined behavior?
Is that behavior really undefined?
Xho
--
-------------------- http://NewsReader.Com/ --------------------
The costs of publication of this article were defrayed in part by the
payment of page charges. This article must therefore be hereby marked
advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
this fact.
------------------------------
Date: 22 Jul 2008 18:16:44 GMT
From: xhoster@gmail.com
Subject: Re: C linked lists in Perl
Message-Id: <20080722141646.125$br@newsreader.com>
"Peter J. Holzer" <hjp-usenet2@hjp.at> wrote:
> >
> > Building list
> > Exiting sub
> > Segmentation fault
>
> That seems to be related to the stack size (if I reduce the stack size
> the crash occurs with smaller lists). So without looking at the code I'd
> guess that the GC calls itself recursively on all referenced objects
> after freeing an object. Since on most OSs the stack is relatively small
> (e.g., 8 MB on Linux/x86), you run out of stack space after a few 10000
> nesting levels. Should be relatively simple to fix, but who in his right
> mind builds datastructures with 100000 nesting levels?
Someone trying to implement a large linked list, for one, or course.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
The costs of publication of this article were defrayed in part by the
payment of page charges. This article must therefore be hereby marked
advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
this fact.
------------------------------
Date: Tue, 22 Jul 2008 12:23:33 -0700
From: "szr" <szrRE@szromanMO.comVE>
Subject: Re: comma puzzle
Message-Id: <g65c3l0f0g@news4.newsguy.com>
Tad J McClellan wrote:
> Nick Wedd <nick@maproom.co.uk> wrote:
>> If I do
>> for ( my $i=0 ; $i<10 ; $i++ ) { print $i; }
>> it writes "0123456789". Fine.
>
>
> That uses the control structure described in the "For Loops"
> section of perlsyn.pod.
>
>
>> Now if I accidentally write
>> for ( my $i=0 , $i<10 , $i++ ) { print $i; }
>
>
> That uses the control structure described in the "Foreach Loops"
> section of perlsyn.pod.
>
> Since you did not provide a loop control variable, the foreach will
> place each list item into $_.
>
> But you never output $_.
>
>
>> it writes "111".
>
>
> it outputs "000" when I run it:
>
> perl -e 'for ( my $i=0 , $i<10 , $i++ ) { print $i; }'
It depends if $i is declared ahead of time or not:
$ perl -e 'for ( my $i=0 , $i<10 , $i++ ) { print $i; }'
000
$ perl -e 'my $i; for ( $i=0 , $i<10 , $i++ ) { print $i; }'
111
This is because in the first one, the C<$i> in the 2nd and 3rd elements
is not the same one in the first element, because that one isn't yet
'known'. When it's declared before hand, then it is known.
One question, I would of actually expected the 2nd run (where C<$i> is
pre-delcared) to output 011. Why does the first element become 1?
Shouldn't it end up like:
$i=0 -> 0,
$i<10 -> 0<10 -> 1 (true),
$i++ -> 0+1 -> 1
Is this a bug?
--
szr
------------------------------
Date: Tue, 22 Jul 2008 11:33:27 -0700
From: brian d foy <brian.d.foy@gmail.com>
Subject: Re: FAQ 3.18 How can I free an array or hash so my program shrinks?
Message-Id: <220720081133277028%brian.d.foy@gmail.com>
In article <OUahk.264135$yE1.173595@attbi_s21>, Michael Carman
<mjcarman@mchsi.com> wrote:
> PerlFAQ Server wrote:
> > 3.18: How can I free an array or hash so my program shrinks?
> >
> > (contributed by Michael Carman)
>
> But edited heavily enough that I barely recognize the bits I added
> anymore. :D Actually, my contribution was more to the cross-referenced
> entry on using less memory.
Yeah, answers morph over time. I can remove your credit if you like,
but I's rather give you credit still :)
> > Memory allocated to global variables can be reused (within your
> > program) by using undef()ing and/or delete().
>
> "using undef()ing" should be "using undef()."
fixing, thanks.
------------------------------
Date: Tue, 22 Jul 2008 12:09:40 -0700
From: "szr" <szrRE@szromanMO.comVE>
Subject: Re: FAQ 4.2 Why is int() broken?
Message-Id: <g65b9l0e2q@news4.newsguy.com>
PerlFAQ Server wrote:
> This is an excerpt from the latest version perlfaq4.pod, which
> comes with the standard Perl distribution. These postings aim to
> reduce the number of repeated questions as well as allow the community
> to review and update the answers. The latest version of the complete
> perlfaq is at http://faq.perl.org .
>
> --------------------------------------------------------------------
>
> 4.2: Why is int() broken?
>
> Your "int()" is most probably working just fine. It's the numbers
> that aren't quite what you think.
>
> First, see the answer to "Why am I getting long decimals (eg,
> 19.9499999999999) instead of the numbers I should be getting (eg,
> 19.95)?".
Maybe I'm just tired, but where exactly do you get these particular
rounding errors, as I cannot reproduce them:
$ perl5.10.0 -e 'print 19.95, qq{\n};'
19.95
$ perl5.10.0 -e 'print 20.0 - 0.05, qq{\n};'
19.95
$ perl5.10.0 -e 'print 9.975 * 2, qq{\n};'
19.95
$ perl5.10.0 -e 'print 39.9 / 2.0, qq{\n};'
19.95
I get the same results on each one of those command-lines on 5.6.1,
5.8.0, 5.8.2, and 5.8.8.
> For example, this
>
> print int(0.6/0.2-2), "\n";
>
> will in most computers print 0, not 1, because even such simple
> numbers as 0.6 and 0.2 cannot be presented exactly by
> floating-point numbers.
Curious:
$ perl5.10.0 -e 'print int(0.6/0.2-2), qq{\n};'
1
$ perl5.8.8 -e 'print int(0.6/0.2-2), qq{\n};'
1
But older Perl's I still have around for testing purposes, which have no
64 bit float or int support all zero:
$ perl5.8.2 -e 'print int(0.6/0.2-2), qq{\n};'
0
$ perl5.8.0 -e 'print int(0.6/0.2-2), qq{\n};'
0
$ perl5.6.1 -e 'print int(0.6/0.2-2), qq{\n};'
0
I take it this is because I compiled perl5.8.8 and perl5.10.0 with 64bit
float (and int) support?
> What you think in the above as 'three' is really more like
> 2.9999999999999995559.
$ perl5.10.0 -e 'print 3.0, qq{\n};'
3
Or am I missing something?
$ perl5.10.0 -e 'print sprintf(qq{%.50f}, 3.0), qq{\n};'
3.00000000000000000000000000000000000000000000000000
I would of expected some rounding errors, but this works on all the Perl
5's on my system just the same (only 5.8.8 and 5.10.0 are compiled with
64 bit floats and ints.)
Again I am a bit tired from a long trip so it's entirely conceivable
that I'm missing something obvious here.
--
szr
------------------------------
Date: Tue, 22 Jul 2008 10:33:33 -0700
From: "szr" <szrRE@szromanMO.comVE>
Subject: Re: FAQ 4.32 How do I strip blank space from the beginning/end of a string?
Message-Id: <g655ld083k@news4.newsguy.com>
brian d foy wrote:
> In article <g5s6b10p5o@news4.newsguy.com>, szr <szrRE@szromanMO.comVE>
> wrote:
>
>>> s/^\s+|\s+$//g;
>>
>> One might think that it would be realatively trivial to optimize a
>> situation like this: if all alternations are anchored, just go to the
>> next anchor if the previous match fails (or something to that
>> effect.)
>>
>> Does this make any sense?
>
> Sure that makes sense. Now just make the patch and send it to p5p so I
> can get back to my single regex instead of two statements :)
I will look into that then. I already have all the 5.10.0 (and past)
source codes so I'll start making some time to take a crack at that and
see if I can dish up something useful :-)
--
szr
------------------------------
Date: Tue, 22 Jul 2008 11:30:31 -0700
From: "szr" <szrRE@szromanMO.comVE>
Subject: Re: how to create a hash whose key is a reference
Message-Id: <g659080bul@news4.newsguy.com>
Gunnar Hjalmarsson wrote:
> freesoft12@gmail.com wrote:
>> I am creating 2 hash tables. In the first hash table I have a string
>> as the key but in the second one I want the reference to that string
>> as the key,
>
> Not possible. Hash keys are always strings.
You be more care with the use of the phrase "Not Possible", as it is
perfectly possible to take the reference of a key. You just have to do
al lthe work of keep the 2nd ref up to date - perhaps usinga Tie module
could be of some use here.
my %h_s = ( A => 123, B => 456, C => 789);
my %h_r = map { \$_ => \$h_s{$_} } keys %h_s;
# Note, this could be the actual value,
# but a ref made more sense.
foreach my $k (keys %h_s) {
my $v = $h_s{$k};
print qq{[$k] => [$v]\n};
}
print "\n";
foreach my $k (keys %h_s) {
my $v = ${$h_r{\$k}};
print qq{[$k] => [$v]\n};
}
print "\n";
[A] => [123]
[C] => [789]
[B] => [456]
[A] => [123]
[C] => [789]
[B] => [456]
I honestly do not know of any situation where such a setup would be
useful or needed. It should also be noted that storing a ref as a hash
key effectively destroys the actual ref since it stringifies the ref and
in the 2nd for-loop, C<$h_r{\$k}>, the same thing happenes, which why
it matches. You cannot use the keys from %h_r themselves as a ref witout
doing some extra work (I'd assume some sort of crazy eval construct
would come into play.)
* * *
In conclusion, there are much better ways to go about this. Namely,
using one hash, and thus one set of keys, and use hash-or-array refs to
store your data structure.
--
szr
------------------------------
Date: Tue, 22 Jul 2008 08:28:03 -0500
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: How to identify a 32 or 64 bit OS?
Message-Id: <86y73udp5o.fsf@lifelogs.com>
On Tue, 22 Jul 2008 00:49:18 +0000 (UTC) Ilya Zakharevich <nospam-abuse@ilyaz.org> wrote:
IZ> [A complimentary Cc of this posting was sent to
IZ> Ted Zlatanov
IZ> <tzz@lifelogs.com>], who wrote in article <86zlobgolz.fsf@lifelogs.com>:
>> On Mon, 21 Jul 2008 01:58:08 +0000 (UTC) Ilya Zakharevich <nospam-abuse@ilyaz.org> wrote:
>> I mentioned it on perl5-porters and CC-d you but the mail bounced.
IZ> To the mail in this posting? Strange, at least some spam is reaching
IZ> me on this address... :-( ;-)
OK, I'll try again next time.
>> Do you want to put the effort into putting something together?
IZ> As I said, I'm sitting on zillions of such patches... Without
IZ> external funding, I'm afraid I would not be able to go through them
IZ> again...
Send me the files you think may contain the patch and I'll see if I can
figure it out, unless that's not possible either.
Thanks
Ted
------------------------------
Date: Tue, 22 Jul 2008 08:22:49 -0500
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: Mail::IMAPClient usage...
Message-Id: <8663qyf3yu.fsf@lifelogs.com>
On Tue, 22 Jul 2008 08:41:15 +0200 Martijn Lievaart <m@rtij.nl.invlalid> wrote:
ML> On Mon, 21 Jul 2008 21:47:41 -0700, Yogi wrote:
>> ($MAILSERVER,$USER,$PW,$num) = ('pop.gmail.com:995/pop3/ssl',
>> 'myid@gmail.com',
>> 'mypwd');
ML> Ahum, IMAP is not pop3, and Mail::IMAPClient does only IMAP. I think you
ML> should look for a pop3 client library.
...he could also use GMail's IMAP services.
GMail IMAP, incidentally, implements a very basic subset of IMAP, but
it's probably enough for the OP.
Ted
------------------------------
Date: Tue, 22 Jul 2008 06:55:08 -0700 (PDT)
From: Yogi <yogeshkagrawal@gmail.com>
Subject: Re: Mail::IMAPClient usage...
Message-Id: <49dfef1f-4b74-406f-b5d2-733b02921875@m36g2000hse.googlegroups.com>
On Jul 22, 6:22=A0pm, Ted Zlatanov <t...@lifelogs.com> wrote:
> On Tue, 22 Jul 2008 08:41:15 +0200 Martijn Lievaart <m...@rtij.nl.invlali=
d> wrote:
>
> ML> On Mon, 21 Jul 2008 21:47:41 -0700, Yogi wrote:
>
> >> ($MAILSERVER,$USER,$PW,$num) =3D ('pop.gmail.com:995/pop3/ssl',
> >> 'm...@gmail.com',
> >> 'mypwd');
>
> ML> Ahum, IMAP is not pop3, and Mail::IMAPClient does only IMAP. I think =
you
> ML> should look for a pop3 client library.
>
> ...he could also use GMail's IMAP services.
>
> GMail IMAP, incidentally, implements a very basic subset of IMAP, but
> it's probably enough for the OP.
>
> Ted
Hi Ted n Rick,
Thanks for your response on this. But even this is not working.
my $pop =3D new Mail::POP3Client( USER =3D> 'myid',
PASSWORD =3D> 'mypwd',
HOST =3D> "pop.gmail.com:995",
USESSL =3D> 1,
DEBUG =3D> 1
) || die("Error here $@");
I tried all suggested changes but no success so far. For userid, I
tried giving myid@gmail.com as well as only 'myid' but all failed. I
am running this script from my windows machine with ActiveState
Perlv5.10.0.
Any suggestions?
------------------------------
Date: Tue, 22 Jul 2008 09:28:28 -0500
From: Rick Sanders <rfs9999@earthlink.net>
Subject: Re: Mail::IMAPClient usage...
Message-Id: <7c13d$4885ee8c$31034@news.teranews.com>
> I tried all suggested changes but no success so far.
> Any suggestions?
Please post the output from your program with DEBUG enabled. That
should point out the problem. You should see something like this:
POP3 <- +OK Gpop ready for requests from <IP> 6pf7997068ywp.0
at ./popClient.pl line 5
POP3 -> CAPA
at ./popClient.pl line 5
POP3 <- +OK Capability list follows
[ snipped ]
POP3 -> USER <your username>
at ./popClient.pl line 5
POP3 <- +OK send PASS
at ./popClient.pl line 5
POP3 -> PASS <your password>
at ./popClient.pl line 5
POP3 <- +OK Welcome.
at ./popClient.pl line 5
POP3 -> STAT
at ./popClient.pl line 5
POP3 <- +OK 189 5021055
etc
"189" is the mail count in my gmail account.
Some other thoughts. Try changing your password to something bogus and
see if the results change. If not, you may not be making an SSL
connection to gmail, eg your username/password may be wrong.
Is the IO::Socket::SSL module installed on your system? Does it have an
SSL library installed?
If you have an account on another server try to connect to it, both with
and without SSL.
-Rick
** Posted from http://www.teranews.com **
------------------------------
Date: Tue, 22 Jul 2008 10:58:37 -0500
From: "J. Gleixner" <glex_no-spam@qwest-spam-no.invalid>
Subject: Re: Mail::IMAPClient usage...
Message-Id: <488603ad$0$33224$815e3792@news.qwest.net>
Yogi wrote:
> On Jul 22, 6:22 pm, Ted Zlatanov <t...@lifelogs.com> wrote:
>> On Tue, 22 Jul 2008 08:41:15 +0200 Martijn Lievaart <m...@rtij.nl.invlalid> wrote:
>>
>> ML> On Mon, 21 Jul 2008 21:47:41 -0700, Yogi wrote:
>>
>>>> ($MAILSERVER,$USER,$PW,$num) = ('pop.gmail.com:995/pop3/ssl',
>>>> 'm...@gmail.com',
>>>> 'mypwd');
>> ML> Ahum, IMAP is not pop3, and Mail::IMAPClient does only IMAP. I think you
>> ML> should look for a pop3 client library.
>>
>> ...he could also use GMail's IMAP services.
>>
>> GMail IMAP, incidentally, implements a very basic subset of IMAP, but
>> it's probably enough for the OP.
>>
>> Ted
>
> Hi Ted n Rick,
> Thanks for your response on this. But even this is not working.
>
> my $pop = new Mail::POP3Client( USER => 'myid',
> PASSWORD => 'mypwd',
> HOST => "pop.gmail.com:995",
> USESSL => 1,
> DEBUG => 1
> ) || die("Error here $@");
>
That's probably not how you would display the actual error.
Form the perldoc:
new returns a valid Mail::POP3Client object in all cases. To test for a
connection failure, you will need to check the number of messages: -1
indicates a connection error. This will likely change sometime in the
future to return undef on an error, setting $! as a side effect. This
change will not happen in any 2.x version.
Follow the documentation and use the Message method.
------------------------------
Date: Tue, 22 Jul 2008 19:36:43 +0200
From: Martijn Lievaart <m@rtij.nl.invlalid>
Subject: Re: Mail::IMAPClient usage...
Message-Id: <pan.2008.07.22.17.36.43@rtij.nl.invlalid>
On Tue, 22 Jul 2008 02:29:50 -0700, Yogi wrote:
> this code is not failing while trying to connect but giving msgCount =
> -1. Am I missing anything here again?
Yes, you missed to read the documentation.
] new returns a valid Mail::POP3Client object in all cases. To test for a
] connection failure, you will need to check the number of messages: -1
] indicates a connection error. This will likely change sometime in the
] future to return undef on an error, setting $! as a side effect. This
] change will not happen in any 2.x version.
I guess you should give the servername as "pop.gmail.com", not
"pop.gmail.com:995/pop3/ssl".
HTH,
M4
------------------------------
Date: 22 Jul 2008 13:28:10 GMT
From: John Bokma <john@castleamber.com>
Subject: Re: PostgreSQL 8.3 working driver for ActivePerl/win?
Message-Id: <Xns9AE35627C948Bcastleamber@130.133.1.4>
John Bokma <john@castleamber.com> wrote:
> Today I installed PostgreSQL 8.3 on a computer running XP
> Professional, but still no luck in installing a working DBD::Pg
>
> Perl -v:
> This is perl, v5.8.8 built for MSWin32-x86-multi-thread
> (with 50 registered patches,
> see perl -V for more detail)
>
> :
> :
> :
> Binary build 820 [274739] provided by ActiveState
Upgrading to
This is perl, v5.8.8 built for MSWin32-x86-multi-thread
(with 18 registered patches, see perl -V for more detail)
:
Binary build 822 [280952] provided by ActiveState
http://www.ActiveState.com
Built Jul 31 2007 19:34:48
did the trick.
--
John
http://johnbokma.com/perl/
------------------------------
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 1739
***************************************
