Re: RFC195: Do not remove 'chop' PLEASE!
On Sun, Jan 28, 2001 at 04:28:08PM +0100, [EMAIL PROTECTED] wrote: Aliasing again. They keys are copies, the values aliases. How bizarre? Why does it work that way? -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ "None of our men are "experts."... because no one ever considers himself expert if he really knows his job." -- From Henry Ford Sr., "My Life and Work," p. 86 (1922):
Re: RFC195: Do not remove 'chop' PLEASE!
"MGS" == Michael G Schwern [EMAIL PROTECTED] writes: MGS On Sun, Jan 28, 2001 at 04:28:08PM +0100, [EMAIL PROTECTED] wrote: Aliasing again. They keys are copies, the values aliases. MGS How bizarre? Why does it work that way? well, my take is that it works for the same reason that values now (5.6+) returns aliases to the actual values of a hash. people wanted access the the actual values of a hash when doing foreach ( values %hash ) so they can mung them. so just using %hash and getting a list of key/value pairs would behave the same but obviously the keys have to be copies or you would have to rehash if you modified them. the values are aliased the same way as if you used values. so chop %hash ; and chop values %hash ; do the exact same results with different levels of efficiency and golf scores. typical of abigail to notice that. :) uri -- Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting The Perl Books Page --- http://www.sysarch.com/cgi-bin/perl_books The Best Search Engine on the Net -- http://www.northernlight.com
Re: RFC195: Do not remove 'chop' PLEASE!
On Sun, Jan 28, 2001 at 12:59:53PM -0500, Michael G Schwern wrote:
On Sun, Jan 28, 2001 at 04:28:08PM +0100, [EMAIL PROTECTED] wrote:
Aliasing again. They keys are copies, the values aliases.
How bizarre? Why does it work that way?
keys HASH returns copies of the keys, while values HASH returns
aliases the values (new in 5.7).
I don't know why, perhaps so you could modify them easily:
for (values %hash) {s/foo/bar/}
just like you can do for arrays.
Abigail
Re: JWZ on s/Java/Perl/
On Sat, 27 Jan 2001 18:16:52 -0500, Michael G Schwern wrote: o The architecture-interrogation primitives are inadequate; there is no robust way to ask ``am I running on Windows'' or ``am I running on Unix.'' **We have $^O, but it requires parsing every time** Uhm, I'm sorry, but that's not good enough. You cannot distinguish between Windows 95/98/ME on one side, and NT/2k on the other, using $^O alone. After all, $^O is just a constant burnt into the executable when perl was compiled. You can run the same perl.exe on all platforms, and indeed, most people do. Yet win9* and NT are different enough in behaviour (e.g. flock) to warrant a test on platform. Er... which is: no go. -- Bart.
Re: RFC195: Do not remove 'chop' PLEASE!
On Sat, 27 Jan 2001 15:42:43 -0700, root wrote:
I read RFC195 suggesting to drop 'chop' and go with 'chomp'.
What does 'chop' have anything to do with 'chomp'?
I'm totally oppose to that. Consider:
my $s;
map { /\S/ $s .= "$_ " } split(/\s+/,@_);
chop($s);
return $s;
Excuse me, but you're using chop() for a task it wasn't invented for.
Think about joining your strings with more than one character.
my $s;
map { /\S/ $s .= "$_ - " } split(/\s+/,@_);
chop($s);
return $s;
That doesn't quite cut it, does it?
Here's how you should have written your code:
return join ' ', grep { /\S/ } split(/\s+/,@_);
I, too, once used chop() to get the last character of a string, in my
case to calculate a barcode check digit.
while(my $digit = chop($barcode)) {
...
}
The while loop should have continued until $barcode was empty, all
digitis consumed. Well, the fact that "0" is false really spoilt it for
me.
And in case you're wondering why I wanted to process a barcode from the
back: because the total number of dogots isn't always the same, and the
last digit is the only one you're always sure of on how it ought to be
processed. For the following digits, you always have to toggle the
behaviour of the processing.
The full story is: chop() is not a generic operator, but one
specifically intended for one dedicated task: dropping the newline from
a string read from a file. If you use it for anything else, it probably
sooner or later will bite you. And it's not particularily good at what
it *was* designed for, e.g. with a file not ending in a newline.
--
Bart.
Re: RFC195: Do not remove 'chop' PLEASE!
Today around 10:19pm, Bart Lateur hammered out this masterpiece:
: I, too, once used chop() to get the last character of a string, in my
: case to calculate a barcode check digit.
:
: while(my $digit = chop($barcode)) {
: ...
: }
:
: The while loop should have continued until $barcode was empty, all
: digitis consumed. Well, the fact that "0" is false really spoilt it for
: me.
my $code = '0924820342840';
while ( length( $_ = chop $code ) 0 ) {
print $_;
}
print "\n";
I would be the first to say that this looks like a reasonable use for
chop(), I also know that in the Real World you wouldn't want to
destroy your bar code. You would want to use it later.
Because of this, and because of the following benchmark, I can't say
that I would use chop() either.
timethese( 100, {
choping = sub {
my $code = '0924820342840';
while ( length( $_ = chop $code ) 0 ) {
#print $_;
}
# print "\n";
},
substr = sub {
my $code = '0924820342840';
foreach ( 1 .. length( $code ) ) {
#print substr $code, $_*-1, 1;
}
# print "\n";
}});
Benchmark: timing 100 iterations of choping, substr...
choping: 38 wallclock secs (37.28 usr + 0.10 sys = 37.38 CPU) @ 26749.89/s
(n=100)
substr: 19 wallclock secs (17.53 usr + 0.07 sys = 17.60 CPU) @ 56818.18/s
(n=100)
: The full story is: chop() is not a generic operator, but one
: specifically intended for one dedicated task: dropping the newline from
: a string read from a file. If you use it for anything else, it probably
: sooner or later will bite you. And it's not particularily good at what
: it *was* designed for, e.g. with a file not ending in a newline.
I'm sure there are other reasonable uses for chop() besides this ( I
can't think of any, funny I feel this way :) however, if the benchmark
is any idication of the speed of chop(), I am just going to use:
substr $foo, -1;
from now on. Of course, just to check:
timethese( 1000, {
choping = sub {
my $code = '0924820342840';
my $last = chop $code;
},
substr = sub {
my $code = '0924820342840';
my $last = substr $code, -1;
}});
Benchmark: timing 1000 iterations of choping, substr...
choping: 32 wallclock secs (31.15 usr + 0.08 sys = 31.23 CPU) @ 320170.76/s
(n=1000)
substr: 34 wallclock secs (32.87 usr + 0.13 sys = 33.00 CPU) @ 303030.30/s
(n=1000)
Doesn't seem like that much gain from chop() to substr(), but it's
still a gain. 20k/s more...
--
print(join(' ', qw(Casey R. Tweten)));my $sig={mail='[EMAIL PROTECTED]',site=
'http://home.kiski.net/~crt'};print "\n",'.'x(length($sig-{site})+6),"\n";
print map{$_.': '.$sig-{$_}."\n"}sort{$sig-{$a}cmp$sig-{$b}}keys%{$sig};
my $VERSION = '0.01'; #'patched' by Jerrad Pierce belg4mit at MIT dot EDU
Re: JWZ on s/Java/Perl/
On Sun, Jan 28, 2001 at 10:07:55PM +0100, Bart Lateur wrote: Uhm, I'm sorry, but that's not good enough. You cannot distinguish between Windows 95/98/ME on one side, and NT/2k on the other, using $^O alone. After all, $^O is just a constant burnt into the executable when perl was compiled. You can run the same perl.exe on all platforms, and indeed, most people do. Yet win9* and NT are different enough in behaviour (e.g. flock) to warrant a test on platform. Er... which is: no go. Well, fork works on both now, but I see your point. There are ways of detecting the OS at run-time under Windows, mostly through MFC junk or peeking in the registry. It would probably be good to do it for the MacOS versions, too. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ That which stirs me, stirs everything. -- Squonk Opera, "Spoon"
Re: JWZ on s/Java/Perl/
On Sun, Jan 28, 2001 at 08:56:33PM -0500, Michael G Schwern wrote: On Sun, Jan 28, 2001 at 10:07:55PM +0100, Bart Lateur wrote: Uhm, I'm sorry, but that's not good enough. You cannot distinguish between Windows 95/98/ME on one side, and NT/2k on the other, using $^O alone. After all, $^O is just a constant burnt into the executable when perl was compiled. You can run the same perl.exe on all platforms, and indeed, most people do. Yet win9* and NT are different enough in behaviour (e.g. flock) to warrant a test on platform. Er... which is: no go. Well, fork works on both now, but I see your point. There are ways of detecting the OS at run-time under Windows, mostly through MFC junk or peeking in the registry. It would probably be good to do it for the MacOS versions, too. The desire to know the name of the runtime platform is a misdirected desire. What you really want to know is whether function Foo will be there, what kind of signature it has, whether file Bar will be there, what kind of format it has, and so on, whether a feature Zog is present, or what is the value of parameter Blah. Just knowing the name of the platform doesn't buy you a whole lot. -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: JWZ on s/Java/Perl/
On Sun, Jan 28, 2001 at 11:54:13PM -0600, Jarkko Hietaniemi wrote: The desire to know the name of the runtime platform is a misdirected desire. What you really want to know is whether function Foo will be there, what kind of signature it has, whether file Bar will be there, what kind of format it has, and so on, whether a feature Zog is present, or what is the value of parameter Blah. Just knowing the name of the platform doesn't buy you a whole lot. True, but you can't do any of all that without knowing the platform accurately (nontrivial and requires core mod or XS). Once that's done, the rest is just a matter of extending File::Spec (trivial and pure Perl). -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ mendel ScHWeRnsChweRNsChWErN SchweRN SCHWErNSChwERnsCHwERN sChWErn ScHWeRn schweRn sCHWErN schWeRnscHWeRN SchWeRN scHWErn SchwErn scHWErn ScHweRN sChwern scHWerNscHWeRn scHWerNScHwerN SChWeRN scHWeRn SchwERNschwERnSCHwern sCHWErN SCHWErN sChWeRn
Re: JWZ on s/Java/Perl/
On Mon, Jan 29, 2001 at 01:08:21AM -0500, Michael G Schwern wrote: On Sun, Jan 28, 2001 at 11:54:13PM -0600, Jarkko Hietaniemi wrote: The desire to know the name of the runtime platform is a misdirected desire. What you really want to know is whether function Foo will be there, what kind of signature it has, whether file Bar will be there, what kind of format it has, and so on, whether a feature Zog is present, or what is the value of parameter Blah. Just knowing the name of the platform doesn't buy you a whole lot. True, but you can't do any of all that without knowing the platform accurately (nontrivial and requires core mod or XS). Once that's done, the rest is just a matter of extending File::Spec (trivial and pure Perl). Trivial? *cough* *snigger* -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: JWZ on s/Java/Perl/
Jarkko Hietaniemi writes: True, but you can't do any of all that without knowing the platform accurately (nontrivial and requires core mod or XS). Once that's done, the rest is just a matter of extending File::Spec (trivial and pure Perl). Trivial? *cough* *snigger* If it was trivial, Configure wouldn't need to exist--we could just use hints files. Lots of hints files. One for each configuration, in fact. Hey Jarkko, I have an idea ... :-) Nat
Re: JWZ on s/Java/Perl/
On Mon, Jan 29, 2001 at 12:10:31AM -0600, Jarkko Hietaniemi wrote: Trivial? *cough* *snigger* I'd write it up for you right now, but its too big to fit in the margin. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Skrewtape I've heard that semen tastes different depending on diet. Is that true? Skrewtape Hello? Schwern Skrewtape: Hang on, I'm conducting research.
