[33164] in Perl-Users-Digest
Perl-Users Digest, Issue: 4443 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Jun 1 09:09:18 2015
Date: Mon, 1 Jun 2015 06:09:04 -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 Mon, 1 Jun 2015 Volume: 11 Number: 4443
Today's topics:
Re: Perl callback not firing from XSUB--advice? <rweikusat@mobileactivedefense.com>
Re: Perl callback not firing from XSUB--advice? <kw@codebykevin.com>
Re: Perl callback not firing from XSUB--advice? <rweikusat@mobileactivedefense.com>
Re: Perl callback not firing from XSUB--advice? <rweikusat@mobileactivedefense.com>
Re: Perl callback not firing from XSUB--advice? <kw@codebykevin.com>
Re: Perl callback not firing from XSUB--advice? <rweikusat@mobileactivedefense.com>
Puzzling Substitution Failure <see.my.sig@for.my.address>
Re: Puzzling Substitution Failure <derykus@gmail.com>
Re: Puzzling Substitution Failure <see.my.sig@for.my.address>
Re: Puzzling Substitution Failure <see.my.sig@for.my.address>
Re: Puzzling Substitution Failure <rweikusat@mobileactivedefense.com>
Strong AI Perl NewConcept Module and June 4th Tiananmen mentificium@gmail.com
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sun, 31 May 2015 16:10:49 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Perl callback not firing from XSUB--advice?
Message-Id: <878uc44wau.fsf@doppelsaurus.mobileactivedefense.com>
Kevin Walzer <kw@codebykevin.com> writes:
> I am building a Perl extension via the xsub API that includes Perl
> callbacks via the perlcall API, and the callbacks are not firing. I
> would appreciate some help.
You don't and there is no XS code below, just a hand-recoding of
something some unspecified version of xsubpp happened to generate when
some Chinese guy ran it at some time in the past. That's not a very good
idea as this means the mock XS routine below is about twice as large as
it could be without adding anything of practical value to it except the
opportunity of getting it wrong.
[...]
>
> /* Assign Perl parameters to char values. */
> SV* perleventclass = ST(0);
> STRLEN len;
> _eventclass=SvPV(perleventclass, len);
> SV* perleventid = ST(1);
> _eventid=SvPV(perleventid, len);
> SV* perlcmd = ST(2);
> _perlcmd=SvPV(perlcmd, len);
[code not using len]
You can use SvPV_nolen when you don't want the length.
------------------------------
Date: Sun, 31 May 2015 13:36:47 -0400
From: Kevin Walzer <kw@codebykevin.com>
Subject: Re: Perl callback not firing from XSUB--advice?
Message-Id: <mkfgp7$pqg$1@dont-email.me>
On 5/31/15 11:10 AM, Rainer Weikusat wrote:
> You don't and there is no XS code below, just a hand-recoding of
> something some unspecified version of xsubpp happened to generate when
> some Chinese guy ran it at some time in the past. That's not a very good
> idea as this means the mock XS routine below is about twice as large as
> it could be without adding anything of practical value to it except the
> opportunity of getting it wrong.
It does appear that I am writing C rather than XS and perhaps it is
better to simply dispense with the XS machinery altogether. My XS code
passes through xsubpp to a C file unmodified. My model for this is not a
Chinese developer, but a Japanese developer, Daisuke Murase, who has
authored about three dozen CPAN modules (see
http://search.cpan.org/~typester/), and who often does this kind of
hand-tuning when interacting with Mac-specific frameworks.
I am persuaded that this approach is better for my needs because the XS
shim seems only to provide a one-to-one mapping between Perl subroutines
and equivalent C functions. It offers no way to call supporting
additional functions at the C level without exposing those functions as
Perl subroutines.
This is what my code does. It exposes one C function as a Perl
subroutine, but event handlers at the C level which are intended to be
passed back to Perl via the perlcall API never fire. This is unexpected.
It's not a question of the Perl interpreter getting the correct
parameters or passing back output; the event handler never fires at all.
The technical piece of my question could be better phrased as such: Is
there any kind of scoping rule that prevents a compiled XSUB from
calling other C functions, defined in the same module, that are not
exposed as XSUBs? Perhaps my event handler never fires because the XSUB
is simply unaware of its existence?
Your sarcastic response offers no help on this point. It would be better
to either offer a useful answer, say "Sorry, I can't help," or remain
silent. Instead, you have opted to be both unprofessional and unhelpful.
I will look elsewhere for assistance.
--Kevin
--
Kevin Walzer
Code by Kevin/Mobile Code by Kevin
http://www.codebykevin.com
http://www.wtmobilesoftware.com
------------------------------
Date: Sun, 31 May 2015 20:26:05 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Perl callback not firing from XSUB--advice?
Message-Id: <87eglweegi.fsf@doppelsaurus.mobileactivedefense.com>
Kevin Walzer <kw@codebykevin.com> writes:
> On 5/31/15 11:10 AM, Rainer Weikusat wrote:
>> You don't and there is no XS code below, just a hand-recoding of
>> something some unspecified version of xsubpp happened to generate when
>> some Chinese guy ran it at some time in the past. That's not a very good
>> idea as this means the mock XS routine below is about twice as large as
>> it could be without adding anything of practical value to it except the
>> opportunity of getting it wrong.
>
> It does appear that I am writing C rather than XS and perhaps it is
> better to simply dispense with the XS machinery altogether. My XS code
> passes through xsubpp to a C file unmodified.
[...]
You didn't write any XS code and running this through the xsub
preprocessor is totally useless. You've chosen to imitate parts of the
output of an unknown version of xsubpp by hand. That's unwise because
you have to debug the additional code and because there are potential
compatibility problems with different Perl version than the one the
backend concepts were ripped from.
> I am persuaded that this approach is better for my needs because the
> XS shim seems only to provide a one-to-one mapping between Perl
> subroutines and equivalent C functions. It offers no way to call
> supporting additional functions at the C level without exposing those
> functions as Perl subroutines.
I don't quite understand how you came up with this absurd idea: It's
possible to put arbitrary C code into XS routines which can - of course
- call other functions written in C. In case of a more complex
extension, the 'common pattern' would be that it includes one or more .c
and .h files for the implementation and a (relatively) small .xs file
providing the interface to perl.
[...]
> Your sarcastic response offers no help on this point. It would be
> better to either offer a useful answer, say "Sorry, I can't help," or
> remain silent. Instead, you have opted to be both unprofessional and
> unhelpful.
Since you don't pay me, if have no reason to behave "professionally"
towards you, whatever this is supposed to mean. And I provided you with
two pieces of 'helpful advices', namely, that I don't think fighting
one's tools is a good idea (see above) and that you could do away with a
dummy variable in your code by using a different 'API call' (a macro,
actually). I don't have a Mac and have no practical knowledge about the
Mac OS X programming interface and - incidentally - this is a Perl
group.
------------------------------
Date: Sun, 31 May 2015 21:02:50 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Perl callback not firing from XSUB--advice?
Message-Id: <87a8wkecr9.fsf@doppelsaurus.mobileactivedefense.com>
Kevin Walzer <kw@codebykevin.com> writes:
[...]
> /*Install Apple Event handlers and map to Perl commands.*/
> XS(installeventhandler)
> {
>
> dXSARGS;
>
> CFMutableArrayRef copyTypes, pasteTypes;
> CFStringRef dataType;
>
> OSErr err;
> OSType eventClass;
> OSType eventID;
>
> if (items < 3) {
> Perl_croak(aTHX_ "Usage: Mac::AEM::installeventhandler(eventClass,
> eventID, Perl command)");
> }
>
> /* Assign Perl parameters to char values. */
> SV* perleventclass = ST(0);
> STRLEN len;
> _eventclass=SvPV(perleventclass, len);
> SV* perleventid = ST(1);
> _eventid=SvPV(perleventid, len);
> SV* perlcmd = ST(2);
> _perlcmd=SvPV(perlcmd, len);
>
> /* Convert chars to CFStringRefs. */
> stringeventClass = CFStringCreateWithCString(kCFAllocatorDefault,
> _eventclass, kCFStringEncodingUTF8);
> stringeventID = CFStringCreateWithCString(kCFAllocatorDefault,
> _eventid, kCFStringEncodingUTF8);
> eventFunction = CFStringCreateWithCString(kCFAllocatorDefault,
> _perlcmd, kCFStringEncodingUTF8);
>
> /* Convert CFStringRefs to OSTypes, which are integers. */
> eventClass = UTGetOSTypeFromString(stringeventClass);
> eventID = UTGetOSTypeFromString(stringeventID);
>
> /* Create CFDictionary to map event ID's to commands. */
> aeDict = CFDictionaryCreateMutable(NULL, 0,
> &kCFTypeDictionaryKeyCallBacks, &kCFTypeDictionaryValueCallBacks);
> CFDictionarySetValue(aeDict, stringeventID, eventFunction);
>
> /* Finally, install the Apple Event handlers. */
> err = AEInstallEventHandler(eventClass, eventID,
> NewAEEventHandlerUPP(AEScriptsAEHandler), 0, false);
> if (err != noErr) {
> fprintf(stdout, "Unable to install custom Apple Events handlers.\n");
> } else {
> fprintf(stdout, "Installing class: %s, id: %s, command: %s\n",
> _eventclass, _eventid, _perlcmd);
> }
> XSRETURN(1);
> }
>
> XS(boot_Mac__AEM) {
>
> newXS("Mac::AEM::installeventhandler", installeventhandler, __FILE__);
>
> }
For illustation: XS code equivalent to this could look as follows (tested with xsubpp only):
----
#include "EXTERN.h"
#include "perl.h"
#include "XSUB.h"
MODULE = bla
void
installevenhandler(class, id, cmd)
char * class
char * id
char * cmd
PREINIT:
CFMutableArrayRef copyTypes, pasteTypes;
CFStringRef dataType;
OSErr err;
OSType eventClass;
OSType eventID;
CODE:
/* Convert chars to CFStringRefs. */
stringeventClass = CFStringCreateWithCString(kCFAllocatorDefault, class, kCFStringEncodingUTF8);
stringeventID = CFStringCreateWithCString(kCFAllocatorDefault, id, kCFStringEncodingUTF8);
eventFunction = CFStringCreateWithCString(kCFAllocatorDefault, cmd, kCFStringEncodingUTF8);
/* Convert CFStringRefs to OSTypes, which are integers. */
eventClass = UTGetOSTypeFromString(stringeventClass);
eventID = UTGetOSTypeFromString(stringeventID);
/* Create CFDictionary to map event ID's to commands. */
aeDict = CFDictionaryCreateMutable(NULL, 0, &kCFTypeDictionaryKeyCallBacks, &kCFTypeDictionaryValueCallBacks);
CFDictionarySetValue(aeDict, stringeventID, eventFunction);
/* Finally, install the Apple Event handlers. */
err = AEInstallEventHandler(eventClass, eventID,
NewAEEventHandlerUPP(AEScriptsAEHandler), 0, false);
if (err != noErr) {
fprintf(stdout, "Unable to install custom Apple Events handlers.\n");
} else {
fprintf(stdout, "Installing class: %s, id: %s, command: %s\n", class, id, cmd);
----
This is not only shorter but also more descriptive because it contains
explicit information about the return value of return value of the
function ('none') and the number and types of its arguments (three
strings).
------------------------------
Date: Sun, 31 May 2015 20:32:20 -0400
From: Kevin Walzer <kw@codebykevin.com>
Subject: Re: Perl callback not firing from XSUB--advice?
Message-Id: <mkg94c$o0g$1@dont-email.me>
On 5/31/15 4:02 PM, Rainer Weikusat wrote:
> This is not only shorter but also more descriptive because it contains
> explicit information about the return value of return value of the
> function ('none') and the number and types of its arguments (three
> strings).
I do appreciate the example you have provided. To be accurate, the
function you rewrote actually does return a value, an OSErr
(Mac-specific datatype). Casting it to void would not work.
The issues I was running into turned out to be unrelated to the xsub
code--specifically, a recurring typo in a config file similar to a
typemap that notifies the system of the IPC events my app will support.
--Kevin
--
Kevin Walzer
Code by Kevin/Mobile Code by Kevin
http://www.codebykevin.com
http://www.wtmobilesoftware.com
------------------------------
Date: Mon, 01 Jun 2015 13:27:55 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Perl callback not firing from XSUB--advice?
Message-Id: <8761778vg4.fsf@doppelsaurus.mobileactivedefense.com>
Kevin Walzer <kw@codebykevin.com> writes:
> On 5/31/15 4:02 PM, Rainer Weikusat wrote:
>> This is not only shorter but also more descriptive because it contains
>> explicit information about the return value of return value of the
>> function ('none') and the number and types of its arguments (three
>> strings).
>
> I do appreciate the example you have provided. To be accurate, the
> function you rewrote actually does return a value, an OSErr
> (Mac-specific datatype). Casting it to void would not work.
The original code contained an XSRETURN(1) but (AFAICT) no code ever
pushing anything onto the stack. Hence, it caimed to return something
but didn't actually do so. Using void as return type doesn't involve any
'casting', it just ends up as XSRETURN_EMPTY, which, in the given
context, means 'no values returned'. Code doing a success/ failure
return could look like this:
if (err != noErr) XSRETURN_EMPTY;
XSRETURN_YES;
XSRETURN_EMPTY will work as intended regardless of the routine being
invoked in scalar or list context while XSRETURN_UNDEF would end up
returning a list with an undef value on it for the latter case.
Another option would be 'croak', the XSUB-equivalent of a Perl 'die'.
------------------------------
Date: Sun, 31 May 2015 17:27:12 -0700
From: Robbie Hatley <see.my.sig@for.my.address>
Subject: Puzzling Substitution Failure
Message-Id: <G8SdnTtEtcdTO_bInZ2dnUVZ572dnZ2d@giganews.com>
I'm working on a script that renames files using regular expressions.
Part of the code looks like this:
my $regexp = $Settings{RegEx};
my $replac = $Settings{Replacement};
say "regular expression = $regexp";
say "replacement string = $replac";
my $NewName = $OldName;
$NewName =~ s/$regexp/$replac/g;
say "\$1 = $1";
That's not working. The s/// operator is replacing the match
with a LITERAL version of what's in the replacement slot.
Here's an example of trying to run the script:
Aragorn@Ketch
/cygdrive/c/E/Scavenged-From-Caches/FF
%rnf '^(\S+)\.avi$' '$1.xyz' '*.avi'
Directory # 1:
/cygdrive/c/E/Scavenged-From-Caches/FF
RegExp = ^(\S+)\.avi$
RepLac = $1.xyz
$1 = 00027BB2B9A747122EA5BD3AE1BFDA938848DA9F
OldName = 00027BB2B9A747122EA5BD3AE1BFDA938848DA9F.avi
NewName = $1.xyz
Rename? (Type y for yes, n for no, q to quit, or a to rename all).
As you can see, the () group-and-capture functions correctly, and
$1 does indeed contain what was in the group. BUT, s/// replaces
the match with a LITERAL "$1.xyz" instead of
"00027BB2B9A747122EA5BD3AE1BFDA938848DA9F.xyz"
as it should.
What would cause this kind of failure of s/// to interpret $1
correctly in the replacement string?
--
Exceedingly puzzled,
Robbie Hatley
Midway City, CA, USA
perl -le 'print "\154o\156e\167o\154f\100w\145ll\56c\157m"'
http://www.well.com/user/lonewolf/
https://www.facebook.com/robbie.hatley
------------------------------
Date: Sun, 31 May 2015 21:34:55 -0700 (PDT)
From: "C.DeRykus" <derykus@gmail.com>
Subject: Re: Puzzling Substitution Failure
Message-Id: <50df90e2-7552-4fa2-8642-9b24ca88d43e@googlegroups.com>
On Sunday, May 31, 2015 at 5:26:57 PM UTC-7, Robbie Hatley wrote:
> I'm working on a script that renames files using regular expressions.
> Part of the code looks like this:
>
> my $regexp = $Settings{RegEx};
> my $replac = $Settings{Replacement};
> say "regular expression = $regexp";
> say "replacement string = $replac";
> my $NewName = $OldName;
> $NewName =~ s/$regexp/$replac/g;
> say "\$1 = $1";
>
> That's not working. The s/// operator is replacing the match
> with a LITERAL version of what's in the replacement slot.
>
> Here's an example of trying to run the script:
>
>
> Aragorn@Ketch
> /cygdrive/c/E/Scavenged-From-Caches/FF
> %rnf '^(\S+)\.avi$' '$1.xyz' '*.avi'
>
> Directory # 1:
> /cygdrive/c/E/Scavenged-From-Caches/FF
> RegExp = ^(\S+)\.avi$
> RepLac = $1.xyz
> $1 = 00027BB2B9A747122EA5BD3AE1BFDA938848DA9F
>
> OldName = 00027BB2B9A747122EA5BD3AE1BFDA938848DA9F.avi
> NewName = $1.xyz
> Rename? (Type y for yes, n for no, q to quit, or a to rename all).
>
>
> As you can see, the () group-and-capture functions correctly, and
> $1 does indeed contain what was in the group. BUT, s/// replaces
> the match with a LITERAL "$1.xyz" instead of
> "00027BB2B9A747122EA5BD3AE1BFDA938848DA9F.xyz"
> as it should.
>
> What would cause this kind of failure of s/// to interpret $1
> correctly in the replacement string?
>
>
The replacement is parsed and evaluated as a normal double quoted string.
Some peril attached unless you're sure about sources but you can use the /ee switch to cause a double evaluation, eg,
$ perl -E '$str = q{file.avi};
> $s = q{^(\S+)\.avi$};
> $e = q{.xyz};
> $r = q{$1 . $e};
> $str =~ s/$s/$r/ee;
> say $str'
file.xyz
see: perldoc perlop (substitution operator)
--
Charles DeRykus
the replacement is done.
------------------------------
Date: Mon, 01 Jun 2015 00:12:02 -0700
From: Robbie Hatley <see.my.sig@for.my.address>
Subject: Re: Puzzling Substitution Failure
Message-Id: <3oqdnUDHB5ktmPHInZ2dnUVZ57ydnZ2d@giganews.com>
On 5/31/2015 9:34 PM, C.DeRykus wrote:
> On Sunday, May 31, 2015 at 5:26:57 PM UTC-7, Robbie Hatley wrote:
> > I'm working on a script that renames files using regular expressions.
> > Part of the code looks like this:
> >
> > ...
> > $NewName =~ s/$regexp/$replac/g;
> > ...
> >
> > That's not working. The s/// operator is replacing the match
> > with a LITERAL version of what's in the replacement slot.
> > ...
>
> The replacement is parsed and evaluated as a normal double quoted string.
> Some peril attached unless you're sure about sources but you can use
> the /ee switch to cause a double evaluation, eg,
>
> $ perl -E '$str = q{file.avi};
>> $s = q{^(\S+)\.avi$};
>> $e = q{.xyz};
>> $r = q{$1 . $e};
>> $str =~ s/$s/$r/ee;
>> say $str'
> file.xyz
>
> see: perldoc perlop (substitution operator)
So, you're saying, I'm getting one too few levels of interpolation?
I'm curious, why does the regex interpolate figuratively but the
replacement is taken too literally?
Ok, I tried both the /e and /ee modifiers. The /e modifier
had no effect. The /ee modifier changed the replacement from
a literal version (wrong) to an empty string (wronger).
But this gives me an idea how to proceed. Basically, I need to
interpolate the variables into a string (as FIRST layer of
interpolation), then tell Perl to evaluate that string as being
Perl code (as SECOND layer of interpolation).
Hmmm. I could use eval() to do that.
Instead of my original code (which doesn't work), lets try THIS:
sub rename_files {
...dozens more lines of code here...
FILE: foreach (@{$curdirfiles})
{
++$filecount;
my $OldName = $_->{Name};
if ($OldName =~ m<$Settings{RegEx}>) {++$matchcount;}
else {++$nomatchcount; next FILE;}
my $r = $Settings{RegEx};
my $e = $Settings{Replacement};
my $NewName;
eval("\$NewName = \$OldName =~ s/$r/$e/rg");
# (I'm backslashing $NewNamd and $OldName because they need
# to be taken literally on FIRST pass, then interpreted as
# Perl code on SECOND pass.)
# Announce old and new file names:
say '';
say "\$r = $r";
say "\$e = $e";
say "OldName = $OldName";
say "NewName = $NewName";
...hundreds more lines of code here...
}
}
Let's see how that works:
Aragorn@Ketch
/cygdrive/c/E/Scavenged-From-Caches/FF
%rnf '^(\S+)\.avi$' '$1.xyz' '*.avi'
Directory # 1:
/cygdrive/c/E/Scavenged-From-Caches/FF
$r = ^(\S+)\.avi$
$e = $1.xyz
OldName = 00027BB2B9A747122EA5BD3AE1BFDA938848DA9F.avi
NewName = 00027BB2B9A747122EA5BD3AE1BFDA938848DA9F.xyz
Rename? (Type y for yes, n for no, q to quit, or a to rename all).
Yeah, it works!!! :-)
Thanks for the tip on "The replacement is parsed and evaluated
as a normal double quoted string." That hit the nail on the head.
The rest was just a matter of separating interpolation into 2 passes.
(I'm still not sure why the replacement was handled so differently
from the RegExp. I'll have to read up on s/// and see why
that's so.)
--
Cheers,
Robbie Hatley
Midway City, CA, USA
perl -le 'print "\154o\156e\167o\154f\100w\145ll\56c\157m"'
http://www.well.com/user/lonewolf/
https://www.facebook.com/robbie.hatley
------------------------------
Date: Mon, 01 Jun 2015 02:40:39 -0700
From: Robbie Hatley <see.my.sig@for.my.address>
Subject: Re: Puzzling Substitution Failure
Message-Id: <WsKdnTaYOKYYtfHInZ2dnUVZ57ydnZ2d@giganews.com>
C.DeRykus : Ok, I'm going back and replying to the parts of your
reply which I skipped-over before, because I've done some research
and thinking on this.
> Some peril attached unless you're sure about sources but
> you can use the /ee switch to cause a double evaluation
That actually does NOT sound at all like what I'm after.
I need the Replacement to be treated as "regex replacement
string language", not "Perl language".
> eg,
>
> $ perl -E '$str = q{file.avi};
>> $s = q{^(\S+)\.avi$};
>> $e = q{.xyz};
>> $r = q{$1 . $e};
>> $str =~ s/$s/$r/ee;
>> say $str'
> file.xyz
Ok, you're basically translating from "replacement language"
to "Perl language" for the sake of the /ee thingy.
Interesting. But I don't like it. Too messy and indirect.
(And also, when I tried your /ee approach, for some reason
it didn't work; the substituted result came out as an empty
string. But perhaps I just wrote it wrong)
I like my "eval" approach better, because it's simpler and
more direct, and it's a one-liner:
eval("\$NewName = \$OldName =~ s/$regexp/$replacement/rg");
The inner "" mandates a "first pass" which just interpolates
the un-back-slashed variables (and leaves the back-slashed
ones as literal Perl code). Depending on what was *in*
$regexp and $replacement, the interpolated version might
look like:
eval( $NewName = $OldName =~ s/^fvw_(\d{4})$/grt_$1/rg )
The outer eval() then executes its contents as Perl code,
and in the process interpolates any back-references in the
replacement string.
> see: perldoc perlop (substitution operator)
Ok, let's see what perldoc has to say.......
% If the delimiter chosen is a single quote, no interpolation is
% done on either the PATTERN or the REPLACEMENT. Otherwise, if
% the PATTERN contains a $ that looks like a variable rather than
% an end-of-string test, the variable will be interpolated into
% the pattern at run-time.
AH-HA. I see now what the problem was. s/// does *NOT* treat
RegExp and Replacement differently. Both are interpolated, but
ONLY ONCE. But since Replacements are more likely to have embedded
back-references, that's DOUBLY indirect, so the substituted results
of something like THIS:
$foo = '^Red-(\d{4})$';
$bar = 'Grn-$1';
$newname = $oldname =~ s/$foo/$bar/rg;
could end up looking like THIS:
Red-3605 => Grn-$1
When what the programmer actually intended was:
Red-3605 => Grn-3605
% A "/e" will cause the replacement portion to be treated as a
% full-fledged Perl expression and evaluated right then and
% there. It is, however, syntax checked at compile-time.
Colorfully but vaguely written. What is "full-fledged" in this
context? What is "right then and there" in this context?
For that matter, what is "evaluated" in this context?
But I can take a good guess: the author appears to be saying
that the "replacement" string will be evaluated as a Perl
expression. But for most replacement strings, that's NOT
what we want!!!
% A second "e" modifier will cause the replacement portion
% to be "eval"ed before being run as a Perl expression.
Here he's saying, evaluate the string as a Perl expression,
the take the RESULT, and evaluate THAT as being ANOTHER Perl
expression, and substitute the result for the match. YIKES.
No, I'll pass. I'm interested in being able to use ordinary
RegExps and Replacements, not force the user of a script to
come up with doubly-indirect meta-meta-Perl code.
% s/Login: $foo/Login: $bar/; # run-time pattern
Misleading and disingenuous. As I found out the hard way
tonight, if $bar contains any back-references, that code
will definitely NOT work, so that actually should have
been written more like this:
% # WARNING: The following will NOT work if $bar contains
% # back-references such as $1, $2, etc:
% s/Login: $foo/Login: $bar/; # run-time pattern
%
% # This alternative works even if $bar contains back-references:
% eval("s/Login: $foo/Login: $bar/");
So I'd have to say, the s/// section of Perldoc's Perlop
page needs some overhauling. Some poor (vague) writing
in there, and some pretty bad omissions.
--
Cheers,
Robbie Hatley
Midway City, CA, USA
perl -le 'print "\154o\156e\167o\154f\100w\145ll\56c\157m"'
http://www.well.com/user/lonewolf/
https://www.facebook.com/robbie.hatley
------------------------------
Date: Mon, 01 Jun 2015 14:03:36 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Puzzling Substitution Failure
Message-Id: <871thv8tsn.fsf@doppelsaurus.mobileactivedefense.com>
Robbie Hatley <see.my.sig@for.my.address> writes:
[...]
> AH-HA. I see now what the problem was. s/// does *NOT* treat
> RegExp and Replacement differently. Both are interpolated, but
> ONLY ONCE. But since Replacements are more likely to have embedded
> back-references, that's DOUBLY indirect, so the substituted results
> of something like THIS:
>
> $foo = '^Red-(\d{4})$';
> $bar = 'Grn-$1';
> $newname = $oldname =~ s/$foo/$bar/rg;
>
> could end up looking like THIS:
>
> Red-3605 => Grn-$1
>
> When what the programmer actually intended was:
>
> Red-3605 => Grn-3605
Variable substitution inside strings is limited to scalar
variables, arrays, and array or hash slices. (In other words,
names beginning with $ or @, followed by an optional bracketed
expression as a subscript.) The following code segment prints
out "The price is $100."
$Price = '$100'; # not interpolated
print "The price is $Price.\n"; # interpolated
There is no double interpolation in Perl, so the $100 is left as
is.
(from the 'Scalar Value Constructors' section of perldata)
> % A "/e" will cause the replacement portion to be treated as a
> % full-fledged Perl expression and evaluated right then and
> % there. It is, however, syntax checked at compile-time.
>
> Colorfully but vaguely written. What is "full-fledged" in this
> context? What is "right then and there" in this context?
> For that matter, what is "evaluated" in this context?
>
> But I can take a good guess: the author appears to be saying
> that the "replacement" string will be evaluated as a Perl
> expression. But for most replacement strings, that's NOT
> what we want!!!
>
> % A second "e" modifier will cause the replacement portion
> % to be "eval"ed before being run as a Perl expression.
>
> Here he's saying, evaluate the string as a Perl expression,
> the take the RESULT, and evaluate THAT as being ANOTHER Perl
> expression, and substitute the result for the match. YIKES.
That's one way to achieve the 'double interpolation' you wanted to
happen.
[rw@duesterwald]~ $perl <<'TT'
$foo = '^Red-(\d{4})$';
$bar = '"Grn-$1"';
$oldname = 'Red-4455';
$oldname =~ s/$foo/$bar/ee;
print("$oldname\n");
TT
Grn-4455
It's just that the replacement expression is not restricted to 'string
building operations',
[rw@duesterwald]~ $perl <<'TT'
$foo = '^Red-(\d{4})$';
$bar = '$1 * 10 + 3';
$oldname = 'Red-4455';
$oldname =~ s/$foo/$bar/ee;
print("$oldname\n");
TT
44553
[...]
> % s/Login: $foo/Login: $bar/; # run-time pattern
>
> Misleading and disingenuous. As I found out the hard way
> tonight, if $bar contains any back-references, that code
> will definitely NOT work,
It will 'definitely' work as documented for 'double-quote
interpolation', that just doesn't do what you apparently wanted it to
do.
[...]
> % # This alternative works even if $bar contains back-references:
> % eval("s/Login: $foo/Login: $bar/");
It's not really much different from ee: It first interpolates $foo and
$bar into the string and then executes the results as Perl code,
[rw@duesterwald]~ $perl <<'TT'
$foo = '^Red-(\d{4})$';
$bar = 'g-$1/; print STDERR "fork() while 1?\n"; #';
$oldname = 'Red-4455';
eval "\$oldname =~ s/$foo/$bar/";
print("$oldname\n");
TT
fork() while 1?
g-4455
------------------------------
Date: Sun, 31 May 2015 06:06:10 -0700 (PDT)
From: mentificium@gmail.com
Subject: Strong AI Perl NewConcept Module and June 4th Tiananmen Massacre Remembrance
Message-Id: <9ff09a54-2749-4ed0-865e-571f9076e5bd@googlegroups.com>
In the porting of Mentifex MindForth into Perl,
the Strong AI sine-qua-non NewConcept module is
a "stub" in your free open-source Perl AI code.
http://ai.neocities.org/AiSteps.html describes
the process of creating a Strong AI not only in
Perl but in any programming language and in any
natural human language relying on Unicode input.
The purpose of the NewConcept module is to aid
in the machine learning of new words in English
and in the formation of mental concepts tagged
associatively by acoustic words and governed by
a linguistic superstructure for logical thinking.
http://mind.sourceforge.net/newcept.html explains
the pre-existing NewConcept module in non-Perl AI.
We still need to code the OldConcept module that
recognizes the input of a previously known idea,
but first we have to develop prerequisite modules
such as AudRecog for the auditory recognition of
keyboard characters standing in for acoustic sound.
We do this Perl AI coding in somber remembrance of
the upcoming June 4th anniversary of the bloody and
still unpunished massacre of innocent young Chinese
students pleading for freedom and democracy in that
not-so-long-ago springtime of youthful aspiration.
We remember the news reports coming in each day as
the happy students built a replica of the American
Statue of Liberty donated by the French to New York.
We saw the students festooning Tiananmen Square with
artwork and handbills breathlessly discussing the
future of China under democracy and self-determination.
Then on June 4th the still-in-power Chinese government
killed the happy young students and left piles of bodies
bleeding to death on the pavement of Tiananmen Square.
When you hold that iPhone to your ear, can you hear
the screams of the students shot down in bloody murder?
We Perl AI coders, mavericks and revolutionaries to the
core, must call for the condemnation and boycot of all
corporations that do greedy bu$ine$$ with the murderous
Chinese government. Why, they can't even run a railroad.
The Chinese government officials make a big show of
calling for the removal of corruption, which to us
Perl coders resolves to the removal and overthrow of
the student-killing Chinese government and the end
to American companies doing bu$ine$$ over dead bodies.
The top Chinese officials not only kill students but
also steal from Chinese society by granting ownership
of Chinese assets to their children and grandchildren.
If Western news media report on the plunder of China
by the killers and their "princeling" families, then
the reporters are banned from the Chinese mainland.
"Let one hundred flowers blossom," let one hundred
American technology workers infiltrate the companies
doing bu$ine$$ with the evil Chinese murderers and
let the illegitimate Chinese government suspect all
Americans working in China as potential subversives
cooperating with the Chinese democratic underground
in furtherance of the overthrow of the government and
the bringing to justice of the murderers of June 4th.
Mentifex
--
http://www.tiananmenuniv.net
http://www.nlg-wiki.org/systems/Mind.Forth
http://aihub.net/artificial-intelligence-lab-projects
https://aa5new.wordpress.com/2015/05/13/mindforth-ist-echte-wissenschaft
------------------------------
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:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#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 4443
***************************************
