[31743] in Perl-Users-Digest
Perl-Users Digest, Issue: 3006 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sat Jun 26 16:09:24 2010
Date: Sat, 26 Jun 2010 13:09:09 -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 Sat, 26 Jun 2010 Volume: 11 Number: 3006
Today's topics:
Re: Accessing Web Site Files Questions <tadmc@seesig.invalid>
Re: Accessing Web Site Files Questions <RedGrittyBrick@SpamWeary.invalid>
Re: bulk flush input <jak@isp2dial.com>
Re: bulk flush input <derykus@gmail.com>
Re: bulk flush input <ben@morrow.me.uk>
Re: bulk flush input <tadmc@seesig.invalid>
Re: bulk flush input <hjp-usenet2@hjp.at>
Re: bulk flush input <jak@isp2dial.com>
Re: bulk flush input <rvtol+usenet@xs4all.nl>
Re: bulk flush input <jak@isp2dial.com>
Re: bulk flush input <ben@morrow.me.uk>
Re: bulk flush input <jak@isp2dial.com>
Re: bulk flush input <xhoster@gmail.com>
Re: bulk flush input <derykus@gmail.com>
Re: bulk flush input <jak@isp2dial.com>
Friendly (WAS: How to generate random number without re <jak@isp2dial.com>
Re: How to generate random number without replacement? (David Combs)
Re: How to generate random number without replacement? (David Combs)
Re: How to generate random number without replacement? (David Combs)
Re: How to generate random number without replacement? <hjp-usenet2@hjp.at>
Re: Proposing a new module: Parallel::Loops <4ux6as402@sneakemail.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sat, 26 Jun 2010 09:04:47 -0500
From: Tad McClellan <tadmc@seesig.invalid>
Subject: Re: Accessing Web Site Files Questions
Message-Id: <slrni2c1v8.pie.tadmc@tadbox.sbcglobal.net>
E.D.G. <edgrsprj@ix.netcom.com> wrote:
> Could someone list the correct Perl code to use for having a Perl program
> download and store or print a file from a Web site?
>
> I read all of the online documentation I could locate
How about not-online documentation?
Such as the documentation for the module that you are using.
> and tried various
> commands. However, error messages keep appearing that say that the Web
> hosts cannot be accessed etc.
Please post verbatim, not paraphrased, error messages, along with
the actual code that you ran to generate those error messages.
Have you seen the Posting Guidelines that are posted here frequently?
> This is a command that I tried for simply printing a text file to the
> monitor. (A real Web site address was used, not the one listed here.)
Why is the one listed here not a real website?
> use LWP::Simple;
perldoc LWP::Simple
has this as its first example:
perl -MLWP::Simple -e 'getprint "http://www.sn.no"'
That works fine for me.
Does that work for you?
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.liamg\100cm.j.dat/"
The above message is a Usenet post.
I don't recall having given anyone permission to use it on a Web site.
------------------------------
Date: Sat, 26 Jun 2010 19:33:57 +0100
From: RedGrittyBrick <RedGrittyBrick@SpamWeary.invalid>
Subject: Re: Accessing Web Site Files Questions
Message-Id: <Ta-dnd0wOoCH1bvRnZ2dnUVZ7tednZ2d@bt.com>
On 26/06/2010 15:04, Tad McClellan wrote:
> E.D.G.<edgrsprj@ix.netcom.com> wrote:
>
>
>> use LWP::Simple;
>
> perldoc LWP::Simple
>
> has this as its first example:
>
> perl -MLWP::Simple -e 'getprint "http://www.sn.no"'
>
> That works fine for me.
>
It probably wouldn't for E.D.G. because, as mentioned, he is using
ActiveState which means he is probably using Windows and needs to use a
different form of quoting:
perl -MLWP::Simple -e "getprint 'http://www.sn.no'"
If I recall correctly, the O.P. is liable to overlook this sort of
detail unless reminded explicitly.
Incorrect quoting may not be the cause of E.D.G's original problem of
course.
--
RGB
------------------------------
Date: Sat, 26 Jun 2010 13:48:22 +0000
From: John Kelly <jak@isp2dial.com>
Subject: Re: bulk flush input
Message-Id: <l30c26d3g5ljqaf3m9u7iqhfed8v5hji98@4ax.com>
On Sat, 26 Jun 2010 08:40:43 +0000 (UTC), Willem
<willem@turtle.stack.nl> wrote:
>John Kelly wrote:
><snip>
>)<> or die "1 EOF\n";
>)<> or die "2 EOF\n";
>)<> or die "3 EOF\n";
>)<> or die "4 EOF\n";
>)<> or die "5 EOF\n";
>)<> or die "6 EOF\n";
>)<> or die "7 EOF\n";
>)<> or die "8 EOF\n";
>)<> or die "9 EOF\n";
><snip>
>) produces output:
>)
>)>data="one"
>)>6 EOF
>)
>)
>) Which seems to prove that a bare <> is scalar context.
>
>No, it proves that the left-hand side of 'or' has scalar context.
Maybe. But when I do this:
><>;
><>;
><> or die "3 EOF\n";
><> or die "4 EOF\n";
><> or die "5 EOF\n";
><> or die "6 EOF\n";
><> or die "7 EOF\n";
><> or die "8 EOF\n";
><> or die "9 EOF\n";
The output is the same, showing the first two <> diamonds read only one
line each, thus proving a bare <> is NOT list context.
>I'm pretty sure that a bare <> has void context, (which usually
> translates to scalar context).
From ISBN 0-596-00027-8:
2.7.3. Void Context
Another peculiar kind of scalar context is the void context. This
context not only doesn't care what the return value's type is, it
doesn't even want a return value. From the standpoint of how functions
work, it's no different from an ordinary scalar context.
>It is really a lot faster to change the line separator.
Yes, but I coded this test to determine what a bare <> does.
>Setting it to \2048 means that it will always read that many bytes,
Right. That's what I decided to use, although 4096.
>and undef'ing it would mean it will read the whole rest of the file.
Which I do NOT want.
>I don't know if <> is smart enough to recognize void context though,
>can probably be tested with a large file and a memory checker tool.
No need for the big hammer, considering the text of 2.7.3, and my test
code.
--
Web mail, POP3, and SMTP
http://www.beewyz.com/freeaccounts.php
------------------------------
Date: Sat, 26 Jun 2010 06:58:00 -0700 (PDT)
From: "C.DeRykus" <derykus@gmail.com>
Subject: Re: bulk flush input
Message-Id: <dbbf3adf-0175-40a8-bb7f-88221f7f8242@x24g2000pro.googlegroups.com>
On Jun 26, 1:40=A0am, Willem <wil...@turtle.stack.nl> wrote:
> John Kelly wrote:
>
> <snip>
> )<> or die "1 EOF\n";
> )<> or die "2 EOF\n";
> )<> or die "3 EOF\n";
> )<> or die "4 EOF\n";
> )<> or die "5 EOF\n";
> )<> or die "6 EOF\n";
> )<> or die "7 EOF\n";
> )<> or die "8 EOF\n";
> )<> or die "9 EOF\n";
> <snip>
> ) produces output:
> )
> )>data=3D"one"
> )>6 EOF
> )
> )
> ) Which seems to prove that a bare <> is scalar context.
>
> No, it proves that the left-hand side of 'or' has scalar context.
>
> I'm pretty sure that a bare <> has void context, (which usually
> =A0translates to scalar context).
Yes, bare <> does have void context:
perl -we '$SIG{INT}=3Dsub{exit};undef $/; <> ; END{print}'
foo
bar
^CUse of uninitialized value in print at -e line 1.
whereas, with just scalar context:
perl -we '$SIG{INT}=3Dsub{exit};undef $/; 1 while <> ; END{print}'
foo
bar
^Cfoo
>
> It is really a lot faster to change the line separator.
> Setting it to \2048 means that it will always read that many bytes,
> and undef'ing it would mean it will read the whole rest of the file.
> I don't know if <> is smart enough to recognize void context though,
> can probably be tested with a large file and a memory checker tool.
>
So this'd be very fast.
undef $/;
<>;
Unfortunately, like () =3D <>, there's potentially
grave impact to a foot:
perl -we '@ARGV=3D("big.txt"); undef $/; <>'
Out of memory during "large" request ...
--
Charles DeRykus
------------------------------
Date: Sat, 26 Jun 2010 15:15:35 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: bulk flush input
Message-Id: <7lehf7-98l1.ln1@osiris.mauzo.dyndns.org>
Quoth "C.DeRykus" <derykus@gmail.com>:
>
> Yes, bare <> does have void context:
>
> perl -we '$SIG{INT}=sub{exit};undef $/; <> ; END{print}'
> foo
> bar
> ^CUse of uninitialized value in print at -e line 1.
>
> whereas, with just scalar context:
>
> perl -we '$SIG{INT}=sub{exit};undef $/; 1 while <> ; END{print}'
> foo
> bar
> ^Cfoo
That's not 'just scalar context'. <>-within-while is special-cased to
assign to $_ (and check 'defined', rather than simply truth). Try
perl -we '$SIG{INT}=sub{exit}; undef $/; $x = <>; END{print}'
Ben
------------------------------
Date: Sat, 26 Jun 2010 09:32:20 -0500
From: Tad McClellan <tadmc@seesig.invalid>
Subject: Re: bulk flush input
Message-Id: <slrni2c3is.png.tadmc@tadbox.sbcglobal.net>
John Kelly <jak@isp2dial.com> wrote:
> On Sat, 26 Jun 2010 08:40:43 +0000 (UTC), Willem
><willem@turtle.stack.nl> wrote:
>>John Kelly wrote:
>><>;
> The output is the same, showing the first two <> diamonds read only one
> line each, thus proving a bare <> is NOT list context.
There is no "bare" <>.
The <> in
<>;
is in a statement.
The statement provides the context for <> (or for whatever else is
in the stmt).
>>I'm pretty sure that a bare <> has void context, (which usually
^^^^^^^
^^^^^^^
>> translates to scalar context).
>
> From ISBN 0-596-00027-8:
What is ISBN 0-596-00027-8?
> 2.7.3. Void Context
> Another peculiar kind of scalar context is the void context. This
> context not only doesn't care what the return value's type is, it
> doesn't even want a return value. From the standpoint of how functions
> work, it's no different from an ordinary scalar context.
Why do you quote that?
That is, what point are you trying to make by quoting that?
I almost called Willem on the "usually" part, until I re-read
the "Context" section in
perldoc perldata
...
User-defined subroutines may choose to care whether they are being
called in a void, scalar, or list context.
void context always translates to scalar context for built-in functions.
void context usually translates to scalar context for user-defined functions.
So the nameless book you quote above is in error.
It should have qualified "functions":
From the standpoint of how built-in functions work, ...
> Yes, but I coded this test to determine what a bare <> does.
That's done easily enough with a simple one-liner:
bash-4.0$ perl -we '<>'
foo
bash-4.0$
Since the program exited after only one input line, then the
readline() must have been in scalar context, else it would have
waited for more input rather than exit()ing. As we can see with:
perl -we 'print <>'
Note that here print() provides the (list) context for <>, and that
the statement provides the (void) context for print().
>>I don't know if <> is smart enough to recognize void context though,
Since it is a built-in, void context is treated the same as scalar context.
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.liamg\100cm.j.dat/"
The above message is a Usenet post.
I don't recall having given anyone permission to use it on a Web site.
------------------------------
Date: Sat, 26 Jun 2010 16:43:00 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: bulk flush input
Message-Id: <slrni2c4fk.nj5.hjp-usenet2@hrunkner.hjp.at>
On 2010-06-26 14:32, Tad McClellan <tadmc@seesig.invalid> wrote:
> John Kelly <jak@isp2dial.com> wrote:
>> From ISBN 0-596-00027-8:
>
> What is ISBN 0-596-00027-8?
http://oreilly.com/catalog/9780596000271/
hp
------------------------------
Date: Sat, 26 Jun 2010 14:46:56 +0000
From: John Kelly <jak@isp2dial.com>
Subject: Re: bulk flush input
Message-Id: <r34c26hitriu9j7iakilc4qtu5u313rjph@4ax.com>
On Sat, 26 Jun 2010 09:32:20 -0500, Tad McClellan <tadmc@seesig.invalid>
wrote:
>John Kelly <jak@isp2dial.com> wrote:
>> On Sat, 26 Jun 2010 08:40:43 +0000 (UTC), Willem
>><willem@turtle.stack.nl> wrote:
>>>John Kelly wrote:
>
>>><>;
>
>> The output is the same, showing the first two <> diamonds read only one
>> line each, thus proving a bare <> is NOT list context.
>
>
>There is no "bare" <>.
>
>The <> in
>
> <>;
>
>is in a statement.
>
>The statement provides the context for <> (or for whatever else is
>in the stmt).
I meant "bare" without a while or foreach which forcibly provide
context.
>
>
>>>I'm pretty sure that a bare <> has void context, (which usually
> ^^^^^^^
> ^^^^^^^
>>> translates to scalar context).
>>
>> From ISBN 0-596-00027-8:
>
>
>What is ISBN 0-596-00027-8?
Programming Perl 3rd edition.
>
>
>> 2.7.3. Void Context
>> Another peculiar kind of scalar context is the void context. This
>> context not only doesn't care what the return value's type is, it
>> doesn't even want a return value. From the standpoint of how functions
>> work, it's no different from an ordinary scalar context.
>
>
>Why do you quote that?
>That is, what point are you trying to make by quoting that?
It says void context is a "kind of scalar context." So according to the
author, void == scalar for purposes of knowing whether <> reads one line
or many.
>
>I almost called Willem on the "usually" part, until I re-read
>the "Context" section in
>
> perldoc perldata
>
> ...
>
> User-defined subroutines may choose to care whether they are being
> called in a void, scalar, or list context.
>
>void context always translates to scalar context for built-in functions.
>
>void context usually translates to scalar context for user-defined functions.
>
>
>So the nameless book you quote above is in error.
I see it gets deep.
>It should have qualified "functions":
>
> From the standpoint of how built-in functions work, ...
>
>
>> Yes, but I coded this test to determine what a bare <> does.
>
>
>That's done easily enough with a simple one-liner:
>
>bash-4.0$ perl -we '<>'
>foo
>bash-4.0$
>
>Since the program exited after only one input line, then the
>readline() must have been in scalar context, else it would have
>waited for more input rather than exit()ing. As we can see with:
>
> perl -we 'print <>'
>
>Note that here print() provides the (list) context for <>, and that
>the statement provides the (void) context for print().
>
>
>>>I don't know if <> is smart enough to recognize void context though,
>Since it is a built-in, void context is treated the same as scalar context.
My stupid test verified that.
--
Web mail, POP3, and SMTP
http://www.beewyz.com/freeaccounts.php
------------------------------
Date: Sat, 26 Jun 2010 18:23:21 +0200
From: "Dr.Ruud" <rvtol+usenet@xs4all.nl>
Subject: Re: bulk flush input
Message-Id: <4c262979$0$22943$e4fe514c@news.xs4all.nl>
Ben Morrow wrote:
> my $data;
> while (<>) {
> chomp;
> length or next;
> $data = $_;
> last;
> }
> {
> local $/ = \2048;
> 1 while <>;
> }
This nicely keeps memory usage limited.
I always use 4096.
An alternative is to seek to the end:
seek STDIN, 0, SEEK_END;
<>;
--
Ruud
------------------------------
Date: Sat, 26 Jun 2010 16:57:52 +0000
From: John Kelly <jak@isp2dial.com>
Subject: Re: bulk flush input
Message-Id: <14bc26hm1r5jp13174fmbkf49ekgdv4l51@4ax.com>
On Sat, 26 Jun 2010 18:23:21 +0200, "Dr.Ruud" <rvtol+usenet@xs4all.nl>
wrote:
>Ben Morrow wrote:
>
>> my $data;
>> while (<>) {
>> chomp;
>> length or next;
>> $data = $_;
>> last;
>> }
>> {
>> local $/ = \2048;
>> 1 while <>;
>> }
>
>This nicely keeps memory usage limited.
>I always use 4096.
I decided to use 4096 too. I also replaced the "length" test with a
regex, to ignore lines containing only superfluous whitespace, prior to
the first line of data:
/^\s*$/ and next;
>An alternative is to seek to the end:
>
> seek STDIN, 0, SEEK_END;
> <>;
I posted, hoping for some magical Perl incantation. After all, there
are so many of them! But seek should be just as good. However, it also
needs a while loop that tests EOF.
Otherwise, the pipe writer could race with you, and write more data
after you seek, but before you read. Without a while loop testing for
EOF, you may falsely assume EOF, and close STDIN while the writer is
still sending more data, thus breaking the pipe.
--
Web mail, POP3, and SMTP
http://www.beewyz.com/freeaccounts.php
------------------------------
Date: Sat, 26 Jun 2010 19:07:48 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: bulk flush input
Message-Id: <k8shf7-hcn1.ln1@osiris.mauzo.dyndns.org>
Quoth John Kelly <jak@isp2dial.com>:
> On Sat, 26 Jun 2010 18:23:21 +0200, "Dr.Ruud" <rvtol+usenet@xs4all.nl>
> wrote:
>
> >An alternative is to seek to the end:
> >
> > seek STDIN, 0, SEEK_END;
> > <>;
>
> I posted, hoping for some magical Perl incantation. After all, there
> are so many of them! But seek should be just as good. However, it also
> needs a while loop that tests EOF.
>
> Otherwise, the pipe writer could race with you, and write more data
> after you seek, but before you read. Without a while loop testing for
> EOF, you may falsely assume EOF, and close STDIN while the writer is
> still sending more data, thus breaking the pipe.
Err... no. Pipes are not seekable, so the seek will simply fail. (Ruud
should have checked the return value of seek for exactly this reason.)
Ben
------------------------------
Date: Sat, 26 Jun 2010 18:42:50 +0000
From: John Kelly <jak@isp2dial.com>
Subject: Re: bulk flush input
Message-Id: <ccic26h8o2g6c2va7gm7ksm3112levjo85@4ax.com>
On Sat, 26 Jun 2010 19:07:48 +0100, Ben Morrow <ben@morrow.me.uk> wrote:
>Quoth John Kelly <jak@isp2dial.com>:
>> On Sat, 26 Jun 2010 18:23:21 +0200, "Dr.Ruud" <rvtol+usenet@xs4all.nl>
>> wrote:
>>
>> >An alternative is to seek to the end:
>> >
>> > seek STDIN, 0, SEEK_END;
>> > <>;
>>
>> I posted, hoping for some magical Perl incantation. After all, there
>> are so many of them! But seek should be just as good. However, it also
>> needs a while loop that tests EOF.
>Err... no. Pipes are not seekable, so the seek will simply fail. (Ruud
>should have checked the return value of seek for exactly this reason.)
I see there's no rabbit in that hat:
>man lseek
>ERRORS
> EBADF fd is not an open file descriptor.
>
> EINVAL whence is not one of SEEK_SET, SEEK_CUR, SEEK_END; or the
> resulting file offset would be negative, or beyond the end of a
> seekable device.
>
> EOVERFLOW
> The resulting file offset cannot be represented in an off_t.
>
> ESPIPE fd is associated with a pipe, socket, or FIFO.
>
It was too good to be true. What was I thinking ...
--
Web mail, POP3, and SMTP
http://www.beewyz.com/freeaccounts.php
------------------------------
Date: Sat, 26 Jun 2010 12:14:50 -0700
From: Xho Jingleheimerschmidt <xhoster@gmail.com>
Subject: Re: bulk flush input
Message-Id: <4c265446$0$11514$ed362ca5@nr5-q3a.newsreader.com>
John Kelly wrote:
> On Sat, 26 Jun 2010 18:23:21 +0200, "Dr.Ruud" <rvtol+usenet@xs4all.nl>
> wrote:
>
>> An alternative is to seek to the end:
>>
>> seek STDIN, 0, SEEK_END;
>> <>;
>
> I posted, hoping for some magical Perl incantation. After all, there
> are so many of them! But seek should be just as good. However, it also
> needs a while loop that tests EOF.
On my system it just doesn't work at all, setting $! to "Illegal seek".
> Otherwise, the pipe writer could race with you, and write more data
> after you seek, but before you read. Without a while loop testing for
> EOF, you may falsely assume EOF, and close STDIN while the writer is
> still sending more data, thus breaking the pipe.
But a broken pipe needn't be a problem. It is merely a condition, not
an error, unless the program decides to turn it into an error. Can you
instruct the other end of the pipe to just behave gracefully on SIGPIPE?
(Alas, bzcat can't be so instructed, as far as I can determine.) This
would be the ultimate in efficiency.
Xho
------------------------------
Date: Sat, 26 Jun 2010 12:32:34 -0700 (PDT)
From: "C.DeRykus" <derykus@gmail.com>
Subject: Re: bulk flush input
Message-Id: <0eb4bdd1-c9bc-4ce8-8adc-33918cc961b9@l25g2000prn.googlegroups.com>
On Jun 26, 7:15=A0am, Ben Morrow <b...@morrow.me.uk> wrote:
> Quoth "C.DeRykus" <dery...@gmail.com>:
>
>
>
> ...
> > whereas, with just scalar context:
>
> > =A0 perl -we '$SIG{INT}=3Dsub{exit};undef $/; 1 while <> ; END{print}'
> > =A0 foo
> > =A0 bar
> > =A0 ^Cfoo
>
> That's not 'just scalar context'. <>-within-while is special-cased to
> assign to $_ (and check 'defined', rather than simply truth). Try
>
> =A0 =A0 perl -we '$SIG{INT}=3Dsub{exit}; undef $/; $x =3D <>; END{print}'
>
Yes, there's more magic to it than "just" implies but
the special-casing does include an assignment to $_
in scalar context.
--
Charles DeRykus
------------------------------
Date: Sat, 26 Jun 2010 19:44:45 +0000
From: John Kelly <jak@isp2dial.com>
Subject: Re: bulk flush input
Message-Id: <vmlc26lofttqbc1d5p39aj6fbdn73tiag0@4ax.com>
On Sat, 26 Jun 2010 12:14:50 -0700, Xho Jingleheimerschmidt
<xhoster@gmail.com> wrote:
>But a broken pipe needn't be a problem. It is merely a condition, not
>an error, unless the program decides to turn it into an error.
I prefer using:
set -e -u -o pipefail
in my bash scripts.
>instruct the other end of the pipe to just behave gracefully on SIGPIPE?
To me it's like compiling with -Wall -Werror. I just do it, and fix
the warnings. I feel better knowing (or at least thinking) that my code
is clean, not sloppy.
>(Alas, bzcat can't be so instructed, as far as I can determine.) This
>would be the ultimate in efficiency.
--
Web mail, POP3, and SMTP
http://www.beewyz.com/freeaccounts.php
------------------------------
Date: Sat, 26 Jun 2010 19:33:39 +0000
From: John Kelly <jak@isp2dial.com>
Subject: Friendly (WAS: How to generate random number without replacement?)
Message-Id: <lhjc26hesqac99h4s1a0vrisg3cbnapn0h@4ax.com>
On Tue, 01 Jun 2010 08:41:53 -0500, John Bokma <john@castleamber.com>
wrote:
>"Peter J. Holzer" <hjp-usenet2@hjp.at> writes:
>
>> On 2010-06-01 08:50, Uri Guttman <uri@StemSystems.com> wrote:
>>>>>>>> "PY" == Peng Yu <pengyu.ut@gmail.com> writes:
>>> PY> What do you mean? I didn't ask you to tell me again.
>>>
>>> i told you how to do it. either you didn't read it or you didn't get the
>>> solution.
>>
>> Uri, nobody asked you to tell him again.
>
>It's exactly this Ogrish behavior of a few regulars that makes this
>place such a pain in the ass. :-(.
>Luckily for the newbies there are sites like stackoverflow.com where at
>least they can vote down such behaviour.
I hate web forum interfaces.
>Again: Dear regular, you /don't have to post/.
Without grumpy old men, what would Usenet be?
Seriously, though, some of us wear many hats and don't have time to
become expert in a tool like Perl. So we wander in and out of various
newsgroups as the need or interest arises.
As for me, I was working on a local problem and found a good solution
using UNIX datagram sockets. It was something I had never used before,
so it took me a while to figure things out and put the pieces together
into a working solution. In the process, I noticed it was hard to find
good *working* examples of UNIX datagram socket code. Since I coded my
solution in Perl I thought why not post it. Maybe no one else needs it,
but if only one person does, it could save them time.
So along trot I, an unknown, into c.l.p.m, and post my news. And what
is the first reply I see? WHO THE HELL ARE YOU AND WHAT ARE YOU DOING
HERE? That's what it felt like anyway.
Some newsgroups suffer from the presence of territorial control freaks.
In one, a particular individual has been obsessed with some of my posts,
to the point of stalking. So if I overreacted upon my arrival here, I
apologize to anyone offended. Except for the stalker. :-(
--
Web mail, POP3, and SMTP
http://www.beewyz.com/freeaccounts.php
------------------------------
Date: Sat, 26 Jun 2010 17:50:55 +0000 (UTC)
From: dkcombs@panix.com (David Combs)
Subject: Re: How to generate random number without replacement?
Message-Id: <i05elu$1kt$1@reader1.panix.com>
I see it differently.
He's got every right to get pissed off from time to time.
How many hours a week does he sit in front of the terminal
answering questions for us (when he could be making money,
presumably, a nice sacrifice for us all!) and after a while
of being eaten by "I have to get back to WORK sometime --
so I can pay some BILLS" or whatever else might be eating
him now and then, that almost it doesn't matter WHAT the
next question is, the least perceived-foolishness/stupidity
in it will elicit a ROAR and accompanying dragon-mouth FLAME
BLAST.
That done, he bypasses a few questions he might have liked
answering, and he's back to his nice helpful self, again
answering hairy questions.
So thank you, Uri, for being there!
David
------------------------------
Date: Sat, 26 Jun 2010 17:56:16 +0000 (UTC)
From: dkcombs@panix.com (David Combs)
Subject: Re: How to generate random number without replacement?
Message-Id: <i05f00$1kt$2@reader1.panix.com>
In article <87ocfuk0ht.fsf@quad.sysarch.com>,
Uri Guttman <uri@StemSystems.com> wrote:
>>>>>> "TZ" == Ted Zlatanov <tzz@lifelogs.com> writes:
>
> TZ> On Tue, 01 Jun 2010 04:50:36 -0400 "Uri Guttman" <uri@StemSystems.com> wrote:
> UG> my %seen ;
> UG> while( 1 ) { $x = int rand( 100_000_000 ) ; $seen{$x} and next ;
> UG> $seen{$x} = 1; print $x }
>
> TZ> This will grow pretty quickly with a hash. Bit::Vector already has
> TZ> Bit_On($index) and bit_test($index) so memory usage and probably
> TZ> performance will be a bit (heh) better.
>
>he said he wanted 1k random numbers out of a large range so a hash would
>be fine for that.
>
>uri
>
>--
>Uri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com --
>----- Perl Code Review , Architecture, Development, Training, Support ------
>--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
WERE this to be a cpan module, maybe a mix would be nice. Bit vector for
the first N of them, N of course requiring N/8 bytes preallocated probably,
and for > N, the hash scheme?
David
------------------------------
Date: Sat, 26 Jun 2010 18:05:52 +0000 (UTC)
From: dkcombs@panix.com (David Combs)
Subject: Re: How to generate random number without replacement?
Message-Id: <i05fhv$1kt$3@reader1.panix.com>
In article <87y6exwo6o.fsf@lifelogs.com>,
Ted Zlatanov <tzz@lifelogs.com> wrote:
>On Tue, 01 Jun 2010 20:54:29 -0700 Xho Jingleheimerschmidt <xhoster@gmail.com> wrote:
>
>XJ> Ted Zlatanov wrote:
>>> On Tue, 01 Jun 2010 04:50:36 -0400 "Uri Guttman"
>>> <uri@StemSystems.com> wrote:
>>>
>UG> my %seen ;
>UG> while( 1 ) { $x = int rand( 100_000_000 ) ; $seen{$x} and next ;
>UG> $seen{$x} = 1; print $x }
>>>
>>> This will grow pretty quickly with a hash. Bit::Vector already has
>>> Bit_On($index) and bit_test($index) so memory usage and probably
>>> performance will be a bit (heh) better.
>
>XJ> I'd be very surprised if Bit::Vector had faster performance, at least
>XJ> until the other method started swapping.
>
>It's C internally so performance is pretty good. But you're probably
>right anyhow, I wasn't thinking.
>
>On Tue, 01 Jun 2010 15:37:34 -0400 "Uri Guttman" <uri@StemSystems.com> wrote:
>
>UG> he said he wanted 1k random numbers out of a large range so a hash would
>UG> be fine for that.
>
>You're right, I wasn't paying enough attention.
>
>Ted
What, you're saying a div and a mod (let's assume 64 bits, if integet) to
find the desired bit, versus dealing each time with a hash bucket to choose
an ensuing chain to hunt down through?
So you make the bucket-array longer, so the chains are short -- get it
long enough so only very, very few chains are longer than one (most
being zero) in length, and you're almost emulating the bit-vector
scheme, but taking up FAR FAR more space.
?
David
------------------------------
Date: Sat, 26 Jun 2010 21:02:19 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: How to generate random number without replacement?
Message-Id: <slrni2cjlr.c5l.hjp-usenet2@hrunkner.hjp.at>
On 2010-06-26 18:05, David Combs <dkcombs@panix.com> wrote:
> In article <87y6exwo6o.fsf@lifelogs.com>,
> Ted Zlatanov <tzz@lifelogs.com> wrote:
>>On Tue, 01 Jun 2010 15:37:34 -0400 "Uri Guttman" <uri@StemSystems.com> wrote:
>>
>>UG> he said he wanted 1k random numbers out of a large range so a hash would
>>UG> be fine for that.
>>
>>You're right, I wasn't paying enough attention.
>
> What, you're saying a div and a mod (let's assume 64 bits, if integet) to
> find the desired bit, versus dealing each time with a hash bucket to choose
> an ensuing chain to hunt down through?
>
> So you make the bucket-array longer, so the chains are short -- get it
> long enough so only very, very few chains are longer than one (most
> being zero) in length, and you're almost emulating the bit-vector
> scheme, but taking up FAR FAR more space.
No, for the use case given (1k random numbers out of a large range) a
hash takes *less* space.
The bit vector takes (max-min)/8 bytes. So for 0 .. 100_000_000 it takes
approximately 12.5 MB. 1000 hash entries take (depending on pointer
size, malloc implementation, etc.) something like 60 to 150 kB. So
that's about 1/100th of the space. I'd still think a bit vector should
be faster.
hp
------------------------------
Date: Sat, 26 Jun 2010 12:25:32 -0700 (PDT)
From: =?ISO-8859-1?Q?Peter_Valdemar_M=F8rch?= <4ux6as402@sneakemail.com>
Subject: Re: Proposing a new module: Parallel::Loops
Message-Id: <6857c2c2-c744-4496-91ac-297bca3321ca@d8g2000yqf.googlegroups.com>
Commenting on Ben's post out of order:
> > $pl->async {
> > bla_bla_bla();
> > }
> > This syntax could easily co-exist with the $pl->foreach and $pl->while
> > syntax.
>
> Not like that it can't, since methods don't have prototypes.
...
> If you want a method call it would have to look like
>
> $pl->async(sub { ... });
Yes you're right, of course.
> > I'm worried though that people will forget to call $pl->joinAll()!
>
> Stick it in DESTROY.
I don't see how that would help. I'm thinking of a user writing
something like:
$pl->share(\%results);
foreach (0..4) {
$pl->async(sub { $results{$_} = foobar($_) } );
}
$pl->joinAll();
useResults(\%results);
In this case, at the time of the call to useResults, %results will
contain the finished results from all forked processes because $pl-
>joinAll() waits for them all to finish. If $pl->joinAll() doesn't get
called, the user will most likely see an empty %results. I don't see
how DESTROY comes in to play here or could help.
> They're not global. %output can be scoped as tightly as you like around
> the async call: async takes a closure, so it will make available (either
> shared or as copies) any lexicals in scope at the time. (This is why $_
> won't work: it isn't a lexical.)
I think I haven't made my concern clear. Is it possible to do:
my %resultsForCalc1 : Shared($pl1);
and have the sharing associated with a particular Parallel::Loops
instance (so my attribute handler gets a reference to $pl1, not the
string '$pl1')?
If so, cool. Don't read any further, I'm satisified (BTW, How?). If
not, lets say one does this:
my %resultsForCalc1 : Shared;
my $pl1 = Parallel::Loops->new(4);
$pl1->foreach([0..9], sub {
$resultsForCalc11{$_} = doSomething($_);
}
useResults(\%resultsForCalc1);
# Block above duplicated, just s/1/2/g
my %resultsForCalc2 : Shared;
my $pl2 = Parallel::Loops->new(4);
$pl1->foreach([0..9], sub {
$resultsForCalc12{$_} = doSomething($_);
}
useResults(\%resultsForCalc1);
Wouldn't the list ( \%resultsForCalc1, \%resultsForCalc2 ) have to be
global? How would I/perl keep track of that the user only wants to
share %resultsForCalc1 in the first calculation and only
%resultsForCalc2 in the second?
By the way, how would one avoid that %foo gets handled as shared in
the following case, since it has gone out of scope?
{
my %foo : Shared;
}
my %resultsForCalc1 : Shared;
my $pl1 = Parallel::Loops->new(4);
$pl1->foreach([0..9], sub {
$resultsForCalc11{$_} = doSomething($_);
}
useResults(\%resultsForCalc1);
I don't (yet?) see how I can detect which of the hashes with the
"Shared" attribute that are in scope at the time of the $pl1-
>foreach() call.
But even if I could detect which of all the shared hashes that were in
scope "now", that may not be what the user wants. There could be other
reasons that the user wants %resultsForCalc1 (from way above) in an
outer scope and not have it shared in some of the calculations where
it happens to be in scope.
Perhaps we're getting a little off-topic here, but now I'm curious
about the attributes business! ;-)
Peter
------------------------------
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 3006
***************************************
