[30574] in Perl-Users-Digest
Perl-Users Digest, Issue: 1817 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun Aug 24 21:09:48 2008
Date: Sun, 24 Aug 2008 18:09:12 -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 Sun, 24 Aug 2008 Volume: 11 Number: 1817
Today's topics:
Re: better way to fetch and install packages than just <edwardjameshartnett@gmail.com>
Re: better way to fetch and install packages than just <edwardjameshartnett@gmail.com>
Re: FAQ 4.44 How do I test whether two arrays or hashes <brian.d.foy@gmail.com>
Re: Help: Characters with colors <hjp-usenet2@hjp.at>
Re: Help: Characters with colors <spamtrap@dot-app.org>
Re: Help: Characters with colors <spamtrap@dot-app.org>
Re: Help: Debug perl codes <hjp-usenet2@hjp.at>
Is Perl breaking convention because it has no character sln@netherlands.com
Re: Is Perl breaking convention because it has no chara xhoster@gmail.com
Re: Is Perl breaking convention because it has no chara <joost@zeekat.nl>
Re: Is Perl breaking convention because it has no chara <spamtrap@dot-app.org>
Re: Is Perl breaking convention because it has no chara sln@netherlands.com
Re: Is Perl breaking convention because it has no chara sln@netherlands.com
Re: killing orphan process in Windows? jamesfred@mailinator.com
Re: recursive filehandle <hjp-usenet2@hjp.at>
Re: recursive filehandle <ben@morrow.me.uk>
Re: The Importance of Terminology's Quality <martin@see.sig.for.address.invalid>
Re: Unable to debug Perl script <ced@blv-sam-01.ca.boeing.com>
Re: Unable to debug Perl script <ben@morrow.me.uk>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sun, 24 Aug 2008 06:25:34 -0700 (PDT)
From: Ed <edwardjameshartnett@gmail.com>
Subject: Re: better way to fetch and install packages than just a bunch of system
Message-Id: <f76a6c88-4a04-49f7-91b0-142f018d5d1d@k37g2000hsf.googlegroups.com>
On Aug 21, 7:58 pm, Q...@domain.invalid wrote:
> Ed <edwardjameshartn...@gmail.com> wrote in message-id: <ba680124-f0bf-4e28-933c-af6cbe265...@y38g2000hsy.googlegroups.com>
>
> > Howdy all!
>
> > As part of a test script, I have to make sure my test machine (i.e.
> > the machine that is running the script) has libraries zlib and hdf5. I
> > do that with this code. Is there a better way?
>
> > if ($opt{netcdf4} && ! -e $install_file) {
> > copy("/upc/share/ed/downloads/zlib-$
> > {zlib_version}.tar.gz", $hdf5dir) || die;
> > copy("/upc/share/ed/downloads/hdf5-$
> > {hdf5_version}.tar.gz", $hdf5dir) || die;
> > chdir($hdf5dir) || die;
> > system("gunzip -f zlib-${zlib_version}.tar.gz");
> > system("tar xf zlib-${zlib_version}.tar");
> > chdir("zlib-$zlib_version");
> > system("./configure --prefix=$hdf5dir");
> > system("make install");
> > chdir($hdf5dir);
> > system("rm -rf zlib-${zlib_version}*");
> > system("gunzip -f hdf5-${hdf5_version}.tar.gz");
> > system("tar xf hdf5-${hdf5_version}.tar");
> > chdir("hdf5-$hdf5_version");
> > system("./configure --prefix=$hdf5dir --with-zlib=$hdf5dir
> > --disable-shared");
> > system("make install");
> > chdir($hdf5dir);
> > system("rm -rf hdf5-${hdf5_version}*");
> > system("touch $install_file");
> > }
>
> > Any comments appreciated!
>
> > Thanks,
>
> > Ed
>
> Id not assume the functionality or existance of those utilities.
>
> Perhaps putting your files into a __DATA__ block and then creating
> the file would work on more systems.
No, these files are software source code packages...
Thanks,
Ed
------------------------------
Date: Sun, 24 Aug 2008 06:27:56 -0700 (PDT)
From: Ed <edwardjameshartnett@gmail.com>
Subject: Re: better way to fetch and install packages than just a bunch of system ?calls?
Message-Id: <e44c6696-8958-4668-adf9-885168dfeb1d@k13g2000hse.googlegroups.com>
On Aug 22, 1:53 pm, Eric Pozharski <why...@pozharski.name> wrote:
> Ed <edwardjameshartn...@gmail.com> wrote:
>
> *SKIP*
>
> > copy("/upc/share/ed/downloads/zlib-$
> > {zlib_version}.tar.gz", $hdf5dir) || die;
>
> In my experience B<File::Copy> has somewhat unintuitive notion of what
> is error. You've better don't rely on that.
Hmmmm? How do you mean unintuitive?
>
> *SKIP*
>
> > system("gunzip -f zlib-${zlib_version}.tar.gz");
> > system("tar xf zlib-${zlib_version}.tar");
>
> If my reading of F<changelog> of B<tar> is correct, than I'd guess that
> B<tar> knows about B<gzip> sometime about Sep 2004. So
> C<tar -xzf whatever.tgz> would do the same.
Not all tars support this, unfortunately. GNU tar does.
>
> And why you copy archives? B<tar> will happily extract (if that's
> possible, of course) from anywhere into I<cwd>.
Hey, good point! Now why didn't I think of that?
>
> *SKIP*
>
> > Any comments appreciated!
>
> Don't write shell in Perl.
What the heck does this mean?
Ed
------------------------------
Date: Sun, 24 Aug 2008 13:54:56 +0000
From: brian d foy <brian.d.foy@gmail.com>
Subject: Re: FAQ 4.44 How do I test whether two arrays or hashes are equal?
Message-Id: <240820081354565600%brian.d.foy@gmail.com>
In article <g8mtud077v@news4.newsguy.com>, szr <szrRE@szromanMO.comVE>
wrote:
> PerlFAQ Server wrote:
> > 4.44: How do I test whether two arrays or hashes are equal?
> > if( %hash1 ~~ %hash2 ) # doesn't check values!
> > {
> > say "The hash keys are the same";
> > }
>
> For testing hashes, I think the smart match operator can confuse people
> who don't realize it doesn't compare the values in the hash,
Hence the comment next to the operation :)
------------------------------
Date: Sun, 24 Aug 2008 16:31:57 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Help: Characters with colors
Message-Id: <slrngb2s6t.q4d.hjp-usenet2@hrunkner.hjp.at>
On 2008-08-20 16:47, Brian Helterlilne <brian.helterline@hp.com> wrote:
> Amy Lee wrote:
>> On Wed, 20 Aug 2008 14:40:19 +0000, Lars Eighner wrote:
>>> In our last episode, <pan.2008.08.20.14.25.29.189243@gmail.com>, the lovely
>>> and talented Amy Lee broadcast on comp.lang.perl.misc:
>>>
>>>> open KER_VER, "<", "/root/version";
>>>> while (<KER_VER>)
>>>> {
>>>> unless (/\s+2.4.\d+/)
>>>> {
>>>> die BOLD RED "Your kernel version is not 2.4.x.\n"
>>>> }
>>>> }
[...]
>
> Read the documentation for the other interface - colored(). It returns a
> string with the codes embedded.
>
> die colored( "Your kernel version is not 2.4.x.\n", 'bold red' );
That has the same problem as Amys version. You may want
die colored( "Your kernel version is not 2.4.x.", 'bold red' ) . "\n";
hp
------------------------------
Date: Sun, 24 Aug 2008 10:45:03 -0400
From: Sherm Pendley <spamtrap@dot-app.org>
Subject: Re: Help: Characters with colors
Message-Id: <m13akuwjyo.fsf@dot-app.org>
"Peter J. Holzer" <hjp-usenet2@hjp.at> writes:
> On 2008-08-20 16:47, Brian Helterlilne <brian.helterline@hp.com> wrote:
>>
>> die colored( "Your kernel version is not 2.4.x.\n", 'bold red' );
>
> That has the same problem as Amys version. You may want
>
> die colored( "Your kernel version is not 2.4.x.", 'bold red' ) . "\n";
Lack of a trailing newline isn't a problem here. In fact, you get more
information (the line number of the error) if the string you pass to
die() doesn't end in a newline.
Example:
admins-macintosh:~ sherm$ perl -e 'die "Ouch!"'
Ouch! at -e line 1.
admins-macintosh:~ sherm$ perl -e 'die "Ouch!\n"'
Ouch!
sherm--
--
My blog: http://shermspace.blogspot.com
Cocoa programming in Perl: http://camelbones.sourceforge.net
------------------------------
Date: Sun, 24 Aug 2008 11:30:27 -0400
From: Sherm Pendley <spamtrap@dot-app.org>
Subject: Re: Help: Characters with colors
Message-Id: <m1tzdav3ak.fsf@dot-app.org>
Sherm Pendley <spamtrap@dot-app.org> writes:
> "Peter J. Holzer" <hjp-usenet2@hjp.at> writes:
>
>> On 2008-08-20 16:47, Brian Helterlilne <brian.helterline@hp.com> wrote:
>>>
>>> die colored( "Your kernel version is not 2.4.x.\n", 'bold red' );
>>
>> That has the same problem as Amys version. You may want
>>
>> die colored( "Your kernel version is not 2.4.x.", 'bold red' ) . "\n";
>
> Lack of a trailing newline isn't a problem here. In fact, you get more
> information (the line number of the error) if the string you pass to
> die() doesn't end in a newline.
>
> Example:
>
> admins-macintosh:~ sherm$ perl -e 'die "Ouch!"'
> Ouch! at -e line 1.
> admins-macintosh:~ sherm$ perl -e 'die "Ouch!\n"'
> Ouch!
On further thought, you're right - that *was* Amy's problem. The const
subs were appending the ANSI color codes *after* the newline in the
message she used, so die() was appending information she didn't
want. Brian's version would do the same thing, with the same result.
Yours works by adding the newline *after* the color codes are added to
the message, so the newline is still the last character in the string
when its passed to die().
sherm--
--
My blog: http://shermspace.blogspot.com
Cocoa programming in Perl: http://camelbones.sourceforge.net
------------------------------
Date: Sun, 24 Aug 2008 16:05:12 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Help: Debug perl codes
Message-Id: <slrngb2qko.q4d.hjp-usenet2@hrunkner.hjp.at>
On 2008-08-20 01:05, Amy Lee <openlinuxsource@gmail.com> wrote:
> Actually speaking, I have read the manual before I post my problem. But I
> hope I can trace every sentence in my perl codes not just 'debug'.
^^^^^ ^^^^^
Well, that's two keywords you could search for. And in fact, if you
search for "trace" in "perldoc perldebug", you will discover AutoTrace,
which is another answer to your question.
hp
------------------------------
Date: Mon, 25 Aug 2008 00:09:49 GMT
From: sln@netherlands.com
Subject: Is Perl breaking convention because it has no character arrays, just strings?
Message-Id: <unr3b45er9eurtkj2b9lnqqdnvmuqjc6h2@4ax.com>
I'm a stronger C++ programmer than Perl.
On another thread posted recently, someone was having a
problem with "sysread", passing in the correct buffer
variable. He assigned an intermediate variable to hold the
correct variable to pass in to sysread.
I was a little taken aback, not by this confusion, but by
the fact that Perl's "sysread" (and all the reads) take a
parameter that is a pure scalar variable.
This seemed kind of weird to me since to populate an external
buffer from within a user subroutine, a reference has to be passed in.
Apparently, this doesen't apply to Perl's builtin functions.
I started thinking about C conventions.
In C, there is a concept of "char a[10];", a character array, which
isin't present in Perl, the language, constuct's.
Conceptually, in C, the core language, it has always been pass by value
or pass by reference (or pointer).
In C, this applies to language core lib calls AND user defined function
calls (I say 'C' but "C++" is no different).
I understand that the smallest data unit is SCALAR, however what I can't
understand this distinction:
In C, you can't pass the address of a character to a function (system or user)
that isn't in a character array. char a[10]; function(a,,,) is really
function(&a[0],,,), the "address of a" is passed. Where char a; function(a,,,,),
the "value in a" is passed.
On the other hand, passing a reference of "a" to a function is assignable
within the function.
So what I find dificult to concieve of is why, or how, Perl can take a seeming
"pass by value" in any other function call, and turn it into an assignable
address (or reference) in a Perl function call without having to actually
pass in a reference to the buffer.
My only guess is that Perl parses and interprets its own call's different
than subroutine calls.
Thats my best guess, and its just a guess.
sln
("Don't taze me bro!")
------------------------------
Date: 25 Aug 2008 00:17:03 GMT
From: xhoster@gmail.com
Subject: Re: Is Perl breaking convention because it has no character arrays, just strings?
Message-Id: <20080824201706.516$mk@newsreader.com>
sln@netherlands.com wrote:
> I'm a stronger C++ programmer than Perl.
>
> On another thread posted recently, someone was having a
> problem with "sysread", passing in the correct buffer
> variable. He assigned an intermediate variable to hold the
> correct variable to pass in to sysread.
>
> I was a little taken aback, not by this confusion, but by
> the fact that Perl's "sysread" (and all the reads) take a
> parameter that is a pure scalar variable.
>
> This seemed kind of weird to me since to populate an external
> buffer from within a user subroutine, a reference has to be passed in.
>
> Apparently, this doesen't apply to Perl's builtin functions.
Nor does it apply to user-defined functions.
my $x="foo";
foo($x);
print $x;
sub foo{ $_[0]="bar"};
__END__
bar
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, 25 Aug 2008 02:28:58 +0200
From: Joost Diepenmaat <joost@zeekat.nl>
Subject: Re: Is Perl breaking convention because it has no character arrays, just strings?
Message-Id: <87r68endit.fsf@zeekat.nl>
sln@netherlands.com writes:
> I'm a stronger C++ programmer than Perl.
>
> On another thread posted recently, someone was having a
> problem with "sysread", passing in the correct buffer
> variable. He assigned an intermediate variable to hold the
> correct variable to pass in to sysread.
>
> I was a little taken aback, not by this confusion, but by
> the fact that Perl's "sysread" (and all the reads) take a
> parameter that is a pure scalar variable.
That's just syntactic sugar.
> This seemed kind of weird to me since to populate an external
> buffer from within a user subroutine, a reference has to be passed in.
Yeah. really, don't go down that road - just look at this as one of
the particularities that perl *just* *has*. If you don't believe me:
http://www.perl.com/pub/a/language/misc/fmproto.html
> Apparently, this doesen't apply to Perl's builtin functions.
sysread *is* is builtin function. if you really want to: read up on
prototypes in perl.
> I started thinking about C conventions.
Please don't go there.
> In C, there is a concept of "char a[10];", a character array, which
> isin't present in Perl, the language, constuct's.
> Conceptually, in C, the core language, it has always been pass by value
> or pass by reference (or pointer).
> In C, this applies to language core lib calls AND user defined function
> calls (I say 'C' but "C++" is no different).
>
> I understand that the smallest data unit is SCALAR, however what I can't
> understand this distinction:
>
> In C, you can't pass the address of a character to a function (system or user)
> that isn't in a character array. char a[10]; function(a,,,) is really
> function(&a[0],,,), the "address of a" is passed. Where char a; function(a,,,,),
> the "value in a" is passed.
> On the other hand, passing a reference of "a" to a function is assignable
> within the function.
>
> So what I find dificult to concieve of is why, or how, Perl can take a seeming
> "pass by value" in any other function call, and turn it into an assignable
> address (or reference) in a Perl function call without having to actually
> pass in a reference to the buffer.
>
> My only guess is that Perl parses and interprets its own call's different
> than subroutine calls.
Basically forget about C style prototypes when dealing with
perl. Perl's prototype deal with coercion, C's prototypes do not.
http://www.perlmonks.org/?node_id=447298
--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
------------------------------
Date: Sun, 24 Aug 2008 20:38:06 -0400
From: Sherm Pendley <spamtrap@dot-app.org>
Subject: Re: Is Perl breaking convention because it has no character arrays, just strings?
Message-Id: <m1hc9aj5e9.fsf@dot-app.org>
sln@netherlands.com writes:
> So what I find dificult to concieve of is why, or how, Perl can take
> a seeming "pass by value" in any other function call, and turn it
> into an assignable address (or reference) in a Perl function call
> without having to actually pass in a reference to the buffer.
>
> My only guess is that Perl parses and interprets its own call's
> different than subroutine calls.
You can make any subroutine (but not a method) act the same way by
supplying a prototype. Suppose you wanted to declare your own
equivalent to the built-in push() function:
sub mypush (\@@) {
my $arr = shift;
push @$arr, @_;
}
You'd call it like this:
mypush @foo, 'bar', 'baz';
Note that you don't need to take the reference to @foo - that's what
the \ in the prototype does. It means that argument will be passed by
reference, and Perl will automatically create the reference.
Have a look at the "Prototypes" section in "perldoc perlsub" for
details.
sherm--
--
My blog: http://shermspace.blogspot.com
Cocoa programming in Perl: http://camelbones.sourceforge.net
------------------------------
Date: Mon, 25 Aug 2008 00:58:43 GMT
From: sln@netherlands.com
Subject: Re: Is Perl breaking convention because it has no character arrays, just strings?
Message-Id: <kr04b49sfkknndb11mipltijjv6l6nl1ls@4ax.com>
On Sun, 24 Aug 2008 20:38:06 -0400, Sherm Pendley <spamtrap@dot-app.org> wrote:
>sln@netherlands.com writes:
>
>> So what I find dificult to concieve of is why, or how, Perl can take
>> a seeming "pass by value" in any other function call, and turn it
>> into an assignable address (or reference) in a Perl function call
>> without having to actually pass in a reference to the buffer.
>>
>> My only guess is that Perl parses and interprets its own call's
>> different than subroutine calls.
>
>You can make any subroutine (but not a method) act the same way by
>supplying a prototype. Suppose you wanted to declare your own
>equivalent to the built-in push() function:
>
> sub mypush (\@@) {
> my $arr = shift;
> push @$arr, @_;
> }
>
>You'd call it like this:
>
> mypush @foo, 'bar', 'baz';
>
>Note that you don't need to take the reference to @foo - that's what
>the \ in the prototype does. It means that argument will be passed by
>reference, and Perl will automatically create the reference.
>
>Have a look at the "Prototypes" section in "perldoc perlsub" for
>details.
>
>sherm--
Hey thanks, I'm going to look into prototypes soon.
I did asume a prototype, like in your example, worked that way.
sln
------------------------------
Date: Mon, 25 Aug 2008 01:03:00 GMT
From: sln@netherlands.com
Subject: Re: Is Perl breaking convention because it has no character arrays, just strings?
Message-Id: <8014b49qpeg8ek5obpll3b2q229k84mqmu@4ax.com>
On 25 Aug 2008 00:17:03 GMT, xhoster@gmail.com wrote:
>sln@netherlands.com wrote:
>> I'm a stronger C++ programmer than Perl.
>>
>> On another thread posted recently, someone was having a
>> problem with "sysread", passing in the correct buffer
>> variable. He assigned an intermediate variable to hold the
>> correct variable to pass in to sysread.
>>
>> I was a little taken aback, not by this confusion, but by
>> the fact that Perl's "sysread" (and all the reads) take a
>> parameter that is a pure scalar variable.
>>
>> This seemed kind of weird to me since to populate an external
>> buffer from within a user subroutine, a reference has to be passed in.
>>
>> Apparently, this doesen't apply to Perl's builtin functions.
>
>Nor does it apply to user-defined functions.
>
>my $x="foo";
>foo($x);
>print $x;
>sub foo{ $_[0]="bar"};
>__END__
>bar
>
>Xho
Interresting.
I didn't realize every value passed in was a reference.
What happens when you pass in a reference?
sln
------------------------------
Date: Sun, 24 Aug 2008 00:16:52 -0700 (PDT)
From: jamesfred@mailinator.com
Subject: Re: killing orphan process in Windows?
Message-Id: <e1ef6569-363b-4a98-be52-186f7e74e691@d45g2000hsc.googlegroups.com>
On Aug 24, 4:41=A0am, Woland99 <wolan...@gmail.com> wrote:
> Howdy - I have a Perl script that uses fairly standard Win32::OLE
> calls to
> read Excel spreadsheets and feed data into build process. Every now
> and
> then that script fails and leaves orphan Excel process. Then
> subsequent
> build fails and you need to manually connect to build machine and use
> Task Manager to kill Excel process before restarting build.
> Is there a way to safely clean after yourself if any of the Win32::OLE
> calls
> fails and to kill Excel process?
> Or - as alternative - is there a way to kill any Excel orphans before
> starting
> to process spreadsheets?
> Any pointers will be greatly appreciated.
>
> JT
If you have the pid of the Excel process, you can
eval "END { kill(9, $pid) unless \$finished }"; $@ and die $@;
where $finished is true if you know that Excel has actually
finished (otherwise you could end up killing another unrelated
process).
But Win32::OLE may support a better method.
------------------------------
Date: Sun, 24 Aug 2008 16:08:44 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: recursive filehandle
Message-Id: <slrngb2qrc.q4d.hjp-usenet2@hrunkner.hjp.at>
On 2008-08-19 17:14, Leon Timmermans <fawaka@gmail.com> wrote:
> On Tue, 19 Aug 2008 18:36:29 +0200, Wijnand Nijs wrote:
>> sub built_tolist($) {
[...]
>> &built_tolist($ems[2]);
> You probably don't want to use prototypes or '&' sigils.
And certainly not both together.
hp
------------------------------
Date: Sun, 24 Aug 2008 23:49:26 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: recursive filehandle
Message-Id: <m459o5-rf11.ln1@osiris.mauzo.dyndns.org>
Quoth "Peter J. Holzer" <hjp-usenet2@hjp.at>:
> On 2008-08-19 17:14, Leon Timmermans <fawaka@gmail.com> wrote:
> > On Tue, 19 Aug 2008 18:36:29 +0200, Wijnand Nijs wrote:
> >> sub built_tolist($) {
> [...]
> >> &built_tolist($ems[2]);
>
> > You probably don't want to use prototypes or '&' sigils.
>
> And certainly not both together.
Well... about the only case where using & on a sub call is reasonable in
modern Perl is when you know the sub is prototyped, but specifically
want to avoid the prototyped behaviour. See e.g. Hash::Util::Fieldhash
for an example of where this can be useful.
Ben
--
For far more marvellous is the truth than any artists of the past imagined!
Why do the poets of the present not speak of it? What men are poets who can
speak of Jupiter if he were like a man, but if he is an immense spinning
sphere of methane and ammonia must be silent? [Feynmann] ben@morrow.me.uk
------------------------------
Date: Sun, 24 Aug 2008 12:28:01 +0000 (UTC)
From: Martin Gregorie <martin@see.sig.for.address.invalid>
Subject: Re: The Importance of Terminology's Quality
Message-Id: <g8rk4h$amj$1@localhost.localdomain>
On Sat, 23 Aug 2008 21:22:05 -0400, John W Kennedy wrote:
> Martin Gregorie wrote:
>> On Sat, 23 Aug 2008 00:06:28 -0400, John W Kennedy wrote:
>>
>>> Martin Gregorie wrote:
>>>> Not necessarily. An awful lot of CPU cycles were used before
>>>> microcode was introduced. Mainframes and minis designed before about
>>>> 1970 didn't use or need it
>>> No, most S/360s used microcode.
>>
>> I never used an S/360.
>>
>> I thought microcode came into the IBM world with S/370 and Future
>> Series (which later reappeared as the AS/400, which I did use). Didn't
>> the S/370 load its microcode off an 8 inch floppy?
>
> Some did, but not all. The 370/145 was the first, and made a big splash
> thereby.
>
..snip...
Thanks for that. As I said, during most of that era I was using ICL kit.
Microcode was never mentioned in the 1900 contect. Hoiwever, they had a
very rough approximation called extracodes. though they were closer to
software traps than microcode: if hardware didn't implement an op code
the OS intercepted it and ran equivalent code. This was used for i/o
operations and for FP instructions on boxes that didn't have FP hardware.
As a result all boxes executed the same instruction set. Some opcodes
might be very slow on some hardware but it would execute.
The 2900 series had huge amounts of microcode - it even defined both
memory mapping and opcodes. You could run 1900 code (24 bit words, fixed
length instructions, ISO character codes) simultaneously with 'native'
code (8 bit bytes, v/l instructions, EBCDIC) with each program running
under its usual OS (George 3 for 1900, VME/B for 1900).
The only other systems I'm aware of that could do this were the big
Burroughs boxes (6700 ?), which used a byte-based VM for COBOL and a word-
based VM for FORTRAN and Algol 60) and IBM AS/400 (OS/400 could run S/34
code alongside S/38 and AS/400 code). AFAICT Intel virtualisation doesn't
do this - all code running under VMware or any of the other VMs is still
running in a standard Intel environment.
--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
------------------------------
Date: Sun, 24 Aug 2008 16:09:31 -0700 (PDT)
From: "comp.lang.c++" <ced@blv-sam-01.ca.boeing.com>
Subject: Re: Unable to debug Perl script
Message-Id: <a4b94ea8-bfa3-4f3a-97dd-ef983b880aa5@n33g2000pri.googlegroups.com>
On Aug 23, 1:06 pm, Ben Morrow <b...@morrow.me.uk> wrote:
> Quoth "comp.lang.c++" <c...@blv-sam-01.ca.boeing.com>:
>
>
>
> > On Aug 22, 12:23 pm, Ben Morrow <b...@morrow.me.uk> wrote:
> > > Quoth "szr" <sz...@szromanMO.comVE>:
>
> > > ...
> > > Presumably the hash function was tweaked in 5.8, and two of the strings
> > > '1'..'5' now end up in the same bucket; I would expect that this was
> > > done to make some real-world set of keys distribute better, but I don't
> > > know.
>
> > Or maybe hv.h provides the clue:
>
> > /* hash a key */
> > ...
> > The "hash seed" feature was added in Perl 5.8.1
> > to perturb the results to avoid "algorithmic
> > complexity attacks".
>
> Nope. Firstly, the hashing appears to have changed *before* 5.8.1;
> secondly, as of 5.8.2 (IIRC) the random-hash-seed behaviour only kicks
> in on hashes that are actually under attack.
>
Seems strange the new hashing behavior - at least in the example
mentioned - is less distributive than 5.6.1. That is, the same 2 keys
now hash the same and get bucketed together whereas with 5.6.1 they
didn't. It just seems very counter-intuitive
that 2 different, single character keys would hash
to the same value in any case if the algorithm
bore any resemblance to the classic one:
int i = key_length;
unsigned int hash = 0;
char *s = key;
while (i--) { hash = hash * 33 + *s++; }
--
Charles DeRykus
------------------------------
Date: Mon, 25 Aug 2008 01:31:42 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Unable to debug Perl script
Message-Id: <e4b9o5-ti41.ln1@osiris.mauzo.dyndns.org>
Quoth "comp.lang.c++" <ced@blv-sam-01.ca.boeing.com>:
> On Aug 23, 1:06 pm, Ben Morrow <b...@morrow.me.uk> wrote:
> > Quoth "comp.lang.c++" <c...@blv-sam-01.ca.boeing.com>:
> > > On Aug 22, 12:23 pm, Ben Morrow <b...@morrow.me.uk> wrote:
> > > > Quoth "szr" <sz...@szromanMO.comVE>:
> >
> > > > ...
> > > > Presumably the hash function was tweaked in 5.8, and two of the strings
> > > > '1'..'5' now end up in the same bucket; I would expect that this was
> > > > done to make some real-world set of keys distribute better, but I don't
> > > > know.
> >
> > > Or maybe hv.h provides the clue:
> >
> > > /* hash a key */
> > > ...
> > > The "hash seed" feature was added in Perl 5.8.1
> > > to perturb the results to avoid "algorithmic
> > > complexity attacks".
> >
> > Nope. Firstly, the hashing appears to have changed *before* 5.8.1;
> > secondly, as of 5.8.2 (IIRC) the random-hash-seed behaviour only kicks
> > in on hashes that are actually under attack.
>
> Seems strange the new hashing behavior - at least in the example
> mentioned - is less distributive than 5.6.1. That is, the same 2 keys
> now hash the same and get bucketed together whereas with 5.6.1 they
> didn't. It just seems very counter-intuitive
> that 2 different, single character keys would hash
> to the same value in any case if the algorithm
> bore any resemblance to the classic one:
>
> int i = key_length;
> unsigned int hash = 0;
> char *s = key;
> while (i--) { hash = hash * 33 + *s++; }
5.6 used exactly that; 5.8 changed it to
char *s_PeRlHaSh_tmp = str;
unsigned char *s_PeRlHaSh = (unsigned char *)s_PeRlHaSh_tmp;
I32 i_PeRlHaSh = len;
U32 hash_PeRlHaSh = 0;
while (i_PeRlHaSh--) {
hash_PeRlHaSh += *s_PeRlHaSh++;
hash_PeRlHaSh += (hash_PeRlHaSh << 10);
hash_PeRlHaSh ^= (hash_PeRlHaSh >> 6);
}
hash_PeRlHaSh += (hash_PeRlHaSh << 3);
hash_PeRlHaSh ^= (hash_PeRlHaSh >> 11);
(hash) = (hash_PeRlHaSh + (hash_PeRlHaSh << 15));
which apparently performs better on real-world data.
Ben
--
The cosmos, at best, is like a rubbish heap scattered at random.
Heraclitus
ben@morrow.me.uk
------------------------------
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 1817
***************************************
