March 2018 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Pavel's ChangeLog week of 2018-03-19

by Guillermo Polito

Can't we make Extensions first class objects in ring? On Mon, Mar 26, 2018 at 11:02 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > 2018-03-26 10:52 GMT+02:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > > 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 > > <pavel.krivanek(a)gmail.com> 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 <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

March 26, 2018

Re: [Pharo-dev] Pavel's ChangeLog week of 2018-03-19

by Pavel Krivanek

2018-03-26 10:52 GMT+02:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > 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 > <pavel.krivanek(a)gmail.com> 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 >> >

March 26, 2018

Re: [Pharo-dev] Pavel's ChangeLog week of 2018-03-19

by Stephane Ducasse

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 <pavel.krivanek(a)gmail.com> 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 >

March 26, 2018

Pavel's ChangeLog week of 2018-03-19

by Pavel Krivanek

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

March 26, 2018

[Pharo 7.0-dev] Build #720: 21471 AthensCairoMatrixTest and CairoUTF8ConverterTest should be in an own package Athens-Tests-Cairo

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #720 was: SUCCESS. The Pull Request #1006 was integrated: "21471 AthensCairoMatrixTest and CairoUTF8ConverterTest should be in an own package Athens-Tests-Cairo" Pull request url: https://github.com/pharo-project/pharo/pull/1006 Issue Url: https://pharo.fogbugz.com/f/cases/21471 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

March 26, 2018

Re: [Pharo-dev] Bloc: Simulating "Worlds"

by Sean P. DeNigris

Sean P. DeNigris wrote > Looks like it's time for my annual Bloc Dream check in ha ha! [crickets chirping]â¦ One year too many? ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

March 25, 2018

Re: [Pharo-dev] DigitalSignatureAlgorithm and dsa.test.out

by Torsten Bergmann

Answering myself: this file is generated from another method in the same class. Not obvious - we should clean this up ... > In DigitalSignatureAlgorithm>>testExamplesFromDisk uses a file called > "dsa.test.out" > > Do we have it somewhere (to turn the method into a real test) or can > we just delete the method ... > > Thx > T. > >

March 25, 2018

DigitalSignatureAlgorithm and dsa.test.out

by Torsten Bergmann

In DigitalSignatureAlgorithm>>testExamplesFromDisk uses a file called "dsa.test.out" Do we have it somewhere (to turn the method into a real test) or can we just delete the method ... Thx T.

March 25, 2018

Re: [Pharo-dev] Some segfault crashes and freezes when trying to re-run saved pharo 7 images

by Eliot Miranda

Hi Holger, On Sat, Mar 24, 2018 at 9:09 PM, Holger Freyther <holger(a)freyther.de> wrote: > > > > On 24. Mar 2018, at 19:22, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: > > > > Dear Eliot, > > > >> d.) Re-write FreeType with Alien and just use the Plugin to > conveniently link/load to freetype.. > > > > I wonder if there is sense in trying to come up with a general memory > handle object that includes a session identifier, so that attempts to free > stake memory always fail. > > I think it would help with the FT2Handle (to invalidate it on a new > session) but it will not solve other image resume/FFI issues. Let's assume > we have multiple calls into a C library (get a handle, call 1st method, > call 2nd method, have a loop with backwards jumps). Something like: > > > | memory | > memory := GetSomeMemorySomewhere. > > 1 to: 5 do: [ > self doSomeCStuffWithMemory: memory pointerAndCheckStillValid. > ... more C stuff > ]. > > We could be interrupted at any point and when the execution is resumed the > handles might be invalid. In Python terminology something like a context > manager could help: > > > # Image saving is delayed/inhibited until after the callout chain > CCallOut with: [ > 1 to: 5 do: [ > self doSomeCStuffWithMemory: memory pointerAndCheckStillValid. > ... more C stuff > ]. > ] > > What do you think? > Is the intent of CCallOut with: aBlock to collect and defer deallocations until the block completes? I think it's nice but complex and wonder how general it is. But it seems like it would impact a lot of code and require a lot of effort changing existing code bases. My handle scheme is only intended to fix the issue of images crashing on startup. The problems with crashing on startup being a) one loses one's work and b) the issue is hard to debug. That, for me, motivates something like the simple fix I p[roposed. I'm not standing in the way of something more beautiful, but I do believe that one shouldn't make the perfect the enemy of the good. _,,,^..^,,,_ best, Eliot

March 25, 2018

Re: [Pharo-dev] Released versions in Pharo Bootstrap

by stephan

On 20-03-18 08:55, Stephan Eggermont wrote: > Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com> > wrote: >> Le 19/03/2018 Ã 18:49, Stephan Eggermont a Ã©crit : >>> Then why bother releasing? >>> >> >> Hi, >> >> For people using Pharo 7 to not get the same bugs for more than 1 year, >> to get the new functionalities and to be able to detect new bugs >> introduced in releases. > > Forgive me for sounding like a broken record. How exactly is this style of > releasing going to help with these points? Anyone? Because AFAIK this just results in release cascades, and that is definitely bad practice. As soon as a dependency needs to change, you need to make a new release. Stephan

March 25, 2018