Re: Latest mondrian breaks forNode: do:
by Alexandre Bergel
Hummm... Strange
According to your log, updateBounds is sent to rectangle from MORoot>>updateBounds. But the code of MORoot>>updateBounds says that #updateBounds can only be sent to a canvas. In your case the canvas is an instance of Rectangle.
In the log, apparently, it is said to be a MOCanvas, as I would expect:
-=-=-=-=-=-=-=-=-=
MORoot>>updateBounds
Receiver: a MORoot
Arguments and temporary variables:
<<error during printing>
Receiver's instance variables:
...
canvas: MOCanvas<0@0 corner: 25@10>
-=-=-=-=-=-=-=-=-=
Really strange...
I am not sure what I can do. Especially if this is related to your image. In that case, just update your image, and wait for it to appear again.
Cheers,
Alexandre
On 27 Jul 2010, at 18:52, Johan Fabry wrote:
> Here you go:
>
> <PharoDebug.log>
>
> On 27 Jul 2010, at 12:37, Alexandre Bergel wrote:
>
>> Johan, do you have the Pharo.log file ?
>>
>> Cheers,
>> Alexandre
>>
>>
>> On 27 Jul 2010, at 18:15, Johan Fabry wrote:
>>
>>> In my image I get 2 DNU, in 2different threads, appearing in the following order
>>>
>>> MORoot>>updateBounds (called in forNode:do: as 'node owner updateBounds.') causes the DNU when sending 'canvas updateBounds'. MORoot canvas is a Rectangle (0@0 corner: 25@10) when causing the DNU but when I debug MORoot canvas is a MOCanvas (MOCanvas<0@0 corner: 25@10>).
>>>
>>> MORoot>>addSelection: aFigure causes DNU in 'selections add: aFigure' because selections is nil. Still nil when I debug it.
>>>
>>> On 26 Jul 2010, at 12:21, Alexandre Bergel wrote:
>>>
>>>> Hi,
>>>>
>>>> I do not get any DNU. I click on inner nodes, and new nodes are normally created.
>>>> forNode:do: is tested in
>>>> #testInteraction10AddingSubNodesAndElementToDisplay
>>>> #testInteraction13NestedInteractions
>>>> #testInteraction14AddingSubnodeToIncreaseRootSize
>>>> #testInteraction4AddingSubNodes
>>>>
>>>> Using the example you gave in your email.
>>>>
>>>> What are exactly the actions you perform to get the DNU?
>>>>
>>>> Cheers,
>>>> Alexandre
>>>>
>>>> On 26 Jul 2010, at 17:58, Johan Fabry wrote:
>>>>
>>>>> Hi Alex, all,
>>>>>
>>>>> The latest mondrian (519) breaks forNode:do: again. Try test code below to get a DNU. Alex could you add some tests for this feature ...
>>>>>
>>>>> view interaction on: MOMouseDown do: [:ann |
>>>>> view forNode: ann element model do: [
>>>>> view interaction on: MOMouseDown do: [:ann2|
>>>>> view forNode: ann2 element model do: [
>>>>> view shape triangle. view nodes: #(6 7 8 9).]].
>>>>> view shape diamond. view nodes: #(3 4 5).]].
>>>>> view nodes: #(1 2)
>>>>>
>>>>> --
>>>>> Johan Fabry
>>>>> jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry
>>>>> PLEIAD Lab - Computer Science Department (DCC) - University of Chile
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Moose-dev mailing list
>>>>> Moose-dev(a)iam.unibe.ch
>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>
>>>> --
>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>>> Alexandre Bergel http://www.bergel.eu
>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>> Moose-dev(a)iam.unibe.ch
>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>> --
>>> Johan Fabry
>>> jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry
>>> PLEIAD Lab - Computer Science Department (DCC) - University of Chile
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> Moose-dev(a)iam.unibe.ch
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> --
>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> Alexandre Bergel http://www.bergel.eu
>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> Moose-dev(a)iam.unibe.ch
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> Johan Fabry
> jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry
> PLEIAD Lab - Computer Science Department (DCC) - University of Chile
>
>
>
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
13 years, 1 month
Latest mondrian breaks forNode: do:
by Johan Fabry
Hi Alex, all,
The latest mondrian (519) breaks forNode:do: again. Try test code below to get a DNU. Alex could you add some tests for this feature ...
view interaction on: MOMouseDown do: [:ann |
view forNode: ann element model do: [
view interaction on: MOMouseDown do: [:ann2|
view forNode: ann2 element model do: [
view shape triangle. view nodes: #(6 7 8 9).]].
view shape diamond. view nodes: #(3 4 5).]].
view nodes: #(1 2)
--
Johan Fabry
jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry
PLEIAD Lab - Computer Science Department (DCC) - University of Chile
13 years, 1 month
PetitParser: PetitSmalltalk
by Alberto Bacchelli
Hi,
In order to define a Java grammar in PetitParser, I am looking at how
PetitSmalltalk is implemented.
- Should a grammar like that of a programming language be
created as a subclass of PPCompositeParser? What's the advantage over
just a subclass of PPParser?
- Unfortunately, I do not understand why PetitSmalltalk uses a
PPSmalltalkTokenParser instead of a normal "token".
Thanks,
Alberto
13 years, 1 month
testMatrixDSM
by Tudor Girba
Hi Jannik,
The testMatrixDSM started to brake recently. I tried to debug, but
cannot figure out what the problem is. I think maybe you changed the
test fixture for another test? Could you take a look?
Cheers,
Doru
--
www.tudorgirba.com
"Every now and then stop and ask yourself if the war you're fighting
is the right one."
13 years, 1 month
PetitParser, longest match
by Alberto Bacchelli
Hi,
I am playing with PetitParser (which looks super-cool!).
Following Lukas' blogpost [1], I defined my identifier as:
<snip>
identifier := #letter asParser , #word asParser star.
</snip>
then, I am using it to find the matches in a given string:
<snip>
identifier matchesIn: 'foo 123 bar12'.
</snip>
which returns:
<snip>
an OrderedCollection(
#($f #($o $o))
#($o #($o))
#($o #())
#($b #($a $r $1 $2))
#($a #($r $1 $2))
#($r #($1 $2))
)
</snip>
Even though the result is correct and makes much sense, would it
be possible to simply have the longest matches?
In that case I would expect something like:
<snip>
an OrderedCollection(
#($f #($o $o))
#($b #($a $r $1 $2))
)
</snip>
Thank you!
Cheers,
Alberto
[1] http://www.lukas-renggli.ch/blog/petitparser-1
13 years, 1 month
Mondrian HorizontalNarrowTreeLayout
by Johan Fabry
Hi Alex, all,
I like the Mondrian NarrowTreeLayout, in my tests it produces the best layout for partially ordered sets (advice dependencies in AspectMaps). However it aligns vertically, and to best fit the visualization it should do this horizontally. Would it be possible to produce a Horizontal version of that one (like HorizontalTreeLayout and friends )?
thanks in advance!
--
Johan Fabry
jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry
PLEIAD Lab - Computer Science Department (DCC) - University of Chile
13 years, 1 month
Transparent edges and tree map
by Alexandre Bergel
Hi!
I am cleaning some legacy code in Mondrian.
Anyone knows what is a transparent edge?
-=-=-=-=-=-=-=-=-=-=-=-=
testTransparentEdges
| view edges model |
model := MOTestModel new.
view := MOViewRenderer new.
view
nodes: model allNodes
using:
(MORectangleShape new width: 60; height: 60 "fixedWidth: 60 fixedHeight: 60").
edges := view
localEdges: model allEdges
from: [:entity | entity first]
to: [:entity | entity last]
using: model shapeForEdge.
window := view open.
self assert: edges value size = model allEdges size.
view layout: MOTreeMapLayout new.
view root deepApplyLayout.
edges value do: [:edge | self deny: edge isVisible].
view layout: MOTreeLayout new.
view root deepApplyLayout.
edges value do: [:edge | self assert: edge isVisible]
-=-=-=-=-=-=-=-=-=-=-=-=
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
13 years, 1 month
New version of DSMCore
by Alexandre Bergel
hi!
I renamed MOGraphElement>>children into nodes.
I produced a new version of DSMCore-Alexandre_Bergel.205
Maybe Jannik wants to double check.
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
13 years, 1 month
faster moose finder
by Tudor Girba
Hi,
When dealing large models, the Moose Finder was slow. I looked into
the reason, and it was due to Group>>= which was doing a
transformation to OrderedCollection.
I now removed the method, and thus group equality relies on the
default == implementation. All tests work, so I guess it is not really
a problem.
Anyway, as a consequence, the Finder is significantly faster now.
Please let me know if you relied on Group>>= or if you encounter other
related problems.
Cheers,
Doru
--
www.tudorgirba.com
"Every thing should have the right to be different."
13 years, 1 month
