I'd like to spend some time doing the same for Parrot, too. I hope that
doing the kind of maintenance I'm interested in makes things easier for
the core Parrot developers do their jobs.
Here's my first patch. Let me know if y'all see this sort of work as
useful, or if I shouldn't bother.
xoxo,
Andy
--
Andy Lester => an...@petdance.com => www.petdance.com => AIM:petdance
Welcome @ parrot, Andy.
> I'd like to spend some time doing the same for Parrot, too. I hope that
> doing the kind of maintenance I'm interested in makes things easier for
> the core Parrot developers do their jobs.
>
> Here's my first patch. Let me know if y'all see this sort of work as
> useful, or if I shouldn't bother.
Useful and very welcome, thanks, applied - r12096. (I've slightly
modified it, used N_BUILTINS once more).
> xoxo,
> Andy
leo
> Here's my first patch. Let me know if y'all see this sort of work as
> useful, or if I shouldn't bother.
Please continue.
In the next round of their scans, Coverity may add Parrot to the list of
projects.
For various annoying reasons, I can't do it, but running CPD over the code
could reveal a lot of interesting information:
-- c
Done. May I submit the duplications a dupe at a time?
How many are there? I think I'd prefer to see a whole list.
> On Apr 6, 2006, at 10:52 PM, Sean Sieger wrote:
> > Done. May I submit the duplications a dupe at a time?
> How many are there? I think I'd prefer to see a whole list.
Depending on the size of the list, I agree -- it might be easier to see
patterns of duplication with the whole list.
If it's really big, we can find a website to host it for a while.
-- c
I put the result of doing cpd on parrot/src/*.c:
This is cool! Thanks for doing it.
Can you rerun it without the files that are apparently intentionally
dupes of each other? For example, there's jit_cpu.c and exec_cpu.c, and
apparently are exact clones of each other.
xoa
My pleasure -- I am looking for a way to contribute.
> Can you rerun it without the files that are apparently intentionally
> dupes of each other? For example, there's jit_cpu.c and exec_cpu.c, and
> apparently are exact clones of each other.
Certainly; but I have a question -- originating in my first view of cpd
results, those of httpd hosted at pmd.sourceforge.net -- are the dupes
that are 'waste' only the ones found in one file? Or, maybe better for
me, how do I discern what you discerned? (I wanna discern!!)
Look at the tops of the files that have dupes. A couple that I looked
at have "Generated by xxx/xxx/xxx.pl" at the top.
Maybe it's better to run it on a fresh checkout of the parrot source code,
rather than a built tree.
Nicholas Clark
And this is that result:
Thanks for doing this. Can you do it without the autogenerated files
in there? Those, I expect to have duplicated code.
As soon as I found the autogenerated files, I thought, 'aren't these
( http://mysite.verizon.net/sean.sieger/12143.txt )
the ones that are not autogenerated?' That's what stopped me earlier.