Moose-dev January 2010

moose-dev@list.inf.unibe.ch

17 participants
68 discussions

Glamour: using the new features
by Johan Fabry 20 Jan '10

20 Jan '10

Hi all, first of all: Thanks Doru for implementing the new features! They are very useful to me. Below is a screenshot of the AspectMaps UI that is using these features. I have a bunch of questions related to this and I would be very grateful if you could help me out. The code of the UI is also below. Very big method, I know, but I did it this way to avoid ambiguities in this mail. Questions: - How do I update the top mondrian panel using the new update mechanism? I want it to redraw itself completely when some of the buttons are pressed and on some of the menu actions of the aspects menu. - The last 2 columns specify the metrics used in the polymetric view. With a transmission I always get the last selections made, but I need to know all selections made in that column so I can print it in the selectionstatus text box. How is this possible? Also, if no selection at all is made I would like to show that in the box (now the box is removed). - The last 3 columns actually do not use any input, but I specify them with "transmit to: ; andShow:" Is there a cleaner way to do this? The code is below: ----snip--- open |browser colors colorizer| "for aspect colors, both automatic assignment and manual selection in menu" colorizer := MOCircularColors new. colors := OrderedCollection new. 1 to: 10 do: [:num| colors add: colorizer nextColor]. browser := GLMTabulator new. browser title: 'AspectMaps Window'. browser row: #mpanel span: 3. browser row:[:r| r column: #models span:2 ; column: #aspectsel span: 2; column: [:c| c row: #buttons span: 4. c row: #selectionstatus.]span: 2; column: #hprop; column: #wprop] span: 2. browser transmit to: #mpanel; from: #models; andShow: [:a | a mondrian painting: [:view :model| model allNamespaces do: [:ns| ns currentShapeFor: view withProperties: self]. view gridLayout.]]. browser transmit to: #models; andShow: [:a | a stackedVerticallyArrangement. a tree title: 'Available projects'; children: [:model | (SortedCollection sortBlock: [:x :y | x name <= y name]) addAll: model allNamespaces asOrderedCollection; yourself ]; act: [:tree | tree selection inspect ] on: $i entitled: 'Inspect'; format: [:model | (model name) copyReplaceAll: '::' with:'.' ]]. browser transmit to: #aspectsel; from: #models transformed: [:model | |topmodel| topmodel := model mooseModel = MooseModel root ifTrue: [model] ifFalse:[model mooseModel]. topmodel allAspects do:[:asp | asp color ifNil: [asp color: colorizer nextColor]]. topmodel allAspects ]; andShow: [:a| a stackedVerticallyArrangement. a tree title: 'Aspects in Project'; format: [:asp | Text string: ((asp show ifTrue: ['(ON) '] ifFalse: ['(OFF) ']), asp name) attribute: (TextColor color: asp color).]; act: [:tree | tree inspect ] on: $i entitled: 'Inspect (i)'; act: [:tree | |asp ann| asp := tree selection. asp show: (asp show not). tree update.] on: $t entitled: 'Toggle On/Off (t)'; actions: [:tree | colors collect: [:col | GLMAction new title: col asString; action: [tree selection color: col. tree update]; category: 'Color']]]. browser transmit to: #buttons; andShow: [:a | a actionList act: [:entity | entity inspect] entitled: 'Vizualize'; act: [:entity | entity inspect] entitled: 'Max Zoom Out'; act: [:entity | entity inspect] entitled: 'Max Zoom In'; act: [:entity | entity inspect] entitled: 'Multiple Aspects Zoom'; act: [:entity | entity inspect] entitled: 'Zoom by Query'. ]. browser transmit to: #hprop; andShow: [:a | a accordionArrangement. a list title: 'Classes Height'; display: self cprops; allowDeselection. a list title: 'Aspects Height'; display: self aprops; allowDeselection. a list title: 'Methods Height'; display: self mprops; allowDeselection. ]. browser transmit to: #wprop; andShow: [:a | a accordionArrangement. a list title: 'Classes Width'; display: self cprops; allowDeselection. a list title: 'Aspects Width'; display: self aprops; allowDeselection. a list title: 'Methods Width'; display: self mprops; allowDeselection. ]. browser transmit to: #selectionstatus; from: #hprop; from: #wprop; andShow: [:a | a text display: [:x :y| x asString , ' ', y asString]; allowNil]. browser openOn: MooseModel root allModels asOrderedCollection ----snip--- -- Johan Fabry jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile

2 12

new browser type: accumulator
by Tudor Girba 18 Jan '10

18 Jan '10

Hi, I am happy to announce a new feature in Glamour in the form of the Accumulator browser. This browser is an implicit one that just takes the input entity and creates a new pane for it. It is called an Accumulator, because it accumulates panes as you provide a new input. These panes are then displayed as tabs. A complementary feature is in a new way bundle transmissions are passed around. You can pass it like before with andShow:, or you can do it with andShowWithoutOverride:. It's not a very nice name, but the idea is that it only transmits the presentation if the same presentations were not already found in the target pane. Using Accumulator you can now emulate browsers that behave like the Eclipse central pane. An example can be found here: GLMBasicExamples new accumulator openOn: 42. This feature is now also used in the MooseFinder and MoosePanel. If you open the Panel and select a model, you open it in a new tab. From the Finder, if you double click on an item in a list you get it in a new tab. I hope you like it. Cheers, Doru -- www.tudorgirba.com "The coherence of a trip is given by the clearness of the goal."

3 2

Glamour health report
by Alexandre Bergel 17 Jan '10

17 Jan '10

A significant slowdown may be noticed when compared with the previous glamourous report (sent on October 23). Details at the end of the amil. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Report produced on 2010-01-16T15:19:06+00:00 ------------------ Opening Browser Benchmark: 15 openings => 2620 ms ------------------ ------------------ Selecting Item in Browser Benchmark 100 size and selections => 2569 ms 200 size and selections => 4359 ms 300 size and selections => 6912 ms 400 size and selections => 8298 ms 500 size and selections => 10414 ms 600 size and selections => 12462 ms 700 size and selections => 14019 ms 800 size and selections => 16123 ms 900 size and selections => 19234 ms 1000 size and selections => 19984 ms 1500 size and selections => 30812 ms 2000 size and selections => 45497 ms ------------------ ------------------ Selecting in finder item Benchmark 1 size and selections => 166 ms 5 size and selections => 897 ms 10 size and selections => 1949 ms 15 size and selections => 2968 ms 20 size and selections => 4008 ms 25 size and selections => 5112 ms 30 size and selections => 11714 ms 35 size and selections => 7686 ms 40 size and selections => 8963 ms 45 size and selections => 10428 ms 50 size and selections => 12471 ms ------------------ 50.66 % of methods are covered from unit tests Progress from last time: +17.19 % -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= From the report generated on Oct 23, we had: Selecting Item Benchmark: 2000 size and selections => 2729 ms Selecting in finder item Benchmark: 50 size and selections => 1881 ms The new version is one magnitude slower. However, opening a browser is slightly faster. The first health report indicated: 15 openings => 3622 ms Cheers, Alexandre

2 2

Mondrian health report
by Alexandre Bergel 16 Jan '10

16 Jan '10

As the regular sanity check, here is the mondrian health report for this month. I created a squeaksource HealthReportProducer. I have in mind plenty of improvements for it (e.g., check of architectural rules, speed progress measurement). I will slowly work on this... Edges got slower to render. I need to dive a bit into the recent changes to understand why. Report produced on 2010-01-16T14:49:26+00:00 Benchmark ManyNode (simple rendering of nodes) : 100 nodes => 15 ms 200 nodes => 53 ms 300 nodes => 113 ms 400 nodes => 201 ms 500 nodes => 345 ms 600 nodes => 457 ms 700 nodes => 760 ms 800 nodes => 812 ms 900 nodes => 1137 ms 1000 nodes => 1243 ms 1600 nodes => 3855 ms Benchmark ManyEdges (simple rendering of edges) : 10 edges => 2 ms 20 edges => 7 ms 30 edges => 43 ms 40 edges => 33 ms 50 edges => 54 ms 60 edges => 139 ms 70 edges => 146 ms 80 edges => 196 ms 90 edges => 314 ms 100 edges => 385 ms 200 edges => 5565 ms 300 edges => 40862 ms 55.65 % of methods are covered by unit tests Progress from last time: +0.57 % Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

1 0

MooseFinder
by Tudor Girba 16 Jan '10

16 Jan '10

Hi, The implementation of the Moose Finder from the Object>>inMoose started to be way too large to, so I moved it into an own class MooseFinder. Cheers, Doru -- www.tudorgirba.com "Not knowing how to do something is not an argument for how it cannot be done."

3 7

Deleting old packages on Moose squeaksource
by Simon Denier 16 Jan '10

16 Jan '10

What do you think of deleting old packages which are completely useless, even for historical purposes. Some are actually from early attempt to port Moose but we have moved on since. A few examples: Moose-Installer Smart-Collections Monticello SLICE-* Merlin (has its own project now) TestWizard (now part of Merlin?) MooseGlamourBrowser (early attempt) Moose-UI (early attempt) Moose-Test-PackageBlueprint (old, duplication) PackageBlueprintOld Moose-PackageBlueprint (deprecated) Moose-NewBlueprint (deprecated) Moose-PB* (deprecated) Moose-NP* (deprecated) Moose-LANTests (old stuff) Moose-Importer-Tests (old stuff) I dont want to delete some deprecated packages which still have a lot of versions, might be interesting for historical purposes. Browsing the Moose repository from MC often feels sluggish : I suspect this is because of the high number of files. Maybe one day we should split between a Moose project and a Famix project. -- Simon

3 4

glamour update
by Tudor Girba 16 Jan '10

16 Jan '10

Hi, Glamour is in a usable state again. The one thing is not working correctly is the update of the overall browser from inside the browser. For example, the mechanism in the MooseModel browseMeta to select a property and then trigger "Focus" from the contextual menu does not update the properties pane again. Things will continue to move in the next period, but it already looks pretty much Ok. Here are a couple of major changes: 1. A pane now can control the rendering of multiple presentations through a CompositePresentation. You can now have different arrangements: tabbed, accordion or stacked. You can find an example at: GLMBasicExamples new differentComposites openOn: (1 to: 100) 2. You can specify titles for a composite and this gets rendered as a groupbox 3. New syntax. To control the composite I introduced a new syntax. - "browser showOn: ; from: ; using: [ browser list]" -> "browser transmit from: ; to: ; andShow: [ :a | a list ]" - "browser sendTo: from:" -> "browser transmit from: ; to:" 4. Simple transmissions and bundle transmissions can have multiple origins and can define transformations per origin port. For example you can have: browser transmit from: #one ; from: #two transformed: [:x | ...] ; to: #three. 5. Presentations can now update using a basic mechanism (first implemented by Jorge and Philipp). For example: a list updateYourselfOn: SomeAnnouncement from: [:entity | some announcer]; The only catch here is that the entity object should point to the objects that gets changed. You can also force an update explicitly from an action: a list act: [:presentation | presentation update] entitled: 'some action'. 6. When updating a presentation, it might be that the selection from the old presentation does not make sense in the new context. To enable a checking you can now specify that you want validation for each change in the ports (in particular for selection). For example: a list shouldValidate: true 7. Finder can now properly embed a browser. This is actually pretty neat :) 8. Finder now remembers the title of the last active presentation and it will favor this one in the new tab Please have a look and let me know if you encounter problems. Cheers, Doru -- www.tudorgirba.com "The coherence of a trip is given by the clearness of the goal."

3 4

updating mondrian
by Tudor Girba 15 Jan '10

15 Jan '10

Hi Alex, I am trying to debug the problem of embedding Mondrian in Glamour and I have a question. Why exactly does Mondrian need to know the window to update? Why is it not enough to just know the Canvas morph? Cheers, Doru -- www.tudorgirba.com "Problem solving efficiency grows with the abstractness level of problem understanding."

3 3

famix changes related to modifiers
by Tudor Girba 15 Jan '10

15 Jan '10

Hi, I noticed that isPackage, isPrivate, isProtected were removed from FAMIXNamedEntity in Famix-Core. It's true that perhaps these methods should be in Famix-Extensions, but they should not be removed. Also, isFinal was moved in Famix-Java. This is a Java specific, because it has a meaning also for C++ programs where isFinal is everything that is not explicitly defined as virtual. Did I miss something? In general, we have to be more careful with changes at such core levels :) Cheers, Doru -- www.tudorgirba.com "One cannot do more than one can do."

4 8

[Mondrian] Thought about MOGraphElement
by Alexandre Bergel 15 Jan '10

15 Jan '10

Hi! Now that some of you are building complex and interactive visualizations, I feel the need to add some annotations on things that are displayed. I am not talking about the model here, but really annotation on the view. For example, assume that I want the size of a node to increase (e.g., to see its method inside) when I double click on it. Where do I store the information that the node has been expanded ? I started to have this need with popupView:. A node needs to know whether its popupview is on or not. I added a variable popup in MOGraphElement which solve this. But more complex interaction requires a generalization of this. I am about to introduce a variable annotation in MOGraphElement that will lazily create a dictionary. Any comment? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

3 4

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev January 2010