19 Jun
2010
19 Jun
'10
10:03 a.m.
Hi Jannik,
Let's take an example: a Node with a RectangleShape. The shape of this
particular node is drawn in:
MOShape>>display: anElement on: aCanvas
So, the RectangleShape will override this method and then it will draw
the actual shape based on the given anElement. For example, the height
of the rectangle is computed like:
MOBoundedShape>>heightFor: anElement
^ anElement
cachedNamed: #cacheheightFor:
ifAbsentInitializeWith: [ self computeHeightFor: anElement ]
So, the actual value is retrieved from anElement. So, you will have a
state per element, which is what is wanted.
I said that if you want to store explicit instance variables instead
of a dictionary, you have to create a class that stores the values for
each shape instance. So, in our example, we could have:
MOGraphElement>>shapeInstance
^ shapeInstance ifNil: [shapeInstance := self shape instanceFor: self]
and then have an MORectangleShapeInstance that stores actual values in
instance variables like height, width etc.
No real difference. The extensions of the meta-model store instance
variables. For example, the Java extensions store instance variables
related to annotations (in FAMIXEntity) or exceptions (in
FAMIXMethod). This should work reasonably well for small dictionaries,
which is the case for storing instance variables.
Well, you said that because of the cache, we need to invalidate it.
But that only happens when you have a global cache. In our case, as
soon as you close the window, the cache is gone.
Cheers,
Doru
As I mentioned
in two mails I sent in the past week, you cannot
store anything in the Shape because a Shape is just a specification
that is shared among multiple graph Elements. Thus, the state must
be stored in the Elements. At the moment this is achieved by the
means of a dictionary (see MOGraphElement>>attributeAt: and friends).
Ahah, yes, I did not read previous mail....
But if a shape is shared, how is computed "aShape model" ? There is
something I do not understand, really.... Of course, we
could also create an InstanceShape that has actual
instance variables, but that would have only limited impact.
I do not understand why ? We use the
same approach to store extension variables in Moose
Entities and that works just fine.
Yes but there is a difference: in moose entities, main variables
are stored in the state of the object, then we extend it and store
in a dictionary other things. Now, maybe I
missed something, but why do you say that the current
cache is global?
Where do I say that ? :) Cheers,
Jannik
--
www.tudorgirba.com
"Every now and then stop and ask yourself if the war you're fighting
is the right one."
Cheers,
Doru
On 18 Jun 2010, at 22:17, Laval Jannik wrote:
---
Jannik Laval
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev Hi Alex,
There is something I do not understand.
Why do you use a cache and not the state of the object ?
Isn't it more efficient to store values in instance variable
instead of a cache construct with a collection, or another complex
structure.
I'm sure you use cache for good reasons,
and maybe my vision is too naive.
But we have several problems which will appear in a near future:
- if we do not use cache, visualization is slow.
- if we use a cache, the space used by pharo will explode (for
now, in a vm with original parameters, it is not possible to load
7 times the MooseModel of Moose itself)
Now, if we have a state for a shape, there are no problem of cache
or of refresh.
But as I said before, my vision is maybe too naive.
Please, explain your choice :)
Thank you
Cheers,
Jannik
PS: for a result, eDSM is always slow, so some parameters are not
cached anymore ?
On Jun 18, 2010, at 14:50 , Alexandre Bergel wrote:
--
www.tudorgirba.com
"Every thing has its own flow."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev > Alex, do you cache all things ?
All the parameters in a shape that could be cached are now cached
(e.g., width: height: fillColor: borderColor: ...)
Cheers,
Alexandre
>
> Thanks,
> Jannik
>
> On Jun 17, 2010, at 17:47 , Tudor Girba wrote:
>
>> I tested on a regular DSM with 259 namespaces and I can now
>> properly scroll once it gets displayed.
>>
>> Jannik, Veronica, could you check in your cases?
>>
>> Cheers,
>> Doru
>>
>>
>>
>> On 17 Jun 2010, at 16:30, Tudor Girba wrote:
>>
>>> Hi Alex,
>>>
>>>>> Indeed, this caching should happen for all properties and
>>>>> for all shapes (both for nodes and for edges). I think that
>>>>> Alex stopped in the middle because he did not know whether
>>>>> this caching had an effect or not.
>>>>
>>>> I was wondering whether it would make sense to do this for
>>>> all the metrics. Apparently yes, I then continued. All shape
>>>> parameters should be cached.
>>>>> Alex, could you take a look at that?
>>>>
>>>> Done. Mondrian-Alexandre_Bergel.470
>>>
>>> Great. I checked a bit the implementation, and I would only
>>> suggest to check for isCached in the attributeAt:ifAbsent:
>>> method, instead of in every *For: methods.
>>>
>>>>> The next question is that if the border color is called all
>>>>> the time, what is the use of the bitmap cache?
>>>>
>>>> The bitmap is for not having to display inner nodes.
>>>> Recursion takes times.
>>>
>>> I know, but if you compute it once why do you still need to re-
>>> render?
>>>
>>> Cheers,
>>> Doru
>>>
>>>
>>>
>>>>>> ======
>>>>>> |view o |
>>>>>> view := MOViewRenderer new.
>>>>>> o := OrderedCollection new: 100.
>>>>>> 1 to: 100 do:[:i | o add: i].
>>>>>> (view shape: (MORectangleShape new
>>>>>> width: [:e | 200];
>>>>>> height: 200;
>>>>>> withBorder;
>>>>>> borderColor: [:e | (Delay forMilliseconds: 50) wait. Color
>>>>>> gray])).
>>>>>> view nodes: o.
>>>>>> view layout: (MOGridLayout new gapSize: 1).
>>>>>> view open
>>>>>> ======
>>>>
>>>> A better version could be
>>>> -=-=-=-=-=-=-=-=-=-=-=-=
>>>> |view o a |
>>>> a := {0}.
>>>> view := MOViewRenderer new.
>>>> o := OrderedCollection new: 100.
>>>> 1 to: 100 do:[:i | o add: i].
>>>> (view shape: (MORectangleShape new
>>>> width: [:e | 200];
>>>> height: 200;
>>>> withBorder;
>>>> borderColor: [:e | a at: 1 put: (a first + 1). Color gray])).
>>>> view nodes: o.
>>>> view layout: (MOGridLayout new gapSize: 1).
>>>> view open.
>>>> a
>>>> -=-=-=-=-=-=-=-=-=-=-=-=
>>>>
>>>> Just inspect the expression, and see if the array a changes
>>>> over the time.
>>>>
>>>> Is there any remaining problem left in Mondrian related to
>>>> the speed issue?
>>>>
>>>> Cheers,
>>>> Alexandre
>>>>
>>>>
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>> Moose-dev(a)iam.unibe.ch
>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>> --
>>> www.tudorgirba.com
>>>
>>> "Some battles are better lost than fought."
>>>
>>>
>>>
>>
>> --
>> www.tudorgirba.com
>>
>> "Some battles are better lost than fought."
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> Moose-dev(a)iam.unibe.ch
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> ---
> Jannik Laval
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
---
Jannik Laval
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev