broken tests :)

Hi Nicolas,

Thanks a lot.

I looked quickly into this. There is at least a simple problem: you are calling queryAllOutgoingDependencies, but this method does not exist anymore. I guess we should replace this with queryAllOutgoingAssociations.

Is this due to a wrongly published refactoring?

Cheers,
Doru



On 30 Jan 2012, at 23:58, Nicolas Anquetil wrote:

>
> Hi,
>
> I already spent 4 hours on this and am not anywhere near the solution :-(
> I think I got myself on a wrong track and cannot get out of it.
>
> So I will ask your help see if you can do better.
>
> From what I understood, the problem is not related to the metrics, but comes
> from accesses to global variables.
> When one does a atClassScope on a queryResult containing an access to a global
> variable, this one returns nil to the message claassScope (this is normal),
> and for some reason that I cannot understand the nil gets inserted in the
> storage of the queryResult in some cases (not always) in the form of a
> SetElement containing it.
>
>
> After lot of debugging, I finally got a method (LANInterface>>originate() )
> that accesses (among other things) SmalltalkGlobalVariable.
>
> My problem is that from here the behaviour seems heratic to me :-(
>
> - 'theMethod queryOutgoingAccesses atClassScope' works,so it does filter out
> the nil coming from the 'SmalltalkGlobalVariable classScope'
> - 'theMethod queryOutgoingReferences atClassScope' also works (there is no
> global variable involved there anyway)
> - 'theMethod queryStaticOutgoingAssociations atClassScope', does not work, it
> contains a SetElement that contains a nil :-(
>
> What baffles me is that the definition of
> FAMIXMethod>>queryStaticOutgoingAssociations is:
>       ^ self queryOutgoingAccesses
>               addAll: self queryOutgoingReferences;
>               "addAll: self queryOutgoingInheritances;     -- inheritance does not
> make sense here"
>               yourself.
>
> I even simplified it a bit to be more sure: staticAssociations = all access +
> all inheritance.
>
> So taken together they exhibit the problem, but taking access alone access
> does not exhibit it.
> If I manually remove all references from the queryStaticOutgoingAssociations'
> result, then it works again, which is logical because this is the same as
> asking 'queryOutgoingAccesses' which already works
>
> Note: to remove elements from the resutls, I use an inspector on the
> MooseQueryResult: 'storage := storage reject: [:a|a class == FAMIXReference]'
>
> Even stranger to me, if I manually remove only one of the references (eg:
> 'storage := storage reject: [:a|a to name = 'String']'), then the result
> starts to be correct again.
>
>
> The test used to built the particular model I am wroking on is
> MooseModelOverviewPyramidExtensionsTest>>testoverviewPyramidMetrics
>
> So here I am.
> Maybe you can provide some fresh view on it?
>
>
> On Monday 30 January 2012 15:09:12 Tudor Girba wrote:
>> Thanks a lot. I ran the tests again and only 6 still have errors:
>> http://ci.moosetechnology.org/job/moose-latest-dev/804/testReport/
>>
>> Let us know how it works.
>>
>> Cheers,
>> Doru
>>
>>
>>
>> On Mon, Jan 30, 2012 at 11:01 AM, Nicolas Anquetil

>>
>> <[hidden email]> wrote:
>>> I looked at it.
>>>
>>> Problem is that I forgot to migrate some metrics from SoftEngMetrics to
>>> famix- extension-metrics. So it was correct in my image but not in the
>>> standard one.
>>>
>>> This is corrected.
>>>
>>> I am still having problems with a test in FAMIXPropertiesTest
>>>
>>> It creates a strange situation where a MooseObjectQuery contains a
>>> SetElement containing a SetElement containing nil.
>>> So the problem might come from some unrelated place.
>>>
>>> First the test class FAMIXPropertiesTest gave me troubles because there
>>> are two of them (one in Moose-Tests-SmalltalkImporter-KGB and one in
>>> Moose-Tests- SmalltalkImporter-core).
>>>
>>> Second, I am teaching today, so I don't have lot of time to devote to
>>> this at this moment.
>>>
>>> So I will leave that for further study tonight or tomorrow.
>>>
>>>
>>> nicolas
>>>
>>> On Sunday 29 January 2012 22:32:54 Tudor Girba wrote:
>>>> I forgot the link:
>>>> http://ci.moosetechnology.org/job/moose-latest-dev/803/testReport/
>>>>
>>>> Cheers,
>>>> Doru
>>>>
>>>> On 29 Jan 2012, at 22:13, Tudor Girba wrote:
>>>>> Hi Nicolas,
>>>>>
>>>>> Your latest changes produced some errors in tests.
>>>>>
>>>>> The troubled seems to be triggered by you removing some methods
>>>>> from
>>>>> FAMIXClassGroup, like abstractness.
>>>>>
>>>>> Could you take a look?
>>>>>
>>>>> Cheers,
>>>>> Doru
>>>>>
>>>>>
>>>>> --
>>>>> www.tudorgirba.com
>>>>>
>>>>> "What is more important: To be happy, or to make happy?"
>>>>
>>>> --
>>>> www.tudorgirba.com
>>>>
>>>> "What we can governs what we wish."
>>>
>>> --
>>> Nicolas Anquetil -- RMod team
>>> INRIA Lille Nord Europe
> --
> Nicolas Anquetil -- RMod team
> INRIA Lille Nord Europe

--
www.tudorgirba.com

"To utilize feedback, you first have to acquire it."

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

Hi,

I had a look on that.

The problem is that in the method #primCollectAtScope, when the #collectAsSet finds a classScope = nil (for example, in a GlobaVariable) it inserts a SetElement and not nil.

primCollectAtScope: aScopeSymbol
    "
    ^ self opposites collectAtScope: aScopeSymbol
    "

    ^self storage collectAsSet: [ :dep | (self opposite: dep) perform: aScopeSymbol ].

See the difference:
#(nil) collectAsSet: #yourself.
#(nil) collect: #yourself.

So, if you check the method #collectAtScope: there is a filter for nil elements, but we will never have nil (just SetElement).

One trivial solution is:
primCollectAtScope: aScopeSymbol
    "
    ^ self opposites collectAtScope: aScopeSymbol
    "

    ^ (self storage collect: [ :dep | (self opposite: dep) perform: aScopeSymbol ]) asSet

I just commited it and the tests are green for FamixPropertiesTest.testHasTheSamePropertiesAs

ps: also updated the invocation from #queryAllOutgoingDependencies to #queryAllOutgoingAssociations Doru cited last email.

On Tue, Jan 31, 2012 at 8:43 PM, Tudor Girba <[hidden email]> wrote:

Hi Nicolas,

Thanks a lot.

I looked quickly into this. There is at least a simple problem: you are calling queryAllOutgoingDependencies, but this method does not exist anymore. I guess we should replace this with queryAllOutgoingAssociations.

Is this due to a wrongly published refactoring?

Cheers,
Doru



On 30 Jan 2012, at 23:58, Nicolas Anquetil wrote:

>
> Hi,
>
> I already spent 4 hours on this and am not anywhere near the solution :-(
> I think I got myself on a wrong track and cannot get out of it.
>
> So I will ask your help see if you can do better.
>
> From what I understood, the problem is not related to the metrics, but comes
> from accesses to global variables.
> When one does a atClassScope on a queryResult containing an access to a global
> variable, this one returns nil to the message claassScope (this is normal),
> and for some reason that I cannot understand the nil gets inserted in the
> storage of the queryResult in some cases (not always) in the form of a
> SetElement containing it.
>
>
> After lot of debugging, I finally got a method (LANInterface>>originate() )
> that accesses (among other things) SmalltalkGlobalVariable.
>
> My problem is that from here the behaviour seems heratic to me :-(
>
> - 'theMethod queryOutgoingAccesses atClassScope' works,so it does filter out
> the nil coming from the 'SmalltalkGlobalVariable classScope'
> - 'theMethod queryOutgoingReferences atClassScope' also works (there is no
> global variable involved there anyway)
> - 'theMethod queryStaticOutgoingAssociations atClassScope', does not work, it
> contains a SetElement that contains a nil :-(
>
> What baffles me is that the definition of
> FAMIXMethod>>queryStaticOutgoingAssociations is:
>       ^ self queryOutgoingAccesses
>               addAll: self queryOutgoingReferences;
>               "addAll: self queryOutgoingInheritances;     -- inheritance does not
> make sense here"
>               yourself.
>
> I even simplified it a bit to be more sure: staticAssociations = all access +
> all inheritance.
>
> So taken together they exhibit the problem, but taking access alone access
> does not exhibit it.
> If I manually remove all references from the queryStaticOutgoingAssociations'
> result, then it works again, which is logical because this is the same as
> asking 'queryOutgoingAccesses' which already works
>
> Note: to remove elements from the resutls, I use an inspector on the
> MooseQueryResult: 'storage := storage reject: [:a|a class == FAMIXReference]'
>
> Even stranger to me, if I manually remove only one of the references (eg:
> 'storage := storage reject: [:a|a to name = 'String']'), then the result
> starts to be correct again.
>
>
> The test used to built the particular model I am wroking on is
> MooseModelOverviewPyramidExtensionsTest>>testoverviewPyramidMetrics
>
> So here I am.
> Maybe you can provide some fresh view on it?
>
>
> On Monday 30 January 2012 15:09:12 Tudor Girba wrote:
>> Thanks a lot. I ran the tests again and only 6 still have errors:
>> http://ci.moosetechnology.org/job/moose-latest-dev/804/testReport/
>>
>> Let us know how it works.
>>
>> Cheers,
>> Doru
>>
>>
>>
>> On Mon, Jan 30, 2012 at 11:01 AM, Nicolas Anquetil

>>
>> <[hidden email]> wrote:
>>> I looked at it.
>>>
>>> Problem is that I forgot to migrate some metrics from SoftEngMetrics to
>>> famix- extension-metrics. So it was correct in my image but not in the
>>> standard one.
>>>
>>> This is corrected.
>>>
>>> I am still having problems with a test in FAMIXPropertiesTest
>>>
>>> It creates a strange situation where a MooseObjectQuery contains a
>>> SetElement containing a SetElement containing nil.
>>> So the problem might come from some unrelated place.
>>>
>>> First the test class FAMIXPropertiesTest gave me troubles because there
>>> are two of them (one in Moose-Tests-SmalltalkImporter-KGB and one in
>>> Moose-Tests- SmalltalkImporter-core).
>>>
>>> Second, I am teaching today, so I don't have lot of time to devote to
>>> this at this moment.
>>>
>>> So I will leave that for further study tonight or tomorrow.
>>>
>>>
>>> nicolas
>>>
>>> On Sunday 29 January 2012 22:32:54 Tudor Girba wrote:
>>>> I forgot the link:
>>>> http://ci.moosetechnology.org/job/moose-latest-dev/803/testReport/
>>>>
>>>> Cheers,
>>>> Doru
>>>>
>>>> On 29 Jan 2012, at 22:13, Tudor Girba wrote:
>>>>> Hi Nicolas,
>>>>>
>>>>> Your latest changes produced some errors in tests.
>>>>>
>>>>> The troubled seems to be triggered by you removing some methods
>>>>> from
>>>>> FAMIXClassGroup, like abstractness.
>>>>>
>>>>> Could you take a look?
>>>>>
>>>>> Cheers,
>>>>> Doru
>>>>>
>>>>>
>>>>> --
>>>>> www.tudorgirba.com
>>>>>
>>>>> "What is more important: To be happy, or to make happy?"
>>>>
>>>> --
>>>> www.tudorgirba.com
>>>>
>>>> "What we can governs what we wish."
>>>
>>> --
>>> Nicolas Anquetil -- RMod team
>>> INRIA Lille Nord Europe
> --
> Nicolas Anquetil -- RMod team
> INRIA Lille Nord Europe

--
www.tudorgirba.com

"To utilize feedback, you first have to acquire it."

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

--
Andre Hora