[13319] in Perl-Users-Digest
Perl-Users Digest, Issue: 729 Volume: 9
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue Sep 7 09:07:27 1999
Date: Tue, 7 Sep 1999 06: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 Tue, 7 Sep 1999 Volume: 9 Number: 729
Today's topics:
Re: "Use <module>" Decide at run-time? (Mitchell Morris)
Computational Counterpoint (Re: fork?) <tchrist@mox.perl.com>
How to get the result of a system call <schan_ca@geocities.com>
Re: How to get the result of a system call <schan_ca@geocities.com>
Re: how to make sort() case insensitive? <Allan@due.net>
Re: How to match as most as possible ? <rhomberg@ife.ee.ethz.ch>
large dataset problem <s.trew@qub.ac.uk>
Re: mysql interview (Matthew Bafford)
Re: mysql interview (Sam Holden)
Soor PERl Newbie Q <pr-pool@megacult.de>
Re: XML::Parser help needed <chris@inta.net.uk>
XS and tie <dada@divinf.it>
Y2K bugs on the Internet finsol@ts.co.nz
Re: Y2K bugs on the Internet (Chine Bleu)
Digest Administrivia (Last modified: 1 Jul 99) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 7 Sep 1999 11:38:09 GMT
From: mgm@unpkhswm04.bscc.bls.com (Mitchell Morris)
Subject: Re: "Use <module>" Decide at run-time?
Message-Id: <slrn7t9u91.nki.mgm@unpkhswm04.bscc.bls.com>
In article <37D2CC46.8B8E394@trw.com>, Robert F wrote:
>Thank you for this suggestion. However, when I implement it, I get an error
>which says
>
>"Too many arguments for HandleError: handleError at driver line 8, near
>"DHCPGlobalParameters)".
>
>I'm lost. I think I'm in over my head using this advanced feature.
>
>
>Joern Reder wrote:
>
>> Robert F wrote:
>>
>> > sub handleError() {
^^
[snip]
You have prototyped this as a function that accepts no parameters. Perhaps
then you should either (a) not give it any parameters, or (b) change the
prototype. I suspect that (b) is the correct course of action.
The relevant doc is "perlsub" in the section labeled "Prototypes"
$ perldoc perlsub
HTH,
+Mitchell
--
Mitchell Morris
OK, I'm weird! But I'm saving up to be eccentric.
------------------------------
Date: 6 Sep 1999 20:19:39 -0700
From: Tom Christiansen <tchrist@mox.perl.com>
Subject: Computational Counterpoint (Re: fork?)
Message-Id: <37d4763b@cs.colorado.edu>
[courtesy cc of this posting mailed to cited author]
In comp.lang.perl.misc, Dan Sugalski <dan@tuatha.sidhe.org> writes:
:(And threads are *not* tough to program--they're really a snap. I don't
:understand the mental blocks folks have about 'em.
I do. It's very simple, actually. You can choose a world with
multiple agents simultaneously active in which the agents can only
affect the state of one another through explicit mechanisms, or else
you can run in a free-for-all world more reminiscent of Core Wars
battles or Commodore-64s. Imagine if every process were to run as
root vis-à-vis access to the filesystem. This is a very scary idea.
Without protection on data resources, mistakes can and do happen far
more frequently than they occur on systems with built-in protections.
Compare Unix or VMS with CP/M, MS-DOS, or Mac OS to see what I mean.
With threads, you have no implicit protections, so everything has to be
very carefully finagled. If you forget, you will sometimes know that
things have gone awry, but sometimes you won't. And worst of all,
whether something blows up is not always a reproducible property.
The vicissitudes of your scheduler get in the way of deterministic
behavior, leaving you with conflicting results across multiple runs.
Even when you use locking, you're still treading on thinner ice than
you would be if separate processes were used. After all, one agent
can completely forget to lock a shared data object and thus render all
other agents' careful locking completely useless. Or you could get
into deadlock based on ordering issues, again subject to the whims
of your scheduler and the phase of the moon. I'll certainly grant
that the implicit freeing up of Perl's lexical locks are a boon, but
that doesn't mean locking is always a trivial matter. There are also
important correctness issues associated with locking, things you learn
at upper-level undergraduate courses in computer science.
Some of these theoretical issues well known to serious database engineers
and operating system (read: kernel) designers, but the programmer
of more modest aspirations does not normally have to deal with them.
You don't have to be a compsci kind of person to write simple script.
But writing most multithreaded applications is just not the same thing.
There's also the practical issue that most operating systems are set
up in terms not of a threading model but a process one. This means
that traditional systems programming techniques are often ill-fitted
to a threading model. I'm thinking about more than just signals.
There are a lot of other considerations, like resource limits,
shared file descriptors, current working directory, or even mere
process identifiers. What happens if you spawn many threads, and one
does a chdir(2)? What happens if they all call accept(2) on the same
shared socket descriptor? What facilities does the provider of your
operating system distribution give you for debugging, profiling, and
analysing threaded programs? Does your ps(1) program allow you to see
where in the kernel each separate thread is blocked in the WCHAN column?
Does your kernel even allow such a thing? What about asyync I/O?
Here's another way of looking at how multithreading is harder than
single-threaded programming: musically. It's certainly easier to
compose a piece of music for an instrument that's only capable of
producing one note at a time, such as the recorder or the human voice,
than it is for a full orchestra all playing in parallel. It's also a
lot easier to play. Even the members of the viol family, which have
several strings, are usually played with one note (or pair of notes)
occurring sequentially after the previous one, since simply playing upon
two strings at an interval a third or a fifth apart is not the separate,
independent melodic motion I'm thinking of.
Compared with violin, it's much harder to write and play something
for the piano where you have multiple simultaneous agents, but it does
allow for contrapuntal polyphony unreachable by a single human voice.
Consider now a full orchestral score. Not only is it hard to write,
it's hard to even read, because you need to keep track of what's going on
by multiple agents in parallel. That's harder to hold in your head all
at once.
Designing a multithreaded program can be a lot like designing a fugue
or any other bit of counterpoint. In both the musical and the computer
cases, you have independent agents making linear progress through the
work, as the hardware clock or the metronome relentlessly marks off one
tick after another. At the same time, the individual threads can seldom
get away with completely ignoring one another.
The vertical, harmonic reading of the piece is as important as the
horizontal, melodic one. This isn't just because of abstruse concerns
based on music theory, like avoiding parallel motion especially in
perfect intervals. Contention for shared resources was as much a
practical concern to the composer as to the programmer. You don't want
to write something that the physical constraints of the instrument would
render unplayable as your fingers got all tangled up crisscrossing over
the same instrument.
J. S. Bach, uncontested master of musical counterpoint, produced his
contrapuntal works for a variety of "processor types", if you would.
Not all operating systems were equally amenable to these multithreaded
applications. Consider a fugue written for a keyboard instrument such
as a piano, harpsichord, or clavichord. There is only one way to access
each note, so you have data contention between different melodic lines,
much as you have in a multithreaded program. Some algorithms prove
particularly challenging to elaborate, resulting in not only overlapping
fingers, but crossed or tortuously overlapping hands.
Yet take such an arduous piece and play it upon an organ, and sometimes
something miraculous happens: it becomes easy! That's because unlike
the aforementioned keyboard instruments, which all have but a single
keyboard, an organ can have several, both manuals and pedals. This can
allow the amateur organist to execute multiple threads of overlapping
access with hardly a blink. That's because while one hand is dancing
upon one manual playing one of the fugue's melodies (that is, executing
a melodic thread), another one can be executing a melody in a different
manaul that tonally overlaps the first one in a way that even the most
accomplished of pianists to throw up his hands in defeat. Add in the
pedals, and you get yet another line.
An organ is like three (or more) separate cooperating processes, two
(or more) with five threads each and the last one with two threads.
Because of the organ's unique property of being able to produce two
completely distinct but overlapping melodies, the organist can do things
the pianist can never dream of. And much as a process can after a fork
set distinct, per-process attributes in each process such as euid, open
FDs, cwd, etc., so too can the organist set different timbres in the
different keyboards, even when these would otherwise sound the same pitch.
How else can multithreaded parallelism in the form of musical counterpoint
be achieved? You could of course use multiple instruments, as we see
throughout the Musical Offering or in some of Bach's choral works.
But that doesn't do you any good if you want to perform a fugue for a
string quartet or an SATB-scored vocal piece when you're all alone.
Setting aside uncommon cases like the PVM library, searching for Mersenne
primes, and SETI analysis, using completely separate instruments is the
exception to the normal state of using one computer to run one program.
But just as you do not truly need multiple CPUs in one computer to execute
a multithreaded program, to compose a piece of musical counterpoint
neither do you absolutely require a strongly multithreaded instrument
like an organ nor even a loosely multithreaded instrument like a piano.
At least, not if your name happens to be Johann Sebastian Bach.
It's often easier to split a task into three separate programs than it is
to do all sub-tasks at once in the same program. Certainly it would be
easier to execute a three-voice fugue that used three separate violins
than it would be to do so using just one instrument. In fact, it's
incredibly difficult to use just one violin for this task. The cello
and the violin each have several strings, and unlike the piano but like
the organ, the same note can be played on different strings. But these
are still essentially single-threaded because there is just one bow.
Despite this apparently fundamental restriction, Bach also wrote
contrapuntal works for instruments that would otherwise appear to be
inherently single threaded. Consider Bach's six cello suites, or his
partitas and sonatas for unaccompanied violin--some of which Larry Wall
can occasionally be badgered into playing for you on his own violin.
The violin fugues are particularly notable, for here the Master has
deftly created the aural illusion of parallel execution by multiple
agents despite the inescapable fact that only one is actually present.
How was this remarkable illusion created? The same way it's done on
a uniprocessor computer system: with time-slicing, or if you would,
through coöperative multitasking.
Employing all the artifice of a mind intimately acquainted with
parallel elaborations on instruments built for that kind of parallel
execution (consider the St Anne Fugue for organ), Bach in his works
for unaccompanied violin used the humble fiddle to produce astonishing
cognitive effects on the human mind's musical processing centers.
It's not just simple time-slicing as your bow quickly switches back
and forth between the two or three different melodic lines, although
certainly there is plenty of that going on.
No, it's much more, something almost magical. Astonishingly, there are
some notes in those pieces that literally cannot be played upon that
instrument--and yet he wrote them in despite this! In some cases, the
listener perceives notes that aren't truly there, as the mind fills in
the tones it expects to encounter at those points.
Most of us, myself certainly included, can only regard in abject terror
the musical intelligence that could conceive of creating so convincing
a work of multiple voices upon so single-threaded an instrument
as the violin. When I see a tightly integrated, highly parallel,
multithreaded application running in a single program without any of the
modern mechanisms of protection and separation that we have all come
to rely upon, something of the same awe is conjured up. Just because
master kernel designers can perform such feats doesn't mean you should
immediately expect everyone else to be able to so just as easily.
--tom
--
"Woman was created from the rib of man; Not from his head to be thought of
only, nor from his hand to be owned, nor from his foot to be beneath, but from
under his arm to be protected, from his side, to be equal, and from his heart
to be loved. . ."
------------------------------
Date: Tue, 07 Sep 1999 05:18:14 -0700
From: stephen chan <schan_ca@geocities.com>
Subject: How to get the result of a system call
Message-Id: <37D50286.B0849670@geocities.com>
Hello:
How do I get the result of a system() call?
I need to do a "cksum" on a bunch of files.
This code use system to execute the "cksum"
command:
$file="a_program";
system('cksum',$file);
It works, but prints the result of "cksum" on screen.
I need the result of "cksum" in my Perl script
to further checking.
Thanks
Stephen
------------------------------
Date: Tue, 07 Sep 1999 05:55:12 -0700
From: stephen chan <schan_ca@geocities.com>
Subject: Re: How to get the result of a system call
Message-Id: <37D50B30.8680DEC9@geocities.com>
No need to answer.
I should have done:
$result = `cksum, $file`;
Thanks
======================================
stephen chan wrote:
> Hello:
>
> How do I get the result of a system() call?
> I need to do a "cksum" on a bunch of files.
> This code use system to execute the "cksum"
> command:
>
> $file="a_program";
> system('cksum',$file);
>
> It works, but prints the result of "cksum" on screen.
> I need the result of "cksum" in my Perl script
> to further checking.
>
> Thanks
> Stephen
------------------------------
Date: Tue, 7 Sep 1999 08:01:42 -0400
From: "Allan M. Due" <Allan@due.net>
Subject: Re: how to make sort() case insensitive?
Message-Id: <7r2u7n$e18$1@nntp9.atl.mindspring.net>
[L] Vicious! wrote in message ...
:Actually I agree, but the could you do me a favour. I run Win98, and
:when I run 'perldoc -f sort' there is no way to actually read the
:stuff. | more doesn't work either and I coulnd find any page switches,
:neither can I write the results to a file using >sort.txt. Suggestions?
:Thnx for helping, by the way!
: (o:
more will work it just needs to be in the batch file. So, one solution
is to open the perldoc.bat file and add | more to the line which reads
perl -x -S "%0" %1 %2 %3 %4 %5 %6 %7 %8 %9
so it becomes:
perl -x -S "%0" %1 %2 %3 %4 %5 %6 %7 %8 %9 | more
I have no idea why this is not distributed this way.
HTH
AmD
--
$email{'Allan M. Due'} = ' All@n.Due.net ';
--random quote --
If the automobile had followed the same development cycle as the
computer, a Rolls-Royce would today cost $100, get one million miles to
the gallon, and explode once a year, killing everyone inside.
- Robert X Cringely
------------------------------
Date: Tue, 07 Sep 1999 13:40:25 +0200
From: Alex Rhomberg <rhomberg@ife.ee.ethz.ch>
Subject: Re: How to match as most as possible ?
Message-Id: <37D4F9A9.44EF5802@ife.ee.ethz.ch>
marcza@my-deja.com wrote:
>
> Sorry, you misunderstood me the same way as Ken.
>
> When I said "maximal possible" matching
> I meant it regarding the array. The maximal (=last) element of the
> array is $A[73]. So $A[77] should NOT be matched. Instead $A[7]
> should be taken. The desired output is
>
> OUT=aAbb3a abaonebaaaAAA bAtwo7aabthreeaa
>
> Concerning the syntax of ...A[0..73].. I know that this expression
> is interpretated as you mentioned. This was only a "pseudo" syntax
> to show a "similar" wish-to-have syntax.
> I am searching a correct perl replacement.
>
> Thank you
In this case, find a Perl RE that matches the numbers you want.
in your case, this would be:
$text =~ s/(A0*(7[1-30]|[1-6]?\d))/$A[$2]/g;
which discards any zeroes after A, then matches the numbers
70-73 (7[1..30]) or 0-69 ([1..6]?\d)
- Alex
perl -e'@A=qw/Perl another Hacker Just/;$_="A00354 A0133 A0
A243";s/A0*([01-3])\d*/$A[$1]/g;print"$_\n";'
------------------------------
Date: Mon, 6 Sep 1999 12:23:32 +0100
From: "Stephen Trew" <s.trew@qub.ac.uk>
Subject: large dataset problem
Message-Id: <7r2sbr$re1$1@news.qub.ac.uk>
Hi,
I have a very large dataset of monthly sea surface temperature covering many
years.
The data is in text file in this format:
1 1990 [ month and year ]
-1000 -1000 -1000 -1000 ...... continues for 360 columns
-1000 -1000 -1000 -1000
.
. continues for 180 rows
.
2 1990
-1000 -1000 -1000 -1000 ...... continues for 360 columns
-1000 -1000 -1000 -1000
.
. continues for 180 rows
.
etc.
Simply put, there are 360 columns of data and 180 rows for each month, thus
the data is in 1 degree cells and covers the entire globe. The datafile
contains eight years worth, about 60 months.
I need to extract a value at a specific longitude and latitude for each
month, e.g.. 6W and 49N equals column 174 and row 41 for each month. What
is the best way to build a script to do this?
Thanks
Stephen
---
<><
Stephen Trew
School of Geography, Queen's University, Belfast BT7 1NN
Tel. +44(0)28 90 273367, Fax. +44(0)28 90 321280
S.Trew@Bigfoot.com ICQ: 15302096
www.bigfoot.com/~S.Trew/Home-Page
------------------------------
Date: Tue, 07 Sep 1999 11:10:43 GMT
From: *@dragons.duesouth.net (Matthew Bafford)
Subject: Re: mysql interview
Message-Id: <slrn7t9rvt.ne.*@dragons.duesouth.net>
Andrew Green <green@argonet.co.uk>, thinking with his hands, posted the
following to comp.lang.perl.misc:
: Failing that, I'd find it *very* interesting to read an informed critique
: of the book - especially that chapter - which points out errors or poor
Uri pointed out a few problems with it a while back:
Newsgroups: comp.lang.perl.misc
Subject: Re: is our reese the author of mysql book?
References: <x7g11qanob.fsf@home.sysarch.com> <slrn7r2bi2.cat.abigail@alexandra.delanet.com>
From: Uri Guttman <uri@sysarch.com>
Message-ID: <x7d7wu9uso.fsf@home.sysarch.com>
Organization: Sysarch, Inc.
Date: 11 Aug 1999 11:55:03 -0400
: Many thanks,
HTH,
: Andrew.
--Matthew
------------------------------
Date: 7 Sep 1999 11:25:13 GMT
From: sholden@pgrad.cs.usyd.edu.au (Sam Holden)
Subject: Re: mysql interview
Message-Id: <slrn7t9tgp.t40.sholden@pgrad.cs.usyd.edu.au>
On Tue, 07 Sep 1999 10:33:50 +0100, Andrew Green <green@argonet.co.uk> wrote:
>In article <slrn7t93f6.lt8.abigail@alexandra.delanet.com>,
> Abigail <abigail@delanet.com> wrote:
>
>> I'm just trying to prevent people from spending money to buy your books.
>
>Too damn late for me, I'm afraid.
>
>I've wanted to learn how to use MySQL databases in my Perl programs for
>quite some time, and so when this book came out, I was delighted: I learn
>things *much* better from books than on screen documents, particularly as
>I tend to find the online docs quite terse, unless it comes to using them
>for reference purposes.
I also like to learn how to use things from a book. Being able to read
stuff on the train is great. I use on-line stuff more, since it is
much better for searching and cut-and-paste programming. But I own a book
for almost every language amd tool-kit I use regularly. Perl/Tk is the
only thing I don't own the book for - I refuse to pay money
for a book with so many obvious errors (the third printing isn't in
my bookshop, so it may be better)
I killfiled Mr Reese a long time ago and thus missed the fun of this
thread. However, I'd just like to add that I'm using a mySQL with the
stuff I'm working on now. I picked up this book in the bookshop on the
weekend and then saw the author list and quickly put it back. So mySQL
will be another thing I don't own the book for.
It might be a good book on mySQL, however, I refuse to give my money to
Mr Reese. Hopefully, karma will work its magic with Mr Reese. I almost
feel sorry for the other authors - how could you survive working with
such a man.
--
Sam
PC's are backwards ... throw them out! Linux is ok though.
--Rob Pike (on the subject of CR/LF etc)
------------------------------
Date: Tue, 07 Sep 1999 14:54:16 +0200
From: David Hefendehl <pr-pool@megacult.de>
Subject: Soor PERl Newbie Q
Message-Id: <37D50AF8.5D0679AB@megacult.de>
Dear all,
I try to read from a .txt file values wich are speratet with :
the file looks like this
value1:value2:valu3
value4:value5:value6
...
Ok I know how to open the file and store the values in an aray
open(FILE, ...
What I now want to do is to give all values in the first row the
Skalarname $1 in the second $2 in the third $3 to print
Name1=value1 Name2=value2 Name3=value3 <br>
Name1=value4 Name2=value5 Name=value5 <br>
...
Please help I'll tryed so many ways but it wont work. Somtimes I only
get the first sometimes nothing...
THANX
DAVE
--
David Hefendehl
Brüsseler Str. 96
50674 Köln
0177/29 25 0 77
http://www.netzgeschmack.de
------------------------------
Date: Tue, 7 Sep 1999 12:20:56 +0100
From: "Chris Denman" <chris@inta.net.uk>
Subject: Re: XML::Parser help needed
Message-Id: <7r2scm$1lqq$1@news2.vas-net.net>
Thanks for that info, I had almost given up hope!
Regards,
Chris Denman
------------------------------
Date: Tue, 7 Sep 1999 13:07:38 +0200
From: "Aldo Calpini" <dada@divinf.it>
Subject: XS and tie
Message-Id: <7r2rki$mrb$1@fe1.cs.interbusiness.it>
good morning people.
I have an interesting problem that can be concisely
expressed as a question:
does the perlguts API for hashes (in particular,
hv_store) support tied hashes and their magic?
the background is:
I have developed an XS extension that now I want to
tie; the constructor was something like:
package some;
sub new {
my $class = shift;
my $self = {};
return bless $self, $class;
}
now it looks like:
package other;
sub TIEHASH {
my $class = shift;
my $object = shift;
return bless $object, $class;
}
package some;
@ISA = qw( other );
sub new {
my $class = shift;
my %tied = ();
tie %tied, $class;
my $self = bless \%tied, $class;
return $self;
}
seems somehow tricky, I know, and I'm not sure it is
conceptually correct, but it's the only I've found to
end up with an object of class 'some' that acts both
as a regular blessed hash and a tied one (except some
DESTROY problem that I've not faced yet ;-)...
that said, my problem is that while constructing, I
have to call some C routine (in the XS part of the
module) that does some operation on $self, including
storing and fetching keys from it; this is done in
the code with something like:
HV* self = (HV*) SvRV(ST(0));
hv_store(self, "-name", 5, someValue, 0);
well, it seems that this call doesn't trigger the
STORE method at all, while for example an hv_fetch()
on self seems to work as expected, eg. the FETCH
method is triggered.
if I move the storing part in the PM file, everything
goes smooth, eg. a call to:
$self->{-name} = $someValue;
produces the desired result.... but I would like to
keep the hv_store() and let it work with the tie
magic.
ideas anyone?
__END__
# Aldo Calpini
print sort {$_{$a} cmp $_{$b}} values %{{split undef,
"xritajbugne fahokem csuctawer jhdtlrnpqloevkshpr"}};
------------------------------
Date: Tue, 07 Sep 1999 12:40:22 GMT
From: finsol@ts.co.nz
Subject: Y2K bugs on the Internet
Message-Id: <7r313k$dcp$1@nnrp1.deja.com>
I have decided to respond to the feedback I have received regarding
"Perl Y2K Bugs on the Internet" in one hit. This feedback relates to my
article at URL:
http://www.y2kinfo.com/journal/features/0899_amon.html
and the internet Y2K bugs collated at URL:
http://www.ts.co.nz/~finsol/y2k_examples.htm
Several responses indicated that the Y2K bugs found were only created by
the incompetent and the inexperienced. This has prompted me to analyse
the locations of the first 100 Y2K bugs listed in my research - these
were listed by URL so were somewhat random.
The results were as follows:
Items: 5, 6 & 100 - Emporia State University, Kansas
Items: 10 & 11 - The University of Kansas
Items: 26 & 27 - Inchon National University of Education, Department of
Computer-Education, Korea
Item: 30 Math and Computer Science Department, Shippensburg University
Item: 34 Massachusetts Institute of Technology, Department of Ocean
Engineering, Design Laboratory
Item: 40. Division of Physiologic Imaging, Department of Radiology,
University of Iowa College of Medicine (written by National Science
Foundation)
Item: 42. The University of Mississippi
Item: 51 52 & 53. Clarkson University, New York, Society of Technical
Writers, Association of Technical Writers and Editors
Item: 60 RMIT University, Melbourne
Item: 79, 80, 83, 84 & 85 Charles Sturt University, NSW, Australia
Items: 69 & 70 Drexel University, Philadelphia
Item: 86 University of Texas at Austin but written by National Science
Foundation
Item: 99 Department of Molecular Biology and Pharmacology, Washington
University School of Medicine, Saint Louis, Missouri
That's 24 in total so far, with 200+ to go. A count of all .edu and .ac
DNS's in my sample gives an overall total of 86 - this is 28% of the
total sample.
All 300+ Y2K bugs plus graphical analysis (which now includes .edu and
.ac DNS analysis) is available at:
http://www.ts.co.nz/~finsol/y2k_examples.htm
So its not the incompetents, idiots or script-kiddies creating and/or
reproducing these Y2K bugs as has been so often stated - unless you want
to include some of the world's top brains in this category. This code
has, in many cases, been published at reputable web sites as examples of
how to code or as tutorials.
It was suggested I notify each of the transgressors of their guilt. As
what I have found is only the tip of the ice berg I cannot see that this
would achieve much. What would be of more benefit is for notable
programmers to speak out on the issue in industry publications and
forums most frequently used by developers. A reduction of the incidence
of these errors on the web would be an indication that the message is
being heard.
What my research sample shows is that anyone can make Y2K errors - it is
just a matter of oversight and error and we are all human. In the case
of the booby trap code problem it is a case of making a logical
assumption which is incorrect.
Is it any surprise that there is such a lot of Y2K bugged code about
when many prominent programmers do very little in informing their
programming community on this subject and in some cases deny there is
indeed any problem?
Despite frequent admonishments that programmers should 'read the
manual', it is clear that Perl is often learnt by example. The
following Perl book review makes this point.
http://www.cuug.ab.ca/CUUGer/9711/proglernperl.html
Perl: A Review of the book "Programming Perl" (The O'Reilly 'Camel
book')
and a shorter one of "Learning Perl" (The 'Llama Book')
and of the language in general
by Roy Brander
"Perl, while basically a computer language that mostly has a simple
grammar and syntax, should be approached like a human language: learn it
by example, adding one new trick or twist with every repetition.
Learning Perl excels at this by embellishing a few example programs a
little more every page with the new material just discussed. By the end
of each chapter, you are proudly trying out impressively powerful
programs with a dozen new features you've learned."
I do not have any grudge against Perl, in fact the language appears to
be very intriguing and maybe one day I'll be developing in it. What I
do have a problem with is programmers who are so besotted with their
language of choice, they refuse to use logic. Even when faced with
hundreds of examples of Y2K bugs, they still see no particular problem
that needs to be addressed. The thinking appears to be that Y2K, when
they acknowledge it exists at all, relates to other languages, not Perl
(or Java, C, C++, Javascript etc.). Others see it as an opportunity for
humor and derisive remarks which obscures the issue being discussed.
Any programming experts who would like to assist getting the message out
there and help in fixing some of the problems, could:
(a) Provide guidelines on what types of Y2K problems to look for in
Perl, Java, C, C++, Javascript etc.
(b) Write software to scan code for the more obvious errors and/or
highlight where dates are manipulated in the code. To cover costs you
could even (heaven forbid!) charge for the software
(c) Acknowledge to readers in this forum that all mission critical code
does need to be checked for Y2K problems, regardless of programming
language.
My principal motives for posting these messages re Y2K are:
(a) A few more programmers may get the message
(b) The feedback provides a barometer that I and others can use to
measure just much the Y2K message has got through to the programming
community. Feedback generated by my last post would indicate that Y2K
awareness is still a very big problem.
If anyone is tiring of this subject then they can either ignore the
messages or use their 'kill file' facility. Alternatively you may
prefer a moderated newsgroup - eg. comp.lang.perl.moderated. However, I
would think that at this time Y2K should be a very relevant issue to
everyone, programmers in particular.
And to the person who objected to my classifying C & C++ in the same
category. Would making distinctions between C and C++ Y2K bugs make the
issue any clearer? I don't think so.
Jocelyn Amon
--
Financial Solutions Limited
http://www.ts.co.nz/~finsol/
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
Date: Tue, 07 Sep 1999 04:55:56 -0800
From: saratoga@myremarq.com (Chine Bleu)
Subject: Re: Y2K bugs on the Internet
Message-Id: <saratoga-0709990455570001@ppp-206-170-2-240.sntc01.pacbell.net>
/ Several responses indicated that the Y2K bugs found were only created by
/ the incompetent and the inexperienced. This has prompted me to analyse
/ the locations of the first 100 Y2K bugs listed in my research - these
/ were listed by URL so were somewhat random.
If you want to watch history repeat itself from the beginning, ask people
about the Y2K38 problem, when the Unix clock overflows.
--
Collective Against Consensual Sanity
v0.1 is sort of up. http://www.angelfire.com/ca3/cacs
For a free CACS T-shirt send $42 shipping and handling.
pretty? http://www.geocities.com/SoHo/Studios/5079/
------------------------------
Date: 1 Jul 99 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 1 Jul 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.
To submit articles to comp.lang.perl.misc (and this Digest), send your
article to perl-users@ruby.oce.orst.edu.
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.
The Meta-FAQ, an article containing information about the FAQ, is
available by requesting "send perl-users meta-faq" from
almanac@ruby.oce.orst.edu. The real FAQ, as it appeared last in the
newsgroup, can be retrieved with the request "send perl-users FAQ" from
almanac@ruby.oce.orst.edu. Due to their sizes, neither the Meta-FAQ nor
the FAQ are included in the digest.
The "mini-FAQ", which is an updated version of the Meta-FAQ, is
available by requesting "send perl-users mini-faq" from
almanac@ruby.oce.orst.edu.
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 729
*************************************
