[19382] in Perl-Users-Digest
Perl-Users Digest, Issue: 1577 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue Aug 21 11:05:36 2001
Date: Tue, 21 Aug 2001 08:05:08 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Message-Id: <998406308-v10-i1577@ruby.oce.orst.edu>
Content-Type: text
Perl-Users Digest Tue, 21 Aug 2001 Volume: 10 Number: 1577
Today's topics:
$0 how to obtain the full path <massimo_morelli@hotmail.com>
Re: $0 how to obtain the full path (John J. Trammell)
Re: $0 how to obtain the full path <massimo_morelli@hotmail.com>
Re: Embedded perl question (Robert J. Lee)
fork() does not work <tiedje.t@stn-atlas.de>
Forwarding To A Page Dependant on User Choice In A Form <rhnetka@myASPhosting.com>
gethostbyaddr resolving <achatz@forthnet.gr>
HTTP::Request::Common file upload <pdumarchie@goldenbytes.com>
Re: passing arrays to a subroutine <philippe.perrin@sxb.bsf.alcatel.fr>
Re: passing arrays to a subroutine <bart.lateur@skynet.be>
Re: passing arrays to a subroutine (Rafael Garcia-Suarez)
Re: passing arrays to a subroutine <ubl@schaffhausen.de>
Re: Perl OO needs the opposite of SUPER:: <ren@tivoli.com>
Re: Perl OO needs the opposite of SUPER:: <ren@tivoli.com>
Re: permuting extremely large string <iltzu@sci.invalid>
Prevent module SNMP_Session to generate a die by which <c.w.vandervelden@kpn.com>
Re: Prevent module SNMP_Session to generate a die by wh <ilya@martynov.org>
Re: subroutines in @INC ? <bart.lateur@skynet.be>
Re: subroutines in @INC ? (Anno Siegel)
Re: subroutines in @INC ? <johndporter@yahoo.com>
Re: subroutines in @INC ? (Anno Siegel)
Re: System call <Graham.T.Wood@oracle.com>
Re: This is not a question ... call me slow if you like <iltzu@sci.invalid>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 21 Aug 2001 16:11:05 +0200
From: "Massimo Morelli" <massimo_morelli@hotmail.com>
Subject: $0 how to obtain the full path
Message-Id: <9ltp8u$nff$1@pinco.nettuno.it>
This should have been simpler.
The program name is tpa.pl:
#!/usr/bin/perl
print $0, "\n";
on unix:
./tpa.pl
on w2000, invoked as tpa.pl:
C:\DOCUME~1\morelli\DOCUME~1\max\src\STAGE\MOVER\SISMA\tpa.pl
on w2000, invoked as perl tpa.pl
tpa.pl
How could I obtain the FULL path of the program?
(cwd() does not work: it is the path from where the program is invoked).
I searched the net, the faq, the books but nothing came out.
Many thanks in advance.
Massimo
------------------------------
Date: 21 Aug 2001 14:35:48 GMT
From: trammell@haqq.hypersloth.invalid (John J. Trammell)
Subject: Re: $0 how to obtain the full path
Message-Id: <slrn9o5bk2.2ki.trammell@haqq.hypersloth.net>
On Tue, 21 Aug 2001 16:11:05 +0200, Massimo Morelli wrote:
> This should have been simpler.
perldoc FindBin
------------------------------
Date: Tue, 21 Aug 2001 16:46:39 +0200
From: "Massimo Morelli" <massimo_morelli@hotmail.com>
Subject: Re: $0 how to obtain the full path
Message-Id: <9ltrbj$o0o$1@pinco.nettuno.it>
Oops.
Many thanks, John.
"John J. Trammell" <trammell@haqq.hypersloth.invalid> wrote in message
news:slrn9o5bk2.2ki.trammell@haqq.hypersloth.net...
> On Tue, 21 Aug 2001 16:11:05 +0200, Massimo Morelli wrote:
> > This should have been simpler.
>
> perldoc FindBin
>
------------------------------
Date: 21 Aug 2001 07:33:15 -0700
From: Zarlock@pretty.co.uk (Robert J. Lee)
Subject: Re: Embedded perl question
Message-Id: <262e5e2a.0108210633.51a192e9@posting.google.com>
Benjamin Goldberg wrote:
> Robert J. Lee wrote:
> > Benjamin Goldberg wrote:
> > > Robert J. Lee wrote:
> > > >
[snip]
[snip of confusing bit where I got confused between subroutines and
functions]
>
> I'm not sure what you mean. If a variable is successfully restored by
> whatever mechanism reads it from the file, then there's no need for it
> to be re-initialized. Why do you assume that it would be 'initialized'
> when it doesn't need to be?
Okay; that wasn't very clear. If the programmer says something like:
$my_variable = 14;
to set the initial value of $my_variable, then every time that line is
processed, it will set the value of $my_variable to 14, even if it has
changed. This could cause problems if that line lies in a block of
code which is read in and processed every time the MUD is started. (As
the MUD is supposed to assume the same state when it starts as it had
when it last ended). This problem goes away when you override it by
loading the variable from a file, but that means working out which
variables to save and load in the first place.
[snip]
> There's an easier way. Just *ask* your authors which variables need to
> be made persistant. Use packages to keep namespaces seperate, and when
> each function is completed, print to the author a list of
> already-persistant variables, and ask if there are any variables used by
> the function which should be persistant but aren't.
Keeping an editable list of the names of all data to be saved is easy
enough.
>
> > > What are you adding scripting for?[snip]
> >
> > The idea is that administrators of the MUD can write subroutines to
> > control how the mud operates (every time someone does something, a
> > perl subroutine is called that checks if any others need to be called
> > to change anything in the MUD). That way, administrators can control
> > exactly what the MUD does in any situation without learning C++,
> > writing lots of messy code and shutting the MUD down to recompile, and
> > without needing direct access to the server to recompile everything.
> > Thus leaving me free to focus on implementing more C++ things.
>
> If you require that the admins put their code in packages [or better
> yet, have the editor prefix their code with appropriate package
> declarations], you should be able to do this without needing any special
> "save everything" module.
Saving the code itself isn't too much of a problem; just put in a
filter in the C++ side to say "save anything typed in in 'perl mode'
to a file". My problem was that I didn't see how to cope with
variables being changed in 'perl mode'. But with a list of variables
to be saved, this shouldn't be too much of a problem.
> > > Anyway, do you really expect that the perl code you had before a
> > > compile will work well with everything after a recompile? I don't
> > > think so.
> >
> > I don't know. I would have thought that as long as the perl side stays
> > the same, and it doesn't use any callbacks into C++ code, that
> > recompiling the C++ side shouldn't make any difference. Wether it
> > would work after being reloaded into memory, I have no idea (pointers
> > to memory areas that have moved etc.). If it *can* be done, then I'm
> > sure someone here will know how...
>
> The thing is, there obviously have to be some callbacks to the C++ for
> the perl code to do anything useful.
Not necessarily. The C++ code can just look directly at the state of
the perl code and see what's changed after calling a perl function (if
all variables are in perl, there's no reason for the C++ code to even
know anything more than "this is the text to give to user number 3").
But it might be easier if it did use callbacks.
> > > Any bits of perl code you need should probably be put each in their
> > > own file, and loaded from those files when the MUD starts [or better
> > > yet, only when they're needed]. Saving the state that the loaded
> > > pieces of code were in when the mud was last up is probably wrong.
> >
> > Except if their state has changed since they were put each in their
> > own file. Which is very likely in this case.
>
> I think you're confusing data with code. You put the code [the
> subroutines] into files when it's written. You put the data into files
> once when it's created [by the subroutines], plus every X minutes as
> backup, and once when the mud shuts down.
>
> The code [the subroutines] is initially in files, it gets loaded when
> users first enter the part of the mud it's relevant to [or loaded when
> the mud boots up], the BEGIN blocks in the code are called, which
> register various callbacks and load the data from the files, and
> registers the data with some sort of backup mechanism. The callbacks do
> whatever special behaviour the admins need.
Code is just data treated in a special way :)
Only thing I don't understand is how exactly one says "save this datum
to a file when it gets created"?
Again, there's quite a bit of work in writing the code to
auto-generate all the save and restore code compared to a complete
save/restore state option. But I guess this is the next best thing.
> > It looks like I'll have to save the subroutines as they are created,
> > and re-load them first on start-up, saving the variables on shut-down,
> > and re-loading them after subroutines to change their values back to
> > what they should be. I was hoping that it could be done more easily
> > than this.
>
> This is exactly the way to do it, except that you can write it so don't
> necessarily need to think about it this way.
>
> For instance:
> package Administorators::AdminName::foo;
> use MudUtilities::Persistant;
> MudUtilities::Persistant::MakePersist \( our ($foo, $bar, $blah) )
> or do {
> $foo = .... initializer for $foo goes here ...;
> $bar = ....;
> $blah = ....;
> }
> ... code which uses $foo, $bar, $blah ...
> sub asdf {
> }
> __END__
>
> The thing is, some code in the file gets run when the file is loaded,
> [including the *definitions* of the subs], but the subs don't actually
> get called until they're called. So you can initialize them however you
> want. Some of this stuff can be auto-generated, too, to make things
> easier. MakePersist can look at caller() to figure out what file called
> it, and use that to figure out where to put the data [each admin's data
> should be seperate from each other admin's data, and for that matter,
> each admin might want each file, each group of subroutines to have
> seperate data files].
This still looks to me like quite a complicated solution to a trivial
problem; I want to add a perl interpretor to a MUD, create new data
and code on demand, and have the state saved to a file so I can reload
after a shutdown at the same place as I left off.
If perl had a "save-everything" and a "load-everything" command then
it would be a lot easier (since I have a fair amount of disk space to
throw at it).
Oh well, it's still easier than writing my own parsing language...
------------------------------
Date: Tue, 21 Aug 2001 16:56:52 +0200
From: "Th. Tiedje" <tiedje.t@stn-atlas.de>
Subject: fork() does not work
Message-Id: <9ltsrj$t9d2@dsit03.atlas.de>
Hi everybody !
What do I have to do to get fork() running
on WNT ?
I know there are CPAN modules out there managing
processes but I simply want to fire up a process
and then forget about it. I believe fork()/exec()
to be the simplest solution.
I'm running WNT 4 and perl -V says "perl5 (5.0
patchlevel 5 subversion 02)". If you need further
information I will gladly supply it.
My apologies if I made a dumb error (not counting
using WNT) or overlooked something obvious.
Thank you for your efforts,
Thomas
And for those craving for code, here it comes:
File whatever.pl:
#!/usr/bin/perl -w
print "Before fork\n";
if (!defined(fork())==0) {
print "fork() error: $?\n";
} else {
print "This is the fork \n";
exec("perl", "foo.pl");
}
print "After fork in 'main'\n";
exit 0;
File foo.pl:
#!/usr/bin/perl -w
print "Forked process\n";
exit 0;
Execution:
1. Put both file into the same directory
2. perl whatever.pl
What I get (within ""):
"Before fork
The Unsupported function fork function is
unimplemented at whatever.pl line 3."
------------------------------
Date: Tue, 21 Aug 2001 14:54:06 GMT
From: "Ryan Hnetka" <rhnetka@myASPhosting.com>
Subject: Forwarding To A Page Dependant on User Choice In A Form??
Message-Id: <iCug7.496$KoS1.10879375@tomcat.sk.sympatico.ca>
Hey Everyone,
I am new to this list, so I apologize in advance if I mess something up.
I am trying to find a CGI script available for free or for a small fee that
will allow me to....well, maybe I will just explain what I need...
The page will be a form for someone to fill in the normal information (name,
address, etc) The form will also include a set of radio buttons (or a drop
down list). This list will be of six different airplanes for sale. The
user will choose which plane they are interested in. Once they are finished
filling in our required information, and choosing which plane they are
interested in, they will hit a submit button.
The actions I need the CGI to do are these:
- process the form and send all the information to multiple email
accounts
- forward the user to a specific URL, based on which plane they wanted
more information on. Basically, the page with the information on the one
plane they choose.
Is this possible? I have looked at many of the regular sites for CGI
scripts, and such and can't find a thing that says it can do this.
Something I looked at in particular was "Form Processor Pro" from MitriDat -
http://www.mitridat.com
They tell me their form will do everything I need, but from looking at the
information on their site, I can't see how. Has anyone had any experience
with this form, and if so, do you think it will provide me with everything I
need?
Thank you for you help everyone.
Ryan Hnetka
My ASP Hosting Inc.
http://www.myASPhosting.com
------------------------------
Date: Tue, 21 Aug 2001 16:33:56 +0300
From: Tassos Chatzithomaoglou <achatz@forthnet.gr>
Subject: gethostbyaddr resolving
Message-Id: <3B826344.EE922144@forthnet.gr>
Let's suppose we have the following dns error condition:
using unix host
---------------
%host 10.200.100.34
Name: sw-ll-ath-01.forthnet.prv
Address: 10.200.100.34
Aliases:
%host 10.200.100.38
Name: sw-ll-ath-01.forthnet.prv
Address: 10.200.100.38
Aliases:
%host sw-ll-ath-01.forthnet.prv
sw-ll-ath-01.forthnet.prv has address 10.200.100.34
Using perl
----------
$router1 = "10.200.100.34";
$router2 = gethostbyaddr(inet_aton($router1),AF_INET);
works ok,
while
$router1 = "10.200.100.38";
$router2 = gethostbyaddr(inet_aton($router1),AF_INET);
doesn't.
$router2 is returned empty (undefined).
Is gethostbyaddr supposed to do "double" resolving (reverse + zone)?
Shouldn't it check only the reverse record?
--
***************************
Chatzithomaoglou Anastasios
Network Operations Center
FORTHnet S.A.
<achatz@forthnet.gr>
***************************
------------------------------
Date: Tue, 21 Aug 2001 15:08:26 +0200
From: "Peter du Marchie" <pdumarchie@goldenbytes.com>
Subject: HTTP::Request::Common file upload
Message-Id: <998399257.275886@newsreader2.wirehub.nl>
Hi everyone,
I wonder if someone can tell me if it is possible to upload files that are
only in memory, not on disk.
I know I can put them on disk first, but I'd rather not, because I extract
them from an email message, and I don't want to have to check for duplicate
filenames, etc.
According to the documentation for HTTP::Request::Common, I have to "[u]se
an undef as $file value if [I] want to specify the content directly." But
what does that mean? How do I provide the contents if $file has to be
undefined?
Thanks in advance for all tips,
Peter du Marchie
------------------------------
Date: Tue, 21 Aug 2001 15:01:02 +0200
From: Philippe PERRIN <philippe.perrin@sxb.bsf.alcatel.fr>
Subject: Re: passing arrays to a subroutine
Message-Id: <3B825B8E.F7446CFC@sxb.bsf.alcatel.fr>
Eli Bendersky wrote:
> I want a subroutine which receives 2 arrays as arguments
> and does some computing with them.
You can pass references as arguments (so side effects inside your
subroutine will be visible from outside). They act like pointers in C :
@arrayA = (1, 2, 3);
@arrayB = (4, 5, 6);
myprint(\@arrayA, \@arrayB);
sub myprint
{
my ($refA, $refB) = @_;
print "2 is $$refA[1]\n"; # to access a given element
print "B is @$refB\n"; # to access the whole array
}
What is more, since there is no copy of your arrays, you save memory.
--
PhP
($r1,$r2,$r3,$r4)=("19|20","0|1","28|29","5|24");($r5,$r6)=("9|10|15|16|$r1|$r2","9|10|$r3");%h=("1|",$r6,"1=","[1-5]|2[0-4]","1/","0|19","1\\","6|25","2|","0|6|19|25|$r6","2/","1|20","2\\",$r4,"3|","$r2|6|$r1|25|$r6","3/",$r4,"4|","$r2|$r1|$r6","4=","2|3|4|11|12|13|14|21|22|23","4/",$r4,"4\\",15,"5|","$r2|9|15|$r1|20|$r3","5/",10,"6|",$r5,"7|",$r5,"7/",$r3);for($l=1;$l<8;$l++){b:for($i=0;$i<30;$i++){c:foreach(keys
%h){next c if(!(/^$l(.*)$/));$a=$1;if($i=~/^($h{$_})$/){print $a;next
b;}}print " ";}print "\n";}
------------------------------
Date: Tue, 21 Aug 2001 13:27:46 GMT
From: Bart Lateur <bart.lateur@skynet.be>
Subject: Re: passing arrays to a subroutine
Message-Id: <27o4otc8e52oekrl2qt1lomi7fc2cuavp6@4ax.com>
Tad McClellan wrote:
>Eli Bendersky <eliben@il.ibm.comNOSPAM> wrote:
>>
>>I want a subroutine which receives 2 arrays as arguments
>>and does some computing with them.
>
>
>Not possible in Perl.
It's kinda possible, using prototypes.
>>How can I achieve it ?
>
>
>Pass two _references_ to arrays instead.
>
> perldoc perlreftut
> perldoc perlref
Well... Using the proper prototype, you can use plain arrays at the
calling part, and you get refs in the sub. So it's a blend of the two.
sub addarrays (\@\@); # necessary if perl doesn't know about
# this sub at the time you first call it
my @a = (1, 2, 3);
my @b = (10, 20, 30);
print join ", ", addarrays(@a, @b);
sub addarrays(\@\@) {
my($aref, $bref) = @_;
return map { $aref->[$_]+$bref->[$_] } 0 .. $#$aref;
}
-->
11, 22, 33
--
Bart.
------------------------------
Date: 21 Aug 2001 13:22:43 GMT
From: rgarciasuarez@free.fr (Rafael Garcia-Suarez)
Subject: Re: passing arrays to a subroutine
Message-Id: <slrn9o4ofg.hei.rgarciasuarez@rafael.kazibao.net>
Philippe PERRIN wrote in comp.lang.perl.misc:
} Eli Bendersky wrote:
} > I want a subroutine which receives 2 arrays as arguments
} > and does some computing with them.
}
} You can pass references as arguments (so side effects inside your
} subroutine will be visible from outside). They act like pointers in C :
}
} @arrayA = (1, 2, 3);
} @arrayB = (4, 5, 6);
} myprint(\@arrayA, \@arrayB);
}
} sub myprint
} {
} my ($refA, $refB) = @_;
}
} print "2 is $$refA[1]\n"; # to access a given element
} print "B is @$refB\n"; # to access the whole array
} }
}
} What is more, since there is no copy of your arrays, you save memory.
Prototypes are also an option. With
sub myprint (\@\@) {
my ($refA, $refB) = @_;
# ...
}
you can write
myprint @arrayA, @arrayB;
(but no longer myprint([1],[2,3])...)
See perlsub.
--
Rafael Garcia-Suarez / http://rgarciasuarez.free.fr/
------------------------------
Date: Tue, 21 Aug 2001 16:02:09 +0100
From: Malte Ubl <ubl@schaffhausen.de>
Subject: Re: passing arrays to a subroutine
Message-Id: <3B8277F0.A1E1880B@schaffhausen.de>
Paul Fortescue schrieb:
>
> "Eli Bendersky" <eliben@il.ibm.comNOSPAM> wrote in message
> news:3B825C48.17A60983@il.ibm.comNOSPAM...
> > Hi,
> >
> > I want a subroutine which receives 2 arrays as arguments
> > and does some computing with them.
> I think this is what you want ...
> @array=qw(A B);
> print "$array[0], $array[1]\n";
> thing(*array);
>
> sub thing
> {
> local *arrayinsub= $_[0];
> print "$arrayinsub[0], $arrayinsub[1]\n";
> }
>
This is probably not what the OP wanted. Look at the other post
for better solutions.
->malte
------------------------------
Date: 20 Aug 2001 22:28:13 -0500
From: Ren Maddox <ren@tivoli.com>
Subject: Re: Perl OO needs the opposite of SUPER::
Message-Id: <m33d6m852q.fsf@dhcp9-161.support.tivoli.com>
On Tue, 21 Aug 2001, mgjv@tradingpost.com.au wrote:
> [1] mine disregarded the gen() method, and instead assumed that
> report() would be called directly. That was a misunderstanding on
> my part, but the point still stands; the song remains the same...
Not that it matters, but mine originally did the same, then I realized
I could leave the gen() call in place to save the implementation
(child?) classes from having to make any SUPER:: calls at all.
--
Ren Maddox
ren@tivoli.com
------------------------------
Date: 20 Aug 2001 23:38:56 -0500
From: Ren Maddox <ren@tivoli.com>
Subject: Re: Perl OO needs the opposite of SUPER::
Message-Id: <m3y9oe6n8f.fsf@dhcp9-161.support.tivoli.com>
On 20 Aug 2001, johnlin@chttl.com.tw wrote:
> Ren Maddox wrote
>> On 18 Aug 2001, John Lin wrote:
>> > But, with current Perl's restriction, using your solution:
>> >
>> > Report::
>> > sub pre_gen; # You need to modify the original class
>> > sub gen; # breaking down subroutines into pieces
>> > sub post_gen; # which I consider to be ugly :)
>> > sub pre_save_as_html;
>> > sub save_as_html;
>> > sub post_save_as_html;
>> > sub pre_print_to_printer;
>> > sub print_to_printer;
>> > sub post_print_to_printer;
>> >
>> [snipped ExtendedReport skeleton]
>>
>> At first blush, I'm not visualizing why you would need all of this.
>> If you are expecting virtual report to handle everything, then
>> pre_report and post_report can handle it. There is no need for
>> pre_gen, post_gen, etc.
>
> Sorry, I meant:
>
> sub gen {
> $self->pre_report_in_gen;
> $self->report;
> $self->post_report_in_gen;
> }
>
> and also
> pre_report_in_save_as_html;
> post_report_in_save_as_html;
> pre_report_in_print_to_printer;
> post_report_in_print_to_printer;
> ...
That still misses the point. In your hypothetical VIRTUAL system, you
said that all you have to change is the virtual implementation of
report(). But if that is true, then in my system all you have to
change is the middle-level implementation of pre_report and
post_report. There is no need to create all these extra pre and post
calls.
Now, if instead you are actually intending to enhance other methods
from the base class then you may need to add this extra structure.
> Actually what I tried to say was:
>
> Since we want to override the "interface", then orerride it, and
> done!!!
Hmm.. that doesn't seem like what you are saying. You don't want to
just override it, you want to interpose the new method in such a way
that the original method is still called.
> Instead, you have to find out every spots where this "interface" is
> used/called, and re-arrange the caller (gen, save_as_html, etc) into
> pieces of ugly codes. That's considered (by me) a drawback of
> current Perl OO.
>
> In most cases, reusing base-class requires that you don't modify it.
> For example, the base class is downloaded from CPAN, or it is the
> company's legacy kernel code. (Hey, reusing, not re-writing!)
That's certainly not true. You simply subclass the base class and
override any methods you want to change. No problem.
> In my solution, everything is done in the middle layer. The base
> class doesn't need to be touched. And it can focus on "what you
> want to do" and no extra efforts needed.
The base class never *needs* to be touched. You simply override
whatever methods need to be overridden. Now, if the base class method
calls
Still, I think I see your point. Assume that you have a base class
that you cannot change and that is poorly implemented in such a way
that distinct behavior is embedded within a single method. Your Report
class has such a method -- gen() does some pre-work, calls a
polymorphic method, then does some post-work. It provides no way to
enhance the pre- or post-work without duplicating code.
My solution was to modify the base class to split off those pieces so
that they can be overridden separately. The alternative is to avoid
modifying the original class and simply override it. But then you are
forced into re-implementing the base class functionality, sacrificing
code reuse.
The solution you suggest is kind of a partial override. You break
polymorphism to force your own behavior on your subclasses. Assuming
such a mechanism, would the subclass be able to override this
behavior?
I expect there is a way to finagle this behavior with Perl, though I
haven't quite come up with it. It might involve overriding the new()
method and perhaps even mucking with the caller's namespace.
I still think the answer is a better design. Or, if you cannot
control the base class, then you are stuck overriding the methods that
need to change, including duplicating code. After all, in your example
you still want all of the base class's behavior, but it is entirely
possible that you only want part of it. I don't see how you could
have a general solution for only partially overriding methods and
getting exactly the interaction you want.
Maybe if you could give an explicit example, even in another language
if necessary, that would help to clarify your need.
--
Ren Maddox
ren@tivoli.com
------------------------------
Date: 21 Aug 2001 14:27:57 GMT
From: Ilmari Karonen <iltzu@sci.invalid>
Subject: Re: permuting extremely large string
Message-Id: <998403953.6486@itz.pp.sci.fi>
In article <3B8145D4.DEFB44BF@yahoo.com>, John Porter wrote:
>Ilmari Karonen wrote:
>> use Tie::CharArray;
>> tie my @chars, 'Tie::CharArray', $string;
>> # now permute @chars with the standard Fisher-Yates shuffle
>
>Yes; but wouldn't it be significantly more efficient to
>modify the F-Y shuffle to swap characters in the string
>directly?
Yes -- about 6 times faster according to my benchmark. But the code
looks a lot uglier. :-)
--
Ilmari Karonen -- http://www.sci.fi/~iltzu/
"Get real! This is a discussion group, not a helpdesk. You post something,
we discuss its implications. If the discussion happens to answer a question
you've asked, that's incidental." -- nobull in comp.lang.perl.misc
------------------------------
Date: Tue, 21 Aug 2001 16:11:50 +0200
From: "Karel van der Velden" <c.w.vandervelden@kpn.com>
Subject: Prevent module SNMP_Session to generate a die by which my CGI script stops running
Message-Id: <uCsMQwkKBHA.318@net005s.hetnet.nl>
Hello All,
I wrote an application which collects snmp data from a bunch of systems. I'm
using the SNMP_Session package. This application is supposed to run all the
time. The problem is that apparently SNMP_Session executes a Perl die when
there's an SNMP problem (e.g. no response received). This, in turn,
terminates the whole application (cgi script). How can I prevent this module
to terminate my program?
Thx in advance,
Karel
------------------------------
Date: 21 Aug 2001 18:46:11 +0400
From: Ilya Martynov <ilya@martynov.org>
Subject: Re: Prevent module SNMP_Session to generate a die by which my CGI script stops running
Message-Id: <87elq5pj2k.fsf@abra.ru>
KvdV> Hello All,
KvdV> I wrote an application which collects snmp data from a bunch of
KvdV> systems. I'm using the SNMP_Session package. This application is
KvdV> supposed to run all the time. The problem is that apparently
KvdV> SNMP_Session executes a Perl die when there's an SNMP problem
KvdV> (e.g. no response received). This, in turn, terminates the whole
KvdV> application (cgi script). How can I prevent this module to
KvdV> terminate my program?
eval {
.... code that can call die ...
};
if($@) {
.... check why we have died ...
}
See 'perldoc -tf eval'
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
| Ilya Martynov (http://martynov.org/) |
| GnuPG 1024D/323BDEE6 D7F7 561E 4C1D 8A15 8E80 E4AE BE1A 53EB 323B DEE6 |
| AGAVA Software Company (http://www.agava.com/) |
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
------------------------------
Date: Tue, 21 Aug 2001 13:19:55 GMT
From: Bart Lateur <bart.lateur@skynet.be>
Subject: Re: subroutines in @INC ?
Message-Id: <90o4ot0a0v7fm6ninngt10kfeerruacbf7@4ax.com>
Anno Siegel wrote:
>Thanks, that's interesting. Let me quote the code example:
>
> BEGIN {
> push @INC, \&somesub;
> sub somesub {
> my ($owncoderef, $wanted_file) = @_;
> # Produce a filehandle somehow
> if ($got_a_handle) {
> return *FH;
> } else {
> returm undef;
> }
> }
> }
>
>So it appears that it does indeed expect a filehandle to be returned,
>and a module is read from it if so. No %INC entry is made.
A file handle?
This sounds like a feature to make tools like perl2exe and perlapp, that
include module source into the same file.
But I can imagine doing strange stuff like pulling in modules over a
network socket.
--
Bart.
------------------------------
Date: 21 Aug 2001 14:00:38 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: subroutines in @INC ?
Message-Id: <9ltpi6$e4v$1@mamenchi.zrz.TU-Berlin.DE>
According to Bart Lateur <bart.lateur@skynet.be>:
> Anno Siegel wrote:
>
> >Thanks, that's interesting. Let me quote the code example:
> >
> > BEGIN {
> > push @INC, \&somesub;
> > sub somesub {
> > my ($owncoderef, $wanted_file) = @_;
> > # Produce a filehandle somehow
> > if ($got_a_handle) {
> > return *FH;
> > } else {
> > returm undef;
> > }
> > }
> > }
> >
> >So it appears that it does indeed expect a filehandle to be returned,
> >and a module is read from it if so. No %INC entry is made.
>
> A file handle?
I suppose that is how the internal see_if_this_module_is_in_this_directory()
routine works: return NULL or an open file.
> This sounds like a feature to make tools like perl2exe and perlapp, that
> include module source into the same file.
You mean, the resulting "binaries" use the feature to pull in modules
they contain themselves? Makes sense.
> But I can imagine doing strange stuff like pulling in modules over a
> network socket.
Quite. In the p5p digest, Simon mentions reading modules from a zipped
archive.
Oh, and it gets weirder: You can also deposit an object in @INC, on which
the method INC is then called. Now, what happens if the object has &{}
overloaded and is also a coderef... :)
Anno
------------------------------
Date: Tue, 21 Aug 2001 14:32:25 GMT
From: John Porter <johndporter@yahoo.com>
Subject: Re: subroutines in @INC ?
Message-Id: <3B82705B.E0D39939@yahoo.com>
Anno Siegel wrote:
> BEGIN {
> push @INC, \&somesub;
> sub somesub {
>
> So it appears that it does indeed expect a filehandle to be returned,
> and a module is read from it if so. No %INC entry is made.
Also note that this coderef is pushed onto the end of @INC,
presumably because it is used as a catchall, for modules which
are not found by traditional lookup means.
--
John Porter
------------------------------
Date: 21 Aug 2001 14:47:11 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: subroutines in @INC ?
Message-Id: <9lts9f$e4v$2@mamenchi.zrz.TU-Berlin.DE>
According to John Porter <johndporter@yahoo.com>:
> Anno Siegel wrote:
> > BEGIN {
> > push @INC, \&somesub;
> > sub somesub {
> >
> > So it appears that it does indeed expect a filehandle to be returned,
> > and a module is read from it if so. No %INC entry is made.
>
> Also note that this coderef is pushed onto the end of @INC,
> presumably because it is used as a catchall, for modules which
> are not found by traditional lookup means.
That may be advisable, but it isn't necessary. When the code returns
undef, the search goes on as it would otherwise.
Anno
------------------------------
Date: Tue, 21 Aug 2001 14:20:37 +0100
From: Graham Wood <Graham.T.Wood@oracle.com>
Subject: Re: System call
Message-Id: <3B826025.54F96EF1@oracle.com>
This is a multi-part message in MIME format.
--------------294907030064CE3CF63297FD
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
agm@physics.berkeley.edu wrote:
> I make a system call of the form:
>
> system "cd /home/john";
>
Use perl's built in chdir function instead. Also die if it doesn't work
and ask perl to tell you why.
chdir ("/home/john") || die "Can't cd to /home/john because $!\n";
$! contains the last error message generated by the system. If there is no
/home/john directory this would explain your error message too.
>
> or
>
> system "PATH=/usr/bin:/bin:";
>
This is asking the system to call a command called PATH which, as far as I
know, doesn't exist. To access environment variables, use the predefined
%ENV hash, as in:
$OLDPATH=$ENV{PATH}
$ENV{PATH}="/usr/bin:/bin:$OLDPATH";
Note that this change will only last until the script exits.
Hope this helps.
Graham Wood
--------------294907030064CE3CF63297FD
Content-Type: text/x-vcard; charset=UTF-8;
name="Graham.T.Wood.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Graham Wood
Content-Disposition: attachment;
filename="Graham.T.Wood.vcf"
begin:vcard
n:;Graham
x-mozilla-html:FALSE
adr:;;;;;;
version:2.1
email;internet:Graham.T.Wood@oracle.com
fn:Graham Wood
end:vcard
--------------294907030064CE3CF63297FD--
------------------------------
Date: 21 Aug 2001 13:35:41 GMT
From: Ilmari Karonen <iltzu@sci.invalid>
Subject: Re: This is not a question ... call me slow if you like...
Message-Id: <998400115.29424@itz.pp.sci.fi>
In article <3b813aab.2448013607@news.isholf.is>, Helgi Briem wrote:
>On 20 Aug 2001 11:51:22 GMT, Przemyslaw Brojewski
><brojek@kis.p.lodz.pl> wrote:
>
>>I get:
>>Modification of a read-only value attempted at cosik line 2.
>>
>>perl 5.6.1.
>>
>>what gives?
>
>OK, you're slow.
No he's not. And this was all my mistake, as was the bug.
1. This is being crossposted. Przemyslaw is from alt.ascii-art.
2. He was referring to a JAPH I'd posted.
3. The subject of this thread came from someone else entirely.
Okay, so he should've quoted my post. Okay, so Helgi should've checked
the newsgroups list and the beginning of the thread. And I should've
been more careful in testing my code before posting it. In the end,
this whole subthread is the result of a series of unfortunate mistakes.
I'd successful crossposted between alt.ascii-art and comp.lang.perl.misc
before, so I didn't see any risk in that. But I should've realized that
the cultures are different enough that there might be misunderstandings.
(Note for a.a-a readers: comp.lang.perl.misc is a high-volume group.
And yes, we do get people actually asking about bugs in code they're not
willing to show, with totally misleading subject lines. Some people get
pretty annoyed with it after a while. Abestos underwear recommended.)
[Followups set to comp.lang.perl.misc ONLY. Keep this out of a.a-a.]
--
Ilmari Karonen -- http://www.sci.fi/~iltzu/
"Get real! This is a discussion group, not a helpdesk. You post something,
we discuss its implications. If the discussion happens to answer a question
you've asked, that's incidental." -- nobull in comp.lang.perl.misc
------------------------------
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.
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 1577
***************************************
