17 May
2009
17 May
'09
11:49 a.m.
Hi Doru,
I reject all the messages that have more than one candidate in their
candidates list from the start. I want to be sure that all the
dependencies I display are actually there.
However, in several cases the importer found a method defined in my
project without finding it in the BaseVisualWorks package (this was
the case with my #include: example). In this case I obtained a
candidateList with a single invoked method, which was my #include:,
and all the classes in my project seemed to depend on it. In fact they
were in 99% of the cases invoking the #include: defined in List.
Cheers,
Mircea.
On May 17, 2009, at 9:57 AM, Tudor Girba wrote:
Hi Mircea,
One idea for pruning the invocations would be to reject all
invocations that have at least one candidate as stub. I think this
should work quite well and would not rely on a hardcoded list of
messages. I would be curious about the difference to your approach.
Cheers,
Doru
On 17 May 2009, at 09:45, Mircea Lungu wrote:
I ended up importing the BaseVisualWorks package
and generating from
it a list of all the methods names. I installed this list in a
helper class in Softwarenaut (BaseVisualWorksMethods class>>names).
I use this collection of methods to filter out the invocations that
go to methods in my model that have the same name as methods that
exist in the BaseVisualWorks package. When analyzing the SPO
project, out of 2000 invocations going to 500 methods in the
project's namespace, i filtered out in this way 600 invocations
going to 40 methods. As a result, the #include: and #with: problems
that I was mentioning in my last email were fixed. The other 38
methods that were filtered also pretty general method names (origin,
height, day, menu) which at the first encounter with the system, I
would say, are not that relevant.
For now this approach is suffcient for me. If I come up with
something better I'll let you know. Also if anybody is interested in
discussing this further ping me.
Cheers,
Mircea.
On May 15, 2009, at 9:09 PM, Stéphane Ducasse wrote:
--
www.tudorgirba.com
"It's not what we do that matters most, it's how we do it."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev Not really we would be really interested to a
good heuristic
Stef
On May 15, 2009, at 4:15 PM, Mircea Lungu wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hi guys,
Today I imported a smalltalk project in Moose/Softwarenaut.
I have more than 3500 invocations with multiple candidates in the
candidates list. I decided that I will ignore those dependencies. I
would rather see fewer dependencies but be sure that the ones I see
are for real (some kind of the lower-bounds of inter-package
dependencies).
The problem is that after removing the ambiguous invocations, I
still have spurious invocations. Two examples:
- In the project, there is a class which defines the #includes:
method. In the resulting model, I have 64 invocations to this
class's #include. However, if you look at the code, you see that
the
overwhelming majority of them are actually invocking
List>>includes:. In fact, the model sais that several classes from
the VisualWorks Base are depending on my code because they call
includes:.
- The same situation with the #with. I have it defined in one
class,
and all the invocations are attributed to the class although almost
all are actually invoking the WATagBrush>>with: from Seaside.
I am thinking that I should ignore the dependencies that have as
target methods that I will define in a blacklist. I would put in
there methods which are frequently used like: for: with: contains:
etc... I guess I can remove a lot of noise this way. Then i could
probably allow the user to further filter methods from the UI of
S*naut.
However, the user would have to know the system in order to be able
to filter out these invocations. And the point of S*naut was that
the user did not know the system... :)
Does anybody have a better approach to making sure that the
dependencies in the model are for real?
Cheers,
Mircea.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev