Test::Pod::Snippets -- which turn code in the SYNOPSIS, and potentially elsewhere in the documentation -- into tests.
Dist::Zilla::Plugin::CoalescePod -- merges related .pm and .pod files together when building the dist.
]]>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.
]]>This combines with the fact that hours run from 1–12 instead of 0–11 to mean that AM/PM flip exactly on the noon/midnight boundaries, but each 1–12 block is offset by an hour against that boundary. So AM/PM and 1–12/1–12 are offset against each other… which is silly of course. That gives you another way of remembering though: 12AM follows 11PM while 12PM follows 11AM, which you can memorise as “it’s the stupid way around”.
Or you can also just fix the missing-zero ineptitude of the system by thinking of 12 as a weird way of spelling 0, which makes 0AM midnight ahead of 1AM, and 0PM noon ahead of 1PM, which is pretty logical. So thinking of 12 as 0 but just saying/spelling it 12 is another way of remembering this. (As they say, you know you are a programmer if you start counting at zero.)
But I find both of these more complicated than the “what block is 12:01 in” aid.
It sure is confusing.
]]>I was going to shout “sitemaps!” before I read on and saw you already have that covered. 😊
X-No-Archive
An HTTP application should not be looking at Usenet headers really. If you do want to add support for something then the corresponding standard for that in HTTP is the Robots tag. If you do add support I think it should be an option, though, and probably not the default.
Another thought is that a tool to turn a site static should be able to respect HTTP headers separately from in-content directives, because a downloaded HTML file will still contain whatever <meta name="robots">
tag was inside it but it will almost certainly not be served with the same X-Robots-Tag
header. So external crawlers can still obey the in-content directives but won’t see the originally present out-of-band directives.
I don’t know if anyone needs even the core feature, though, let alone any more complicated elaborations of it. I’d say it depends on whether there is anyone serving both the Plack app being archived by Wallflower and the static archive generated from it by Wallflower. In that case I can imagine it being helpful to rope off some piece of the dynamic app. It’s not how I’d personally use Wallflower though.
]]>my $content = do { local ( *ARGV, $/ ) = [ ... ]; <> };
This differs from the incorrect version by exactly 3 character swaps.
]]>Localized assignment to a
typeglob only localizes the slot being assigned to. The rest of the typeglob remains unlocalized, which means the magic <>
still messes up the global $ARGV
and the global *ARGV{IO}
filehandle.
For example:
sub report_ARGV { use Data::Dump 'pp'; say shift; say ' $ARGV = ', pp $ARGV; say ' @ARGV = ', pp @ARGV; say ' %ARGV = ', pp %ARGV; say ' *ARGV->tell = ', *ARGV->tell; }
report_ARGV('before:'); my $content = do { local ( *ARGV, $/ ) = [ __FILE__ ]; <> }; report_ARGV('after:');
produces:
before: $ARGV = undef @ARGV = () %ARGV = () *ARGV->tell = -1
]]>after: $ARGV = "/tmp/slurp_demo.pl" @ARGV = () %ARGV = () *ARGV->tell = 429
I had to go all the way to
$_ = [ __FILE__ ] for local *ARGV;
to make it work in a single statement. Even something like
*{ \local *ARGV } = [ __FILE__ ];
wouldn’t work, despite the fact that circumfix deref is effectively a do { }
block with a whole separate inner scope (e.g. *{ my $x = 'hi'; local \*ARGV } = [ __FILE__ ]; say $x;
is a strict vars violation).
I don’t think local
is that super-intelligent, which means what’s going on must be something like local
only schedules localisation but that it doesn’t actually happen until the next point at which the temps stack gets cleaned up… or something like that. (I’m not actually a guts hacker, unfortunately. It would help to read the actual implementation of localisation…)
PS: There is of course no point in writing it that way once it becomes that subtle and that much of a mouthful. The two-statement version is simple and obvious.
]]>Perl newbies repository is
https://github.com/yuki-kimoto/perlnewbie/tree/master
You can help me in Github by pull request.
]]>Thank you.
My big problem is that I'm not english native.
My English is not rigth and not natural.
I'm glad for you to check my unnatural English.
But forbidding people to say unpleasant things beforehand is not allowed in the EU. Kicking people out solely because a few non-elected others do not like your expression is not acceptable. But it has been done a few times now. Giving your own interpretation on very sensitive terms as harassment is really wrong.
Event organize MUST mediate when there are problems. As resolution, the MAY kick-out someone for that event. They can be asked in court for their reasons, and will often loose. (That's why you should get an organizers insurance)
Organizers can impose a bit stricter rules when the event is for members of an association, where the rules have passed a vote on the members meeting. We lack all of that in the Perl community, so end-up in horrible fights and a self-elected elite.
]]>TPF should offer a boilerplate set of community guidelines which perl affiliated projects may elect to adopt.
Beyond that, perhaps a mediation service should be offered to assist in resolving complaints. Projects may then wish to opt-in to the outcome of these resolutions.
This is not the first time this has happened, it is however the first time the perl community didnt pile on to someone. That's something *everyone* should think about.
https://blogs.perl.org/users/lets_code_perl/2019/07/tpf-perl-deserves-better-please-do-better.html