[27189] in Perl-Users-Digest
Perl-Users Digest, Issue: 9008 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Mar 1 18:06:14 2006
Date: Wed, 1 Mar 2006 15:05:11 -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 Wed, 1 Mar 2006 Volume: 10 Number: 9008
Today's topics:
Re: A Problem With GD <samwyse@gmail.com>
Re: A Problem With GD <samwyse@gmail.com>
DynaLoader <bol@adv.magwien.gv.at>
Re: Keith Keller - Coward currys favour <dha@panix.com>
Re: Ordered hashes (Anno Siegel)
Re: Ordered hashes xhoster@gmail.com
Re: Ordered hashes <january.weiner@gmail.com>
Re: Ordered hashes <january.weiner@gmail.com>
Re: Remote.pm (File::Remote) problem <1usa@llenroc.ude.invalid>
Re: simple pointer operations (newbe) <rvtol+news@isolution.nl>
Re: simple pointer operations (newbe) <uri@stemsystems.com>
Re: simple pointer operations (newbe) <rvtol+news@isolution.nl>
Re: simple pointer operations (newbe) <uri@stemsystems.com>
Re: simple pointer operations (newbe) (Anno Siegel)
Re: simple pointer operations (newbe) <abigail@abigail.nl>
Re: simple pointer operations (newbe) <uri@stemsystems.com>
simple regexp problem <sm244@kent.ac.uk>
Re: simple regexp problem <1usa@llenroc.ude.invalid>
Re: Weighing the evidence, Perl is a GUESSING game !! <dha@panix.com>
Re: Weighing the evidence, Perl is a GUESSING game !! <uri@stemsystems.com>
Re: Weighing the evidence, Perl is a GUESSING game !! <dha@panix.com>
Re: Weighing the evidence, Perl is a GUESSING game !! <rwxr-xr-x@gmx.de>
Re: Weighing the evidence, Perl is a GUESSING game !! <matthew.garrish@sympatico.ca>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 01 Mar 2006 11:25:51 GMT
From: Samwyse <samwyse@gmail.com>
Subject: Re: A Problem With GD
Message-Id: <3xfNf.42624$H71.8782@newssvr13.news.prodigy.com>
Mark Manning wrote:
> I was looking for someone.
Then you need to try alt.personals
------------------------------
Date: Wed, 01 Mar 2006 11:26:53 GMT
From: Samwyse <samwyse@gmail.com>
Subject: Re: A Problem With GD
Message-Id: <1yfNf.42625$H71.2308@newssvr13.news.prodigy.com>
Mark Manning wrote:
> Yeah, I know - but thanks.
Thanks for what? I'm confused. What are you talking about?
------------------------------
Date: Wed, 1 Mar 2006 16:13:34 +0100
From: "Ferry Bolhar" <bol@adv.magwien.gv.at>
Subject: DynaLoader
Message-Id: <1141226018.699654@proxy.dienste.wien.at>
Hi,
while playing with XSLoader, I found these commands in XSLoader.pm:
package DynaLoader;
boot_DynaLoader('DynaLoader') if defined(&boot_DynaLoader) &&
!defined(&dl_error);
I understand that DynaLoader::boot_DynaLoader is Perl's initial routine to
enable
dynamic loading by making known (using newXS() calls) some routines starting
with
"dl_" (dl_load_file, dl_find_symbol, dl_install_xsub, dl_error) in the
"DynaLoader"
namespace which are all required for dynamic loading support and are invoked
later
by DynaLoaders "bootstrap" and XSLoaders "load" routines, when a module's
.so
file should be loaded.
So the command above calls this initial routine if it exists (Perl was built
with support
for dynamlic loading) and this initialization was not yet done (dl_error(),
one of the
known routines, does not yet exist as Perl function).
So far, so good.
What I can't unterstand is the purpose of the 'DynaLoader' argument in the
call to
"boot_DynaLoader". It works without this argument as well and in the
generated
boot_DynaLoader() function (by xsubpp, I suppose), there is no use of this
argument in any way.
So, just for couriosity, can someone explain the meaning of this argument?
MTIA & kind greetings from Vienna,
Ferry
--
Ing. Ferry Bolhar
Municipality of Vienna, Department 14
A-1010 Vienna / AUSTRIA
E-mail: bol@adv.magwien.gv.at
------------------------------
Date: Wed, 1 Mar 2006 17:27:23 +0000 (UTC)
From: "David H. Adler" <dha@panix.com>
Subject: Re: Keith Keller - Coward currys favour
Message-Id: <slrne0bmbr.qdk.dha@panix2.panix.com>
On 2006-03-01, rrrrrr rrrrrrrr <rr@rrrrrr.org> wrote:
> Josef Moellers <josef.moellers@fujitsu-siemens.com> trolled:
>
>> For one, Keith Keller uses a real name.
>
> It may be a real name. But it's not his name.
Well, that still puts him one up on you...
--
David H. Adler - <dha@panix.com> - http://www.panix.com/~dha/
Freedom ain't nothing but a word, ain't nothing but a word. Let me
see your ID. - Gil Scott-Heron, "Johannesburg"
------------------------------
Date: 1 Mar 2006 11:06:15 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: Ordered hashes
Message-Id: <du3v77$br$1@mamenchi.zrz.TU-Berlin.DE>
January Weiner <january.weiner@gmail.com> wrote in comp.lang.perl.misc:
> Hi,
>
> I run into this basic problem now and then.
>
> Hashes allow you to access an element by a key. However, hashes are not
> ordered. Take the following example: I have a hash containing a menu
> structure:
>
> my %menu = ( -file => [ "new", "open", "save" ],
> -analize => [ "count", "add", "subtract" ],
> -help => [ "yelp", "cry", "bang your head on the wall" ],
> ) ;
>
> Now I have some arbitrary function that should display this menu. However,
> the order should be preserved,
There are modules that give you hashes that *do* preserve order.
Tie::IxHash is one.
> and there is no way we could order it
> automatically (e.g. alphabetically). I see two solutions:
Why not? A typical menu doesn't have a million entries. It is usually
no problem to sort the entries alphabetically by their hash keys each
time they are displayed.
> 1) create a menu index:
>
> my @menu_idx = ( "-file", "-analize", "-help" ) ;
>
> for(@menu_idx) {
> do_something($menu{$_}) ;
> }
That is probably what order-preserving hashes do under the hood.
> 2) pretend %menu is an array:
Pretend? You have changed the representation, the menu now *is* an
array.
> my @menu = ( "-file", [ "new", "open", "save" ],
> "-analize", [ "count", "add", "subtract" ],
> "-help", [ "yelp", "cry", "bang your head on the wall" ],
> ) ;
>
> my %menu_hash = @menu ;
>
> for($i = 0 ; $i < scalar(@menu) ; $i += 2) {
> do_something($menu_hash{$menu[$i]}) ;
> }
>
> Neither seems to be satisfactory. Are there better ways of dealing with
> this problem?
I'd probably use another variant. Represent the menu as a list of
pairs:
my @menu = (
[ -file => [ qw( new open save)]],
[ -analyze => [ qw( count add subtract)]],
[ -help => [ qw( yelp cry), 'bang your head on the wall']],
);
Then you can loop over @menu in the given order (like an array) and
access the name and the choices individually, like with a hash.
for ( @menu ) {
print "$_->[ 0]: ", join( ', ', @{ $_->[ 1] }), "\n";
}
Anno
--
If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers.
------------------------------
Date: 01 Mar 2006 15:46:22 GMT
From: xhoster@gmail.com
Subject: Re: Ordered hashes
Message-Id: <20060301105010.074$Sg@newsreader.com>
January Weiner <january.weiner@gmail.com> wrote:
> Now I have some arbitrary function that should display this menu.
> However, the order should be preserved, and there is no way we could
> order it automatically (e.g. alphabetically). I see two solutions:
>
> 1) create a menu index:
>
> my @menu_idx = ( "-file", "-analize", "-help" ) ;
>
> for(@menu_idx) {
> do_something($menu{$_}) ;
> }
# how about a hash slice?
do_somehitng($_) foreach @menu{@menu_idx};
>
> 2) pretend %menu is an array:
>
> my @menu = ( "-file", [ "new", "open", "save" ],
> "-analize", [ "count", "add", "subtract" ],
> "-help", [ "yelp", "cry", "bang your head on the wall" ],
> ) ;
>
> my %menu_hash = @menu ;
>
> for($i = 0 ; $i < scalar(@menu) ; $i += 2) {
> do_something($menu_hash{$menu[$i]}) ;
> }
>
> Neither seems to be satisfactory. Are there better ways of dealing with
> this problem?
How to deal with the problem depends on what specifically you find
unsatisfactory about the solutions you already have.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
------------------------------
Date: Wed, 1 Mar 2006 18:04:23 +0100 (CET)
From: January Weiner <january.weiner@gmail.com>
Subject: Re: Ordered hashes
Message-Id: <du4k6n$fik$1@sagnix.uni-muenster.de>
Anno Siegel <anno4000@lublin.zrz.tu-berlin.de> wrote:
> There are modules that give you hashes that *do* preserve order.
> Tie::IxHash is one.
Right, thanks -- that is the solution I sought.
> Why not? A typical menu doesn't have a million entries. It is usually
> no problem to sort the entries alphabetically by their hash keys each
> time they are displayed.
Either you have Menus not sorted logically, or you have to remember that
"File" is "aFile" and "Help" is "zHelp". Anyway, menus were just an
example I came up with.
> Pretend? You have changed the representation, the menu now *is* an
> array.
Yes, formally speaking it is, but practically speaking I do not use it as
one, correct? Anyway, it was a metaphor.
> I'd probably use another variant. Represent the menu as a list of
> pairs:
> my @menu = (
> [ -file => [ qw( new open save)]],
> [ -analyze => [ qw( count add subtract)]],
> [ -help => [ qw( yelp cry), 'bang your head on the wall']],
> );
> Then you can loop over @menu in the given order (like an array) and
> access the name and the choices individually, like with a hash.
I think I'm lost. How can I access the elements of @menu above
individually like in a hash? I have to access the elements of @menu by
their index, and cannot do so by the key (or you mean the elements of the
anonymous arrays within?).
Cheers, and thanks!
j.
--
------------------------------
Date: Wed, 1 Mar 2006 18:04:43 +0100 (CET)
From: January Weiner <january.weiner@gmail.com>
Subject: Re: Ordered hashes
Message-Id: <du4k7b$fik$2@sagnix.uni-muenster.de>
Ch Lamprecht <christoph.lamprecht.no.spam@web.de> wrote:
> Hi,
> perldoc -q order hash
Thanks!!
j.
--
------------------------------
Date: Wed, 01 Mar 2006 16:52:11 GMT
From: "A. Sinan Unur" <1usa@llenroc.ude.invalid>
Subject: Re: Remote.pm (File::Remote) problem
Message-Id: <Xns977978D7BED56asu1cornelledu@127.0.0.1>
Dayton Jones <tkoedge@comcast.net> wrote in
news:b7WdnSuPq7BLgZjZnZ2dnUVZ_sadnZ2d@comcast.com:
Dayton, *please* do not top-post.
> A. Sinan Unur wrote:
>> Dayton Jones <tkoedge@comcast.net> wrote in
>> news:CfOdnXLeZoy5hJjZRVn-uA@comcast.com:
>>
>>
>>>A. Sinan Unur wrote:
>>>
>>>>Dayton Jones <tkoedge@comcast.net> wrote in
>>>>news:tZKdnQtkzPuPkZjZnZ2dnUVZ_sGdnZ2d@comcast.com:
>>>>
>>>>
>>>>> I've got a very simple script (see below) that uses the
>>>>> File::Remote module. I've set up the script to use ssh/scp
>>>>> and there is no problem for the user to ssh to the hosts -
>>>>> but the script fails with a "permission denied" error on the
>>>>>> copy command.
>>>>>
>>>>>-- begin script
>>>>>
>>>>>#!/usr/bin/perl
>>>>
>>>>
>>>>use strict;
>>>>use warnings;
>>>>
>>>>missing.
>>>>
>>>>
>>>>>use File::Remote qw(:replace);
>>>>>
>>>>>setrsh('/usr/bin/ssh');
>>>>>serrcp('/usr/bin/scp');
>>
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> ...
>>
>>
>>>I added the strict/warnings but had the same result -- with no extra
>>>information.
>>
>>
>> Well, did you fix the typo above?
>>
>> I don't have File-Remote installed, by I doubt serrcp is correct.
>
> Yes, I noticed that when reading your original response -- changed it
> to "setrcp="
Well, apologoies, I misdiagnosed the problem. I looked at the source
code of File::Remote, and the problem simply is that /dev/null has a
different name on Windows, i.e. NUL.
The dirty fix would involve replacing File::Remote::_system.
You could also just go in and edit out the 1 > /dev/null out of the
backticked string. But then, you'd be modifiying a module, and it might
get overwritten when you upgrade to a new version etc.
#!/usr/bin/perl
use strict;
use warnings;
use File::Remote qw(:replace);
use File::Spec::Functions qw( canonpath );
setrsh(canonpath 'C:/opt/cygwin/bin/ssh.exe');
setrcp(canonpath 'C:/opt/cygwin/bin/scp.exe');
settmp(canonpath $ENV{TEMP});
{
no warnings 'redefine';
*File::Remote::_system = sub {
my($self, @cmd) = File::Remote::_self_or_default(@_);
# return "Broken pipe" if cmd invalid
# chomp(my $return = `@cmd 2>&1 1>/dev/null || echo 32`);
chomp(my $return = `@cmd 2>&1 1>NUL || echo 32`);
File::Remote::_debug("_system(@cmd) = $return");
if ($return) {
# if echo'ed an int (internal tests), use it,
# else use "Permission denied" (13)
$return =~ m/^(\d+)$/;
$! = $1 || 13;
return undef;
}
return 1;
};
}
copy('localfile', 'remotefile')
or die "\$\@ = $@\n\$! = $!\n";
__END__
Sinan
--
A. Sinan Unur <1usa@llenroc.ude.invalid>
(reverse each component and remove .invalid for email address)
comp.lang.perl.misc guidelines on the WWW:
http://mail.augustmail.com/~tadmc/clpmisc/clpmisc_guidelines.html
------------------------------
Date: Wed, 1 Mar 2006 18:07:48 +0100
From: "Dr.Ruud" <rvtol+news@isolution.nl>
Subject: Re: simple pointer operations (newbe)
Message-Id: <du4od8.1d8.1@news.isolution.nl>
Uri Guttman schreef:
> [addressing r0b1co]
> just make sure you know which of your schizo personalities is
> controlling you at the moment.
I like to think that r0b1co is one of the many clever jokes by Abigail.
Same for Pur1Gur1. I need to be wrong of course.
--
Affijn, Ruud
"Gewoon is een tijger."
------------------------------
Date: Wed, 01 Mar 2006 12:50:25 -0500
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: simple pointer operations (newbe)
Message-Id: <x7irqydpge.fsf@mail.sysarch.com>
>>>>> "R" == Ruud <rvtol+news@isolution.nl> writes:
R> Uri Guttman schreef:
>> [addressing r0b1co]
>> just make sure you know which of your schizo personalities is
>> controlling you at the moment.
R> I like to think that r0b1co is one of the many clever jokes by Abigail.
R> Same for Pur1Gur1. I need to be wrong of course.
knowing abigail (in person) i will say you are wrong. trolls like those
are always self *cough* taught and are immune to real logic. they learn
enough to bamboozle newbies but so quickly fall when confronted with
anyone who has a functioning neuron or two. what is interesting is how
robic claims to know c and reads some perl guts but is clueless about
how they relate. the fact that perl uses the a real c address as part of
the value (numeric or string) of references is total smart as it will
guarantee the uniqueness of the ref value since the ram address is also
unique. but don't try to explain it to robic as he know better.
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, 1 Mar 2006 19:19:20 +0100
From: "Dr.Ruud" <rvtol+news@isolution.nl>
Subject: Re: simple pointer operations (newbe)
Message-Id: <du4ssn.19k.1@news.isolution.nl>
Uri Guttman schreef:
> the fact that perl uses the a
> real c address as part of the value (numeric or string) of references
> is total smart as it will guarantee the uniqueness of the ref value
> since the ram address is also unique.
Well, unique until the allocated block is moved. Unless the address is
more like a handle. Or the block was allocated as fixed.
> but don't try to explain it to
> robic as he know better.
I haven't seen any of his (or her) postings for already a very long
time.
--
Affijn, Ruud
"Gewoon is een tijger."
------------------------------
Date: Wed, 01 Mar 2006 14:17:35 -0500
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: simple pointer operations (newbe)
Message-Id: <x7slq2c6uo.fsf@mail.sysarch.com>
>>>>> "R" == Ruud <rvtol+news@isolution.nl> writes:
R> Uri Guttman schreef:
>> the fact that perl uses the a
>> real c address as part of the value (numeric or string) of references
>> is total smart as it will guarantee the uniqueness of the ref value
>> since the ram address is also unique.
R> Well, unique until the allocated block is moved. Unless the address is
R> more like a handle. Or the block was allocated as fixed.
the sv (or whatever the internal thing the ref is) never get reallocated
as they are fixed sized. only the string/array/hash buffers get
reallocated as needed and they are pointed to by a member of the sv. so
the ref value will never change as long as the ref is valid (not garbage
collected).
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: 1 Mar 2006 19:38:34 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: simple pointer operations (newbe)
Message-Id: <du4t7q$igr$1@mamenchi.zrz.TU-Berlin.DE>
Uri Guttman <uri@stemsystems.com> wrote in comp.lang.perl.misc:
> >>>>> "R" == Ruud <rvtol+news@isolution.nl> writes:
>
> R> Uri Guttman schreef:
> >> the fact that perl uses the a
> >> real c address as part of the value (numeric or string) of references
> >> is total smart as it will guarantee the uniqueness of the ref value
> >> since the ram address is also unique.
>
> R> Well, unique until the allocated block is moved. Unless the address is
> R> more like a handle. Or the block was allocated as fixed.
>
> the sv (or whatever the internal thing the ref is) never get reallocated
> as they are fixed sized. only the string/array/hash buffers get
> reallocated as needed and they are pointed to by a member of the sv. so
> the ref value will never change as long as the ref is valid (not garbage
> collected).
There is one exception: On thread (ithread) creation, everything is
cloned and one of the branches wakes up with all refaddrs changed.
That's why some implementations of inside-out classes aren't thread-safe.
An object in a newly cloned thread will appear to have lost its data.
The problem is fixable, at a price.
As far as I'm concerned thread users get what they deserve and deserve
what they get :)
Anno
--
If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers.
------------------------------
Date: 01 Mar 2006 19:41:35 GMT
From: Abigail <abigail@abigail.nl>
Subject: Re: simple pointer operations (newbe)
Message-Id: <slrne0bu7f.h1.abigail@alexandra.abigail.nl>
Uri Guttman (uri@stemsystems.com) wrote on MMMMDLXV September MCMXCIII in
<URL:news:x7slq2c6uo.fsf@mail.sysarch.com>:
`` >>>>> "R" == Ruud <rvtol+news@isolution.nl> writes:
``
`` R> Uri Guttman schreef:
`` >> the fact that perl uses the a
`` >> real c address as part of the value (numeric or string) of references
`` >> is total smart as it will guarantee the uniqueness of the ref value
`` >> since the ram address is also unique.
``
`` R> Well, unique until the allocated block is moved. Unless the address is
`` R> more like a handle. Or the block was allocated as fixed.
``
`` the sv (or whatever the internal thing the ref is) never get reallocated
`` as they are fixed sized. only the string/array/hash buffers get
`` reallocated as needed and they are pointed to by a member of the sv. so
`` the ref value will never change as long as the ref is valid (not garbage
`` collected).
SV might get reallocated - or rather, copied, when you may not expect it,
for instance when using threads.
#!/opt/perl/5.8.8/bin/thr-perl-64 -l
use threads;
use strict;
use warnings;
my $ref = do {\my $var};
print $ref;
threads -> create (sub {print $ref}) -> join;
__END__
SCALAR(0x81a8390)
SCALAR(0x828649c)
Abigail
--
perl -wle 'eval {die [[qq [Just another Perl Hacker]]]};; print
${${${@}}[$#{@{${@}}}]}[$#{${@{${@}}}[$#{@{${@}}}]}]'
------------------------------
Date: Wed, 01 Mar 2006 14:48:24 -0500
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: simple pointer operations (newbe)
Message-Id: <x7lkvuc5fb.fsf@mail.sysarch.com>
>>>>> "AS" == Anno Siegel <anno4000@lublin.zrz.tu-berlin.de> writes:
AS> Uri Guttman <uri@stemsystems.com> wrote in comp.lang.perl.misc:
>> the sv (or whatever the internal thing the ref is) never get reallocated
>> as they are fixed sized. only the string/array/hash buffers get
>> reallocated as needed and they are pointed to by a member of the sv. so
>> the ref value will never change as long as the ref is valid (not garbage
>> collected).
AS> There is one exception: On thread (ithread) creation, everything is
AS> cloned and one of the branches wakes up with all refaddrs changed.
AS> That's why some implementations of inside-out classes aren't thread-safe.
AS> An object in a newly cloned thread will appear to have lost its data.
AS> The problem is fixable, at a price.
AS> As far as I'm concerned thread users get what they deserve and deserve
AS> what they get :)
as a strong advocate of event loops over threads i fully agree with that
sentiment. :)
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, 01 Mar 2006 19:33:42 +0000
From: "S.Marion" <sm244@kent.ac.uk>
Subject: simple regexp problem
Message-Id: <du4sum$bsb$1@oheron.kent.ac.uk>
Hello,
I'm new to perl and have the following problem.
I have patterns such as:
[Ljava/lang/StackTraceElement
that I want to turn into:
Ljava/lang/StackTraceElement[]
To do this I've got the following regexp:
$methodRet =~ s/(\[*)([^\[]*)/$2$1/;
But this doesn't work since it looks like looping endlessly...
Could anyone point out the mistake?
Cheers,
Marion Sebastien
------------------------------
Date: Wed, 01 Mar 2006 19:50:02 GMT
From: "A. Sinan Unur" <1usa@llenroc.ude.invalid>
Subject: Re: simple regexp problem
Message-Id: <Xns9779970045585asu1cornelledu@127.0.0.1>
"S.Marion" <sm244@kent.ac.uk> wrote in news:du4sum$bsb$1
@oheron.kent.ac.uk:
> I'm new to perl and have the following problem.
> I have patterns such as:
> [Ljava/lang/StackTraceElement
> that I want to turn into:
> Ljava/lang/StackTraceElement[]
>
> To do this I've got the following regexp:
> $methodRet =~ s/(\[*)([^\[]*)/$2$1/;
>
> But this doesn't work since it looks like looping endlessly...
> Could anyone point out the mistake?
In the example data you have provided, there is only one [ at the
beginning. So, you should anchor the regex at the beginning of the
string, look for a [ right there. I don't understand what you are trying
to do in the second capturing group: Match zero or times *will* succeed
when it matches zero times.
#!/usr/bin/perl
use warnings;
use strict;
my $s = '[Ljava/lang/StackTraceElement';
$s =~ s{\A \[ ( \w+ (?: / \w+ )* ) }
{$1\[\]}x;
print "$s\n";
__END__
--
A. Sinan Unur <1usa@llenroc.ude.invalid>
(reverse each component and remove .invalid for email address)
comp.lang.perl.misc guidelines on the WWW:
http://mail.augustmail.com/~tadmc/clpmisc/clpmisc_guidelines.html
------------------------------
Date: Wed, 1 Mar 2006 17:45:43 +0000 (UTC)
From: "David H. Adler" <dha@panix.com>
Subject: Re: Weighing the evidence, Perl is a GUESSING game !!
Message-Id: <slrne0bne7.qdk.dha@panix2.panix.com>
On 2006-03-01, Uri Guttman <uri@stemsystems.com> wrote:
>>>>>> "r" == robic0 <robic0> writes:
>
> r> I'm ready to go to the mat on this one ...
>
> i'd like to introduce you to moronzilla one day. the two of you would
> make a very happy and loonie couple and you could go off inventing your
> own languages.
Please do not do that unless we can seal them off in their own pocket
dimension. KTHX.
dha
--
David H. Adler - <dha@panix.com> - http://www.panix.com/~dha/
It was when a cow-orker proudly showed me his Java Ring that I finally
realised that Java was nothing more than a huge April Fool joke that had
got out of hand. - Andy Wardley
------------------------------
Date: Wed, 01 Mar 2006 13:21:24 -0500
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: Weighing the evidence, Perl is a GUESSING game !!
Message-Id: <x77j7edo0r.fsf@mail.sysarch.com>
>>>>> "DHA" == David H Adler <dha@panix.com> writes:
DHA> On 2006-03-01, Uri Guttman <uri@stemsystems.com> wrote:
>>>>>>> "r" == robic0 <robic0> writes:
>>
r> I'm ready to go to the mat on this one ...
>>
>> i'd like to introduce you to moronzilla one day. the two of you would
>> make a very happy and loonie couple and you could go off inventing your
>> own languages.
DHA> Please do not do that unless we can seal them off in their own pocket
DHA> dimension. KTHX.
i would expect their intro to create such a warped dimension and hence
writing their own lang.
it would be too funny to watch them 'communicate' all their perl
knowledge.
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, 1 Mar 2006 19:42:27 +0000 (UTC)
From: "David H. Adler" <dha@panix.com>
Subject: Re: Weighing the evidence, Perl is a GUESSING game !!
Message-Id: <slrne0bu94.4s.dha@panix2.panix.com>
On 2006-03-01, Uri Guttman <uri@stemsystems.com> wrote:
>>>>>> "DHA" == David H Adler <dha@panix.com> writes:
>
> DHA> On 2006-03-01, Uri Guttman <uri@stemsystems.com> wrote:
> >>>>>>> "r" == robic0 <robic0> writes:
> >>
> r> I'm ready to go to the mat on this one ...
> >>
> >> i'd like to introduce you to moronzilla one day. the two of you would
> >> make a very happy and loonie couple and you could go off inventing your
> >> own languages.
>
> DHA> Please do not do that unless we can seal them off in their own pocket
> DHA> dimension. KTHX.
>
> i would expect their intro to create such a warped dimension and hence
> writing their own lang.
I don't feel comfortable leaving such things to chance.
> it would be too funny to watch them 'communicate' all their perl
> knowledge.
Maybe for you. At this point, I've moved on to finding it tiresome. To
each their own. :-)
dha
--
David H. Adler - <dha@panix.com> - http://www.panix.com/~dha/
I don't want to get bitter/I don't want to turn cruel/I don't want to
get old before I have to/I don't want to get jaded/Petrified and
weighted/I don't want to get bitter like you. - Jill Sobule
------------------------------
Date: Wed, 1 Mar 2006 23:13:09 +0100
From: "Lukas Mai" <rwxr-xr-x@gmx.de>
Subject: Re: Weighing the evidence, Perl is a GUESSING game !!
Message-Id: <du569l$8s9$01$2@news.t-online.com>
robic0 schrob:
[..]
> I find it incredible to read some recent posts where
> actual C pointers are somehow analogous to a Perl
> construct. There is *nothing* available in Perl scripts
> except pseudo C. There is *no* C, ie: addresses or
> pointer arithmatic you can see, do, or say in Perl !!
perldoc -f pack
...
p A pointer to a null-terminated string.
P A pointer to a structure (fixed-length string).
...
> The core of Perl is compiled. That is the end of contact
> with Perl's core C code!! After that its an interfaced,
> pseudo language thats provided to Perl programmers.
"Pseudo" has nothing to do with compilation.
> You have zero (0) control of the internals of Perl after that,
> only to the extent of which is provided by such.
> When you write Perl scripts, your so far away from C and the
> operating system, you can't see!
perldoc perlxs
perldoc Inline::C
perldoc -f syscall
> After Perl is compiled there is not interaction with it, it
> exists as a binary. There is no construct in Perl to alter
> dynamic pointers in the C Perl core!
Yes, there is. You can implement peek and poke in pure Perl, at least on
Unix-like systems.
> Even if you wanted
> to increment an address from a script, and it passed you the
> (current) virtual memory location, the indirection would be
> a killer! The time involved would be prohibitive. Perhaps
> if there were pseudo C-like primitives in the native Perl
> language, it would be feasable. It would involve multiple
> indirection though. But what "++" construct from Perl?
> How would that crash the machine, let me count the ways.
> Boundries don't exists in the Perl population like it does
> in C/C++. To let a Perl script control addressing would be
> a nightmare!
>
> Thats why they don't allow that shit!
Bla, bla, bla.
$ perl -e '$# = "%n"; print 42'
Segmentation fault
> If there's anybody who reads this who thinks otherwise
> just post a follow. Otherwise *Perl* does not and will
> never (because of the history off psudo languages) allow
> access to and alteration of C core's.
"Pseudo" has nothing to do with C. C is not the reality. You can
implement C in Perl.
> I'm writing this because of the recent avalance of bullshit
> on this subject by Abgail and Sunan and others on a single subject.
I bet you couldn't even understand a single Abigail JAPH/obfu.
> I'm ready to go to the mat on this one ...
>
> -robic
You suck at spelling names.
HTH, Lukas
------------------------------
Date: Wed, 1 Mar 2006 17:47:33 -0500
From: "Matt Garrish" <matthew.garrish@sympatico.ca>
Subject: Re: Weighing the evidence, Perl is a GUESSING game !!
Message-Id: <4wpNf.4374$972.180487@news20.bellglobal.com>
"Uri Guttman" <uri@stemsystems.com> wrote in message
news:x7veuyvjgz.fsf@mail.sysarch.com...
>>>>>> "r" == robic0 <robic0> writes:
>
> r> I'm ready to go to the mat on this one ...
>
> i'd like to introduce you to moronzilla one day. the two of you would
> make a very happy and loonie couple and you could go off inventing your
> own languages.
>
At least Xah has a personal crusade against the unix f*ckheads who use Perl,
and is almost convincing in his blather (though in a warped and demented
kind of way). robic0's attempts to mimic him just fall flat in so many
ways...
Matt
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V10 Issue 9008
***************************************
