Hi,
I see in some methods that there is a double cache lookup for
compatibility purposes.
We can see for example #numberOfLinesOfCode with the lookup for #LOC,
#numberOfStatements with #NOS and #cyclomaticComplexity with #CYCLO.
Those changes were done 7 years ago. Should we still keep those
compatibility lookup or do you think it is time to remove them? Because,
when applied to thousands of entities this can slow down some
operations. For small models it is acceptable but for really large model
it would be cool if we could done only one lookup.
I am waiting your opinion on this :)
--
Cyril Ferlicot
https://ferlicot.frhttp://www.synectique.eu
2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France
Le 23/09/2017 à 21:01, Stéphane Ducasse a écrit :
>
> I was thinking more about Moose, Seaside…..
> Because Pharo is not that large. Even if we can remove things.
> And the bootstrap is not really related to that.
>
From Moose we get only FAME and FAMIX, but we can restrict a little more
FAMIX. I would like to make groups depending of the language because for
now we load everything for every language. Not loading the Smalltalk
package into non smalltalk technologies would help us to reduce the time
of queries.
For Seaside I opened an issue on Seaside issue tracker some weeks ago to
be able to load seaside without the tests. It will probably be done for
Seaside 3.3.
Then I think we use pretty much everything that we load on top of Pharo.
>
> ok do you know when the queries dict is used?
> Because this is the first time I hear about it.
>
Here is the list of usages I see:
- MooseModel use it to save bookmarks
- FAMIXContainerEntity use it in #classes
- FAMIXNamespace use it for #methods
- FAMIXPackage use it for #classes, #concernedClassesCollection,
#extendedClasses, #extensionClasses, #extensionMethods, #localMethods
- Other FAMIXXXX use it that way
- MooseAbstractGroup use it in the #allModelXXX methods and
#allWithSubTypesOf:
…
>
> --------------------------------------------
> Stéphane Ducasse
> http://stephane.ducasse.free.fr
> http://www.synectique.eu / http://www.pharo.org
> 03 59 35 87 52
> Assistant: Julie Jonas
> FAX 03 59 57 78 50
> TEL 03 59 35 86 16
> S. Ducasse - Inria
> 40, avenue Halley,
> Parc Scientifique de la Haute Borne, Bât.A, Park Plaza
> Villeneuve d'Ascq 59650
> France
>
--
Cyril Ferlicot
https://ferlicot.frhttp://www.synectique.eu
2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France
Once again I hit the wrong button… Forwarding.
-------- Message transféré --------
Sujet : Re: [Moose-dev] Re: Time to clean old compatibility code?
Date : Sun, 24 Sep 2017 10:45:42 +0200
De : Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com>
Pour : Stéphane Ducasse <stephane.ducasse(a)inria.fr>
Le 24/09/2017 à 09:11, Stéphane Ducasse a écrit :
> can you send the code so that we really understand what is the double
> cache lookup?
numberOfStatements
<MSEProperty: #numberOfStatements type: #Number>
<MSEComment: 'The number of statements in a method'>
^ self
lookUpPropertyNamed: #numberOfStatements
computedAs: [
"This is needed for providing backward compatibility to exporters
that use NOS as a property name"
self
lookUpPropertyNamed: #NOS
computedAs: [
self mooseModel isSmalltalk
ifTrue: [
| parser |
parser := RBVisitorForFAMIXMetrics new.
parser processMethod: self usingImporter: nil inModel: nil.
parser numberOfStatements ]
ifFalse: [ self notExistentMetricValue ] ] ]
>
> --------------------------------------------
> Stéphane Ducasse
> http://stephane.ducasse.free.fr
> http://www.synectique.eu / http://www.pharo.org
> 03 59 35 87 52
> Assistant: Julie Jonas
> FAX 03 59 57 78 50
> TEL 03 59 35 86 16
> S. Ducasse - Inria
> 40, avenue Halley,
> Parc Scientifique de la Haute Borne, Bât.A, Park Plaza
> Villeneuve d'Ascq 59650
> France
>
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)list.inf.unibe.ch
> https://www.list.inf.unibe.ch/listinfo/moose-dev
>
--
Cyril Ferlicot
https://ferlicot.frhttp://www.synectique.eu
2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France
I forward because I cliked "answer" instead of "answer all"…
-------- Message transféré --------
Sujet : Re: [Moose-dev] Re: MooseDefaultState
Date : Sat, 23 Sep 2017 20:30:14 +0200
De : Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com>
Pour : Stéphane Ducasse <stephane.ducasse(a)inria.fr>
Le 23/09/2017 à 20:12, Stéphane Ducasse a écrit :
>
>
> cyril can you explain to me what is for queries?
> Did you check if there are smalldictionary?
>
In the MooseDefaultState there is 4 ivar.
entity : the entity using this state
attributes : a way to add dynamically properties to save. This
dictionary is never reset.
properties and queries : those two are caches that can be reset. They
save the result of long operations as #numberOfLinesOfCodes
But I do not know why we have two dictionaries instead of one and I
would like to know.
>>
>> Image without model : 263Mo
> Just loading the code takes that amount of space?
> Are you sure that we use all that?
>
This is what my Window's memory manager tell me. I'm sure we can remove
a lot of thing but I was waiting more progresses on the Bootstrap to
explore the possibility to reduce image size.
>> Image with model and default synectique caches : 650Mo
> What is a synectique caches?
>
After loading a model we launch the build of some caches in order to get
usable interfaces directly. Else some browsers can take 30sec to first
load then they take less than 1sec. To avoid this we generate some of
those caches at loading.
>> Image without model : 263Mo
>> Image with model : 589Mo
> so this is 6 mo so 1%?
>
The most interesting part is when we already use caches. The grow in
memory of the caches is reduced.
>
> Yes I would like to know.
> Do you know if the keys of “queries” clash with the keys of properties?
I tried in the application I am working on and there is none in this model.
Here is the script:
states := MooseModel allSubInstances first entities collect: #privateState.
MooseDefaultState compile: 'allPropertiesKeys
^ propertyCache keys'.
MooseDefaultState compile: 'allQueriesKeys
^ queryCache keys'.
properties := states flatCollectAsSet: #allPropertiesKeys.
queries := states flatCollectAsSet: #allQueriesKeys.
properties size = (properties \ queries) size. "true"
>
> --------------------------------------------
> Stéphane Ducasse
> http://stephane.ducasse.free.fr
> http://www.synectique.eu / http://www.pharo.org
> 03 59 35 87 52
> Assistant: Julie Jonas
> FAX 03 59 57 78 50
> TEL 03 59 35 86 16
> S. Ducasse - Inria
> 40, avenue Halley,
> Parc Scientifique de la Haute Borne, Bât.A, Park Plaza
> Villeneuve d'Ascq 59650
> France
>
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)list.inf.unibe.ch
> https://www.list.inf.unibe.ch/listinfo/moose-dev
>
--
Cyril Ferlicot
https://ferlicot.frhttp://www.synectique.eu
2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France
Hi,
Alex Syrel, Andrei Chis and I are happy to announce a new addition to the
Glamorous Toolkit:
GTSpotter, a novel interface for spotting objects.
GTSpotter has two goals:
- Provide a uniform yet moldable interface that can work on any object, and
- Handle searching through arbitrary levels of object nesting.
We think this will have a significant impact on the development workflow in
Pharo.
Here is a couple of screenshots:
[image: Inline image 2] [image: Inline image 1] [image: Inline image 3]
A trailer is available here:
https://www.youtube.com/watch?v=PhSmjR3NOlU
A detailed description is available here:
http://www.humane-assessment.com/blog/introducing-gtspotter
It works already in Pharo 3.0 and can be played with by following the
instructions from:
http://gt.moosetechnology.org
Please let us know what you think.
Enjoy,
The Glamorous Team
Hi
for certain metrics we need to compute the total amount of lines of code for the complete project.
FAMIXClass >> calculateARLCOMUnderstand
"Class LCOM LOC
C1 12 1000
C2 2 50
For C1 1000/1050 * 12
For C2 50/1050 * 2
"
self halt.
^ self TR_LoC / self mooseModel TR_totalNumberOfLinesOfCode * self TR_LCOM
Now I have a question because totalNumberOfLinesOfCode does exist on Model but on TypeGroup
I wrote it like that on FAMIXTypeGroup
TR_totalNumberOfLinesOfCode
<MSEProperty: #TR_totalNumberOfLinesOfCode type: #Number>
<derived>
<MSEComment: 'Total number of lines of code from Understand'>
^ self
lookUpPropertyNamed: #TR_totalNumberOfLinesOfCode
computedAs: [ (self sumNumbers: [ :each | each TR_LoC ]) asFloat ]
How can I access for example totalNumberOfLinesOfCode at the model level?
Stef
--------------------------------------------
Stéphane Ducasse
http://stephane.ducasse.free.frhttp://www.synectique.eu / http://www.pharo.org
03 59 35 87 52
Assistant: Julie Jonas
FAX 03 59 57 78 50
TEL 03 59 35 86 16
S. Ducasse - Inria
40, avenue Halley,
Parc Scientifique de la Haute Borne, Bât.A, Park Plaza
Villeneuve d'Ascq 59650
France
Hi,
Currently the implementation of #children in MooseEntity is really
fragile. In the current implementation, we select all the selectors
matching "all*s" and we merge the results of these methods.
This is fragile because we could have #allContainerFiles that would not
return children. Also it is possible that there is no method matching
this pattern for some children.
In the meanwhile, Anne, Jean-Christophe and Vincent worked in the usage
of the mse properties in order to build more generic algos. There is
currently a #childrenEntities and a #parentEntities methods to get the
children/parents based on the meta-model of the language. I think this
is now stable.
I will deprecate #childrenEntities and #parentEntities and rename them
#children and #parents now.
So, no need to implement some #children methods anymore :)
--
Cyril Ferlicot
https://ferlicot.frhttp://www.synectique.eu
2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France
Hi,
I saw that in FAMIXInvocation we have an instance variable named
"receiverSourceCode". I think this is a bad idea to get variables like
this one because source code should be saved via source anchors. Also,
it is not used in Moose image.
I would like to replace the accessors by:
receiverSourceCode
^ self receiver sourceText
receiverSourceCode: aString
self deprecated: 'The source code of the receiver should not be saved
as a property. Instead access it via the receiver entity.'
Any objection? If I get none I'll do it soon to reduce memory consumption.
--
Cyril Ferlicot
https://ferlicot.frhttp://www.synectique.eu
2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France
