Smalltalk › Frameworks & Tools › Moose

Change in FAME

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

6 messages Options

DiegoLont

Change in FAME

Hi all,

I wanted to update FAME so it is a bit more memory efficient: it now has a null multi value link that allows for an "empty" multi value link, that uses a lot less memory. And since this is about 80% of the links, I thought this was a good idea.

Now I run into a test, that doesn't work anymore (actually 3 test). But when debugging the test I cannot find the error, it always returns the expected value. Changing the order of the tests helps (why I do not know). So if someone can take a look. The test cases are
testFamixMethodTypeDeclarationsWithoutSelfLoops
testFamixMethodOutgoingTypeDeclarations
testFamixClassOutgoingTypeDeclarations

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

Stephan Eggermont-3

Re: Change in FAME

The changes were made in

Moose-Tests-SmalltalkImporter-KGB-DiegoLont.27
Fame-Core-DiegoLont.17
Famix-Core-DiegoLont.225

- fix issue 975 remove:ifAbsent:
- Add a FMNullMultivalueLink and use that when there are no values
yet. FMMultivalueLink allocates an OrderedCollection (with default
space for 10 items) as values. In the models we have, about 85%
of the multivaluelinks are empty. In WhiteStar, we save about 10MB.
- replace initiializations with FMMultivalueLink through FMNullMultivalueLink
in Famix-Core
- reordered tests. We would like some comments on that.

Stephan

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

Nicolas Anquetil

Re: Change in FAME

In reply to this post by DiegoLont

did you run the tests before?
I believe I saw some of them fail in the past ... ?

nicolas

On 08/30/2013 04:06 PM, Diego Lont wrote:

> Hi all,
>
> I wanted to update FAME so it is a bit more memory efficient: it now has a null multi value link that allows for an "empty" multi value link, that uses a lot less memory. And since this is about 80% of the links, I thought this was a good idea.
>
> Now I run into a test, that doesn't work anymore (actually 3 test). But when debugging the test I cannot find the error, it always returns the expected value. Changing the order of the tests helps (why I do not know). So if someone can take a look. The test cases are
> testFamixMethodTypeDeclarationsWithoutSelfLoops
> testFamixMethodOutgoingTypeDeclarations
> testFamixClassOutgoingTypeDeclarations
>
> Cheers,
> Diego
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

--
Nicolas Anquetil -- RMod research team (Inria)

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

Stephan Eggermont-3

Re: Change in FAME

In reply to this post by DiegoLont

Nicolas wrote:
>did you run the tests before?
>I believe I saw some of them fail in the past ... ?

Uhm, we broke the build from 981 to 984,
but I'm not aware of earlier problems.

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

Tudor Girba-2

Re: Change in FAME

Hi,

I went a bit over your code. Interesting finding. We had a similar idea with MooseMinimalState, but you are bringing it forward.

After loading your improvement, I get on the ArgoUML 0.34:

FMNullMultivalueLink allInstances size ==> 567234

FMMultivalueLink allInstances size ==> 103591

This is signifiant! Good catch.

However, there is still an issue with the way you are dynamically transforming the null value into a real value:

noMoreNull

self owner instVarNamed: self selector put:

(FMMultivalueLink on: self owner opposite: self opposite).

^(self owner perform: self selector)

Here you are assuming that there is an instance variable with the name of the selector. This is brittle. We need to find a better way.

Doru

On Fri, Aug 30, 2013 at 9:31 PM, Stephan Eggermont <[hidden email]> wrote:

Nicolas wrote:
>did you run the tests before?
>I believe I saw some of them fail in the past ... ?

Uhm, we broke the build from 981 to 984,
but I'm not aware of earlier problems.

Stephan

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

www.tudorgirba.com

"Every thing has its own flow"

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

Anne Etien

Re: Change in FAME

Hi,

The introduction of FMNullMultivalueLink leads to error in Orion. So we made some modifications.

Most specifically, the remark of Doru concerning the assumed presence of a selector with the same name raised issues in Orion. To correct that, noMoreNull has been modified to:

noMoreNull
^ (self owner instVarNamed: self selector put:
(FMMultivalueLink on: self owner opposite: self opposite)).

We also modified FMNullMultivalueLink >>unsafeadd (by adding the return):

unsafeAdd: anElement

^self noMoreNull unsafeAdd: anElement

And finally, we remove the species method in order it returns a FMNullMultivalueLink and not an OrderedCollection.

We committed these changes and the tests of Moose remain green. The tests of Orion are now green.

Anne

Le 1 sept. 2013 à 07:56, Tudor Girba a écrit :

Hi,

I went a bit over your code. Interesting finding. We had a similar idea with MooseMinimalState, but you are bringing it forward.

After loading your improvement, I get on the ArgoUML 0.34:

FMNullMultivalueLink allInstances size ==> 567234
FMMultivalueLink allInstances size ==> 103591

This is signifiant! Good catch.

However, there is still an issue with the way you are dynamically transforming the null value into a real value:

noMoreNull

self owner instVarNamed: self selector put:
(FMMultivalueLink on: self owner opposite: self opposite).
^(self owner perform: self selector)

Here you are assuming that there is an instance variable with the name of the selector. This is brittle. We need to find a better way.

Doru

On Fri, Aug 30, 2013 at 9:31 PM, Stephan Eggermont <[hidden email]> wrote:

Nicolas wrote:
>did you run the tests before?
>I believe I saw some of them fail in the past ... ?

Uhm, we broke the build from 981 to 984,
but I'm not aware of earlier problems.

Stephan

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

--
www.tudorgirba.com

"Every thing has its own flow"

_______________________________________________
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