Hi!
Some improvement were made over the last few days (Thanks Henrik!).
Here is the health report run on a 64/32 vm, 5.7b3.
Compared with the report sent on August 11, we are significantly faster on simple rendering of edges (due to the fast node lookup scheme), rendering inner nodes (due to the fast node lookup scheme again)
But a bit slower on rending simple nodes (27%), ManyInnerNodesAndEdges (3%), many small nodes.
Report produced on 2010-09-14T10:26:51+00:00
System version Pharo-1.1-11411 of 17 July 2010 update 11411
Benchmark ManyNode (simple rendering of nodes) :
100 nodes => 6 ms
200 nodes => 11 ms
300 nodes => 16 ms
400 nodes => 21 ms
500 nodes => 28 ms
600 nodes => 32 ms
700 nodes => 36 ms
800 nodes => 42 ms
900 nodes => 48 ms
1000 nodes => 52 ms
1600 nodes => 84 ms
3200 nodes => 169 ms
6400 nodes => 485 ms
Benchmark ManyEdges (simple rendering of edges) :
10 edges => 3 ms
20 edges => 7 ms
30 edges => 15 ms
40 edges => 26 ms
50 edges => 40 ms
60 edges => 56 ms
70 edges => 213 ms
80 edges => 99 ms
90 edges => 128 ms
100 edges => 273 ms
200 edges => 1120 ms
300 edges => 3538 ms
Benchmark ManyInnerNodes :
5 nodes => 142 ms
10 nodes => 2754 ms
15 nodes => 9345 ms
Benchmark Displaying ManyInnerNodes :
5 nodes => 193 ms
10 nodes => 888 ms
15 nodes => 10393 ms
Benchmark Displaying ManyInnerNodesAndEdges :
1 nodes => 8 ms
2 nodes => 232 ms
3 nodes => 3328 ms
4 nodes => 34497 ms
Benchmark Displaying elementAt :
100 nodes => 4 ms
500 nodes => 6 ms
1000 nodes => 9 ms
1500 nodes => 12 ms
2000 nodes => 15 ms
2500 nodes => 18 ms
Benchmark many small nodes :
2000 nodes => 3328 ms
Benchmark edges bounds :
500 nodes => 134 ms
Benchmark subnodes lookup :
20000 nodes => 3896 ms
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi Alex,
I have a problem with Mondrian (last version).
Text are cut when displayed. I see only the top of the text.
You can reproduce it with:
=====
(view shape: (MOFixedRectangleShape new
width: 180;
height: 180;
text: [:entity | entity asString];
withBorder;
borderColor: Color gray)).
view nodes: #(blah blaf blag)
======
Cheers,
---
Jannik Laval
Hi guys,
You can now find the proceedings of this year's FAMOOSr online at:
http://www.moosetechnology.org/events/famoosr2010#proceedings
You can look at the papers and even if you will not be physically
present there, you can send us questions that we could ask the
presenters during the workshop.
Cheers,
Mircea and Simon.
Hi!
After a short session of pair programming with Henrik, we found places where node lookup can be severally optimized.
As a result, blueprint complexity opens on 509 classes in 72 seconds.
I know that some issues are still open related to node lookup (lazy edges and http://code.google.com/p/moose-technology/issues/detail?id=400). I will work on them...
Thanks Henrik!
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On 9/9/10 6:13 PM, alberto.bacchelli(a)usi.ch wrote:
> On 9/9/10 6:09 PM, Alexandre Bergel wrote:
>> Let us know how it goes Alberto
>>
>> A good test for your work may be to parse the whole JDK. I did a similar experiment a few years ago. I used Smacc. I had to manually modify some files because the java parser in the Java compiler is written by hand. And it permits things that are not expressed in the grammar. For example:
>>
>> class Foo {} ;
>>
>> is accepted by the Java compiler, but it is hardly accessed by most grammars.
>
> Yes, the Java Language Specifications are very very very badly written.
> The book is full of errors and does not consider some cases, as
> you also reported.
> For this reason, I based my porting on the grammar written for
> ANTLR: it passes all the regression tests that the hand-written
> compiler passes.
"It" is referring to the ANTLR grammar, not to PetitJava (yet ;)
On 9/9/10 6:09 PM, Alexandre Bergel wrote:
> Let us know how it goes Alberto
>
> A good test for your work may be to parse the whole JDK. I did a similar experiment a few years ago. I used Smacc. I had to manually modify some files because the java parser in the Java compiler is written by hand. And it permits things that are not expressed in the grammar. For example:
>
> class Foo {} ;
>
> is accepted by the Java compiler, but it is hardly accessed by most grammars.
Yes, the Java Language Specifications are very very very badly written.
The book is full of errors and does not consider some cases, as
you also reported.
For this reason, I based my porting on the grammar written for
ANTLR: it passes all the regression tests that the hand-written
compiler passes.
If anyone wants to have a look,
you can find petitjava on squeaksource.
Alberto
On 9/9/10 4:45 PM, Fabrizio Perin wrote:
> Hi,
> i'm soo sorry but it is not a secret/encrypted message. The idea was to send a mail to Mircea picking up its email address from the mail about VB and this is the result :)
>
> Really sorry for the spam!
>
> By the way as far as i know there is nothing for VB in Moose but recently i got quite impressed from the power of petit parser. I think that would be possible to setup a basic VB parser with Petit Parser in a week.
I don't think it will be as easy as it seems.
PetitParser is great and simplifies a lot your life.
The problem is finding a reliable VB grammar to implement,
and creating the AST from the grammar.
I am working (although with a certain discontinuity) on
PetitJava and it is taking much time.
Alberto
Famoosr happens on Friday the 17th, same time as Esug. In particular, a "bazaar session" (I like the name, thanks Mircea :)) is planned at the end of the workshop, which means pair programming and hacking tools.
Now, I would not be there because I will be at Esug, but one thing has been on my mind lately: why not try some kind of distributed hacking session between Esug and Famoosr? Not for everybody, just a small experiment with one pair on both sites. I think that Lukas did such a thing in the past to help some clients with Seaside.
What do you say?
--
Simon
Hi,
There are 3 tests that fail. It looks like they fail because of the same assertion:
self assert: v = (742@351).
where v is actually 742@350.
Alex, any ideas?
Cheers,
Doru
--
www.tudorgirba.com
"To lead is not to demand things, it is to make them happen."
