Did this error happen while a Clustering loading window popped up while still having the DIC:.. loading window open? In that case, this is due to the fact that the original SCG-Algorithm Clustering did not support the use of CodeFoo.Unlimited positive as valid distance, I added a small fix to that package to support it, so you will have to update that package.
If not, could you maybe inspect and send me a stacktrace so I can see where it could go wrong?
regards, Toon
On (12/07/07 17:47), Hani ABDEEN wrote:
From: Hani ABDEEN hani.abdeen@univ-savoie.fr To: Toon Verwaest tverwaes@infogroep.be Cc: Moose-dev@iam.unibe.ch Subject: Re: [Moose-dev] Class clustering (Bug:Exceptions) Date: Thu, 12 Jul 2007 17:47:43 +0200
Hi,
I have tried to perform "Find clusters in model" on different models (Smalltalk and java models). I always got an exception such as: #Subscript out of bounds ... Note that I use VW7.5 with X11 (Mac).
bests, Hani
On Jul 10, 2007, at 19:27 PM, Toon Verwaest wrote:
Hi,
I have published my work up until now on classcluster detection in the scg store under the highly original bundle-name "Clustering". Like this you can play around a bit to see what it can do etc.
Some notes:
- In order to find clusters, the clustering plugin needs to be
installed, by running "SCG.Moose.AbstractEntity initializeAllMofDescriptions". I am sure there is a clean way to do this automatically when loading packages, but since I have no clue how to install that... this is how it works for now :) Next if you open the moose browser, rightclick on a model, "Find Clusters in Model".
- To get better results, make sure you merge instance and class part
of classes when generating models
- I have included Adrians dendrogram clustering, but have written a
wrapper around it to be able to browse the hierarchy as such that "double information" is avoided. For example if a b and c are all at distance 1 of each other, their combination a,b,c has threshold 1 too, so it is not useful to see a,b,c with left a,b with distance 1 and right c, so this info just gets pruned away. Currently the Interface and DeltaIC plugins are hierarchical and the reasons prefixed by * are hierarchical reasons (are possibly browsable).
Adrian: currently I have to do a bit of hacking to get similar results, but it might be cleaner if the algorithms would support items laying at Infinity+ from each other (if clustered their threshold is also Infinity+), so those results can be filtered easier...
- I know parts of the code (especially the UI and the sorting of
reasons) should be cleaned up a bit... but I don't have time for that for the moment, and like this at least you can already see some of the possibilities that it creates
Best regards, Toon _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev