[32251] in Perl-Users-Digest
Perl-Users Digest, Issue: 3518 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Oct 12 09:09:25 2011
Date: Wed, 12 Oct 2011 06:09:05 -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 Wed, 12 Oct 2011 Volume: 11 Number: 3518
Today's topics:
Re: Help me to Improve <rweikusat@mssgmbh.com>
Re: Help me to Improve <ben@morrow.me.uk>
Re: Help me to Improve <rweikusat@mssgmbh.com>
Re: The Concepts and Confusions of Prefix, Infix, Postf dihedral88888@googlemail.com
Re: Tricky STDERR issue under windows <ben@morrow.me.uk>
Re: Tricky STDERR issue under windows <bjoern@hoehrmann.de>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 11 Oct 2011 14:09:48 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: Help me to Improve
Message-Id: <87sjmz3c9v.fsf@sapphire.mobileactivedefense.com>
xhoster@gmail.com writes:
> Tad McClellan <tadmc@seesig.invalid> wrote:
>> 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.
>
> Sure, but who cares?
I assume that you got this wrong by accident. It should have been
"Sure, but I don't care". Why precisely you consider this to be
noteworthy enough to post it escapes me, however.
>> > 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.
>
> Why would the person need to do that?
In order to determine what will become of the string.
> I find it more common that I need to interpolate where I (or
> someone) didn't before, and now I have to inspect
> the whole string to find out what it was that motivated the person to make
> it a single quote rather than double in the first place, only to find out
> there was no reason for it.
But there was a reason for it, this reason being given above. And if
you need to change the string, you'll have to inspect it anyway, in
[...]
>> I, errr, agree with Rainer here, more for his second reason
>> that for his first.
>>
>> I am always looking to optimize for maintenance.
>
> Using single quotes because the content does not *currently* require
> interpolation is not optimizing for maintenance. Optimizing for
> maintenance would require you to predict how the usage is likely to change
> in the future, and using whatever style of quotes is less likely to need to
> change under that theory of the future.
If 'optimizing for maintenance' requires 'predicting the future' then
it can't be done because the future can't be predicted.
------------------------------
Date: Tue, 11 Oct 2011 09:13:41 -0500
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Help me to Improve
Message-Id: <mYednWkKUtOI0gnTnZ2dnUVZ8hadnZ2d@bt.com>
Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
> xhoster@gmail.com writes:
> > Tad McClellan <tadmc@seesig.invalid> wrote:
> >> Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
> >> >
> >> > Using double-quotes means the compiler has to analyze the string order
> >> > to determine if and how something needs to be interpolated into
> >> > it.
> >
> > Sure, but who cares?
>
> I assume that you got this wrong by accident. It should have been
> "Sure, but I don't care". Why precisely you consider this to be
> noteworthy enough to post it escapes me, however.
No, it should've been 'No, it doesn't'. When the compiler is scanning a
q// string, it runs along looking for a \ or a final delimiter. When
it's scanning a qq// string, it does exactly the same thing, looking for
$ or @ as well. In particular, it does *not* pull out the whole string
up to the closing delimiter and then rescan it looking for
interpolations: as far as the compiler is concerned, a string like
"foo $bar"
ends at the '$'.
In any case, the difference is almost certainly unmeasurable, so it
doesn't matter.
> >> > 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.
> >
> > Why would the person need to do that?
>
> In order to determine what will become of the string.
Under normal circumstances, if I see something looking like $foo it
represents a variable. The only exceptions are inside a single-quoted
string, and \-escaped inside a double-quoted string. \-escaping is so
universal I don't have to think about it any more, so the case which
trips me up is a (non-\-escaped) $foo inside a single-quoted string.
> But there was a reason for it, this reason being given above. And if
> you need to change the string, you'll have to inspect it anyway, in
[snip]
>
> If 'optimizing for maintenance' requires 'predicting the future' then
> it can't be done because the future can't be predicted.
You really don't understand about maintainable programming, do you? Yes,
it requires predicting the future. It's not that hard to do, in a
general sort of way, especially if you have a nice set of 'do it this
way if you can' rules to follow. (You can predict the future by
predicting you'll keep following those rules.)
Ben
------------------------------
Date: Tue, 11 Oct 2011 22:30:44 +0100
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: Help me to Improve
Message-Id: <878vor2p2z.fsf@sapphire.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
>> xhoster@gmail.com writes:
>> > Tad McClellan <tadmc@seesig.invalid> wrote:
>> >> Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
>> >> >
>> >> > Using double-quotes means the compiler has to analyze the string order
>> >> > to determine if and how something needs to be interpolated into
>> >> > it.
>> >
>> > Sure, but who cares?
>>
>> I assume that you got this wrong by accident. It should have been
>> "Sure, but I don't care". Why precisely you consider this to be
>> noteworthy enough to post it escapes me, however.
>
> No, it should've been 'No, it doesn't'.
That's not possible, given that the compiler needs to determine what
needs to be interpolated into which locations of the string.
> When the compiler is scanning a
> q// string, it runs along looking for a \ or a final delimiter. When
> it's scanning a qq// string, it does exactly the same thing, looking for
> $ or @ as well. In particular, it does *not* pull out the whole string
> up to the closing delimiter and then rescan it looking for
> interpolations:
Nobody except you wrote that. And - of course - that's exactly what
perl is doing, judgeing from a rather cursory look at toke.c: First,
a 'string token' is created by calling scan_str, then, the string
created in this way is scanned for 'characters requiring special
processing' and if one is found, the 'op' which is being created is
changed from OP_CONST to OP_STRINGIFY, cf
case '"':
s = scan_str(s,!!PL_madskills,FALSE);
DEBUG_T( { printbuf("### Saw string before %s\n", s); } );
if (PL_expect == XOPERATOR) {
if (PL_lex_formbrack && PL_lex_brackets == PL_lex_formbrack) {
PL_expect = XTERM;
deprecate_old(commaless_variable_list);
return REPORT(','); /* grandfather non-comma-format format */
}
else
no_op("String",s);
}
if (!s)
missingterm(NULL);
pl_yylval.ival = OP_CONST;
/* FIXME. I think that this can be const if char *d is replaced by
more localised variables. */
for (d = SvPV(PL_lex_stuff, len); len; len--, d++) {
if (*d == '$' || *d == '@' || *d == '\\' || !UTF8_IS_INVARIANT((U8)*d)) {
pl_yylval.ival = OP_STRINGIFY;
break;
}
}
TERM(sublex_start());
[Perl_yylex, toke.c]
[...]
> In any case, the difference is almost certainly unmeasurable, so it
> doesn't matter.
That should probably also been "I don't care about that" instead of
"it doesn't matter". Also, the difference is measurable using
sufficiently long strings. Eg, on the computer where I tested this
(3.2Ghz Intel i3), creating a subroutine returning a string of 8192 As
with that string being "-quoted is about 1.4 times slower than
when string is '-quoted. Granted, that's a contrived example and the
absolute numbers are really low (4.75E-5s vs 3.37E-5s for a single
invocation of the function, IOW, the per-character cost is in the
nanosecond range).
>> >> > 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.
>> >
>> > Why would the person need to do that?
>>
>> In order to determine what will become of the string.
>
> Under normal circumstances, if I see something looking like $foo it
> represents a variable. The only exceptions are inside a single-quoted
> string, and \-escaped inside a double-quoted string. \-escaping is so
> universal I don't have to think about it any more, so the case which
> trips me up is a (non-\-escaped) $foo inside a single-quoted string.
The common way to read a (n English) text is to start at the top and
read each line from left to right until the bottom has been
reached and using shortcuts based on assumptions regarding what the
content of the text will be is bound to lead to misunderstandings.
>> But there was a reason for it, this reason being given above. And if
>> you need to change the string, you'll have to inspect it anyway, in
> [snip]
>>
>> If 'optimizing for maintenance' requires 'predicting the future' then
>> it can't be done because the future can't be predicted.
>
> You really don't understand about maintainable programming, do you? Yes,
> it requires predicting the future.
If it requires predicting the future than it can't be done. This is
nothing to do with conjectures about my understanding of anything but
is a fact: The future can't be predicted.
------------------------------
Date: Tue, 11 Oct 2011 14:35:14 -0700 (PDT)
From: dihedral88888@googlemail.com
Subject: Re: The Concepts and Confusions of Prefix, Infix, Postfix and Fully Functional Notations
Message-Id: <18603505.27.1318368915102.JavaMail.geo-discussion-forums@prng5>
Please stick to programming issues, techniques, tricks and experiences in using various programming languages.
------------------------------
Date: Tue, 11 Oct 2011 07:00:55 -0500
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Tricky STDERR issue under windows
Message-Id: <Oq-dnSRnSYxqsgnTnZ2dnUVZ8qqdnZ2d@bt.com>
Quoth comp.lang.perl.misc@googlegroups.com:
> I seem to have hit a rather tricky issue with STDERR redirection and
> libraries used via XS and wonder if anybody has any ideas.
>
> I have an XS module which uses an external library. This library uses
> stdio, not PerlIO and can't be changed. I need to capture STDERR that
> this library outputs. This can't be done using PerlIO tricks like
> opening to an in memory scalar I realise. On non-windows, I can redirect
> STDERR to a file and read it in later when the library calls are
> finished. This works fine. On windows, it doesn't work because
> apparently, as soon as you re-open STDERR to a file, it decouples the
> library STDERR from perl's STDERR and the library continues to write to
> its own STDERR and it seems impossible to capture it.
You probably want to call SetStdHandle
http://msdn.microsoft.com/en-us/library/ms686244%28v=VS.85%29.aspx . It
has been added to recent versions of Win32API::File (0.1200) but oddly
seems not to be documented... I assume that's just an oversight.
Ben
------------------------------
Date: Tue, 11 Oct 2011 14:07:53 +0200
From: Bjoern Hoehrmann <bjoern@hoehrmann.de>
Subject: Re: Tricky STDERR issue under windows
Message-Id: <7lb8971a4ri1p0je7m0e0ciaqr31dmgl09@hive.bjoern.hoehrmann.de>
* philkime@kime.org.uk wrote in comp.lang.perl.misc:
>I have an XS module which uses an external library. This library uses
>stdio, not PerlIO and can't be changed. I need to capture STDERR that
>this library outputs. This can't be done using PerlIO tricks like
>opening to an in memory scalar I realise. On non-windows, I can redirect
>STDERR to a file and read it in later when the library calls are
>finished. This works fine. On windows, it doesn't work because
>apparently, as soon as you re-open STDERR to a file, it decouples the
>library STDERR from perl's STDERR and the library continues to write to
>its own STDERR and it seems impossible to capture it.
As I recall it, file handles are valid only within the same runtime. If
you are using MSVC++ and Perl was linked to one library and your XS code
to another one then they will have trouble exchanging file descriptors.
Using multiple processes would probably allow you to let cmd.exe do the
redirecting, have you tried that, redirecting via `perl example 2> err`?
--
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
------------------------------
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 3518
***************************************
