January 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] LearningObject

by Guillermo Polito

> On 28 ene 2016, at 11:07 a.m., Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > 2016-01-28 10:43 GMT+01:00 Guillermo Polito <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>>: > - You should not copy methods *just like that*. Methods are bounded (using the last literal in the literal list) to the class that owns it, to be able to resolve super sends. That is, every time there is a super send, the VM checks to which class it belongs and continues the lookup in the superclass of that class. > > But is not #addSelector:withMethod: should take care about it? I guess traits installation not creates methods by compiling. For traits. But I wouldnât be sure for others :). This is a part of the system that need some love I think... > > > - Maybe it is writing to the sources file that doesnât work from different processes? > > It should be fixed by synchronising such operations. > Anyway copy approach should not touch source file at all. >

Jan. 28, 2016

Re: [Pharo-dev] LearningObject

by stepharo

Indeed I could but I thought that recompiling I was sure that everything is correct Le 28/1/16 09:51, Denis Kudriashov a Ã©crit : > Hi. > > Nice trick :) > > 2016-01-27 20:42 GMT+01:00 stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>>: > > ATMinimalLearningObject >> addFromObjectSelector: aSelector > > | method | > method := OpalCompiler new > class: self class; > source: (Object sourceCodeAt: aSelector); > compile. > self class addSelector: aSelector withMethod: method. > > > Why compilation is needed? > Is adding copy of method not working? > > self class addSelector: aSelector withMethod: (Object >> > aSelector) copy. >

Jan. 28, 2016

Re: [Pharo-dev] LearningObject

by Denis Kudriashov

2016-01-28 10:43 GMT+01:00 Guillermo Polito <guillermopolito(a)gmail.com>: > - You should not copy methods *just like that*. Methods are bounded (using > the last literal in the literal list) to the class that owns it, to be able > to resolve super sends. That is, every time there is a super send, the VM > checks to which class it belongs and continues the lookup in the superclass > of that class. > But is not #addSelector:withMethod: should take care about it? I guess traits installation not creates methods by compiling. > > - Maybe it is writing to the sources file that doesnât work from > different processes? > It should be fixed by synchronising such operations. Anyway copy approach should not touch source file at all.

Jan. 28, 2016

Re: [Pharo-dev] LearningObject

by Guillermo Polito

- You should not copy methods *just like that*. Methods are bounded (using the last literal in the literal list) to the class that owns it, to be able to resolve super sends. That is, every time there is a super send, the VM checks to which class it belongs and continues the lookup in the superclass of that class. - Maybe it is writing to the sources file that doesnât work from different processes? > On 28 ene 2016, at 9:53 a.m., Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > 2016-01-28 8:23 GMT+01:00 stepharo <stepharo(a)free.fr <mailto:stepharo@free.fr>>: > I wanted to avoid to use the class Api becuase with ProtoObject you never know. > I think that I found the problem. > The compilation happens in another thread. > > It is strange. You create new compiler instance for each method. How they can influence each other?

Jan. 28, 2016

Re: [Pharo-dev] Contributing to Pharo

by Sven Van Caekenberghe

> On 28 Jan 2016, at 09:55, Christophe Demarey <Christophe.Demarey(a)inria.fr> wrote: > > > Le 28 janv. 2016 Ã 09:34, Sven Van Caekenberghe a Ã©crit : > >> >>> On 28 Jan 2016, at 09:23, Christophe Demarey <Christophe.Demarey(a)inria.fr> wrote: >>> >>> I read too fast. >>> But my comment is still true. >>> We also want a new version browser. Monticello browser is too tied to ... Monticello. We would like a better approach for both git and monticello. >> >> It is totally wrong to put Git and Monticello at the same level, they are related but different things. >> >> Monticello models our code and your changes to it. It also has a way of putting a package into a persistent representation that can be copied around. An MC server is nothing more than storage. >> >> Filetree is another way of doing that, using a different representation, but it still needs MC for the high level stuff. Git is versioned storage. And there is a conflict there, yes. >> >> But throwing away the MC code and changes model would leave you with file outs. You do not want to go there, really. Never, ever. > > I fully agree. > The problem is that Monticello does too much things: code representation, versioning, loading of the code and call of #initialize methods, etc. > We want to keep a code representation but the question that comes: is it the better code representation? We also have ring, ficus (hierarchical model on top of ring). For code representation, we would like to represent code (from packages to method source code) for multiple versions, in a hierarchical way (to be able to query easily), potentially coming from a remote environment. > We also need to split the loading part (loading from the code representation) and the serialization / deserialization part. > > At the end, we want an uniform way to represent code (not SCM related), a common API for versioning and different backends (git, Monticello). By the way, we can add the storage format: there are already different versions of the filetree format (with metadata, without, one file per method, one file per class). At some point, we need to handle this point of variability. Excellent summary. Lots of work ;-)

Jan. 28, 2016

Re: [Pharo-dev] Contributing to Pharo

by Christophe Demarey

Le 28 janv. 2016 Ã 09:34, Sven Van Caekenberghe a Ã©crit : > >> On 28 Jan 2016, at 09:23, Christophe Demarey <Christophe.Demarey(a)inria.fr> wrote: >> >> I read too fast. >> But my comment is still true. >> We also want a new version browser. Monticello browser is too tied to ... Monticello. We would like a better approach for both git and monticello. > > It is totally wrong to put Git and Monticello at the same level, they are related but different things. > > Monticello models our code and your changes to it. It also has a way of putting a package into a persistent representation that can be copied around. An MC server is nothing more than storage. > > Filetree is another way of doing that, using a different representation, but it still needs MC for the high level stuff. Git is versioned storage. And there is a conflict there, yes. > > But throwing away the MC code and changes model would leave you with file outs. You do not want to go there, really. Never, ever. I fully agree. The problem is that Monticello does too much things: code representation, versioning, loading of the code and call of #initialize methods, etc. We want to keep a code representation but the question that comes: is it the better code representation? We also have ring, ficus (hierarchical model on top of ring). For code representation, we would like to represent code (from packages to method source code) for multiple versions, in a hierarchical way (to be able to query easily), potentially coming from a remote environment. We also need to split the loading part (loading from the code representation) and the serialization / deserialization part. At the end, we want an uniform way to represent code (not SCM related), a common API for versioning and different backends (git, Monticello). By the way, we can add the storage format: there are already different versions of the filetree format (with metadata, without, one file per method, one file per class). At some point, we need to handle this point of variability.

Jan. 28, 2016

Re: [Pharo-dev] LearningObject

by Denis Kudriashov

2016-01-28 8:23 GMT+01:00 stepharo <stepharo(a)free.fr>: > I wanted to avoid to use the class Api becuase with ProtoObject you never > know. > I think that I found the problem. > The compilation happens in another thread. > It is strange. You create new compiler instance for each method. How they can influence each other?

Jan. 28, 2016

Re: [Pharo-dev] LearningObject

by Denis Kudriashov

Hi. Nice trick :) 2016-01-27 20:42 GMT+01:00 stepharo <stepharo(a)free.fr>: > ATMinimalLearningObject >> addFromObjectSelector: aSelector > > | method | > method := OpalCompiler new > class: self class; > source: (Object sourceCodeAt: aSelector); > compile. > self class addSelector: aSelector withMethod: method. > Why compilation is needed? Is adding copy of method not working? self class addSelector: aSelector withMethod: (Object >> aSelector) copy.

Jan. 28, 2016

Re: [Pharo-dev] Contributing to Pharo

by Thierry Goubier

Hi Dale, 2016-01-27 15:41 GMT+01:00 Dale Henrichs <dale.henrichs(a)gemtalksystems.com>: > > > On 1/27/16 12:03 AM, Thierry Goubier wrote: > >> Hi Dale, >> >> then a question: how does one query a baselineOf or a configOf to >> retrieve the current project state (i.e. packages) loaded in the image? >> >> Thierry >> >> Thierry, > > Good question:) > > To start with in tODE I have a class > TDMetacelloProjectRegistrationDefinition which is part of the following > hierarchy: > > Object > TDDefinition > TDPackageBasedDefinition > TDAbstractProjectRegistrationDefinition > TDGitProjectRegistrationDefinition > TDMetacelloProjectRegistrationDefinition > TDMetacelloRegistrationDefinition > TDMetacelloBaselineRegistrationDefinition > TDMetacelloConfigurationRegistrationDefinition > TDMetacelloHybridRegistrationDefinition > TDMetacelloUnloadedProjectRegistrationDefinition > > The method TDMetacelloProjectRegistrationDefinition>>workingCopies[1] > calculates the list of MCWorkingCopy instances for the loaded packages > associated with a project (including the configurationof or baselineof... > or both). > > The key Metacello methods called include: > > MetacelloProjectRegistration>>projectVersion[2] > MetacelloMCVersion>>packages[3] > MetacelloPackageSpec>>workingCopy[4] > MetacelloMCProjectSpec>>projectPackage[5] > > This is really the key information for doing all of the other operations > for a "Project Browser" like "save all dirty packages and commit" and "give > me diffs for all dirty packages in project"... > I was just asking that because I'd like to see that information merged as much as possible; separating concepts just strikes me as unneeded complexity, at least for baselines. Configurations are a bit different, since a configuration can snapshot multiple versions. But I'd really like to make it simple and obvious how to setup a project. I'll make a few tries, and see what I can come up with. When I'll have the time :( Thierry > > Dale > > [1] > https://github.com/dalehenrich/tode/blob/master/repository/Topez-Server-Cor… > [2] > https://github.com/dalehenrich/metacello-work/blob/master/repository/Metace… > [3] > https://github.com/dalehenrich/metacello-work/blob/master/repository/Metace… > [4] > https://github.com/dalehenrich/metacello-work/blob/master/repository/Metace… > [5] > https://github.com/dalehenrich/metacello-work/blob/master/repository/Metace… > >

Jan. 28, 2016

Re: [Pharo-dev] Contributing to Pharo

by Sven Van Caekenberghe

> On 28 Jan 2016, at 09:23, Christophe Demarey <Christophe.Demarey(a)inria.fr> wrote: > > I read too fast. > But my comment is still true. > We also want a new version browser. Monticello browser is too tied to ... Monticello. We would like a better approach for both git and monticello. It is totally wrong to put Git and Monticello at the same level, they are related but different things. Monticello models our code and your changes to it. It also has a way of putting a package into a persistent representation that can be copied around. An MC server is nothing more than storage. Filetree is another way of doing that, using a different representation, but it still needs MC for the high level stuff. Git is versioned storage. And there is a conflict there, yes. But throwing away the MC code and changes model would leave you with file outs. You do not want to go there, really. Never, ever. > Esteban did a prototype for himself but he has no time to work on it, sadly > > Le 27 janv. 2016 Ã 15:13, Dale Henrichs a Ã©crit : > >> Haha, I certainly understand the lack of time/manpower ... Just in case it wasn't clear, when I said "project browser" I wasn't talking about replacing the code browser (Nautilus), but replacing/augmenting the Monticello Browser - which should turn out to be a much simpler undertaking --- "Project Browser" that manages the projects within the image - load, save, changes, etc.: >> >> <Screen Shot 2016-01-27 at 6.11.33 AM.png> >> >> >> Dale >> >> On 1/26/16 11:29 PM, Christophe Demarey wrote: >>> Hi Dale, >>> >>> Le 27 janv. 2016 Ã 04:11, Dale Henrichs a Ã©crit : >>> >>>> I've been wondering no-one in the Pharo community has started building a "Project Browser" to replace the "Package Browser" .... I've had a "project browser" in tODE for several years now and you work with a manageble list of Metacello projects like the following: >>> Of course, we have that in mind. We would love to have it but lack of time / manpower ... >>> We are not happy with the current browser (Nautilus). We could have something really more powerful. It will come but we have other projects to achieve before ;) >>> If someone comes with a better browser, we would love to set it as default. >>> >>> Cheers, >>> Christophe >> >

Jan. 28, 2016