It's not clear from your post if the first optimization only applies to variables being tested by and/or operators, would it apply as well to e.g. (x() && y())
(although obviously there would be less gain due to subroutine call overhead), or to more complex forms like (($x || $y) && ($i || j))
?
It can now support something like Exporter.pm's %EXPORT_TAGS, along with numerous other improvements. I also toiled a bit at it with Devel::Cover and it has 100% test coverage now. In the progress of achieving that I found a few minor bugs that I fixed.
In implementing this module I tried to avoid adding narrow specific features (like %ENV overrides, or support for %EXPORT_TAGS), and instead added more general callbacks that make those features and others I haven't even thought of yet possible.
For why I needed to write the umpteenth constant creation module on the CPAN instead of using something that already exists see the rationale in the documentation.
This module's already been stable for a while and I see no reason why I'd introduce any breaking changes to it. If you'd like an easy-to-use constant defining module that you can use in multiple mutually incompatible environments give it a shot.
]]>Here's an E-Mail that was sent to Hinrik:
I want to buy a Marklov pluggable engine, Where can i buy one, i am coming to
Iceland for a visit, can i come to your shop?
And, in another E-Mail sent to me:
Hi,
I would like to buy a Hailo. Where can i get one and how much do they cost?
Thanks Julie
Clearly I should quit my dayjob and start selling copies of Hailo on CD in a dedicated store just for this purpose.
More seriously though, is anyone else getting similar spam these days about their CPAN distros? It seems odd to get a couple of these E-Mails within a few days.
We did have someone contact us a couple of years ago legitimately wanting to buy a license for of Hailo. It took quite a long E-Mail exchange to convince that person that yes, we were in fact giving it away for free.
]]>On any given day I'll spend some time sitting down and some time standing up, alternating how much time I spend on either one, some days I'm almost entirely sitting, and some days it's the opposite.
I'd really recommend it.
]]>Moose will simple die if you pass it a value that violates a type constraint, in an environment where you control the whole stack this is usually what you want, but when you're dealing with data from other people and user-supplied parameters you often want to handle the situation more gracefully.
Curtis pointed this out on the Moose mailing list, and quickly found that this was something covered in the Moose FAQ.
I hacked up something that would change the behavior globally, but of course this is something you want to do on a per-attribute level. Jesse Luehrs provided a basic implementation of it which I expanded on, and which I've now uploaded to the CPAN as MooseX::Attribute::TypeConstraint::CustomizeFatal
The module allows you to tweak what Moose does when a type constraint fails on a per-attribute level. The default is to die as Moose does by default, but you can also make it warn and accept the bad value, or warn and fall back on the default value, or just silently ignore the bad value and fall back on the default value.
]]>$ perl -MDevel::Peek -wle 'Dump $_ for .96, 0.96'
SV = NV(0x100817408) at 0x100811318
REFCNT = 2
FLAGS = (NOK,READONLY,pNOK)
NV = 0.96
SV = NV(0x100817400) at 0x100811330
REFCNT = 2
FLAGS = (NOK,READONLY,pNOK)
NV = 0.96
]]>
S_tokenize_use()
and S_force_version()
in toke.c. They do their own manual numeric parsing.
]]>
You can see that this is what's going on with these simple test programs:
$ perl -wle 'package Test; sub VERSION { warn "version: @_" } sub import { warn "import: @_" } use Test 10'
version: Test 10 at -e line 1.
import: Test at -e line 1.
$ perl -wle 'package Test; sub VERSION { warn "version: @_" } sub import { warn "import: @_" } use Test 010'
version: Test 8 at -e line 1.
import: Test at -e line 1.
$ perl -wle 'package Test; sub VERSION { warn "version: @_" } sub import { warn "import: @_" } use Test 0.10'
version: Test 0.1 at -e line 1.
import: Test at -e line 1.
$ perl -wle 'package Test; sub VERSION { warn "version: @_" } sub import { warn "import: @_" } use Test .10'
import: Test 0.1 at -e line 1.
Once the parser has decided that it's a version number it'll get eaten and passed to VERSION, and the rest, if any, will go to import.
But if it doesn't decide that it'll die for the same reason that:
use Test "foo" "bar";
dies, i.e. you have to supply a comma if you're supplying a list of two items where the first isn't a version number.
But yes, arguably this is a bug and the "use" statement should be accepting any number that you could pass to Test->VERSION(). This should at least be documented.
]]>So I wrote a short one-off script to find out what words I cound construct from the flags.
Now it just gives you one word that contains as many of the flags as possible, and gives you the remainder. What would be more interesting would be to detect cases where multiple valid words can be made from the flags. E.g. "mix" and "uploads". It just detected that by accident.
I leave that as an exercise for the reader.
]]>M-x which-function-mode
Which you can automatically load with a mode hook. It'll work with any programming mode that supports Imenu. Which is almost all of them.
]]>git push [options] <repository> <refspec>
E.g. you can do:
git checkout some-branch git push origin some-other-branch:yet-another-name
To push your local some-other-branch
to origin
's yet-another-name
branch even though your working copy has some-branch
checked out.
But if you supply an *empty* source at the left-hand side of the ":
" you'll push an empty refspec to an existing remote branch, so you'll delete it.