[32248] in Perl-Users-Digest
Perl-Users Digest, Issue: 3515 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun Oct 9 21:09:26 2011
Date: Sun, 9 Oct 2011 18:09:09 -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 Sun, 9 Oct 2011 Volume: 11 Number: 3515
Today's topics:
Code/module for "paranoid" checks of SSL peer/server ce <anfi@onet.eu>
GuiTest - scraping the content of dropdown in Jave app? <woland99@gmail.com>
Re: GuiTest - scraping the content of dropdown in Jave <ben@morrow.me.uk>
Re: GuiTest - scraping the content of dropdown in Jave <woland99@gmail.com>
Re: GuiTest - scraping the content of dropdown in Jave <ben@morrow.me.uk>
Re: GuiTest - scraping the content of dropdown in Jave <woland99@gmail.com>
Re: Help me to Improve <rweikusat@mssgmbh.com>
Re: Help me to Improve <mvdwege@mail.com>
Re: Help me to Improve <jurgenex@hotmail.com>
Re: Help me to Improve <tadmc@seesig.invalid>
Re: Help me to Improve <tadmc@seesig.invalid>
Re: Help me to Improve <ben@morrow.me.uk>
Re: Help me to Improve <jurgenex@hotmail.com>
Re: Help me to Improve <ben@morrow.me.uk>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sun, 09 Oct 2011 21:23:11 +0200
From: Andrzej Adam Filip <anfi@onet.eu>
Subject: Code/module for "paranoid" checks of SSL peer/server certificate
Message-Id: <kvfl36hy5d-BA9@ollie.huge.strangled.net>
Could you recommend sample perl code/module for _paranoid_ SSL
peer/server certificate checks?
--
[pl>en Andrew] Andrzej A. Filip : anfi@onet.eu : Andrzej.Filip@gmail.com
I do not believe that this generation of Americans is willing to resign itself
to going to bed each night by the light of a Communist moon...
-- Lyndon B. Johnson
------------------------------
Date: Sat, 8 Oct 2011 09:16:01 -0700 (PDT)
From: Woland99 <woland99@gmail.com>
Subject: GuiTest - scraping the content of dropdown in Jave app?
Message-Id: <aacb9a6e-492a-473c-9f5f-764d33eebeb1@n15g2000vbn.googlegroups.com>
Hi - I am trying to use Perl to run a simple test scrip on Java app. I
need to run same testcase for ALL the items on one of the dropdown
controls. Problem is - content of that control ie. item on that
dropdown list may change from build to build and there is a LOT of
them 50+ so not feasible to simply copy them by hand.
Is there any way to use Perl to extract content of such control?
I tried GuiTest module - it does ok job in controlling the pp although
it does not seem to see any child windows on it - just the main one -
of class SunAwtFrame - I can do SenKeys and it is sufficient to run
the test but I really need to enumerate results by the content of that
control. Perhaps there is another tool better suited for the task of
running Java app?
TIA for any pointers/references/hel,
JT
------------------------------
Date: Sat, 08 Oct 2011 15:31:38 -0500
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: GuiTest - scraping the content of dropdown in Jave app?
Message-Id: <rJednWqbdoi3Lg3TnZ2dnUVZ7sOdnZ2d@bt.com>
Quoth Woland99 <woland99@gmail.com>:
> Hi - I am trying to use Perl to run a simple test scrip on Java app. I
> need to run same testcase for ALL the items on one of the dropdown
> controls. Problem is - content of that control ie. item on that
> dropdown list may change from build to build and there is a LOT of
> them 50+ so not feasible to simply copy them by hand.
> Is there any way to use Perl to extract content of such control?
> I tried GuiTest module - it does ok job in controlling the pp although
> it does not seem to see any child windows on it - just the main one -
> of class SunAwtFrame - I can do SenKeys and it is sufficient to run
> the test but I really need to enumerate results by the content of that
> control. Perhaps there is another tool better suited for the task of
> running Java app?
Is the Java app using AWT or Swing? (I presume you're not talking about
something web-based, which would be much easier to test.) If it's Swing
you probably can't get at the contents at all: Swing does its own
drawing, so as far as the OS knows there's nothing there but coloured
pixels. If it's AWT then I thought AWT used real OS controls, but ICBW.
When you say 'GuiTest' do you mean Win32::GuiTest or X11::GUITest (or
something else)? Win32::GuiTest has a GetComboContents function, *if*
you're talking about a real (Win32) combo box and you can find its hWnd.
If you aren't or you can't you're probably out of luck.
Since you're writing tests for this app, is it reasonable to assume you
can also modify it? If so, you can get the app to write the list to a
file somewhere.
Ben
------------------------------
Date: Sat, 8 Oct 2011 14:54:07 -0700 (PDT)
From: Woland99 <woland99@gmail.com>
Subject: Re: GuiTest - scraping the content of dropdown in Jave app?
Message-Id: <0dc17d39-6168-469c-b365-9b86d4e1f4af@t16g2000yqm.googlegroups.com>
On Oct 8, 3:31=A0pm, Ben Morrow <b...@morrow.me.uk> wrote:
> Quoth Woland99 <wolan...@gmail.com>:
>
> > Hi - I am trying to use Perl to run a simple test scrip on Java app. I
> > need to run same testcase for ALL the items on one of the dropdown
> > controls. Problem is - content of that control ie. item on that
> > dropdown list may change from build to build and there is a LOT of
> > them 50+ so not feasible to simply copy them by hand.
> > Is there any way to use Perl to extract content of such control?
> > I tried GuiTest module - it does ok job in controlling the pp although
> > it does not seem to see any child windows on it - just the main one -
> > of class SunAwtFrame - I can do SenKeys and it is sufficient to run
> > the test but I really need to enumerate results by the content of that
> > control. Perhaps there is another tool better suited for the task of
> > running Java app?
>
> Is the Java app using AWT or Swing? (I presume you're not talking about
> something web-based, which would be much easier to test.) If it's Swing
> you probably can't get at the contents at all: Swing does its own
> drawing, so as far as the OS knows there's nothing there but coloured
> pixels. If it's AWT then I thought AWT used real OS controls, but ICBW.
>
> When you say 'GuiTest' do you mean Win32::GuiTest or X11::GUITest (or
> something else)? Win32::GuiTest has a GetComboContents function, *if*
> you're talking about a real (Win32) combo box and you can find its hWnd.
> If you aren't or you can't you're probably out of luck.
>
> Since you're writing tests for this app, is it reasonable to assume you
> can also modify it? If so, you can get the app to write the list to a
> file somewhere.
>
> Ben
Thanks for reply Ben,
As I said WinSpy sees that Java app as single object of class
SunAwtFrame.
Technically yes I could get access to Java source code but that app
is
written and maintained by entirely diff group in our organization and
that would require going through million hoops.
Yes Win32:GuiTest and I can't seem to get handle to combo box - but
thanks
for that pointer.
JT
------------------------------
Date: Sat, 08 Oct 2011 18:04:18 -0500
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: GuiTest - scraping the content of dropdown in Jave app?
Message-Id: <ao2dnZkDfZVvSw3TnZ2dnUVZ8u-dnZ2d@bt.com>
Quoth Woland99 <woland99@gmail.com>:
> On Oct 8, 3:31 pm, Ben Morrow <b...@morrow.me.uk> wrote:
> > Quoth Woland99 <wolan...@gmail.com>:
> >
> > > Hi - I am trying to use Perl to run a simple test scrip on Java app. I
> >
> > Is the Java app using AWT or Swing? (I presume you're not talking about
> > something web-based, which would be much easier to test.) If it's Swing
> > you probably can't get at the contents at all: Swing does its own
> > drawing, so as far as the OS knows there's nothing there but coloured
> > pixels. If it's AWT then I thought AWT used real OS controls, but ICBW.
> >
> > When you say 'GuiTest' do you mean Win32::GuiTest or X11::GUITest (or
> > something else)? Win32::GuiTest has a GetComboContents function, *if*
> > you're talking about a real (Win32) combo box and you can find its hWnd.
> > If you aren't or you can't you're probably out of luck.
>
> Thanks for reply Ben,
> As I said WinSpy sees that Java app as single object of class
> SunAwtFrame.
If there aren't any OS-level windows there then the app must be using
Swing or something else like it that does its own drawing. In that case
your only real options are either getting the source to the app or
running it against a patched version of javax.swing (or whatever it
actually uses), at which point this becomes definitely not a Perl
problem.
Ben
------------------------------
Date: Sun, 9 Oct 2011 02:04:48 -0700 (PDT)
From: Woland99 <woland99@gmail.com>
Subject: Re: GuiTest - scraping the content of dropdown in Jave app?
Message-Id: <be332057-f90e-4156-bd90-f68231be297f@5g2000yqo.googlegroups.com>
On Oct 8, 6:04=A0pm, Ben Morrow <b...@morrow.me.uk> wrote:
> Quoth Woland99 <wolan...@gmail.com>:
>
>
>
>
>
>
>
>
>
> > On Oct 8, 3:31 pm, Ben Morrow <b...@morrow.me.uk> wrote:
> > > Quoth Woland99 <wolan...@gmail.com>:
>
> > > > Hi - I am trying to use Perl to run a simple test scrip on Java app=
. I
>
> > > Is the Java app using AWT or Swing? (I presume you're not talking abo=
ut
> > > something web-based, which would be much easier to test.) If it's Swi=
ng
> > > you probably can't get at the contents at all: Swing does its own
> > > drawing, so as far as the OS knows there's nothing there but coloured
> > > pixels. If it's AWT then I thought AWT used real OS controls, but ICB=
W.
>
> > > When you say 'GuiTest' do you mean Win32::GuiTest or X11::GUITest (or
> > > something else)? Win32::GuiTest has a GetComboContents function, *if*
> > > you're talking about a real (Win32) combo box and you can find its hW=
nd.
> > > If you aren't or you can't you're probably out of luck.
>
> > Thanks for reply Ben,
> > As I said WinSpy sees that Java app as single object of class
> > SunAwtFrame.
>
> If there aren't any OS-level windows there then the app must be using
> Swing or something else like it that does its own drawing. In that case
> your only real options are either getting the source to the app or
> running it against a patched version of javax.swing (or whatever it
> actually uses), at which point this becomes definitely not a Perl
> problem.
>
> Ben
Hmmm - it will be super ugly but I think I can grab a shot of the app
win every time I make a selection, crop it and run it thru some
freebie OCR (all using GuiTest) - it will be slow but will suffice
until I can connect with that app team and persuade them to change
their code. Thanks, Ben.
------------------------------
Date: Sun, 09 Oct 2011 21:46:51 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: Help me to Improve
Message-Id: <8762jx7v0k.fsf@sapphire.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
[...]
> I see Tad's already mentioned you're using 'our' where you could be
> using 'my'. I would add that there's no need for concatentation when you
> can interpolate, and that you can assign directly to a hash too:
>
> my $APP_HOME = '/usr/local/application';
> my $HTTPRESP = 'httpresp';
> my %LOGFILE = (
> file => "$APP_HOME/$HTTPRESP/logs/generic.log",
> );
>
> (Whether to use single or double quotes when nothing will be
> interpolated is a matter of taste.
Using double-quotes means the compiler has to analyze the string order
to determine if and how something needs to be interpolated into
it. Otherwise, this effort can be avoided and also the effort the next
person who looks at the code needs to come to the same result.
[...]
>> my $confdir = "$APP_HOME/$HTTPRESP/conf";
>> my $pm = new Parallel::ForkManager($MAX_PROC);
>
> It's best to avoid dative method syntax (METHOD OBJECT ARGS or METHOD
> CLASS ARGS), at least in part because it encourages the idea that there
> is something special about the 'new' method.
>
> my $pm = Parallel::ForkManager->new($MAX_PROC);
>
> (Yes, I know you just copied that from the documentation. Unfortunately
> a lot of CPAN documentation uses older, now-discouraged idioms in the
> examples.)
In this particular case, the 'indirect object' syntax is actually even
'discouraged' by the corresponding Perl documentation. More generally,
however, the sentence above parses as "a lot of people who wrote
useful code disagreed with some (or all) opinions
$random_people_on_usenet had regarding what they should have done".
>> my $cnfhs = get_configurations();
>>
>> foreach my $key ( keys %$cnfhs ) {
>>
>> my $conf = $cnfhs->{$key};
>
> You can write that loop as
>
> while (my ($key, $conf) = each %$cnfhs) {
>
> and it'll even be more efficient on really large hashes. (Not enough
> people remember about 'each'.)
Except in case of insanely large hashes (> 500,000 keys, according to
some tests I did a while back), getting the list of keys and
traversing the hash 'open coded' will be faster than calling Perl
subroutine per key. OTOH, the latter should need less memory.
[...]
>> sub get_configurations {
>>
>> my @confs = glob( $confdir . "/*.conf" );
>
> Passing a value into a sub in a file-scoped global is always worth
> avoiding if you can. In this case it's easy: pass it in as a real
> parameter instead.
Doing something because it can be done is just about the most awful
reason for doing it which can be imagined, especially in code where
more or less everything can be done.
> It may seem silly calling get_configurations($confdir) when you know
> perfectly well that get_configurations can see that variable, but it
> rapidly becomes less silly when you come back six months later and take
> it out without remembering some sub half way down the file needed
> it.
It is silly to remove something without checking that it isn't needed
and even more silly to remove something and not even run the changed
file through the compiler before assuming that the change was ok. And
with 'strict', such a change won't go through the compiler.
>
> <snip>
>> sub logger {
>> my $logfilename = shift;
>> $LOGFILE{file} = $logfilename;
>> my $conf = q(
>> log4perl.logger = INFO, FileApp
>> log4perl.appender.FileApp =
>> Log::Log4perl::Appender::File
>> log4perl.appender.FileApp.filename = sub {getLogfilename();}
>
> <...later...>
>> sub getLogfilename {
>>
>> return "$APP_HOME/$HTTPRESP/logs/" . $LOGFILE{file} . ".log";
>>
>> }
>
> It's not really clear to me what you're trying to do here with
> $LOGFILE{file}, but it can almost certainly be done less confusingly.
> Since you don't appear to use it anywhere else, is there any reason not
> to just put the correct filename straight in the log4perl config?
The subroutine above is a specific algorithm with a generic name and
the usual reason for functional decomposition (didn't someboday claim
that was acutally used in practice not that long ago) is that it
simplifies the code at each level abstraction by moving details
which are not relevant for the present algorithm elsewhere.
------------------------------
Date: Sun, 09 Oct 2011 23:15:22 +0200
From: Mart van de Wege <mvdwege@mail.com>
Subject: Re: Help me to Improve
Message-Id: <86r52l989h.fsf@gareth.avalon.lan>
Rainer Weikusat <rweikusat@mssgmbh.com> writes:
> Ben Morrow <ben@morrow.me.uk> writes:
>
>
>>> my $confdir = "$APP_HOME/$HTTPRESP/conf";
>>> my $pm = new Parallel::ForkManager($MAX_PROC);
>>
>> It's best to avoid dative method syntax (METHOD OBJECT ARGS or METHOD
>> CLASS ARGS), at least in part because it encourages the idea that there
>> is something special about the 'new' method.
>>
>> my $pm = Parallel::ForkManager->new($MAX_PROC);
>>
>> (Yes, I know you just copied that from the documentation. Unfortunately
>> a lot of CPAN documentation uses older, now-discouraged idioms in the
>> examples.)
>
> In this particular case, the 'indirect object' syntax is actually even
> 'discouraged' by the corresponding Perl documentation. More generally,
> however, the sentence above parses as "a lot of people who wrote
> useful code disagreed with some (or all) opinions
> $random_people_on_usenet had regarding what they should have done".
>
There are actually good, technical, reasons why the indirect syntax is
being discouraged.
But do not let that stop you from ranting at what you perceive to be
irrational authoritarianism. The rest of us will enjoy our code without
hard to find bugs.
Mart
--
"We will need a longer wall when the revolution comes."
--- AJS, quoting an uncertain source.
------------------------------
Date: Sun, 09 Oct 2011 14:18:07 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Help me to Improve
Message-Id: <4o34971ac7feanj7ka6ibrlmmeag1oj9em@4ax.com>
Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
>Ben Morrow <ben@morrow.me.uk> writes:
>> Passing a value into a sub in a file-scoped global is always worth
>> avoiding if you can. In this case it's easy: pass it in as a real
>> parameter instead.
>
>Doing something because it can be done is just about the most awful
>reason for doing it which can be imagined, especially in code where
>more or less everything can be done.
Are you arguing in favour of or against global variables?
jue
------------------------------
Date: Sun, 09 Oct 2011 16:54:23 -0500
From: Tad McClellan <tadmc@seesig.invalid>
Subject: Re: Help me to Improve
Message-Id: <slrnj9451i.dq9.tadmc@tadbox.sbcglobal.net>
Jürgen Exner <jurgenex@hotmail.com> wrote:
> Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
>>Ben Morrow <ben@morrow.me.uk> writes:
>>> Passing a value into a sub in a file-scoped global is always worth
>>> avoiding if you can. In this case it's easy: pass it in as a real
>>> parameter instead.
>>
>>Doing something because it can be done is just about the most awful
>>reason for doing it which can be imagined, especially in code where
>>more or less everything can be done.
>
> Are you arguing in favour of or against global variables?
I was wondering that too...
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.liamg\100cm.j.dat/"
The above message is a Usenet post.
I don't recall having given anyone permission to use it on a Web site.
------------------------------
Date: Sun, 09 Oct 2011 17:02:46 -0500
From: Tad McClellan <tadmc@seesig.invalid>
Subject: Re: Help me to Improve
Message-Id: <slrnj945h9.dq9.tadmc@tadbox.sbcglobal.net>
Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
> Ben Morrow <ben@morrow.me.uk> writes:
>
> [...]
>
>> I see Tad's already mentioned you're using 'our' where you could be
>> using 'my'. I would add that there's no need for concatentation when you
>> can interpolate, and that you can assign directly to a hash too:
>>
>> my $APP_HOME = '/usr/local/application';
>> my $HTTPRESP = 'httpresp';
>> my %LOGFILE = (
>> file => "$APP_HOME/$HTTPRESP/logs/generic.log",
>> );
>>
>> (Whether to use single or double quotes when nothing will be
>> interpolated is a matter of taste.
>
> Using double-quotes means the compiler has to analyze the string order
> to determine if and how something needs to be interpolated into
> it. Otherwise, this effort can be avoided and also the effort the next
> person who looks at the code needs to come to the same result.
The Moon is blue...
I, errr, agree with Rainer here, more for his second reason
that for his first.
I am always looking to optimize for maintenance.
Using double quotes when nothing is intended to be interpolated
is in _bad_ taste. :-)
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.liamg\100cm.j.dat/"
The above message is a Usenet post.
I don't recall having given anyone permission to use it on a Web site.
------------------------------
Date: Sun, 09 Oct 2011 17:51:33 -0500
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Help me to Improve
Message-Id: <nZOdnQ0guILouA_TnZ2dnUVZ8hCdnZ2d@bt.com>
Quoth Tad McClellan <tadmc@seesig.invalid>:
> Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
> > Ben Morrow <ben@morrow.me.uk> writes:
> >
> > [...]
> >
> >> I see Tad's already mentioned you're using 'our' where you could be
> >> using 'my'. I would add that there's no need for concatentation when you
> >> can interpolate, and that you can assign directly to a hash too:
> >>
> >> my $APP_HOME = '/usr/local/application';
> >> my $HTTPRESP = 'httpresp';
> >> my %LOGFILE = (
> >> file => "$APP_HOME/$HTTPRESP/logs/generic.log",
> >> );
> >>
> >> (Whether to use single or double quotes when nothing will be
> >> interpolated is a matter of taste.
> >
> > Using double-quotes means the compiler has to analyze the string order
> > to determine if and how something needs to be interpolated into
> > it. Otherwise, this effort can be avoided and also the effort the next
> > person who looks at the code needs to come to the same result.
'X is a matter of taste' was supposed to be interpreted as 'I know some
people here disagree with me about X and I don't want to start a boring
thread going over it again'. Oh well.
> I, errr, agree with Rainer here, more for his second reason
> that for his first.
>
> I am always looking to optimize for maintenance.
>
> Using double quotes when nothing is intended to be interpolated
> is in _bad_ taste. :-)
Well, at least I'm not alone:
In message <31836.1270260026@chthon>, <tchrist@perl.com> wrote:
|
| Also, I see you keep using single quotes for strings that don't need them.
| Why? Those aren't really a generic string, you know. They loudly scream
| "DO NOT INTERPOLATE ANYTHING HERE!!!", so I always scrutinize them extra
| hard to try to figure out what it is that you're trying to suppress. Plus
| I hate having to deal with backslash escapes that aren't. Perl strings
| normally interpolate, and it takes something special to suppress that:
|
| $string = $normal ; # interpolate values normally
| $string = "$normal" ; # interpolate values normally
| $string = `$normal` ; # interpolate values normally
| $string = '$abnormal' ; # DON'T INTERPOLATE VALUES!!!
| $string = \$abnormal ; # DON'T INTERPOLATE VALUES!!!
| $string = "\$abnormal" ; # DON'T INTERPOLATE VALUES!!!
|
| $match = /normal/ ; # interpolate values normally
| $match = m(normal) ; # interpolate values normally
| $match = m'abnormal' ; # DON'T INTERPOLATE VALUES!!!
|
| func($x); # interpolate values normally
| func("$x"); # interpolate values normally
| func(`$x`); # interpolate values normally
| func(\$x); # DON'T INTERPOLATE VALUES!!!
| func('$x'); # DON'T INTERPOLATE VALUES!!!
| func(qx'$x'); # DON'T INTERPOLATE VALUES!!!
|
| <<TOKEN # interpolate values normally
| <<"TOKEN" # interpolate values normally
| <<`TOKEN` # interpolate values normally
| <<\TOKEN # DON'T INTERPOLATE VALUES!!!
| <<'TOKEN' # DON'T INTERPOLATE VALUES!!!
|
| Besides being the more normal kind of quote for the more normal kind of
| string operation, double quotes are also much easier to read than are
| single quotes, because they're bigger and easier to see and can't be
| confused with backquotes in a font-dependent manner.
|
| I realize that not everybody shares viewpoints on all these things. That's
| perfectly fine. I also realize that plenty of people do share these views,
| and that deserves to be recognized not extinguished.
Ben
------------------------------
Date: Sun, 09 Oct 2011 16:07:56 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Help me to Improve
Message-Id: <cu9497lhlifrs6irbsl3b96aqcke22b01i@4ax.com>
Ben Morrow <ben@morrow.me.uk> wrote:
>In message <31836.1270260026@chthon>, <tchrist@perl.com> wrote:
>|
>| Also, I see you keep using single quotes for strings that don't need them.
>| Why? Those aren't really a generic string, you know. They loudly scream
>| "DO NOT INTERPOLATE ANYTHING HERE!!!", so I always scrutinize them extra
>| hard to try to figure out what it is that you're trying to suppress. Plus
>| I hate having to deal with backslash escapes that aren't. Perl strings
>| normally interpolate, and it takes something special to suppress that:
>|
>| $string = $normal ; # interpolate values normally
>| $string = "$normal" ; # interpolate values normally
By some definition of normally. This assignment actually stringifies
$normal which most often is not the desired action when dealing with
e.g. numbers. Therefore you could argue if this is the "normal" or
"naively expected" semantic.
>| $string = `$normal` ; # interpolate values normally
>| $string = '$abnormal' ; # DON'T INTERPOLATE VALUES!!!
I like to think of '...' as the literal operator or the literal quotes.
They don't munge their text.
>| $string = \$abnormal ; # DON'T INTERPOLATE VALUES!!!
>| $string = "\$abnormal" ; # DON'T INTERPOLATE VALUES!!!
Actually example does interpolated. It is interpolates \$ as the literal
dollar sign.
etc, etc.
jue
------------------------------
Date: Sun, 09 Oct 2011 19:09:13 -0500
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Help me to Improve
Message-Id: <g7-dndczRKU0qg_TnZ2dnUVZ7oidnZ2d@bt.com>
Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
> Ben Morrow <ben@morrow.me.uk> writes:
>
> > It's best to avoid dative method syntax (METHOD OBJECT ARGS or METHOD
> > CLASS ARGS), at least in part because it encourages the idea that there
> > is something special about the 'new' method.
> >
> > my $pm = Parallel::ForkManager->new($MAX_PROC);
> >
> > (Yes, I know you just copied that from the documentation. Unfortunately
> > a lot of CPAN documentation uses older, now-discouraged idioms in the
> > examples.)
>
> In this particular case, the 'indirect object' syntax is actually even
> 'discouraged' by the corresponding Perl documentation. More generally,
> however, the sentence above parses as "a lot of people who wrote
> useful code disagreed with some (or all) opinions
> $random_people_on_usenet had regarding what they should have done".
I know. I was aware when I wrote that paragraph that I was weaselling
out of properly explaining what's wrong with the dative syntax, and the
reason I was doing that was that I can never remember an example of
where it goes wrong :). I can give you *lots* of examples where Perl
assumes I'm making a dative method call when I didn't want it to, but
that's a reason for not putting it in the language at all, rather than
one for not using it if its there.
I believe the canonical example is
my $rv = method $obj;
with a 'sub method' in the current package. While that is a problem
(since it will parse differently depending on the presence of the sub)
it is easily disambiguated:
my $rv = method $obj ();
So, can anyone remind me of when this actually goes wrong?
> >> my $cnfhs = get_configurations();
> >>
> >> foreach my $key ( keys %$cnfhs ) {
> >>
> >> my $conf = $cnfhs->{$key};
> >
> > You can write that loop as
> >
> > while (my ($key, $conf) = each %$cnfhs) {
> >
> > and it'll even be more efficient on really large hashes. (Not enough
> > people remember about 'each'.)
>
> Except in case of insanely large hashes (> 500,000 keys, according to
> some tests I did a while back), getting the list of keys and
> traversing the hash 'open coded' will be faster than calling Perl
> subroutine per key. OTOH, the latter should need less memory.
Interesting. The efficiency wasn't the point, of course. The point was
to get key and value in one go.
When you say 'calling Perl subroutine per key' do you mean just the call
to 'each'? 'each' isn't a subroutine, of course, but the while loop does
have to run some Perl every iteration rather than just popping the
stack.
> > <snip>
> >> sub logger {
> >> my $logfilename = shift;
> >> $LOGFILE{file} = $logfilename;
> >> my $conf = q(
> >> log4perl.logger = INFO, FileApp
> >> log4perl.appender.FileApp =
> >> Log::Log4perl::Appender::File
> >> log4perl.appender.FileApp.filename = sub {getLogfilename();}
> >
> > <...later...>
> >> sub getLogfilename {
> >>
> >> return "$APP_HOME/$HTTPRESP/logs/" . $LOGFILE{file} . ".log";
> >>
> >> }
> >
> > It's not really clear to me what you're trying to do here with
> > $LOGFILE{file}, but it can almost certainly be done less confusingly.
> > Since you don't appear to use it anywhere else, is there any reason not
> > to just put the correct filename straight in the log4perl config?
>
> The subroutine above is a specific algorithm with a generic name and
> the usual reason for functional decomposition (didn't someboday claim
> that was acutally used in practice not that long ago) is that it
> simplifies the code at each level abstraction by moving details
> which are not relevant for the present algorithm elsewhere.
For there to be any merit to that argument, getLogFilename would have to
be independant of logger. Since logger sets a global read by
getLogFilename, this obviously isn't the case. If you were to rewrite
the code so it looked like
sub logger {
my $logfilename = shift;
my $logpath = getLogFilename($logfilename);
my $conf = qq(
...filename = $logpath
I would consider that a sensible arrangement. You can argue about
whether or not the mapping from basename to full path should be a
separate function: in this case, since it's neither particularly
complicated nor something that can be changed at runtime ISTM better to
put the expression inline, but it makes little difference.
What I was complaining about was the extremely convoluted data path that
went like this:
- stuff a value into (the sole element of) a global;
- create a string containing the Perl code for a sub call;
- pass that string to a method, which will
- parse out the sub call;
- call the sub, which will
- pull the value out of the global;
- interpolate it into a path;
- return that path;
- use the returned value as a log filename.
I was recommending something more like
- interpolate the basename into a path;
- interpolate that path into a config string;
- pass that string to a method, which will
- use it as a log filename.
Whether the first step is a sub call or a direct expression is
irrelevant.
Ben
------------------------------
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 3515
***************************************
