- Pharo-dev - lists.pharo.org

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

Re: [Pharo-dev] Contributing to Pharo

by Christophe Demarey

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. 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

Re: [Pharo-dev] LearningObject

by stepharo

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. Le 28/1/16 00:17, ClÃ©ment Bera a Ã©crit : > Hello, > > The logging of sources is not part of the compiler. It is part of the > behavior API. > > Something like that would work : > > ATMinimalLearningObject >> addFromObjectSelector: aSelector > self class compile: (Object >> aSelector) sourceCode classified: #foo > > Now it is strange that the decompiler can't decompile instVarAt: . It > looks like it is a bug related to primitive error code decompilation. > This is something I should look at during the sprint... > > > 2016-01-27 20:42 GMT+01:00 stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>>: > > Hi guys > > I'm on holidays (no book no mooc no bugs just playing magic good > music and hacking a bit) > and I wanted to implemented a fun object that learn from Object by > copying the methods. > > ProtoObject subclass: #ATMinimalLearningObject > instanceVariableNames: '' > classVariableNames: '' > package: 'MiniActalk2' > > > ATMinimalLearningObject >> doesNotUnderstand: aMessage > > | sel | > sel := aMessage selector. > Transcript show: 'Does not understand ', sel printString ; cr. > ^ (Object includesSelector: sel) > ifTrue: [ > self addFromObjectSelector: sel. > aMessage sendTo: self ] > ifFalse: [ super doesNotUnderstand: aMessage ]. > > ATMinimalLearningObject >> addFromObjectSelector: aSelector > > | method | > method := OpalCompiler new > class: self class; > source: (Object sourceCodeAt: aSelector); > compile. > self class addSelector: aSelector withMethod: method. > > ATMinimalLearningObject subclass: #ATProtozoid > instanceVariableNames: 'ff' > classVariableNames: '' > package: 'MiniActalk2' > > > Now it is working but I have the impression that we may have a > problem. > > When I do > ATProtozoid new instVarAt: 1 > > > I get the following definition for instVarAt: > > instVarAt: t1 > self error: 'Decompilation failed' > > > but > > Object sourceCodeAt: #instVarAt: returns the correct string. > > 'instVarAt: index > "Primitive. Answer a fixed variable in an object. The > numbering of the variables > corresponds to the named instance variables, followed by the > indexed instance > variables. Fail if the index is not an Integer or is not the > index of a fixed variable. > Essential. See Object documentation whatIsAPrimitive." > > <primitive: 173 error: ec> > self primitiveFailed' > > May be the compile is not logging the method body. > But since the compiler is full uncommented this is super nice to > learn and get empowered. > > Stef > > >

Jan. 28, 2016

Re: [Pharo-dev] Experiences with git, tODE and GsDevKit_home: Part 1 - basic structure considerations

by Ben Coman

On Thu, Jan 28, 2016 at 9:41 AM, Ben Coman <btc(a)openinworld.com> wrote: > > > On Thu, Jan 28, 2016 at 5:03 AM, Dale Henrichs < > dale.henrichs(a)gemtalksystems.com> wrote: > >> The git repository is not tightly coupled to the image like the changes >> file (you can delete a git repository without impacting the functionality >> of an image), but if you are making changes in the image, then you _are_ >> coupled to a particular git commit identified by its SHA. >> >> Metacello will record the SHA of the git repository at the time that >> packages are loaded from a git repository (to enable this feature in Pharo, >> some methods need to be implemented in the MetacelloPlatform for Pharo) and >> this information is stored along with the Metacello registration for the >> project. >> >> Since the git repository can be independently manipulated from the shell >> or an image can be saved that references a SHA that is no longer "current" >> .... it is very important that the SHA be recorded and made visible to >> users via the tools. >> > > By "current", do you mean the currently checked out directory as seen from > the shell command line? > > Slightly off topic... > I wonder if we could avoid needing a currently checked out directory as > seen from the command line and have the Image work directly with the git > repository (within the .git folder - is this what libgit integration may > give us?) thus making the Image the equivalent of the current checked out > directory? Then lets dump the .changes file by... rather than a method's > source reference being a (fragile) hardcoded index into the .changes file, > make each method an SHA key into the git (or mercurial) repository. > * Git is fundamentally a content-addressable filesystem with a VCS user > interface written on top of it. Youâll learn more about what this means in > a bit. [2] > * Git is a simple key-value data store. You can insert any kind of content > into it, and it will give you back a key that you can use to retrieve the > content again at any time. [3] > * [In Mercurial...] each revision of a file is identified by a 'NodeID', > which is a SHA hash of its contents (combined with the position of that > node in the history). [4] > * The baseline data structures for Fossil and Git are the same (modulo formatting details). Both systems store check-ins as immutable objects referencing their immediate ancestors and named by their SHA1 hash. [5] So to firm up this idea, while we might not want to tie ourselves too tightly to git, rather than try working with *all* types of source code management, would it be reasonable to concentrate on an abstraction layer focused on *content-addressable* source code? That is, would this provide flexibility for sufficient backend options, but a better experience with those than a totally generic source code management. (btw, Could EPICEA be made to work with SHAs?) cheers -ben > > In short, should our source code indexing be "content-addressable" with > the possibility to use *any* key-value repository. Each method SHA would > be calculated from its own source code and parent class SHA. Each class > would calculate its SHA from its definition and superclass' SHA. A > package/project SHA would be calculated from all its component class and > method SHAs. > > [1] https://git-scm.com/book/en/v1/Git-Internals-Plumbing-and-Porcelain > [2] https://git-scm.com/book/en/v1/Git-Internals > [3] https://git-scm.com/book/en/v1/Git-Internals-Git-Objects > [4] http://ericsink.com/vcbe/html/repository_structure.html > [5] http://fossil-scm.org/xfer/doc/trunk/www/fossil-v-git.wiki > > cheer -ben > > > >> Soooo --- managing skew is an important function for the "project >> browser"... Here's what the tODE "Project Browser" looks like when version >> skew is detected: >> > > In this I assume the red ones are skewed and the X ^ Y represent commits, > but could you explain which ones. > > > Well I think that's enough for now...Here are some topics that I plan to >> cover in future posts: >> - what has to be done to get the initial clone and hook it into an >> image? >> - sharing git repos between separate "active images" >> - cloning a github:// repos? >> - ssh vs https clones >> - working with remotes >> >> Dale >> >> [1] https://github.com/dalehenrich/tode >> [2] https://github.com/GsDevKit/GsDevKit_home >> [3] https://github.com/dalehenrich/metacello-work >> [4] https://github.com/dalehenrich/filetree >> > >

Jan. 28, 2016

Re: [Pharo-dev] Experiences with git, tODE and GsDevKit_home: Part 1 - basic structure considerations

by Ben Coman

On Thu, Jan 28, 2016 at 5:03 AM, Dale Henrichs < dale.henrichs(a)gemtalksystems.com> wrote: > The git repository is not tightly coupled to the image like the changes > file (you can delete a git repository without impacting the functionality > of an image), but if you are making changes in the image, then you _are_ > coupled to a particular git commit identified by its SHA. > > Metacello will record the SHA of the git repository at the time that > packages are loaded from a git repository (to enable this feature in Pharo, > some methods need to be implemented in the MetacelloPlatform for Pharo) and > this information is stored along with the Metacello registration for the > project. > > Since the git repository can be independently manipulated from the shell > or an image can be saved that references a SHA that is no longer "current" > .... it is very important that the SHA be recorded and made visible to > users via the tools. > By "current", do you mean the currently checked out directory as seen from the shell command line? Slightly off topic... I wonder if we could avoid needing a currently checked out directory as seen from the command line and have the Image work directly with the git repository (within the .git folder - is this what libgit integration may give us?) thus making the Image the equivalent of the current checked out directory? Then lets dump the .changes file by... rather than a method's source reference being a (fragile) hardcoded index into the .changes file, make each method an SHA key into the git (or mercurial) repository. * Git is fundamentally a content-addressable filesystem with a VCS user interface written on top of it. Youâll learn more about what this means in a bit. [2] * Git is a simple key-value data store. You can insert any kind of content into it, and it will give you back a key that you can use to retrieve the content again at any time. [3] * [In Mercurial...] each revision of a file is identified by a 'NodeID', which is a SHA hash of its contents (combined with the position of that node in the history). [4] In short, should our source code indexing be "content-addressable" with the possibility to use *any* key-value repository. Each method SHA would be calculated from its own source code and parent class SHA. Each class would calculate its SHA from its definition and superclass' SHA. A package/project SHA would be calculated from all its component class and method SHAs. [1] https://git-scm.com/book/en/v1/Git-Internals-Plumbing-and-Porcelain [2] https://git-scm.com/book/en/v1/Git-Internals [3] https://git-scm.com/book/en/v1/Git-Internals-Git-Objects [4] http://ericsink.com/vcbe/html/repository_structure.html cheer -ben > Soooo --- managing skew is an important function for the "project > browser"... Here's what the tODE "Project Browser" looks like when version > skew is detected: > In this I assume the red ones are skewed and the X ^ Y represent commits, but could you explain which ones. > > [image: project list with version skew] > > > > Well I think that's enough for now...Here are some topics that I plan to > cover in future posts: > - what has to be done to get the initial clone and hook it into an image? > - sharing git repos between separate "active images" > - cloning a github:// repos? > - ssh vs https clones > - working with remotes > > Dale > > [1] https://github.com/dalehenrich/tode > [2] https://github.com/GsDevKit/GsDevKit_home > [3] https://github.com/dalehenrich/metacello-work > [4] https://github.com/dalehenrich/filetree >

Jan. 28, 2016

Re: [Pharo-dev] GTDebugger missing block parameters?

by Eliot Miranda

Hi Nicolai > On Jan 15, 2016, at 4:57 AM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > 2016-01-15 13:26 GMT+01:00 Stephan Eggermont <stephan(a)stack.nl>: >> When debugging a method containing a block with a parameter, >> the parameter is missing from the variable list (because it is aliased?). > > Yes, this happens with block vars from optimized blocks (ifNotNil:). > The tempvars arent't local to the block, but method vars. > And the debugger (debuggerMap) doesn't knows about this (this happens on both debuggers AFAIK). It works in the Squeak debugger. Try e.g. debugging Character space printOn: Transcript > >> >> Stephan >

Jan. 28, 2016