[...]
here.]]>
I don't think your version handles the last case with backslash escapes.
]]>*
specially, no. But it supports many other features (wildcards don't match a leading dot, curlies, etc) plus it uses a rather C-like approach to converting the pattern (iterating over single characters, state machine) so it would take more than 10 seconds of looking at it to make any major changes to the algorithm.]]>
@list = 2, 3, 4;
print @list; # 2;
The Unix time number increases by exactly 86,400 each day, regardless of how long the day is.]]>
use Time::Local qw{ timelocal }; $today = timelocal( 0, 0, 0, (localtime)[3 .. 5]);
(from eg/almanac
in the Astro::Coord::ECI distribution).
This algorithm should not be generalized to years far from the current year, because of the way Time::Local interprets the year. I ran into the "far from the current year" issue when a correspondent wanted to use Astro::Coord::ECI to calculate the sunrise at the full moon nearest the summer solstice in 3000 BC. Which goes to show that when you publish software you never know what it will be used for.
]]>Some dev comes along as says "why are we using the old constant
pragma?" So they "fix" the code:
Might I suggest not hiring people who will dis-improve the code by rote rule-following? 😊
But also, if that’s your problem:
use strict; use warnings;
package DEBUG;
sub import {
eval sprintf 'sub %s::DEBUG () { %d } 1', ''.caller, !!$_[1]
or die
}
1;
You can put ample warnings in the POD not to touch that file without talking about it with the dev lead.
This DEBUG.pm
plays the exact same role as Keyword::DEVELOPMENT, except for not needing the keywords API or Keyword::Simple.
If you take the else block off, you will get fewer opcodes with the constant folding.
But how is that relevant to why Keyword::DEVELOPMENT is better? It only offers the equivalent of if (DEBUG) { ... }
without an else
block – a scenario in which both approaches yield the exact same opcodes.
It’s only the else
block that gets the implicit-do{}
treatment. You are complaining about the behaviour of the pure-Perl version for the equivalent of a feature your module doesn’t have in the first place.
I concede it’s not entirely irrelevant insofar as missing features cannot be misused, but it’s still an apples/oranges complaint.
I don't actually know why this is, but there you go. I hope some internals guru will come along and tell me what I'm missing here :)
Write the code with a variable to prevent constant-folding, and leave off the -exec
switch when dumping the optree.
You’ll see that the whole if (...) {...} else {...}
construct compiles to a ternary with two do{}
blocks. But for some reason the one for the else
branch gets to keep its nextstate
op while the one for the if
branch sees its nextstate
op excised.
I don’t know why that difference exists. But my understanding is that the nextstate
is the reason that that block cannot lose the enter
/leave
frame when the other branch is constant-folded away.
(I may have some of this backwards. One side is just a scope
op while the other has an enter
/leave
frame, both of which amount to do{}
, but maybe differently heavy versions. That much is the limit of my guts knowledge.)
DEVELOPMENT
keyword offers.
Consider the following:
DEVELOPMENT {
expensive_debugging_code();
}
else {
log_the_issue();
}
You are correct that this will provide the same opcodes, but it looks wrong and when you can write code where undesired behavior looks wrong, that's awesome. The DEVELOPMENT
keyword is designed to augment behavior, not alter it.
"meta-spec" : {
"url" : "http://search.cpan.org/perldoc?CPAN::Meta::Spec",
"version" : 2
},
META.yml does not have this -- guess it's a version 2 thing. Both ExtUtils::MakeMaker and Module::Build do this. I can't speak for other build tools.
]]>cat /var/log/messages|perl -e 'while (>) {/(\d+\.\d+\.\d+\.\d+)/ && print "$1\n"};'
]]>