[30025] in Perl-Users-Digest
Perl-Users Digest, Issue: 1268 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun Feb 10 16:09:43 2008
Date: Sun, 10 Feb 2008 13:09:09 -0800 (PST)
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, 10 Feb 2008 Volume: 11 Number: 1268
Today's topics:
Re: "Use of uninitialized value" warning <joost@zeekat.nl>
Re: "Use of uninitialized value" warning <rvtol+news@isolution.nl>
CHEAP DIOR, AF1, DSQUARED, BAPESTA, HOGAN, CHANEL, VERS <globwholesale15@126.com>
Modules, global variables and such <january.weiner@gmail.com>
Re: Modules, global variables and such <noreply@gunnar.cc>
Re: Modules, global variables and such <january.weiner@gmail.com>
Re: Modules, global variables and such <abigail@abigail.be>
Re: Modules, global variables and such <abigail@abigail.be>
Re: Modules, global variables and such <january.weiner@gmail.com>
Re: Modules, global variables and such <january.weiner@gmail.com>
Re: Modules, global variables and such <pue@gmx.net>
Re: Modules, global variables and such <noreply@gunnar.cc>
Re: Modules, global variables and such <ben@morrow.me.uk>
Re: Modules, global variables and such <mark.clementsREMOVETHIS@wanadoo.fr>
Re: Modules, global variables and such <ben@morrow.me.uk>
Re: Modules, global variables and such <abigail@abigail.be>
Re: Modules, global variables and such <abigail@abigail.be>
Re: PerlCtrl's IDL and enums <ben@morrow.me.uk>
Re: Question about PDL <joost@zeekat.nl>
Re: Question about PDL <january.weiner@gmail.com>
Re: Using END and the die function <pgodfrin@gmail.com>
Re: Using END and the die function <usenet05@drabble.me.uk>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sun, 10 Feb 2008 14:45:55 +0100
From: Joost Diepenmaat <joost@zeekat.nl>
Subject: Re: "Use of uninitialized value" warning
Message-Id: <87lk5sdiwc.fsf@zeekat.nl>
Uri Guttman <uri@stemsystems.com> writes:
> don't use the 'value' of an if/else statement. it does have one but it
> is very bad code to expect the last evaluated value to be useful. just
> put return statements in there will make it much better.
I think lisp has ruined me; I use this kind of thing quite a bit, at
least when there's only a single statement in each clause.
Of course I could have done
defined($s1) && defined($s2) ? $s1 eq $s2 : defined($s1) == defined($s2);
But I always find that a lot harder to read.
> but you still have a bug. what if one element is '0' and the other
> undefined?
Then they aren't equal. Which I understood the OP wanted. I may ofcourse
be wrong.
--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
------------------------------
Date: Sun, 10 Feb 2008 19:33:02 +0100
From: "Dr.Ruud" <rvtol+news@isolution.nl>
Subject: Re: "Use of uninitialized value" warning
Message-Id: <fonjhi.qs.1@news.isolution.nl>
Joost Diepenmaat schreef:
> defined($s1) && defined($s2) ? $s1 eq $s2 : defined($s1)
> == defined($s2);
>
> But I always find that a lot harder to read.
Then write it in a way that reads easier. Examples:
defined($s1) && defined($s2)
?
$s1 eq $s2
:
defined($s1) == defined($s2)
;
defined($s1) && defined($s2)
? $s1 eq $s2
: defined($s1) == defined($s2)
;
etc.
--
Affijn, Ruud
"Gewoon is een tijger."
------------------------------
Date: Sun, 10 Feb 2008 12:12:30 -0800 (PST)
From: globwholesale <globwholesale15@126.com>
Subject: CHEAP DIOR, AF1, DSQUARED, BAPESTA, HOGAN, CHANEL, VERSACE, SHOES, SNEAKERS, TAINERS
Message-Id: <b9adfd9a-12cf-477b-884a-9907ca7512dd@v4g2000hsf.googlegroups.com>
WWW .cheapforwholesale. COM
Nike shoes | china nike shoes | air jordan sneakers | cheap gucci
shoes | cheap prada sneakers | gucci sneakers | mix jordan sneakers |
chanel sandals | gucci sandals | dior sandals | wholesale jordan
sneakers | nike running shoes | nike stock shoes | air jordan at
whlesale price | nike shoes air jordan supplier from in china |
Lacoste Trainers | puma trainers | louis vuitton purse | prada purse
|
gucci handbags | chanel purse | coach purse | nike bas kerball shoes
|
Nike Sneakers| cheap nike sneakers | nike shoes from china | nike
replica | copy nike sneakers | nike factory stores | nike stores
Nike wholesale - Nike shoes wholesale
(www.cheapforwholesale.com) china Wholesale Cheap Nike jordans
sneakers
Michael Jordan Shoes,Nike Jordan Basketball shoes...Jordan Shoes, Air
Jordan Sneakers , Air Jordan Wholesale All of the Air Jordan sneakers
have Nike Air in the shoes. Authentic quality Jordans Sneakers Custom
China Wholesale Jordan gucci sneakers prada gucci purse Handbag We
sale new Nike Sneakers,Air Jordan Sneakers,AIR FORCE 1S,Nike Dunks
SB,Bape Sta from nike outlets and factory stores,
www.cheapforwholesale.com Nike wholesale - Jordan Shoes. Nike Shoes,
sport Shoes, Reebok Shoes,Running Shoes , prada chanel dior gucci
sandals,Nike Shox,Nike Flightposite ,Nike jordan Basketball shoes K1X
Chiefglider wholesale suppliers factory.
www.cheapforwholesale.com sale new Nike Sneakers,Air Jordan
Sneakers,AIR
FORCE 1S,Nike Dunks SB, Bape Sta from nike Wholesale china nike
jordans gucci prada sneakers at cheap price
www.cheapforwholesale.com Wholesale Nike Dunk,Authentic Jordans
Wholesale,Nike Shoes Wholesale,Discount Nike Air Force 1 for
wholesale
and sale from china .china wholesale discount cheap nike jordan gucci
prada sneakers lacoste puma trainers at china factory price.
Our Products: Cheap Christian Audigier | Versace Shoes | Dirk
Bikkembergs shoes | China Jordans Sneakers | Air Force Ones | Nike
Shoes | Dunk SB Shoes | Gucci Shoes Wholesale | Puma Trainers |
Timberlands Boots | Adidas Trainers | D&G Shoes | Armant shoes |
Dsquared shoes Store | BapeSta shoes | Lacoste Trainers | Converse
Shoes | Hogan shoes | Prada Shoes | Louis Vuitton shoes | Richmond
Shoes | Diesel Shoes | Chanel shoes | Dior Shoes | Burberry Shoes
| Evisu shoes | Visvim Sneakers | Ed-Hardy Slipper | Crocs Sandals
| Dior Shoes For Womens | Cheap Ugg boots | Women AF1 | Women's
Dunk | Women's Jordans | Women's Shox/Max | Women's Ice Cream |
Kid Shoes | women's chanel | brand boots | LV sandals | Gucci
sandals | Women's Bape | Dior Sandals | Chanel Sandals | Prada
sandals | Bearpaw Shoes | Gino Green Global | NFL Jerseys | Ed
Hardy Tshirts n Jeans | Artful T-shirts | Coogi T-shirts | LRG T-
shirts | Rich Yung T-shirts n Hoodies | CA T-Shirts | Abercrombie &
Fitch | Helen Coat | Women's Burberry Coat | Armani Jacket | Prada
Jacket | Versace Jacket | Red Monkey Jeans Wholesale | Bape hoody
| BBC Wholesale Jeans | Evisu Wholesale Jean | Diesel Jeans | Rock
Republic Jeans | True Religion Jeans | Seven Jeans | Bape Jeans |
Levis Jeans | Antik Jeans | lacoste Clothes | Ralph Lauren | Juicy
| Underwear | The North Face | 10Deep Hoody | Gucci Clothes |
Designers Hoodies | Other Brand Jeans | Cavalli Jeans | D&G Clothes
| Boss Suit | Shirts | Polo Handbag | Guess Handbags | A & F
Handbag | Anya Hindmarch Bag | Louis Vuitton handbag | Gucci
handbag | Prada handbags | Chanel Handbag | Chloe handbag | Coach
handbag | Hermes handbag | Dior handbag | Fendi purse | Wallets |
Miumiu Handbag | Juicy Handbag | D&G Handbags | Bcbg Handbag |
Jimmy Choo Handbag | Clear AF1 Low | Full Clear AF1 | Clear Bape |
Clear Jordan | Women Clear AF1 | Rolex Watches | Gucci Watches |
Chanel Watches | Omega Watches | Ipod Nano | hot | Perfume
Wholesale | necklace | Bracelet | Ring & Earring | Prada Wholesale
Sunglasses | DG Wholesale Sunglasses | Fendi Wholesale Sunglasses |
Burberry Wholesale Sunglasses | Chanel Wholesale Sunglasses | Louis
Vuitton Wholesale Sunglasses | Dior Wholesale Sunglasses | Gucci
Wholesale Sunglasses | Armani Wholesale Sunglasses | Versace
Wholesale Sunglasses | Brand Cap | Lacoste Belts | Louis Vuitton
Belts | Gucci Belts | Chanel Belts | Bape Belts | Juicy Belts |
Pearl Necklace | Pearl Jewelry Set | Pearl Bracelet | Pearl
Earrings | Pearl Strands | Gemstone Jewelry | GPS | Nokia | Apple
| Reebok NFL Jersey Wholesale | perfume |
------------------------------
Date: Sun, 10 Feb 2008 12:24:37 +0100 (CET)
From: January Weiner <january.weiner@gmail.com>
Subject: Modules, global variables and such
Message-Id: <fommtl$670$1@sagnix.uni-muenster.de>
Hello,
I have the following problem. I had a script that contained only one
global variable which was called $DEBUG. I just used it to print out
various think or do some checks in debugging mode
print "number of objects $n_obj\n" if $DEBUG ;
check_sanity if $DEBUG ;
The program grew and now I splitted it up into several modules.
Question: what to do with the debug variable?
* I could make it local to all of the functions, but I would really hate
passing it through to each of the functions separately. Firstly, IMO this
is one of the few cases where global variables are justified, and second,
this would require me to make hundreds of modifications in the code.
* I could make it a global variable in each of the modules, and create a
function that switches on the debugging for one module only. This would
have the advantage that I could specify which module to debug.
Disadvantage is that I need to remember to switch it on in every module
if I want to switch it on globally.
* Finally, I could make a separate module with generic tests for sanity and
printing warning messages, and that module would hold the only instance
of the $DEBUG variable. Again, many modifications in the code required.
Of course, I can imagine that there are gazillions of other ways of doing
that, and that there are specific modules that do precisely what I want.
What route would you recommend?
Regards,
January
------------------------------
Date: Sun, 10 Feb 2008 12:40:14 +0100
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: Modules, global variables and such
Message-Id: <618653F1s13lfU1@mid.individual.net>
January Weiner wrote:
> I have the following problem. I had a script that contained only one
> global variable which was called $DEBUG. I just used it to print out
> various think or do some checks in debugging mode
>
> print "number of objects $n_obj\n" if $DEBUG ;
> check_sanity if $DEBUG ;
>
> The program grew and now I splitted it up into several modules.
>
> Question: what to do with the debug variable?
>
> * I could make it local to all of the functions, but I would really hate
> passing it through to each of the functions separately. Firstly, IMO this
> is one of the few cases where global variables are justified, and second,
> this would require me to make hundreds of modifications in the code.
>
> * I could make it a global variable in each of the modules, and create a
> function that switches on the debugging for one module only. This would
> have the advantage that I could specify which module to debug.
> Disadvantage is that I need to remember to switch it on in every module
> if I want to switch it on globally.
>
> * Finally, I could make a separate module with generic tests for sanity and
> printing warning messages, and that module would hold the only instance
> of the $DEBUG variable. Again, many modifications in the code required.
You didn't mention the simplest way:
Keep it a global variable in one of the modules and use its fully
qualified name when calling it from other modules, e.g. $MyModule::DEBUG
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: Sun, 10 Feb 2008 12:46:50 +0100 (CET)
From: January Weiner <january.weiner@gmail.com>
Subject: Re: Modules, global variables and such
Message-Id: <fomo7a$670$2@sagnix.uni-muenster.de>
Gunnar Hjalmarsson <noreply@gunnar.cc> wrote:
> > * Finally, I could make a separate module with generic tests for sanity and
> > printing warning messages, and that module would hold the only instance
> > of the $DEBUG variable. Again, many modifications in the code required.
> You didn't mention the simplest way:
> Keep it a global variable in one of the modules and use its fully
> qualified name when calling it from other modules, e.g. $MyModule::DEBUG
This is more or less my third way. It requires modifying each of the
statements containing $DEBUG and including the module in all the other
modules and the main code. But yes, I am considering this, thanks!
j.
------------------------------
Date: 10 Feb 2008 11:54:45 GMT
From: Abigail <abigail@abigail.be>
Subject: Re: Modules, global variables and such
Message-Id: <slrnfqtpg5.ifi.abigail@alexandra.abigail.be>
_
Gunnar Hjalmarsson (noreply@gunnar.cc) wrote on VCCLXXVI September
MCMXCIII in <URL:news:618653F1s13lfU1@mid.individual.net>:
-: January Weiner wrote:
-: > I have the following problem. I had a script that contained only one
-: > global variable which was called $DEBUG. I just used it to print out
-: > various think or do some checks in debugging mode
-: >
-: > print "number of objects $n_obj\n" if $DEBUG ;
-: > check_sanity if $DEBUG ;
-: >
-: > The program grew and now I splitted it up into several modules.
-: >
-: > Question: what to do with the debug variable?
-: >
-: > * I could make it local to all of the functions, but I would really hate
-: > passing it through to each of the functions separately. Firstly, IMO this
-: > is one of the few cases where global variables are justified, and second,
-: > this would require me to make hundreds of modifications in the code.
-: >
-: > * I could make it a global variable in each of the modules, and create a
-: > function that switches on the debugging for one module only. This would
-: > have the advantage that I could specify which module to debug.
-: > Disadvantage is that I need to remember to switch it on in every module
-: > if I want to switch it on globally.
-: >
-: > * Finally, I could make a separate module with generic tests for sanity and
-: > printing warning messages, and that module would hold the only instance
-: > of the $DEBUG variable. Again, many modifications in the code required.
-:
-: You didn't mention the simplest way:
-:
-: Keep it a global variable in one of the modules and use its fully
-: qualified name when calling it from other modules, e.g. $MyModule::DEBUG
That's what I usually do, except that put the variable in main, so I
can just use $::DEBUG.
Or sometimes, I use $ENV {DEBUG}.
Abigail
--
srand 123456;$-=rand$_--=>@[[$-,$_]=@[[$_,$-]for(reverse+1..(@[=split
//=>"IGrACVGQ\x02GJCWVhP\x02PL\x02jNMP"));print+(map{$_^q^"^}@[),"\n"
------------------------------
Date: 10 Feb 2008 11:57:30 GMT
From: Abigail <abigail@abigail.be>
Subject: Re: Modules, global variables and such
Message-Id: <slrnfqtpla.ifi.abigail@alexandra.abigail.be>
_
January Weiner (january.weiner@gmail.com) wrote on VCCLXXVI September
MCMXCIII in <URL:news:fomo7a$670$2@sagnix.uni-muenster.de>:
@@ Gunnar Hjalmarsson <noreply@gunnar.cc> wrote:
@@ > > * Finally, I could make a separate module with generic tests for sanity and
@@ > > printing warning messages, and that module would hold the only instance
@@ > > of the $DEBUG variable. Again, many modifications in the code required.
@@
@@ > You didn't mention the simplest way:
@@
@@ > Keep it a global variable in one of the modules and use its fully
@@ > qualified name when calling it from other modules, e.g. $MyModule::DEBUG
@@
@@ This is more or less my third way. It requires modifying each of the
@@ statements containing $DEBUG and including the module in all the other
@@ modules and the main code. But yes, I am considering this, thanks!
You seem to have the impression that if you're using a variable
$MyModule::DEBUG, you have to have a MyModule.pm, and you have
to 'use' that file.
That's not true.
package Fnurd;
use strict;
use warnings;
say "Hi, I'm a debugging message." if $MyModule::DEBUG;
works well.
Abigail
--
srand 123456;$-=rand$_--=>@[[$-,$_]=@[[$_,$-]for(reverse+1..(@[=split
//=>"IGrACVGQ\x02GJCWVhP\x02PL\x02jNMP"));print+(map{$_^q^"^}@[),"\n"
------------------------------
Date: Sun, 10 Feb 2008 13:23:12 +0100 (CET)
From: January Weiner <january.weiner@gmail.com>
Subject: Re: Modules, global variables and such
Message-Id: <fomqbg$670$3@sagnix.uni-muenster.de>
Abigail <abigail@abigail.be> wrote:
> You seem to have the impression that if you're using a variable
> $MyModule::DEBUG, you have to have a MyModule.pm, and you have
> to 'use' that file.
> That's not true.
> package Fnurd;
> use strict;
> use warnings;
> say "Hi, I'm a debugging message." if $MyModule::DEBUG;
Ah, OK. I always used only functions exported from modules or OO modules.
These must be exported and the modules must be imported. I assumed that the
same holds for the variables.
j.
------------------------------
Date: Sun, 10 Feb 2008 13:45:50 +0100 (CET)
From: January Weiner <january.weiner@gmail.com>
Subject: Re: Modules, global variables and such
Message-Id: <fomrlu$670$4@sagnix.uni-muenster.de>
Abigail <abigail@abigail.be> wrote:
> That's what I usually do, except that put the variable in main, so I
> can just use $::DEBUG.
This is it! Thank you (both) very much.
> srand 123456;$-=rand$_--=>@[[$-,$_]=@[[$_,$-]for(reverse+1..(@[=split
> //=>"IGrACVGQ\x02GJCWVhP\x02PL\x02jNMP"));print+(map{$_^q^"^}@[),"\n"
'eresal nPhkuHrJ cteatro'? There is something disconcerting in this
message...
j.
------------------------------
Date: Sun, 10 Feb 2008 14:16:18 +0100
From: =?ISO-8859-1?Q?Andreas_P=FCrzer?= <pue@gmx.net>
Subject: Re: Modules, global variables and such
Message-Id: <618bklF1t8q24U1@mid.individual.net>
Abigail schrieb:
>
> You seem to have the impression that if you're using a variable
> $MyModule::DEBUG, you have to have a MyModule.pm, and you have
> to 'use' that file.
>
> That's not true.
>
>
> package Fnurd;
>
> use strict;
> use warnings;
>
> say "Hi, I'm a debugging message." if $MyModule::DEBUG;
>
>
> works well.
>
>
> Abigail
For curious lurkers like me, soaking up wisdom from c.l.p.m, I think it
should be mentioned that $MyModule::DEBUG needs to be declared via 'our'
for this to work, because:
$ perl -Mstrict -Mwarnings -le'
package MyModule;
my $DEBUG = 1;
package Fnurd;
print "Debug on" if $MyModule::DEBUG;
'
Name "MyModule::DEBUG" used only once: possible typo at -e line 5.
whereas with 'our':
$ perl -Mstrict -Mwarnings -le'
package MyModule;
our $DEBUG = 1;
package Fnurd;
print "Debug on" if $MyModule::DEBUG;
'
Debug on
But then I don't even have to use the fully qualified name:
$ perl -Mstrict -Mwarnings -le'
package MyModule;
our $DEBUG = 1;
package Fnurd;
print "Debug on" if $DEBUG;
'
Debug on
Toying a little more, I find that
$ perl -Mstrict -Mwarnings -le'
package MyModule;
my $DEBUG = 1;
package Fnurd;
print "Debug on" if $DEBUG;
'
Debug on
works equally well.
What am I not understanding?
Thank you,
Andreas Pürzer
--
Have Fun,
and if you can't have fun,
have someone else's fun.
The Beautiful South
------------------------------
Date: Sun, 10 Feb 2008 15:04:12 +0100
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: Modules, global variables and such
Message-Id: <618ej1F1q8tjiU1@mid.individual.net>
Andreas Pürzer wrote:
> Abigail schrieb:
>> January Weiner wrote:
>>> Gunnar Hjalmarsson <noreply@gunnar.cc> wrote:
>>>> Keep it a global variable in one of the modules and use its fully
>>>> qualified name when calling it from other modules, e.g. $MyModule::DEBUG
>>>
>>> This is more or less my third way. It requires modifying each of the
>>> statements containing $DEBUG and including the module in all the other
>>> modules and the main code. But yes, I am considering this, thanks!
>>
>> You seem to have the impression that if you're using a variable
>> $MyModule::DEBUG, you have to have a MyModule.pm, and you have
>> to 'use' that file.
>>
>> That's not true.
>>
>> package Fnurd;
>>
>> use strict;
>> use warnings;
>>
>> say "Hi, I'm a debugging message." if $MyModule::DEBUG;
>>
>> works well.
>
> For curious lurkers like me, soaking up wisdom from c.l.p.m, I think it
> should be mentioned that $MyModule::DEBUG needs to be declared via 'our'
> for this to work, because:
>
> $ perl -Mstrict -Mwarnings -le'
> package MyModule;
> my $DEBUG = 1;
> package Fnurd;
> print "Debug on" if $MyModule::DEBUG;
> '
> Name "MyModule::DEBUG" used only once: possible typo at -e line 5.
That's because the my() declared $DEBUG and $MyModule::DEBUG are two
different variables...
> whereas with 'our':
>
> $ perl -Mstrict -Mwarnings -le'
> package MyModule;
> our $DEBUG = 1;
> package Fnurd;
> print "Debug on" if $MyModule::DEBUG;
> '
> Debug on
>
> But then I don't even have to use the fully qualified name:
>
> $ perl -Mstrict -Mwarnings -le'
> package MyModule;
> our $DEBUG = 1;
> package Fnurd;
> print "Debug on" if $DEBUG;
> '
> Debug on
You do have to use the fully qualified name if you call the variable
from somewhere outside the MyModule package.
> Toying a little more, I find that
>
> $ perl -Mstrict -Mwarnings -le'
> package MyModule;
> my $DEBUG = 1;
> package Fnurd;
> print "Debug on" if $DEBUG;
> '
> Debug on
>
> works equally well.
Not if you call it from some other module or from the main script.
> What am I not understanding?
Maybe you didn't read the whole thread carefully enough? ;-)
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: Sun, 10 Feb 2008 19:17:53 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Modules, global variables and such
Message-Id: <18v385-aj11.ln1@osiris.mauzo.dyndns.org>
Quoth Gunnar Hjalmarsson <noreply@gunnar.cc>:
> Andreas Pürzer wrote:
>
> > whereas with 'our':
> >
> > $ perl -Mstrict -Mwarnings -le'
> > package MyModule;
> > our $DEBUG = 1;
> > package Fnurd;
> > print "Debug on" if $MyModule::DEBUG;
> > '
> > Debug on
> >
> > But then I don't even have to use the fully qualified name:
> >
> > $ perl -Mstrict -Mwarnings -le'
> > package MyModule;
> > our $DEBUG = 1;
> > package Fnurd;
> > print "Debug on" if $DEBUG;
> > '
> > Debug on
>
> You do have to use the fully qualified name if you call the variable
> from somewhere outside the MyModule package.
No, not if you use 'our'. An often-overlooked property of 'our' is that
it creates a lexical alias to the package variable: in simple terms, you
can use that variable unqualified for the rest of the lexical scope,
even if you change package. This is why the second example above works
as it does.
> > Toying a little more, I find that
> >
> > $ perl -Mstrict -Mwarnings -le'
> > package MyModule;
> > my $DEBUG = 1;
> > package Fnurd;
> > print "Debug on" if $DEBUG;
> > '
> > Debug on
> >
> > works equally well.
>
> Not if you call it from some other module or from the main script.
More precisely: if you attempt to use it in some other lexical scope.
Package statements are irrelevant for lexicals, so if you have some code
in another file that is in package MyModule it still can't see the
lexical.
Ben
------------------------------
Date: Sun, 10 Feb 2008 19:27:08 +0000
From: Mark Clements <mark.clementsREMOVETHIS@wanadoo.fr>
Subject: Re: Modules, global variables and such
Message-Id: <47af500c$0$882$ba4acef3@news.orange.fr>
January Weiner wrote:
> Hello,
>
> I have the following problem. I had a script that contained only one
> global variable which was called $DEBUG. I just used it to print out
> various think or do some checks in debugging mode
>
> print "number of objects $n_obj\n" if $DEBUG ;
> check_sanity if $DEBUG ;
>
This post is orthogonal to the other messages in this thread, but you
may want to check out
Carp::Assert
Log::Log4perl
Mark
------------------------------
Date: Sun, 10 Feb 2008 19:21:22 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Modules, global variables and such
Message-Id: <iev385-aj11.ln1@osiris.mauzo.dyndns.org>
Quoth abigail@abigail.be:
> _
> Gunnar Hjalmarsson (noreply@gunnar.cc) wrote on VCCLXXVI September
> MCMXCIII in <URL:news:618653F1s13lfU1@mid.individual.net>:
> -: January Weiner wrote:
> -: > I have the following problem. I had a script that contained only one
> -: > global variable which was called $DEBUG. I just used it to print out
> -: > various think or do some checks in debugging mode
<snip>
> -:
> -: You didn't mention the simplest way:
> -:
> -: Keep it a global variable in one of the modules and use its fully
> -: qualified name when calling it from other modules, e.g. $MyModule::DEBUG
>
> That's what I usually do, except that put the variable in main, so I
> can just use $::DEBUG.
If this code might be used in some other, unrelated program (that is,
the debugging state belongs with the module, not the program as a whole)
you can create a package global and then import it into your other
packages:
package MyModule;
require 'Exporter';
our @ISA = 'Exporter';
our @EXPORT_OK = qw/$DEBUG/;
our $DEBUG;
__DATA__
package MyModule::Foo;
use MyModule qw/$DEBUG/;
# now just use $DEBUG, as before
__DATA__
Ben
------------------------------
Date: 10 Feb 2008 19:44:57 GMT
From: Abigail <abigail@abigail.be>
Subject: Re: Modules, global variables and such
Message-Id: <slrnfqul1p.ifi.abigail@alexandra.abigail.be>
_
January Weiner (january.weiner@gmail.com) wrote on VCCLXXVI September
MCMXCIII in <URL:news:fomqbg$670$3@sagnix.uni-muenster.de>:
:: Abigail <abigail@abigail.be> wrote:
:: > You seem to have the impression that if you're using a variable
:: > $MyModule::DEBUG, you have to have a MyModule.pm, and you have
:: > to 'use' that file.
::
:: > That's not true.
::
::
:: > package Fnurd;
::
:: > use strict;
:: > use warnings;
::
:: > say "Hi, I'm a debugging message." if $MyModule::DEBUG;
::
:: Ah, OK. I always used only functions exported from modules or OO modules.
:: These must be exported and the modules must be imported. I assumed that the
:: same holds for the variables.
Oh, it's certainly true that there's no difference between variables and
subroutines in that aspect.
Except that if you *do not* have to export subroutines from modules to
be able to use them. If you use fully qualified names, no exporting
is needed. In fact, you don't even need a module to create a subroutine
in a certain namespace.
package main;
sub MyModule::hello {
say "Hello, world";
}
...
package Fnurd;
MyModule::hello; # Prints 'Hello, world'
Abigail
--
# Perl 5.6.0 broke this.
%0=map{reverse+chop,$_}ABC,ACB,BAC,BCA,CAB,CBA;$_=shift().AC;1while+s/(\d+)((.)
(.))/($0=$1-1)?"$0$3$0{$2}1$2$0$0{$2}$4":"$3 => $4\n"/xeg;print#Towers of Hanoi
------------------------------
Date: 10 Feb 2008 19:51:53 GMT
From: Abigail <abigail@abigail.be>
Subject: Re: Modules, global variables and such
Message-Id: <slrnfqulep.ifi.abigail@alexandra.abigail.be>
_
Andreas Pürzer (pue@gmx.net) wrote on VCCLXXVI September MCMXCIII in
<URL:news:618bklF1t8q24U1@mid.individual.net>:
## Abigail schrieb:
## >
## > You seem to have the impression that if you're using a variable
## > $MyModule::DEBUG, you have to have a MyModule.pm, and you have
## > to 'use' that file.
## >
## > That's not true.
## >
## >
## > package Fnurd;
## >
## > use strict;
## > use warnings;
## >
## > say "Hi, I'm a debugging message." if $MyModule::DEBUG;
## >
## >
## > works well.
## >
## >
## > Abigail
##
## For curious lurkers like me, soaking up wisdom from c.l.p.m, I think it
## should be mentioned that $MyModule::DEBUG needs to be declared via 'our'
## for this to work,
No.
package main;
use 5.10.0;
use strict;
use warnings;
$MyModule::DEBUG = 1;
say "Hi, I'm a debugging message." if $MyModule::DEBUG;
__END__
Hi, I'm a debugging message.
## because:
##
## $ perl -Mstrict -Mwarnings -le'
## package MyModule;
## my $DEBUG = 1;
## package Fnurd;
## print "Debug on" if $MyModule::DEBUG;
## '
## Name "MyModule::DEBUG" used only once: possible typo at -e line 5.
[ Snip ]
## What am I not understanding?
You are not understanding that when I say:
You seem to have the impression that if you're using a variable
$MyModule::DEBUG, you have to have a MyModule.pm, and you have
to 'use' that file.
That's not true.
You really do not have to have a MyModule.pm.
Of course, if you want to have a module called MyModule, want to have
a variable $MyModule::DEBUG, *and* want to refer to that variable as
$DEBUG when in the module MyModule, *then* you need to use our instead
of my.
But there's no need for a module MyModule just to have a single variable
in that namespace.
Abigail
--
A perl rose: perl -e '@}>-`-,-`-%-'
------------------------------
Date: Sun, 10 Feb 2008 19:07:38 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: PerlCtrl's IDL and enums
Message-Id: <qku385-aj11.ln1@osiris.mauzo.dyndns.org>
Quoth axtens <Bruce.Axtens@gmail.com>:
>
> Is there a way to specify enums in the IDL for a PerlCtrl?
You seem to be asking a lot of questions about ActiveState's PDK. While
this is a reasonable place to ask, I don't get the impression there are
a lot of people here who can help you. You may have more luck looking
for some ActiveState-specific list, or (if you are entitled) asking
ActiveState support directly.
Ben
------------------------------
Date: Sun, 10 Feb 2008 14:59:27 +0100
From: Joost Diepenmaat <joost@zeekat.nl>
Subject: Re: Question about PDL
Message-Id: <87hcggdi9s.fsf@zeekat.nl>
January Weiner <january.weiner@gmail.com> writes:
> PDL is supposed to be much faster and to have a smaller memory footprint.
>
> While I can see the latter (the footprint is now negligible compared to the
> whole program), it is roughly three to four times slower than the regular
> perlish way. I am creating the matrix as follows [please bear with me -- I
> am not posting actual code, because it is rather complex, and you will see
> that answering my question doesn't require finding out whether my code is
> correct]:
>
> $matrix = short(zeroes($l1, $l2)) ;
>
> (where $l1 and $l2 are dimensions of the matrix), and accessing / setting
> the elements using at() and set():
>
> set( $matrix, $i, $j, $value ) ;
> $value = at( $matrix, $i, $j ) ;
>
> There is another way of doing it using PDL::NiceSlice, which uses
> constructs like $matrix->($i, $j), but I found it to be even slower.
If I'm reading you correctly, all your calculations involve getting a
value from the matrix, processing it in pure perl and then setting it
back. That is not how you get good speed from PDL. You want to move as
many calculations as you can to the PDL operators, especially those
operators that can act on groups of values.
I only have very limited knowledge of PDL, but it seems to me that you
could probably do your averaging by using the PDL projection
operators. See
<http://www.johnlapeyre.com/pdl/pdldoc/newbook/node4.html#SECTION00440000000000000000>
and the section immediately after that.
--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
------------------------------
Date: Sun, 10 Feb 2008 15:17:33 +0100 (CET)
From: January Weiner <january.weiner@gmail.com>
Subject: Re: Question about PDL
Message-Id: <fon11t$670$5@sagnix.uni-muenster.de>
Joost Diepenmaat <joost@zeekat.nl> wrote:
> If I'm reading you correctly, all your calculations involve getting a
> value from the matrix, processing it in pure perl and then setting it
> back. That is not how you get good speed from PDL. You want to move as
> many calculations as you can to the PDL operators, especially those
> operators that can act on groups of values.
Yes, I do it now. The operation that I needed was conv2d from PDL::Image2D,
with a convolution matrix of the form zeroes($window,$window)->diagonal++.
However, the other big advantage from PDL is for me the reduction of the
memory footprint, which is substantial.
I'm now stuck with the old conundrum: low memory footprint OR speed.
j.
> I only have very limited knowledge of PDL, but it seems to me that you
> could probably do your averaging by using the PDL projection
> operators. See
> <http://www.johnlapeyre.com/pdl/pdldoc/newbook/node4.html#SECTION00440000000000000000>
> and the section immediately after that.
> --
> Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
------------------------------
Date: Sun, 10 Feb 2008 07:42:13 -0800 (PST)
From: pgodfrin <pgodfrin@gmail.com>
Subject: Re: Using END and the die function
Message-Id: <d2da5943-2258-442b-85bc-b1f47a28ec84@e4g2000hsg.googlegroups.com>
On Feb 8, 5:56 pm, Tad J McClellan <ta...@seesig.invalid> wrote:
> pgodfrin <pgodf...@gmail.com> wrote:
> > On Feb 8, 1:28 pm, nolo contendere <simon.c...@fmr.com> wrote:
> >> On Feb 8, 2:07 pm, pgodfrin <pgodf...@gmail.com> wrote:
>
> >> > I'd like to die() with a return code (no pun intended) - I'm not sure
> >> > how to do it without wrapping some extra code around die. Any
> >> > thoughts?
>
> >> > Here's a snippet:
>
> [ snip snippet ]
>
> >> > This works fine if I explicitly code both steps - first setting the
> >> > $return_code and then executing die. But, this kind of statement won't
> >> > permit that 'cause of the nature of the or operator:
>
> >> > mkdir($tgt_dir) or die "Mkdir ($tgt_dir) command failed.\n";
> >> Would 'exit' suit your needs? Just 'warn' whatever message you want,
> >> then call 'exit' with the return code you want.
>
> > That would work, but it's still a two step operation, so I couldn't
> > use the or operator.
>
> Sure you could:
>
> mkdir($tgt_dir) or warn "Mkdir ($tgt_dir) command failed.\n" and exit 42;
>
> Reads like English:
>
> make the directory or warn and exit
>
> --
> Tad McClellan
> email: perl -le "print scalar reverse qq/moc.noitatibaher\100cmdat/"
Yeah - I like that - thanks!
regards,
pg
------------------------------
Date: Sun, 10 Feb 2008 18:51:48 GMT
From: Graham Drabble <usenet05@drabble.me.uk>
Subject: Re: Using END and the die function
Message-Id: <Xns9A40BFE381AB8grahamdrabblelineone@ID-77355.user.dfncis.de>
On 08 Feb 2008 Tad J McClellan <tadmc@seesig.invalid> wrote in
news:slrnfqpr0o.96t.tadmc@tadmc30.sbcglobal.net:
> Sure you could:
>
> mkdir($tgt_dir) or warn "Mkdir ($tgt_dir) command failed.\n"
> and exit 42;
>
> Reads like English:
>
> make the directory or warn and exit
Can warn() ever return false? If it did then your code above wouldn't
exit. mkdir() or die() will always cause it to exit AFAICT.
--
Graham Drabble
http://www.drabble.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 1268
***************************************
