Phalanx / CPANTS / Kwalitee
Hi!
CPANTS and Phalanx both care about Kwalitee. So I thought it might be a good
idea to come up with one more or less complete list of Kwalitee-hints that
both projects can use.
A lot of the hints listed at http://qa.perl.org/phalanx/kwalitee.html are
rather vague, which is OK for Phalanx, as it is run by humans.
But CPANTS needs a hard, computable list of hints.
Anyway, here is what the dev-version of CPANTS currently cosiders as
kwalitee-hints:
* distname includes version
* extracts nicely
* does not include symlinks (which some OS cannot handle)
* no strange permissions (files undeleteable by owner, eg)
* contains files:
* Makefile.PL or Build.PL or configure
* README
* MANIFEST
* t/* or test.pl
* one *.pm in top-level OR lib/
Hints that were in Leon's last release, but which I didn't port up to now:
* POD errors
* POD/Code ratio (what would be a good measurement?)
* testers results
* number of releases
Some ideas:
* wheater PREREQ_PM matches used modules (hard!)
* AUTHOR != 'R.U. Thor'
* Description
* ratings
* a lot of code analysis (to be done without running the code!!)
Obviously, this list is far from complete, which is why I request some
feedback on more hints for Kwalitee from all of you!
--
#!/usr/bin/perl http://domm.zsi.at
for(ref bless{},just'another'perl'hacker){s-:+-$-gprint$_.$/}
Re: cvs commit: parrot/io io.c io_buf.c
Melvin Smith [EMAIL PROTECTED] writes: Did you consider using the method interface in ParrotIO? That ought to be even extensible with user code. Yes, I'm trying to get back up to speed on everything. The method interface is a new feature that I need to look at. I've written a first cut on the method interface in parrotio.pmc. The system is fairly simple: At class_init time the methods are registred in a hash and the find_method function looks up this hash and returns a invoke-able PMC (a NCI). See t/pmc/io.t for example. bye boe -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: An evil task for the interested
Jeff Clites [EMAIL PROTECTED] wrote: On Oct 9, 2003, at 8:43 AM, Dan Sugalski wrote: ... Not a huge task, we just need to order PMCs before destroying them, ..., but there isn't a way to ask a mark() method to set another flag. This leaves me stuck with regard to PMCs with custom mark methods (but it's working for the other PMC flavors of referring). This sounds exactly as it needs the general PMC traverse/iterator too, discussed in the thread [RfC] vtable-dump. ,--[ /me ]--- | So I'm speaking of a framework, which calls a vtable-traverse() method | that calls vtable methods (freeze, clone, dump, or whatever) on SELF | and then puts aggregate items (if any) on a TODO list. This | functionality is IMHO that of an iterator. This does address stack | blowing and self-referential structures. ` Using mark() for everything doesn't work as soon as Luke Palmers scheme Subject: PATCH] Re: Timely Destruction: An efficient, complete solution is merged (BTW where are the benchmarks). So, I wanted to see if I'm missing something obvious, or if we need for mark() to take a parameter to indicate the flag to set. An extra parameter (and check in pobject_lives) would slow down DOD, so rather not. Thoughts? Yep: vtable-traverse() JEff leo
Re: [off-list] Re: LANGUAGES.STATUS also for languages not in the tree?
Dan Sugalski [EMAIL PROTECTED] writes: On Wed, 8 Oct 2003, Luke Palmer wrote: Luke Palmer writes: Hi Jos, Jos Visser writes: Mightn't it be (is this English by the way? :-) a good idea to use LANGUAGES.STATUS also for maintaining track of parrot-generating compilers that are not in the main tree? Yeah, that's English. Mightn't is an archaic word which is sometimes fun to use. Saying it be is using the subjunctive mood in to be, also seldom used, but you use it correctly here. I just learned about the English subjunctive a little while ago; it has greatly improved my understanding of those wierd constructs involving might and lest. There it goes again! That was *supposed* to be off-list! Well, now the entirety of the internals list can learn about English grammar. Hoo-ray. You mean American Grammar. I'm pretty sure it's not at all archaic English Grammar It certainly isn't round our way. It mightn't be quite The Queen's English, but you can fix that by simply expanding the contraction to might not. Americans don't do shall/will do they?
x86 JIT and GCC 3.3 don't play well together
To the point of failing near-every test. GCC 2.95, on the other hand, seems quite happy with it. (details at http://tinderbox.perl.org) Could someone take a look at things and see what's going on please? Dan
Re: An evil task for the interested
Jeff Clites [EMAIL PROTECTED] writes: On Oct 9, 2003, at 8:43 AM, Dan Sugalski wrote: We've got ordered destruction on the big list 'o things to do, and it looks like we need to get that done sooner rather than later. ... Not a huge task, we just need to order PMCs before destroying them, to make sure we don't call the destructor for a PMC before we destroy the things that depend on it. A quick run through the PMC pools to build up a dependency chain if there's more than one PMC that needs destruction should do it. I have a partial implementation of this now. (Need to clean it up before submitting it.) There are a couple of thorny points that may need some discussion, but I'll start with the sharpest thorn: For PMCs with a custom mark method, the idea is that it's opaque exactly what other object they have references to, right? (That is, the PMC knows how to mark them alive, but doesn't reveal what they are, right?) Right. There are ways to find out which PMCs are actually marked but that is digging in the deep internals of the DOD-System. After a call to vtable-mark the list interpreter-mark_ptr/pmc-next_for contains the objects which are marked. With some hacks that create a new list before the next call to vtable-mark it might be possible to get a list of children. But I don't suggest to go this way. I'm asking because my approach is to collect the list of PMCs which need their destroys called, and trace through this set (like a DOD run) to see which ones are referred to by others on the list (and more importantly, which ones are not), destroy() those that are unreferenced and take them off the list (or do this to an arbitrary one if none are unreferenced), and repeat until done. You might need to iterate quite often with this approach. The worst case scenario is destroying a linked list. You iterate the list, find out which is the head, destroy it and search the list again for the new head. But you can, while generating the list of PMCs which need destruction enforce that this list is ordered. If you know nothing about the object already append it to the front of the list, if you know that it must destroyed after an object which is already on list enter it after the list. If the tree is walked depth first you get a list which is in the right order for destruction. The destruction is then just iterating a list and calling the functions. But I did not figure out a way to do the depth-first tree-walking without massive recursion. This works out fine, but I don't think I can use the PObj_live_FLAG for this marking or it will mess up the subsequent work in free_unused_pobjects(), but there isn't a way to ask a mark() method to set another flag. This leaves me stuck with regard to PMCs with custom mark methods (but it's working for the other PMC flavors of referring). So, I wanted to see if I'm missing something obvious, or if we need for mark() to take a parameter to indicate the flag to set. We need a general tree-walk vtable. This is needed for dump, freeze and more things. Leo suggested something like that in the thread [RfC] vtable-dump. One way to implement this is a generalization of the mark-function. I don't like the idea of generalizing the mark function: mark is called very often and should be as fast as possible. I think we should have one mark function which is very tight coupled to the gc-system and one general iterator function. (For a second I was about to decide that I could re-use PObj_live_FLAG, since by definition it will be unset for objects we are going to destroy(), thinking that I just need to be sure to clear the flag again before getting to the rest of free_unused_pobjects(), but since there's no unmark() method I'm again stuck, since my tracing could inadvertently appear to bring things back to life. Though I suppose a subsequent DOD run would get them) Resurrection of objects is opening a can of worms. Do we really want to go into this. It might be a nice feature, but it is worse the trouble. bye boe -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: [perl #24185] [PATCH] JIT debugging on AIX
On Fri, 10 Oct 2003, Adam Thomason wrote: Here's the beginning of support for debugging the JIT core with the native compiler on AIX. This patch implements a replacement for jit_debug.c that emits XCOFF-compatible stabs in order to placate the AIX assembler. It's not quite ready for merging; I'm posting it in the hope that somebody might have some insights on how to make the debugger cooperate. I'm fairly certain I'm assembling the stabs object correctly since they all show up in the symbol table of the assembled object, but at the moment gdb seems unwilling to import those symbols using add-symbol-file (i.e., it won't let me step into jit_func). On the other hand, GNU 'objdump -g' doesn't see them either, so the XCOFF stabs support in the GNU tools may just be lacking, in which case I'll have to fall back to the native debugger. If anybody could offer suggestions on how to make gdb or dbx behave (or any other advice on PPC JIT debugging), I'd be very appreciative. I'm applying this -- I'm assuming that it'll get more attention if more people can get at it, and it doesn't seem to affect the current JIT. (Hard to say, as it's crashing on me, but we'll see on the next tinder run :) Dan
Re: FreeBSD (4.8) can't build imcc
the top level Makefile has this rule to build the object files in
languages/imcc:
$(IMCC_DIR)/%.o : $(IMCC_DIR)/%.c
$(PERL) tools/dev/cc_flags.pl ./CFLAGS $(CC) -I$(IMCC_DIR) $(CFLAGS) -o
$@ -c $
the build fails at imcparser.o for me (the first object file)
[skipping]
Having a grovel around the FreeBSD make and GNU make documentation
suggests
that $(IMCC_DIR)/%.o : $(IMCC_DIR)/%.c is a GNU make pattern rule, and
means nothing to FreeBSD. However, I'm not convinced that that rule is
even necessary, as IIRC the C compiler should be looking for include files
in the same directory as the source.
[skipping]
I propose replace
@$(PERL) tools/dev/cc_flags.pl ./CFLAGS $(CC) $(CFLAGS) ${cc_o_out}$@ -c $
by
@$(PERL) tools/dev/cc_flags.pl ./CFLAGS $(CC) $(CFLAGS) -I$(@D)
${cc_o_out}$@ -c $
and remove
$(IMCC_DIR)/%${o} : $(IMCC_DIR)/%.c
$(PERL) tools/dev/cc_flags.pl ./CFLAGS $(CC) -I$(IMCC_DIR) $(CFLAGS)
${cc_o_out}$@ -c $
Nick Kostirya/
Re: x86 JIT and GCC 3.3 don't play well together
Dan Sugalski [EMAIL PROTECTED] wrote: To the point of failing near-every test. GCC 2.95, on the other hand, seems quite happy with it. (details at http://tinderbox.perl.org) Could someone take a look at things and see what's going on please? Fix committed. Dan leo
Re: x86 JIT and GCC 3.3 don't play well together
On Mon, 13 Oct 2003, Leopold Toetsch wrote: Dan Sugalski [EMAIL PROTECTED] wrote: To the point of failing near-every test. GCC 2.95, on the other hand, seems quite happy with it. (details at http://tinderbox.perl.org) Could someone take a look at things and see what's going on please? Fix committed. Cool, thanks. Dan
Re: x86 JIT and GCC 3.3 don't play well together
Leopold Toetsch [EMAIL PROTECTED] writes: Dan Sugalski [EMAIL PROTECTED] wrote: To the point of failing near-every test. GCC 2.95, on the other hand, seems quite happy with it. (details at http://tinderbox.perl.org) Could someone take a look at things and see what's going on please? Strange, with gcc 3.3.1 I could not reproduce this error. Only one test fails: t/op/number.NOK 38# Failed test (t/op/number.t at line 1038) # got: '12.50 # -1.996899 # ' # expected: '12.50 # 0.00 # ' # Looks like you failed 1 tests of 38. Fix committed. And that was before this fix was commited. From the gcc3.3.1 docs it seems that -mno-accumulate-outgoing-args is default. bye boe -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: x86 JIT and GCC 3.3 don't play well together
On Mon, 13 Oct 2003, Juergen Boemmels wrote: Leopold Toetsch [EMAIL PROTECTED] writes: Dan Sugalski [EMAIL PROTECTED] wrote: To the point of failing near-every test. GCC 2.95, on the other hand, seems quite happy with it. (details at http://tinderbox.perl.org) Could someone take a look at things and see what's going on please? Strange, with gcc 3.3.1 I could not reproduce this error. 3.3.2 dies like this. (And the fix is apparently very specific, as arete, which looks to be running 3.3.2, dies wiht a complaint about no-accumulate-outgoing-args not existing. I think we're entering a maze of twisty little compiler version quirks, all of them annoying. :( Dan
Re: Phalanx / CPANTS / Kwalitee
On Mon, Oct 13, 2003 at 10:28:29AM +0200, Thomas Klausner wrote: * contains files: * Makefile.PL or Build.PL or configure configure? * README Personally, I find READMEs useless duplication. Even more so now that search.cpan.org works so well. * t/* or test.pl test.pl is not a good thing. It doesn't get parsed by make test. It just runs and spits the output to the screen. If a test fails, make test will still succeed. Still, its better than nothing at all. * one *.pm in top-level OR lib/ Or Module/*.pm. Seems a little dubious anyway, there are POD-only modules. Some ideas: * wheater PREREQ_PM matches used modules (hard!) Nearly impossible since: require Foo::Bar if $some_condition; Otherwise Module::Info-modules_used() can handle it. -- Michael G Schwern[EMAIL PROTECTED] http://www.pobox.com/~schwern/ AY! The ground beef, she is burning my groin! http://sluggy.com/d/990105.html
Re: x86 JIT and GCC 3.3 don't play well together
Dan Sugalski [EMAIL PROTECTED] writes: On Mon, 13 Oct 2003, Juergen Boemmels wrote: Leopold Toetsch [EMAIL PROTECTED] writes: Dan Sugalski [EMAIL PROTECTED] wrote: To the point of failing near-every test. GCC 2.95, on the other hand, seems quite happy with it. (details at http://tinderbox.perl.org) Could someone take a look at things and see what's going on please? Strange, with gcc 3.3.1 I could not reproduce this error. 3.3.2 dies like this. (And the fix is apparently very specific, as arete, which looks to be running 3.3.2, dies wiht a complaint about no-accumulate-outgoing-args not existing. Looking a bit more closely to the gcc-docs: This option is specific to i386 and x86-64. As ariete is an ia64 it does not recognize this option. I think we're entering a maze of twisty little compiler version quirks, all of them annoying. :( It also depends on the target. An i386 needs diffrent flags than a ia64. :-( On the positive side adding -mno-accumulate-outgoing-args did not hurt on gcc-3.3.1/i386; it still fails only t/op/numbers_38.pasm. I will try to find out whats wrong with this. bye boe -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: FreeBSD (4.8) can't build imcc
Nick Kostirya [EMAIL PROTECTED] writes:
I propose replace
@$(PERL) tools/dev/cc_flags.pl ./CFLAGS $(CC) $(CFLAGS) ${cc_o_out}$@ -c $
by
@$(PERL) tools/dev/cc_flags.pl ./CFLAGS $(CC) $(CFLAGS) -I$(@D)
${cc_o_out}$@ -c $
and remove
$(IMCC_DIR)/%${o} : $(IMCC_DIR)/%.c
$(PERL) tools/dev/cc_flags.pl ./CFLAGS $(CC) -I$(IMCC_DIR) $(CFLAGS)
${cc_o_out}$@ -c $
I tested it and it seems to work on Linux/i386 too.
But before appling it I want to here something from the windows folks
bye
boe
Context diff:
Index: config/gen/makefiles/root.in
===
RCS file: /cvs/public/parrot/config/gen/makefiles/root.in,v
retrieving revision 1.145
diff -u -r1.145 root.in
--- config/gen/makefiles/root.in13 Oct 2003 13:36:08 - 1.145
+++ config/gen/makefiles/root.in13 Oct 2003 15:26:15 -
@@ -240,7 +240,7 @@
MAKE_C = ${make_c}
.c$(O) :
- @$(PERL) tools/dev/cc_flags.pl ./CFLAGS $(CC) $(CFLAGS) ${cc_o_out}$@ -c $
+ @$(PERL) tools/dev/cc_flags.pl ./CFLAGS $(CC) $(CFLAGS) -I$(@D) ${cc_o_out}$@
-c $
all : flags_dummy $(TEST_PROG) docs
@@ -608,8 +608,6 @@
$(IMCC_O_FILES) : $(IMCC_H_FILES) $(ALL_H_FILES)
-$(IMCC_DIR)/%${o} : $(IMCC_DIR)/%.c
- $(PERL) tools/dev/cc_flags.pl ./CFLAGS $(CC) -I$(IMCC_DIR) $(CFLAGS)
${cc_o_out}$@ -c $
docs, test and maintainer targets
Re: x86 JIT and GCC 3.3 don't play well together
Dan Sugalski [EMAIL PROTECTED] wrote: I think we're entering a maze of twisty little compiler version quirks, all of them annoying. :( The problem is JIT_CGP. This does nasty things with call frames, as well as gcc does. Only core_ops_cgp.c has to be compiled with mno-accumulate-... Or we disable JIT_CGP for failing gcc versions. Dan leo
[COMMIT] perl6 sub calling
For those of you not on the CVS list, I just committed a rather large
change to the perl6 compiler that implements a subset of the A6
subroutine signature rules. My implementation is rather ad-hoc, but it
is a decent representation of my slowly evolving understanding of how
this stuff's supposed to work. Eventually, I'd like to rewrite it to
be more encapsulated, and make it plug into the parser better. Ooh,
and it needs some runtime context stuff, but I don't think that really
exists anywhere in perl6 right now.
Even better, I'd love to see someone else rewrite it properly.
See languages/perl6/t/compiler/call.t for several examples of usage.
Briefly, it handles things like:
sub f ($a, $b) { ... }
sub g ($a, +$b) { ... }
sub h ($a, [EMAIL PROTECTED]) { ... }
f(1,2);
f(a, b = 2);
g(a = 1, b = 2);
h(1, 2, 3, 4);
h(1, 2, [EMAIL PROTECTED], 40);
It pretends to handle optional parameters, but if you don't pass in a
value to an optional parameter, it reuses whatever happened to be
lying around in that register, and there's no way of telling whether
the caller specified a value or not.
I doubt anyone will actually use any of this for a while, so unless I
get change requests I'm planning on leaving this in its current
half-baked state for now, and going back to using it for a regular
expression engine, which is why I went down this rabbit hole in the
first place.
Re: x86 JIT and GCC 3.3 don't play well together
Leopold Toetsch [EMAIL PROTECTED] writes:
Dan Sugalski [EMAIL PROTECTED] wrote:
I think we're entering a maze of twisty little compiler version quirks,
all of them annoying. :(
The problem is JIT_CGP. This does nasty things with call frames, as well
as gcc does. Only core_ops_cgp.c has to be compiled with
mno-accumulate-... Or we disable JIT_CGP for failing gcc versions.
That explains something. The compilation of cgoto is so anoyingly slow
on my machine that I nearly always configure with --cgoto=0.
Another idea would be only add -mnoaccumulate-... if the target
supports it and needs it.
Something like this:
Index: config/auto/gcc.pl
===
RCS file: /cvs/public/parrot/config/auto/gcc.pl,v
retrieving revision 1.12
diff -u -r1.12 gcc.pl
--- config/auto/gcc.pl 13 Oct 2003 14:19:28 - 1.12
+++ config/auto/gcc.pl 13 Oct 2003 17:35:22 -
@@ -18,8 +18,9 @@
%gnuc=eval cc_run() or die Can't run the test program: $!;
cc_clean();
- my($gccversion, $warns, $ccwarn);
+ my($gccversion, $warns, $ccwarn, $ccflags);
$ccwarn=Configure::Data-get('ccwarn');
+ $ccflags=Configure::Data-get('ccflags');
unless (exists $gnuc{__GNUC__}) {
return;
@@ -74,7 +75,7 @@
2.7 = ,
2.8 = -Wsign-compare,
2.95 = ,
- 3.0 = -Wformat-nonliteral -Wformat-security -Wpacked
-Wdisabled-optimization -mno-accumulate-outgoing-args -Wno-shadow,
+ 3.0 = -Wformat-nonliteral -Wformat-security -Wpacked
-Wdisabled-optimization -Wno-shadow,
# -Wsequence-point is part of -Wall
# -Wfloat-equal may not be what we want
# We shouldn't be using __packed__, but I doubt -Wpacked will harm us
@@ -96,6 +97,11 @@
}
$warns = join ' ', @warns;
}
+# target dependend options
+my $target = Configure::Data-get('cpuarch');
+if ($target eq 'i386' $gccversion = 3.0) {
+ $ccflags .= ' -mno-accumulate-outgoing-args';
+}
}
if (defined $miniparrot $gccversion) {
@@ -112,6 +118,7 @@
Configure::Data-set(
ccwarn= $warns $ccwarn,
+ccflags = $ccflags,
gccversion = $gccversion
);
}
Index: lib/Parrot/Configure/RunSteps.pm
===
RCS file: /cvs/public/parrot/lib/Parrot/Configure/RunSteps.pm,v
retrieving revision 1.26
diff -u -r1.26 RunSteps.pm
--- lib/Parrot/Configure/RunSteps.pm30 Sep 2003 12:52:47 - 1.26
+++ lib/Parrot/Configure/RunSteps.pm13 Oct 2003 17:35:23 -
@@ -23,9 +23,9 @@
auto/byteorder.pl
auto/pack.pl
auto/format.pl
+ auto/jit.pl
auto/gcc.pl
auto/isreg.pl
- auto/jit.pl
auto/funcptr.pl
auto/cgoto.pl
auto/gc.pl
Re: x86 JIT and GCC 3.3 don't play well together
Juergen Boemmels [EMAIL PROTECTED] writes:
t/op/number.NOK 38# Failed test (t/op/number.t at line 1038)
# got: '12.50
# -1.996899
# '
# expected: '12.50
# 0.00
# '
# Looks like you failed 1 tests of 38.
I think I found out why this test is failing (randomly):
The null_n op emits in emits the address to a auto variable in
Parrot_null_n_jit. But this frame is destroyed after the emission of
the code. When the code is run it uses a reference to a no longer
existing frame which may contain random data. The value zero has to
outlive the invokation of Parrot_null_n_jit so making zero static
will solve the problem.
Can someone with more jit-experience verify that I'm correct?
bye
boe
Index: jit/i386/core.jit
===
RCS file: /cvs/public/parrot/jit/i386/core.jit,v
retrieving revision 1.48
diff -u -U7 -r1.48 core.jit
--- jit/i386/core.jit 3 Oct 2003 15:43:49 - 1.48
+++ jit/i386/core.jit 13 Oct 2003 19:11:55 -
@@ -129,15 +129,15 @@
}
Parrot_null_s {
Parrot_null_x s/_N/_i/ s/INT_R/STRING_R/ s/val/NULL/
}
Parrot_null_n {
-FLOATVAL zero = 0;
+static FLOATVAL zero = 0;
if (MAP[1]) {
jit_emit_mov_ri_n(NATIVECODE, MAP[1], zero);
}
else {
jit_emit_mov_mi_ni(NATIVECODE, NUM_REG[1], zero);
}
}
RE: [perl #24188] [PATCH] io/io_unix.c fails on OS X
Hmm, this still fails on AIX, since the guard (PARROT_HAS_HEADER_SYSSOCKIO) and the
header (sys/socket.h) don't match. I don't have sys/sockio.h, but sys/socket.h is
required to prevent the same sizeof(incomplete type) error that Michael reported.
There's no $Config{i_syssocket}, though, so it can't just be changed to
PARROT_HAS_HEADER_SYSSOCKET, unless sys/socket.h is added to the list of in
config/auto/headers.pl. A patch for that and the guard is attached.
-Original Message-
From: Michael Scott (via RT)
[mailto:[EMAIL PROTECTED]
Sent: Saturday, October 11, 2003 3:16 PM
To: [EMAIL PROTECTED]
Subject: [perl #24188] [PATCH] io/io_unix.c fails on OS X
# New Ticket Created by Michael Scott
# Please include the string: [perl #24188]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=24188
The file io/io_unix.c is failing to compile on OS X 10.2.6
with gcc 3.3
with the following error:
io/io_unix.c: In function `PIO_sockaddr_in':
io/io_unix.c:451: error: invalid application of `sizeof' to an
incomplete type
make: *** [io/io_unix.o] Error 1
The attached patch adds a conditional include for sys/socket.t.
-- attachment 1
--
url: http://rt.perl.org/rt2/attach/65951/49265/da818d/io_unix_c.patch
io.patch
Description: io.patch
RE: [perl #24188] [PATCH] io/io_unix.c fails on OS X
On Mon, 13 Oct 2003, Adam Thomason wrote:
Hmm, this still fails on AIX, since the guard
(PARROT_HAS_HEADER_SYSSOCKIO) and the header (sys/socket.h) don't match.
I don't have sys/sockio.h, but sys/socket.h is required to prevent the
same sizeof(incomplete type) error that Michael reported. There's no
$Config{i_syssocket}, though, so it can't just be changed to
PARROT_HAS_HEADER_SYSSOCKET, unless sys/socket.h is added to the list of
in config/auto/headers.pl. A patch for that and the guard is attached.
Applied, thanks.
Dan
Website needs updating
All~ I have noticed that the webpage seems to stay rather behind the current state. Perhaps replacing it with somehting that is easier to keep up-to-date like a wiki would be useful... I don't really know, but at the least it should be updated to state something truer then the current release is version 0.0.10 I understand that the webpage is low on the priority list, probably rightly so. But I often get the false impression that a project is dead, simply because the website is. Now for the good news, my Debian pentium laptop with gcc 3.3.2 passes all tests successfully (after a `make realclean`) Matt
RE: Website needs updating
Matt_Fowles wrote: Perhaps replacing it with somehting that is easier to keep up-to-date like a wiki would be useful... Mike Scott created an unofficial wiki at http://www.vendian.org/parrot/wiki/bin/view.cgi -- Garrett Goebel IS Development Specialist ScriptPro Direct: 913.403.5261 5828 Reeds Road Main: 913.384.1008 Mission, KS 66202 Fax: 913.384.2180 www.scriptpro.com garrett at scriptpro dot com
Re: Phalanx / CPANTS / Kwalitee
-BEGIN PGP SIGNED MESSAGE- Moin, On Monday 13 October 2003 11:57, Michael G Schwern wrote: On Mon, Oct 13, 2003 at 10:28:29AM +0200, Thomas Klausner wrote: * contains files: * Makefile.PL or Build.PL or configure configure? * README Personally, I find READMEs useless duplication. Even more so now that search.cpan.org works so well. You have never maintained a big project, were the *brief* introduction in README is 8 pages, accompanied by an INSTALL file with another 15, not to speak of the $three-digit-figure pages of userland documenatation :) In that case a README is a lifesaver, because it is, if ever, the only thing someone reads :) (That was a joke about you personally. :-) I find that a short intro in the README (if it isn't immidiately replicated in the .pod, where it does _not_ belong if there are more than on .pm files) is very usefull. Unfortunately, not every project has a README, or a useless one (like just a boilerplate or something like this). The README should explain the goals and target of the package, contact points etc etc.. I agree that merely having one doesn't say much, but if it is lacking, that certainly shows the authors attitude... * t/* or test.pl test.pl is not a good thing. It doesn't get parsed by make test. It just runs and spits the output to the screen. If a test fails, make test will still succeed. Still, its better than nothing at all. If there are t/* _and_ test.pl this probably should be marked as bad. test.pl is usually old cruft still lingering around :) * one *.pm in top-level OR lib/ Or Module/*.pm. Seems a little dubious anyway, there are POD-only modules. And what about doc/Somedoc.pod files? Just my 0.02Eurocent, Tels - -- Signed on Mon Oct 13 18:51:43 2003 with key 0x93B84C15. Visit my photo gallery at http://bloodgate.com/photos/ PGP key on http://bloodgate.com/tels.asc or per email. Now, admittedly, it's critical software. This is the 'let's go kill people' software. -- Mark A. Welsh III -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux) Comment: When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl. iQEVAwUBP4rYKHcLPEOTuEwVAQG6mwf+Ke2wRst2S3FEUtb+x0SgTsbNtuJGc3e8 71nycuArl2eXhRYyyk7yZm73AxPWdE6cyOcSg94Y0MtD2t58OMDiRUksomLRtMBC TD441s1Wmx3HrxYqTGLHLeuDmJjVbsCnFJkr8Vfc/cPbp0u+yDFo5ZtaF1QhIWXQ djAMTWLjgaYk9OfxswiTj1YohQIGzzqTaHlQalvU4GyHYz0enAT71YGyHF/ZEYz6 d5BsvdMFLIobx/zvyWYKMkdd5hv45oL621L2S+I0tKevZzbWe9MNmGB1MvWFb7hy WlH/7wVT7qq3QHlo4O8fzoVMU1zFfGBoff7uLeL8rh7vEPuLs3L2ow== =uqva -END PGP SIGNATURE-
Re: Phalanx / CPANTS / Kwalitee
Thomas Klausner wrote in perl.qa : Hints that were in Leon's last release, but which I didn't port up to now: * POD errors * POD/Code ratio (what would be a good measurement?) use Pod::Coverage ? * testers results * number of releases
Re: Phalanx / CPANTS / Kwalitee
On Mon, Oct 13, 2003 at 06:51:43PM +0200, Tels wrote: * t/* or test.pl test.pl is not a good thing. It doesn't get parsed by make test. It just runs and spits the output to the screen. If a test fails, make test will still succeed. Still, its better than nothing at all. If there are t/* _and_ test.pl this probably should be marked as bad. test.pl is usually old cruft still lingering around :) No, t/* and test.pl is ok. test.pl is basically just a program that gets run at make test time. DBI and the DBD::* modules use test.pl to display benchmarking information. -- Michael G Schwern[EMAIL PROTECTED] http://www.pobox.com/~schwern/ I know you get this a lot, but what's an unholy fairy like you doing in a mosque like this?
Devel::Cover bug in ActiveState Perl for *Linux*
After much research, I've managed to reduce a Devel::Cover bug down to a one-liner
which only
fails on one box. This box is unique because it's ActiveState Perl for Linux (not my
choice!).
However, that might be a red herring. My 'perl -V' is below the test case. Does
anyone have a
similar setup which they can check this against?
--
$ perl -MDevel::Cover -e 'local *{foo} = sub {}'
Devel::Cover 0.26: Collecting coverage data for branch, condition, statement,
subroutine and time.
Pod coverage is unvailable. Please install Pod::Coverage from CPAN.
Selecting packages matching:
Ignoring packages matching:
Ignoring packages in:
.
/dp/usr/cxp/perl/lib
/usr/local/lib/perl5/site_perl
/usr/local/lib/perl5/site_perl/5.6.1
/usr/local/lib/perl5/site_perl/5.6.1/i686-linux-multi
/usr/local/stow/perl-5.6.1-a633/lib/perl5/5.6.1
/usr/local/stow/perl-5.6.1-a633/lib/perl5/5.6.1/i686-linux-multi
/usr/local/stow/perl-5.6.1-a633/lib/perl5/site_perl
/usr/local/stow/perl-5.6.1-a633/lib/perl5/site_perl/5.6.1
/usr/local/stow/perl-5.6.1-a633/lib/perl5/site_perl/5.6.1/i686-linux-multi
Can't locate object method find_cv via package B::SPECIAL (perhaps you forgot to
load
B::SPECIAL?) at
/usr/local/stow/perl-5.6.1-a633/lib/perl5/5.6.1/i686-linux-multi/B.pm line 213.
END failed--call queue aborted.
--
And the Perl -V
--
$ perl -V
Summary of my perl5 (revision 5.0 version 6 subversion 1) configuration:
Platform:
osname=linux, osvers=2.4.9-e.3, archname=i686-linux-multi
uname='linux bulkmailer 2.4.9-e.3 #1 fri may 3 17:02:43 edt 2002 i686 unknown '
config_args='-d -O -Dinstallstyle=lib/perl5
-Dprefix=/usr/local/stow/perl-5.6.1-a633
-Uinstallusrbinperl -Dd_dosuid=define -Dotherlibdirs=/usr/local/lib/perl5/site_perl
-Dusemultiplicity'
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=define
useperlio=undef d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
Compiler:
cc='cc', ccflags ='-fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64',
optimize='-O2',
cppflags='-fno-strict-aliasing -I/usr/local/include'
ccversion='', gccversion='2.96 2731 (Red Hat Linux 7.2 2.96-108.1)',
gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
alignbytes=4, usemymalloc=n, prototype=define
Linker and Libraries:
ld='cc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib
libs=-lnsl -lgdbm -ldb -ldl -lm -lc -lcrypt -lutil
perllibs=-lnsl -ldl -lm -lc -lcrypt -lutil
libc=/lib/libc-2.2.4.so, so=so, useshrplib=false, libperl=libperl.a
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic'
cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib'
Characteristics of this binary (from libperl):
Compile-time options: MULTIPLICITY USE_LARGE_FILES PERL_IMPLICIT_CONTEXT
Locally applied patches:
ActivePerl Build 633
Built under linux
Compiled at Mar 24 2003 17:43:39
%ENV:
PERL5LIB=/dp/usr/cxp/perl/lib
@INC:
/dp/usr/cxp/perl/lib/i686-linux-multi
/dp/usr/cxp/perl/lib
/usr/local/stow/perl-5.6.1-a633/lib/perl5/5.6.1/i686-linux-multi
/usr/local/stow/perl-5.6.1-a633/lib/perl5/5.6.1
/usr/local/stow/perl-5.6.1-a633/lib/perl5/site_perl/5.6.1/i686-linux-multi
/usr/local/stow/perl-5.6.1-a633/lib/perl5/site_perl/5.6.1
/usr/local/stow/perl-5.6.1-a633/lib/perl5/site_perl
/usr/local/lib/perl5/site_perl/5.6.1/i686-linux-multi
/usr/local/lib/perl5/site_perl/5.6.1
/usr/local/lib/perl5/site_perl
--
Any ideas on where to look next?
Cheers,
Ovid
=
Silence is Evilhttp://users.easystreet.com/ovid/philosophy/indexdecency.htm
Ovid http://www.perlmonks.org/index.pl?node_id=17000
Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/
__
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
Re: Phalanx / CPANTS / Kwalitee
-BEGIN PGP SIGNED MESSAGE- Moin, On Monday 13 October 2003 10:28, Thomas Klausner wrote: Hi! * POD/Code ratio (what would be a good measurement?) No. Some _very_ complex code takes little documentation like: =head2 sub delete_first_n_entries($N) Deletes the first N entries from the list. That pretty much sums it up and any more documentation probably only confuses. However, the method in question could easily be 10 pages long. (Look at the code in Math::BigInt::Calc.pm, for instance. Basically, _mul() multiplies two numbers - and it is _huge_. There are other issues, like the doc in the pod is usually for the code and the userland doc. However, in certain cases you also have userland doc (like: how to use the thing) and code doc (what does sub XYZ do?) seperated. Should these be rn together? But the an included XYZ guid for dummies would skew the numbers (It suggest much doc, but the code maybe not documented at all) etc. I donät think sensible results can be done by comparing pod to code size. It is similiar silly like counting line numbers. (does the fact that I optimized 2 pages code away mean I wrote -128 lines of code this week? :) Obviously, this list is far from complete, which is why I request some feedback on more hints for Kwalitee from all of you! Unfortunately, it is had for me to come up with good, machine-implementable rules.. Probably something like: *.pm file has more than 1000 lines of code = bad :-) Best wishes, Tels - -- Signed on Mon Oct 13 19:40:43 2003 with key 0x93B84C15. Visit my photo gallery at http://bloodgate.com/photos/ PGP key on http://bloodgate.com/tels.asc or per email. Call me Justin, Justin Case. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux) Comment: When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl. iQEVAwUBP4rk2ncLPEOTuEwVAQE5mwf9EqbcU2Fb1FD57uv2u8mwruF4CytE7tKl dkRePVBOvuOFOQ8EEu2LO0uTjPDlbA9+Ko5EFQtoN+1HWAKqsR0MlfIcZx1TeXiw 67K6xxwPI3Z5O6qnZKGrqkDymxg1NlO9HfYYI9nPah2WXgixXk48ynytEdsa0QDY vunBMwbILON486Nz9ieKUAvk39fPezQq9Dsicl0IKj03f6F4Tvc7cbo4yToeiY9s YuZevJPG5bSVl2pBQoGoRvA5HaSdW9twvy2s6BLekx7hD3CpdSYX5+9jK5CG3eov HWqMkoEHLwk1fhAyQFbRKo3VdJCKjPvM3QT0waHuLnalX3RKQmwdjA== =lmnE -END PGP SIGNATURE-
Re: Devel::Cover bug in ActiveState Perl for *Linux*
FYI: I've managed to replicate this error on another ActiveState Perl linux box. The Perl -V information is the same, but the module list is quite a bit smaller. The only common element that I can find is ActiveState. Cheers, Ovid = Silence is Evilhttp://users.easystreet.com/ovid/philosophy/indexdecency.htm Ovid http://www.perlmonks.org/index.pl?node_id=17000 Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/ __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com
Re: Devel::Cover bug in ActiveState Perl for *Linux*
On Mon, Oct 13, 2003 at 01:49:58PM -0700, Ovid wrote: After much research, I've managed to reduce a Devel::Cover bug down to a one-liner which only fails on one box. This box is unique because it's ActiveState Perl for Linux (not my choice!). However, that might be a red herring. My 'perl -V' is below the test case. Does anyone have a similar setup which they can check this against? I think the key is that it is perl version 5.6.1. I can reproduce the problem on a stock 5.6.1 on linux (well, hacked just enough to get it to build). Is there any chance that we can just say it is a bug in 5.6.1 that has been fixed? I think that is actually the case. Devel::Cover uses the B modules which were still a little immature in 5.6.1. The test works (in that the bug does not show) for 5.8.0, 5.8.1, maintperl and bleadperl. Actually, I wonder whether 5.6.1 should be supported or not. It generally works, but then you get cases like this. The results are also different between different versions of perl, and often it is 5.6.1 and the rest. But this is a problem which will only get worse. In any case, thanks a lot for tracking this down. I'm sure it wasn't trivial. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
RE: [perl #24188] [PATCH] io/io_unix.c fails on OS X
At 04:15 PM 10/13/2003 -0400, Dan Sugalski wrote:
On Mon, 13 Oct 2003, Adam Thomason wrote:
Hmm, this still fails on AIX, since the guard
(PARROT_HAS_HEADER_SYSSOCKIO) and the header (sys/socket.h) don't match.
I don't have sys/sockio.h, but sys/socket.h is required to prevent the
same sizeof(incomplete type) error that Michael reported. There's no
$Config{i_syssocket}, though, so it can't just be changed to
PARROT_HAS_HEADER_SYSSOCKET, unless sys/socket.h is added to the list of
in config/auto/headers.pl. A patch for that and the guard is attached.
Applied, thanks.
Thanks Adam. Sometimes it is good for us to start breaking things because
more things get done. :)
-Melvin
Re: Website needs updating
Coming soon, a revised website that'll be easy for everyone to send patches to, and much easier for us to give others direct access to modifying it. The core is in place, but there are one or two technical chunks that need to get finished before I can call it done. (or at least feature/content equivalent) -R At Mon, 13 Oct 2003 14:45:56 -0600, [EMAIL PROTECTED] wrote: All~ I have noticed that the webpage seems to stay rather behind the current state. Perhaps replacing it with somehting that is easier to keep up-to-date like a wiki would be useful... I don't really know, but at the least it should be updated to state something truer then the current release is version 0.0.10
