[31689] in Perl-Users-Digest
Perl-Users Digest, Issue: 2952 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed May 19 16:09:28 2010
Date: Wed, 19 May 2010 13:09:11 -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 Wed, 19 May 2010 Volume: 11 Number: 2952
Today's topics:
Re: bit-twiddling on 32-bit machines <nospam-abuse@ilyaz.org>
Re: bit-twiddling on 32-bit machines <ben@morrow.me.uk>
Re: bit-twiddling on 32-bit machines <nospam-abuse@ilyaz.org>
Re: determining whether a server supports secure authen <someone@example.com>
Re: determining whether a server supports secure authen <nospam-abuse@ilyaz.org>
Re: determining whether a server supports secure authen sln@netherlands.com
Re: Don't understand: when('foo' and/or 'bar') <nospam-abuse@ilyaz.org>
Re: Don't understand: when('foo' and/or 'bar') <w.c.humann@arcor.de>
Re: Don't understand: when('foo' and/or 'bar') <uri@StemSystems.com>
ls in ftp fails <mikaelpetterson@hotmail.com>
Re: ls in ftp fails <peter@makholm.net>
Re: ls in ftp fails <ben@morrow.me.uk>
Re: ls in ftp fails <No_4@dsl.pipex.com>
Re: ls in ftp fails sln@netherlands.com
Re: ls in ftp fails <nobodyhere@example.com>
Re: ls in ftp fails <smallpond@juno.com>
Re: People don't understand: smart match, when etc <nospam-abuse@ilyaz.org>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 19 May 2010 10:21:36 +0000 (UTC)
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: bit-twiddling on 32-bit machines
Message-Id: <slrnhv7etg.740.nospam-abuse@powdermilk.math.berkeley.edu>
On 2010-05-18, Ben Morrow <ben@morrow.me.uk> wrote:
>> > > 8 hours of my time trying to debug it because of a stupid assumption
>> > > on my part. When doing a lot of shifts and bit-wise xor's it's easy
>> > > for 32-bit integers to overflow into double precision floating point
>> > > values. I recognized this early on and thought I was capturing only
>> > > the lowest 32 bits with ($x &= 0xffffffff). That simply does not work!
>> > > The way I got around it was with ($x %= 4294967296). In hindsight it's
>> > > easy for me now to recognize why the first not only doesn't work but
>> > > doesn't even make sense with the mixed number types. I hope this helps
>> > > someone else. Happy bit-twiddling!
>> >
>> > perldoc -f integer
>>
>> Tried it, didn't work with the integer pragma. The only way I could
>> get it to work properly was to allow an integer promotion to a C
>> double and then do the modulo arithmetic to capture the least-
>> significant 32 bits.
>
> Depending on what you're doing, promotion to double *should* safely give
> you 53 bits of integer precision, but you may want to consider
> rebuilding your perl with -Duse64bitint to avoid type conversion all
> over the place. The standard FreeBSD build has been built with this
> option for a while now, and there is some talk of using it for the
> Debian builds of 5.12.
Having int wider than float type is a VERY large can of worms (well,
at least it was the last time I was looking; did things change
recently?). What is reported above (which is, essentially, a bug of
the implementation of `use integer') is a very small can of worms.
Does not look like a fair trade...
Ilya
------------------------------
Date: Wed, 19 May 2010 14:28:44 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: bit-twiddling on 32-bit machines
Message-Id: <cl5dc7-iu4.ln1@osiris.mauzo.dyndns.org>
Quoth Ilya Zakharevich <nospam-abuse@ilyaz.org>:
> On 2010-05-18, Ben Morrow <ben@morrow.me.uk> wrote:
> >
> > Depending on what you're doing, promotion to double *should* safely give
> > you 53 bits of integer precision, but you may want to consider
> > rebuilding your perl with -Duse64bitint to avoid type conversion all
> > over the place. The standard FreeBSD build has been built with this
> > option for a while now, and there is some talk of using it for the
> > Debian builds of 5.12.
>
> Having int wider than float type is a VERY large can of worms (well,
> at least it was the last time I was looking; did things change
> recently?).
That's all been fixed, I think by Nick Clark during 5.8. A whole lot of
code in {pp,sv}.c is now conditional on NV_PRESERVES_UV, which is
determined by Configure.
Ben
------------------------------
Date: Wed, 19 May 2010 18:46:36 +0000 (UTC)
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: bit-twiddling on 32-bit machines
Message-Id: <slrnhv8cgc.8h5.nospam-abuse@powdermilk.math.berkeley.edu>
On 2010-05-19, Ben Morrow <ben@morrow.me.uk> wrote:
>
> Quoth Ilya Zakharevich <nospam-abuse@ilyaz.org>:
>> On 2010-05-18, Ben Morrow <ben@morrow.me.uk> wrote:
>> >
>> > Depending on what you're doing, promotion to double *should* safely give
>> > you 53 bits of integer precision, but you may want to consider
>> > rebuilding your perl with -Duse64bitint to avoid type conversion all
>> > over the place. The standard FreeBSD build has been built with this
>> > option for a while now, and there is some talk of using it for the
>> > Debian builds of 5.12.
>>
>> Having int wider than float type is a VERY large can of worms (well,
>> at least it was the last time I was looking; did things change
>> recently?).
>
> That's all been fixed, I think by Nick Clark during 5.8. A whole lot of
> code in {pp,sv}.c is now conditional on NV_PRESERVES_UV, which is
> determined by Configure.
Looks like I might have been not very specific. The can of worms I
meant is with the semantic, not implementation - things "not behaving
as expected" vs things behaving "obviously wrong".
This thread is one example of the "first category" - if one forgets
what happens with `use integer', which is obviously a bug (BTW, is it
reported yet?).
Yours,
Ilya
------------------------------
Date: Wed, 19 May 2010 10:40:36 -0700
From: "John W. Krahn" <someone@example.com>
Subject: Re: determining whether a server supports secure authentication
Message-Id: <ooVIn.8447$yx.4005@newsfe13.iad>
Tad McClellan wrote:
> Uno <merrilljensen@q.com> wrote:
>
>> my $socket = new IO::Socket::INET (PeerAddr => $remote_host,
>> PeerPort => $remote_port,
>> Proto => "tcp",
>> Type => SOCK_STREAM)
>> or die "scheisse mal\n";
>>
>> print $socket "data\n";
>
>
> This one is:
>
> print FILEHANDLE LIST
>
>
>> my $line = <$socket>;
>>
>> print $line;
>
> This one is:
>
> print LIST
>
>
>> q1) Can someone say a few words about the differences between the print
>> statements.
>
>
> perldoc -f print
>
>
>> Apparently, one sends a message to another machine,
>
>
> FILEHANDLE may be a scalar variable name, in which case the variable
> contains the name of or a reference to the filehandle
>
>
>> and the
>> other sends a message to mine.
>
>
> If FILEHANDLE is omitted, prints by default to standard output
If FILEHANDLE is omitted, prints to the currently selected
filehandle which by default is standard output.
perldoc -f select
John
--
The programmer is fighting against the two most
destructive forces in the universe: entropy and
human stupidity. -- Damian Conway
------------------------------
Date: Wed, 19 May 2010 19:16:45 +0000 (UTC)
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: determining whether a server supports secure authentication
Message-Id: <slrnhv8e8t.8h5.nospam-abuse@powdermilk.math.berkeley.edu>
On 2010-05-19, Uno <merrilljensen@q.com> wrote:
> I guess I don't know who an "attacker" is. I see movies where any
> computer capability can exist, like Seth Green controlling traffic in
> Los Angeles in "The Italian Job." I admire Seth's genius (Robot
> Chicken), but don't think the situation possible.
> What would it take for another entity to suck up all my packets that I
> sent to q.com?
Google for it; it must be discussed out to the death. (IIRC MIB do
not need to suck up anything; all they need is to reply EARLIER than
your intended target - which is not hard given that they are IN
BETWEEN.)
Hope this helps,
Ilya
------------------------------
Date: Wed, 19 May 2010 12:36:35 -0700
From: sln@netherlands.com
Subject: Re: determining whether a server supports secure authentication
Message-Id: <qbf8v51vfu8obhkqsgkl2sct0ti95ru55e@4ax.com>
On Wed, 19 May 2010 19:16:45 +0000 (UTC), Ilya Zakharevich <nospam-abuse@ilyaz.org> wrote:
>On 2010-05-19, Uno <merrilljensen@q.com> wrote:
>> I guess I don't know who an "attacker" is. I see movies where any
>> computer capability can exist, like Seth Green controlling traffic in
>> Los Angeles in "The Italian Job." I admire Seth's genius (Robot
>> Chicken), but don't think the situation possible.
>
>> What would it take for another entity to suck up all my packets that I
>> sent to q.com?
>
>Google for it; it must be discussed out to the death. (IIRC MIB do
>not need to suck up anything; all they need is to reply EARLIER than
>your intended target - which is not hard given that they are IN
>BETWEEN.)
>
Such things are criminal, how are we to protect ourselves.
-sln
------------------------------
Date: Wed, 19 May 2010 10:17:47 +0000 (UTC)
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: Don't understand: when('foo' and/or 'bar')
Message-Id: <slrnhv7emb.740.nospam-abuse@powdermilk.math.berkeley.edu>
On 2010-05-19, Uri Guttman <uri@StemSystems.com> wrote:
> >> this does need some more explanation. i see a smart match tutorial in
> >> the future (prolly not from me!).
> IZ> I think the much more productive solution is to avoid smart matching
> IZ> completely. (I have no idea WHY it was added to the language; looks
> IZ> like a severely not-enough-thought-about feature...)
> this isn't a smart matching issue but a when/given issue and when it
> will use smart matching. if you want to bitch about a feature, then
> know which is which before you bitch! :)
So it is "smarter than smart" matching. Do you see any difference?
Ilya
------------------------------
Date: Wed, 19 May 2010 03:35:03 -0700 (PDT)
From: Wolfram Humann <w.c.humann@arcor.de>
Subject: Re: Don't understand: when('foo' and/or 'bar')
Message-Id: <de74617c-6611-4480-ba37-7f81a7d37dab@q13g2000vbm.googlegroups.com>
On May 18, 8:25=A0pm, "Uri Guttman" <u...@StemSystems.com> wrote:
> having read the docs i agree it isn't very clear. try it again with
> regexes like /foo/ and /bar/ also with && instead of 'and'.
Going from 'and' and 'or' to '&&' and '||' makes no difference. '/foo/
or /bar/' works -- but only because (/foo/ or /bar/) already does what
I want without needing any given/when or smartmatching specials. When
testing for undef I need to write 'when(/foo/ or !defined($_))'. Maybe
Willem's solution below is better here.
On May 18, 8:35=A0pm, Willem <wil...@turtle.stack.nl> wrote:
>
> However, to get the behaviour for 'or' that you want, you can do somethin=
g
> like: given($x) { when (['foo', 'bar']) { say 'f' } }
That extends nicely to when(['foo', undef]). Thanks for the idea. The
only drawback is that the intention is not as obvious because the 'or'
is implicit from the undelying 'grep'-like smartmatching.
Thanks for all replies,
Wolfram
------------------------------
Date: Wed, 19 May 2010 12:29:05 -0400
From: "Uri Guttman" <uri@StemSystems.com>
Subject: Re: Don't understand: when('foo' and/or 'bar')
Message-Id: <874oi326um.fsf@quad.sysarch.com>
>>>>> "IZ" == Ilya Zakharevich <nospam-abuse@ilyaz.org> writes:
IZ> On 2010-05-19, Uri Guttman <uri@StemSystems.com> wrote:
>> >> this does need some more explanation. i see a smart match tutorial in
>> >> the future (prolly not from me!).
IZ> I think the much more productive solution is to avoid smart matching
IZ> completely. (I have no idea WHY it was added to the language; looks
IZ> like a severely not-enough-thought-about feature...)
>> this isn't a smart matching issue but a when/given issue and when it
>> will use smart matching. if you want to bitch about a feature, then
>> know which is which before you bitch! :)
IZ> So it is "smarter than smart" matching. Do you see any difference?
yes i see the difference. given/when decides whether to do boolean or
smart matching. then smart matching may do some more decisions. fairly
obvious differences in the phases.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
------------------------------
Date: Wed, 19 May 2010 05:55:46 -0700 (PDT)
From: mike <mikaelpetterson@hotmail.com>
Subject: ls in ftp fails
Message-Id: <ce673acb-4160-4421-8058-5e4bd16e311c@a20g2000vbc.googlegroups.com>
Hi,
I connect to a remote ftp site:
I see the following from the script:
Directory is /mirror/eclipse/technology/epp/downloads/release/galileo/
SR2
I cannot list the files in the directory $current_dir.
The line that fails is:
my @files=$ftp -> ls("$current_dir") or die "Could not list files. $!
\n";
Any idea what I am doing wrong? All help is very much appreciated.
//mike
Code:
use strict;
use warnings;
use Net::FTP;
my $message;
my $hostname ="ftp.ing.umu.se";
my $remote_dir = "/mirror/eclipse/technology/epp/downloads/release/
galileo/SR2/";
my $ftp = Net::FTP -> new ($hostname,Timeout => 30,Debug => 0) or
die "Cannot access $hostname via FTP\n";
$ftp -> login("anonymous",'-anonymous@') or
die "Invalid user name and/or password\n",$ftp-> $message;
$ftp->binary();
$ftp->cwd("$remote_dir") or die "Couldn't change directory. $!", $ftp->
$message;
my $current_dir = $ftp -> pwd();
print ("Directory is $current_dir \n");
my @files=$ftp -> ls("$current_dir") or die "Could not list files. $!
\n";
foreach my $file (@files){
print "$file \n";
}
------------------------------
Date: Wed, 19 May 2010 16:35:45 +0200
From: Peter Makholm <peter@makholm.net>
Subject: Re: ls in ftp fails
Message-Id: <87sk5o0xj2.fsf@vps1.hacking.dk>
mike <mikaelpetterson@hotmail.com> writes:
> The line that fails is:
>
> my @files=$ftp -> ls("$current_dir") or die "Could not list files. $!
> \n";
In the documentation for Net::FTP I see no sign of $! having any
significance to errors in the module. The synopsis have examples of
error handling using $ftp->message. It might be more helpful.
(Not that the message method is actually documentes. *sigh*)
//Makholm
------------------------------
Date: Wed, 19 May 2010 17:06:01 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: ls in ftp fails
Message-Id: <9sedc7-m96.ln1@osiris.mauzo.dyndns.org>
Quoth Peter Makholm <peter@makholm.net>:
> mike <mikaelpetterson@hotmail.com> writes:
>
> > The line that fails is:
> >
> > my @files=$ftp -> ls("$current_dir") or die "Could not list files. $!
> > \n";
>
> In the documentation for Net::FTP I see no sign of $! having any
> significance to errors in the module. The synopsis have examples of
> error handling using $ftp->message. It might be more helpful.
>
> (Not that the message method is actually documentes. *sigh*)
It is, though it's a little obscure.
perldoc Net::FTP:
| Methods for the adventurous
| "Net::FTP" inherits from "Net::Cmd" so methods defined in "Net::Cmd"
| may be used to send commands to the remote FTP server.
perldoc Net::Cmd:
| message ()
| Returns the text message returned from the last command
|
| code ()
| Returns the 3-digit code from the last command. If a command is
| pending then the value 0 is returned
Ben
------------------------------
Date: Wed, 19 May 2010 21:00:33 +0100
From: Big and Blue <No_4@dsl.pipex.com>
Subject: Re: ls in ftp fails
Message-Id: <YvKdneIhPt783mnWnZ2dnUVZ8t-dnZ2d@pipex.net>
On 05/19/10 13:55, mike wrote:
> Any idea what I am doing wrong? All help is very much appreciated.
Are you sure that is the code you are using...
> $ftp -> login("anonymous",'-anonymous@') or
> die "Invalid user name and/or password\n",$ftp-> $message;
...since that line produces the error message:
> Use of uninitialized value $message in method lookup at ftp.pl line 21.
> Can't locate object method "" via package "Net::FTP" at ftp.pl line 21.
owing to the extraneous $ in front of message.
With that fixed, it works for me.
[mysys]: perl ftp.pl
Directory is /mirror/eclipse/technology/epp/downloads/release/galileo/SR2
/mirror/eclipse/technology/epp/downloads/release/galileo/SR2/eclipse-rcp-galileo-SR2-linux-gtk.tar.gz.sha1
.....
/mirror/eclipse/technology/epp/downloads/release/galileo/SR2/eclipse-reporting-galileo-SR2-macosx-cocoa-x86_64.tar.gz.md5
--
Just because I've written it doesn't mean that
either you or I have to believe it.
------------------------------
Date: Wed, 19 May 2010 13:03:45 -0700
From: sln@netherlands.com
Subject: Re: ls in ftp fails
Message-Id: <ivg8v51kk4otuo7vo23prdapgt6sej7hgt@4ax.com>
On Wed, 19 May 2010 21:00:33 +0100, Big and Blue <No_4@dsl.pipex.com> wrote:
>On 05/19/10 13:55, mike wrote:
>
> > Any idea what I am doing wrong? All help is very much appreciated.
>
>Are you sure that is the code you are using...
>
> > $ftp -> login("anonymous",'-anonymous@') or
> > die "Invalid user name and/or password\n",$ftp-> $message;
^^^^^^^^^^^^^^^^
>
>...since that line produces the error message:
Yeah, look at that. Good eye!
-sln
------------------------------
Date: Wed, 19 May 2010 13:06:14 -0700
From: Ohhhh maaan <nobodyhere@example.com>
Subject: Re: ls in ftp fails
Message-Id: <XwXIn.16206$TL5.14286@newsfe24.iad>
mike wrote:
> Hi,
>
> I connect to a remote ftp site:
>
> I see the following from the script:
>
> Directory is /mirror/eclipse/technology/epp/downloads/release/galileo/
> SR2
>
> I cannot list the files in the directory $current_dir.
>
> The line that fails is:
>
> my @files=$ftp -> ls("$current_dir") or die "Could not list files. $!
> \n";
>
Works for me, try setting PASV mode or not, because it's likely a
firewall issue that's blocking the listing.
------------------------------
Date: Wed, 19 May 2010 06:44:32 -0700 (PDT)
From: smallpond <smallpond@juno.com>
Subject: Re: ls in ftp fails
Message-Id: <63bbcd75-0293-457a-982b-9cd3a52e7133@f13g2000vbm.googlegroups.com>
On May 19, 8:55=A0am, mike <mikaelpetter...@hotmail.com> wrote:
> Hi,
>
> I connect to a remote ftp site:
>
> I see the following from the script:
>
> Directory is /mirror/eclipse/technology/epp/downloads/release/galileo/
> SR2
>
> I cannot list the files in the directory $current_dir.
>
> The line that fails is:
>
> my @files=3D$ftp -> ls("$current_dir") or die "Could not list files. $!
> \n";
>
> Any idea what I am doing wrong? All help is very much appreciated.
Yes. What you are doing wrong is not telling us what error got
printed
by the die, The whole point of the die instruction is to print out
that informative little $! thingy.
------------------------------
Date: Wed, 19 May 2010 19:03:40 +0000 (UTC)
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: People don't understand: smart match, when etc
Message-Id: <slrnhv8dgb.8h5.nospam-abuse@powdermilk.math.berkeley.edu>
On 2010-05-19, Uri Guttman <uri@StemSystems.com> wrote:
> >> >> this does need some more explanation. i see a smart match tutorial in
> >> >> the future (prolly not from me!).
>
> IZ> I think the much more productive solution is to avoid smart matching
> IZ> completely. (I have no idea WHY it was added to the language; looks
> IZ> like a severely not-enough-thought-about feature...)
>
> >> this isn't a smart matching issue but a when/given issue and when it
> >> will use smart matching. if you want to bitch about a feature, then
> >> know which is which before you bitch! :)
>
> IZ> So it is "smarter than smart" matching. Do you see any difference?
>
> yes i see the difference. given/when decides whether to do boolean or
> smart matching. then smart matching may do some more decisions. fairly
> obvious differences in the phases.
What I meant is that the semantic of given/when is, by inheritance,
yet more baroque than one of smart matching. People are just plain
not able to juggle in mind that many logical switch tables.
IMO, one should have left only "the most obvious entries" in the
logic of smart matching [ones which can be deduced without
confusion from a VERY short list of rules], and just plain PROHIBIT
all the rest. One might have needed to be yet more strict with
given/when... (Well, the more complex semantic could have been
left on different keywords, clearly marking "this piece of code
requires special attention".)
IMO, one should have done the same with precedence tables of Perl -
one should be able to prohibit all the non-obvious confusion-prone
combinations via `use strict q(precedence)', forcing the user to use
explicit parentheses.
(The situation with RExen is kinda borderline; the complexity there is
clearly "visually marked" by "bizarre delimiters". BTW: Now, when I
added syntax highlight of RExen to CPerl, I think that this complexity
went another notch down... I would not mind 2-3 more notches down,
but I have not seen any promising idea yet...)
Yours,
Ilya
------------------------------
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:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#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 2952
***************************************
