[13879] in Perl-Users-Digest
Perl-Users Digest, Issue: 1289 Volume: 9
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Nov 5 03:05:26 1999
Date: Fri, 5 Nov 1999 00:05:11 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Message-Id: <941789110-v9-i1289@ruby.oce.orst.edu>
Content-Type: text
Perl-Users Digest Fri, 5 Nov 1999 Volume: 9 Number: 1289
Today's topics:
Re: chdir (perl v4) (David H. Adler)
dbm file broken <jdijkmei@dds.nl>
Re: duplicates in an array <sumengen@iplab.ece.ucsb.edu>
Re: flock (Abigail)
Re: Help? What are Black Squares? (David H. Adler)
Re: how can I display command results as they occur?? (Abigail)
Re: how sort an array? <uri@sysarch.com>
Re: how sort an array? (Peter J. Kernan)
Re: how sort an array? (Andrew Johnson)
Re: how sort an array? (Abigail)
Re: how sort an array? <marcel.grunauer@lovely.net>
Re: how sort an array? (Abigail)
Re: how sort an array? (Ilya Zakharevich)
Re: how sort an array? <uri@sysarch.com>
Re: Inplace editing and safety <uri@sysarch.com>
Re: localtime object y2k compliant? (Kragen Sitaker)
Re: localtime object y2k compliant? <uri@sysarch.com>
Re: localtime object y2k compliant? <lr@hpl.hp.com>
My own Crypt function <dab@ucla.edu>
need my program to interface with Dictionary and Thesau <kigray@cs.utexas.edu>
perl dB <any@any.com>
Re: PERL in Windows CE? <uri@sysarch.com>
Re: PERL in Windows CE? <neil@pacifier.com>
Re: Record realaudio in perl <jomagam@yahoo.com>
Re: Yet another Perl Sockets question... (Kragen Sitaker)
Digest Administrivia (Last modified: 16 Sep 99) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 5 Nov 1999 06:31:42 GMT
From: dha@panix7.panix.com (David H. Adler)
Subject: Re: chdir (perl v4)
Message-Id: <slrn824uee.j4.dha@panix7.panix.com>
In article <012072c6.81e80413@usw-ex0109-069.remarq.com>, JRC wrote:
>we use
>chdir ("/etc/blahblah")
>at the begining of a program. Later a
>system("xyz");
>returns incorrect results. As I said above, we're on a
>SUN Ultra runnig perl 4. (Don't ask why, that's a legacy
>issue!)
Last I checked, using perl4 was more of a *security* issue... :-/
dha
--
David H. Adler - <dha@panix.com> - http://www.panix.com/~dha/
He was from the planet Blobnar.
- Jon Orwant
------------------------------
Date: Fri, 5 Nov 1999 08:49:33 +0100
From: "jeroen dijkmeijer" <jdijkmei@dds.nl>
Subject: dbm file broken
Message-Id: <7vu1fu$jb7$1@news.worldonline.nl>
Hi All,
We were running an application which used the DBM file functionality
together whith dbmopen, this has always worked fine. But lately things have
changed the production computer changed and the System Manager convinced me
that nothing changed except for the hardware. However after this migration
the dbmopen function executed without problems but as soon as we tried to
address the keys in this file map {} keys %the_file_hash, gave an error
allocation too large, rgl. 79 van zoek.pl.
Currently we solved the problem by using DB_File instead and converting the
dbmfile to the DB_File format on the development platform, which still works
fine. However superiors do not support this fix and demand a full
explanation.
Does anyone have a clue what could have been wrong, or can anybody think of
a convincing explanation.
Any help is greatly appreciated.
Jeroen.
------------------------------
Date: Thu, 4 Nov 1999 21:06:05 -0800
From: "Baris Sumengen" <sumengen@iplab.ece.ucsb.edu>
Subject: Re: duplicates in an array
Message-Id: <7vto1l$r04@yuggoth.ucsb.edu>
Yes, you are right. Everybody has to go over all the FAQ's once before
posting here.
But there is also another issue. I honestly sometimes don't understand the
solution in the FAQ's. (I obviously don't know all the perl basics). But the
idea behind perl is: "You don't have to know everything, but youy can still
write useful programs".
Baris.
David Cassell <cassell@mail.cor.epa.gov> wrote in message
news:38221FD6.276E4B63@mail.cor.epa.gov...
> Baris Sumengen wrote:
> >
> > Thanks,
> > I only used to use books to learn perl until now. But The perl FAQ's are
> > nice. I will be spending couple of days on them.
> > baris.
>
> Let me just interject this one tidbit:
>
> In Andrew Johnson's book "Elements of Programming with Perl",
> the author not only tells people how to post in this newsgroup
> so as not to rile the Dark Perl Daemons, but also tells them
> how to access and read the docs including the FAQ. He even
> tells people not to assume their question is too unusual to
> be in the FAQ.
>
> Thank you, Andrew.
>
> David
> --
> David Cassell, OAO cassell@mail.cor.epa.gov
> Senior computing specialist
> mathematical statistician
------------------------------
Date: 5 Nov 1999 01:21:09 -0600
From: abigail@delanet.com (Abigail)
Subject: Re: flock
Message-Id: <slrn8251i6.dk.abigail@alexandra.delanet.com>
Max (nihilist@kenobiz.com) wrote on MMCCLVII September MCMXCIII in
<URL:news:382241e5.67722414@news.acronet.net>:
^^ if i flock(YESFILE, 2) what happens when another file requests that
^^ same file? does it just die, or does it get placed in a queue?
Did you read the manual? Did you *try*?
Abigail
--
perl -wleprint -eqq-@{[ -eqw\\- -eJust -eanother -ePerl -eHacker -e\\-]}-
-----------== Posted via Newsfeeds.Com, Uncensored Usenet News ==----------
http://www.newsfeeds.com The Largest Usenet Servers in the World!
------== Over 73,000 Newsgroups - Including Dedicated Binaries Servers ==-----
------------------------------
Date: 5 Nov 1999 07:01:41 GMT
From: dha@panix7.panix.com (David H. Adler)
Subject: Re: Help? What are Black Squares?
Message-Id: <slrn82506l.j4.dha@panix7.panix.com>
In article <38221F28.32D459C@mail.cor.epa.gov>, David Cassell wrote:
>Abigail wrote:
>[snip]
>
>You just copied this right off alt.fan.buffy-the-vampire-slayer
>now didn't you? It's last week's episode, right?
Damn. I must have missed that one. Sounded good too... :-)
>And also:
>$str =~ s/lion/loin/;
Which, of course, reminds me of a Letterman top 10 list: Films playing
in times square (this is obviously from some time ago... :-| )
#[insert number here]: The Loin King.
>So, who was wearing the loin cloth? Buffy? Willow?
Mmm... Willow...
Oh. Sorry... was miles away... :-)
irrelevantly yours,
dave (no, not you, the other one... :-)
--
David H. Adler - <dha@panix.com> - http://www.panix.com/~dha/
Your pluck is admirable. However, arguing for a 'pure computer
science' approach in the perl5-porters mailing list is somewhat like
inquiring about mileage in a Maserati dealership. People are given to
drop their champagne glasses and stare. - Felix Gallo, p5p
------------------------------
Date: 5 Nov 1999 01:22:23 -0600
From: abigail@delanet.com (Abigail)
Subject: Re: how can I display command results as they occur??
Message-Id: <slrn8251kh.dk.abigail@alexandra.delanet.com>
Bill Darbie (noSpam@noSpam.com) wrote on MMCCLVII September MCMXCIII in
<URL:news:7vtbd4$4qe$1@fcnews.fc.hp.com>:
// I have the following line of perl code:
//
// $out = `make 2>&1`;
// print $out;
//
// This does a build of code for me and then prints the output.
// The problem is that the build can take over an hour and I
// want to see the results as they are happening. Right now
// I see nothing for over an hour and then all the output comes
// out at the end. How can I execute my make and see the
// results unbuffered?
By not doing doing things complicated:
system "make";
Abigail
--
perl -wle '$, = " "; print grep {(1 x $_) !~ /^(11+)\1+$/} 2 .. shift'
-----------== Posted via Newsfeeds.Com, Uncensored Usenet News ==----------
http://www.newsfeeds.com The Largest Usenet Servers in the World!
------== Over 73,000 Newsgroups - Including Dedicated Binaries Servers ==-----
------------------------------
Date: 05 Nov 1999 00:20:59 -0500
From: Uri Guttman <uri@sysarch.com>
Subject: Re: how sort an array?
Message-Id: <x7bt997bus.fsf@home.sysarch.com>
>>>>> "LR" == Larry Rosler <lr@hpl.hp.com> writes:
LR> In article <slrn824bm9.dk.abigail@alexandra.delanet.com> on 4 Nov
LR> 1999 19:07:52 -0600, Abigail <abigail@delanet.com> says...
>> How about LUPS: Larry's and Uri's Pack Sort?
LR> ULP!
Uri's and Larry's Pack?
this is going downhill very fast without brakes.
at least our technique is getting more widespread and known. when the
right name comes along i am sure larry and i will know it. GRP is among
the better ones so far but it ain't a winner.
uri
--
Uri Guttman --------- uri@sysarch.com ---------- 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
------------------------------
Date: 5 Nov 1999 05:21:16 GMT
From: pete@theory2.phys.cwru.edu (Peter J. Kernan)
Subject: Re: how sort an array?
Message-Id: <slrn824qab.k5i.pete@theory2.phys.cwru.edu>
On Thu, 4 Nov 1999 17:35:10 -0800, Larry Rosler <lr@hpl.hp.com> wrote:
.=Things about nuclear physics that I learned in graduate school are now
.=taught in high school. It's just a matter of technical maturity, which
those kids cross my path. they know as much as you did in high
school about nuclear physics. 8-?
.=takes time. Even those who (like me) can toss off an ST by rote were
.=boggled by it on very first acquaintance. For the GRP, this too shall
.=pass.
maybe not. i dont GRok the GRIP (GR Instinctive Praysort) yet, but i am
working it. the important difference, as far as the boggledness passing,
is the need for the cheat sheet. with ST once you grok the concepts you
have it (anonymous array, map). with GRP after getting the essential
idea knowledge of details is required (pack and sprintf bells and
whistles). but, it is great that GRP is out there if you need it.
--
Pete
------------------------------
Date: Fri, 05 Nov 1999 06:18:54 GMT
From: andrew-johnson@home.com (Andrew Johnson)
Subject: Re: how sort an array?
Message-Id: <iFuU3.738$Zu4.17880@news1.rdc1.mb.home.com>
In article <x7bt997bus.fsf@home.sysarch.com>,
Uri Guttman <uri@sysarch.com> wrote:
! >>>>> "LR" == Larry Rosler <lr@hpl.hp.com> writes:
[snip]
! LR> ULP!
!
! Uri's and Larry's Pack?
!
! this is going downhill very fast without brakes.
something like the 'ROGUE' pack sort sounds rather cool and
mysterious --- with a few alternatives for the E:
ROsler GUttman Efficient pack sort
Effective
Elusive
Egregious
Economic
Emancipated
Eminent
Elderberry
:-)
andrew
--
Andrew L. Johnson http://www.manning.com/Johnson/
The generation of random numbers is too
important to be left to chance.
------------------------------
Date: 5 Nov 1999 01:12:18 -0600
From: abigail@delanet.com (Abigail)
Subject: Re: how sort an array?
Message-Id: <slrn82511g.dk.abigail@alexandra.delanet.com>
Larry Rosler (lr@hpl.hp.com) wrote on MMCCLVII September MCMXCIII in
<URL:news:MPG.128bd42c8e495ec298a1ad@nntp.hpl.hp.com>:
__
__ Here is about the simplest non-trivial sort: Sort an array of strings
__ by the first substring of digits in each element.
__
__ ST (elementary school -- or is it?):
__
__ my @out = map { $_->[0] }
__ sort { $a->[1] <=> $b->[1] }
__ map { [ $_, /(\d+)/ ] }
__ @in;
__
__ GR Prefix Sort (high-school version):
__
__ my @out = map { substr $_, 10 }
__ sort
__ map { sprintf('%.10d', /(\d+)/) . $_ }
__ @in;
__
__ GR Packed Sort (junior-college version):
__
__ my @out = map { substr $_, 4 }
__ sort
__ map { pack('N', /(\d+)/) . $_ }
__ @in;
__
__ An argument could be made that the ST has more punctuation and is harder
__ to understand than the 'obscure' GRP sorts. It is certainly slower, if
__ that matters. It may be slightly faster to write (because as Uri says,
__ you have to use some brains -- or a cheatsheet such as Appendix B in our
__ paper -- to figure out the string prefix), but his module will help with
__ that (if and when :-).
Punctuation doesn't make something harder to understand.
The packed GR sort takes advantage of the fact that for the packing
algorithm f, f(x) le f(y) iff x le y. (Who says this is always true? ;-))
ST is also more general, as GR prefix sort only works for strings, and
GR packed sort for packable objects. ST tacks the original object away,
and doesn't have to recreate it.
Suppose you want to sort a list of code references. (What, noone
does that on a regular basis...?)
Simple sort: @out = sort {$a -> () cmp $b -> ()} @in;
ST: @out = map {$_ -> [0]}
sort {$a -> [1] cmp $b -> [1]}
map {[$_, $_ -> ()]} @in;
GR Prefix: ??
GR Packed: ??
The "simplicity" of ST lies in the fact that given the sort function,
the creation of the ST is mechanical. And it works all the time.
Note that I would write the given example as an ST, but in a slightly
different way:
@out = map {$_ -> [0]}
sort {$a -> [1] <=> $b -> [1] or
$a -> [2] cmp $b -> [2]}
map {my ($ds) = /([1-9]\d*)/ || 0; [$_, length $ds, $ds]} @in;
which has a somewhat higher upperbound on the number of digits that can be
used [1]. The ST as quoted is limited to 51 or 52 digits, or whatever the
number of digits is that Perl can deal with without a loss. The prefix GR
limits itself to 10 digits - you would need a second pass to determine the
maximum number of digits. But if you do that, your memory usuage suddenly
explodes to worst case Omega (M * N), where M is the length of the longest
string, and N the number of strings. The GR Pack version limits itself
to 32 bit integers. Again, you would need 2 passes to figure out to
pack if you go beyond that. Also leading to Omega (M * N) memory usage.
And the latter brings me to why GR Pack is more difficult than ST. It
exposes an implementation layer, where ST (or GR Prefix) don't.
Note that there also exists a modified ST, that like GR Prefix and
GR Pack has the advantage of not having a code block with sort, and
like ST, doesn't like itself to strings or package objects. It's also
stable.
Sorting the coderefs again:
my @out = do {my %hash;
push @{$hash {$_ -> ()}} => $_ for @in;
map {@{$hash {$_}}}
sort keys %hash};
which can be simplified if it is known that all sortable values are unique.
Note that this sort has the added benefit of being stable, unlike ST or
GR Prefix/Pack.
It beats ST in the following benchmark:
#!/opt/perl/bin/perl -w
use strict;
use Benchmark;
my $iterations = 1 << ($ARGV [0] || 4);
my $size = 1 << ($ARGV [1] || 12);
# Build an array of coderefs.
$#::in = $size - 1;
for (my $i = 0; $i < $size; $i ++) {
my $rand = join '' => ('a' .. 'z') [map {rand 26} 1 .. 5];
$::in [$i] = sub {$rand};
}
print "Array size = $size\n";
timethese ($iterations => {
assign => 'my @out = @::in',
simple => 'my @out = sort {$a -> () cmp $b -> ()} @::in',
ST => 'my @out = map {$_ -> [0]}
sort {$a -> [1] cmp $b -> [1]}
map {[$_, $_ -> ()]} @::in',
STn => 'my @out = map {$_ -> [0]}
map {[$_, $_ -> ()]} @::in',
abigail => 'my @out = do {my %hash;
push @{$hash {$_ -> ()}} => $_ for @::in;
map {@{$hash {$_}}}
sort keys %hash}',
abigailn => 'my @out = do {my %hash;
push @{$hash {$_ -> ()}} => $_ for @::in;
map {@{$hash {$_}}}
keys %hash}',
});
__END__
Array size = 16384
Benchmark: timing 64 iterations of ST, STn, abigail, abigailn, assign, simple...
ST: 92 wallclock secs ( 82.42 usr + 0.03 sys = 82.45 CPU)
STn: 29 wallclock secs ( 26.06 usr + 0.01 sys = 26.07 CPU)
abigail: 65 wallclock secs ( 59.21 usr + 0.00 sys = 59.21 CPU)
abigailn: 55 wallclock secs ( 49.67 usr + 0.00 sys = 49.67 CPU)
assign: 3 wallclock secs ( 2.34 usr + 0.01 sys = 2.35 CPU)
simple: 312 wallclock secs (283.44 usr + 0.20 sys = 283.64 CPU)
Some experimenting suggests that ST is faster for array sizes up 64.
[1] Let me know when you have a machine where you cannot store the
length of a string in a variable without losing precision....
Abigail
--
perl -we '$@="\145\143\150\157\040\042\112\165\163\164\040\141\156\157\164".
"\150\145\162\040\120\145\162\154\040\110\141\143\153\145\162".
"\042\040\076\040\057\144\145\166\057\164\164\171";`$@`'
-----------== Posted via Newsfeeds.Com, Uncensored Usenet News ==----------
http://www.newsfeeds.com The Largest Usenet Servers in the World!
------== Over 73,000 Newsgroups - Including Dedicated Binaries Servers ==-----
------------------------------
Date: Fri, 05 Nov 1999 07:26:43 GMT
From: Marcel Grunauer <marcel.grunauer@lovely.net>
Subject: Re: how sort an array?
Message-Id: <U5QiOKxmc1TfuP4zLeobXkCeUMRK@4ax.com>
On Fri, 05 Nov 1999 06:18:54 GMT, andrew-johnson@home.com (Andrew
Johnson) wrote:
> something like the 'ROGUE' pack sort sounds rather cool and
> mysterious --- with a few alternatives for the E:
>
> ROsler GUttman Efficient pack sort
> Effective
> Elusive
> Egregious
> Economic
> Emancipated
> Eminent
> Elderberry
Eccentric
Eclectic
Enigmatic
--
Marcel, Perl Padawan
sub AUTOLOAD{$_=$AUTOLOAD;s;.*::;;;y;_; ;;print}&Just_Another_Perl_Hacker;
------------------------------
Date: 5 Nov 1999 01:39:46 -0600
From: abigail@delanet.com (Abigail)
Subject: Re: how sort an array?
Message-Id: <slrn8252l3.dk.abigail@alexandra.delanet.com>
Abigail (abigail@delanet.com) wrote on MMCCLVII September MCMXCIII in
<URL:news:slrn82511g.dk.abigail@alexandra.delanet.com>:
``
`` Note that I would write the given example as an ST, but in a slightly
`` different way:
``
`` @out = map {$_ -> [0]}
`` sort {$a -> [1] <=> $b -> [1] or
`` $a -> [2] cmp $b -> [2]}
`` map {my ($ds) = /([1-9]\d*)/ || 0; [$_, length $ds, $ds]} @in;
``
`` which has a somewhat higher upperbound on the number of digits that can be
`` used [1]. The ST as quoted is limited to 51 or 52 digits, or whatever the
`` number of digits is that Perl can deal with without a loss. The prefix GR
`` limits itself to 10 digits - you would need a second pass to determine the
`` maximum number of digits. But if you do that, your memory usuage suddenly
`` explodes to worst case Omega (M * N), where M is the length of the longest
`` string, and N the number of strings. The GR Pack version limits itself
`` to 32 bit integers. Again, you would need 2 passes to figure out to
`` pack if you go beyond that. Also leading to Omega (M * N) memory usage.
Well, you can of course apply the Prefix technique twice. First prefix
it with whatever you need to sort on (of variable length), then prefix
that with the lenght, using a fixed width size.
Something similar might work for the packing technique.
@out = map {substr $_ => 10 + substr $_ => 0, 10}
sort
map {my ($ds) = /(\d+)/; $ds =~ s/^0+(?=\d)//;
sprintf "%10d%s%s" => length ($ds), $ds, $_}
Abigail
--
$_ = "\x3C\x3C\x45\x4F\x54";
print if s/<<EOT/<<EOT/e;
Just another Perl Hacker
EOT
-----------== Posted via Newsfeeds.Com, Uncensored Usenet News ==----------
http://www.newsfeeds.com The Largest Usenet Servers in the World!
------== Over 73,000 Newsgroups - Including Dedicated Binaries Servers ==-----
------------------------------
Date: 5 Nov 1999 07:44:33 GMT
From: ilya@math.ohio-state.edu (Ilya Zakharevich)
Subject: Re: how sort an array?
Message-Id: <7vu1t1$sbb$1@charm.magnus.acs.ohio-state.edu>
[A complimentary Cc of this posting was sent to Abigail
<abigail@delanet.com>],
who wrote in article <slrn82511g.dk.abigail@alexandra.delanet.com>:
> The "simplicity" of ST lies in the fact that given the sort function,
> the creation of the ST is mechanical. And it works all the time.
If it is true, then it is the compiler who should do it, not the
coder.
> which has a somewhat higher upperbound on the number of digits that can be
> used [1].
> [1] Let me know when you have a machine where you cannot store the
> length of a string in a variable without losing precision....
By definition IV is large enough to keep a pointer. Thus it is large
enough to keep the length. However, you may need to through in `use integer'
to force integer-<=> - if there are machines around which can have
2**53-long strings but do not have a long double. ;-)
Ilya
------------------------------
Date: 05 Nov 1999 02:57:29 -0500
From: Uri Guttman <uri@sysarch.com>
Subject: Re: how sort an array?
Message-Id: <x7so2l5q1i.fsf@home.sysarch.com>
>>>>> "A" == Abigail <abigail@delanet.com> writes:
A> The packed GR sort takes advantage of the fact that for the packing
A> algorithm f, f(x) le f(y) iff x le y. (Who says this is always true? ;-))
A> ST is also more general, as GR prefix sort only works for strings, and
A> GR packed sort for packable objects. ST tacks the original object away,
A> and doesn't have to recreate it.
the GR sort doesn't have to recreate the original record and it can be
used on complex structures like LoH and LoL just fine. one trick is to
use an index sort and use the sorted indexes in an array slice to get
the sorted records.
A> Suppose you want to sort a list of code references. (What, noone
A> does that on a regular basis...?)
A> Simple sort: @out = sort {$a -> () cmp $b -> ()} @in;
A> ST: @out = map {$_ -> [0]}
A> sort {$a -> [1] cmp $b -> [1]}
A> map {[$_, $_ -> ()]} @in;
A> GR Prefix: ??
A> GR Packed: ??
GR index sort:
$index = 0 ;
@indexes = map unpack( 'N', substr( $_, -4 ) ),
sort
map $_ -> () . pack( 'N', $index++ ), @in;
@out = @in[ @indexes ] ;
you can merge the last two statements if you want:
@out = @in[
map unpack( 'N', substr( $_, -4 ) ),
sort
map $_ -> () . pack( 'N', $index++ ), @in
] ;
A> The "simplicity" of ST lies in the fact that given the sort function,
A> the creation of the ST is mechanical. And it works all the time.
there are almost no cases where the GRP can't do what the ST does. and
our claim is not for simplicity but speed. and it is not that much more
complex and it is even simpler in some cases (multiple keys in
particular).
A> Note that there also exists a modified ST, that like GR Prefix and
A> GR Pack has the advantage of not having a code block with sort, and
A> like ST, doesn't like itself to strings or package objects. It's also
A> stable.
A> Sorting the coderefs again:
A> my @out = do {my %hash;
A> push @{$hash {$_ -> ()}} => $_ for @in;
A> map {@{$hash {$_}}}
A> sort keys %hash};
A> which can be simplified if it is known that all sortable values are unique.
A> Note that this sort has the added benefit of being stable, unlike ST or
A> GR Prefix/Pack.
my example above is stable as the index is part of the sort key. and
your example is more obscure. what is the output of the code ref is not
string sortable such as integers with varying lengths? i actually wonder
if you have read our paper. you seem to be railing on it without reason.
A> It beats ST in the following benchmark:
of course it will beat it. the main premise in our paper is to remove
any code blocks from sorts.
the biggest win of GRP over ST is with multiple keys. the ST has to do
multiple compares (ladder compares) where the GRP still does a plain
string compare with no code block. if the primary key is not very
unique, you will have many secondary compares which eats the cpu.
and there are several ways to pack the keys, pack or sprintf. the keys
can be fixed or varying length. there are plenty of variations to
customize according to the needs of the sort. but if you just want to
rip out a code quickie, the ST is fine. again, unless the sort is
complex or large enough, it mmake not much difference in the real world
and simpler code is better then.
A> $::in [$i] = sub {$rand};
you are returning a number but doing string compares. so your ST is
losing by converting the number to a string each time. your hash key
trick does it only once per key. that is your big win here. as i said
before, try this with varying length integers. you have to pad them as
hash keys to make your trick work.
A> ST => 'my @out = map {$_ -> [0]}
A> sort {$a -> [1] cmp $b -> [1]}
^^^
try <=>
also try my GRP example above.
A> [1] Let me know when you have a machine where you cannot store the
A> length of a string in a variable without losing precision....
??? a GRP can a packed N for the key length which is 32 bits. not many
strings get that long.
uri
--
Uri Guttman --------- uri@sysarch.com ---------- 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
------------------------------
Date: 05 Nov 1999 00:16:43 -0500
From: Uri Guttman <uri@sysarch.com>
Subject: Re: Inplace editing and safety
Message-Id: <x7eme57c1w.fsf@home.sysarch.com>
>>>>> "ll" == lee lindley <lee.lindley@bigfoot.com> writes:
ll> Nobody is above the fray in c.l.p.misc. If you post code that
ll> doesn't work, no amount of waffling can save you.
ll> Come on uri, take your whuppin' like a man and stop trying to hide
ll> behind some lawyer-like weasle words like "untested".
i could have just called it pseudo code and not worried at all about the
syntax. i was just illustrating a concept and didn't care about missing
punctuation.
ll> We will accept a short acknowldgement like
ll> mea culpa # or Ouch. Sorry about that. # or Good catch on that.
ll> I'll be more careful next time.
you won't get it.
ll> Lest you be tempted to reply with some less polite 2 word answers,
ll> I've been making a club. :-)
i won't join any club that would have me as a member (or would beat me).
uri
--
Uri Guttman --------- uri@sysarch.com ---------- 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
------------------------------
Date: Fri, 05 Nov 1999 05:20:36 GMT
From: kragen@dnaco.net (Kragen Sitaker)
Subject: Re: localtime object y2k compliant?
Message-Id: <EOtU3.30204$23.1579368@typ11.nn.bcandid.com>
In article <3822354B.27217820@mail.cor.epa.gov>,
David Cassell <cassell@mail.cor.epa.gov> wrote:
>Kragen Sitaker wrote:
>> In article <38221D17.3C3A409F@mail.cor.epa.gov>,
>> David Cassell <cassell@mail.cor.epa.gov> wrote:
>> >Jocelyn Amon wrote:
>Her table has all the URLs given. Tracking down the guilty
>parties seems feasible.
>
>I did a little web-searching too, and I plan to put my
>results together in a (hopefully) useful post to this newsgroup
>in a couple weeks on "HOW TO FIX Y2K BUGS IN YOUR PERL CODE"
>or some similar stupid title designed to snag clouded corneas.
That would be totally terrific.
>> I still think localtime() and gmtime() should return a 0-based year,
>> not a 1900-based year. The bugs would have been avoided altogether.
>
>Well, after 2000 this won't be as much of an issue.. I hope.
I think you're right.
>> I think the best solution is to make life easier for casual
>> programmers. It won't solve the problem altogether, of course --
>> casual programmers will write buggy code no matter what we do. But the
>> least we can do is give them environments where the most likely bugs
>> are more obvious. This benefits us too.
>
>Logical, captain. How do you plan to do this?
Hmm, well, I don't know. Using Perl is a start; designing reasonably
transparent interfaces helps. It'd be nice if running programs under a
debugger of sorts, so you could see all the values for at least one
iteration of everything -- just like in Excel -- would help a lot,
too.
--
<kragen@pobox.com> Kragen Sitaker <http://www.pobox.com/~kragen/>
Tue Nov 02 1999
6 days until the Internet stock bubble bursts on Monday, 1999-11-08.
<URL:http://www.pobox.com/~kragen/bubble.html>
------------------------------
Date: 05 Nov 1999 00:44:19 -0500
From: Uri Guttman <uri@sysarch.com>
Subject: Re: localtime object y2k compliant?
Message-Id: <x77ljx7arw.fsf@home.sysarch.com>
>>>>> "LR" == Larry Rosler <lr@hpl.hp.com> writes:
LR> I have a suggestion, actually. The world needs to be made aware
LR> of the Y2038 Bug, the sooner the better. You're the one to do it!
LR> I expect to miss the FUD around that one. What a pity. It will
LR> be so much fun.
aw, come on larry, intel/hp will have merced (or itanium) out by then?
and surely you will be around for 38 more years!
live long and prosper,
uri
--
Uri Guttman --------- uri@sysarch.com ---------- 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
------------------------------
Date: Thu, 4 Nov 1999 22:01:12 -0800
From: Larry Rosler <lr@hpl.hp.com>
Subject: Re: localtime object y2k compliant?
Message-Id: <MPG.128c127ccce3c9a098a1b3@nntp.hpl.hp.com>
In article <x77ljx7arw.fsf@home.sysarch.com> on 05 Nov 1999 00:44:19 -
0500, Uri Guttman <uri@sysarch.com> says...
> >>>>> "LR" == Larry Rosler <lr@hpl.hp.com> writes:
>
> LR> I have a suggestion, actually. The world needs to be made aware
> LR> of the Y2038 Bug, the sooner the better. You're the one to do it!
>
> LR> I expect to miss the FUD around that one. What a pity. It will
> LR> be so much fun.
>
> aw, come on larry, intel/hp will have merced (or itanium) out by then?
> and surely you will be around for 38 more years!
But why would I want to still be doing this stuff?
--
(Just Another Larry) Rosler
Hewlett-Packard Laboratories
http://www.hpl.hp.com/personal/Larry_Rosler/
lr@hpl.hp.com
------------------------------
Date: Thu, 4 Nov 1999 23:36:34 -0800
From: "David Beckwith" <dab@ucla.edu>
Subject: My own Crypt function
Message-Id: <7vu1dr$nt7$1@carroll.library.ucla.edu>
Hi,
I would like to write my own crypt function. Can somebody explain to me
how I might go about doing that? Also, do you know any good tutorials or
webpages on how to encrypt passwords? I need to learn the basic ideas
behind it as well.
Thank you very much,
David :)
------------------------------
Date: Thu, 4 Nov 1999 16:03:36 -0600
From: Kimbrough Gray <kigray@cs.utexas.edu>
Subject: need my program to interface with Dictionary and Thesaurus
Message-Id: <Pine.LNX.4.10.9911041602260.3994-100000@cowboy.cs.utexas.edu>
I am writing a translation program in perl. I need to interface with a
Dictionary and a Thesaurus. I know there a web sites like
http://www.thesaurus.com/ which give information.
I do not know how to have a program utilize these sites.
So These are my questions.
First is there a Dictionary or Thesaurus in the format of a text file
somewhere.
Second I know there are programs like "dict" in Unix. This program used
to be on the UNIX system I have access to at school. Now it is gone.
Does anyone know of any machines that I could gain access to with a
dict like program or a thesaurus program.
Finally does anyone know of a way by which a perl program can go to
a web page fill out a form, press a submit button and then save the
results.
------------------------------
Date: Fri, 5 Nov 1999 13:32:05 +0800
From: "¤@¤ë" <any@any.com>
Subject: perl dB
Message-Id: <7vtpqj$jc$1@news.hk.linkage.net>
#!/usr/bin/perl
use DBI;
#use DBD::ODBC;
$DSN="DBI:ODBC:Test SQL";
$user="sa";
$pw="";
$dbh = DBI->connect($DSN,$user,$pw) *{|| die "Unable to
connect: }$DBI::errstr\n" unless $dbh;
print "Content-type: text/html\n\n";
--------------------------------------------end
the above script do work in linux shell but doesn't work in http request,
also, if I all additional sentence after $dbh=DBI..., it always appears
http500 error, how can I solve that?? thx.
------------------------------
Date: 05 Nov 1999 01:06:12 -0500
From: Uri Guttman <uri@sysarch.com>
Subject: Re: PERL in Windows CE?
Message-Id: <x73dul79rf.fsf@home.sysarch.com>
>>>>> "j" == johnsteele <johnsteele@my-deja.com> writes:
j> Anyone know if PERL (ActiveState) will run under Windows CE? John
does anything run (as opposed to crawl) under wince? i wrote an rtos for
a pdp-11 (20 years ago that was faster and more stable than wince. it is
the bloatiest piece of shit redmond has ever evacuated out its
anus. they paid att 5 BILLION (buying their stock) to force them to use
it their set top boxes (att owns lots of cable co's now) because NO ONE
was buying it. like other redmondware it charged more than its
competitors for less and said it has compatiblity with winblows! think
of all those winblow programmers out ther you can hire. both major
lies. imagine your typical winblows programmer who expects to be able to
reboot every 5 minutes to clear up his hung program venturing into the
realtime embedded world. scary, ain't it?
perl will run under some embedded/rtos systems such as qnx and i have
heard of work in progress for vxworks.
like win2k, wince is one of the most apt names redmond has ever coined.
i hope perl never is ported to wince because when it is, the apocolypse
will be upon us.
i hope i do offend anyone who cares.
uri
--
Uri Guttman --------- uri@sysarch.com ---------- 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
------------------------------
Date: 4 Nov 1999 23:23:50 PST
From: Neil <neil@pacifier.com>
Subject: Re: PERL in Windows CE?
Message-Id: <38228606.0@news.pacifier.com>
Uri Guttman <uri@sysarch.com> wrote:
> i hope i do offend anyone who cares.
Someone at my company bought one of these wince machines and it is
now a paper weight. Your commentary was hilarious! Porting Perl to
wince would be like hanging a Rembrandt in a dingy alley.
Neil
------------------------------
Date: Fri, 05 Nov 1999 01:26:26 -0500
From: Balazs Rauznitz <jomagam@yahoo.com>
Subject: Re: Record realaudio in perl
Message-Id: <38227892.34BD746B@yahoo.com>
Kragen Sitaker wrote:
> The protocol is a secret, last I heard, and the specification is not
> available. As far as I know, therefore, there is no Perl
> implementation of the protocol at present, nor a C implementation
> easily usable from Perl.
That sucks. It's so anti-internetish that they have a protocol that's a
secret. I'll try to see what I can hack up though. There is an option in
RealPlayer to communicate through HTTP only, so it shouldn't be extremly hard
to capture what is sent back and forth..
> The secrecy of the protocol allows RealNetworks to (a) maintain a
> monopoly on RealAudio servers, and (b) incorrectly claim to potentials
> server customers that the RealAudio stream cannot be recorded.
It would be _really_ incorrect claim, since you can record with certain
versions of realaudio; of course the ones you pay for.
> (You can, of course, record it as it comes out of your sound card, or as it
> goes into your sound driver. If you're using Linux, there's a kernel
> patch to help with this.)
What's it's name ?
Thanks: Balazs
------------------------------
Date: Fri, 05 Nov 1999 05:39:56 GMT
From: kragen@dnaco.net (Kragen Sitaker)
Subject: Re: Yet another Perl Sockets question...
Message-Id: <M4uU3.30229$23.1581302@typ11.nn.bcandid.com>
In article <38225A25.29467964@mediaone.net>,
Akira <akira####@mediaone.net> wrote:
>sorry... I should review my posts better...
>
>The actual send/recv should read...
>
>Server: $socket->send(@filecontents, 0) or die "Send died: $!\n";
Hmm. You probably don't want to pass an array to send(). The first
element of the array will be sent, using the flags in the second
element of the array, to the address in the third element of the array
(if it's not a connected socket), and subsequent elements of the array
will be ignored.
I'm assuming this isn't what you want because you appear to be trying
to pass flags of 0. But maybe @filecontents only has one element and
so you're OK.
>Client: $socket->recv($buff, 1024);
>
>
>What I'm trying to figure out is how to tell the receiving end to stop looking
>for data.
It's a protocol thing; you have to define a protocol. The simplest
solution is to close the connection when you're done sending. Second
simplest is to send the number of bytes in the data first, then send
the data. Third (or maybe tied for second) is to define some sequence
of bytes that can't occur in the data and send that after the end of
the data. (Then you have to figure out how to change the data to
encode that sequence of bytes as something else, if it's a possibility.)
> I was assuming (bad idea) that if one side is sending that the other
>side that's receiving would stop receiving because the sending side said it was
>through.
Well, if you stop sending, the other side *will* stop receiving --
it'll hang in the recv() call without receiving anything. :)
> (told you it was a bad idea to assume). I've talked with a few people
>and they said that perl doesn't really account for this. That it's a function
>of the sockets on the machine being used.
Maybe I didn't understand your question, then. end-of-message
indications in TCP need to be done by endpoint programs, not the
networking stack.
> Also that I need to send the client
>the size of the buffer being sent so that it can use that value for the recv.
>ie $socket->recv($buff, $length).
You don't have to do that. You can if you want to. Be aware that the
size you send data in may not be the size it gets received in if you're
using TCP instead of UDP.
>The purpose of posting to the comp.lang.perl.misc (for those thinking of
>RTFMing me) is to determine which RTFM i'm missing out on.
Not a Perl FM, I think.
>Does perl take account of this? Who tells the server (send) to stop sending?
You mean when the recipient's buffer is full? The recipient tells its
OS by not reading more data; the OS's buffers fill up and it tells the
sender's OS by letting the TCP window close; the sender's OS tells the
sending process by making it hang in the send call until there's space.
I can't imagine you mean "who tells the server when it's done sending
all the data".
>Who tells the client (recv) to stop buffering to *that* specific buffer?
Reading from a blocking socket either (a) hangs until any data is
ready, then reads whatever is available, or (b) immediately returns any
queued incoming data, regardless of how much or little there is --
unless it's too big to fit in the buffer, in which case it only returns
one bufferfull. Is that what you meant?
>I'm using IO::Socket for simplicity....
Bravo!
--
<kragen@pobox.com> Kragen Sitaker <http://www.pobox.com/~kragen/>
Tue Nov 02 1999
6 days until the Internet stock bubble bursts on Monday, 1999-11-08.
<URL:http://www.pobox.com/~kragen/bubble.html>
------------------------------
Date: 16 Sep 99 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 16 Sep 99)
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: The mail to news gateway, and thus the ability to submit articles
| through this service to the newsgroup, has been removed. I do not have
| time to individually vet each article to make sure that someone isn't
| abusing the service, and I no longer have any desire to waste my time
| dealing with the campus admins when some fool complains to them about an
| article that has come through the gateway instead of complaining
| to the source.
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 V9 Issue 1289
**************************************
