Method invocation for Smalltalk code in Moose

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Method invocation for Smalltalk code in Moose

Alexandre Bergel
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
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: Method invocation for Smalltalk code in Moose

Simon Denier-3
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
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

--
 Simon




_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: Method invocation for Smalltalk code in Moose

Alexandre Bergel
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:
>
>> 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
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> Simon
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.






_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: Method invocation for Smalltalk code in Moose

Simon Denier-3

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:
>
>> 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
>>> [hidden email]
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> --
>> Simon
>>
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

--
 Simon




_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: Method invocation for Smalltalk code in Moose

cdelaunay
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 <[hidden email]>

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:
>
>> 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
>>> [hidden email]
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> --
>> Simon
>>
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

--
 Simon




_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: Method invocation for Smalltalk code in Moose

Simon Denier-3

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 <[hidden email]>

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:
>
>> 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
>>> [hidden email]
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> --
>> Simon
>>
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

--
 Simon




_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

--
 Simon




_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: Method invocation for Smalltalk code in Moose

Alexandre Bergel
In reply to this post by cdelaunay
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 <[hidden email]>
>
> 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:
> >
> >> 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
> >>> [hidden email]
> >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
> >>
> >> --
> >> Simon
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> Moose-dev mailing list
> >> [hidden email]
> >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
> >>
> >
> > --
> > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> > Alexandre Bergel  http://www.bergel.eu
> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > Moose-dev mailing list
> > [hidden email]
> > https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
>  Simon
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.






_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: Method invocation for Smalltalk code in Moose

Simon Denier-3

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:
>
>> 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 <[hidden email]>
>>
>> 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:
>>>
>>>> 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
>>>>> [hidden email]
>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>
>>>> --
>>>> Simon
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>> [hidden email]
>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>
>>>
>>> --
>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>> Alexandre Bergel  http://www.bergel.eu
>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> [hidden email]
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> --
>> Simon
>>
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

--
 Simon




_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: Method invocation for Smalltalk code in Moose

cdelaunay
In reply to this post by Simon Denier-3


2010/8/18 Simon Denier <[hidden email]>

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 <[hidden email]>

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:
>
>> 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
>>> [hidden email]
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> --
>> Simon
>>
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

--
 Simon




_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

--
 Simon




_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev



_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: Method invocation for Smalltalk code in Moose

Stéphane Ducasse
In reply to this post by Alexandre Bergel

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
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: Method invocation for Smalltalk code in Moose

Tudor Girba
Hi,


On 19 Aug 2010, at 11:27, Stéphane Ducasse wrote:

>
> 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

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


>>
>> 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
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

--
www.tudorgirba.com

"Obvious things are difficult to teach."




_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev