On 5 Feb 2004, at 14:35, Leo Simons wrote:
Stefano Mazzocchi wrote:I think the key is that the gump runs as for Gump or Gumpy do *not* contain enough information.
what might work sometimes is (pattern) matching the <package/> statements of the dependencies against the errors produced by javac or unit tests, and cvs history.
that would've caught the xml-batik error, I think. I mean,
[javac] /data/gump/xml-batik/sources/org/apache/batik/script/rhino/ BatikSecurityController.java:69: org.apache.batik.script.rhino.BatikSecurityController is not abstract and does not override abstract method callWithDomain(java.lang.Object,org.mozilla.javascript.Context,org.mozi lla.javascript.Callable,org.mozilla.javascript.Scriptable,org.mozilla.j avascript.Scriptable,java.lang.Object[]) in org.mozilla.javascript.SecurityController
[javac] public class BatikSecurityController extends SecurityController {
is clearly showing to any human programmer that whatever produces the
org.mozilla.javascript
package is the problem, since BatikSecurityController.java presumably didn't change since the previous build yet started causing a compilation failure.
you'd need to be pretty intelligent about parsing the error message though. But it seems to be there in some way, without needing /that/ many statistics.
You are using an "altavista" approach of heuristical pattern matching, I want to use a more Google-like approach of making human inferencing emerge out of implicit topological properties of a graph.
I have a pretty strong opinion on why the first much inferior compared to the second (as google showed rather evidently, but that's just the tip of the iceberg)
-- Stefano.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
