[26150] in Perl-Users-Digest
Perl-Users Digest, Issue: 8341 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sat Aug 20 09:05:24 2005
Date: Sat, 20 Aug 2005 06:05:05 -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 Sat, 20 Aug 2005 Volume: 10 Number: 8341
Today's topics:
Re: Defencive Programming and DIe Handlers (Was: Dynam <vtatila@mail.student.oulu.fi>
Re: Dynamic Typing, Defencive Programming and Prototype <tassilo.von.parseval@rwth-aachen.de>
Re: how to read file from sub-directories and do an ave <a@cuhk.edu.hk>
Re: Interfaces and Type Safety, Dynamic Typing (OOP New <mark.clementsREMOVETHIS@wanadoo.fr>
Re: Organizing data for readability and efficiency <Mark.Seger@hp.com>
Re: Very basic question on using references inside func <nobull@mail.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sat, 20 Aug 2005 13:02:14 +0300
From: "Veli-Pekka Tätilä" <vtatila@mail.student.oulu.fi>
Subject: Re: Defencive Programming and DIe Handlers (Was: Dynamic Typing etc...)
Message-Id: <de6v3m$hpp$1@news.oulu.fi>
Tassilo v. Parseval wrote:
> Ah, sorry, as always I've forgotten the trailing semicolon behind the
> assignment of the closure.
Ah, has happened to me loads. The same thing with Java's anonymous inner
classes.
> $SIG{ __DIE__ } = sub {
> ...
> };
Hey thanks a bunch, works very well. In addition to running in a very strict
mode I managed to setup myself a nice die handler. It emits the warning beep
and prints out the error on screen. This is standard stuf so far, though.
Additionally it uses the system's default SAPI voice, if available, to read
out loud the "dier message". Highly cool and saves some keyboard commands as
a screen reader user.
--
With kind regards Veli-Pekka Tätilä (vtatila@mail.student.oulu.fi)
Accessibility, game music, synthesizers and programming:
http://www.student.oulu.fi/~vtatila/
------------------------------
Date: Sat, 20 Aug 2005 07:30:19 +0200
From: "Tassilo v. Parseval" <tassilo.von.parseval@rwth-aachen.de>
Subject: Re: Dynamic Typing, Defencive Programming and Prototypes (Was: Interfaces and Type Safety)
Message-Id: <slrndgdfvb.r6.tassilo.von.parseval@localhost.localdomain>
Also sprach Veli-Pekka Tätilä:
> Tassilo v. Parseval wrote:
>> Don't the pseudo-signals __WARN__ and __DIE__ work on windows, too?
>> use warningsd FATAL => 'all';
>> $SIG{ __DIE__ } = sub {
>> for (1 .. 10) {
>> print STDERR "\a"; # need auto-flushed handle here
>> select undef, undef, undef, 0.2;
>> }
>> }
>
> I'm not actually sure having never delt with signals before. It would seem
> your example compiles but as soon as I try doing something after this sig
> handler definition, I get a syntax error. Most likely my bad, though.
Ah, sorry, as always I've forgotten the trailing semicolon behind the
assignment of the closure. Afterall, it's an ordinary statement and no
named function definition:
$SIG{ __DIE__ } = sub {
...
};
Now it'll work.
Tassilo
--
use bigint;
$n=71423350343770280161397026330337371139054411854220053437565440;
$m=-8,;;$_=$n&(0xff)<<$m,,$_>>=$m,,print+chr,,while(($m+=8)<=200);
------------------------------
Date: Sat, 20 Aug 2005 18:58:49 +0800
From: "Ross" <a@cuhk.edu.hk>
Subject: Re: how to read file from sub-directories and do an average?
Message-Id: <de72c7$2m8m$1@justice.itsc.cuhk.edu.hk>
if i don't sort the dir names, it cannot guarantee to take average
correctly, if so like using:
$curdir = `pwd`;
chop $curdir;
$curdir = $curdir . "/$ARGV[0]";
@inputdirname = readdir(WORKINGDIR);
foreach $inputdirname (sort @inputdirname) {
print $curdir.$inputdirname; <STDIN>;
opendir(SUBDIR, $curdir.$inputdirname) || die ("unable to open dir
named $inputdirname $!");
<processing>
chdir ($curdir);
<counting>
}
. and .. are taken into account
------------------------------
Date: Sat, 20 Aug 2005 09:12:25 +0200
From: Mark Clements <mark.clementsREMOVETHIS@wanadoo.fr>
Subject: Re: Interfaces and Type Safety, Dynamic Typing (OOP Newbie in Perl)
Message-Id: <4306d7c1$0$22302$8fcfb975@news.wanadoo.fr>
Tassilo v. Parseval wrote:
> Also sprach Veli-Pekka Tätilä:
<snip>
>
>>in the Java implementation, too. And as for friends, I was testing some
>>badly written awt code with J-Unit (is there a P-Unit or something for
>>Perl?), and dearly wished I could just say hey gimme full access when I'm
>>testing. In stead I had to manually hack the code changing private parts to
>>public in places.
>
<snip>
> As for P-Unit, I am not entirely familiar with what J-Unit does. As far
> as I know it's some sort of testing framework. Similar things exist for
> Perl. See all the Test:: modules on the CPAN that are used for most CPAN
> modules when you do 'make test'.
PerlUnit
http://perlunit.sourceforge.net/
Mark
------------------------------
Date: Sat, 20 Aug 2005 06:09:27 -0400
From: Mark Seger <Mark.Seger@hp.com>
Subject: Re: Organizing data for readability and efficiency
Message-Id: <43070157$1@usenet01.boi.hp.com>
Anno Siegel wrote:
> Mark Seger <Mark.Seger@hp.com> wrote in comp.lang.perl.misc:
>
>>>Put the description of each plot into a hash with usefully named keys.
>>>Then make a list of those:
>>>
>>>
>>> my @plots;
>>>
>>> push @plots, {
>>> title => 'Plot 13',
>>> ymax => 120,
>>> # ...
>>> };
>>>
>>> push @plots, {
>>> title => 'Plot 14',
>>> ymax => 1.5,
>>> # ...
>>> };
>>
>>good to know I was on the right track with my thinking. now to add a
>>slightly differnt wrinkle, in some cases I'll have mulitple not single
>>elements such as multiple lines on the same plot and therefore a legend
>>with multiple plot titles and even mulitple Y-axis entries. how would I
>> mix in arrays with what you described above? can I have something like
>>
>>ymax => @max
>>legend => @names
>>
>>where max is an array of the maximums for each plot line?
>
>
> That is elementary Perl. Read perlref and perldsc.
>
>
>>And finally, how is the efficiency of all this? Something like a plot
>
>
> You appear to be obsessed with efficiency. You even wrote me in private
> about it, but I want to keep it on Usenet, I won't reply.
>
> At this stage of programming, efficiency is no concern of yours. The
> point to begin worrying about efficiency is when you have a correct and
> working program and it turns out to be slow, not before.
I'm afraid I have to strongly disagree with. I've known far to many
programmers who simply 'get it running' and then try to make it
efficient. Sometimes this cannot be done without an entire
redesign/rewrite, perhaps one of the best examples of this is database
design in which your table organization is plan ineficient.
I am at the point where I've done some preliminary design and want to
ensure I 'get it right' when I do it for real.
I do admit many times you can 'get it wrong' and still recover as was
the case when I found by changing a simple thing like
if ($x=~/string1|string2/)
to
if ($x=~/string1) || ($x=~/string2)
was much more efficient
> Also I fully agree with Xho's take that the organization of your data
> is unlikely to have a noticeable effect on the runtime.
again I have to disagree. perhaps I could have stated my question about
how the internals of arrays vs hashes are organized but I really didn't
want to go there. When I think of an array I think of adding and index
to a pointer to get the the cell you desire. When I think of a hash I
think of having to do some sort of lookup which seems like more overhead
to me.
> Thirdly, optimization is highly dependent on how the program is used,
> what hardware it is run on, with what frequency, and so on. All we
> have from you is a very sketchy plan to plot a lot of graphics. That
> is no base to discuss efficiency. Please don't insist, you'll only
> annoy people.
I guess all I can say in my defence is that when I started the topic I
did try to say I was trying to avoid making things too complicted, but I
guess I failed... 8-(
>>title or legend is only going to be accessed once when I draw the plot,
>>but the ymax represents something I have to check against for every data
>>point. Are there any inefficiencies worth worrying about in accessing
>>that data within a hash? In general when I need to access something
>>100Ks of times I do worry about hashes vs arrays.
>
>
> Don't. If you have a plot to make, it won't matter if you have to access
> an array or a hash to do so. It won't even matter if you have to access
> it a hundred or a thousand times per plot, the plot time will still
> dominate. It's like planning a 1000 mile journey and asking everybody
> how to clear your driveway so you'll have a quick start.
All can say with reference to my earlier comment about reorganizing a
single pattern match in an 'if' statement is that I had a script that
was reading something like a few millions lines of text and analyzing
it. It took something like a minute to run before I modified it and
after the modification I shaved off over 10 seconds, which to me is a
very significant thing.
Whenever I write a script that doesn't process all that much data I
don't worry too much about efficiency but when there is a lot of data I
get scared.
-mark
------------------------------
Date: Sat, 20 Aug 2005 10:40:52 +0100
From: Brian McCauley <nobull@mail.com>
Subject: Re: Very basic question on using references inside functions
Message-Id: <de6tr6$up5$1@redhat2.bham.ac.uk>
Anno Siegel wrote:
> You know the reason to avoid package variables: exposure.
I think this is often over-played. Perl allows you to play about with
package variables in other packages just as it lets you fiddle with the
internal of objects. But it's fairly obvious when you are doing it.
> If you have
> a rogue function do_something() (say, imported from somewhere), which does
>
> sub do_something {
> # ....
> our $y = 'something else';
> }
If this was imported from elsewhere it would be talking about a $y in a
different package so there would be no problem. If it's not imported
and is defined within the same module then it's just the usual problem
of managing global variables. (Note when I say 'global' I don't mean
'package', I mean 'package or file-scoped lexical'). This is why you
should always minimize your use of global variables. But sometimes they
are the right tool for the job.
> then calling do_something() while "*y = \ $_[ 0]" is in effect has
> unexpected and hard-to-trace consequences:
>
> sub foo6 {
> our $y;
> *y = \ shift();
> do_something()
> $y =~ s/g/k/g;
> }
If you are going to use package variables it's wise to get into the
habit of using local().
That said I would _not_ use typeglobs for this reason - I'd use one of
the other approaches given in this thead.
------------------------------
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 8341
***************************************
