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.
Not really we would be really interested to a good heuristic
Stef
On May 15, 2009, at 4:15 PM, Mircea Lungu wrote:
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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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:
Not really we would be really interested to a good heuristic
Stef
On May 15, 2009, at 4:15 PM, Mircea Lungu wrote:
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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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:
Not really we would be really interested to a good heuristic
Stef
On May 15, 2009, at 4:15 PM, Mircea Lungu wrote:
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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"It's not what we do that matters most, it's how we do it."
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:
Not really we would be really interested to a good heuristic
Stef
On May 15, 2009, at 4:15 PM, Mircea Lungu wrote:
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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"It's not what we do that matters most, it's how we do it."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hmm, I think the logic of the importer might need to be rethought. It looks like if it finds something in the model it does not look for methods outside. Most of the times this is Ok, but in your case it looks like it is not.
Did you try any of the tools that detect the types of the variables (e.g., RoelTyper - although I do not know if it is available for VW)?
Cheers, Doru
On 17 May 2009, at 11:49, Mircea Lungu wrote:
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:
Not really we would be really interested to a good heuristic
Stef
On May 15, 2009, at 4:15 PM, Mircea Lungu wrote:
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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"It's not what we do that matters most, it's how we do it."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"In a world where everything is moving ever faster, one might have better chances to win by moving slower."
On May 17, 2009, at 3:23 PM, Tudor Girba wrote:
Hmm, I think the logic of the importer might need to be rethought. It looks like if it finds something in the model it does not look for methods outside. Most of the times this is Ok, but in your case it looks like it is not.
Did you try any of the tools that detect the types of the variables (e.g., RoelTyper - although I do not know if it is available for VW)?
It is for both squeak and VW
Cheers, Doru
On 17 May 2009, at 11:49, Mircea Lungu wrote:
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:
Not really we would be really interested to a good heuristic
Stef
On May 15, 2009, at 4:15 PM, Mircea Lungu wrote:
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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"It's not what we do that matters most, it's how we do it."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"In a world where everything is moving ever faster, one might have better chances to win by moving slower."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On 17 mai 09, at 15:23, Tudor Girba wrote:
Hmm, I think the logic of the importer might need to be rethought. It looks like if it finds something in the model it does not look for methods outside. Most of the times this is Ok, but in your case it looks like it is not.
Yes, some kind of importing context for the candidate operator. This is something I want to look at in Pharo, to optimize anyway.
Did you try any of the tools that detect the types of the variables (e.g., RoelTyper - although I do not know if it is available for VW)?
Cheers, Doru
On 17 May 2009, at 11:49, Mircea Lungu wrote:
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:
Not really we would be really interested to a good heuristic
Stef
On May 15, 2009, at 4:15 PM, Mircea Lungu wrote:
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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"It's not what we do that matters most, it's how we do it."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"In a world where everything is moving ever faster, one might have better chances to win by moving slower."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Simon
On May 17, 2009, at 11:49 AM, Mircea Lungu wrote:
Hi Doru,
I reject all the messages that have more than one candidate in their candidates list from the start.
why? As soon as you have a polymorphic method, you remove it? I do not understand
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:
Not really we would be really interested to a good heuristic
Stef
On May 15, 2009, at 4:15 PM, Mircea Lungu wrote:
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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"It's not what we do that matters most, it's how we do it."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-
Mircea Lungu -
Simon Denier -
Stéphane Ducasse -
Tudor Girba