[33092] in Perl-Users-Digest
Perl-Users Digest, Issue: 4368 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Feb 11 11:09:23 2015
Date: Wed, 11 Feb 2015 08:09:07 -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, 11 Feb 2015 Volume: 11 Number: 4368
Today's topics:
Re: eval <rweikusat@mobileactivedefense.com>
Re: eval <gravitalsun@hotmail.foo>
Re: eval <rweikusat@mobileactivedefense.com>
Re: eval <gravitalsun@hotmail.foo>
Re: eval <derykus@gmail.com>
Re: I am trying to find the programmer that wrote the P <rweikusat@mobileactivedefense.com>
Re: I am trying to find the programmer that wrote the P gnewton574@gmail.com
Re: I am trying to find the programmer that wrote the P <gravitalsun@hotmail.foo>
Re: I am trying to find the programmer that wrote the P <justin.1410@purestblue.com>
Re: I am trying to find the programmer that wrote the P <gravitalsun@hotmail.foo>
Reading PI-DB with Win32::OLE and PISDK michael.menge@rwe.com
recursive regex <gravitalsun@hotmail.foo>
Re: recursive regex <rweikusat@mobileactivedefense.com>
Re: recursive regex <rweikusat@mobileactivedefense.com>
Re: recursive regex <gravitalsun@hotmail.foo>
Re: recursive regex <gravitalsun@hotmail.foo>
Re: recursive regex <m@rtij.nl.invlalid>
Re: recursive regex <rweikusat@mobileactivedefense.com>
Re: Traversing through sub dirs and read file contents <rweikusat@mobileactivedefense.com>
Re: Why can I get away with this? <rweikusat@mobileactivedefense.com>
Re: Why can I get away with this? <m@rtij.nl.invlalid>
Re: Why can I get away with this? <rweikusat@mobileactivedefense.com>
Re: Why can I get away with this? <m@rtij.nl.invlalid>
Re: Why can I get away with this? <rweikusat@mobileactivedefense.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 10 Feb 2015 15:10:52 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: eval
Message-Id: <87wq3pajk3.fsf@doppelsaurus.mobileactivedefense.com>
George Mpouras <gravitalsun@hotmail.foo> writes:
> On 10/2/2015 10:59, Peter Makholm wrote:
>> use warnings qw(FATAL)
>
> Very good I think what you suggest is doing the trick.
> my $code = '$val >= 20 ? 1:0';
>
> for my $val ('break it', 30 , 10) {
> my $result = eval "use warnings qw(FATAL); $code";
>
>
> if ($@) {
> print "code evaluation failed because $@\n";
> # sendmail etc
> }
> else {
> print "eval succeed, result is $result\n"
> }
>
> }
When I run this as is, it prints
eval succeed, result is 0
eval succeed, result is 1
eval succeed, result is 0
Changing the eval to
my $result = eval "use warnings FATAL => 'numeric'; $code";
yields
code evaluation failed because Argument "break it" isn't numeric in numeric ge (>=) at (eval 1) line 1.
eval succeed, result is 1
eval succeed, result is 0
Possibly useful here: Scalar::Util::looks_like_number
------------------------------
Date: Tue, 10 Feb 2015 17:44:57 +0200
From: George Mpouras <gravitalsun@hotmail.foo>
Subject: Re: eval
Message-Id: <mbd90q$2pbi$1@news.ntua.gr>
> Changing the eval to
>
> my $result = eval "use warnings FATAL => 'numeric'; $code";
>
> yields
>
> code evaluation failed because Argument "break it" isn't numeric in numeric ge (>=) at (eval 1) line 1.
>
> eval succeed, result is 1
> eval succeed, result is 0
>
> Possibly useful here: Scalar::Util::looks_like_number
>
Actually Peter's solution is great because now program
can know if something is broken or if the evaluation
was successful to continue its flow logic.
$code pieces are on external config files
I will have a look at Scalar::Util
------------------------------
Date: Tue, 10 Feb 2015 15:54:31 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: eval
Message-Id: <87k2zpahjc.fsf@doppelsaurus.mobileactivedefense.com>
George Mpouras <gravitalsun@hotmail.foo> writes:
>> Changing the eval to
>>
>> my $result = eval "use warnings FATAL => 'numeric'; $code";
>>
>> yields
>>
>> code evaluation failed because Argument "break it" isn't numeric in numeric ge (>=) at (eval 1) line 1.
>>
>> eval succeed, result is 1
>> eval succeed, result is 0
>>
>> Possibly useful here: Scalar::Util::looks_like_number
>>
>
>
> Actually Peter's solution is great because now program
> can know if something is broken or if the evaluation
> was successful to continue its flow logic.
Well, "it doesn't work", at least not for perl 5.14.2 and perl 5.10.1: A
warnings category the FATAL is supposed to apply to is additionally
needed. 'numeric' was my idea of a sensible category for this
case. 'all' can be used instead if you really want all warnings to be
considered fatal. OTOH, this opens up the possibility for stuff like
code evaluation failed because It's Friday, the 13th, panic in the streets!
------------------------------
Date: Tue, 10 Feb 2015 21:32:46 +0200
From: George Mpouras <gravitalsun@hotmail.foo>
Subject: Re: eval
Message-Id: <mbdmcv$ro4$1@news.ntua.gr>
On 10/2/2015 5:54 μμ, Rainer Weikusat wrote:
> George Mpouras <gravitalsun@hotmail.foo> writes:
>>> Changing the eval to
>>>
> Well, "it doesn't work",
unfortunately this
#!/usr/bin/perl
use strict; use warnings;
my $code = '$val >= 20 ? 1:0';
for my $val ('break it', 30 , 10) {
my $result = eval "use warnings qw/FATAL/; $code";
if ($@) {
print "code evaluation failed because $@\n";
}
else {
print "code evaluation succeed, result is $result\n"
}
}
works only at 5.20 or later. it is documented here
http://perldoc.perl.org/warnings.html
use v5.20; # Perl 5.20 or greater is required for the following
use warnings 'FATAL'; # short form of "use warnings FATAL => 'all';"
unfortunately this send me back to square 1 , because the virtul host I
am playing (debian 8 unstable) have 5.20.1 but the server it will run
have only 5.16 or something.
The program have absolute no control over the evaluted code so no
checks (scalar::util etc) or corrections can be applied.
I have to catch even the complation errors at eval to decide if it is
safe to continue. I do not know now if it is possible.
------------------------------
Date: Tue, 10 Feb 2015 14:04:26 -0800 (PST)
From: "C.DeRykus" <derykus@gmail.com>
Subject: Re: eval
Message-Id: <c3c369b8-e7ce-49df-be08-460d682545ee@googlegroups.com>
On Tuesday, February 10, 2015 at 11:32:51 AM UTC-8, George Mpouras wrote:
> On 10/2/2015 5:54 =CE=BC=CE=BC, Rainer Weikusat wrote:
> > George Mpouras <gravitalsun@hotmail.foo> writes:
> >>> Changing the eval to
> >>>
> > Well, "it doesn't work",
>=20
> unfortunately this
>=20
> #!/usr/bin/perl
> use strict; use warnings;
> my $code =3D '$val >=3D 20 ? 1:0';
> for my $val ('break it', 30 , 10) {
> my $result =3D eval "use warnings qw/FATAL/; $code";
> if ($@) {
> print "code evaluation failed because $@\n";
> }
> else {
> print "code evaluation succeed, result is $result\n"
> }
> }
>=20
>=20
> works only at 5.20 or later. it is documented here
>=20
> http://perldoc.perl.org/warnings.html
> use v5.20; # Perl 5.20 or greater is required for the following
> use warnings 'FATAL'; # short form of "use warnings FATAL =3D> 'all';"
>=20
> unfortunately this send me back to square 1 , because the virtul host I
> am playing (debian 8 unstable) have 5.20.1 but the server it will run=20
> have only 5.16 or something.
>=20
> The program have absolute no control over the evaluted code so no
> checks (scalar::util etc) or corrections can be applied.
> I have to catch even the complation errors at eval to decide if it is=20
> safe to continue. I do not know now if it is possible.
IIUC, maybe hack the open with a scalar filehandle (available since 5.8.0)=
:
for (...) {
{ local *STDERR;
open(STDERR,'>',\my $err);
my $result =3D eval "$code";
if ($@ or $err) {
print "code evaluation failed because \$@=3D$@ \$err=3D$err\n";
}
else {
print "eval succeed, result is $result err=3D$err\n"
}
}
}
--=20
Charles DeRykus
--=20
Charles DeRykus
------------------------------
Date: Wed, 11 Feb 2015 14:57:32 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: I am trying to find the programmer that wrote the Perl scripts for QuizPlease in about 1997.
Message-Id: <878ug48pib.fsf@doppelsaurus.mobileactivedefense.com>
Justin C <justin.1410@purestblue.com> writes:
> On 2015-02-11, gnewton574@gmail.com <gnewton574@gmail.com> wrote:
>> Thank all of you for your answers. Apparently Rob McCormack that
>> owns Moneytree Software hired a Perl programmer. Anyway I have been
>> trying to figure out what this programmer did for about 10 years.
>> Finally I gave up. I sat down and got serious and wrote my own
>> program. Mine is about 100 lines, the origianl is over 500 lines and
>> uses qpcgi-lib.pl while I used CGI qw(:standard). My program works
>> better and is easier to maintain. At least I know what it does. It
>> grades a submitted test, sends the client the grades, etc and records
>> all this into a data file at the server. This is all pretty simple to
>> veteran programmers but I am not a veteran and have a lot to learn.
>> I am also 71 years old so I had better hurry up and learn this stuff.
>> I will say this, Perl is one hell of a language. I come from the old
>> school where we learned Basic, Fortran IV, PL/1. Ellie Quigley's
>> book, Perl by Example, was an immense help for me. I have 16 Perl
>> books but this book is the best one of all of them for me.
>
> CGI is deprecated. It'll be pulled from core (if it hasn't been
> already). I'd suggest CGI::Application but it depends on CGI :/
So much for
The following modules will be removed from the core distribution
in a future release, and will at that time need to be installed
from CPAN. Distributions on CPAN which require these modules
will need to list them as prerequisites.
The core versions of these modules will now issue "deprecated"
-category warnings to alert you to this fact. To silence these
deprecation warnings, install the modules in question from CPAN.
_Note that the planned removal of these modules from core does
not reflect a judgement about the quality of the code and should
not be taken as a suggestion that their use be halted._ Their
disinclusion from core primarily hinges on their necessity to
bootstrapping a fully functional, CPAN-capable Perl
installation, not on concerns over their design.
CGI and its associated CGI:: packages
http://perldoc.perl.org/5.20.0/perldelta.html#Module-removals
------------------------------
Date: Wed, 11 Feb 2015 01:07:21 -0800 (PST)
From: gnewton574@gmail.com
Subject: Re: I am trying to find the programmer that wrote the Perl scripts for QuizPlease in about 1997.
Message-Id: <af22bf99-a678-4b6b-9f19-bc107fbde3c8@googlegroups.com>
Thank all of you for your answers. Apparently Rob McCormack that owns Mone=
ytree Software hired a Perl programmer. Anyway I have been trying to figur=
e out what this programmer did for about 10 years. Finally I gave up. I sa=
t down and got serious and wrote my own program. Mine is about 100 lines, =
the origianl is over 500 lines and uses qpcgi-lib.pl while I used CGI qw(:s=
tandard). My program works better and is easier to maintain. At least I k=
now what it does. It grades a submitted test, sends the client the grades,=
etc and records all this into a data file at the server. This is all prett=
y simple to veteran programmers but I am not a veteran and have a lot to le=
arn. I am also 71 years old so I had better hurry up and learn this stuff.=
I will say this, Perl is one hell of a language. I come from the old sch=
ool where we learned Basic, Fortran IV, PL/1. Ellie Quigley's book, Perl by=
Example, was an immense help for me. I have 16 Perl books but this book i=
s the best one of all of them for me.
------------------------------
Date: Wed, 11 Feb 2015 11:49:44 +0200
From: George Mpouras <gravitalsun@hotmail.foo>
Subject: Re: I am trying to find the programmer that wrote the Perl scripts for QuizPlease in about 1997.
Message-Id: <mbf8ip$5sg$1@news.ntua.gr>
On 11/2/2015 11:07, gnewton574@gmail.com wrote:
> Rob McCormack
Strange, I expect the company owner, at least, to know the name of the
employ. Anyway if you have any technical issue you can always post here.
------------------------------
Date: Wed, 11 Feb 2015 11:15:38 +0000
From: Justin C <justin.1410@purestblue.com>
Subject: Re: I am trying to find the programmer that wrote the Perl scripts for QuizPlease in about 1997.
Message-Id: <q7qrqb-sf6.ln1@zem.masonsmusic.co.uk>
On 2015-02-11, gnewton574@gmail.com <gnewton574@gmail.com> wrote:
> Thank all of you for your answers. Apparently Rob McCormack that owns Moneytree Software hired a Perl programmer. Anyway I have been trying to figure out what this programmer did for about 10 years. Finally I gave up. I sat down and got serious and wrote my own program. Mine is about 100 lines, the origianl is over 500 lines and uses qpcgi-lib.pl while I used CGI qw(:standard). My program works better and is easier to maintain. At least I know what it does. It grades a submitted test, sends the client the grades, etc and records all this into a data file at the server. This is all pretty simple to veteran programmers but I am not a veteran and have a lot to learn. I am also 71 years old so I had better hurry up and learn this stuff. I will say this, Perl is one hell of a language. I come from the old school where we learned Basic, Fortran IV, PL/1. Ellie Quigley's book, Perl by Example, was an immense help for me. I have 16 Perl books but this book is the best o!
ne of all of them for me.
CGI is deprecated. It'll be pulled from core (if it hasn't been
already). I'd suggest CGI::Application but it depends on CGI :/
Time to grasp the metal and learn Dancer? Or try this:
http://www.simon-cozens.org/content/i-finally-get-psgi-and-plack
and use PSGI/Plack directly.
Justin.
--
Justin C, by the sea.
------------------------------
Date: Wed, 11 Feb 2015 17:13:20 +0200
From: George Mpouras <gravitalsun@hotmail.foo>
Subject: Re: I am trying to find the programmer that wrote the Perl scripts for QuizPlease in about 1997.
Message-Id: <mbfrhh$1rf1$1@news.ntua.gr>
On 11/2/2015 13:15, Justin C wrote:
> On 2015-02-11, gnewton574@gmail.com <gnewton574@gmail.com> wrote:
>> Thank all of you for your answers. Apparently Rob McCormack that owns Moneytree Software hired a Perl programmer. Anyway I have been trying to figure out what this programmer did for about 10 years. Finally I gave up. I sat down and got serious and wrote my own program. Mine is about 100 lines, the origianl is over 500 lines and uses qpcgi-lib.pl while I used CGI qw(:standard). My program works better and is easier to maintain. At least I know what it does. It grades a submitted test, sends the client the grades, etc and records all this into a data file at the server. This is all pretty simple to veteran programmers but I am not a veteran and have a lot to learn. I am also 71 years old so I had better hurry up and learn this stuff. I will say this, Perl is one hell of a language. I come from the old school where we learned Basic, Fortran IV, PL/1. Ellie Quigley's book, Perl by Example, was an immense help for me. I have 16 Perl books but this book is the best !
one of a
ll of them for me.
>
> CGI is deprecated. It'll be pulled from core (if it hasn't been
> already). I'd suggest CGI::Application but it depends on CGI :/
>
> Time to grasp the metal and learn Dancer? Or try this:
> http://www.simon-cozens.org/content/i-finally-get-psgi-and-plack
> and use PSGI/Plack directly.
>
>
> Justin.
>
if you know what you are doing you can have far better performance than
using these http frameworks.
Usually you only want to parse the url arguments or write a service. For
me CGI is the no 1 choice.
------------------------------
Date: Tue, 10 Feb 2015 05:46:55 -0800 (PST)
From: michael.menge@rwe.com
Subject: Reading PI-DB with Win32::OLE and PISDK
Message-Id: <56558363-460d-4991-83f7-cc40622d0891@googlegroups.com>
Hallo,
I'm trying to read data from PI-db from company Osisoft using OLE and the PI-SDK (win 7 with strawberry perl V5.18.2, PISDK version 1.4.0 build 416).
I can read the snapshotdata of a PI-tag, but calling method "RecordedValues" I allways get an error message
"win32::OLE(0.1711) error 0x80020005: "Typkonflikt"
in METHOD/PROPERTYGET "RecordedValues" argument "BoundaryType" at Pi.pl line ..
An internet search shows (http://support.microsoft.com/kb/507620/de) (translated from german):
The error message occurs only if the following conditions are met:
- the parameter is passed by reference
- the corresponding Visual Basic data type is either Byte, Integer, Single or Double
This behaviour is intended.
Perhaps the error is that Perl passes parameter by referenz, but the argument "BoundaryType" has to be passed by value.
The PI-Help-Utility looks like this:
---
RecordedValues Method (PIData object)
This method returns compressed values for the requested time range from the archive as a PIValues collection.
Syntax
object.RecordedValues StartTime, EndTime, BoundaryType, [FilterExp], [ShowFiltered], [AsyncStatus]
The RecordedValues method syntax has these parts:
Part Description
object An object expression that evaluates to a PIData object.
StartTime A Variant containing the time. See the Settings section for allowable values.
EndTime A Variant containing the time. See the Settings section for allowable values. When ...
BoundaryType A value from the BoundaryTypeConstants enumeration type that determines how the times and values of the returned end points are determined.
---
You get the BoundaryTypeConstants with (my $piConst = Win32::OLE::Const->Load($PI);),
possible values are 0,1,2,3 and should be declared as .NET-Enumeration of type int (4 Bytes).
I've tried various ways to call the method, but the error message remains.
Here is an extract of the perl code:
#! /usr/bin/perl
use warnings;
use strict;
use Win32::OLE;
use Win32::OLE::Const;
use Win32::OLE::Variant;
my $PI = Win32::OLE->new('PISDK.PISDK') or die "PISDK Error: ",Win32::OLE->LastError();
my $piConst = Win32::OLE::Const->Load($PI);
#print "PiConst: $_ \t= $piConst->{$_}\n"
for (sort(keys(%$piConst))); # print all constants
my $server = $PI->Servers->Item("Servername") or
die "No PI server Objekt: ",Win32::OLE->LastError(),"\n";
my $status = $server->Open("UID=Username;PWD=Userpassword");
print_point ('PI-Tag_Name');
sub print_point {
my $piTag = $_[0];
my $point = $server->PIPoints->item($piTag);
print "\npiTag: $piTag Point: $point\n";
unless ($point) {
print "piTag $piTag kann nicht gelesen werden\n";
return;
}
print "\t$_ = $point->{$_}\n" for (sort(keys(%$point))); # ok
print "\tData: $_ = $point->Data->{$_}\n"
for (sort(keys(%{$point->{Data}}))); # ok
print "\tData-Snapshot: $_ = $point->Data->Snapshot->{$_}\n"
for (sort(keys(%{$point->Data->{Snapshot}}))); # ok
my $startTime = Variant(VT_DATE,'05.01.2015 12:00:00');
my $endTime = Variant(VT_DATE,'07.01.2015 23:45:00');
my $btFlag = Variant(VT_I4,$piConst->{btInside});
$Win32::OLE::Warn = 3;
my $recValues = $point->Data->RecordedValues
($startTime,$endTime,$btFlag); # error "Typkonflikt" at argument "BoundaryType"
my $recValues = $point->Data->RecordedValues
($startTime,$endTime,$piConst->{btInside}); # same error
my $recValues = $point->Data->RecordedValues
('05.01.2015 12:00:00','07.01.2015 12:00:00',0); # same error
my $recValues = $point->Data->RecordedValues
( {StartTime => "05.01.2015 12:00:00", # same error
EndTime => "07.01.2015 12:00:00",
BoundaryType => Variant(VT_I4,0)} ); # BoundaryType => 0}
}
------------------------------
Date: Tue, 10 Feb 2015 17:50:22 +0200
From: George Mpouras <gravitalsun@hotmail.foo>
Subject: recursive regex
Message-Id: <mbd9av$2q2m$1@news.ntua.gr>
The following works fine and expand the macros that may
exist on a string
my %macro=(
'%MONITOR%' =>'11',
'%LEVEL%' =>'22',
'%CONDITION%' =>'33',
'%EPOCHTIMEOFEVENT%'=>'44',
'%COMMANDOUTPUT%' =>'55',
'%DESCRIPTION%' =>'66');
$_ = 'hello %MONITOR%sys%LEVEL% %CONDITION% world';
s/(\%[^\%]+\%)/( exists $macro{$1} ? $macro{$1} : $& )/ge;
say;
I was trying to get the same result but using smaller macro names like
my %macro=(
'$MONITOR' =>'11',
'$LEVEL%' =>'22', ...
but unfortunately the regex is getting too hard to
find if a macro is finished inside the string.
------------------------------
Date: Tue, 10 Feb 2015 16:41:06 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: recursive regex
Message-Id: <87bnl1afdp.fsf@doppelsaurus.mobileactivedefense.com>
George Mpouras <gravitalsun@hotmail.foo> writes:
> The following works fine and expand the macros that may
> exist on a string
>
> my %macro=(
> '%MONITOR%' =>'11',
> '%LEVEL%' =>'22',
> '%CONDITION%' =>'33',
> '%EPOCHTIMEOFEVENT%'=>'44',
> '%COMMANDOUTPUT%' =>'55',
> '%DESCRIPTION%' =>'66');
>
> $_ = 'hello %MONITOR%sys%LEVEL% %CONDITION% world';
> s/(\%[^\%]+\%)/( exists $macro{$1} ? $macro{$1} : $& )/ge;
> say;
>
>
> I was trying to get the same result but using smaller macro names like
>
> my %macro=(
> '$MONITOR' =>'11',
> '$LEVEL%' =>'22', ...
>
> but unfortunately the regex is getting too hard to
> find if a macro is finished inside the string.
Hmm ...
s/(\$[A-Z]+)/$macro{$1} \/\/ $1/ge;
?
------------------------------
Date: Tue, 10 Feb 2015 17:35:48 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: recursive regex
Message-Id: <877fvpacui.fsf@doppelsaurus.mobileactivedefense.com>
Rainer Weikusat <rweikusat@mobileactivedefense.com> writes:
> George Mpouras <gravitalsun@hotmail.foo> writes:
>> The following works fine and expand the macros that may
>> exist on a string
>>
>> my %macro=(
>> '%MONITOR%' =>'11',
>> '%LEVEL%' =>'22',
>> '%CONDITION%' =>'33',
>> '%EPOCHTIMEOFEVENT%'=>'44',
>> '%COMMANDOUTPUT%' =>'55',
>> '%DESCRIPTION%' =>'66');
>>
>> $_ = 'hello %MONITOR%sys%LEVEL% %CONDITION% world';
>> s/(\%[^\%]+\%)/( exists $macro{$1} ? $macro{$1} : $& )/ge;
>> say;
>>
>>
>> I was trying to get the same result but using smaller macro names like
>>
>> my %macro=(
>> '$MONITOR' =>'11',
>> '$LEVEL%' =>'22', ...
>>
>> but unfortunately the regex is getting too hard to
>> find if a macro is finished inside the string.
>
> Hmm ...
>
> s/(\$[A-Z]+)/$macro{$1} \/\/ $1/ge;
>
> ?
Other idea: Use a substituion regex matching just the macro names:
------------
use 5.14.2;
my %macro=(
'$MONITOR' =>'11',
'$LEVEL' =>'22',
'$CONDITION' =>'33',
'$EPOCHTIMEOFEVENT'=>'44',
'$COMMANDOUTPUT' =>'55',
'$DESCRIPTION' =>'66');
$_ = 'hello $MONITORsys$LEVEL $CONDITION world! $A';
my $re = '(\$(?:'.join('|', map { substr($_, 1); } keys(%macro)).'))';
#print("$re\n");
s/$re/$macro{$+}/ge;
say;
------------
------------------------------
Date: Tue, 10 Feb 2015 21:58:26 +0200
From: George Mpouras <gravitalsun@hotmail.foo>
Subject: Re: recursive regex
Message-Id: <mbdnt2$101i$1@news.ntua.gr>
> '$EPOCHTIMEOFEVENT'=>'44',
> '$COMMANDOUTPUT' =>'55',
> '$DESCRIPTION' =>'66');
>
> $_ = 'hello $MONITORsys$LEVEL $CONDITION world! $A';
>
> my $re = '(\$(?:'.join('|', map { substr($_, 1); } keys(%macro)).'))';
> #print("$re\n");
>
> s/$re/$macro{$+}/ge;
> say;
this is clever and working on all difficult cases I could think I will
use it.
------------------------------
Date: Tue, 10 Feb 2015 22:10:52 +0200
From: George Mpouras <gravitalsun@hotmail.foo>
Subject: Re: recursive regex
Message-Id: <mbdokc$11u1$1@news.ntua.gr>
On 10/2/2015 9:58 μμ, George Mpouras wrote:
>> '$EPOCHTIMEOFEVENT'=>'44',
>> '$COMMANDOUTPUT' =>'55',
>> '$DESCRIPTION' =>'66');
>>
>> $_ = 'hello $MONITORsys$LEVEL $CONDITION world! $A';
>>
>> my $re = '(\$(?:'.join('|', map { substr($_, 1); } keys(%macro)).'))';
>> #print("$re\n");
>>
>> s/$re/$macro{$+}/ge;
>> say;
>
> this is clever and working on all difficult cases I could think I will
> use it.
>
>
>
may be the (?: ..) is not neccassery, because the
my $re = "(\\". join("|\\", keys %macro) .')' also works
but anyway it is only cosmetic, thanks
------------------------------
Date: Wed, 11 Feb 2015 16:13:10 +0100
From: Martijn Lievaart <m@rtij.nl.invlalid>
Subject: Re: recursive regex
Message-Id: <658sqb-3lm.ln1@news.rtij.nl>
On Tue, 10 Feb 2015 21:58:26 +0200, George Mpouras wrote:
>> '$EPOCHTIMEOFEVENT'=>'44', '$COMMANDOUTPUT' =>'55',
>> '$DESCRIPTION' =>'66');
>>
>> $_ = 'hello $MONITORsys$LEVEL $CONDITION world! $A';
>>
>> my $re = '(\$(?:'.join('|', map { substr($_, 1); } keys(%macro)).'))';
>> #print("$re\n");
>>
>> s/$re/$macro{$+}/ge;
>> say;
>
> this is clever and working on all difficult cases I could think I will
> use it.
I think you'll need to add something like a reverse sort on the keys to
make it work when one key is the prefix of another, e.g. $MAP1 should not
match when $MAP11 exists and is requested. So $MAP11 should come earlier
in the regex, so reverse sorting the keys should take care of that.
M4
------------------------------
Date: Wed, 11 Feb 2015 15:40:24 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: recursive regex
Message-Id: <87pp9g78yf.fsf@doppelsaurus.mobileactivedefense.com>
Martijn Lievaart <m@rtij.nl.invlalid> writes:
> On Tue, 10 Feb 2015 21:58:26 +0200, George Mpouras wrote:
>>> '$EPOCHTIMEOFEVENT'=>'44', '$COMMANDOUTPUT' =>'55',
>>> '$DESCRIPTION' =>'66');
>>>
>>> $_ = 'hello $MONITORsys$LEVEL $CONDITION world! $A';
>>>
>>> my $re = '(\$(?:'.join('|', map { substr($_, 1); } keys(%macro)).'))';
>>> #print("$re\n");
>>>
>>> s/$re/$macro{$+}/ge;
>>> say;
>>
>> this is clever and working on all difficult cases I could think I will
>> use it.
>
> I think you'll need to add something like a reverse sort on the keys to
> make it work when one key is the prefix of another, e.g. $MAP1 should not
> match when $MAP11 exists and is requested.
I assumed Perl would prefer the longer match but it (at least the
version I tested) actually uses the first match, cf
[rw@doppelsaurus]/tmp#perl -le '"mapmap" =~ /(map|mapmap)/; print $+'
map
[rw@doppelsaurus]/tmp#perl -le '"mapmap" =~ /(map|mapmap)/; print $+'
map
[rw@doppelsaurus]/tmp#perl -le '"mapmap" =~ /(mapmap|map)/; print $+'
mapmap
Corrected example:
---------------------
use 5.14.2;
my %macro=(
'$MON' =>'1',
'$MONITOR' =>'11',
'$LEVEL' =>'22',
'$CONDITION' =>'33',
'$EPOCHTIMEOFEVENT'=>'44',
'$COMMANDOUTPUT' =>'55',
'$DESCRIPTION' =>'66');
$_ = 'hello $MONITORsys$LEVEL $CONDITION world! $A $MONATIR';
my $re = '(\$(?:'.join('|', map { substr($_, 1) } sort { length($b) <=> length($a) } keys(%macro)).'))';
#print("$re\n");
s/$re/$macro{$+}/ge;
say;
------------------------------
Date: Tue, 10 Feb 2015 20:40:35 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Traversing through sub dirs and read file contents
Message-Id: <87386da4ak.fsf@doppelsaurus.mobileactivedefense.com>
Henry Law <news@lawshouse.org> writes:
> On 08/02/15 14:09, Rainer Weikusat wrote:
>> File::Find is a walking horror
>
> Well, IANPH but I use it all the time for doing what it's designed to
> do: follow a tree and let me do whatever I want with directories and
> files it finds. It may have some exotic fault that I wot not of, but
> for the base use case it works flawlessly.
"It works" is not the gold-standard software, except maybe when the
people writing it have a seriously hard time getting something together
which works at all, it's rather a basic criterion for 'being
acceptable': It should at least work (not that there isn't a lot of
software which doesn't). Preferably, it should also work in a sensible
way, eg, it should scale up and down without gross inefficiencies, and
the code should be as simple as possible while still accomplishing
that because some day, it will have to be changed to fix a bug or add a
feature and this should be doable by 'ordinary people' (who haven't
studied this particular problem for $time_periods) within a reasonable
amount of time. And that's where File::Find falls down: It's much too
complicated for solving a simple, actual problem because it's supposed
to solve all of a class of related problems and most of its code will
thus be useless for any particular use case (or won't ever be useful in
a certain context --- an automatic configuration program supposed to
manage Linux-based virtual servers will never have to deal with a VMS
filesystem).
Also, the interface is a little 'strange': Presumably in
order to have 'better performance' when working with insanely large
amounts of data, it's a callback function called 'the wanted function'
despite the name is not meant this way which has to extract all its
information from a set of 'global variables will well-known
names'. Something like this may be sensible as a performance hack (if it
actually improves performance which would need to be determined) and a
'universal file-finding module' obviously has to err on the side of
that, but when counting cycles that hard is not necessary, a more
'procedural' one where the callback gets its arguments passed as
arguments is IMHO preferable (and when counting cycles that hard,
open-coding the operation as part of the traversal code will probably be
faster).
Possibly illustrative example: Some code I'm dealing with used to use
Data::Dumper to serialize certain Perl datastructures (anonymous arrays
containing complex objects) to text files in order to provide bootstrap
information when the containing program has to start while not able to
contact a database server (possibly located on another
continent). Originally, this used the Data::Dumper XS implementation
because this seemed to be the sensible choice. As installations grew
larger and with them the amount of data to be serialized, it was found
that the XS implementation would corrupt the memory of the running perl
process, ultimatively causing it to crash. After a quick look at that, I
immediately abandoned the idea of fixing the bug and switched to using
the Perl implementation instead.
This worked nicely for a couple of years but ended up as major
performance problem when installations grew large enough, mainly because
the complete, serialized representation had to be created in memory
prior to writing it out (which led to Perl process hogging the CPU for
minutes will growing to sizes beyond 6G). Also, the created files were
seriously large and inspecting them resulted in the discovery that more
than 80% of their content were space-characters used for pretty
printing. I made a few half-assed changes to the Perl code (still much
too complicated and supporting much to many features of no use in this
situation). I then implemented just the necessary features in 237 lines
of C which create equivalent but much smaller files much faster using a
lot less memory.
Had I done this from the start, it wouldn't have taken more time than
was lost trying to make Data::Dumper work as required and the
customer-visible problems could have been avoided entirely. And the
standard module was a much better fit for my problem the File::Find is
for something requiring a 'simple', limited-scale directory traversal.
------------------------------
Date: Tue, 10 Feb 2015 15:23:16 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Why can I get away with this?
Message-Id: <87oap1aizf.fsf@doppelsaurus.mobileactivedefense.com>
Martijn Lievaart <m@rtij.nl.invlalid> writes:
> On Mon, 09 Feb 2015 23:23:41 -0800, Robbie Hatley wrote:
>
>> Wait, there's actually one other character which *MUST* be disallowed in
>> file names in nearly every file system, and that's '\0', except perhaps
>> as the vary last character of a file name. The reason I say that is, if
>> you put '\0' at the beginning or middle of a file name, when Perl or the
>> OS tries to read back the file name, it stops reading characters when it
>> hits the null terminator, so that THIS file name:
>>
>> $FileName = "斊詥觬榹苵\0匞寨蹼粿砺";
>>
>> would be foreshortened on readback to:
>>
>> $FileName = "斊詥觬榹苵";
>>
>> and give "file not found" errors.
>
> I guess you have a C background, because the above is not logical at all.
It's a perfectly arbitrary restriction imposed by the way strings are
defined in C. This means everything which supports some kind of 'native
C or C++ interface' will necessarily include this restriction (not
strictly necessarily, just very likely).
------------------------------
Date: Wed, 11 Feb 2015 15:34:59 +0100
From: Martijn Lievaart <m@rtij.nl.invlalid>
Subject: Re: Why can I get away with this?
Message-Id: <jt5sqb-r9a.ln1@news.rtij.nl>
On Tue, 10 Feb 2015 15:23:16 +0000, Rainer Weikusat wrote:
> Martijn Lievaart <m@rtij.nl.invlalid> writes:
>> On Mon, 09 Feb 2015 23:23:41 -0800, Robbie Hatley wrote:
>>
>>> Wait, there's actually one other character which *MUST* be disallowed
>>> in file names in nearly every file system, and that's '\0', except
>>> perhaps as the vary last character of a file name. The reason I say
>>> that is, if you put '\0' at the beginning or middle of a file name,
>>> when Perl or the OS tries to read back the file name, it stops reading
>>> characters when it hits the null terminator, so that THIS file name:
>>>
>>> $FileName = "斊詥觬榹苵\0匞寨蹼粿砺";
>>>
>>> would be foreshortened on readback to:
>>>
>>> $FileName = "斊詥觬榹苵";
>>>
>>> and give "file not found" errors.
>>
>> I guess you have a C background, because the above is not logical at
>> all.
>
> It's a perfectly arbitrary restriction imposed by the way strings are
> defined in C. This means everything which supports some kind of 'native
> C or C++ interface' will necessarily include this restriction (not
> strictly necessarily, just very likely).
Again, this is a non sequitur.
The correct logic would be: Windows uses an API where filenames are null-
terminated, so null cannot be part of the filename. Anything else is
stretching.
Obviously, this has it's roots in traditional C-strings, but that is a
conscious choice by the Windows developers. They could just as well have
used a character count, as other parts of the Windows API do.
M4
------------------------------
Date: Wed, 11 Feb 2015 14:53:22 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Why can I get away with this?
Message-Id: <87d25g8pp9.fsf@doppelsaurus.mobileactivedefense.com>
Martijn Lievaart <m@rtij.nl.invlalid> writes:
> On Tue, 10 Feb 2015 15:23:16 +0000, Rainer Weikusat wrote:
>> Martijn Lievaart <m@rtij.nl.invlalid> writes:
>>> On Mon, 09 Feb 2015 23:23:41 -0800, Robbie Hatley wrote:
>>>
>>>> Wait, there's actually one other character which *MUST* be disallowed
>>>> in file names in nearly every file system, and that's '\0', except
>>>> perhaps as the vary last character of a file name. The reason I say
>>>> that is, if you put '\0' at the beginning or middle of a file name,
>>>> when Perl or the OS tries to read back the file name, it stops reading
>>>> characters when it hits the null terminator, so that THIS file name:
>>>>
>>>> $FileName = "斊詥觬榹苵\0匞寨蹼粿砺";
>>>>
>>>> would be foreshortened on readback to:
>>>>
>>>> $FileName = "斊詥觬榹苵";
>>>>
>>>> and give "file not found" errors.
>>>
>>> I guess you have a C background, because the above is not logical at
>>> all.
>>
>> It's a perfectly arbitrary restriction imposed by the way strings are
>> defined in C. This means everything which supports some kind of 'native
>> C or C++ interface' will necessarily include this restriction (not
>> strictly necessarily, just very likely).
>
> Again, this is a non sequitur.
>
> The correct logic would be: Windows uses an API where filenames are null-
> terminated, so null cannot be part of the filename. Anything else is
> stretching.
>
> Obviously, this has it's roots in traditional C-strings, but that is a
> conscious choice by the Windows developers.
"That's completely wrong except that it's not ?!?". You're just
paraphrasing my text reverted: C (and C++) use the
sequence-of-bytes-terminated-by-0 convention for strings. Both are
extremely popular languages, more so by the time the respective design
descisions were made, hence, designing something like 'file system
naming conventions' such that filenames can be processed by 'standard C
functions' makes/ made a lot of sense.
------------------------------
Date: Wed, 11 Feb 2015 16:18:54 +0100
From: Martijn Lievaart <m@rtij.nl.invlalid>
Subject: Re: Why can I get away with this?
Message-Id: <uf8sqb-3lm.ln1@news.rtij.nl>
On Wed, 11 Feb 2015 14:53:22 +0000, Rainer Weikusat wrote:
> Martijn Lievaart <m@rtij.nl.invlalid> writes:
>> On Tue, 10 Feb 2015 15:23:16 +0000, Rainer Weikusat wrote:
>>> Martijn Lievaart <m@rtij.nl.invlalid> writes:
>>>> On Mon, 09 Feb 2015 23:23:41 -0800, Robbie Hatley wrote:
>>>>
>>>>> Wait, there's actually one other character which *MUST* be
>>>>> disallowed in file names in nearly every file system, and that's
>>>>> '\0', except perhaps as the vary last character of a file name. The
>>>>> reason I say that is, if you put '\0' at the beginning or middle of
>>>>> a file name, when Perl or the OS tries to read back the file name,
>>>>> it stops reading characters when it hits the null terminator, so
>>>>> that THIS file name:
>>>>>
>>>>> $FileName = "斊詥觬榹苵\0匞寨蹼粿砺";
>>>>>
>>>>> would be foreshortened on readback to:
>>>>>
>>>>> $FileName = "斊詥觬榹苵";
>>>>>
>>>>> and give "file not found" errors.
>>>>
>>>> I guess you have a C background, because the above is not logical at
>>>> all.
>>>
>>> It's a perfectly arbitrary restriction imposed by the way strings are
>>> defined in C. This means everything which supports some kind of
>>> 'native C or C++ interface' will necessarily include this restriction
>>> (not strictly necessarily, just very likely).
>>
>> Again, this is a non sequitur.
>>
>> The correct logic would be: Windows uses an API where filenames are
>> null-
>> terminated, so null cannot be part of the filename. Anything else is
>> stretching.
>>
>> Obviously, this has it's roots in traditional C-strings, but that is a
>> conscious choice by the Windows developers.
>
> "That's completely wrong except that it's not ?!?". You're just
> paraphrasing my text reverted: C (and C++) use the
> sequence-of-bytes-terminated-by-0 convention for strings. Both are
> extremely popular languages, more so by the time the respective design
> descisions were made, hence, designing something like 'file system
> naming conventions' such that filenames can be processed by 'standard C
> functions' makes/ made a lot of sense.
That is not what you originally said, and this makes sense yes. It's
actually what I also said, just in other words.
Having an API that can be easily be used from C is obviously an
advantage. It's a sound decision. But it is not a *MUST* (your emphasis).
Besides that, you stated that such would be unusable from Perl, which is
obviously bogus. Perl handles embedded nulls just fine.
M4
------------------------------
Date: Wed, 11 Feb 2015 15:34:11 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Why can I get away with this?
Message-Id: <87twys798s.fsf@doppelsaurus.mobileactivedefense.com>
Martijn Lievaart <m@rtij.nl.invlalid> writes:
> On Wed, 11 Feb 2015 14:53:22 +0000, Rainer Weikusat wrote:
>> Martijn Lievaart <m@rtij.nl.invlalid> writes:
>>> On Tue, 10 Feb 2015 15:23:16 +0000, Rainer Weikusat wrote:
>>>> Martijn Lievaart <m@rtij.nl.invlalid> writes:
>>>>> On Mon, 09 Feb 2015 23:23:41 -0800, Robbie Hatley wrote:
>>>>>
>>>>>> Wait, there's actually one other character which *MUST* be
>>>>>> disallowed in file names in nearly every file system, and that's
>>>>>> '\0', except perhaps as the vary last character of a file name. The
>>>>>> reason I say that is, if you put '\0' at the beginning or middle of
>>>>>> a file name, when Perl or the OS tries to read back the file name,
>>>>>> it stops reading characters when it hits the null terminator, so
>>>>>> that THIS file name:
>>>>>>
>>>>>> $FileName = "斊詥觬榹苵\0匞寨蹼粿砺";
>>>>>>
>>>>>> would be foreshortened on readback to:
>>>>>>
>>>>>> $FileName = "斊詥觬榹苵";
>>>>>>
>>>>>> and give "file not found" errors.
>>>>>
>>>>> I guess you have a C background, because the above is not logical at
>>>>> all.
>>>>
>>>> It's a perfectly arbitrary restriction imposed by the way strings are
>>>> defined in C. This means everything which supports some kind of
>>>> 'native C or C++ interface' will necessarily include this restriction
>>>> (not strictly necessarily, just very likely).
>>>
>>> Again, this is a non sequitur.
>>>
>>> The correct logic would be: Windows uses an API where filenames are
>>> null-
>>> terminated, so null cannot be part of the filename. Anything else is
>>> stretching.
>>>
>>> Obviously, this has it's roots in traditional C-strings, but that is a
>>> conscious choice by the Windows developers.
>>
>> "That's completely wrong except that it's not ?!?". You're just
>> paraphrasing my text reverted: C (and C++) use the
>> sequence-of-bytes-terminated-by-0 convention for strings. Both are
>> extremely popular languages, more so by the time the respective design
>> descisions were made, hence, designing something like 'file system
>> naming conventions' such that filenames can be processed by 'standard C
>> functions' makes/ made a lot of sense.
>
> That is not what you originally said, and this makes sense yes. It's
> actually what I also said, just in other words.
I'm sorry but that's a misunderstanding on your part: That's exactly
what I originally said: This is the C convention. Hence, anything which
supports a C API will 'necessarily' adhere to it (with 'necessarily'
really supposed to mean 'very likely because throwing rocks at people
who take the C convention for granted make little sense').
[...]
> Besides that, you stated that such would be unusable from Perl, which is
> obviously bogus. Perl handles embedded nulls just fine.
I certainly didn't.
------------------------------
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 4368
***************************************
