|
|
|
|
Subject: RE: bug in recursiveNeighbourhood: n
From: Nicolas Becu (becu@uni-hohenheim.de)
Date: Thu Jun 02 2005 - 10:14:31 CEST
Hello Pierre and others,
I would like to mention that, from my experience, changing the super class
of class directly in the browser is a bit risky.
I explain my point.
I used to follow the method you describe quiet often and each time or at
least quiet often I was getting error message when loading the model or when
initialising it. The problem was coming from the fact that Cormas stores
somewhere the collections of social, passive, spatial classes etc... and
that the direct change of a super class in the browser, doesn't update those
cormas collections. Therefore cormas was looking for classes stored in its
collections that didn't exist anymore.. (or at least that's what I
understood from the bugs I was getting)
I also faced the same kind of problem with the model and classes parameters
window (the one used for sensitivity analysis). Once again it was the fact
that the direct change of a super class in the browser, wasn't updating the
Parameter window and I was getting a bug.
What I was doing then, was changing manually the listing of classes of my
model, in the various cormas collections. But it was always bugging in some
way.
Now, with the functionality of cormas to define sub classes of any class of
the model things are much easier. Still I'm not sure that those direct
changes of super class in the browser are not going to disturb cormas. So
instead of doing those tricky things of updating manually cormas collections
etc... what I prefer to do when I want to change the super class of a class
of my model is :
- I file out my class, let say Mimi
- then I delete the class Mimi
- I save, close and reopen my model
- I create again the class Mimi at the correct location of my model class
hierarchy
- I open the file out file of my class Mimi (Mimi.st) with the File Manager
of VW
- I then change in the text the super class of my class Mimi.
- I save the st file and then I do a file in.
This seems to work better, because Cormas can make the entire initialisation
of the class that is specific to the new inheritance of that class.
However, I still get problems when I create a class that doesn't inherit
from Cormas classes. I especially do that for creating model specific
interfaces. I then create a class Interface which super class is
UI.ApplicationModel and I change the category of the class to the one of my
model.
Now, while it wasn't doing it in previous versions of Cormas, Cormas in
someway manages to see the class Interface and tries to fit it within its
collections of PassiveObjects, SocialClasses etc... and of course the class
Interface doesn't match the requirements of those kind of classes.
For example, I get the same kind of problems as the one described in Paolo's
last email. It tries to fit the Interface class within the Msg category and
as it can't it bugs.
I don't know how all these problems about changing class hierarchy and
defining classes that don't belong to the Cormas classes' hierarchy can be
resolved.
Perhaps it could be good to know how people using Cormas intensively manage
to do that kind of things in an appropriate way.
Perhaps we could also think of some new Cormas functionalities that will
enable moving a class from one hierarchical location to another (a "change
hierarchy" option below the "rename" and "remove" options when you right
click a class in entities window). In my case I would also enjoy having an
option (through a button in the cormas interface for example) that will
enable creating model specific interfaces in a clean way (without
interfering with Cormas entities).
See you
Nicolas
-----Original Message-----
From: owner-cormas@cirad.cirad.fr [mailto:owner-cormas@cirad.cirad.fr] On
Behalf Of Pierre Bommel
Sent: 01 June 2005 14:30
To: Stefano Farolfi
Cc: cormas@cirad.fr
Subject: Re: bug in recursiveNeighbourhood: n
Hello Stefano and Bruno,
To change the super class of a class, you need to open a browser on
your class, then
simply change the name of the super class. Ex :
CormasNS.Models.SylvoPastJeu defineClass: #Massif
superclass: #{CormasNS.Kernel.SpatialEntityAggregate}
by
CormasNS.Models.SylvoPastJeu defineClass: #Massif
superclass: #{CormasNS.Kernel. EntitySet}
And accept.
Bon courage les gars !
Pierre
Le 23 mai 05, à 07:22, Stefano Farolfi a écrit :
>
> Hello everybody,
> I need some technical help, does someone know how to change the
> superClass
> of a class already created? I am trying to change a
> SpatialAgregateNotConnex
> into a Spatial EntitySet. I tried to change the attribute "superClass"
> in
> the class definition and the hyerarchy changed, but the Cormas space
> representation still asks to this aggregate method of its old super
> class
> ( SpatialAgregateNotConnex ) and it sends me an error message...
> Thank you in advance for your help, if someone already had this
> problem,
> I wish you a nice week,
> Bruno Bonte
>
>
> Dr. Stefano Farolfi
> Cirad Tera Green
> Ceepa University of Pretoria
> 0002 Pretoria
> South Africa
>
> Tel. ++27 12 420 4659
> Fax: ++27 12 420 4958
> ----- Original Message -----
> From: "Pierre Bommel" <bommel@cirad.fr>
> To: "Hoekstra, J. (Jeljer)" <jhoekstra@feweb.vu.nl>
> Cc: <cormas@cirad.fr>
> Sent: Monday, August 23, 2004 6:00 PM
> Subject: Re: bug in recursiveNeighbourhood: n
>
>
>> Hello all,
>>
>> This error was already notified and corrected by Stan
> (http://cormas.cirad.fr/forum/cormas/archives/0104.html).
>> In Cormas2004 version the body of this method is now quite different :
>> recursiveNeighbourhood: radius
>> "Returns a collection of the cells include into the radius.
>> radius = Integer > 0"
>>
>> | allCells layers |
>> allCells := OrderedCollection new.
>> layers := self allLayersTo: radius.
>> layers do: [:layer | allCells addAll: layer].
>> ^allCells
>>
>> and it is much more quick than previously.
>> This is one of the new features that I didn't describe in the "what's
>> new"
> page...
>> Best regards,
>>
>> Pierre
>>
>> "Hoekstra, J. (Jeljer)" a écrit :
>>
>>> Hi all,
>>>
>>> I found an error in recursiveNeighbourhood: n (version 2003, perhaps
> also in 2004). It does some double counting. The bug is fixed by
> changing
> newVoisins in peripherie in the last line of the loop.
>>> The bug free version of recursiveNeighbourhood: n is added below.
>>>
>>> cheers,
>>> Jeljer
>>>
>>> recursiveNeighbourhood: n
>>> | ensemble peripherie newVoisins |
>>> ensemble := OrderedCollection new.
>>> ensemble add: self.
>>> peripherie := OrderedCollection new.
>>> peripherie add: self.
>>> n timesRepeat:
>>> [newVoisins := OrderedCollection new.
>>> peripherie do: [:p | p neighbourhood do:[:v| (newVoisins
>>> includes: v)
> ifFalse: [newVoisins add: v]]].
>>> "peripherie do: [:p | newVoisins addAll: p neighbourhood]."
>>> peripherie := newVoisins reject: [ :i | ensemble includes: i ].
>>> ensemble addAll: peripherie "newVoisins"].
>>> ^ensemble
>>
>> --
>> ***********************************
>> Pierre Bommel
>> CIRAD TA 60/15
>> 73, rue Jean-François Breton
>> 34398 Montpellier cedex 5 France
>> Phone: +33 (0)4 67 59 38 53
>> Fax: +33 (0)4 67 59 38 27
>> http://cormas.cirad.fr
>> ***********************************
>>
>>
>
>
Pierre Bommel
SHIS QI 26, Conjunto 15, Casa 18
71670-150
Brasilia DF
tel: (00 55 61) 367 3405