[29949] in Perl-Users-Digest
Perl-Users Digest, Issue: 1192 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Jan 14 00:09:43 2008
Date: Sun, 13 Jan 2008 21:09: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 Sun, 13 Jan 2008 Volume: 11 Number: 1192
Today's topics:
Re: Active State perl for windows not working. <john@castleamber.com>
Re: Converting milliseconds to seconds <t.x.michaels@gmail.com>
Re: Converting milliseconds to seconds <joost@zeekat.nl>
Re: Converting milliseconds to seconds <joost@zeekat.nl>
Re: Converting milliseconds to seconds <t.x.michaels@gmail.com>
Re: Converting milliseconds to seconds <joost@zeekat.nl>
Re: Converting milliseconds to seconds <nospam-abuse@ilyaz.org>
Re: looking for efficient way to parse a file <emartin24@gmail.com>
Re: Simple "rm -rf"? <bernie@fantasyfarm.com>
Re: Simple "rm -rf"? <bernie@fantasyfarm.com>
Wait for background processes to complete <pgodfrin@gmail.com>
Re: Wait for background processes to complete xhoster@gmail.com
Re: Wait for background processes to complete <ben@morrow.me.uk>
Re: Why does undef->{id} give a warning and $undefined_ himanshu.garg@gmail.com
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 13 Jan 2008 16:23:44 GMT
From: John Bokma <john@castleamber.com>
Subject: Re: Active State perl for windows not working.
Message-Id: <Xns9A2469BFA554Ecastleamber@130.133.1.4>
"Gerry Ford" <invalid@invalid.net> wrote:
> I disagree that spam, garbage or republicans come from others' Perl
> bin. Spam comes from England,
If you mean the stuff made by Hormel, that's SPAM(TM).
--
John
http://johnbokma.com/mexit/
------------------------------
Date: Sun, 13 Jan 2008 15:10:17 -0800 (PST)
From: magoo <t.x.michaels@gmail.com>
Subject: Re: Converting milliseconds to seconds
Message-Id: <988529ea-0f90-4c33-a324-89a071bef5bc@v4g2000hsf.googlegroups.com>
Ilya,
Thank you for sharing your hard-won information.
It is much appreciated by myself and certainly by others who may not
explicitly say so.
It is still amazing to me to hear of round-off errors and is a
reminder to all to be on guard
when computing numeric results. Experts as well as novices can be
bitten by these evil bugs when
they least expect it.
Thanks again for sharing your knowledge with the rest of us.
T. Michaels
------------------------------
Date: Mon, 14 Jan 2008 01:40:36 +0100
From: Joost Diepenmaat <joost@zeekat.nl>
Subject: Re: Converting milliseconds to seconds
Message-Id: <87r6glgry3.fsf@zeekat.nl>
magoo <t.x.michaels@gmail.com> writes:
> Ilya,
>
> Thank you for sharing your hard-won information.
>
> It is much appreciated by myself and certainly by others who may not
> explicitly say so.
>
> It is still amazing to me to hear of round-off errors and is a
> reminder to all to be on guard
> when computing numeric results. Experts as well as novices can be
> bitten by these evil bugs when
> they least expect it.
While I suspect your post is sarcastic, I do think it's wise to point
out that many people - some even experienced programmers - have a
simplistic (which is to say *wrong*) view of what happens when floating
point numbers are represented in binary (which is what's used by
default in most if not all commerically available computers today).
The basic point is: there are many fractional numbers that can be
notated without errors in decimal (like 0.1) which *cannot* be represented
correctly in the finite binary floating point notation used by most
CPUs, in the same way that 1/3 cannot be notated in a finite decimal
floating point (i.e. 1.3333333..., which by the way can't be correctly
represented in binary either).
This means that some floating point numbers that we tend to think of as
"easy and finite" because of our familiarity with the decimal notation
are not in fact finite to the processor that happens to run the
calculation. Which leads to errors in the result where you may not
expect to find any.
Most languages that go for performance see this as an acceptable
trade-off, at least by default, and perl is one of those languages.
Anyway, all this means that blindly truncating floats (i.e, using int())
to "round down" *will* result in errors. In fact, all rounding
will. We just have a more acute sense of the error when 0.999999999
gets rounded down to 0. To avoid that, use (s)printf to use a more
appropriate rounding rule.
Also note that on my machine at least, sprintf uses "banker's rounding",
which IMHO is a good choice, but can also confuse matters even further.
See also:
http://en.wikipedia.org/wiki/Floating_point
http://en.wikipedia.org/wiki/Banker%27s_rounding
Hope this helps someone at least,
Joost.
------------------------------
Date: Mon, 14 Jan 2008 01:42:54 +0100
From: Joost Diepenmaat <joost@zeekat.nl>
Subject: Re: Converting milliseconds to seconds
Message-Id: <87myr9gru9.fsf@zeekat.nl>
Joost Diepenmaat <joost@zeekat.nl> writes:
> CPUs, in the same way that 1/3 cannot be notated in a finite decimal
> floating point (i.e. 1.3333333..., which by the way can't be correctly
> represented in binary either).
I meant 0.33333333....
Man, these numbers are confusing!
Joost
------------------------------
Date: Sun, 13 Jan 2008 17:24:49 -0800 (PST)
From: magoo <t.x.michaels@gmail.com>
Subject: Re: Converting milliseconds to seconds
Message-Id: <520c0406-7a29-4ed1-bd1e-5d51dad85e4c@d21g2000prf.googlegroups.com>
Joost,
My post was in no way intended to be sarcastic.
It was my intention only to thank Ilya (for whom I have nothing
but admiration and respect)
for sharing with us the information he did.
How many of us could have written about our own mistakes in a
public forum, with the good
intention of helping others? Not many I suspect, I for one do not
like to publicize my mistakes.
Your post was informative as well, and added more information to
the discussion which is a good
thing. The earlier discussion seemed to be getting bogged down and
headed nowhere.
As you say, numbers and especially their computer representation,
can get confusing!
Best regards,
T. Michaels
On Jan 13, 7:42 pm, Joost Diepenmaat <jo...@zeekat.nl> wrote:
> Joost Diepenmaat <jo...@zeekat.nl> writes:
> > CPUs, in the same way that 1/3 cannot be notated in a finite decimal
> > floating point (i.e. 1.3333333..., which by the way can't be correctly
> > represented in binary either).
>
> I meant 0.33333333....
>
> Man, these numbers are confusing!
>
> Joost
------------------------------
Date: Mon, 14 Jan 2008 04:13:05 +0100
From: Joost Diepenmaat <joost@zeekat.nl>
Subject: Re: Converting milliseconds to seconds
Message-Id: <87ir1xgkvy.fsf@zeekat.nl>
magoo <t.x.michaels@gmail.com> writes:
> Joost,
>
> My post was in no way intended to be sarcastic.
>
> It was my intention only to thank Ilya (for whom I have nothing
> but admiration and respect)
> for sharing with us the information he did.
I think he was taking an obviously wrong-headed view of what it was that
was causing the problem, though maybe it could have been explained a bit
clearer to him in this thread.
Anyway, as I said, confusion with regards to floats are common and I don't
blame him or anyone else who makes that mistake.
I also think that perl's documentation could at least include a few (more?)
pointers to explain the issues with floating point representation.
Where I do have a problem is when Ilya claims, quite vehemently, that
this is some sort of bug in perl, while it is purely due to the
inherent inaccuracies in the processor and/or C library that happens to
implement floating point semantics, which you will *have* to learn to
deal with when programming with floats in most any language. In other
words: unless the language you're using is explicitly documented to use
decimal notation for floating points on the platform you're using you
should assume it cannot represent all finite decimal floats, and could
be off in any direction by some amount. Because that is the case for most
languages and processors in use today.
Joost.
------------------------------
Date: Mon, 14 Jan 2008 03:22:01 +0000 (UTC)
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: Converting milliseconds to seconds
Message-Id: <fmekgp$e4t$1@agate.berkeley.edu>
[A complimentary Cc of this posting was NOT [per weedlist] sent to
Ilya Zakharevich
<nospam-abuse@ilyaz.org>], who wrote in article <fmciie$2svu$1@agate.berkeley.edu>:
> > As I said: you are greatly mistaken about the intended semantic of int().
> > You may want to read the documentation for clarification.
> As I said, the existing state of documentation of Perl is, at most,
> pitiful. (If you still do not realize this, I wrote some
> [significant?] part of implementation of Perl's int(). *This* is why
> I feel so hurt by this bug of mine. ;-)
Thinking about it more, this illusion of grandeur may be a piece of my
imagination ;-). I remember a lot of struggle to make int() and "%"
conformant to `perldoc perlnumber'; I definitely implemented at least
one of these - but I do not remember which.
Sorry,
Ilya
------------------------------
Date: Sun, 13 Jan 2008 07:46:26 -0800 (PST)
From: Eric Martin <emartin24@gmail.com>
Subject: Re: looking for efficient way to parse a file
Message-Id: <5b323c9d-78b3-4141-a6f9-a7eb88ab7397@e10g2000prf.googlegroups.com>
On Jan 12, 2:59 pm, Gunnar Hjalmarsson <nore...@gunnar.cc> wrote:
> Eric Martin wrote:
> > I have a file with the following data structure:
> > #category
> > item name
> > data1
> > data2
> > item name
> > data1
> > data2
> > #category
> > item name
> > data1
> > data2
> > ... etc.
>
> > Any line that starts with #, indicates a new category. Between
> > categories, there can be any number of items, with associated data.
> > Each item has exactly two data properties.
>
> > My plan was to just get an array that contained the index of each of
> > the categories and then parse each item from there, since they are in
> > a set format...
>
> Not sure what you mean by that. Could you please expand?
I was thinking of loading the file into an array, iterating over it to
find the index values for each category, then parsing the data between
each category, using the array of indexes I previously created.
However, your suggestion to use a HoHoA and code sample, proved to be
exactly what I needed.
>
> > but I was wondering if there were any suggestions for a
> > more efficient way...
>
> Efficient - in what sense?
I probably should have said effective ;)
>
> To me, the described data structure would suggest a HoHoA (hash of
> hashes of arrays):
>
> use Data::Dumper;
>
> my (%HoHoA, $cat);
> while ( <DATA> ) {
> chomp;
> if ( substr($_, 0, 1) eq '#' ) {
> $cat = substr $_, 1;
> next;
> }
> for my $item ( 0, 1 ) {
> chomp( $HoHoA{$cat}{$_}[$item] = <DATA> );
> }}
>
> print Dumper \%HoHoA;
>
> __DATA__
> #category1
> item1
> data1
> data2
> item2
> data1
> data2
> #category2
> item1
> data1
> data2
>
> --
> Gunnar Hjalmarsson
> Email:http://www.gunnar.cc/cgi-bin/contact.pl
Thanks for the code sample, it worked great! I didn't realize
referencing <DATA> in the while block would "increment" the record of
the data file.
-Eric
------------------------------
Date: Sun, 13 Jan 2008 10:32:59 -0500
From: Bernie Cosell <bernie@fantasyfarm.com>
Subject: Re: Simple "rm -rf"?
Message-Id: <esako318qi9479ihg3f14tvag435k9r9uf@library.airnews.net>
Abigail <abigail@abigail.be> wrote:
} Bernie Cosell (bernie@fantasyfarm.com) wrote on VCCXLVII September
} MCMXCIII in <URL:news:r3iho3psrttro1d7vpdoup8ct9nrfoij4f@library.airnews.net>:
} ?? I want to nuke a temp directory. The very simplest way to do it is
} ?? system("rm", "-rf", TEMPDIR), but I'm wondering if there's a perlish way to
} ?? do it that'd be about as easy.
} Considering that Perl is a glue language, calling a tool to do the job
} is a VERY Perlish way to accomplish your goals.
}
} system rm => "-rf", TEMPDIR
}
} takes just one line.
I agree. I didn't mention it in the post, but I've been doing some Windows
perling recently and that's what got me thinking about it -- I wondered
*IF* [just speculating] just how much addition trouble it'd be to clean up
that temp directory *IF* I happened to need to port the pgm to Windows. For
now, of course, on Unix, just leaving the 'system' in works just fine. [in
a similar vein, I've gotten more careful about avoiding MySQL
"convenienices" and trying to go with "standard' SQL, just in case [again,
only "IF"..:o)] we changed to a different backend database].
/Bernie\
--
Bernie Cosell Fantasy Farm Fibers
bernie@fantasyfarm.com Pearisburg, VA
--> Too many people, too few sheep <--
------------------------------
Date: Sun, 13 Jan 2008 10:33:03 -0500
From: Bernie Cosell <bernie@fantasyfarm.com>
Subject: Re: Simple "rm -rf"?
Message-Id: <ebbko3tu24c82vgmkqnog7kjba0lssds6j@library.airnews.net>
Peter Scott <Peter@PSDT.com> wrote:
} On Sat, 12 Jan 2008 09:04:56 -0500, Bernie Cosell wrote:
} > I want to nuke a temp directory. The very simplest way to do it is
} > system("rm", "-rf", TEMPDIR), but I'm wondering if there's a perlish way to
} > do it that'd be about as easy....
}
} If your program creates the directory to begin with, consider using
} File::Temp:
}
} $tempdir = tempdir( $template, CLEANUP => 1);
Very cool: I didn't know about that! But even more to the point, poking
around in the ::Temp code revealed that File::Path has a rmtree() function
that does exactly what I was looking for [and I peeked at the code and
doing the nuking portably is quite an adventure!] Thanks for the
pointer...
/Bernie\
--
Bernie Cosell Fantasy Farm Fibers
bernie@fantasyfarm.com Pearisburg, VA
--> Too many people, too few sheep <--
------------------------------
Date: Sun, 13 Jan 2008 19:08:01 -0800 (PST)
From: pgodfrin <pgodfrin@gmail.com>
Subject: Wait for background processes to complete
Message-Id: <7d5664d6-7526-43d7-8562-fc32e2a85e62@e25g2000prg.googlegroups.com>
Greetings,
Well - I've spent a bunch of time trying to figure this out - to no
avail.
Here's what I want to do - run several commands in the background and
have the perl program wait for the commands to complete. Fork doesn't
do it, nor does wait nor waitpid.
Any thoughts?
Here's a sample program which starts the processes:
while (<*.txt>)
{
print "Copying $_ \n";
system("cp $_ $_.old &") ;
}
print "End of excercise\n";
exit;
I mean if this were a shell program - this would work:
for x in `ls *.txt`
do
print "Copying $_ \n"
cp $_ $_.old &
done
wait
thanks,
pg
------------------------------
Date: 14 Jan 2008 03:43:33 GMT
From: xhoster@gmail.com
Subject: Re: Wait for background processes to complete
Message-Id: <20080113224337.431$3B@newsreader.com>
pgodfrin <pgodfrin@gmail.com> wrote:
> Greetings,
> Well - I've spent a bunch of time trying to figure this out - to no
> avail.
>
> Here's what I want to do - run several commands in the background and
> have the perl program wait for the commands to complete. Fork doesn't
> do it, nor does wait nor waitpid.
None of them individually do it, no. You have to use them together.
>
> Any thoughts?
>
> Here's a sample program which starts the processes:
>
> while (<*.txt>)
> {
> print "Copying $_ \n";
> system("cp $_ $_.old &") ;
This starts a shell, which then starts cp in the background. As soon as
the cp is *started*, the shell exits. So Perl has nothing to wait for, as
the shell is already done (and waited for) before system returns. You need
to use fork and system or fork and exec. Or you could use
Parallel::ForkManager, which will wrap this stuff up nicely for you and
also prevent you from fork-bombing your computer if there are thousands of
*.txt
> }
> print "End of excercise\n";
> exit;
1 until -1==wait(); # on my system, yours may differ
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: Mon, 14 Jan 2008 03:51:38 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Wait for background processes to complete
Message-Id: <ar2r55-3ih1.ln1@osiris.mauzo.dyndns.org>
Quoth pgodfrin <pgodfrin@gmail.com>:
>
> Here's what I want to do - run several commands in the background and
> have the perl program wait for the commands to complete. Fork doesn't
> do it, nor does wait nor waitpid.
>
> Any thoughts?
>
> Here's a sample program which starts the processes:
>
> while (<*.txt>)
> {
> print "Copying $_ \n";
> system("cp $_ $_.old &") ;
This string contains a shell metachar (&), so system will fork a shell
and wait for it. The shell will run cp in the background, and then exit,
at which point system will return. Unfortunately, the only process which
knew cp's pid was the shell, which has just exitted, so you can't wait
for that process at all (cp now has init as its parent, like any other
orphaned process).
You need to either implement the behaviour you want with fork, exec and
waitpid (it's a little complicated, but entirely possible) or use
IPC::Run, something like
use IPC::Run qw/run/;
my @cmds;
while (<*.txt>) {
print "Copying $_\n";
push @cmds, [cp => $_, "$_.old"];
}
run map { ($_, '&') } @cmds;
This is also safer than system STRING in the case where your filenames
have funny characters in them.
> }
> print "End of excercise\n";
> exit;
Falling off the end is a perfectly valid way to end a Perl program. exit
is usually reserved for exceptional circumstances.
> I mean if this were a shell program - this would work:
>
> for x in `ls *.txt`
> do
> print "Copying $_ \n"
> cp $_ $_.old &
> done
> wait
This works because the shell implements '&' directly, rather than using
a different shell, so it can remember the pids to wait for itself.
Ben
------------------------------
Date: Sun, 13 Jan 2008 06:34:28 -0800 (PST)
From: himanshu.garg@gmail.com
Subject: Re: Why does undef->{id} give a warning and $undefined_var->{id} doesn't
Message-Id: <0344c0bd-d38e-46ea-b789-e83adc21233c@s12g2000prg.googlegroups.com>
On Jan 4, 9:56 am, Ivan Novick <i...@0x4849.net> wrote:
> On Jan 3, 1:00 am,himanshu.g...@gmail.com wrote:
>
> > % cat test.pl
> > use Test::Simple tests => 2;
> > use strict;
> > my $undefined_var;
> > ok(!$undefined_var->{id}, '!$undefined_var->{id}');
> > ok(!undef->{id}, '!undef->{id}')
>
> > % perl test.pl
> > 1..2
> > ok 1 - !$request->{id}
> > Can't use an undefined value as a HASH reference at test.pl line 5.
> > # Looks like you planned 2 tests but only ran 1.
> > # Looks like your test died just after 1.
>
> Try running this code:
>
> ###########################
> use strict;
> my $x = undef;
> print "$x\n";
> $x->{id} = 3;
> print "$x\n";
> ###########################
>
> You will see $x starts as undefined but perl will create a hash when
> you try to assign something to a $x->{id}. As Tad, said, they call
> that autovivification which means "to bring oneself to life".
>
> The second time you print $x it has a memory address.
>
> You can not do the same by directly using undef as the address of a
> hash because that is not a scalar variable that can hold the address
> of a created hash and thus its illegal syntax.
>
> Regards,
> Ivan Novickhttp://www.0x4849.net
Yes,
Got it now. Couldn't have been explained better.
Thank You,
Himanshu.
------------------------------
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 1192
***************************************
