Moose-dev

moose-dev@list.inf.unibe.ch

6621 discussions

by Laval Jannik

Hi all, What is the state of Famix30 in VisualWorks ? I had a problem today: a guy ask to me how to use the DSM in VW. DSM is not updated in VW. I would like to propose to him to export as mse file. But I think that the mse file is in Famix2. In pharo, we have Famix3. So, we should do a tool to make Famix3 with Famix2. Is it difficult to do this ? I think no, but my vision may be bad ? Cheers --- Jannik Laval PhD Student - Rmod Team - INRIA Certified Project Management Associate (IPMA) http://www.jannik-laval.eu http://rmod.lille.inria.fr ---

15 years, 4 months

java import wizard

by Tudor Girba

Hi Cyrille, Thanks for building the bridge to inFusion. It was long on my todo list and I am happy that you did a nice work there :). Cheers, Doru -- www.tudorgirba.com "From an abstract enough point of view, any two things are similar."

15 years, 4 months

Changes in Fame

by Cyrille Delaunay

Hi, I just save some changes on the Fame squeaksource repository: - Implement a 'ParseClientFilter' that enable to parse and import mse filtering some elements. This is use in Moose to specify the FAMIX elements (FAMIX.Class, FAMIX.Method, ...) you want to import in a MooseModel from a MSE File (This is already available by selecting 'import from MSE' in the MoosePanel). - Two Lint rules in Fame-Util about the Moose issue 143 -> checking if a FM3 class respect the fame name convention between FM3 and Smalltalk -> checking if the superclass defined in a FM3MetaDescription t exist and is well defined.

15 years, 4 months

Can you publish an update to date version of CAnalyzer

by Stéphane Ducasse

hi guys our process just SUCKS!!! I have to go into XML pastell ... to make sure that I get the right version numbers. I would like to WORK today. Stef

15 years, 4 months

New version of Mondrian

by Alexandre Bergel

Dear List, I produced a new version of Mondrian (Mondrian-Alexandre_Bergel.296) which include a highly wished features. Edges may now received events. It gives a relatively good approximation for Spline edges also. All tests are green. I tried it on large visualizations (UML, System complexity, Class blueprint). It runs well. If you encounter some issues, please let me know. I am now investigating whether there is a slow down or not. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

15 years, 4 months

Glamour Panes communication

by Laval Jannik

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

15 years, 4 months

popupView: is now working

by Alexandre Bergel

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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

15 years, 4 months

Re: [Pharo-project] Feature request: Waiting cursor on load

by Tudor Girba

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."

15 years, 4 months

Assessing bottlenecks in the Moose importer

by Simon Denier

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

15 years, 4 months

Mondrian Health report

by Alexandre Bergel

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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

15 years, 4 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev