- Moose-dev - INF Mailman

by Anne Etien

Hi, Would it be possible to have a quick install of Moose64 for Linux, Mac and Windos available somewhere easily accessible? I was teaching moose yesterday and today again with other students. It took half an hour to get an image of Moose 64 that works, downloading Moose64 on the CI website, Pharo VM on another web sites and the sources. It is not a good image that we give to the students with this complexity just to download Moose. I really think that it is relevant for the students to work on Moose, but please help us by providing an archive with everything in it. I agree that because it is open source project, I could help in this, but I am sure, that you will prefer not, because I am really bad at this. Thanks a lot for your help. Anne

7 years, 7 months

3
2
0 0

Users of TDependencyQueries

by Cyril Ferlicot

Hi, Currently Moose-Query works with Traits. There is : - TDependencyQueries containing all the query system and the common queries such as #queryIncomingAccesses - TOODependencyQueries using TDependencyQueries and adding the method specific to OO entities (mostly inheritance queries) The users of TDependencyQueries are: - TOODependencyQueries - FAMIXAnnotationInstance - FAMIXAnnotationInstanceAttribute - FAMIXSourceAnchor The users of TOODependencyQueries are: - FAMIXNamedEntity I think it would make sense to move TDependencyQueries to FAMIXEntity. FAMIXEntity has all the API needed to the queries and it would help with the consistancy. For example I think that all famix entities should be able to answer to "queryAllIncomingAssociations". It would felp making more generic tools. What do you think? Does that bother someone? -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques Prévert 01, 59650 Villeneuve d'ascq France

7 years, 7 months

6
21
0 0

Improvement on DistributionMap

by Anne Etien

Hi, I find how to easily do one Distribution map from elements. However, as you can see, it is not very beautiful. - Is there an easy way to get legend on distribution map? Here each color corresponds to an author, but if I don’t say it to you you can’t invent it. - the labels are too long, there are the result of element printString and not of element mooseName. How can I change that? - I would also like to be able to inspect each element when clicking on it. But once again, since DistributionMap doesn’t inherit from any Roassal element, I don’t know how to do it. Can anyone help me? Thanks in advance. Anne

7 years, 7 months

2
2
0 0

Glamour: Raw list selection?

by Sean P. DeNigris

I have a list presentation that modifies the selection before transmitting: a list … send: [ :version | [ db backupVersion: version ] on: Error do: [ :e | e ] ] This makes sense for consumption by other presentations, but I just discovered the need internally-to-the-list to access the raw selection (before the sendBlock is applied). Is that possible? ----- Cheers, Sean -- Sent from: http://forum.world.st/Moose-f1310756.html

7 years, 7 months

2
2
0 0

Passing context class with GTSpotter

by Peter Uhnák

Hi, I'm extending Spotter and wonder how I can achieve the following. I have some domain model, for the sake of example let's imagine Item" and "Container" classes; where "Container" can contain other Items or Containers. Then I have a custom Spotter wrapper class that shows the initial Spotter cadidates and can perform something with the spotted objects. Object subclass: #MySpotterModel slots: { #container. #something }. MySpotterModel>>doSomethingWith: item something doSomethingTo: item MySpotterModel>>spotterContentFor: aStep <spotterOrder: 10> ^ aStep listProcessor title: 'Items'; candidatesLimit: Float infinity; allCandidates: [ container items ]; actLogic: [ :item | self doSomethingWith: item. aStep exit ]; matchSubstring So far so good. Now the problem is, that I would like to "dive" (right arrow) into a container further, so there would be (notice that I am already duplicating behavior) MySpotterModel>>spotterContentFor: aStep <spotterOrder: 10> ^ aStep listProcessor title: 'Items'; candidatesLimit: Float infinity; allCandidates: [ self items ]; actLogic: [ :item | "self doSomethingWith: item. "<<<<<<<------------ aStep exit ]; matchSubstring So my question is ... how can I "pass along" a custom instance? Thanks, Peter

7 years, 8 months

1
0
0 0

Management of #queryAll{Direction}Associations (complete one)

by Cyril Ferlicot

Hi! Sorry for my previous incomplete mail. I missclicked. Here is the full one: I have some improvements I would like to make to Moose query and I would like your approuval. First. Currently there is: - #queryAllOutgoing and #queryAllOutgoingAssociations to query all the outgoing associations of the receiver - #queryAllIncoming and #queryAllIncomingAssociations to query all the incoming associations of the receiver #queryAll{Direction} is based on the meta-model properties while #queryAll{Direction}Associations seems to be more empirical. See: queryAllOutgoingAssociations ^ self queryStaticOutgoingAssociations addAll: self queryAllOutgoingInvocations; yourself I propose two changes: - Remove the empirical implementation to use only the one based on the meta-model - Deprecate #queryAllIncoming and #queryAllOutgoing. I think #queryAllIncomingAssociations is a better name, but I can change my mine if you have a different opinion on that. Second. To query all the in/out associations with the method based on the meta-models, there is the use of "FAMIXAssociation withAllSubclassesDo:" to iterate on the associations and do the queries for all of them. I have three problems with that: - This is not efficient. If an entity can have only 2 incoming associations it will still try the queries for all the associations in the image - This has a role in the circular dependency between FAMIX-Core and Moose-Query packages because we reference FAMIXAssociation - If one day we create another project from FAME to represent something that is not a software model, we will maybe not have FAMIXAssociation but we might still have associations. And Moose-Query could still be useful on this project. I propose to add to TEntityMetaLevelDependency two methods: allOutgoingAssociationTypes ^ (self allChildrenTypes flatCollectAsSet: #outgoingAssociationTypes) addAll: self outgoingAssociationTypes; yourself and allIncomingAssociationTypes ^ (self allChildrenTypes flatCollectAsSet: #incomingAssociationTypes) addAll: self incomingAssociationTypes; yourself Thus the entities will be able to return the associations they and their children can have. Then we can replace "FAMIXAssociation withAllSubclassesDo:" by "(self strategy allAssociationTypesFor: anEntity) do:" where the strategy is a MooseQuery{Direction}DirectionStrategy that will call either #allIncomingAssociationTypes or #allOutgoingAssociationTypes. I have an image with all those changes and all the tests of Moose-Query and Moose-Chef are green. I am waiting your opinion on this changes. Have a nice day. -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques Prévert 01, 59650 Villeneuve d'ascq France

7 years, 8 months

4
3
0 0

RTExampleFactory is missing sourceClass:

by Alexandre Bergel

Hi! How can I update GTExample? Why not having a "GToolkit update” world menu entry, somewhere? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

7 years, 8 months

3
3
0 0

Cannot update GLMTabulator containing list with Separators

by Peter Uhnák

Hi, apparently it is not possible to update a GLMTabulator if it contains a list pane with separators. Tested in P6 & P7. ``` data := { { #one. #two. #three } asOrderedCollection. { #alpha. #beta } asOrderedCollection } asOrderedCollection. browser := GLMTabulator new. browser column: #list; column: #actions. browser transmit to: #list; andShow: [ :a | a fastList withSeparators ]. browser transmit to: #actions; andShow: [ :a | a actionList act: [ :actionList | data last add: #dynamic. browser update ] entitled: 'Add Item'; act: [ :actionList | data last remove: #dynamic ifAbsent: [ ]. browser update ] entitled: 'Remove Item'. ]. browser openOn: data. ``` [image: Inline image 1] Thanks, Peter

7 years, 8 months

2
1
0 0

GLMTabulator buttons

by Peter Uhnák

Hi, I went through the GLM examples and the chapter ( http://pharobooks.gforge.inria.fr/PharoByExampleTwo-Eng/latest/Glamour.pdf ) however none of them mention any of the following. Is it possible to change the width of an action button? It seems that the width is fixed. [image: Inline image 1] Likewise is it possible to change the layout, so the buttons are on top of each other and not side-by-side? Finally it seems that setting icons does not work; tested in Pharo 6 and Pharo 7: (screenshot above). Maybe it works only for the toolbar icons? browser := GLMTabulator new. browser column: #one. browser transmit to: #one; andShow: [ :a | a actionList act: [:entity | entity inspect ] iconName: #glamorousInspect entitled: 'Longer Button Label...'; act: [:entity | entity explore ] icon: #glamorousOpen asIcon entitled: 'Explore']. browser openOn: 42. Any pointers appreciated, Peter

7 years, 8 months

3
2
0 0

Inspector Presentation?

by Sean P. DeNigris

I've found the following idiom (or parts of it) to be repeatedly useful: browser transmit ... andShow: [ :a :b | a finder show: [ :b :object | object gtInspectorPresentationsIn: b inContext: GTInspector new ] ] I wonder if it's worth reifying into the DSL. I first thought `a inspector`, but it seems Object already implements it to open an actual... inspector ;) ----- Cheers, Sean -- Sent from: http://forum.world.st/Moose-f1310756.html

7 years, 8 months

1
0
0 0

Moose Editor: Can We Handle Errors More Gracefully

by Sean P. DeNigris

While protoyping a Glamour browser in the editor, it seemed that once I got an error, I was no longer able to "Go" and have the browser appear in the top pane. I had to close the editor and open a new one. This was an unsatisfying workflow. Is there a workaround? If not, could we wrap these inevitable errors so they don't take down the tool? ----- Cheers, Sean -- Sent from: http://forum.world.st/Moose-f1310756.html

7 years, 8 months

1
1
0 0

Management of #queryAll{Direction}Associations

by Cyril Ferlicot

Hi! I have some improvements I would like to make to Moose query and I would like your approuval. First. Currently there is: - #queryAllOutgoing and #queryAllOutgoingAssociations to query all the outgoing associations of the receiver - #queryAllIncoming and #queryAllIncomingAssociations to query all the incoming associations of the receiver #queryAll{Direction} is based on the properties while #queryAll{Direction}Associations seems to be more empirical. See: queryAllOutgoingAssociations ^ self queryStaticOutgoingAssociations addAll: self queryAllOutgoingInvocations; yourself I propose two changes: - Remove the empirical implementation to use only the one based on the meta-model - Deprecate #queryAllIncoming and #queryAllOutgoing. I think #queryAllIncomingAssociations is a better name, but I can change my mine if you have a different opinion on that. Second. To query all the in/out associations with the method based on the meta-models, there is the use of "FAMIXAssociation withAllSubclassesDo:" to iterate on the associations and do the queries for all of them. I have three problems with that: - This is not efficient. If an entity can have only 2 incoming associations it will still try the queries for all the associations in the image - This has a role in the circular dependency between FAMIX-Core and Moose-Query packages because we reference FAMIXAssociation - If one day we create another project from FAME to represent something that is not a software model, we will maybe not have FAMIXAssociation but we might still have associations. And Moose-Query could still be useful on this project. I propose to add to TEntityMetaLevelDependency two methods: allOutgoingAssociationTypes ^ (self allChildrenTypes flatCollectAsSet: #outgoingAssociationTypes) addAll: self outgoingAssociationTypes; yourself and allIncomingAssociationTypes ^ (self allChildrenTypes flatCollectAsSet: #incomingAssociationTypes) addAll: self incomingAssociationTypes; yourself Thus the entities will be ab -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques Prévert 01, 59650 Villeneuve d'ascq France

7 years, 8 months

1
0
0 0

GTExample with dependencies no longer considered example

by Peter Uhnák

Hi, apparently CompiledMethod>>#isGTExampleMethod has been changed from isGTExampleMethod ^ self pragmas anySatisfy: [ :each | each isGTExamplePragma ] to isGTExampleMethod ^ (self pragmas anySatisfy: [ :each | each isGTExamplePragma ]) and: [ self numArgs = 0 ] ( https://github.com/feenkcom/gtoolkit-examples/blob/master/src/GToolkit-Exam… , also strange that I don't see the history of the method on github). In either case this means that if an example has dependencies it is no longer an example, because it has arguments. Thanks, Peter

7 years, 8 months

2
2
0 0

Glamour Feature Discoverability

by Sean P. DeNigris

I was just building a Glamour browser by combining behavior from the many examples. Somehow, I got into a fight with #display:. Because of the way I had set up my model, I was expecting display to accept an individual list item, and it was receiving the list collection instead. Also, I found out later that what I really wanted was #format, as I just wanted to change the way the underlying item was shown in the list. So here's my question: while trying to figure out how #display: worked, I found where it was implemented but there was no method comment. This seems to be a core part of the scripting language and I know Moose in general to be extremely thoughtfully written, so I am assuming that there is some other way/place where this sort of thing is documented of which I'm not aware. What am I missing? ----- Cheers, Sean -- Sent from: http://forum.world.st/Moose-f1310756.html

7 years, 9 months

1
0
0 0

start of Fortran parser

by Nicolas Anquetil

We started to work on a Fortran parser: https://github.com/NicolasAnquetil/VerveineF.git Because it's easiest for us, we are using the Eclipse parsing infrastructure (project Photran) The parser is in a VERY preliminary version as it only recognizes function declarations and calls Famix will also have to be adapted to Fortran ... It is released under MIT licence have fun nicolas -- Nicolas Anquetil -- MCF (HDR) Project-Team RMod

7 years, 9 months

2
2
0 0

About numberofLines of code

by Stéphane Ducasse

Hi It seems totalNumberOfLinesOfCode disappeared from FamixTypeGroup recently. Now I wonder if the new implementation is correct because it would be nice to take into account class definition size. MooseAbstractGroup >> numberOfLinesOfCode <MSEProperty: #numberOfLinesOfCode type: #Number> <MSEComment: 'The number of classes in the model'> ^ self lookUpPropertyNamed: #numberOfLinesOfCode computedAs: [ self allMethods sum: #numberOfLinesOfCode ] What do you think? Stef -------------------------------------------- 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

7 years, 9 months

3
3
0 0

FAMIXFile>>numberOfCharacters

by Cyril Ferlicot

Hi, Here is the implémentation of FAMIXFile>>numberOfCharacters numberOfCharacters <MSEProperty: #numberOfCharacters type: #Number> <MSEComment: 'Number of characters in a file.'> <derived> ^ self lookUpPropertyNamed: #numberOfCharacters computedAs: [ | result | result := self fileExists ifTrue: [ self sourceText size - self totalNumberOfLinesOfText + 1 ] ifFalse: [ 0 ]. result max: 0 ] I see some problems on this implémentation. IIUC, we take the size of the source text and we remove 1 for each line return. This is wrong because in case of CRLF the lines returns are two characters long. I think that it would be better to have: self sourceText lines ifEmpty: [ 0 ] ifNotEmpty: [ :lines | lines sum: #size ] But, I do not agree with the fact that we should remove the lines returns to the number of characters. They are characters, why should we remove them? I propose this implémentation: numberOfCharacters <MSEProperty: #numberOfCharacters type: #Number> <MSEComment: 'Number of characters in a file.'> <derived> ^ self lookUpPropertyNamed: #numberOfCharacters computedAs: [ self sourceText size ] This is because #sourceText already manage the case where the file exist or not. If I have no complain, I'll do this change. -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques Prévert 01, 59650 Villeneuve d'ascq France

7 years, 9 months

3
3
0 0

Supporting reuse of composed metrics out of elementary metrics from different tools.

by Stéphane Ducasse

Hi guys We wanted to reuse metrics computation for example alves ratio (shown below) but for metrics imported from different tools like understand or sonar. calculateAlvesRatio “note that we do not know if this definition is correct but we want to reuse it" ^ self numberOfLinesOfCode / self lcom3 We wanted to avoid to reify all the metrics to avoid to blow memory (yes Cyril we the researchers are not totally dummy :). Here is a solution: double dispatch :) So tell us. FAMIXClass >> calculateAlvesLCOMRatio ^ (self family numberOfLinesOfCodeForClass: self) / (self family lcomForClass: self) MooseFamily >> lcomForClass: aClass ^ aClass lcom3 MooseFamily >> numberOfLinesOfCodeForClass: aClass ^ aClass numberOfLinesOfCode UnderstandFamily >> lcomForClass: aClass ^ aClass understand_LCOM UnderstandFamily >> numberOfLinesOfCodeForClass: aClass ^ aClass understand_LoC testClassLinesOfCodeWithMooseFamily "self nodeClass propertyNamed: #family put: FamixFamily uniqueInstance." self nodeClass familyClass: MooseFamily. self assert: self nodeClass numberOfLinesOfCode equals: 58. self assert: self nodeClass lcom3 equals: 10 / 11. self assert: self nodeClass calculateAlvesLCOMRatio equals: 319 / 5 testClassLinesOfCodeWithUnderstandFamily self nodeClass familyClass: UnderstandFamily. self nodeClass propertyNamed: #understand_LoC put: 85; propertyNamed: #understand_LCOM put: 11. self assert: self nodeClass calculateAlvesLCOMRatio equals: 85 / 11 Comments are welcome and code available at: MCSmalltalkhubRepository owner: 'Moose' project: 'Moose' user: '' password: ‘' Stef -------------------------------------------- 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

7 years, 9 months

1
0
0 0

Promote Moose-Hismo as a project

by Cyril Ferlicot D.

Hi, Currently ConfigurationOfFamix loads the packages `Moose-Hismo`, `Moose-HismoImporter` and `Moose-Tests-HismoImporter`. I have the impression that this should be its own project and that it should not be in the ConfigurationOfFamix. Thus I propose to create a ConfigurationOfHismo and to reference it in ConfigurationOfMoose. Any objection? -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques Prévert 01, 59650 Villeneuve d'ascq France

7 years, 9 months

3
2
0 0

MooseDefaultState

by Cyril Ferlicot D.

Hi, Can someone explain the real interest to get a dictionary for properties and a dictionary for queries in the MooseDefaultState? Is there a downside to merge both? I did some tests by creating a SYNState using a single dictionary for both properties and queries. Here is the memory impact: MooseDefaultState ------------------- Image without model : 263Mo Image with model : 605Mo Image with model and default synectique caches : 650Mo Image with model, default caches and after using the application : 792Mo SYNState ------------------- Image without model : 263Mo Image with model : 589Mo Image with model and default synectique caches : 575Mo (There was probably a full GC that garbaged the temporary object of the import) Image with model, default caches and after using the application : 706Mo We see a clear gain of memory. (I did exactly the same interactions in both try) We might be interested by this at Synectique. This is why I would like to know the reasons to have two different dictionaries since there is no class comment. If the difference will not impact our tools I'll make the default state configurable and I will introduce this SYNState renaming it "MooseMemoryEfficientState" if it is fine with everyone. Thank you in advance for the infos. -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques Prévert 01, 59650 Villeneuve d'ascq France

7 years, 9 months

3
8
0 0

Time to clean old compatibility code?

by Cyril Ferlicot D.

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.fr http://www.synectique.eu 2 rue Jacques Prévert 01, 59650 Villeneuve d'ascq France

7 years, 9 months

3
4
0 0

Re: MooseDefaultState

by Cyril Ferlicot D.

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.fr http://www.synectique.eu 2 rue Jacques Prévert 01, 59650 Villeneuve d'ascq France

7 years, 9 months

4
6
0 0

Fwd: Re: Re: Time to clean old compatibility code?

by Cyril Ferlicot D.

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.fr http://www.synectique.eu 2 rue Jacques Prévert 01, 59650 Villeneuve d'ascq France

7 years, 9 months

1
0
0 0

Fwd: Re: Re: MooseDefaultState

by Cyril Ferlicot D.

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.fr http://www.synectique.eu 2 rue Jacques Prévert 01, 59650 Villeneuve d'ascq France

7 years, 9 months

1
0
0 0

[ann] gtspotter: a moldable interface for spotting objects

by Tudor Girba

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

7 years, 9 months

6
21
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev