Henk P. Penning wrote:
> -- add a javascript function "hostedby()"
> -- add an empty in the "footer_mirror" section
I certainly approve of only showing the logo to people who run JavaScript.
-zefram
James E Keenan wrote:
>Would anyone know of any prior art for detection of "short edit distances"?
>(Perhaps even already on CPAN?)
Text::Levenshtein.
-zefram
t been installed into blib/lib, with the
build step being broken by the same thing that broke the MANIFEST check.
>Do you know what could have caused this?
I'm mystified as to how that could happen. Need to poke around an
example of it to debug further.
-zefram
James E Keenan wrote:
That leaves only the problem of capturing STDOUT
close(STDOUT);
open(STDOUT, , \$captured_stdout);
-zefram
in those cases. It incidentally leaves *STDOUT{IO}
empty, so that an explicit close is no longer required before the reopen.
-zefram
(mangle) these names for case-incapable filesystems
is a bug. We should not pander to that bug; we should fix it.
-zefram
point
INST_FILE
/home/zefram/usr/perl/perl_install/perl-5.14.2-i32-f52/lib/5.14.2/integer.pm
INST_VERSION 1.00
cpan[3] m INTEGER
Module id = INTEGER
CPAN_USERID SHERZODR (Sherzod Ruzmetov sherz...@cpan.org)
CPAN_VERSION 1.93
CPAN_FILES/SH/SHERZODR/Class-PObject-2.17
to the strict
syntax that has been carefully worked out for version.pm. The meta
spec should continue to conform to the strict syntax unless there's an
overwhelmingly good reason to deviate from it.
-zefram
David Golden wrote:
Right now, the draft says an identifier and that
term could be defined further.
I take identifier, without further explanation, to mean
/[A-Za-z_][0-9A-Za-z_]*/. Not anything involving \w, note.
-zefram
.
I know for a fact that in Finnish law an author cannot
give away his rights, and the same applies in other European countries.
So public domain isn't necessarily even a null license.
-zefram
of another distro in the normal
manner.
-zefram
.
-zefram
. Possibly the DLSI items also should be, as individual items
encoded in the META style. (D has already been proposed.) Then one
could generate the DLSIP code from the META file, if really desired.
-zefram
its own namespace for modules. We should also
have a way to specify language as part of a dependency name, to manage
cross-language dependencies. Doing those suggests that language could
be consistently stated in META as part of the module name, rather than
needing a separate field.
-zefram
of Perl syntax already
defined. I needed to implement it a while ago for work purposes, and now
it's on CPAN, as Data::Pond. It's similar in spirit to JSON, which of
course gives the same kind of parsing choice for the JavaScript language.
-zefram
testing really is
a distinct job from building. Consumers of META information should be
expected to merge phase-specific requirements in whatever way is suitable
for their workflow; we can't reliably predict what that workflow will be.
-zefram
. The META file is completely the wrong place
for this sort of information.
-zefram
, so we could sensibly list
them in META in a formal manner. CPAN installation tools should learn to
track this sort of dependency and plug into the OS's packaging mechanism.
-zefram
.
-zefram
once then
the dependencies that an install tool must gather for one of the phases
would have to implicitly include all the dependencies listed for the
other phase. It would grossly compromise the separation of phases.
-zefram
, in those cases that are adequately described
by a widely-used license. In the unusual cases where no defined keyword
suffices, machine readability (beyond recognising that this is the case)
is a lot less important.
-zefram
21 matches
Mail list logo
