We sensibly run at the same pace than in mid-july.
Cheers,
Alexandre
Report produced on 2010-08-10T18:50:00-04:00
System version Pharo-1.1-11400-rc2 of 12 June 2010 update 11400
Benchmark ManyNode (simple rendering of nodes) :
100 nodes => 7 ms
200 nodes => 12 ms
300 nodes => 18 ms
400 nodes => 24 ms
500 nodes => 29 ms
600 nodes => 150 ms
700 nodes => 42 ms
800 nodes => 47 ms
900 nodes => 53 ms
1000 nodes => 60 ms
1600 nodes => 95 ms
3200 nodes => 186 ms
6400 nodes => 380 ms
Benchmark ManyEdges (simple rendering of edges) :
10 edges => 2 ms
20 edges => 8 ms
30 edges => 21 ms
40 edges => 38 ms
50 edges => 66 ms
60 edges => 104 ms
70 edges => 152 ms
80 edges => 227 ms
90 edges => 306 ms
100 edges => 418 ms
200 edges => 5172 ms
300 edges => 38460 ms
Benchmark ManyInnerNodes :
5 nodes => 175 ms
10 nodes => 2420 ms
15 nodes => 11174 ms
Benchmark Displaying ManyInnerNodes :
5 nodes => 154 ms
10 nodes => 850 ms
15 nodes => 10047 ms
Benchmark Displaying ManyInnerNodesAndEdges :
1 nodes => 9 ms
2 nodes => 240 ms
3 nodes => 3280 ms
4 nodes => 30758 ms
Benchmark Displaying elementAt :
100 nodes => 3 ms
500 nodes => 5 ms
1000 nodes => 9 ms
1500 nodes => 11 ms
2000 nodes => 14 ms
2500 nodes => 17 ms
Benchmark many small nodes :
2000 nodes => 2248 ms
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi!
The new version of Mondrian should make some of us happy. Before displaying the view, using the #open method, the view is rendered in a non displayed form. This means that if there is an error in your script, you will have a debugger instead of a freeze of the image.
This is something I should have done at least 1 year ago. But at least, now this is done.
If you have a scenario that freezes the image, please let me know. This is really annoying.
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi Alex,
I would need your help in introducing the ChildrenShape. Without this,
the FormsBuilder is highly underutilized.
The problem I have is that currently the drawing of the nested graphs
is handled on the Figure side, while it should be handled by the
Shape. So, I would need your help to move this behavior while still
preserving the caching logic.
The ChildrenShape should then override the display:on: to display
these elements.
Would you have time to look into this?
For example, the following code should define a umlClassShape:
| builder childrenShape titleShape umlClassShape |
childrenShape := MOChildrenShape new.
titleShape := MORectangleShape new text: 'Title'; fillColor: Color
transparent.
builder := MOFormsBuilder new.
builder column; center; fill; pref; grow.
builder row; center; pref; fill; grow; row; center; fill; pref; grow.
builder x: 1 y: 1 add: titleShape.
builder x: 1 y: 2 add: childrenShape.
umlClassShape := builder asShape.
view nodeShape: umlClassShape.
view nodes: (1 to: 3) forEach: [:each |
view nodes: (1 to: 10) ]
Cheers,
Doru
--
www.tudorgirba.com
"Not knowing how to do something is not an argument for how it cannot
be done."
This can be interested to other Smalltalkers :)
Begin forwarded message:
> From: Kris Gybels <kris-gybels(a)skynet.be>
> Date: August 5, 2010 6:13:01 PM GMT+02:00
> To: Stéphane Ducasse <stephane.ducasse(a)inria.fr>
> Cc: Andy Kellens <akellens(a)vub.ac.be>, Johan Brichau <johan.brichau(a)uclouvain.be>
> Subject: Re: do you have an idea how we could talk from pharo to vw?
>
> A direct answer to your question where the code is:
>
> The code of STaPLe is in a SourceForge CVS repository, this page explains how to check out the repository or browse it via a web browser: http://sourceforge.net/scm/?type=cvs&group_id=96556
>
> There are brief NOTES files explaining what additional things you need (SWI-Prolog) and how the code can be built if you would really want to try it out; but be warned, the last time I looked at it was in 2003 ...
>
> About the idea:
>
> I would suggest you start by using an existing distributed messaging framework to communicate between Pharo and VisualWorks. I don't know about any such frameworks, since I never needed one, but I'd be surprised if one for Smalltalk does not exist. ;)
>
> The only advantage I can immediately see to doing something similar to what I did with STaPLe is that you can eliminate the overhead of process switching and socket communication by running the two virtual machines in the same process. The essence of STaPLe is a small piece of C code that staples together the virtual machines of VisualWorks and SWI-Prolog by using their C foreign function interfaces. But except for the fact that they communicate through these foreign function interfaces and not through sockets, STaPLe does much the same thing as you would have to do for distributed messaging: it converts strings and numbers from one virtual machine to the other, makes proxies for objects so that they can be sent a message from the other side and so on. This creates a lot of overhead for each message send. I am not sure whether process switching and socket communication creates enough additional overhead to try to optimize it away.
>
> So: Try distributed messaging first. That way you don't need to do anything in C. If you find it is too slow for what you want to do, try to get rid of process switching and socket communication by using the foreign function interface way. If it's still too slow, then err ... I think the only option left is: run all your code in only one Smalltalk virtual machine ;))
>
> Regards,
> Kris.
>
> On 05 Aug 2010, at 11:47, Stéphane Ducasse wrote:
>
>> thanks!
>>
>> Stef
>>
>> On Aug 5, 2010, at 11:46 AM, Andy Kellens wrote:
>>
>>> Stef,
>>>
>>> I added Kris's new email address to this conversation.
>>>
>>> On 05 Aug 2010, at 11:45, Stéphane Ducasse wrote:
>>>
>>>> Hi kris
>>>>
>>>> how can I access the code of staple?
>>>>
>>>> Stef
>>>> On Aug 5, 2010, at 10:48 AM, Andy Kellens wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> The trick with using VW as a DLL indeed seems a good idea.
>>>>> While I also don't have a clue how this actually works, I believe Kris used it when he implemented StaPLe (a bridge between SWI-Prolog and VW).
>>>>> You can probably find some example code on that project's website: http://staple.sourceforge.net/
>>>>>
>>>>> Andy
>>>>>
>>>>> On 05 Aug 2010, at 10:42, Johan Brichau wrote:
>>>>>
>>>>>> Hm.... except the traditional unwanted xml-rpc communication, I would investigate the possibility to use Alien/FFI and talk to Visualworks as a dll.
>>>>>> I seem to remember that Visualworks can be used like that, but I'm not sure.
>>>>>>
>>>>>> If that works, you can create a high-level communication layer that would make communication seamless.
>
>
Hi Doru,
In a form builder, should we have a rendering of the inner nodes at each =
occurrence of a children shape? If there is no children shape in a form =
builder, can the inner nodes be rendered?
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi guys,
I publish a small description of Orion on moose website (http://).
A tutorial is also available (For now it is small and maybe it has some english issues. I will improve it).
Orion is a tool for reengineering, to simulate changes and compare their impact on multiple versions of software source code models.
You can try it:
=====
Gofer new
squeaksource: 'Orion';
package: 'ConfigurationOfOrion';
load.
(Smalltalk at: #ConfigurationOfOrion) perform: #loadDefault.
=====
I am also available to answer your questions.
Cheers,
---
Jannik Laval
Hi,
I am working a bit on some enhancements for Moose Finder:
- You can now extend it with new presentations by adding a method in
the Finder with a pragma like:
sourceTextIn: aComposite
<presentation: 10>
aComposite text
title: 'Source';
titleIcon: MenuIcons mooseSourceText;
display: [ :each | each mooseInterestingEntity sourceText ];
when: [ :input | (input mooseInterestingEntity class canUnderstand:
#sourceText)
and: [input mooseInterestingEntity sourceText notEmpty ] ]
- I added icons for the default presentations (see attached picture)
Cheers,
Doru
--
www.tudorgirba.com
"From an abstract enough point of view, any two things are similar."
http://groups.yahoo.com/group/trevtourenn/message
fburdung restloser Verantwortlichkeit nach oben,
wobei niemand Autoritat Untergebenen gegenuber erhalt, der nicht selbst Besserkonner der betreffenden
Arbeit ist. Im Verlaufe von zwei Jahren habe ich mich mit meiner
{669 Aufbau der Bewegung}
Ansicht immer mehr durchgesetzt, und heute ist sie in der Bewegung, wenigstens soweit die oberste
Leitung in Frage kommt, bereits selbstverstandlich.
Der sichtbare Erfolg dieser Haltung aber zeigte sich am 9. November 1923: Als ich vier Jahre vorher zur
Bewegung kam, war nicht einmal ein Stempel vorhanden. Am 9. November 1923 fand die Auflosung
der Partei, die Beschlagnahme ihres Vermogens statt. Dieses bezifferte sich einschlie.lich aller
Wertobjekte und der Zeitung bereits auf uber hundertsiebzigtaus