- Pharo-dev - lists.pharo.org

[Pharo 7.0-dev] Build #728: 21577 Cannot read from /dev/urandom

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

There is a new Pharo build available! The status of the build #728 was: SUCCESS. The Pull Request #1093 was integrated: "21577 Cannot read from /dev/urandom" Pull request url: https://github.com/pharo-project/pharo/pull/1093 Issue Url: https://pharo.fogbugz.com/f/cases/Issue21577 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

March 27, 2018

[ANN] Slides for a Lecture: MetaLinks

by Marcus Denker

Hi, I did last week a short lecture at VUB Brussels. Topic: MetaLinks. Slideshare: https://www.slideshare.net/MarcusDenker/lecture-metalinks PDF: http://marcusdenker.de/talks/18LectureMetaLinks/MetaLinks.pdf <http://marcusdenker.de/talks/18LectureMetaLinks/MetaLinks.pdf> Marcus

March 27, 2018

[Pharo 7.0-dev] Build #727: 21642-Add-Deprecated-to-the-old-Ring-package-names

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

There is a new Pharo build available! The status of the build #727 was: SUCCESS. The Pull Request #1148 was integrated: "21642-Add-Deprecated-to-the-old-Ring-package-names" Pull request url: https://github.com/pharo-project/pharo/pull/1148 Issue Url: https://pharo.fogbugz.com/f/cases/21642 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

March 27, 2018

[Pharo 7.0-dev] Build #726: 21646 AbstractFileReference should use "utilities" protocol name

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

There is a new Pharo build available! The status of the build #726 was: SUCCESS. The Pull Request #1149 was integrated: "21646 AbstractFileReference should use "utilities" protocol name" Pull request url: https://github.com/pharo-project/pharo/pull/1149 Issue Url: https://pharo.fogbugz.com/f/cases/21646 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

March 27, 2018

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

by Christophe Demarey

Hi Ben, > Le 26 mars 2018 Ã 17:21, Ben Coman <btc(a)openinworld.com> a Ã©crit : > > 2. Double-clicked it and got "Windows Defender SmartScreen prevented an unrecognized app from starting." [1] > (btw, I didn't get this with the msi-installer generated from Advanced Installer which I linked above. But maybe that was because the msi-installer was created and installed on the same PC, so it was just trusting itself by default. The msi wasn't signed, so is the experience different on other people's machine?) For this, I can get a signed version with Inria. It just requires manual signing by some Inria security unit. So I will only do this for release versions > 3. Clicked "More Info" which allowed me to click "Run Anyway" and got... > "To continue, enter admin user name and password" [2] > so this is not really suited to students doing a user-level install on locked down lab machines. agree but with app signed, the problem should be solved > 4. After entering the password for user "Admin" (i.e. not Administrator, just another account in Administrators group) > the install location was (as expected) given as.... > "C:\Users\Admin\AppData\Local\PharoLauncher" [3] Ah, I missed that. Not what I expected. > which again is not friendly to non-admin users. > But just for kicks, I changed the install location to... > "C:\Users\Ben\AppData\Local\PharoLauncher" > and clicking on the PharoLauncher icon in the Start Menu > it opened okay, and downloaded a 60539 image and associated VM > and that image ran okay. > > So its a step in the right direction, however... > the Start Menu shortcut entry is for All User per its location here... > C:\ProgramData\Microsoft\Windows\Start Menu\Programs\PharoLauncher > and the target of the shortcut is... > C:\Users\Ben\AppData\Local\PharoLauncher\Pharo.exe > so it only worked coincidentally because I'm clicking the Start Menu icon as user "Ben" > and it would be broken for a second Standard User. > > From my reading it will be a struggle to get NSIS working smoothly > for multiple use cases at different privilege levels. i.e. both non-admin and admin users. I will probably give a change to AdvancedInstaller. Thanks for the feedback. Christophe

March 27, 2018

[Pharo 7.0-dev] Build #725: Use self hMargin negated instead of -3 in ScrollPane

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

There is a new Pharo build available! The status of the build #725 was: SUCCESS. The Pull Request #1094 was integrated: "Use self hMargin negated instead of -3 in ScrollPane" Pull request url: https://github.com/pharo-project/pharo/pull/1094 Issue Url: https://pharo.fogbugz.com/f/cases/21578 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

March 26, 2018

[Pharo 7.0-dev] Build #724: 21370 integrate fuel 300

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

There is a new Pharo build available! The status of the build #724 was: SUCCESS. The Pull Request #914 was integrated: "21370 integrate fuel 300" Pull request url: https://github.com/pharo-project/pharo/pull/914 Issue Url: https://pharo.fogbugz.com/f/cases/21370 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

March 26, 2018

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

by Tudor Girba

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 <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 > -- www.tudorgirba.com www.feenk.com "It's not how it is, it is how we see it."

March 26, 2018

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

by Stephane Ducasse

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

[Pharo 7.0-dev] Build #723: 21473 Cleanup CharacterSet class

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

There is a new Pharo build available! The status of the build #723 was: FAILURE. The Pull Request #1008 was integrated: "21473 Cleanup CharacterSet class" Pull request url: https://github.com/pharo-project/pharo/pull/1008 Issue Url: https://pharo.fogbugz.com/f/cases/21473 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

March 26, 2018