Pavel's ChangeLog week of 2018-03-19

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Pavel's ChangeLog week of 2018-03-19

Pavel Krivanek-3
Hi,

I did some serious Ring 2 refactorings that I wanted to have finished
before the integration into Pharo.
Because Pharo now starts to support the stateful traits, it needs to
be supported by the metamodel too. However, we need to be able to
model the images with the old traits as well and from the internal
point of view, they are quite different.
Moreover, if you load a code into the Ring model, you sometimes do not
know if the behavior, where you load a method, is a class or you later
will realize that it is a trait. The Ring 2 used for this a complex
machinery that was able to switch the behavior kind using the
#becomeForward: message.
Some time ago I decided to solve both problems by introducing of the
behavior strategies. That means that every behavior is a composition
of an instance of the RGBehavior class and a behavior strategy (e.g.
RGClassStrategy). Then changing of the behavior kind is then only a
matter of swapping of the strategy (which has a state so it not so
straightforward but still easy). The classes like RGClass or RGTrait
are still present but now they are only the factories that produce the
behaviors and they have no real instances.

The next big thing I decided to do in Ring is renaming of the
entities. From the beginning, I used the prefix "RG2" to avoid the
collisions with the old Ring implementation but I supposed that before
the final release it will be renamed because, from the user
perspective, the Ring 2 should be a replacement for the old Ring and
not completely separate project. The attempts to replace the old Ring
with the new one showed me, that it is possible, but the old Ring is
so deeply used in the system that it leads to a huge amount of
instabilities.
So I decided to rename the Ring 2 classes and some methods to do not
make collisions with the old implementation. While the old Ring class
was named RGClassDefinition and in Ring 2 it was RG2ClassDefinition,
now it is renamed simply to RGClass. RG2Definition was renamed to
RGObject. The only ugly exception is RG2Package which is now named
RGPackageDefinition because the old Ring does not follow the naming
convention and uses the name "RGPackage". The old Ring packages will
get suffix "Deprecated" into their names. The old Ring and the Ring2
can coexist in one image and it is still possible to load the new Ring
into the Pharo 6.

Then I started to work on the changes metamodel for Ring with the goal
to be able to record, reproduce and revert (almost) all changes that
the user does in the model. The main goal of it is to be able to get
comparisons of two models and compute loading order of the changes so
it will be more easy to replace the Monticello metamodel and the
metamodel for code differences with a single solid solution based on
Ring.

Cheers,
-- Pavel

Reply | Threaded
Open this post in threaded view
|

Re: Pavel's ChangeLog week of 2018-03-19

Stephane Ducasse-3
Pavel

Why we do not know if this is a class or trait?
May be we could have decided that Ring2 only works for new traits if
this simplifies your life.

Stef

On Mon, Mar 26, 2018 at 10:37 AM, Pavel Krivanek
<[hidden email]> wrote:

> Hi,
>
> I did some serious Ring 2 refactorings that I wanted to have finished
> before the integration into Pharo.
> Because Pharo now starts to support the stateful traits, it needs to
> be supported by the metamodel too. However, we need to be able to
> model the images with the old traits as well and from the internal
> point of view, they are quite different.
> Moreover, if you load a code into the Ring model, you sometimes do not
> know if the behavior, where you load a method, is a class or you later
> will realize that it is a trait. The Ring 2 used for this a complex
> machinery that was able to switch the behavior kind using the
> #becomeForward: message.
> Some time ago I decided to solve both problems by introducing of the
> behavior strategies. That means that every behavior is a composition
> of an instance of the RGBehavior class and a behavior strategy (e.g.
> RGClassStrategy). Then changing of the behavior kind is then only a
> matter of swapping of the strategy (which has a state so it not so
> straightforward but still easy). The classes like RGClass or RGTrait
> are still present but now they are only the factories that produce the
> behaviors and they have no real instances.
>
> The next big thing I decided to do in Ring is renaming of the
> entities. From the beginning, I used the prefix "RG2" to avoid the
> collisions with the old Ring implementation but I supposed that before
> the final release it will be renamed because, from the user
> perspective, the Ring 2 should be a replacement for the old Ring and
> not completely separate project. The attempts to replace the old Ring
> with the new one showed me, that it is possible, but the old Ring is
> so deeply used in the system that it leads to a huge amount of
> instabilities.
> So I decided to rename the Ring 2 classes and some methods to do not
> make collisions with the old implementation. While the old Ring class
> was named RGClassDefinition and in Ring 2 it was RG2ClassDefinition,
> now it is renamed simply to RGClass. RG2Definition was renamed to
> RGObject. The only ugly exception is RG2Package which is now named
> RGPackageDefinition because the old Ring does not follow the naming
> convention and uses the name "RGPackage". The old Ring packages will
> get suffix "Deprecated" into their names. The old Ring and the Ring2
> can coexist in one image and it is still possible to load the new Ring
> into the Pharo 6.
>
> Then I started to work on the changes metamodel for Ring with the goal
> to be able to record, reproduce and revert (almost) all changes that
> the user does in the model. The main goal of it is to be able to get
> comparisons of two models and compute loading order of the changes so
> it will be more easy to replace the Monticello metamodel and the
> metamodel for code differences with a single solid solution based on
> Ring.
>
> Cheers,
> -- Pavel
>

Reply | Threaded
Open this post in threaded view
|

Re: Pavel's ChangeLog week of 2018-03-19

Pavel Krivanek-3
2018-03-26 10:52 GMT+02:00 Stephane Ducasse <[hidden email]>:
> Pavel
>
> Why we do not know if this is a class or trait?

Imagine that you are loading a package that has an extension method to
a class in a foreign package. It is identified only by the behavior
name, e.g. "TBehavior". But later, e.g. during merging of the package
model with some other, you will realize that the method is in fact a
part of a trait so you need to change kind of the class stub you
already have.

> Maybe we could have decided that Ring2 only works for new traits if
> this simplifies your life.

Because the traits are now a library and anyone can come with its own
metaclass that modifies the behavior metamodel, it is reasonable to
support it. And anyway, this work is already done ;-)

-- Pavel

> Stef
>
> On Mon, Mar 26, 2018 at 10:37 AM, Pavel Krivanek
> <[hidden email]> wrote:
>> Hi,
>>
>> I did some serious Ring 2 refactorings that I wanted to have finished
>> before the integration into Pharo.
>> Because Pharo now starts to support the stateful traits, it needs to
>> be supported by the metamodel too. However, we need to be able to
>> model the images with the old traits as well and from the internal
>> point of view, they are quite different.
>> Moreover, if you load a code into the Ring model, you sometimes do not
>> know if the behavior, where you load a method, is a class or you later
>> will realize that it is a trait. The Ring 2 used for this a complex
>> machinery that was able to switch the behavior kind using the
>> #becomeForward: message.
>> Some time ago I decided to solve both problems by introducing of the
>> behavior strategies. That means that every behavior is a composition
>> of an instance of the RGBehavior class and a behavior strategy (e.g.
>> RGClassStrategy). Then changing of the behavior kind is then only a
>> matter of swapping of the strategy (which has a state so it not so
>> straightforward but still easy). The classes like RGClass or RGTrait
>> are still present but now they are only the factories that produce the
>> behaviors and they have no real instances.
>>
>> The next big thing I decided to do in Ring is renaming of the
>> entities. From the beginning, I used the prefix "RG2" to avoid the
>> collisions with the old Ring implementation but I supposed that before
>> the final release it will be renamed because, from the user
>> perspective, the Ring 2 should be a replacement for the old Ring and
>> not completely separate project. The attempts to replace the old Ring
>> with the new one showed me, that it is possible, but the old Ring is
>> so deeply used in the system that it leads to a huge amount of
>> instabilities.
>> So I decided to rename the Ring 2 classes and some methods to do not
>> make collisions with the old implementation. While the old Ring class
>> was named RGClassDefinition and in Ring 2 it was RG2ClassDefinition,
>> now it is renamed simply to RGClass. RG2Definition was renamed to
>> RGObject. The only ugly exception is RG2Package which is now named
>> RGPackageDefinition because the old Ring does not follow the naming
>> convention and uses the name "RGPackage". The old Ring packages will
>> get suffix "Deprecated" into their names. The old Ring and the Ring2
>> can coexist in one image and it is still possible to load the new Ring
>> into the Pharo 6.
>>
>> Then I started to work on the changes metamodel for Ring with the goal
>> to be able to record, reproduce and revert (almost) all changes that
>> the user does in the model. The main goal of it is to be able to get
>> comparisons of two models and compute loading order of the changes so
>> it will be more easy to replace the Monticello metamodel and the
>> metamodel for code differences with a single solid solution based on
>> Ring.
>>
>> Cheers,
>> -- Pavel
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Pavel's ChangeLog week of 2018-03-19

Guillermo Polito
Can't we make Extensions first class objects in ring?

On Mon, Mar 26, 2018 at 11:02 AM, Pavel Krivanek <[hidden email]> wrote:
2018-03-26 10:52 GMT+02:00 Stephane Ducasse <[hidden email]>:
> Pavel
>
> Why we do not know if this is a class or trait?

Imagine that you are loading a package that has an extension method to
a class in a foreign package. It is identified only by the behavior
name, e.g. "TBehavior". But later, e.g. during merging of the package
model with some other, you will realize that the method is in fact a
part of a trait so you need to change kind of the class stub you
already have.

> Maybe we could have decided that Ring2 only works for new traits if
> this simplifies your life.

Because the traits are now a library and anyone can come with its own
metaclass that modifies the behavior metamodel, it is reasonable to
support it. And anyway, this work is already done ;-)

-- Pavel

> Stef
>
> On Mon, Mar 26, 2018 at 10:37 AM, Pavel Krivanek
> <[hidden email]> wrote:
>> Hi,
>>
>> I did some serious Ring 2 refactorings that I wanted to have finished
>> before the integration into Pharo.
>> Because Pharo now starts to support the stateful traits, it needs to
>> be supported by the metamodel too. However, we need to be able to
>> model the images with the old traits as well and from the internal
>> point of view, they are quite different.
>> Moreover, if you load a code into the Ring model, you sometimes do not
>> know if the behavior, where you load a method, is a class or you later
>> will realize that it is a trait. The Ring 2 used for this a complex
>> machinery that was able to switch the behavior kind using the
>> #becomeForward: message.
>> Some time ago I decided to solve both problems by introducing of the
>> behavior strategies. That means that every behavior is a composition
>> of an instance of the RGBehavior class and a behavior strategy (e.g.
>> RGClassStrategy). Then changing of the behavior kind is then only a
>> matter of swapping of the strategy (which has a state so it not so
>> straightforward but still easy). The classes like RGClass or RGTrait
>> are still present but now they are only the factories that produce the
>> behaviors and they have no real instances.
>>
>> The next big thing I decided to do in Ring is renaming of the
>> entities. From the beginning, I used the prefix "RG2" to avoid the
>> collisions with the old Ring implementation but I supposed that before
>> the final release it will be renamed because, from the user
>> perspective, the Ring 2 should be a replacement for the old Ring and
>> not completely separate project. The attempts to replace the old Ring
>> with the new one showed me, that it is possible, but the old Ring is
>> so deeply used in the system that it leads to a huge amount of
>> instabilities.
>> So I decided to rename the Ring 2 classes and some methods to do not
>> make collisions with the old implementation. While the old Ring class
>> was named RGClassDefinition and in Ring 2 it was RG2ClassDefinition,
>> now it is renamed simply to RGClass. RG2Definition was renamed to
>> RGObject. The only ugly exception is RG2Package which is now named
>> RGPackageDefinition because the old Ring does not follow the naming
>> convention and uses the name "RGPackage". The old Ring packages will
>> get suffix "Deprecated" into their names. The old Ring and the Ring2
>> can coexist in one image and it is still possible to load the new Ring
>> into the Pharo 6.
>>
>> Then I started to work on the changes metamodel for Ring with the goal
>> to be able to record, reproduce and revert (almost) all changes that
>> the user does in the model. The main goal of it is to be able to get
>> comparisons of two models and compute loading order of the changes so
>> it will be more easy to replace the Monticello metamodel and the
>> metamodel for code differences with a single solid solution based on
>> Ring.
>>
>> Cheers,
>> -- Pavel
>>
>




--

   

Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - http://www.cnrs.fr


Web: http://guillep.github.io

Phone: +33 06 52 70 66 13

Reply | Threaded
Open this post in threaded view
|

Re: Pavel's ChangeLog week of 2018-03-19

Pavel Krivanek-3
Maybe, but it does not solve the issue because, in Ring, every model is a full, closed and complete environment where every message tries to return you reasonable value even for unresolved parts of the model. You can start to build your model from everywhere you want.

method := RGMethod named: #someMethod.
self assert: (method parent localMethods size = 1).
self assert: (method parent name = #unresolved).
self assert: (method parent package = method package).

method parent name: #SomeBehavior.
self assert: method parent isTrait not.
method environment ensureTraitNamed: #SomeBehavior.
method package: (method environment ensurePackageNamed: #PackageWithExtension).
self assert: method parent isTrait.
self assert: (method parent package ~~ method package).

Cheers,
-- Pavel

2018-03-26 11:21 GMT+02:00 Guillermo Polito <[hidden email]>:
Can't we make Extensions first class objects in ring?

On Mon, Mar 26, 2018 at 11:02 AM, Pavel Krivanek <[hidden email]> wrote:
2018-03-26 10:52 GMT+02:00 Stephane Ducasse <[hidden email]>:
> Pavel
>
> Why we do not know if this is a class or trait?

Imagine that you are loading a package that has an extension method to
a class in a foreign package. It is identified only by the behavior
name, e.g. "TBehavior". But later, e.g. during merging of the package
model with some other, you will realize that the method is in fact a
part of a trait so you need to change kind of the class stub you
already have.

> Maybe we could have decided that Ring2 only works for new traits if
> this simplifies your life.

Because the traits are now a library and anyone can come with its own
metaclass that modifies the behavior metamodel, it is reasonable to
support it. And anyway, this work is already done ;-)

-- Pavel

> Stef
>
> On Mon, Mar 26, 2018 at 10:37 AM, Pavel Krivanek
> <[hidden email]> wrote:
>> Hi,
>>
>> I did some serious Ring 2 refactorings that I wanted to have finished
>> before the integration into Pharo.
>> Because Pharo now starts to support the stateful traits, it needs to
>> be supported by the metamodel too. However, we need to be able to
>> model the images with the old traits as well and from the internal
>> point of view, they are quite different.
>> Moreover, if you load a code into the Ring model, you sometimes do not
>> know if the behavior, where you load a method, is a class or you later
>> will realize that it is a trait. The Ring 2 used for this a complex
>> machinery that was able to switch the behavior kind using the
>> #becomeForward: message.
>> Some time ago I decided to solve both problems by introducing of the
>> behavior strategies. That means that every behavior is a composition
>> of an instance of the RGBehavior class and a behavior strategy (e.g.
>> RGClassStrategy). Then changing of the behavior kind is then only a
>> matter of swapping of the strategy (which has a state so it not so
>> straightforward but still easy). The classes like RGClass or RGTrait
>> are still present but now they are only the factories that produce the
>> behaviors and they have no real instances.
>>
>> The next big thing I decided to do in Ring is renaming of the
>> entities. From the beginning, I used the prefix "RG2" to avoid the
>> collisions with the old Ring implementation but I supposed that before
>> the final release it will be renamed because, from the user
>> perspective, the Ring 2 should be a replacement for the old Ring and
>> not completely separate project. The attempts to replace the old Ring
>> with the new one showed me, that it is possible, but the old Ring is
>> so deeply used in the system that it leads to a huge amount of
>> instabilities.
>> So I decided to rename the Ring 2 classes and some methods to do not
>> make collisions with the old implementation. While the old Ring class
>> was named RGClassDefinition and in Ring 2 it was RG2ClassDefinition,
>> now it is renamed simply to RGClass. RG2Definition was renamed to
>> RGObject. The only ugly exception is RG2Package which is now named
>> RGPackageDefinition because the old Ring does not follow the naming
>> convention and uses the name "RGPackage". The old Ring packages will
>> get suffix "Deprecated" into their names. The old Ring and the Ring2
>> can coexist in one image and it is still possible to load the new Ring
>> into the Pharo 6.
>>
>> Then I started to work on the changes metamodel for Ring with the goal
>> to be able to record, reproduce and revert (almost) all changes that
>> the user does in the model. The main goal of it is to be able to get
>> comparisons of two models and compute loading order of the changes so
>> it will be more easy to replace the Monticello metamodel and the
>> metamodel for code differences with a single solid solution based on
>> Ring.
>>
>> Cheers,
>> -- Pavel
>>
>




--

   

Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - http://www.cnrs.fr


Web: http://guillep.github.io

Phone: <a href="tel:+33%206%2052%2070%2066%2013" value="+33652706613" target="_blank">+33 06 52 70 66 13


Reply | Threaded
Open this post in threaded view
|

Re: Pavel's ChangeLog week of 2018-03-19

Stephane Ducasse-3
Thanks Pavel. 
Carolina will start to work with Ring2 and Calypso to work on micro kernels :)

Stef

On Mon, Mar 26, 2018 at 11:41 AM, Pavel Krivanek <[hidden email]> wrote:
Maybe, but it does not solve the issue because, in Ring, every model is a full, closed and complete environment where every message tries to return you reasonable value even for unresolved parts of the model. You can start to build your model from everywhere you want.

method := RGMethod named: #someMethod.
self assert: (method parent localMethods size = 1).
self assert: (method parent name = #unresolved).
self assert: (method parent package = method package).

method parent name: #SomeBehavior.
self assert: method parent isTrait not.
method environment ensureTraitNamed: #SomeBehavior.
method package: (method environment ensurePackageNamed: #PackageWithExtension).
self assert: method parent isTrait.
self assert: (method parent package ~~ method package).

Cheers,
-- Pavel

2018-03-26 11:21 GMT+02:00 Guillermo Polito <[hidden email]>:
Can't we make Extensions first class objects in ring?

On Mon, Mar 26, 2018 at 11:02 AM, Pavel Krivanek <[hidden email]> wrote:
2018-03-26 10:52 GMT+02:00 Stephane Ducasse <[hidden email]>:
> Pavel
>
> Why we do not know if this is a class or trait?

Imagine that you are loading a package that has an extension method to
a class in a foreign package. It is identified only by the behavior
name, e.g. "TBehavior". But later, e.g. during merging of the package
model with some other, you will realize that the method is in fact a
part of a trait so you need to change kind of the class stub you
already have.

> Maybe we could have decided that Ring2 only works for new traits if
> this simplifies your life.

Because the traits are now a library and anyone can come with its own
metaclass that modifies the behavior metamodel, it is reasonable to
support it. And anyway, this work is already done ;-)

-- Pavel

> Stef
>
> On Mon, Mar 26, 2018 at 10:37 AM, Pavel Krivanek
> <[hidden email]> wrote:
>> Hi,
>>
>> I did some serious Ring 2 refactorings that I wanted to have finished
>> before the integration into Pharo.
>> Because Pharo now starts to support the stateful traits, it needs to
>> be supported by the metamodel too. However, we need to be able to
>> model the images with the old traits as well and from the internal
>> point of view, they are quite different.
>> Moreover, if you load a code into the Ring model, you sometimes do not
>> know if the behavior, where you load a method, is a class or you later
>> will realize that it is a trait. The Ring 2 used for this a complex
>> machinery that was able to switch the behavior kind using the
>> #becomeForward: message.
>> Some time ago I decided to solve both problems by introducing of the
>> behavior strategies. That means that every behavior is a composition
>> of an instance of the RGBehavior class and a behavior strategy (e.g.
>> RGClassStrategy). Then changing of the behavior kind is then only a
>> matter of swapping of the strategy (which has a state so it not so
>> straightforward but still easy). The classes like RGClass or RGTrait
>> are still present but now they are only the factories that produce the
>> behaviors and they have no real instances.
>>
>> The next big thing I decided to do in Ring is renaming of the
>> entities. From the beginning, I used the prefix "RG2" to avoid the
>> collisions with the old Ring implementation but I supposed that before
>> the final release it will be renamed because, from the user
>> perspective, the Ring 2 should be a replacement for the old Ring and
>> not completely separate project. The attempts to replace the old Ring
>> with the new one showed me, that it is possible, but the old Ring is
>> so deeply used in the system that it leads to a huge amount of
>> instabilities.
>> So I decided to rename the Ring 2 classes and some methods to do not
>> make collisions with the old implementation. While the old Ring class
>> was named RGClassDefinition and in Ring 2 it was RG2ClassDefinition,
>> now it is renamed simply to RGClass. RG2Definition was renamed to
>> RGObject. The only ugly exception is RG2Package which is now named
>> RGPackageDefinition because the old Ring does not follow the naming
>> convention and uses the name "RGPackage". The old Ring packages will
>> get suffix "Deprecated" into their names. The old Ring and the Ring2
>> can coexist in one image and it is still possible to load the new Ring
>> into the Pharo 6.
>>
>> Then I started to work on the changes metamodel for Ring with the goal
>> to be able to record, reproduce and revert (almost) all changes that
>> the user does in the model. The main goal of it is to be able to get
>> comparisons of two models and compute loading order of the changes so
>> it will be more easy to replace the Monticello metamodel and the
>> metamodel for code differences with a single solid solution based on
>> Ring.
>>
>> Cheers,
>> -- Pavel
>>
>




--

   

Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - http://www.cnrs.fr


Web: http://guillep.github.io

Phone: <a href="tel:+33%206%2052%2070%2066%2013" value="+33652706613" target="_blank">+33 06 52 70 66 13



Reply | Threaded
Open this post in threaded view
|

Re: Pavel's ChangeLog week of 2018-03-19

Tudor Girba-2
In reply to this post by Pavel Krivanek-3
This sounds really exciting!

I’d be very curious to learn more about this.

Cheers,
Doru

> On Mar 26, 2018, at 10:37 AM, Pavel Krivanek <[hidden email]> wrote:
>
> Hi,
>
> I did some serious Ring 2 refactorings that I wanted to have finished
> before the integration into Pharo.
> Because Pharo now starts to support the stateful traits, it needs to
> be supported by the metamodel too. However, we need to be able to
> model the images with the old traits as well and from the internal
> point of view, they are quite different.
> Moreover, if you load a code into the Ring model, you sometimes do not
> know if the behavior, where you load a method, is a class or you later
> will realize that it is a trait. The Ring 2 used for this a complex
> machinery that was able to switch the behavior kind using the
> #becomeForward: message.
> Some time ago I decided to solve both problems by introducing of the
> behavior strategies. That means that every behavior is a composition
> of an instance of the RGBehavior class and a behavior strategy (e.g.
> RGClassStrategy). Then changing of the behavior kind is then only a
> matter of swapping of the strategy (which has a state so it not so
> straightforward but still easy). The classes like RGClass or RGTrait
> are still present but now they are only the factories that produce the
> behaviors and they have no real instances.
>
> The next big thing I decided to do in Ring is renaming of the
> entities. From the beginning, I used the prefix "RG2" to avoid the
> collisions with the old Ring implementation but I supposed that before
> the final release it will be renamed because, from the user
> perspective, the Ring 2 should be a replacement for the old Ring and
> not completely separate project. The attempts to replace the old Ring
> with the new one showed me, that it is possible, but the old Ring is
> so deeply used in the system that it leads to a huge amount of
> instabilities.
> So I decided to rename the Ring 2 classes and some methods to do not
> make collisions with the old implementation. While the old Ring class
> was named RGClassDefinition and in Ring 2 it was RG2ClassDefinition,
> now it is renamed simply to RGClass. RG2Definition was renamed to
> RGObject. The only ugly exception is RG2Package which is now named
> RGPackageDefinition because the old Ring does not follow the naming
> convention and uses the name "RGPackage". The old Ring packages will
> get suffix "Deprecated" into their names. The old Ring and the Ring2
> can coexist in one image and it is still possible to load the new Ring
> into the Pharo 6.
>
> Then I started to work on the changes metamodel for Ring with the goal
> to be able to record, reproduce and revert (almost) all changes that
> the user does in the model. The main goal of it is to be able to get
> comparisons of two models and compute loading order of the changes so
> it will be more easy to replace the Monticello metamodel and the
> metamodel for code differences with a single solid solution based on
> Ring.
>
> Cheers,
> -- Pavel
>

--
www.tudorgirba.com
www.feenk.com

"It's not how it is, it is how we see it."


Reply | Threaded
Open this post in threaded view
|

Re: Pavel's ChangeLog week of 2018-03-19

Juraj Kubelka
In reply to this post by Pavel Krivanek-3
Hi Pavel,

On Mar 26, 2018, at 10:37, Pavel Krivanek <[hidden email]> wrote:

Then I started to work on the changes metamodel for Ring with the goal
to be able to record, reproduce and revert (almost) all changes that
the user does in the model. The main goal of it is to be able to get
comparisons of two models and compute loading order of the changes so
it will be more easy to replace the Monticello metamodel and the
metamodel for code differences with a single solid solution based on
Ring.

I am interested in playing with the recording-reproduce-and-revert feature. Is it possible? 
How do you compare it with Epicea? 
May your work replace Epicea (or part of it) or is it different? 

Cheers,
Juraj