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.euhttp://rmod.lille.inria.fr
---
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
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
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."
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
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
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
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.(?)
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."
