I was having a look at CPANTS again this morning, and I noticed
something rather strange.
There are now two kwalitee tests for 'has_test_pod' and
'has_test_pod_coverage'. These check that there are test scripts for
POD correctness and POD coverage.
These seem completely and utterly wrong to me.
This fixes installing to a different DESTDIR.
Index: Makefile.PL
===
--- Makefile.PL (revision 1233)
+++ Makefile.PL (working copy)
@@ -105,10 +105,10 @@
pure_site_install ::
\$(NOECHO) \$(MOD_INSTALL) \\
-
Rafael Garcia-Suarez writes:
This fixes installing to a different DESTDIR.
Thanks, applied.
Luke
Index: Makefile.PL
===
--- Makefile.PL (revision 1233)
+++ Makefile.PL (working copy)
@@ -105,10 +105,10 @@
William Coleda [EMAIL PROTECTED] wrote:
When invoking a PIR-defined object from C, what's the proper call?
pmc_new ? (Does that handle class_init) ?
I don't understand the question. Do you want to instantiate an object?
If yes, just do the same as the respective opcodes are doing:
cl =
This one fixes make test, by forcing the fix of test target of the
generated Makefile. I'd rather have Ingy reviewing it or something,
because AFAICT it's his territory -- dark makemaker places where black
magic hides behind obscure curtains. (make install still works and
still installs everything
Rafael Garcia-Suarez writes:
This one fixes make test, by forcing the fix of test target of the
generated Makefile. I'd rather have Ingy reviewing it or something,
because AFAICT it's his territory -- dark makemaker places where black
magic hides behind obscure curtains. (make install still
1) the PASM and PIR assemblers are now extended to understand arbitrary
PMC constants:
.const .Integer P0 = 42 # PASM
.const .Integer i = 42# PIR
.const Integer i = 42# PIR
Caveat: don't use this yet, the PMC constants vanish after the first GC
sweep. See below.
The
These seem completely and utterly wrong to me. Surely the kwalitee
checks should be purely that the POD is correct and sufficiently covers
the module?
Especially because pod.t and pod-coverage.t don't need to actually get
distributed with the module. Perhaps I keep pod*.t in my Subversion
I've been experimenting with dynamic linkage on Windows. As a teaser
to read on, here's how far I've got.
Before
Failed TestStat Wstat Total Fail Failed List of Failed
---
t\dynclass\foo.t 1
I'm glad to report that I managed to release 6.0.13 during
YAPC::Taipei, several minutes before my Perl 6 the Ultimate Talk,
which was quite successful. :-)
You can download 6.0.13 from:
http://search.cpan.org/dist/Perl6-Pugs/
I've forgotten to include t/README in the MANIFEST, but you can
I've been following the progress of pugs in awe of the speed of the
progress, the breadth of the scope and the exemplary way in which
Autrijus has run the project. And I've been considering how best I
could contribute.
One of the many aspects of the project that is to be admired is the test
I just did a CVS update (the first in a while, with all necessary
options present, btw), and got some dynamic loading failures, e.g.:
[EMAIL PROTECTED] perl -Ilib t/dynclass/foo.t
1..1
not ok 1 - abs
# Failed test (t/dynclass/foo.t at line 21)
# got: 'Couldn't
# New Ticket Created by Peter Sinnott
# Please include the string: [perl #34586]
# in the subject line of all future correspondence about this issue.
# URL: https://rt.perl.org/rt3/Ticket/Display.html?id=34586
patch #34564 dropped the $ in the parent sorting in gen_parent_list
this patch
# New Ticket Created by chromatic
# Please include the string: [perl #34587]
# in the subject line of all future correspondence about this issue.
# URL: https://rt.perl.org/rt3/Ticket/Display.html?id=34587
---
osname= linux
osvers= 2.4.24-benh0
arch= powerpc-linux
cc= gcc 3.4.3
I've been writing a Lisp implementation on top of Parrot for the last
several months (and I'm just about at the point where I'm ready to unleash
it upon the world). I seem to have run up against some issues which
*appear* to be related to the garbage collector collecting objects that
aren't
On Sun, 2005-03-27 at 12:25 -0800, Peter Sinnott wrote:
patch #34564 dropped the $ in the parent sorting in gen_parent_list
this patch restores it
Good catch.
Thanks, applied.
-- c
Randy W. Sims wrote:
There is my unpublished CPAN::Metadata at:
svn co http://svn.versiondude.net/randys/CPAN-Metadata/trunk/ CPAN-Metadata
It reads, writes, and validates metadata according to the spec. It still
needs a bit of work, and updates to the actual spec need to be
formalized before it
On Sun, Mar 27, 2005 at 08:32:59PM -0500, Christopher H. Laco wrote:
Along the lines of converting to Module::Build...it went well until I
started doing tests...things that worked now break, probably do to how
they're now run...
t\xsp.Use of uninitialized value in
Michael G Schwern wrote:
On Sun, Mar 27, 2005 at 08:32:59PM -0500, Christopher H. Laco wrote:
Along the lines of converting to Module::Build...it went well until I
started doing tests...things that worked now break, probably do to how
they're now run...
t\xsp.Use of uninitialized
Leo~
On Sun, 27 Mar 2005 16:37:41 +0200, Leopold Toetsch [EMAIL PROTECTED] wrote:
5) infix method signature change:
METHOD PMC* add( [INTERP, SELF,] PMC* rhs, PMC ยด*dest) {
if (!dest)
dest = pmc_new(INTERP, SELF-vtable-base_type);
...
return dest;
}
If
From: Leopold Toetsch [EMAIL PROTECTED]
Date: Sun, 27 Mar 2005 16:37:41 +0200
1) Mixed infix operations
Opcodes that take one PMC and one native type argument, like:
op add(in PMC, in PMC, in INT)
should probably become plain vtable methods again. There isn't much
These seem completely and utterly wrong to me. Surely the kwalitee
checks should be purely that the POD is correct and sufficiently covers
the module?
One problem I can see with this is that (I think) the only way to
indicate extra private methods is to do so in pod-coverage.t. For
instance:
22 matches
Mail list logo
