Moose-dev July 2015

moose-dev@list.inf.unibe.ch

38 participants
74 discussions

Roassal callbacks as events
by Peter Uhnák 19 Aug '15

19 Aug '15

Hi, this is just an idea that's been bugging me for some time... what if callbacks could be attached just like regular events? e.g. aBox when: TRExtentChanged do: [ :event | (self parentFor: aBox) rebuild ] Is there benefit in having some events as events and some as callbacks? Isn't event more versatile? What do you think? I should probably check how this is done in Bloc... Peter

4 8

RTEdge class "edge construction" deprecated
by Peter Uhnák 05 Aug '15

05 Aug '15

Hi, "edge construction" protocol of RTEdge is deprecated, but I don't see by what. RTEdgeBuilder perhaps? Thanks, Peter

2 3

interview on .Net Rocks! about Moose, humane assessment, Pharo and GT
by Tudor Girba 03 Aug '15

03 Aug '15

Hi, I had the pleasure of giving an interview for the .Net Rocks! podcast. It was quite fun and I managed to mention Moose, humane assessment, Pharo and GT in 45 minutes. It was not as smooth as a presentation but I still think it's a useful advertisement. Let me know what you think, and feel free to promote it further: https://dotnetrocks.com/default.aspx?showNum=1172 http://www.tudorgirba.com/blog/dotnetrocks-interview-moose-humane-assessmen… Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow"

5 9

Roassal TRConstraint deprecation
by Peter Uhnák 03 Aug '15

03 Aug '15

Hi Alex, you've marked TRConstraint as obsolete, however not all behavior has been yet implemented in new RTConstraint. Namely methods from "public - resizing", "public - camera", and "public - aligning". Secondly I am not sure about the name of RTConstraint class>>child:parent: (Tudor also didn't like the name when he saw it. :)) I don't think the naming fits well into Roassal... maybe RTConstraint class>>on:backElement: ? Thanks, Peter

2 3

Re: [Pharo-dev] GanttChartMorph openOn: aCollectionOfActivities ?
by Alexandre Bergel 03 Aug '15

03 Aug '15

Hi Hannes! Here is a first shoot paired-programmed with Juraj using Roassal: -=-=-=-=-=-=-=-=-=-=-=-= b := RTTimeLine new. b addEntry: (RTTimeLineEntry new identifier: #WP1; start: 0; end: 5). b addEntry: (RTTimeLineEntry new identifier: #WP2; start: 5; end: 8). b addEntry: (RTTimeLineEntry new identifier: #WP3; start: 7; end: 10). b axisX numberOfLabels: 5. b -=-=-=-=-=-=-=-=-=-=-=-= Here some slightly more elaborated example: -=-=-=-=-=-=-=-=-=-=-=-= “One color per entry" | b d | b := RTTimeLine new. b addEntry: (RTTimeLineEntry new identifier: #c1; start: 0; end: 5). b addEntry: (RTTimeLineEntry new identifier: #c1; start: 6; end: 8). b addEntry: (RTTimeLineEntry new identifier: #c2; start: 0; end: 5). b addEntry: (RTTimeLineEntry new identifier: #c2; start: 8; end: 10). b addEntry: (RTTimeLineEntry new identifier: #c3; start: 0; end: 10). b addEntry: (RTTimeLineEntry new identifier: #c4; start: 5; end: 10). b addEntry: (RTTimeLineEntry new identifier: #c5; start: 5; end: 8). d := RTVerticalTickLineDecorator new. d shape line color: Color white. b addDecorator: d. b axisX numberOfLabels: 5; labelRotation: -45; labelConversion: [ :v | Date year: 2015 day: v ]. b shape color: (RTMultiLinearColorForIdentity new objects: b entries). b -=-=-=-=-=-=-=-=-=-=-=-= One color per timeline -=-=-=-=-=-=-=-=-=-=-=-= | b | b := RTTimeLine new. b addEntry: (RTTimeLineEntry new identifier: #c1; start: 0; end: 5). b addEntry: (RTTimeLineEntry new identifier: #c1; start: 6; end: 8). b addEntry: (RTTimeLineEntry new identifier: #c2; start: 0; end: 5). b addEntry: (RTTimeLineEntry new identifier: #c2; start: 8; end: 10). b addEntry: (RTTimeLineEntry new identifier: #c3; start: 0; end: 10). b addEntry: (RTTimeLineEntry new identifier: #c4; start: 5; end: 10). b addEntry: (RTTimeLineEntry new identifier: #c5; start: 5; end: 8). d := RTVerticalTickLineDecorator new. d shape line color: Color white. b addDecorator: d. b axisX numberOfLabels: 5; labelRotation: -45; labelConversion: [ :v | Date year: 2015 day: v ]. b shape color: (RTMultiLinearColorForIdentity new command: #identifier; objects: #(c1 c2 c3 c4 c5)). b -=-=-=-=-=-=-=-=-=-=-=-= Age of some classes: -=-=-=-=-=-=-=-=-=-=-=-= | b | b := RTTimeLine new. b extent: 500 @ 500. ((RTShape withAllSubclasses sortedAs: #ageInDaysRounded) select: #hasMethods) do: [ :cls | e := RTTimeLineEntry new. e identifier: cls. e start: cls computeYoungestMethod ageInDays. e end: cls computeOldestMethod ageInDays. b addEntry: e ]. b -=-=-=-=-=-=-=-=-=-=-=-= All these examples are in the Roassal time line example menu. This is still an early version. Let us know how it goes! https://www.facebook.com/ObjectProfile/posts/840542572699008 Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > On May 7, 2015, at 4:25 PM, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: > > Hello > > Has somebody done a GANTT chart? > > GanttChartMorph openOn: aCollectionOfActivities > > ? > > Activities have > - id > - description > - start date > - end date > ? > > Regards > > Hannes >

2 17

Roassal RTAttachPoint inverted
by Peter Uhnák 02 Aug '15

02 Aug '15

Hi Alex, I've noticed that with addition of DoubleArrowedLine you've also added concept of "inverted" to attach points. This seems really strange from the perspective that all methods startingPointOf: and endingPointOf: are identical only with swapped ifTrue:/ifFalse: for example ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ startingPointOf: anEdge ^ (inverted ifTrue:[anEdge to] ifFalse:[anEdge from]) position endingPointOf: anEdge ^ (inverted ifTrue: [anEdge from] ifFalse: [anEdge to]) position ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ this is harder to read and more error-prone than ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ startingPointOf: anEdge ^ anEdge from position endingPointOf: anEdge ^ anEdge to position ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ plus there is code duplication. And this is just the simplest attach point. Since I should also add "inverted" to my attach points that are in Roassal (RTRectangleAttachPoint, ...) maybe the actual computation should be delegated? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ RTAttachPoint>>startingPointOf: anEdge ^ inverted ifTrue: [ self basicEndingPointOf: anEdge ] ifFalse: [ self basicStartingPointOf: anEdge ] RTAttachPoint>>endingPointOf: anEdge ^ inverted ifTrue: [ self basicStartingPointOf: anEdge ] ifFalse: [ self basicEndingPointOf: anEdge ] RTAttachPoint>>basicStartingPointOf: anEdge ^ self subclassResponsibility RTAttachPoint>>basicEndingPointOf: anEdge ^ self subclassResponsibility ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This also will not break current implementation but it will give opportunity to improve them. And if there was a situation where the implementation would be actually different for inverted (and not just swapped values), than you could still just implement startingPointOf:/endingPointOf: Thanks, Peter

2 1

Roassal on Bloc on not Pharo
by Peter Uhnák 02 Aug '15

02 Aug '15

Hi, I am wondering... how will moving Roassal to Bloc affect other platforms such as VisualWorks? Because it seems it would be unportable with Bloc, no? Peter

6 9

Large API vs Builder like API
by Alexandre Bergel 01 Aug '15

01 Aug '15

Hi! It would be great to get feedback from you guys. We have the class TRConstraint that allows for roassal elements to be aligned (cf Section 10 in https://dl.dropboxusercontent.com/u/31543901/AgileVisualization/Roassal/010… <https://dl.dropboxusercontent.com/u/31543901/AgileVisualization/Roassal/010…>). Currently, you can write: TRConstraint use: centralDot alignFromTop: negativeElements Which align all the elements contained in the collection negativeElements against a fix point, centralDot. It looks pretty easy to read. However, the class TRConstraint has many methods (alignFromBottom:, alignFromLeft:, use: aShape alignFromBottom: shapes, …) which are essentially all duplicated code. So, I though about creating a compact class, called RTAlignment. You can now write: RTAlignment new elements: negativeElements; fixedElement: centralDot; top But, I find that less nice to read. Any opinion? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

3 2

News about the new version of MooseChef and questions
by Anne Etien 31 Jul '15

31 Jul '15

Hi, We have improved MooseChef with a generic version MooseQuery. In the following when we talk about MooseChef, it means the current version available by default in Moose. When we talk about MooseQuery, it means the generic improved version, available on Anne’s smalltalkHub repository. All the tests of MooseChef except 4 are passing when using our new MooseQuery API. These four tests concern the same point package scope for extension method. Considering classA having a method methodA1 calling a method methodBExt1 that extends classB. classB is defined in pckgB and its extension method by pckgC. Considering the two following requests: 1. classA queryOutgoingInvocation atClassScope atPackageScope 2. classA queryOutgoingInvocation atPackageScope To the first query, MooseChef and MooseQuery answer the same: pckgB To the second query, MooseChef answers pckgC and MooseQuery answers pckgB and pckgC. So first question: What is the expected behavior? What do we want? According to us, MooseQuery behavior is more consistent. *************** Considering now Java code. class1 contains a method method1 which in its turn contains an inner class innerClass2. innerClass2 contains 2 methods method21 and method22. the following query: innerClass2 methodScope In MooseChef this query has for result method21 and method22. The following query: innerClass2 atScope: FAMIXMethod In MooseQuery this query has for result method1. Indeed, the atScope: method look for the container (also called parent). So the second question: what is the expected behavior? Do we want like in MooseQuery that atScope: by default always goes up in the containment tree since it is a generic version of atTypeScope, atPackageScope... and do we want another method to goes down in the containment tree? In MooseChef, methodScope, always goes down to look for the contained methods. typeScope always goes up except for ScopingEntities. These methods have been implemented for each type of entities. It is what we want to avoid with MooseQuery. ****************** It is clear that Synectique will soon migrate to this new version and that our project of SQL analysis will also use it. Please don’t hesitate to use it. MCHttpRepository location: 'http://smalltalkhub.com/mc/AnneEtien/MooseQueryDraft/main' user: '' password: ‘' We will do as soon as possible a small doc to explain the usage. Thank you in advance for your answer to our questions. Jean-Christophe and Anne

4 11

Distribution/Color Map of file size
by Brice GOVIN 30 Jul '15

30 Jul '15

Hi, yesterday I heard someone from my team talking about a tool for visualizing quickly file size in your system. I was wondering if there is anything done with Roassal for that? I looked at the current version of Roassal in Moose 6.0 but I didnt find anything. If there is one could someone help me otherwise should it not be nice to have some? Thanks for your answer. Regards, -------------- Brice Govin PhD student in RMoD research team at INRIA Lille Software Engineer at THALES AIR SYSTEMS Rungis ENSTA-Bretagne ENSI2014 64 chemin des boeufs 91220 PALAISEAU

3 4

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev July 2015