[28384] in Perl-Users-Digest
Perl-Users Digest, Issue: 9748 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Sep 21 14:05:49 2006
Date: Thu, 21 Sep 2006 11:05:07 -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 Thu, 21 Sep 2006 Volume: 10 Number: 9748
Today's topics:
Re: array of hashes with a little more... <mikebjunk@gmail.com>
Re: array of hashes with a little more... <tzz@lifelogs.com>
DBI hashref to CGI optgroup? <ggershSNACK@CAKEctc.net>
Re: DBI hashref to CGI optgroup? <mritty@gmail.com>
Re: DBI hashref to CGI optgroup? <David.Squire@no.spam.from.here.au>
Re: DBI hashref to CGI optgroup? <David.Squire@no.spam.from.here.au>
Re: DBI hashref to CGI optgroup? <ggershSNACK@CAKEctc.net>
Re: DBI hashref to CGI optgroup? <glex_no-spam@qwest-spam-no.invalid>
Deleting characters from the end of each line <arussell@leggmason.com>
Re: Deleting characters from the end of each line <mritty@gmail.com>
Re: Deleting characters from the end of each line <tadmc@augustmail.com>
Re: explaining how memory works with tie()ed hashs <glex_no-spam@qwest-spam-no.invalid>
Re: Help with plotting <pradeep.bg@gmail.com>
Re: Help with plotting <David.Squire@no.spam.from.here.au>
Re: How do I find the Nth index of array that is (whate <tadmc@augustmail.com>
Re: How do I find the Nth index of array that is (whate <tadmc@augustmail.com>
Re: How do I find the Nth index of array that is (whate <tzz@lifelogs.com>
Re: Learning perl - for experienced programmers <jwkenne@attglobal.net>
Re: Learning perl - for experienced programmers <jwkenne@attglobal.net>
Re: Learning perl - for experienced programmers <jwkenne@attglobal.net>
Re: Net::Telnet, script exits after connection failure <janin.netosoite@TULPPAgmail.com>
Priority flag and MIME::Lite <maitrebart@excite.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 21 Sep 2006 08:34:47 -0700
From: "mikeybe" <mikebjunk@gmail.com>
Subject: Re: array of hashes with a little more...
Message-Id: <1158852887.010455.206430@m73g2000cwd.googlegroups.com>
Just wanted to let everyone know that I finally got it working
correctly. I couldn't have done it without you so thank you very much!
I ended up making an AoA with the number pair values from @deweystring
[000, 100],
[100, 200],
etc.
Then used those to create a hash of arrays of hashes....crazy junk and
I'm not sure I fully grasp the syntax but it was a learning process.
Thanks again,
Mike
------------------------------
Date: Thu, 21 Sep 2006 12:56:04 -0400
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: array of hashes with a little more...
Message-Id: <g69hcz1cg63.fsf@CN1374059D0130.kendall.corp.akamai.com>
On 20 Sep 2006, mikebjunk@gmail.com wrote:
>> I wonder if mikeybe doesn't really want the range to be part of the
>> RSS feed URL:
>>
>> /getrss.cgi?start=020&end=030&start=100&end=200
>>
>> Then dynamically generate the resulting documents, providing some
>> prebuilt RSS feed queries for users who don't want to build their
>> own. IIRC the multiple start/end parameters should be OK.
>
> I thought about this...and it may be where I end up turning to later
> on, but to make a long story short, I'm not doing this now:) The skinny
> is that the whole project will be run from a unix box perl script which
> will extract the data, create rss feeds from it daily/weekly whatever,
> and then FTP the files to the web server. I will make links manually on
> the relevant web pages.
One alternate approach you may want to consider is to pre-generate the
smallest chunks, e.g. 020-029, 030-039, etc. as pure data that you can
just include in a bigger result. So your big results will just be an
aggregation of pre-generated small results.
This will have the advantage of predictability. Instead of A to B, C
to D, etc. you will just generate N (1000/10 for example) uniform
pieces of data without any trickery. It will be simpler to understand
and manage than your manually configured ranges, IMHO.
I'm trying to help you with something bigger than the exact approach,
now that I think about it. Try to extract the configuration out of
the code. What you have now requires a code update every time you
change the configuration.
Hope this helps
Ted
------------------------------
Date: Thu, 21 Sep 2006 11:30:14 -0400
From: Greg G <ggershSNACK@CAKEctc.net>
Subject: DBI hashref to CGI optgroup?
Message-Id: <6fGdnfWM1_IcMo_YnZ2dnUVZ_vadnZ2d@ctc.net>
Here's what I'm trying to do:
my $sql1 = "select location, location_name from location_names order by
location";
$all_locs = $dbh->selectall_hashref($sql1, "LOCATION");
print "<tr><td>\n";
print "<select name='available_locations' multiple size=20
style='width:150'>\n";
print optgroup (-name=>"available_locations", -values => \%$all_locs );
print "</select></td>\n";
Should be pretty simple, right? Except that it doesn't work! The
option group gets generated with stuff like this:
<option value="LOC1">HASH(0xa381bbc)</option>
The LOC1 is, of course, correct. However, that HASH reference sure
isn't the location name. What am I doing wrong here? This seems like
it should be straightfoward, but I've tried a ton of variations, and
nothing seems to help.
Thanks.
-Greg G
------------------------------
Date: 21 Sep 2006 08:49:28 -0700
From: "Paul Lalli" <mritty@gmail.com>
Subject: Re: DBI hashref to CGI optgroup?
Message-Id: <1158853768.162368.277840@k70g2000cwa.googlegroups.com>
Greg G wrote:
> Here's what I'm trying to do:
>
> my $sql1 = "select location, location_name from location_names order by
> location";
> $all_locs = $dbh->selectall_hashref($sql1, "LOCATION");
>
> print "<tr><td>\n";
> print "<select name='available_locations' multiple size=20
> style='width:150'>\n";
> print optgroup (-name=>"available_locations", -values => \%$all_locs );
> print "</select></td>\n";
>
>
> Should be pretty simple, right? Except that it doesn't work! The
> option group gets generated with stuff like this:
>
> <option value="LOC1">HASH(0xa381bbc)</option>
>
> The LOC1 is, of course, correct. However, that HASH reference sure
> isn't the location name. What am I doing wrong here? This seems like
> it should be straightfoward, but I've tried a ton of variations, and
> nothing seems to help.
What do you think is inside of $all_locs? selectall_hashref returns a
hash of hashes. The key of the outer hash is each value of the
LOCATION column from your table. The value is a reference to a hash,
where the key is the column name and the value is the entry for that
column in that row.
The value of the -values parameter, however, is supposed to be a
single-level hash, of just string keys and string values.
selectall_hashref is not going to do what you want. You're going to
have to build your hash piece by piece, with each fetch from the
statement handle.
my %location_of;
my $sql1 = "select location, location_name from location_names order by
location";
my $sth = $dbh->prepare($sql);
$sth->execute();
while (my $row = $sth->fetchrow_hashref) {
$location_of{ $row->{location} } = $row->{location_name};
}
And then use \%location_of in your -values attribute.
Paul Lalli
------------------------------
Date: Thu, 21 Sep 2006 16:50:00 +0100
From: David Squire <David.Squire@no.spam.from.here.au>
Subject: Re: DBI hashref to CGI optgroup?
Message-Id: <eeucb9$pq9$1@gemini.csx.cam.ac.uk>
Greg G wrote:
>
> Here's what I'm trying to do:
>
> my $sql1 = "select location, location_name from location_names order by
> location";
> $all_locs = $dbh->selectall_hashref($sql1, "LOCATION");
>
> print "<tr><td>\n";
> print "<select name='available_locations' multiple size=20
> style='width:150'>\n";
I take it you're using CGI.pm and some DBI/DBD modules? You really need
to tell us the complete context of what you're doing.
> print optgroup (-name=>"available_locations", -values => \%$all_locs );
$all_locs is already a hashref, so what is the \% for? You deference it
with % and then re-reference it with \ ???
> print "</select></td>\n";
>
>
> Should be pretty simple, right? Except that it doesn't work! The
> option group gets generated with stuff like this:
>
> <option value="LOC1">HASH(0xa381bbc)</option>
>
> The LOC1 is, of course, correct. However, that HASH reference sure
> isn't the location name. What am I doing wrong here? This seems like
> it should be straightfoward, but I've tried a ton of variations, and
> nothing seems to help.
According to the CGI.pm documentation, -values should be specified using
an arrayref, not a hashref. You need to ask DBI for an arrayref (or
array), not a hash.
DS
------------------------------
Date: Thu, 21 Sep 2006 16:53:45 +0100
From: David Squire <David.Squire@no.spam.from.here.au>
Subject: Re: DBI hashref to CGI optgroup?
Message-Id: <eeuci9$pq9$2@gemini.csx.cam.ac.uk>
David Squire wrote:
> According to the CGI.pm documentation, -values should be specified using
> an arrayref, not a hashref. You need to ask DBI for an arrayref (or
> array), not a hash.
Actually, further reading shows that you can in fact pass it a hashref,
in which case "the keys will be used for the menu values, and the values
will be used for the menu labels". Perhaps that is what you wanted.
DS
------------------------------
Date: Thu, 21 Sep 2006 12:35:13 -0400
From: Greg G <ggershSNACK@CAKEctc.net>
Subject: Re: DBI hashref to CGI optgroup?
Message-Id: <HcydnTJAorMmI4_YnZ2dnUVZ_umdnZ2d@ctc.net>
Paul Lalli wrote:
> What do you think is inside of $all_locs? selectall_hashref returns a
> hash of hashes. The key of the outer hash is each value of the
> LOCATION column from your table. The value is a reference to a hash,
> where the key is the column name and the value is the entry for that
> column in that row.
>
> The value of the -values parameter, however, is supposed to be a
> single-level hash, of just string keys and string values.
>
> selectall_hashref is not going to do what you want. You're going to
> have to build your hash piece by piece, with each fetch from the
> statement handle.
Thanks. I think I may have also been distracted by CGI::FormBuilder...
In any case, I had to do a little more jiggery-pokerey, because the
resultant hash wasn't sorted (well, duh, right?), so, here's what I
finished up with (and does work for me):
my @loc_values = ();
my %loc_labels = ();
my $sql1 = "select location, location_name from location_names order by
location";
my $sth1 = $dbh->prepare($sql1);
$sth1->execute();
while (my $row = $sth1->fetchrow_hashref) {
push @loc_values, $row->{LOCATION};
$loc_labels{ $row->{LOCATION} } = "$row->{LOCATION}
($row->{LOCATION_NAME})";
}
print optgroup (-name=>"available_locations",
-values => \@loc_values,
-labels => \%loc_labels,
);
Thanks for the quick response.
-Greg G
------------------------------
Date: Thu, 21 Sep 2006 12:01:32 -0500
From: "J. Gleixner" <glex_no-spam@qwest-spam-no.invalid>
Subject: Re: DBI hashref to CGI optgroup?
Message-Id: <4512c4b0$0$10300$815e3792@news.qwest.net>
Greg G wrote:
[...]
> In any case, I had to do a little more jiggery-pokerey, because the
> resultant hash wasn't sorted (well, duh, right?), so, here's what I
> finished up with (and does work for me):
Could also use Tie::IxHash:
"...implements Perl hashes that preserve the order in which the hash
elements were added. ..."
>
> my @loc_values = ();
> my %loc_labels = ();
No need to initialize them.
> my $sql1 = "select location, location_name from location_names order by
> location";
Could use single quotes there.
> my $sth1 = $dbh->prepare($sql1);
> $sth1->execute();
> while (my $row = $sth1->fetchrow_hashref) {
> push @loc_values, $row->{LOCATION};
> $loc_labels{ $row->{LOCATION} } = "$row->{LOCATION}
> ($row->{LOCATION_NAME})";
That's OK, provided your $row->{ LOCATION } is unique, of course.
> }
Take a look at bind_columns(), which is faster and will make
that much easier to read, there won't be any need for "$row->".
>
> print optgroup (-name=>"available_locations",
No need to use double quotes.
> -values => \@loc_values,
> -labels => \%loc_labels,
> );
Also, you can do one call to print with multiple arguments:
print "<tr><td>\n",
"<select name='available_locations' ...\n",
optgroup (-name=>"available_locations", ...);
Could also use CGI's popup_menu(), instead of '<select.. '.
------------------------------
Date: 21 Sep 2006 07:12:03 -0700
From: "amrussell" <arussell@leggmason.com>
Subject: Deleting characters from the end of each line
Message-Id: <1158847922.886302.304080@k70g2000cwa.googlegroups.com>
I am trying to figure out how I can go to the end of each line in a
report and delete an exact number of characters from right to left. I
have some characters at the end of each line in some reports I am
processing and I want to get rid of them. I know how to do a search
and replace, but the patterns are never the same. Can any one help?
------------------------------
Date: 21 Sep 2006 07:23:06 -0700
From: "Paul Lalli" <mritty@gmail.com>
Subject: Re: Deleting characters from the end of each line
Message-Id: <1158848586.048906.52610@k70g2000cwa.googlegroups.com>
amrussell wrote:
> I am trying to figure out how I can go to the end of each line in a
> report and delete an exact number of characters from right to left. I
> have some characters at the end of each line in some reports I am
> processing and I want to get rid of them. I know how to do a search
> and replace, but the patterns are never the same. Can any one help?
s/// is useful to remove specific patterns.
substr() is useful to remove specific numbers of characters.
substr($s, -3) = q{};
for example, will remove the last three characters of $s.
perldoc -f substr
for more substr tricks.
Paul Lalli
------------------------------
Date: Thu, 21 Sep 2006 09:30:14 -0500
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: Deleting characters from the end of each line
Message-Id: <slrneh58fm.k3i.tadmc@magna.augustmail.com>
amrussell <arussell@leggmason.com> wrote:
> I am trying to figure out how I can go to the end of each line in a
> report and delete an exact number of characters from right to left.
perldoc -f substr
> Can any one help?
substr($str, -$exact_number_of_characters, length $str, '');
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Thu, 21 Sep 2006 10:52:32 -0500
From: "J. Gleixner" <glex_no-spam@qwest-spam-no.invalid>
Subject: Re: explaining how memory works with tie()ed hashs
Message-Id: <4512b484$0$34077$815e3792@news.qwest.net>
botfood wrote:
[...]
> In this particular case, each record is not that big, except for one
> specific type of 'book-keeping' record that is used to keep track of
> what records are considered 'complete' by this particular application.
> With a couple reports, I need to whip thru all complete records
> searching for various things.... And in another spot I know that the
> code looks for matches within this big record that contains around 20k
> 'words' consisting of about 20 digits.
[...]
> The next part of the question is.... if it sounds like a large internal
> indexing record is likely to be a problem, what would some recommended
> techniques be to break that out? should I create a separate DB file to
> use as an index? I am really wondering how best to 'fake' large
> database capabilities to manage keeping track of status without eating
> tons of memory.
If I understand your issue correctly, possibly using another key
for these completed entries, or a separate DBM, would be better.
For example, if the key were by a user name, then add an additional
key of ${username}_completed. That could be stored in the same DBM or
you could create another "completed" DBM containing the user name as
its key, the 20-digits, or the "various things" you're looking for,
could be stored where ever it makes sense.
This way you'd know what user names were completed and could
easily access the data for the user name in the other table.
I'd think that'd be much more efficient when compared to a key of
'completed' containing all of the user names.
Try to design it as if it were simply a hash, which is all
it is. Using the DBM will really optimize memory and
disk space, however you're responsible for design the
keys and records to work well as a hash.
------------------------------
Date: 21 Sep 2006 09:11:05 -0700
From: "Deepu" <pradeep.bg@gmail.com>
Subject: Re: Help with plotting
Message-Id: <1158855065.203003.5020@d34g2000cwd.googlegroups.com>
Thanks a lot for the help. I tried the below code and am getting an
error like:
Can't locate PDL/Graphics/PLplot.pm in @INC
Can somebody please let me know what changes need to be done.
Thanks
use strict;
use warnings;
use PDL;
use PDL::Graphics::PLplot;
my @yesArray = qw(10 6 18 20 10);
my @noArray = qw(8 7 10 12 10);
my @unknownArray = qw(14 20 10 10 10);
my $fmt = "%-10s %5s %5s %5s\n";
printf ($fmt, '', qw(YES NO UNKNOWN));
printf $fmt, 'FILE'.($_+1), $yesArray[$_],
$noArray[$_], $unknownArray[$_] for (0..$#yesArray);
my $pl = PDL::Graphics::PLplot->new(DEV => 'pbm',
FILE => 'make_yn_table.pbm');
$pl->setparm(PLOTTYPE => 'LINEPOINTS', LINEWIDTH => 4);
my $x = sequence(scalar @yesArray)+1;
$pl->xyplot($x, pdl [ @yesArray ] );
$pl->xyplot($x, pdl [ @noArray ], COLOR => 'RED');
$pl->xyplot($x, pdl [ @unknownArray ], COLOR => 'BLUE');
print $x;
$pl->close;
------------------------------
Date: Thu, 21 Sep 2006 18:12:50 +0100
From: David Squire <David.Squire@no.spam.from.here.au>
Subject: Re: Help with plotting
Message-Id: <eeuh5j$5i1$1@gemini.csx.cam.ac.uk>
Deepu wrote:
> Thanks a lot for the help. I tried the below code and am getting an
> error like:
>
> Can't locate PDL/Graphics/PLplot.pm in @INC
>
> Can somebody please let me know what changes need to be done.
>
Ermmm.... install the module?
If you have already installed it, then it must be in a non-standard
place w.r.t. your Perl installation, and you will have to tell Perl
where to look via a "use lib '/path/to/directory/where/module/is';" line
at the top of the script.
DS
------------------------------
Date: Thu, 21 Sep 2006 08:00:27 -0500
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: How do I find the Nth index of array that is (whatever)
Message-Id: <slrneh537b.ji7.tadmc@magna.augustmail.com>
usenet@DavidFilmer.com <usenet@DavidFilmer.com> wrote:
> Michele Dondi wrote:
>> print +(grep !$array[$_], 0..$#array)[2], "\n";
>
> That's really cool. But I don't get the reason for the "+" - wuzzat?
See the 3rd paragraph in:
perldoc perlfunc
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Thu, 21 Sep 2006 08:03:07 -0500
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: How do I find the Nth index of array that is (whatever)
Message-Id: <slrneh53cb.ji7.tadmc@magna.augustmail.com>
Michele Dondi <bik.mido@tiscalinet.it> wrote:
> On 21 Sep 2006 01:02:32 -0700, usenet@DavidFilmer.com wrote:
>
>>Michele Dondi wrote:
>>> print +(grep !$array[$_], 0..$#array)[2], "\n";
>>
>>That's really cool. But I don't get the reason for the "+" - wuzzat?
> It' like having another pair of parens around the whole
> print() args,
Which everybody would understand immediately.
> but it's lighter IMHO.
But it introduces "startle factor" that would not be there if you
instead chose to use parenthesis around this function's argument list.
It is lighter for development, but much heavier for maintenance...
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Thu, 21 Sep 2006 13:04:33 -0400
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: How do I find the Nth index of array that is (whatever)
Message-Id: <g69d59pcfry.fsf@CN1374059D0130.kendall.corp.akamai.com>
On 21 Sep 2006, bik.mido@tiscalinet.it wrote:
> On Wed, 20 Sep 2006 11:27:21 -0400, Ted Zlatanov <tzz@lifelogs.com>
> wrote:
>
>> This uses an xor, then adds up the value at $offset until the sum
>> reaches 3. It can probably be improved and shortened.
>
> Interesting approach; but...
>
>> my @array = ('foo', '', 'bar', '', '', '', 'baz', '');
>> my @barray = map { $_ xor 1 } @array;
>
> (i) Your xor amounts to a C<!>.
Ah, I should have seen that.
> (ii) You have *two* loops: one implicit in the map() and this explicit
> one, whereas one would suffice:
>
> #!/usr/bin/perl -l
>
> use warnings;
> use strict;
> use Data::Dumper;
>
> my @array = ('foo', '', 'bar', '', '', '', 'baz', '');
>
> my $cnt;
>
> for (0..$#array) {
> $cnt += !$array[$_];
> print, last if $cnt == 3;
> }
Yes, definitely better than my version :) Thanks for taking the time
to improve it.
> Of course if put into a sub it can become quite different:
>
> sub findnth {
> my $cnt=shift;
> $cnt -= !$_[$_] or return $_ for 0..$#_;
> }
>
> print findnth 3, @array;
Cool. I think that's the best solution so far. But it should return
undef (IMO) if it doesn't find the nth false value, so just "return
undef" at the end will suffice.
Ted
------------------------------
Date: Thu, 21 Sep 2006 09:42:24 -0400
From: "John W. Kennedy" <jwkenne@attglobal.net>
Subject: Re: Learning perl - for experienced programmers
Message-Id: <8FwQg.1338$V51.1022@newsfe10.lga>
addinall wrote:
> John W. Kennedy wrote:
>> anno4000@radom.zrz.tu-berlin.de wrote:
>>> John W. Kennedy <jwkenne@attglobal.net> wrote in comp.lang.perl.misc:
>>>> anno4000@radom.zrz.tu-berlin.de wrote:
>>>>> For many years, COBOL was the *only* tool for certain IO-heavy and
>>>>> table-oriented tasks that come up in financial and administrative
>>>>> computing. At least it was the only COmmon Business Oriented
>>>>> Language and claimed to be specially fit for these purposes. People
>>>>> believed it and developed large code bases in COBOL. In reality,
>>>>> the FORTRAN of the day would have worked as well, if not better.
>>>> No, it wouldn't have, lacking, as it did (just off the top of my head):
>>>> decorated numeric output,
>>>> record I/O,
>>>> fixed-point arithmetic, and
>>>> even the most primitive string manipulation.
>>> Okay, the lack of records (what is record I/O?)
>> In C, fread/fwrite. FORTRAN binary I/O, the nearest equivalent, is
>> scatter/gather.
>
> Eh?
>
> What is wrong with
>
> OPEN
> READ
> WRITE
> CLOSE
In the first place, there were no OPEN or CLOSE statements in FORTRAN in
the time period under discussion. OPEN was achieved implicitly; CLOSE
was implied, as needed, by the END FILE and REWIND statements.
In the second place, as I said, FORTRAN binary I/O is scatter-gather,
and thus imposed an unacceptable overhead.
--
John W. Kennedy
"The blind rulers of Logres
Nourished the land on a fallacy of rational virtue."
-- Charles Williams. "Taliessin through Logres: Prelude"
------------------------------
Date: Thu, 21 Sep 2006 09:48:15 -0400
From: "John W. Kennedy" <jwkenne@attglobal.net>
Subject: Re: Learning perl - for experienced programmers
Message-Id: <DKwQg.1339$V51.388@newsfe10.lga>
anno4000@radom.zrz.tu-berlin.de wrote:
> John W. Kennedy <jwkenne@attglobal.net> wrote in comp.lang.perl.misc:
>> anno4000@radom.zrz.tu-berlin.de wrote:
>>> John W. Kennedy <jwkenne@attglobal.net> wrote in comp.lang.perl.misc:
>>>> anno4000@radom.zrz.tu-berlin.de wrote:
>>>>> For many years, COBOL was the *only* tool for certain IO-heavy and
>>>>> table-oriented tasks that come up in financial and administrative
>>>>> computing. At least it was the only COmmon Business Oriented
>>>>> Language and claimed to be specially fit for these purposes. People
>>>>> believed it and developed large code bases in COBOL. In reality,
>>>>> the FORTRAN of the day would have worked as well, if not better.
>>>> No, it wouldn't have, lacking, as it did (just off the top of my head):
>>>> decorated numeric output,
>>>> record I/O,
>>>> fixed-point arithmetic, and
>>>> even the most primitive string manipulation.
>>> Okay, the lack of records (what is record I/O?)
>> In C, fread/fwrite. FORTRAN binary I/O, the nearest equivalent, is
>> scatter/gather.
>>
>>> is serious. Other
>>> features could be supported by library routines.
>> At a completely unacceptable overhead for most of them, replacing, in
>> most cases, sequences of three to five instructions with hundreds or
>> thousands.
>
> I don't understand. If a compiler can realize an operation in a handful
> of instructions, why should a library take hundreds or thousands?
Because a compiler is aware of compile-time constants.
--
John W. Kennedy
"The blind rulers of Logres
Nourished the land on a fallacy of rational virtue."
-- Charles Williams. "Taliessin through Logres: Prelude"
------------------------------
Date: Thu, 21 Sep 2006 09:55:31 -0400
From: "John W. Kennedy" <jwkenne@attglobal.net>
Subject: Re: Learning perl - for experienced programmers
Message-Id: <rRwQg.1340$V51.927@newsfe10.lga>
addinall wrote:
> John W. Kennedy wrote:
>> anno4000@radom.zrz.tu-berlin.de wrote:
>>> For many years, COBOL was the *only* tool for certain IO-heavy and
>>> table-oriented tasks that come up in financial and administrative
>>> computing. At least it was the only COmmon Business Oriented
>>> Language and claimed to be specially fit for these purposes. People
>>> believed it and developed large code bases in COBOL. In reality,
>>> the FORTRAN of the day would have worked as well, if not better.
>> No, it wouldn't have, lacking, as it did (just off the top of my head):
>> decorated numeric output,
>
> F14.2
And what about thousand commas, "CR" and "DB", and floating currency signs?
> Fourteen digit places, reserve two for decimal.
No, fourteen characters, reserving three for decimal point and two
decimal digits.
>> record I/O,
> OPEN
> READ
> WRITE
> CLOSE
No, as I have already explained.
> Could all access record I/O
>
>> fixed-point arithmetic, and
>
> FORTRAN had support for fixed point arithmatic since the IBM
> 360/44.
No it did not. In the first place, 44PS FORTRAN supported exactly the
same language as FORTRAN G and H (it even used the same manual). In the
second place, FORTRAN has /never/ supported fixed-point arithmetic.
(Except to the extent that integer arithmetic is a subset.)
>> even the most primitive string manipulation.
>
> Eh?
>
> CHAR
> ICHAR
> TRIM
> INDEX
> LEN
> STRING // STRING2 // STRING3
None of which existed in the period in question.
--
John W. Kennedy
"The blind rulers of Logres
Nourished the land on a fallacy of rational virtue."
-- Charles Williams. "Taliessin through Logres: Prelude"
------------------------------
Date: Thu, 21 Sep 2006 20:40:36 +0300
From: "--Jani--" <janin.netosoite@TULPPAgmail.com>
Subject: Re: Net::Telnet, script exits after connection failure
Message-Id: <s8AQg.17124$4w3.10787@reader1.news.jippii.net>
> I am assuming you have a list of devices you are connecting to.. and it
> moves to the next device on the list?
>
This is what I'm trying to do. I works fine if I'm using some other action
than those in Telnet.pm and with Telnet.pm also if all devices can be
connected. But if there's one device which does not respond, the whole
script dies.
I think I'll have to do as J. Gleixner said and try to find errmode config
and change it to return.
Jani
------------------------------
Date: 21 Sep 2006 07:57:27 -0700
From: "Maitre Bart" <maitrebart@excite.com>
Subject: Priority flag and MIME::Lite
Message-Id: <1158850647.347933.273930@k70g2000cwa.googlegroups.com>
Is there a way to set the priority flag in an email to be sent using
MIME::Lite ?
I looked in the MIME::Lite doc but found nothing about priority. I
searched with Goggle in vain.
------------------------------
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 V10 Issue 9748
***************************************
