Moose-dev December 2009

moose-dev@list.inf.unibe.ch

29 participants
67 discussions

Glamour Panes communication
by Laval Jannik 02 Dec '09

02 Dec '09

Hi Doru, I'm working on a browser and I have a problem for communication between pane. Here is a part of my sourcecode: ===== | browser| browser := GLMTabulator new. browser row: #browser; row: #feedback. browser showOn:#browser; using:[ browser custom: self orionBrowser. ]. browser showOn: #feedback; from: #browser -> #selectedVersion; from: #browser -> #selectedCat; from: #browser -> #selectedElement; using:[ |feed| feed := self feedback. feed allowNil. browser custom: feed. ]. ^ browser ==== In the "self feedback", I only have selectedVersion. The other values are nil. Have you an idea of my problem ? the repository is:'http://www.squeaksource.com/Orion' and the concerned method is OrionBrowser>>oBrowser. Thank you for your help. Cheers --- Jannik Laval PhD Student - Rmod Team - INRIA Certified Project Management Associate (IPMA) http://www.jannik-laval.eu http://rmod.lille.inria.fr ---

5 13

popupView: is now working
by Alexandre Bergel 02 Dec '09

02 Dec '09

Today is a good day! Open a Mondrian easel on a FAMIXClassGroup and execute: -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= view interaction popupView: [:entity :aView | entity viewBlueprintOn: aView]. view shape rectangle width: #numberOfMethods; height: #numberOfAttributes. view nodes: classGroup. view edgesFrom: #superclass. view treeLayout -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Following the idea of Doru, the nice things is that you can have popup on a popup. Execute the following in a MOEasel, and move the mouse in the popup. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= view interaction popupView: [:entity :aView | aView interaction popupView: [: anentity :aView2 | aView2 nodes: (1 to: 20)]. aView nodes: (1 to: 20)]. view nodes: (1 to: 20). -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= popupView: accept a Two arguments block. If you forget one, then the image freeze. This is a know issue, we're working on it.... Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

4 13

Re: [Pharo-project] Feature request: Waiting cursor on load
by Tudor Girba 02 Dec '09

02 Dec '09

Hi Johan, Thanks for the report. A better forum for Moose related problems would be the moose-dev(a)iam.unibe.ch mailing list. You can subscribe here: https://www.iam.unibe.ch/mailman/listinfo/moose-dev Also, to create an issue related to Moose, please use: http://code.google.com/p/moose-technology/issues/list Coming to your issue, this is due to Metacello having no progress bar. However, if you open a Transcript, you will get a progress report. So, now I changed a bit the ConfigurationOfMoose and it opens it for you when you loadDefault. You can get the change in: ConfigurationOfMoose-tg.33 Cheers, Doru On 30 Nov 2009, at 16:19, Alexandre Bergel wrote: >> finally able to get going on Pharo, I wanted to load Moose. I got the >> ConfigurationOfMoose package, and run the loadDefault method. > > Very good start! > >> I have no problem with a 'load' taking for ever, I know I am on the >> other side of the ocean. But please change the cursor to a 'wait' >> cursor while doing the load. It takes a loooooooong time before the >> first progress bar shows, I almost panicked. And now a progress bar >> just dissapeared, but there is still nothing I can do. The 'wait' >> cursor would go a long way in easing my mind. And it's probably just >> one line of code ... > > > Yeah, this is a well known problem. > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com "One cannot do more than one can do."

4 3

Assessing bottlenecks in the Moose importer
by Simon Denier 02 Dec '09

02 Dec '09

Hi there I'm trying to assess bottlenecks in the Moose importer. I think there are some hidden scalability issues especially in the InstallElementsOperator and the CandidateListOperator. Now I cant run a profiler on that because the image crashes before the end, so I just randomly pick some interruption from time to time (especially when I dont have feedback by a progress bar). Some suspect code: InstallElementsOperator >>basicRun model entityStorage forSetup. self container do: [:each | model add: each. self increment]. model entityStorage forRuntime <------- here: converting to a runtime storage takes a long time CandidateListOperator >>setUp "dont call 'model allMethods' here because it sorts the group and we dont care at this level" groups := ((model allWithType: FAMIXMethod) reject: #isAbstract) groupedBy: #signature <----- groupedBy: create a dictionary with all method signatures, I suspect it becomes inefficient on large models Any taker/suggestion on this? ----------------------------- Also I think it would be good to launch the importer in a separate/ background thread, with the possibility to cancel it. What we can do basically (for example): [MooseScripts createModelForPharo] forkAt: 20 (give it a low priority to not starve other process, esp. UI) and we can still interrupt the process in Now if someone knowledgeable in Morphic can come with an enhanced progress bar with a cancel button, which would terminate the import process when clicked. -- Simon

5 9

Mondrian Health report
by Alexandre Bergel 01 Dec '09

01 Dec '09

From the version Mondrian-Alexandre_Bergel.277 in October, the current version of Mondrian is slightly slower on rendering nodes (it took 2907 ms to render 1600 nodes). And we are slightly faster on edges (amazing :-). Report produced on 2009-12-01T12:53:48+00:00 Benchmark ManyNode (simple rendering of nodes) : 100 nodes => 17 ms 200 nodes => 51 ms 300 nodes => 113 ms 400 nodes => 193 ms 500 nodes => 316 ms 600 nodes => 440 ms 700 nodes => 590 ms 800 nodes => 770 ms 900 nodes => 951 ms 1000 nodes => 1218 ms 1600 nodes => 3054 ms Benchmark ManyEdges (simple rendering of edges) : 10 edges => 2 ms 20 edges => 5 ms 30 edges => 14 ms 40 edges => 29 ms 50 edges => 50 ms 60 edges => 82 ms 70 edges => 124 ms 80 edges => 188 ms 90 edges => 268 ms 100 edges => 350 ms 200 edges => 4651 ms 300 edges => 36049 ms 56.04 % of methods are covered Progress from last time: +0.92 % Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

1 0

FAMIXSourceAnchor superclass
by Cyrille Delaunay 01 Dec '09

01 Dec '09

Hi, The smalltalk superclass of 'FAMIXSourceAnchor' is 'MooseEntity'. But in its method #annotation, the superclass described in the pragma #MSEClass:super: is 'FAMIXEntity'. I guess it's a problem but my lack of knowledge in Fame doesn't allow me to be sure.(?)

2 1

progress bars
by Tudor Girba 01 Dec '09

01 Dec '09

Hi, I created a convenience subclass of MooseTask called MooseCustomTask that allows you to easily display a progress bar. Here is an example: MooseCustomTask runWithProgress: [:task | (1 to: 500000) do: [:each | task increment ] ] description: 'Demo' length: 500000 Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow."

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev December 2009