- Pharo-dev - lists.pharo.org

[Pharo 7.0-dev] Build #722: Fix Case #21647 - Slot Comments Should List Necessary Overrides

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

There is a new Pharo build available! The status of the build #722 was: SUCCESS. The Pull Request #1150 was integrated: "Fix Case #21647 - Slot Comments Should List Necessary Overrides" Pull request url: https://github.com/pharo-project/pharo/pull/1150 Issue Url: https://pharo.fogbugz.com/f/cases/21647 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

March 26, 2018

[Pharo 7.0-dev] Build #721: 21623-Update-Jenkinsfile-to-use-staged-bootstrap

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

There is a new Pharo build available! The status of the build #721 was: SUCCESS. The Pull Request #1135 was integrated: "21623-Update-Jenkinsfile-to-use-staged-bootstrap" Pull request url: https://github.com/pharo-project/pharo/pull/1135 Issue Url: https://pharo.fogbugz.com/f/cases/21623 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

March 26, 2018

Re: [Pharo-dev] Experiment: New Download page based on Pharo Launcher

by Guillermo Polito

On Fri, Mar 23, 2018 at 7:53 PM, Ben Coman <btc(a)openinworld.com> wrote: > > > On 23 March 2018 at 11:31, Ben Coman <btc(a)openinworld.com> wrote: > >> >> >> On 23 March 2018 at 05:14, CÃ©drick BÃ©ler <cdrick65(a)gmail.com> wrote: >> >>> Hi, >>> >>> I just saw students and they still have some problem on windows with the >>> launcher. >>> >>> First, the launcher has to be run in admin mode. >>> >>> Then, the image download starts but there is an error when >>> uncompressing. Here is the stack. >>> >>> Any idea on how to fix that ? >>> >> >> Now I notice... >> the Linux PharoLauncher download is a ZIP file >> and the Mac PharoLauncher download is a ZIP file >> so... can we make the Windows PharoLauncher download a ZIP file? >> >> Doing that, at least as an interim measure, would *immediately* make >> PharoLauncher >> usable to students on locked-down Windows machines in University student >> labs. >> I'd expect this will improve the success with this experiment >> to use PharoLauncher as the main user entry point. >> >> The problem with using an "Installer" for the Windows PharoLauncher is >> the large amount >> of testing required to work *reliably* with *all* the "different ways >> people work" >> under several different versions of Windows introduced different layers >> of user security intricacies. >> Lets move forward in small steps. A ZIP download/extract is simple, and >> consistent with other platforms. >> >> In the meantime while waiting for that to happen, you can... >> >> 1. Download/extract http://files.pharo.org/platform/Pharo6.1-win.zip >> >> 2. Rename Pharo6.1 folder to PharoLauncher >> Rename Pharo6.1.* files to PharoLauncher1.1.* >> >> 3. Metacello new >> smalltalkhubUser: 'Pharo' >> project: 'PharoLauncher'; >> configuration: 'PharoLauncher'; >> load. >> PhLDeploymentScript doAll. >> PharoLauncher open. >> Smalltalk snapshot: true andQuit: true. >> > >> 4. Zip up the parent folder, test on another machine and provide a link >> to your students. >> >> cheers -ben >> >> >> P.S. I was going to suggest also renaming Pharo.exe to >> PharoLauncher.exe >> but with an empty Documents\Pharo\vms >> I get... "Error: Cannot detect Pharo executable in >> C:\Temp\MyPharoLauncher\PharoLauncher" >> in PhLVirtualMachine>>initializeOn: "File @ >> C:\Temp\MyPharoLauncher\PharoLauncher" >> since "executables := aFolder allChildrenMatching: self class >> executableName." >> is empty since "self class executableName" ==> "Pharo.exe" >> >> It would be nice for that to not be hard coded. I tried digging further >> but ran out of time. >> I am curious it mattered since using "Pharo.exe" the Launcher went on to >> download a VM anyway. >> >> >> P.S.2. >> I believe the best path forward for system-wide PharoLauncher installed >> under "C:\Program Files" >> would be to install there only... >> * the VM >> * PharoLauncher.ZIP >> * a tiny non-Pharo wrapper program as the shortcut linked from AllUsers > >> Start Menu > PharoLauncher >> that extracts PharoLauncher.ZIP to the user's data area and then starts >> that user specific PharoLauncher. >> >> Then regardless whether: >> * they individually download/extract PharoLauncher.ZIP >> * the system-wide-wrapper extracts PharoLauncher.ZIP >> its a similar experience for users which should aid reliability by >> reducing the number of "different " use cases. >> > > Coincidentally I have returned to Windows for a short while so thought I > should > put my money where my mouth is and have a stab at this. After a few hours > trying with NSIS, > I went searching for an alternative and Advanced Installer looked like a > good chance. > https://www.advancedinstaller.com/feats-list.html > The important part of (free) Basic Features is "Windows 10/8/7/Vista and > UAC installs" > Also further down are some CI options. > > After just the "Simple Installation" tutorial and experimenting a few > hours I ironed out > a potential solution uploaded for testing to > http://www.mediafire.com/file/3g579bmzqspt8e1/BCPharoLauncher.msi > with the full build tree at http://www.mediafire.com/file/ > 5ijiww848lbkk7m/PharoLauncher%20Advanced%20Installer.zip > Links should be live for 30 days. > I've directly attached the much smaller installer-configuration file > "PharoLauncher.aip". > > > PharoLauncher was built with some minor changes from above... > 1. Download/extracted http://files.pharo.org/platform/Pharo6.1-win.zip > > 2. Renamed Pharo6.1 folder to BCPharoLauncher > Renamed Pharo6.1.* files to PharoLauncher1.1.* > > 3. Metacello new > smalltalkhubUser: 'Pharo' > project: 'PharoLauncher'; > configuration: 'PharoLauncher'; > load. > PharoLauncher hardResetPersistanceState: true. > PhLDeploymentScript doAll. > PhLDeploymentScript closeWindowsAndOpenLauncher. > Smalltalk snapshot: true andQuit: true. > > 4. Moved the image & changes files into a subfolder "PerUserFiles" > > 5. Built BCPharoLauncher.msi > > I prefixed my initials to distinguish it from the current official > PharoLauncher installer. > Hopefully this can be adopted as the official installer and they can be > dropped off. > > > Key features: > a. Provides a choice to install for "Everybody" (i.e. C:\Program Files > (x86)\Pharo\BCPharoLauncher\) > or "Only for me" (i.e. C:\Users\Ben\AppData\Local\Programs\Pharo\ > BCPharoLauncher\) > per attached screen snapshot. > > b. Start the install as a Standard User and it escalates only as needed. > WOW, YES. I want this, thanks Ben :) > > c. The Desktop and Start Menu shortcuts run the following script... > > // File: PharoLauncher.js > // Author: Ben Coman 2018.03.24 > // Purpose: Facilitate each user to run a personal copy of > PharoLauncher.image in their own data area. > > // Locations > basename = "\\PharoLauncher1.1"; > WshShell = WScript.CreateObject("WScript.Shell"); > fso = WScript.CreateObject("Scripting.FileSystemObject"); > systemFolder = fso.GetAbsolutePathName("."); > vmFilename = systemFolder + "\\Pharo.exe" > systemBasename = systemFolder + "\\PerUserFiles" + basename; > userFolder = WshShell.ExpandEnvironmentStrings("% > LOCALAPPDATA%\\Pharo"); > userFolder2 = userFolder + "\\PharoLauncher"; > userBasename = userFolder2 + basename; > > // Ensure user data folder exists for PharoLauncher > if( ! fso.FolderExists(userFolder)) > { fso.CreateFolder(userFolder); > fso.CreateFolder(userFolder2) > } > > // If either image or changes files missing from user folder, > copy from system folder. > if( ! fso.FileExists(userBasename + ".image") || ! > fso.FileExists(userBasename + ".changes")) > { > //WScript.Echo("Setting up user environment"); > fso.CopyFile(systemBasename + ".image", userBasename + > ".image", true); > fso.CopyFile(systemBasename + ".changes", userBasename + > ".changes", true); > } > > // Start personal copy of PharoLauncher > WshShell.Exec(vmFilename + " " + userBasename + ".image") > > > cheers -ben > > -- 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

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 <guillermopolito(a)gmail.com>: > 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 <+33%206%2052%2070%2066%2013> >

March 26, 2018

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