[29057] in Perl-Users-Digest

home help back first fref pref prev next nref lref last post

Perl-Users Digest, Issue: 301 Volume: 11

daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Apr 4 11:10:36 2007

Date: Wed, 4 Apr 2007 08:09: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           Wed, 4 Apr 2007     Volume: 11 Number: 301

Today's topics:
    Re: Can't change filenames..why? <tadmc@augustmail.com>
    Re: Can't change filenames..why? <spamtrap@dot-app.org>
    Re: Can't change filenames..why? <jurgenex@hotmail.com>
    Re: Can't change filenames..why? <uri@stemsystems.com>
    Re: comp.lang.perl.cgi? <bik.mido@tiscalinet.it>
    Re: extending a module? <bugbear@trim_papermule.co.uk_trim>
    Re: extending a module? anno4000@radom.zrz.tu-berlin.de
    Re: extending a module? <nobull67@gmail.com>
    Re: extending a module? <bugbear@trim_papermule.co.uk_trim>
    Re: How to resolve funky sync issues with fork here. <lpitcher@sympatico.ca>
    Re: How to resolve funky sync issues with fork here. <cdalten@gmail.com>
    Re: How to run Perl script as GUI Windows program? Like <sisyphus1@nomail.afraid.org>
    Re: How to turn off "Caps Lock" from Perl script. <sisyphus1@nomail.afraid.org>
    Re: HowTo parse huge Files <bik.mido@tiscalinet.it>
        More controlled Module loading - Faking output from cal <stumo@stumo.org.uk>
    Re: More controlled Module loading - Faking output from <spamtrap@dot-app.org>
    Re: More controlled Module loading - Faking output from <rs@474.at>
    Re: More controlled Module loading - Faking output from anno4000@radom.zrz.tu-berlin.de
    Re: perl OOP <spamtrap@dot-app.org>
    Re: perl OOP <bik.mido@tiscalinet.it>
    Re: perl OOP <bik.mido@tiscalinet.it>
    Re: Problem in the Perl script <bik.mido@tiscalinet.it>
        Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)

----------------------------------------------------------------------

Date: Wed, 4 Apr 2007 07:03:57 -0500
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: Can't change filenames..why?
Message-Id: <slrnf1751d.c7u.tadmc@tadmc30.august.net>

Ed Jay <edMbj@aes-intl.com> wrote:
> Tad McClellan scribed:
>>Ed Jay <edMbj@aes-intl.com> wrote:
>>
>>> $filepath = 'http://yadayada.com/uploads;
>>
>>
>>You need quotes on *both* ends of strings.

>>> rename($filename,$imgCode$i.jpg) or die "Could not rename file: $!";	
>>                   ^^^^^^^^^^
>>
>>Syntax error.
>>
>>
>>> The original files upload fine. Everything seems to work.
>>
>>
>>We cannot help you if you lie to us.
>
> You need to learn some table manners.


You said the program could run.

Programs cannot run when they contain (multiple) syntax errors.

So long!


-- 
    Tad McClellan                          SGML consulting
    tadmc@augustmail.com                   Perl programming
    Fort Worth, Texas


------------------------------

Date: Wed, 04 Apr 2007 07:28:32 -0400
From: Sherm Pendley <spamtrap@dot-app.org>
Subject: Re: Can't change filenames..why?
Message-Id: <m2648cnztr.fsf@local.wv-www.com>

Ed Jay <edMbj@aes-intl.com> writes:

> You need to learn some table manners.

Manners are when you say "thank you" when you receive good advice from
smart people like Tad.

*plonk*

sherm--

-- 
Web Hosting by West Virginians, for West Virginians: http://wv-www.net
Cocoa programming in Perl: http://camelbones.sourceforge.net


------------------------------

Date: Wed, 04 Apr 2007 14:28:32 GMT
From: "Jürgen Exner" <jurgenex@hotmail.com>
Subject: Re: Can't change filenames..why?
Message-Id: <kCOQh.6740$%G4.2506@trndny05>

Ed Jay wrote:
> You did, however, provide a useful hint. I had chdir $filepath when
> $filePath was defined.

And had you used 'use strict;' then perl itself would have told you right 
away that that was your problem.

jue




------------------------------

Date: Wed, 04 Apr 2007 10:42:27 -0400
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: Can't change filenames..why?
Message-Id: <x71wj0kxpo.fsf@mail.sysarch.com>

>>>>> "EJ" == Ed Jay <edMbj@aes-intl.com> writes:

  EJ> Uri Guttman scribed:
  >>>>>>> "EJ" == Ed Jay <edMbj@aes-intl.com> writes:
  >> 
  EJ> Tad McClellan scribed:
  >> >> 
  >> >>> The original files upload fine. Everything seems to work.
  >> >> 
  >> >> We cannot help you if you lie to us.
  >> 
  EJ> You need to learn some table manners.
  >> 
  >> ever watch house on tv. as he says everyone lies. simple fact of life.
  >> 
  >> and if you think getting a tough but correct answer from tad is worse
  >> than a polite but stupid answer from moronzilla (also know as
  >> gurlknowsnoperl) then you have a lot to learn.

  EJ> A tough answer that includes name calling isn't a tough answer. It's an
  EJ> inappropriate and offensive response. 

he didn't call you a name. he stated something you did. big
difference. he said you lied in your post (which you did as your code
did NOT compile as posted) but he didn't call you a liar. now i could
call you a whiner but i will just say you are whining too much.

  >> and get perl on your own box and test it there. relying on uploading to
  >> test perl is like using stilts to ice skate.
  >> 
  EJ> I have Perl installed. As I mentioned to another, my warnings did not hint
  EJ> at the real problem, as did hers.

hers?? ignore moronzilla. if you listen to its advice you do so at your
own peril. your perl will be much worse for your efforts. if you want,
google for its posting history

and you kept saying tested when uploaded. you never said (lying by
omission) tested locally. and warnings weren't the original complaint
about your post - it was not even compiling. so get your story straight
and tell it completely as the guidelines (mostly written and maintained
by the aformentioned tad!) so helpfully tell you to.

uri

-- 
Uri Guttman  ------  uri@stemsystems.com  -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs  ----------------------------  http://jobs.perl.org


------------------------------

Date: Wed, 04 Apr 2007 16:54:10 +0200
From: Michele Dondi <bik.mido@tiscalinet.it>
Subject: Re: comp.lang.perl.cgi?
Message-Id: <7ue713tej0bdv23tiled987mhm62gak8g2@4ax.com>

On Tue, 3 Apr 2007 20:11:43 -0500, Tad McClellan
<tadmc@augustmail.com> wrote:

>>> Simple, isn't it?
>>
>> To an experienced developer it is.
>>
>> On the other hand, the volume of off-topic posts here suggests that parti-
>> tioning the problem space is a difficult concept for novices to master. I
>> can't imagine how creating a new group would change that.

Me neither: in fact I feel like specifying this, because that was my
position too. I realise that maybe this was not entirely clear.

>This post, along with Sherm's other one, pretty much mirrors my
>position on this subject.

FWIW count me too.


Michele
-- 
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
 .'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,


------------------------------

Date: Wed, 04 Apr 2007 11:39:47 +0100
From: bugbear <bugbear@trim_papermule.co.uk_trim>
Subject: Re: extending a module?
Message-Id: <46138073$0$8759$ed2619ec@ptn-nntp-reader02.plus.net>

Brian McCauley wrote:
> On Apr 3, 4:18 pm, bugbear <bugbear@trim_papermule.co.uk_trim> wrote:
>> For local convenience I would like to "wrap"
>> an existing module, making a new and slightly
>> larger/customised module.
>>
>> Is there a convention on doing this?
>> Export and @ISA would seem quite key :-)
>>
>> Specifically, can I (somehow)
>> manufacture the new Modules @EXPORT and
>> @EXPORT_OK from the underlying module?
> 
> @EXPORT and @EXPORT_OK are ordinary package variables you can
> manipulate them just like any other.
> 
> eg.
> 
> use Some::Module;
> our @EXPORT = (@Some::Module::EXPORT, 'plus', 'some', 'more');
> 

Great - that works nicely in separate files, but when I tried
to do it with an "infile" package it failed.

Here's my "base" package (file)

package A;
use strict;
use base qw(Exporter);
use vars qw(@EXPORT);
@EXPORT = qw($v);

our $v = 42;

1;

Here's my child package (there's a standard package called 'B' !!)

package BB;
use strict;
use Data::Dumper;

use A;
use vars qw(@EXPORT @ISA);
@ISA = qw(A);
@EXPORT = (@A::EXPORT);

1;

Here's my main script.

#!/usr/bin/perl

use BB;

use Data::Dumper;

print Dumper("main::v", $main::v);
print Dumper("A", $A::v);
print Dumper("BB", $B::v);
print Dumper("v", $v);

This works a treat, but if I code this:

(main script)
package BB;
use strict;
use Data::Dumper;

use A;
use vars qw(@EXPORT @ISA);
@ISA = qw(A);
@EXPORT = (@A::EXPORT);

package main;
use Data::Dumper;

print Dumper("main::v", $main::v);
print Dumper("A", $A::v);
print Dumper("BB", $B::v);
print Dumper("v", $v);

which is the same but with the "BB" package inline,
the compiler barfs at the last line:

Variable "$v" is not imported at ./leak2.pl line 18.
Global symbol "$v" requires explicit package name at ./leak2.pl line 18.
Execution of ./leak2.pl aborted due to compilation errors.

I tried adding a "import BB;" after the "package main;"
but it made no difference.

Explanations and/or work rounds welcomed.

    BugBear


------------------------------

Date: 4 Apr 2007 12:21:56 GMT
From: anno4000@radom.zrz.tu-berlin.de
Subject: Re: extending a module?
Message-Id: <57hjj4F2d9k6iU1@mid.dfncis.de>

bugbear  <bugbear@trim_papermule.co.uk_trim> wrote in comp.lang.perl.misc:
> Brian McCauley wrote:
> > On Apr 3, 4:18 pm, bugbear <bugbear@trim_papermule.co.uk_trim> wrote:
> >> For local convenience I would like to "wrap"
> >> an existing module, making a new and slightly
> >> larger/customised module.
> >>
> >> Is there a convention on doing this?
> >> Export and @ISA would seem quite key :-)
> >>
> >> Specifically, can I (somehow)
> >> manufacture the new Modules @EXPORT and
> >> @EXPORT_OK from the underlying module?
> > 
> > @EXPORT and @EXPORT_OK are ordinary package variables you can
> > manipulate them just like any other.
> > 
> > eg.
> > 
> > use Some::Module;
> > our @EXPORT = (@Some::Module::EXPORT, 'plus', 'some', 'more');
> > 
> 
> Great - that works nicely in separate files, but when I tried
> to do it with an "infile" package it failed.

[snippage]

> I tried adding a "import BB;" after the "package main;"
> but it made no difference.

You're on the right track.  Make that a method call, and make sure it
happens at compile time (untested).

    BEGIN { BB->import }

Anno


------------------------------

Date: 4 Apr 2007 05:41:56 -0700
From: "Brian McCauley" <nobull67@gmail.com>
Subject: Re: extending a module?
Message-Id: <1175690516.400240.307740@n76g2000hsh.googlegroups.com>

On Apr 4, 11:39 am, bugbear <bugbear@trim_papermule.co.uk_trim> wrote:

> package A;
> use strict;
> use base qw(Exporter);
> use vars qw(@EXPORT);
> @EXPORT = qw($v);
>
> our $v = 42;
>
> 1;

> (main script)
> package BB;
> use strict;
> use Data::Dumper;
>
> use A;
> use vars qw(@EXPORT @ISA);
> @ISA = qw(A);
> @EXPORT = (@A::EXPORT);
>
> package main;
> use Data::Dumper;
>
> print Dumper("main::v", $main::v);
> print Dumper("A", $A::v);
> print Dumper("BB", $B::v);
> print Dumper("v", $v);
>
> which is the same but with the "BB" package inline,
> the compiler barfs at the last line:

Not exactly - use() is a compile time operation. What you've done here
is the inline analogue of "require BB" not "use BB".

> Variable "$v" is not imported at ./leak2.pl line 18.
> Global symbol "$v" requires explicit package name at ./leak2.pl line 18.
> Execution of ./leak2.pl aborted due to compilation errors.
 
^^^^^^^^^^^^^^^^^^^^^^^^
The clue is in the message, note the word "compilation".

> I tried adding a "import BB;" after the "package main;"
> but it made no difference.

Yes, that is necessary but not sufficient. There are two differences
between use() and require(). That's only one of them.

To make $main::v exist at compile time you need the assignment of
@BB::EXPORT and the call to import BB to happen prior to the
compilation of Dumper("v", $v) as they would if you'd use()d BB as a
separate module file.

Note as an additional benefit of wrapping the inline BB in a block you
don't need the explicit "package main" and it's save to use our for
@EXPORT and @ISA.

use strict;

BEGIN {
    package BB;
    use Data::Dumper;

    use A;
    our @ISA = qw(A);
    our @EXPORT = (@A::EXPORT);
}

BEGIN {
    import BB;
}

use Data::Dumper;

print Dumper("main::v", $main::v);
print Dumper("A", $A::v);
print Dumper("BB", $B::v);
print Dumper("v", $v);



------------------------------

Date: Wed, 04 Apr 2007 14:08:17 +0100
From: bugbear <bugbear@trim_papermule.co.uk_trim>
Subject: Re: extending a module?
Message-Id: <4613a342$0$8718$ed2619ec@ptn-nntp-reader02.plus.net>

Brian McCauley wrote:
> On Apr 4, 11:39 am, bugbear <bugbear@trim_papermule.co.uk_trim> wrote:
> 
>> package A;
>> use strict;
>> use base qw(Exporter);
>> use vars qw(@EXPORT);
>> @EXPORT = qw($v);
>>
>> our $v = 42;
>>
>> 1;
> 
>> (main script)
>> package BB;
>> use strict;
>> use Data::Dumper;
>>
>> use A;
>> use vars qw(@EXPORT @ISA);
>> @ISA = qw(A);
>> @EXPORT = (@A::EXPORT);
>>
>> package main;
>> use Data::Dumper;
>>
>> print Dumper("main::v", $main::v);
>> print Dumper("A", $A::v);
>> print Dumper("BB", $B::v);
>> print Dumper("v", $v);
>>
>> which is the same but with the "BB" package inline,
>> the compiler barfs at the last line:
> 
> Not exactly - use() is a compile time operation. What you've done here
> is the inline analogue of "require BB" not "use BB".
> 
>> Variable "$v" is not imported at ./leak2.pl line 18.
>> Global symbol "$v" requires explicit package name at ./leak2.pl line 18.
>> Execution of ./leak2.pl aborted due to compilation errors.
>  
> ^^^^^^^^^^^^^^^^^^^^^^^^
> The clue is in the message, note the word "compilation".
> 
>> I tried adding a "import BB;" after the "package main;"
>> but it made no difference.
> 
> Yes, that is necessary but not sufficient. There are two differences
> between use() and require(). That's only one of them.
> 
> To make $main::v exist at compile time you need the assignment of
> @BB::EXPORT and the call to import BB to happen prior to the
> compilation of Dumper("v", $v) as they would if you'd use()d BB as a
> separate module file.
> 
> Note as an additional benefit of wrapping the inline BB in a block you
> don't need the explicit "package main" and it's save to use our for
> @EXPORT and @ISA.

Can I just say "thanks" for not only solving my problem,
but providing an excellent and clear explanation
of the issues.

    BugBear


------------------------------

Date: 4 Apr 2007 05:22:44 -0700
From: "Lew Pitcher" <lpitcher@sympatico.ca>
Subject: Re: How to resolve funky sync issues with fork here.
Message-Id: <1175689364.376659.162790@d57g2000hsg.googlegroups.com>

On Apr 3, 9:27 pm, "grocery_stocker" <cdal...@gmail.com> wrote:
> Here is a copy a persons code I saw on a blog. The only difference
> here is that I enable warnings use my().
>
> #!/usr/bin/perl -w
>
> my @array = qw(ugh geeze blah test smith bob homes point);
>
> my $num = "10";
>
> for(1..$num) {
>     my $pid = fork();
>     if ($pid) {
>     # parent
>         push(@childs, $pid);
>     } elsif ($pid == 0) {
>     # child
>         print "@array\n\n";
>         sleep 5;
>         exit(0);
>     } else {
>         die "couldn't fork: $!\n";
>     }
>     print "BEFORE FOR BRACKET\n";
>
> }
>
> print "AFTER FOR BRACKET\n";
>
> foreach (@childs) {
>     waitpid($_, 0);
>
> }
>
> And here is what I get when I run it a few times...
[snip]
> [cdalten@localhost perl]$ ./par.pl
> ugh geeze blah test smith bob homes point
>
> BEFORE FOR BRACKET
> ugh geeze blah test smith bob homes point
>
> BEFORE FOR BRACKET
> ugh geeze blah test smith bob homes point
>
> BEFORE FOR BRACKET
> ugh geeze blah test smith bob homes point
>
> BEFORE FOR BRACKET
> ugh geeze blah test smith bob homes point
>
> BEFORE FOR BRACKET
> BEFORE FOR BRACKET
> ugh geeze blah test smith bob homes point
>
> ugh geeze blah test smith bob homes point

I presume that the above apparent out-of-order results is what you are
concerned about?

> BEFORE FOR BRACKET
> ugh geeze blah test smith bob homes point
>
> BEFORE FOR BRACKET
> ugh geeze blah test smith bob homes point
>
> BEFORE FOR BRACKET
> ugh geeze blah test smith bob homes point
>
> BEFORE FOR BRACKET
> AFTER FOR BRACKET
> [cdalten@localhost perl]$
>
> The lines:
> BEFORE FOR BRACKET
> ugh geeze blah test smith bob homes point
>
> Sometmes don't appear in sync.

Scheduling of ready processes is rarely so simple as to natively
produce an "in sync" result unless you've coded a tight coupling
between the processes. I'd say that there is no real problem here; you
just caught a couple of processes executing in an order that, while
legal and proper, you didn't expect.

> How would I get them in sync?
> Would I have to insert another wait() into the child? Just need some ideas
> here.

Move your waitpid() call so that it executes immediately prior to
your
 print "BEFORE FOR BRACKET\n";
statement. This way, the parent will wait for the child to complete
(and thus write the array) before it proceeds to generate the BEFORE
FOR BRACKET line. In this way, you maintain a tight coupling between
parent process and child process.



------------------------------

Date: 4 Apr 2007 06:45:57 -0700
From: "grocery_stocker" <cdalten@gmail.com>
Subject: Re: How to resolve funky sync issues with fork here.
Message-Id: <1175694357.892119.143340@n76g2000hsh.googlegroups.com>

On Apr 4, 5:22 am, "Lew Pitcher" <lpitc...@sympatico.ca> wrote:
> On Apr 3, 9:27 pm, "grocery_stocker" <cdal...@gmail.com> wrote:
>
>
>
> > Here is a copy a persons code I saw on a blog. The only difference
> > here is that I enable warnings use my().
>
> > #!/usr/bin/perl -w
>
> > my @array = qw(ugh geeze blah test smith bob homes point);
>
> > my $num = "10";
>
> > for(1..$num) {
> >     my $pid = fork();
> >     if ($pid) {
> >     # parent
> >         push(@childs, $pid);
> >     } elsif ($pid == 0) {
> >     # child
> >         print "@array\n\n";
> >         sleep 5;
> >         exit(0);
> >     } else {
> >         die "couldn't fork: $!\n";
> >     }
> >     print "BEFORE FOR BRACKET\n";
>
> > }
>
> > print "AFTER FOR BRACKET\n";
>
> > foreach (@childs) {
> >     waitpid($_, 0);
>
> > }
>
> > And here is what I get when I run it a few times...
> [snip]
> > [cdalten@localhost perl]$ ./par.pl
> > ugh geeze blah test smith bob homes point
>
> > BEFORE FOR BRACKET
> > ugh geeze blah test smith bob homes point
>
> > BEFORE FOR BRACKET
> > ugh geeze blah test smith bob homes point
>
> > BEFORE FOR BRACKET
> > ugh geeze blah test smith bob homes point
>
> > BEFORE FOR BRACKET
> > ugh geeze blah test smith bob homes point
>
> > BEFORE FOR BRACKET
> > BEFORE FOR BRACKET
> > ugh geeze blah test smith bob homes point
>
> > ugh geeze blah test smith bob homes point
>
> I presume that the above apparent out-of-order results is what you are
> concerned about?
>

Yes, I'm concerned about the out-of-order-results.

>
> > BEFORE FOR BRACKET
> > ugh geeze blah test smith bob homes point
>
> > BEFORE FOR BRACKET
> > ugh geeze blah test smith bob homes point
>
> > BEFORE FOR BRACKET
> > ugh geeze blah test smith bob homes point
>
> > BEFORE FOR BRACKET
> > AFTER FOR BRACKET
> > [cdalten@localhost perl]$
>
> > The lines:
> > BEFORE FOR BRACKET
> > ugh geeze blah test smith bob homes point
>
> > Sometmes don't appear in sync.
>
> Scheduling of ready processes is rarely so simple as to natively
> produce an "in sync" result unless you've coded a tight coupling
> between the processes. I'd say that there is no real problem here; you
> just caught a couple of processes executing in an order that, while
> legal and proper, you didn't expect.
>
> > How would I get them in sync?
> > Would I have to insert another wait() into the child? Just need some ideas
> > here.
>
> Move your waitpid() call so that it executes immediately prior to
> your
>  print "BEFORE FOR BRACKET\n";
> statement. This way, the parent will wait for the child to complete
> (and thus write the array) before it proceeds to generate the BEFORE
> FOR BRACKET line. In this way, you maintain a tight coupling between
> parent process and child process.

I moved the waipid() right before:
print "BEFORE FOR BRACKET\n";

And when I ran the program a a few hundred times. I got the tight
coupling. Now, for whatever reasons, I thought the sleep() in the
child process would somehow produce the tight coupling.

One last question. How can I tell if this program is running
sequentially or in parallel? I tried tracing the code via the
debugger, but all I got where like 10 screens when I ran the code.

Thanks,
Chad



------------------------------

Date: Wed, 4 Apr 2007 22:37:33 +1000
From: "Sisyphus" <sisyphus1@nomail.afraid.org>
Subject: Re: How to run Perl script as GUI Windows program? Like Word, Notepad, Calculator etc.
Message-Id: <46139c0e$0$9770$afc38c87@news.optusnet.com.au>


"max" <max@xxx.tovle.ct> wrote in message 
news:euvkua$9bd$1@ss408.t-com.hr...
> How to run Perl script as GUI Windows program? Like Word, Notepad,
> Calculator etc.

In addition to Ian Wilson's suggestions, I (naively) expect that Win32::GUI 
might also have something to offer.

(Be aware that I'm no expert in this, or any other, area.)

Cheers,
Rob 



------------------------------

Date: Wed, 4 Apr 2007 21:11:05 +1000
From: "Sisyphus" <sisyphus1@nomail.afraid.org>
Subject: Re: How to turn off "Caps Lock" from Perl script.
Message-Id: <461387c7$0$5745$afc38c87@news.optusnet.com.au>


"katera" <katera@tovle.ct> wrote in message 
news:euvlkg$bh0$1@ss408.t-com.hr...
> How to turn off "Caps Lock" from Perl script.

This is a problem close to my heart. (I only ever hit the "Caps Lock" by 
mistake ... well ... to be honest, I have occasionally intentionally turned 
"Caps Lock" on when typing in product keys - which always seem to use upper 
case alpha chars).

A quick question to the perlmonks CB ascertained that (as far as was known) 
there's no perl solution to the problem.

There are, however, bound to be software solutions (depending upon your OS). 
On Win32, PowerToy is apparently one such solution.

However, acting on the judicious advice handed out on the perlmonks CB, I've 
just taken the hardware solution of prizing off the "Caps Lock" key and 
covering the hole with cellotape (to prevent foreign objects such as 
dandruff and breadcrumbs from getting into the guts of the keyboard).

It's working really well, so far, and looks like being the permanent 
solution to *my* woes wrt "Caps Lock".

Hth.

Cheers,
Rob 



------------------------------

Date: Wed, 04 Apr 2007 15:03:21 +0200
From: Michele Dondi <bik.mido@tiscalinet.it>
Subject: Re: HowTo parse huge Files
Message-Id: <dd8713tkvc5a96lpsl0h04palnmgje5i3p@4ax.com>

On 29 Mar 2007 05:24:30 -0700, "cadetg@googlemail.com"
<cadetg@googlemail.com> wrote:

>Dear Perl Monks, I am developing at the moment a script which has to

Now that I notice this:

http://perlmonks.org/?node_id=607211

I understand your intro better. Why didn't you say you also posted
there (although one may have guessed)? Why didn't you say there you
also posted here? Why didn't you report in each place what people told
you in the other one?


Michele
-- 
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
 .'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,


------------------------------

Date: 4 Apr 2007 05:06:06 -0700
From: "Stumo" <stumo@stumo.org.uk>
Subject: More controlled Module loading - Faking output from caller
Message-Id: <1175688366.096365.127560@d57g2000hsg.googlegroups.com>

Hi

I'm trying to write my own function that works like use but outputs a
more user friendly error message if the module isn't present.

My current tactic is to have my function in it's own package, and it
uses File::Package to do the loading - however this doesn't import
things into the correct namespace (neither does calling import()
directly for some packages that have redefined it).

Is there any way I can change what caller() returns, so my function
does not appear and everything behaves as if it was called from the
namespace that called my function?

Alternatively, are there any other solutions?

Stuart Moore



------------------------------

Date: Wed, 04 Apr 2007 08:32:48 -0400
From: Sherm Pendley <spamtrap@dot-app.org>
Subject: Re: More controlled Module loading - Faking output from caller
Message-Id: <m2odm4mia7.fsf@local.wv-www.com>

"Stumo" <stumo@stumo.org.uk> writes:

> I'm trying to write my own function that works like use but outputs a
> more user friendly error message if the module isn't present.

 ...

> Alternatively, are there any other solutions?

Push() a reference to your function onto the end of @INC. It'll be called
if the requested module isn't found in any of the previous entries.

    #!/usr/bin/perl

    use strict;
    use warnings;

    BEGIN {
        push @INC, sub {
            my ($self, $mod) = @_;
            die "no such module: $mod";
        };
    }

    use No::Such::Module;

See "perldoc -f require" for details.

sherm--

-- 
Web Hosting by West Virginians, for West Virginians: http://wv-www.net
Cocoa programming in Perl: http://camelbones.sourceforge.net


------------------------------

Date: Wed, 04 Apr 2007 14:35:33 +0200
From: Robert 'phaylon' Sedlacek <rs@474.at>
Subject: Re: More controlled Module loading - Faking output from caller
Message-Id: <46139bae$0$20282$9b4e6d93@newsspool3.arcor-online.net>

Stumo wrote:
> I'm trying to write my own function that works like use but outputs a
> more user friendly error message if the module isn't present.

'use' is a construct that is parsed by perl as soon as it's seen. IIRC
you can't make your own 'use' functions at the moment. You'd need to
have to call your function in a BEGIN { } block. Otherwise you will run
into problems with imported symbols that aren't available at compile time.

I would propose making it a regular module with an import() method. For
example, like this syntax:

  use Module::OrDieWithNiceMessage 'Module::To::Load', \@imports,
    { message => q(The module 'Module::To::Load couldn't be found) };

> My current tactic is to have my function in it's own package, and it
> uses File::Package to do the loading - however this doesn't import
> things into the correct namespace (neither does calling import()
> directly for some packages that have redefined it).

Personally I prefer Class::Inspector to do such things:

  use Class::Inspector;
  my $module = 'Foo::Bar';
  eval { require Class::Inspector->filename($module) };
  if ($@) {
      # handle module loading error
  }

> Is there any way I can change what caller() returns, so my function
> does not appear and everything behaves as if it was called from the
> namespace that called my function?

You could either use $module->can('import') to get at the code reference
for the original import() method and use goto to "replace" the current
subroutine with the imported one (although I don't know how you'd have
to work with @_) or use something like Sub::Uplevel (see CPAN).

> Alternatively, are there any other solutions?

See the above for a few solutions. I personally never needed such a
thing, but I'm wondering if there's nothing on CPAN yet to do this kind
of stuff.

 .phaylon


------------------------------

Date: 4 Apr 2007 12:46:16 GMT
From: anno4000@radom.zrz.tu-berlin.de
Subject: Re: More controlled Module loading - Faking output from caller
Message-Id: <57hl0oF2d9k6iU2@mid.dfncis.de>

Stumo <stumo@stumo.org.uk> wrote in comp.lang.perl.misc:
> Hi
> 
> I'm trying to write my own function that works like use but outputs a
> more user friendly error message if the module isn't present.
> 
> My current tactic is to have my function in it's own package, and it
> uses File::Package to do the loading - however this doesn't import
> things into the correct namespace (neither does calling import()
> directly for some packages that have redefined it).
> 
> Is there any way I can change what caller() returns, so my function
> does not appear and everything behaves as if it was called from the
> namespace that called my function?
> 
> Alternatively, are there any other solutions?

Don't call import, goto it.  That preserves the calling package so
->import won't be confused. Make sure, @_ is what you need it to be,
and then (untested)

    goto File::Package->can( 'import') ||
        die "'File::Package" can't import"

Anno


------------------------------

Date: Wed, 04 Apr 2007 08:00:46 -0400
From: Sherm Pendley <spamtrap@dot-app.org>
Subject: Re: perl OOP
Message-Id: <m2vegcmjrl.fsf@local.wv-www.com>

Xiong Changnian <please@nospam.net> writes:

> In article <slrnf156i7.s2c.abigail@alexandra.abigail.be>,
>  Abigail <abigail@abigail.be> wrote:
>
>> Xiong Changnian (please@nospam.net) wrote on MMMMCMLXIII September
>> MCMXCIII in <URL:news:please-9A3ECC.10162403042007@free.teranews.com>:
>> ||  
>> ||  BUT, new -- an object constructor -- is, by definition, used to make a 
>> ||  new object.
>> 
>> No. 'new' doesn't so by definition....
>
> What you mean to say is that "new" is not a reserved keyword

Abigail said exactly what he meant to. New() is not an object constructor
by definition. It is commonly used as such by convention.

> An object constructor is used to make a new object

Once again, Captain Obvious saves the day!

> I have /defined/ new to be an object constructor. My method new is, by 
> definition, used to make a new object.

You have no idea what the term "by definition" means, do you? The very fact
that you chose for yourself to follow convention proves that new() is not
an object constructor by definition. If it were, there would have been no
choice for you to make.

> Why would anyone have a problem with this? I really don't understand why 
> anyone would quibble in this fashion. What's the point?

The point is that you're wrong. You can whine that it's rude to point out
your mistake, or learn from your mistake and move on - your choice.

sherm--

-- 
Web Hosting by West Virginians, for West Virginians: http://wv-www.net
Cocoa programming in Perl: http://camelbones.sourceforge.net


------------------------------

Date: Wed, 04 Apr 2007 15:08:13 +0200
From: Michele Dondi <bik.mido@tiscalinet.it>
Subject: Re: perl OOP
Message-Id: <5h87135u6497msr73vlug63qlvd6aanlhv@4ax.com>

On Tue, 03 Apr 2007 13:38:43 -0400, Uri Guttman <uri@stemsystems.com>
wrote:

>  XC> * The $object is (usually) a reference to an anonymous hash. Inside our 
>
>no. it is always a blessed reference. what reference type is independent
>and there are reasons to use types other than hashes. inside-out objects

Indeed! In fact yesterday I posted an article in PerlMonks in which I
used a blessed subref. It is worth pointing out that I somewhat made a
fool of me because the "problem" I addressed by that technique is
better handled with simple overloading, while I had mistakenly assumed
that the latter could not take care of that. What is important is that
the thread was instructive, anyway:

http://perlmonks.org/?node_id=608102


Michele
-- 
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
 .'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,


------------------------------

Date: Wed, 04 Apr 2007 17:05:37 +0200
From: Michele Dondi <bik.mido@tiscalinet.it>
Subject: Re: perl OOP
Message-Id: <i3f713l00poscie90manl55s6s9tufsm4o@4ax.com>

On Wed, 04 Apr 2007 01:23:34 -0700, Xiong Changnian
<please@nospam.net> wrote:

>> ||  BUT, new -- an object constructor -- is, by definition, used to make a 
>> ||  new object.
>> 
>> No. 'new' doesn't so by definition....
>
>What you mean to say is that "new" is not a reserved keyword; you're 
>right: it's arbitrarily chosen. 
>
>An object constructor is used to make a new object and in my sample code 
>I have /defined/ new to be an object constructor. My method new is, by 
>definition, used to make a new object. 
>
>* * *
>
>Why would anyone have a problem with this? I really don't understand why 
>anyone would quibble in this fashion. What's the point? 

Personally I think he was right pinpointing that. From your words it
may actually seem that you mean that new is a reserved keyword. This
is a common misconception. Thus anything that correctes it is mostly
welcome. Also, I'm not a big supporter of the "principle of
authority", but quite about anything that Abigail writes, even if
controversial, is *by definition* interesting. Thus I would pay
attention to it, a priori.


PS: May I dare to make a personal remark? Conciseness is by no means a
quality of mine, and I regret it. But you seem beat me by several
orders of magnitude. Granted: I'm not claiming we should all express
ourselves with slogans, do not misunderstand me. In fact there may be
good reasons to be verbose in certain given situations. But from the
admittedly restricted statistical sample of your posts thus far my
impression is that the content/container ratio is ridicolously low.
Apart some of them to which I applied the good will to read from
beginning to end, I'm now skipping them altogether from some point on,
and I bet others will be similarly annoyed. Since you also seem to
have something interesting to say (otherwise I would simply ignore or
killfile you with no regret) can I suggest you try to condense it some
more?


Michele
-- 
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
 .'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,


------------------------------

Date: Wed, 04 Apr 2007 16:51:57 +0200
From: Michele Dondi <bik.mido@tiscalinet.it>
Subject: Re: Problem in the Perl script
Message-Id: <pke713lsburv6lrd4ibhppdq27nq1c2sq8@4ax.com>

On Wed, 04 Apr 2007 00:46:20 -0700, Xiong Changnian
<please@nospam.net> wrote:

>> I hadn't. I didn't even know what "manhole" meant. Of course I do know
>> what a manhole is. I just didn't know the English word....
>
>Philip Roth writes of his struggle with his parents' native language 
>(Yiddish) in /Portnoy's Complaint/:

Quite curiously, I read *that* book quite recently, namely last
summer. I didn't remember that detail, though. On an even more OT
basis, today I read an interesting and funny blog entry on how
language changes over time, that was reported in an italian comics ng
I follow:

http://www.yesbutnobutyes.com/archives/2007/03/top_15_unintent.html


Michele
-- 
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
 .'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,


------------------------------

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 301
**************************************


home help back first fref pref prev next nref lref last post