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 week, 1 day
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
5 years, 5 months
[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
5 years, 6 months
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?
5 years, 9 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
5 years, 11 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
5 years, 11 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
5 years, 11 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
5 years, 12 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
5 years, 12 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
5 years, 12 months
