18 Aug
2010
18 Aug
'10
3:21 p.m.
Hi!
I am analyzing Mondrian in Moose. One thing that I am bumping into, is that wrong
dependencies are inferred whereas I am sure that they do not exist. This is not a new, we
have to type in Smalltalk. For example:
MOEdge>>fromPositions
^ shape fromPositions
#fromPositions is implemented 3 times, by MOAbstractLayout, MOEdge, and MOLineShape.
In the case of MOEdge>>fromPositions, I am sure that it does not invoke
MOAbstractLayout>>fromPositions
I guess that everyone analyzing smalltalk code bumped into this very situation.
My question is how do we do in that case?
One easy solution, is to annotate Mondrian with an adequate pragma:
MOEdge>>fromPositions
<invoke: #fromPositions of: MOLineShape>
^ shape fromPositions
We can decline this pragma into:
<doesNotInvoke: #selector of: AClass>
<invoke: #fromPositions of: #(MOLineShape MOEdge)>
Simon told me Cyrille has worked on this problem. I am currently trying to use RoelTyper.
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
18 Aug
18 Aug
3:42 p.m.
Hi Alex
Did you try the different strategies provided for invocations resolution in the importer
wizard? Indeed, Cyrille coded a few strategies to use RoelTyper for better method
resolution (as well as inference of instance variable types). Unfortunately, there are no
test for this so I don't no how reliable it is. I would love to have tests and
precision/recall score for these strategies!
On 18 août 2010, at 15:21, Alexandre Bergel wrote:
Hi!
I am analyzing Mondrian in Moose. One thing that I am bumping into, is that wrong
dependencies are inferred whereas I am sure that they do not exist. This is not a new, we
have to type in Smalltalk. For example:
MOEdge>>fromPositions
^ shape fromPositions
#fromPositions is implemented 3 times, by MOAbstractLayout, MOEdge, and MOLineShape.
In the case of MOEdge>>fromPositions, I am sure that it does not invoke
MOAbstractLayout>>fromPositions
I guess that everyone analyzing smalltalk code bumped into this very situation.
My question is how do we do in that case?
One easy solution, is to annotate Mondrian with an adequate pragma:
MOEdge>>fromPositions
<invoke: #fromPositions of: MOLineShape>
^ shape fromPositions
We can decline this pragma into:
<doesNotInvoke: #selector of: AClass>
<invoke: #fromPositions of: #(MOLineShape MOEdge)>
Simon told me Cyrille has worked on this problem. I am currently trying to use
RoelTyper.
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
Simon
4:27 p.m.
I will try. In the meantime, I created a new issue.
http://code.google.com/p/moose-technology/issues/detail?id=435
Cheers,
Alexandre
On 18 Aug 2010, at 09:42, Simon Denier wrote:
Hi Alex
Did you try the different strategies provided for invocations resolution in the importer
wizard? Indeed, Cyrille coded a few strategies to use RoelTyper for better method
resolution (as well as inference of instance variable types). Unfortunately, there are no
test for this so I don't no how reliable it is. I would love to have tests and
precision/recall score for these strategies!
On 18 août 2010, at 15:21, Alexandre Bergel wrote:
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi!
I am analyzing Mondrian in Moose. One thing that I am bumping into, is that wrong
dependencies are inferred whereas I am sure that they do not exist. This is not a new, we
have to type in Smalltalk. For example:
MOEdge>>fromPositions
^ shape fromPositions
#fromPositions is implemented 3 times, by MOAbstractLayout, MOEdge, and MOLineShape.
In the case of MOEdge>>fromPositions, I am sure that it does not invoke
MOAbstractLayout>>fromPositions
I guess that everyone analyzing smalltalk code bumped into this very situation.
My question is how do we do in that case?
One easy solution, is to annotate Mondrian with an adequate pragma:
MOEdge>>fromPositions
<invoke: #fromPositions of: MOLineShape>
^ shape fromPositions
We can decline this pragma into:
<doesNotInvoke: #selector of: AClass>
<invoke: #fromPositions of: #(MOLineShape MOEdge)>
Simon told me Cyrille has worked on this problem. I am currently trying to use
RoelTyper.
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
Simon
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
4:44 p.m.
On 18 août 2010, at 16:27, Alexandre Bergel wrote:
I will try. In the meantime, I created a new issue.
http://code.google.com/p/moose-technology/issues/detail?id=435
Maybe it would be better to open an issue about testing AbstractCandidateListOperator
subclasses, since they already use RoelTyper.
Cyrille, could you make a quick summary of the strategies available?
Cheers,
Alexandre
On 18 Aug 2010, at 09:42, Simon Denier wrote:
--
Simon
Hi Alex
Did you try the different strategies provided for invocations resolution in the importer
wizard? Indeed, Cyrille coded a few strategies to use RoelTyper for better method
resolution (as well as inference of instance variable types). Unfortunately, there are no
test for this so I don't no how reliable it is. I would love to have tests and
precision/recall score for these strategies!
On 18 août 2010, at 15:21, Alexandre Bergel wrote:
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev Hi!
I am analyzing Mondrian in Moose. One thing that I am bumping into, is that wrong
dependencies are inferred whereas I am sure that they do not exist. This is not a new, we
have to type in Smalltalk. For example:
MOEdge>>fromPositions
^ shape fromPositions
#fromPositions is implemented 3 times, by MOAbstractLayout, MOEdge, and MOLineShape.
In the case of MOEdge>>fromPositions, I am sure that it does not invoke
MOAbstractLayout>>fromPositions
I guess that everyone analyzing smalltalk code bumped into this very situation.
My question is how do we do in that case?
One easy solution, is to annotate Mondrian with an adequate pragma:
MOEdge>>fromPositions
<invoke: #fromPositions of: MOLineShape>
^ shape fromPositions
We can decline this pragma into:
<doesNotInvoke: #selector of: AClass>
<invoke: #fromPositions of: #(MOLineShape MOEdge)>
Simon told me Cyrille has worked on this problem. I am currently trying to use
RoelTyper.
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
Simon
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
5:07 p.m.
So strategies available are:
a CandidateListOperator (the class used at the origin, could maybe be
removed) compute a list of possible type for a FamixInvocation's receiver
when:
- the receiver is a Class (so its type is then evident :))
- the receiver is 'self'
- the receiver is 'super'
a CandidateListOperatorAcceptingAnyKindOfReceiver compute a list of possible
type for a FamixInvocation's receiver when:
- the receiver is a Class (so its type is then evident :))
- the receiver is 'self'
- the receiver is 'super'
- the receiver is a FAMIXAttribute
should normally accept any kind of receiver, but all type are not yet
supported or implemented.
a CandidateListOperatorAcceptingBasicAndVariableReceivers compute a list of
possible type for a FamixInvocation's receiver when:
- the receiver is a Class (so its type is then evident :))
- the receiver is 'self'
- the receiver is 'super'
- the receiver is a FAMIXAttribute
a CandidateListOperatorAcceptingSimpleKindsOfReceiver compute a list of
possible type for a FamixInvocation's receiver when:
- the receiver is a Class (so its type is then evident :))
- the receiver is 'self'
- the receiver is 'super' (so does the same job than the original class)
a CandidateListOperatorNotAcceptingAnyReceiver doesn't compute any possible
type.
should normally accept any kind of receiver, but all type are not yet
supported or implemented.
2010/8/18 Simon Denier <Simon.Denier(a)inria.fr>
On 18 août 2010, at 16:27, Alexandre Bergel wrote:
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
Simon
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
I will try. In the meantime, I created a new
issue.
http://code.google.com/p/moose-technology/issues/detail?id=435
Maybe it would be better to open an issue about testing
AbstractCandidateListOperator subclasses, since they already use RoelTyper.
Cyrille, could you make a quick summary of the strategies available?
Cheers,
Alexandre
On 18 Aug 2010, at 09:42, Simon Denier wrote:
> Hi Alex
>
> Did you try the different strategies provided for invocations resolution
in
the importer wizard? Indeed, Cyrille coded a few strategies to use
RoelTyper for better method resolution (as well as inference of instance
variable types). Unfortunately, there are no test for this so I don't no how
reliable it is. I would love to have tests and precision/recall score for
these strategies!
>
>
>
> On 18 août 2010, at 15:21, Alexandre Bergel wrote:
>
>> Hi!
>>
>> I am analyzing Mondrian in Moose. One thing that I am bumping into, is
that wrong dependencies are inferred whereas I am sure that they do not
exist. This is not a new, we have to type in Smalltalk. For example:
>>
>> MOEdge>>fromPositions
>> ^ shape fromPositions
>>
>> #fromPositions is implemented 3 times, by MOAbstractLayout, MOEdge, and
MOLineShape.
>> In the case of
MOEdge>>fromPositions, I am sure that it does not invoke
MOAbstractLayout>>fromPositions
>>
>> I guess that everyone analyzing smalltalk code bumped into this very
situation.
>>
>> My question is how do we do in that case?
>> One easy solution, is to annotate Mondrian with an adequate pragma:
>>
>> MOEdge>>fromPositions
>> <invoke: #fromPositions of: MOLineShape>
>> ^ shape fromPositions
>>
>> We can decline this pragma into:
>> <doesNotInvoke: #selector of: AClass>
>> <invoke: #fromPositions of: #(MOLineShape MOEdge)>
>>
>> Simon told me Cyrille has worked on this problem. I am currently trying
to
use RoelTyper.
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
Simon
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
5:24 p.m.
On 18 août 2010, at 17:07, Cyrille Delaunay wrote:
So strategies available are:
a CandidateListOperator (the class used at the origin, could maybe be removed) compute a
list of possible type for a FamixInvocation's receiver when:
- the receiver is a Class (so its type is then evident :))
- the receiver is 'self'
- the receiver is 'super'
So now it''s the same as CandidateListOperatorAcceptingSimpleKindsOfReceiver
right?
a CandidateListOperatorAcceptingAnyKindOfReceiver compute a list of possible type for a
FamixInvocation's receiver when:
- the receiver is a Class (so its type is then evident :))
- the receiver is 'self'
- the receiver is 'super'
- the receiver is a FAMIXAttribute
should normally accept any kind of receiver, but all type are not yet supported or
implemented.
CandidateListOperatorAcceptingBasicAndVariableReceivers
CandidateListOperatorAcceptingSimpleKindsOfReceiver
are nowadays the same?
Nowadays there are some tests for candidates, which imply testing CandidateListOperator.
We should have independent tests for each strategy (best would be to extract the current
tests for candidates, and also start testing
CandidateListOperatorAcceptingBasicAndVariableReceivers which might have good precision)
a CandidateListOperatorAcceptingBasicAndVariableReceivers compute a list of possible
type for a FamixInvocation's receiver when:
- the receiver is a Class (so its type is then evident :))
- the receiver is 'self'
- the receiver is 'super'
- the receiver is a FAMIXAttribute
a CandidateListOperatorAcceptingSimpleKindsOfReceiver compute a list of possible type for
a FamixInvocation's receiver when:
- the receiver is a Class (so its type is then evident :))
- the receiver is 'self'
- the receiver is 'super' (so does the same job than the original class)
a CandidateListOperatorNotAcceptingAnyReceiver doesn't compute any possible type.
should normally accept any kind of receiver, but all type are not yet supported or
implemented.
2010/8/18 Simon Denier <Simon.Denier(a)inria.fr>
On 18 août 2010, at 16:27, Alexandre Bergel wrote:
--
Simon
I will try. In the meantime, I created a new
issue.
http://code.google.com/p/moose-technology/issues/detail?id=435
Maybe it would be better to open an issue about testing AbstractCandidateListOperator
subclasses, since they already use RoelTyper.
Cyrille, could you make a quick summary of the strategies available?
Cheers,
Alexandre
On 18 Aug 2010, at 09:42, Simon Denier wrote:
--
Simon
_______________________________________________
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 Hi Alex
Did you try the different strategies provided for invocations resolution in the importer
wizard? Indeed, Cyrille coded a few strategies to use RoelTyper for better method
resolution (as well as inference of instance variable types). Unfortunately, there are no
test for this so I don't no how reliable it is. I would love to have tests and
precision/recall score for these strategies!
On 18 août 2010, at 15:21, Alexandre Bergel wrote:
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev Hi!
I am analyzing Mondrian in Moose. One thing that I am bumping into, is that wrong
dependencies are inferred whereas I am sure that they do not exist. This is not a new, we
have to type in Smalltalk. For example:
MOEdge>>fromPositions
^ shape fromPositions
#fromPositions is implemented 3 times, by MOAbstractLayout, MOEdge, and MOLineShape.
In the case of MOEdge>>fromPositions, I am sure that it does not invoke
MOAbstractLayout>>fromPositions
I guess that everyone analyzing smalltalk code bumped into this very situation.
My question is how do we do in that case?
One easy solution, is to annotate Mondrian with an adequate pragma:
MOEdge>>fromPositions
<invoke: #fromPositions of: MOLineShape>
^ shape fromPositions
We can decline this pragma into:
<doesNotInvoke: #selector of: AClass>
<invoke: #fromPositions of: #(MOLineShape MOEdge)>
Simon told me Cyrille has worked on this problem. I am currently trying to use
RoelTyper.
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
Simon
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
19 Aug
19 Aug
9:37 a.m.
2010/8/18 Simon Denier <Simon.Denier(a)inria.fr>
On 18 août 2010, at 17:07, Cyrille Delaunay wrote:
So strategies available are:
a CandidateListOperator (the class used at the origin, could maybe be
removed) compute a list of possible type for a FamixInvocation's receiver
when:
- the receiver is a Class (so its type is then evident :))
- the receiver is 'self'
- the receiver is 'super'
So now it''s the same
as CandidateListOperatorAcceptingSimpleKindsOfReceiver right?
yes
a CandidateListOperatorAcceptingAnyKindOfReceiver compute a list of
possible type for a FamixInvocation's receiver when:
- the receiver is a Class (so its type is then evident :))
- the receiver is 'self'
- the receiver is 'super'
- the receiver is a FAMIXAttribute
should normally accept any kind of receiver, but all type are not yet
supported or implemented.
CandidateListOperatorAcceptingBasicAndVariableReceivers
CandidateListOperatorAcceptingSimpleKindsOfReceiver
are nowadays the same?
yes
Nowadays there are some tests for candidates, which imply
testing CandidateListOperator. We should have independent tests for each
strategy (best would be to extract the current tests for candidates, and
also start testing CandidateListOperatorAcceptingBasicAndVariableReceivers
which might have good precision)
a CandidateListOperatorAcceptingBasicAndVariableReceivers compute a list
of possible type for a FamixInvocation's receiver when:
- the receiver is a Class (so its type is then evident :))
- the receiver is 'self'
- the receiver is 'super'
- the receiver is a FAMIXAttribute
a CandidateListOperatorAcceptingSimpleKindsOfReceiver compute a list of
possible type for a FamixInvocation's receiver when:
- the receiver is a Class (so its type is then evident :))
- the receiver is 'self'
- the receiver is 'super' (so does the same job than the original class)
a CandidateListOperatorNotAcceptingAnyReceiver doesn't compute any possible
type.
should normally accept any kind of receiver, but all type are not yet
supported or implemented.
2010/8/18 Simon Denier <Simon.Denier(a)inria.fr>
On 18 août 2010, at 16:27, Alexandre Bergel wrote:
--
Simon
_______________________________________________
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
--
Simon
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
I will try. In the meantime, I created a new
issue.
http://code.google.com/p/moose-technology/issues/detail?id=435
Maybe it would be better to open an issue about testing
AbstractCandidateListOperator subclasses, since they already use RoelTyper.
Cyrille, could you make a quick summary of the strategies available?
Cheers,
Alexandre
On 18 Aug 2010, at 09:42, Simon Denier wrote:
> Hi Alex
>
> Did you try the different strategies provided for invocations
resolution in
the importer wizard? Indeed, Cyrille coded a few strategies to
use RoelTyper for better method resolution (as well as inference of instance
variable types). Unfortunately, there are no test for this so I don't no how
reliable it is. I would love to have tests and precision/recall score for
these strategies!
>
>
>
> On 18 août 2010, at 15:21, Alexandre Bergel wrote:
>
>> Hi!
>>
>> I am analyzing Mondrian in Moose. One thing that I am bumping into, is
that wrong dependencies are inferred whereas I am sure that they do not
exist. This is not a new, we have to type in Smalltalk. For example:
>>
>> MOEdge>>fromPositions
>> ^ shape fromPositions
>>
>> #fromPositions is implemented 3 times, by MOAbstractLayout, MOEdge,
and
MOLineShape.
>> In the case of
MOEdge>>fromPositions, I am sure that it does not
invoke
MOAbstractLayout>>fromPositions
>>
>> I guess that everyone analyzing smalltalk code bumped into this very
situation.
>>
>> My question is how do we do in that case?
>> One easy solution, is to annotate Mondrian with an adequate pragma:
>>
>> MOEdge>>fromPositions
>> <invoke: #fromPositions of: MOLineShape>
>> ^ shape fromPositions
>>
>> We can decline this pragma into:
>> <doesNotInvoke: #selector of: AClass>
>> <invoke: #fromPositions of: #(MOLineShape MOEdge)>
>>
>> Simon told me Cyrille has worked on this problem. I am currently
trying to
use RoelTyper.
>
> Cheers,
> Alexandre
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
Simon
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
18 Aug
18 Aug
5:31 p.m.
Yeah, this is what I thought.
Maybe we could introduce CandidateListTypeInferencer that use Roel Typer?
I entered what you said on http://code.google.com/p/moose-technology/issues/detail?id=435
Maybe something can be added to the Moose Book.
Cheers,
Alexandre
On 18 Aug 2010, at 11:07, Cyrille Delaunay wrote:
So strategies available are:
a CandidateListOperator (the class used at the origin, could maybe be removed) compute a
list of possible type for a FamixInvocation's receiver when:
- the receiver is a Class (so its type is then evident :))
- the receiver is 'self'
- the receiver is 'super'
a CandidateListOperatorAcceptingAnyKindOfReceiver compute a list of possible type for a
FamixInvocation's receiver when:
- the receiver is a Class (so its type is then evident :))
- the receiver is 'self'
- the receiver is 'super'
- the receiver is a FAMIXAttribute
should normally accept any kind of receiver, but all type are not yet supported or
implemented.
a CandidateListOperatorAcceptingBasicAndVariableReceivers compute a list of possible
type for a FamixInvocation's receiver when:
- the receiver is a Class (so its type is then evident :))
- the receiver is 'self'
- the receiver is 'super'
- the receiver is a FAMIXAttribute
a CandidateListOperatorAcceptingSimpleKindsOfReceiver compute a list of possible type for
a FamixInvocation's receiver when:
- the receiver is a Class (so its type is then evident :))
- the receiver is 'self'
- the receiver is 'super' (so does the same job than the original class)
a CandidateListOperatorNotAcceptingAnyReceiver doesn't compute any possible type.
should normally accept any kind of receiver, but all type are not yet supported or
implemented.
2010/8/18 Simon Denier <Simon.Denier(a)inria.fr>
On 18 août 2010, at 16:27, Alexandre Bergel wrote:
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
I will try. In the meantime, I created a new
issue.
http://code.google.com/p/moose-technology/issues/detail?id=435
Maybe it would be better to open an issue about testing AbstractCandidateListOperator
subclasses, since they already use RoelTyper.
Cyrille, could you make a quick summary of the strategies available?
Cheers,
Alexandre
On 18 Aug 2010, at 09:42, Simon Denier wrote:
--
Simon
_______________________________________________
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 Hi Alex
Did you try the different strategies provided for invocations resolution in the importer
wizard? Indeed, Cyrille coded a few strategies to use RoelTyper for better method
resolution (as well as inference of instance variable types). Unfortunately, there are no
test for this so I don't no how reliable it is. I would love to have tests and
precision/recall score for these strategies!
On 18 août 2010, at 15:21, Alexandre Bergel wrote:
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev Hi!
I am analyzing Mondrian in Moose. One thing that I am bumping into, is that wrong
dependencies are inferred whereas I am sure that they do not exist. This is not a new, we
have to type in Smalltalk. For example:
MOEdge>>fromPositions
^ shape fromPositions
#fromPositions is implemented 3 times, by MOAbstractLayout, MOEdge, and MOLineShape.
In the case of MOEdge>>fromPositions, I am sure that it does not invoke
MOAbstractLayout>>fromPositions
I guess that everyone analyzing smalltalk code bumped into this very situation.
My question is how do we do in that case?
One easy solution, is to annotate Mondrian with an adequate pragma:
MOEdge>>fromPositions
<invoke: #fromPositions of: MOLineShape>
^ shape fromPositions
We can decline this pragma into:
<doesNotInvoke: #selector of: AClass>
<invoke: #fromPositions of: #(MOLineShape MOEdge)>
Simon told me Cyrille has worked on this problem. I am currently trying to use
RoelTyper.
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
Simon
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
8:25 p.m.
On 18 août 2010, at 17:31, Alexandre Bergel wrote:
Yeah, this is what I thought.
Maybe we could introduce CandidateListTypeInferencer that use Roel Typer?
Once again, Roel Typer is already used in
CandidateListOperatorAcceptingBasicAndVariableReceivers and
CandidateListOperatorAcceptingAnyKindOfReceiver
to compute possible types for attributes.
See #computeInstanceVariableCandidateListFor:
Now there is still work to do
I entered what you said on
http://code.google.com/p/moose-technology/issues/detail?id=435
Maybe something can be added to the Moose Book.
Cheers,
Alexandre
On 18 Aug 2010, at 11:07, Cyrille Delaunay wrote:
--
Simon
So strategies available are:
a CandidateListOperator (the class used at the origin, could maybe be removed) compute a
list of possible type for a FamixInvocation's receiver when:
- the receiver is a Class (so its type is then evident :))
- the receiver is 'self'
- the receiver is 'super'
a CandidateListOperatorAcceptingAnyKindOfReceiver compute a list of possible type for a
FamixInvocation's receiver when:
- the receiver is a Class (so its type is then evident :))
- the receiver is 'self'
- the receiver is 'super'
- the receiver is a FAMIXAttribute
should normally accept any kind of receiver, but all type are not yet supported or
implemented.
a CandidateListOperatorAcceptingBasicAndVariableReceivers compute a list of possible
type for a FamixInvocation's receiver when:
- the receiver is a Class (so its type is then evident :))
- the receiver is 'self'
- the receiver is 'super'
- the receiver is a FAMIXAttribute
a CandidateListOperatorAcceptingSimpleKindsOfReceiver compute a list of possible type for
a FamixInvocation's receiver when:
- the receiver is a Class (so its type is then evident :))
- the receiver is 'self'
- the receiver is 'super' (so does the same job than the original class)
a CandidateListOperatorNotAcceptingAnyReceiver doesn't compute any possible type.
should normally accept any kind of receiver, but all type are not yet supported or
implemented.
2010/8/18 Simon Denier <Simon.Denier(a)inria.fr>
On 18 août 2010, at 16:27, Alexandre Bergel wrote:
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev I will try. In the meantime, I created a new
issue.
http://code.google.com/p/moose-technology/issues/detail?id=435
Maybe it would be better to open an issue about testing AbstractCandidateListOperator
subclasses, since they already use RoelTyper.
Cyrille, could you make a quick summary of the strategies available?
Cheers,
Alexandre
On 18 Aug 2010, at 09:42, Simon Denier wrote:
--
Simon
_______________________________________________
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 Hi Alex
Did you try the different strategies provided for invocations resolution in the importer
wizard? Indeed, Cyrille coded a few strategies to use RoelTyper for better method
resolution (as well as inference of instance variable types). Unfortunately, there are no
test for this so I don't no how reliable it is. I would love to have tests and
precision/recall score for these strategies!
On 18 août 2010, at 15:21, Alexandre Bergel wrote:
> Hi!
>
> I am analyzing Mondrian in Moose. One thing that I am bumping into, is that wrong
dependencies are inferred whereas I am sure that they do not exist. This is not a new, we
have to type in Smalltalk. For example:
>
> MOEdge>>fromPositions
> ^ shape fromPositions
>
> #fromPositions is implemented 3 times, by MOAbstractLayout, MOEdge, and MOLineShape.
> In the case of MOEdge>>fromPositions, I am sure that it does not invoke
MOAbstractLayout>>fromPositions
>
> I guess that everyone analyzing smalltalk code bumped into this very situation.
>
> My question is how do we do in that case?
> One easy solution, is to annotate Mondrian with an adequate pragma:
>
> MOEdge>>fromPositions
> <invoke: #fromPositions of: MOLineShape>
> ^ shape fromPositions
>
> We can decline this pragma into:
> <doesNotInvoke: #selector of: AClass>
> <invoke: #fromPositions of: #(MOLineShape MOEdge)>
>
> Simon told me Cyrille has worked on this problem. I am currently trying to use
RoelTyper.
>
> Cheers,
> Alexandre
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
Simon
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 
19 Aug
19 Aug
11:27 a.m.
On Aug 18, 2010, at 3:21 PM, Alexandre Bergel wrote:
Hi!
I am analyzing Mondrian in Moose.
Excellent this is the best thing that we can do: using moose to analyse our own software.
We want to do that for pharo too.
One thing that I am bumping into, is that wrong
dependencies are inferred whereas I am sure that they do not exist. This is not a new, we
have to type in Smalltalk. For example:
MOEdge>>fromPositions
^ shape fromPositions
#fromPositions is implemented 3 times, by MOAbstractLayout, MOEdge, and MOLineShape.
In the case of MOEdge>>fromPositions, I am sure that it does not invoke
MOAbstractLayout>>fromPositions
yes but how a analyser can get that?
I guess that everyone analyzing smalltalk code bumped into this very situation.
My question is how do we do in that case?
One easy solution, is to annotate Mondrian with an adequate pragma:
MOEdge>>fromPositions
<invoke: #fromPositions of: MOLineShape>
^ shape fromPositions
the problem with static information is that it may fast get desynchronised
We can decline this pragma into:
<doesNotInvoke: #selector of: AClass>
<invoke: #fromPositions of: #(MOLineShape MOEdge)>
Simon told me Cyrille has worked on this problem. I am currently trying to use
RoelTyper.
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
11:38 a.m.
Hi,
On 19 Aug 2010, at 11:27, Stéphane Ducasse wrote:
--
www.tudorgirba.com
"Obvious things are difficult to teach."
On Aug 18, 2010, at 3:21 PM, Alexandre Bergel wrote:
I agree. Except if you have a nice PluggableType system that can also
ensure some level of checking, you do not want to have these kind of
annotations in your source code.
Cheers,
Doru
Hi!
I am analyzing Mondrian in Moose.
Excellent this is the best thing that we can do: using moose to
analyse our own software.
We want to do that for pharo too.
One thing that I am bumping into, is that wrong
dependencies are
inferred whereas I am sure that they do not exist. This is not a
new, we have to type in Smalltalk. For example:
MOEdge>>fromPositions
^ shape fromPositions
#fromPositions is implemented 3 times, by MOAbstractLayout, MOEdge,
and MOLineShape.
In the case of MOEdge>>fromPositions, I am sure that it does not
invoke MOAbstractLayout>>fromPositions
yes but how a analyser can get that?
I guess that everyone analyzing smalltalk code bumped into this
very situation.
My question is how do we do in that case?
One easy solution, is to annotate Mondrian with an adequate pragma:
MOEdge>>fromPositions
<invoke: #fromPositions of: MOLineShape>
^ shape fromPositions
the problem with static information is that it may fast get
desynchronised
We can decline this pragma into:
<doesNotInvoke: #selector of: AClass>
<invoke: #fromPositions of: #(MOLineShape MOEdge)>
Simon told me Cyrille has worked on this problem. I am currently
trying to use RoelTyper.
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
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
4999
days inactive
5000
days old
10 comments
5 participants
participants (5)
-
Alexandre Bergel -
Cyrille Delaunay -
Simon Denier -
Stéphane Ducasse -
Tudor Girba