Nicholas Clark <[EMAIL PROTECTED]> writes:
> Maybe it's better to run it on a fresh checkout of the parrot source code,
> rather than a built tree.
And this is that result:
http://mysite.verizon.net/sean.sieger/cpd_12143.txt
On Sat, Apr 08, 2006 at 12:13:27PM -0500, Andy Lester wrote:
> On Sat, Apr 08, 2006 at 11:40:33AM -0400, Sean Sieger ([EMAIL PROTECTED])
> wrote:
> > 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
>
On Sat, Apr 08, 2006 at 11:40:33AM -0400, Sean Sieger ([EMAIL PROTECTED]) wrote:
> 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 fo
[EMAIL PROTECTED] (Andy Lester) writes:
> This is cool! Thanks for doing it.
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 exa
On Sat, Apr 08, 2006 at 10:00:05AM -0400, Sean Sieger ([EMAIL PROTECTED]) wrote:
> I put the result of doing cpd on parrot/src/*.c:
>
> http://mysite.verizon.net/sean.sieger/cpd_12139.txt
This is cool! Thanks for doing it.
Can you rerun it without the files that are apparently intentionally
dup
On 19 Apr 2004, at 21:03, Ovid wrote:
As part of our refactoring project, we'd like to find duplicated code.
Our hand-rolled scripts do a decent job, but could use a lot of work.
Rather than do a lot of work, I'm curious to know if anyone knows of
any tools already out there for that.
Any su
