Moose-dev

moose-dev@list.inf.unibe.ch

6621 discussions

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, 6 months

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, 6 months

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, 6 months

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, 6 months

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, 6 months

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, 6 months

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, 6 months

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, 6 months

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, 6 months

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, 6 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev