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