Moose-dev September 2017

moose-dev@list.inf.unibe.ch

25 participants
33 discussions

Fwd: [Pharo-users] [ ANN ] Pharo Days 2016

by Tudor Girba

> Begin forwarded message: > > From: Sven Van Caekenberghe <sven(a)stfx.eu> > Subject: [Pharo-users] [ ANN ] Pharo Days 2016 > Date: December 9, 2015 at 9:52:09 AM EST > To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org>, Pharo Development List <pharo-dev(a)lists.pharo.org>, Pharo Business <pharo-business(a)lists.pharo.org> > Reply-To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> > > Dear fellow Pharoers, > > Mark your calendars: on Thursday March 31 & Friday April 1 we are organising the Pharo Days 2016. This year we moved the location to Namur, Belgium, just a bit south of Brussels, at the very beautiful location of the ‘Cercle de Wallonie’ overlooking the river Meuse. > > We’ll update the following page moving forward. > > https://medium.com/concerning-pharo/pharo-days-2016-c52fe4d7caf > > You can ask questions on any of the Pharo mailing lists or you can email the Pharo Board. > > Let's make this another success, together ! We hope to see as many of you as possible. > > -- www.tudorgirba.com "We are all great at making mistakes."

1 year, 1 month

C/Cpp parser

by Nicolas Anquetil

Synectique is openning the source code for a C/C++ parser based on Eclipse CDT. https://github.com/Synectique/VerveineC-Cpp.git The parser was developed as an Eclipse (Mars release) plugin and is under MIT licence. nicolas -- Nicolas Anquetil -- MCF (HDR) Project-Team RMod

7 years

[Glamour] default selection in ListPresentation

by Cyrille Delaunay

Hello, Is there a way to set a default selection to a list presentation? so that when I open the browser, the morphic list has already a value selected. I tried that: |tmpBrowser| tmpBrowser := GLMTabulator new. tmpBrowser row: #list. tmpBrowser transmit to: #list; andShow: [:a | a list display: [:input | input]; selection: #a; yourself ]. tmpBrowser openOn: #( b c d v a d f r). but the list still open with nothing selected

7 years, 1 month

Delegating views

by Luke Gorrie

Hoi, What is the best way for an object to delegate one or more GTInspector views to other objects? I have been using a pattern like this: gtInspectorFooIn: composite <gtInspectorPresentationOrder: 5> otherObject gtInspectorFooIn: composite but I am wondering whether there is a better way, and also whether this method is valid (I've occasionally seen odd behavior, like Inspector panes disappearing after I "Refresh", and I wonder if I could be somehow confusing the model or if this is not relevant.) also: Supposing this pattern is valid, is there an easy way to override the title of the view(s) added by otherObject?

7 years, 4 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, 7 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, 7 months

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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev September 2017