February 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Future "Modules system"

by Craig Latta

Hi-- Yes, Spoon[1] supports multiple active versions of the same class. Background: Spoon has no system dictionary, nor does it use "chunk-format" files such as sources or changes files, or "fileouts". It doesn't use files at all, apart from object memory snapshots and virtual machine executables, which are embedded into the Spoon "app" as far as the host platform is concerned. Instead of using source code in files, Spoon uses a distributed live-objects history system called Naiad (short for "Name And Identity Are Distinct"). Each normal object memory is paired with a special separate memory, connected by remote messaging, for recording history information. This special memory is called a "history memory", and the memory it describes is called a "subject memory". The history memory stores "edition" objects which describe various development events, including class and method installation. These editions are managed by an "edit history" object, which is exposed to its subject memory as a seamless proxy. Class installation happens whenever you define a new class, or change the definition of a class. The edition that describes a class installation includes all the information needed to replay that event, to undo it, and to provide context for people studying it later (for example, the author and the time of installation). Among that information is the name given to the class at the time. Each edition has a reference to the previous and next editions. The edit history stores the most recent edition for the class in a dictionary; the key is a UUID[2]. That UUID is also stored in a slot of the active class object being described, in the subject memory. When the compiler needs to find the class object for a name mentioned in source code, it asks the edit history for the IDs of all the active classes with that name, and finds all the active classes for those IDs, by traversing the class hierarchy. If there is more than one class for the same name, the user interface can help the developer make a choice, by showing some of the additional contextual information from the edit history. (The history memory is effectively an application-specific distributed object database. Multiple subject memories can use the same history memory, and history memories can federate. From each subject memory object's point of view, the edit history is just a normal local object.) With this organization, the name of each class can be anything. It doesn't matter that you already have a class called Array, you could install as many more as you like. They would each have a different ID, and you could tell them apart from their historical information. Since the name of every class is unconstrained, every class effectively has its own namespace, without having to reify the concept of "namespace" in the developer's mental model of the system, or in the implementation of the system. And now for your use cases... :) Since class names are unconstrained, supporting multiple classes with the same name, but with unrelated development histories, is trivial. For example, you and I both happened to choose the same name for classes which we have developed independently, have different message interfaces, and different slot layouts. Our classes coexist, the compiler can compile new methods for them (with occasional disambiguation from a person informed by historical information), and instantiation works as always. At the other extreme, you might want to install a previous version of an active class that evolved over many versions, without modifying the active class object. The system would create a class using information from the older class edition, but give the resulting class object a new ID, and record this with an appropriate class edition using that new ID. Personally, I would make some attempt to avoid both of these situations, through discussion with my fellow authors, but I recognize that this isn't always feasible. For more details about Naiad, please see my blog[3]. thanks again, -C [1] http://netjam.org/spoon [2] http://en.wikipedia.org/wiki/Universally_unique_identifier [3] http://tinyurl.com/8f5zq85 (thiscontext.wordpress.com) -- Craig Latta www.netjam.org/resume +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS)

Feb. 4, 2013

Re: [Pharo-project] [ANN] NativeBoost project moved to new hosting: smalltalkhub

by StÃ©phane Ducasse

Igor I think that camillo made this because NativeBoost is an essential part of our infrastructure and this is good to know that it is working. So I think that we should thank camillo for the time he spent on that. Stef On Feb 4, 2013, at 4:50 PM, Igor Stasenko wrote: > On 31 January 2013 22:31, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> Igor can you also update the ci? >> >> https://ci.inria.fr/rmod/job/NativeBoost/configure >> > it looks already up to date. > > why do we need this job btw? who uses it? > > (i'd like to mention that you should not expect from me that i will > feel responsible for updating/syncing something > which i was not created nor aware of) > > > > -- > Best regards, > Igor Stasenko. >

Feb. 4, 2013

Re: [Pharo-project] Monkey noise in IssueTracker

by Ben Coman

Igor Stasenko wrote: > On 4 February 2013 17:41, Ben Coman <btc(a)openinworld.com> wrote: > > >> Also btw,https://git.gitorious.org/cogvm/blessed.git >> gives a 404 Not Found error. >> >> >> > that's really strange. > > >> cheers -ben >> >> > > > > Doh! I was just clicking through without considering that address is really the one for git to use. For a browser link, dropping the .git extension works. Perhaps it is just a co-incidence that it becomes a link in the issue tracker, that however is likely to mislead others.

Feb. 4, 2013

Re: [Pharo-project] Monkey noise in IssueTracker

by Igor Stasenko

On 4 February 2013 17:56, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 4 February 2013 17:41, Ben Coman <btc(a)openinworld.com> wrote: > >> Also btw,https://git.gitorious.org/cogvm/blessed.git >> gives a 404 Not Found error. >> >> > that's really strange. the git:// protocol works fine.. since i am able to pull from it. -- Best regards, Igor Stasenko.

Feb. 4, 2013

Re: [Pharo-project] Monkey noise in IssueTracker

by Igor Stasenko

On 4 February 2013 17:41, Ben Coman <btc(a)openinworld.com> wrote: > Also btw,https://git.gitorious.org/cogvm/blessed.git > gives a 404 Not Found error. > > that's really strange. > cheers -ben > -- Best regards, Igor Stasenko.

Feb. 4, 2013

Re: [Pharo-project] Future "Modules system"

by Martin Dias

On Mon, Feb 4, 2013 at 5:25 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Hi > > 2013/2/4 Martin Dias <tinchodias(a)gmail.com> >> >> I arrived to almost the same problem some weeks ago, when I was >> thinking on how to have multiple versions of Fuel at the same time, so >> one can, for example, easily migrate her files to a newer version. >> >> Fuel has lots of extension methods, so we need also multiple versions >> of the same extension method. >> >> Then, I arrived to ClassBoxes paper, from which I would like to >> extract and reproduce the experiment in a Pharo2.0 with Opal compiler. >> I guess Opal can simplify the implementation. >> There is also a paper about a prototype named CoExist, based on >> squeak. I didn't try it but apparently they only have a little >> performance degradation, because they used a modified vm. > > > I think It can be implemented with method wrappers and without impact on > performance of methods which has not everrided versions. > When you load code from package with method extensions you can put this > methods in target class with method wrappers which know about classboxies > logic. But rest system will continue working as usuall. > > Do you have links on CoExist? yes: http://www.bastiansteinert.org/coexist.html anyway it's a bit off-topic because their prototype is not about modules... best regards, Martin > > Best regards, > Denis > >> >> >> Martin >> >> >> >> On Sun, Feb 3, 2013 at 12:36 PM, Camillo Bruni <camillobruni(a)gmail.com> >> wrote: >> > Have a look at ClassBoxes: >> > >> > http://scg.unibe.ch/archive/papers/Berg03aClassboxes.pdf >> > >> > I think they come pretty close to what you have in mind. >> > >> > On 2013-02-03, at 12:30, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: >> > >> >> Hello. >> >> >> >> Some days ago I think about how java works with dependencies and how it >> >> can >> >> be implemented in smalltalk. >> >> >> >> For java example libA.jar uses SharedClass.methodA and libB.jar uses >> >> SharedClass.methodB. But #methodA exists only in version deployed as >> >> libS-a.jar. And #methodB exists only in version deployed as libS-b.jar. >> >> Dependency from libA.jar on libS-a.jar and libB.jar on libS-b.jar are >> >> defined explicitly in their classpathes. So libA.jar knows nothing >> >> about >> >> libS-b.jar and v.v. And that's why your java programm can works at same >> >> time with libA.jar and libB.jar. They will use different versions of >> >> same >> >> class. >> >> >> >> What it means in context of pharo? >> >> >> >> In pharo we have configurations which manage dependencies of projects. >> >> But >> >> you can't use at same time projectA and projectB which depend on >> >> different >> >> versions of projectS (when they both use same SharedClass from projectS >> >> like in java example). If you load projectA last you will get >> >> SharedClass >> >> with only methodA. If you load projectB last you will get SharedClass >> >> with >> >> only methodB. So projectA and projectB can't works correctly at same >> >> time. >> >> My example very simple. It includes just single class differencies. It >> >> can >> >> be more complicated and java world is good example for this. >> >> >> >> So my global question is how it can be solved in pharo? Do you have >> >> some >> >> plan for this? >> >> >> >> I can't remember something similar in pharo vision docs. But maybe what >> >> Stephane called "modules system" is exactly about this? I mean what >> >> Stephane always opposes in namespaces/environment discussions. And I >> >> think >> >> that this problem is ortogonal to namespaces/environments support. Do >> >> you >> >> agree? Do you know about such reseach in smalltalk? >> >> >> >> Little conclusion about such module system (if we can named it such >> >> way?) >> >> and what it is required from pharo: >> >> >> >> - ability to get in image different versions of same package. >> >> - separated class (global) dictionaries (multiple Smalltalk's) per >> >> package >> >> version. Maybe it can be named Module. So let's think about Module as >> >> unique Package+Version pair which contains all globals specific to this >> >> version and all dependent other Modules. >> >> - each Module knows it dependencies from other Modules, This >> >> information >> >> can be retreived from configuration. >> >> - each method and class should know from which project version (module) >> >> it >> >> was loaded. >> >> - inside any methods compiler should resolve class names based on >> >> Module >> >> dependencies information. Compiler should lookup actual class objects >> >> from >> >> module dependencies hierarchy. So no global Smalltak for compiler. But >> >> Smalltalk can be stay in system as default core Module. >> >> - If you want to use class which presents in two loaded versions of >> >> same >> >> package you should resolve conflict manually. Such action should add >> >> dependency to Module of your code. >> >> - Module can't have dependencies of two Modules of same package. It >> >> means >> >> that code of your project can use only version of some dependant class. >> >> I >> >> think it is essential restriction of Modules system. >> >> >> >> Main thing which Module system can get to us is ability to safelly load >> >> any >> >> versions of our projects and use it. It is not matter how old this >> >> code. >> >> System just loads old version of pharo core for example. Existed pharo >> >> core >> >> will continue works correctly. >> >> >> >> So what you think about it? >> >> >> >> Best regards, >> >> Denis >> > >> > >> >

Feb. 4, 2013

[Pharo-project] Monkey noise in IssueTracker

by Ben Coman

Since I am not involved in integrating issues and I'm not sure how all the info added to the Issue Tracker y the Monkey is used, this is just a general observation. While it is nice to see the Monkey recording of its work in the Issue Tracker (it gives a professional feel), I am wondering whether "on success" it could be a bit more concise. Perhaps it could list only failed test packages, or not put a newline after each package. For example, http://code.google.com/p/pharo/issues/detail?id=6603 has had three successful runs in the last 26 hours. Also btw,https://git.gitorious.org/cogvm/blessed.git gives a 404 Not Found error. cheers -ben

Feb. 4, 2013

[Pharo-project] [update 2.0] #20512

by Marcus Denker

20512 ----- Issue 7361: endless Cancel in discard What do you want to do? http://code.google.com/p/pharo/issues/detail?id=7361 Issue 7416: #compilerClass on behaviors should return Smalltalk>>#compilerClass http://code.google.com/p/pharo/issues/detail?id=7416 Diff information: http://ss3.gemstone.com/ss/Pharo20/Polymorph-Widgets-MarcusDenker.767.diff http://ss3.gemstone.com/ss/Pharo20/Nautilus-MarcusDenker.408.diff http://ss3.gemstone.com/ss/Pharo20/Compiler-MarcusDenker.373.diff

Feb. 4, 2013

[Pharo-project] Strange behaviour in Spec

by Andrei Vasile Chis

Hi, While playing with spec I started to have some quite random and strange behaviour. I'll try to explain what happen, because it might be a nasty/not that nasty bug. I had a ListComposableModel and some very simple code like: aListComposableModel whenListChanged: [ :aList | aListComposableModel setSelectedItem: aList first ]. >From time to time this code seem to randomly fail because the selection wasn't set. I manage to reduce the error to the following equivalent code: aListComposableModel whenListChanged: [ :aList | aList = aListComposableModel listItems ]. What happen was that sometimes the list held by the model was the previous list and not the new list, which was actually correctly passes to the block. This seem to be caused by the way ListComposableModel uses announcers to update its internal state. In ListComposableModel>>registerEvents there is the code: listHolder whenChangedDo: [ self refreshListItems ]. This registers an announcement that should clear the cache: ListComposableModel >>refreshListItems listItemsCache := nil. ^ self changed: #listElementAt: In my code by using 'aListComposableModel whenListChanged:' I also register an event that should be executed when the elements of the list change. So by now the listHolder containing the elements of the list has two registered events. The problem is that in order for this to work correctly they have to execute in the order they were added: first invalidate the cache, then the other events registered by the user. However I do not think that announcers guarantee this. So from time to time they execute in the wrong way. This means that the code in the whenListChanged: block will execute in a state in which internaly aListComposableModel still contains the previous list. Does this make sense? Andrei

Feb. 4, 2013

Re: [Pharo-project] Future "Modules system"

by Denis Kudriashov

Hi 2013/2/4 Martin Dias <tinchodias(a)gmail.com> > I arrived to almost the same problem some weeks ago, when I was > thinking on how to have multiple versions of Fuel at the same time, so > one can, for example, easily migrate her files to a newer version. > > Fuel has lots of extension methods, so we need also multiple versions > of the same extension method. > > Then, I arrived to ClassBoxes paper, from which I would like to > extract and reproduce the experiment in a Pharo2.0 with Opal compiler. > I guess Opal can simplify the implementation. > There is also a paper about a prototype named CoExist, based on > squeak. I didn't try it but apparently they only have a little > performance degradation, because they used a modified vm. > I think It can be implemented with method wrappers and without impact on performance of methods which has not everrided versions. When you load code from package with method extensions you can put this methods in target class with method wrappers which know about classboxies logic. But rest system will continue working as usuall. Do you have links on CoExist? Best regards, Denis > > Martin > > > > On Sun, Feb 3, 2013 at 12:36 PM, Camillo Bruni <camillobruni(a)gmail.com> > wrote: > > Have a look at ClassBoxes: > > > > http://scg.unibe.ch/archive/papers/Berg03aClassboxes.pdf > > > > I think they come pretty close to what you have in mind. > > > > On 2013-02-03, at 12:30, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > >> Hello. > >> > >> Some days ago I think about how java works with dependencies and how it > can > >> be implemented in smalltalk. > >> > >> For java example libA.jar uses SharedClass.methodA and libB.jar uses > >> SharedClass.methodB. But #methodA exists only in version deployed as > >> libS-a.jar. And #methodB exists only in version deployed as libS-b.jar. > >> Dependency from libA.jar on libS-a.jar and libB.jar on libS-b.jar are > >> defined explicitly in their classpathes. So libA.jar knows nothing about > >> libS-b.jar and v.v. And that's why your java programm can works at same > >> time with libA.jar and libB.jar. They will use different versions of > same > >> class. > >> > >> What it means in context of pharo? > >> > >> In pharo we have configurations which manage dependencies of projects. > But > >> you can't use at same time projectA and projectB which depend on > different > >> versions of projectS (when they both use same SharedClass from projectS > >> like in java example). If you load projectA last you will get > SharedClass > >> with only methodA. If you load projectB last you will get SharedClass > with > >> only methodB. So projectA and projectB can't works correctly at same > time. > >> My example very simple. It includes just single class differencies. It > can > >> be more complicated and java world is good example for this. > >> > >> So my global question is how it can be solved in pharo? Do you have some > >> plan for this? > >> > >> I can't remember something similar in pharo vision docs. But maybe what > >> Stephane called "modules system" is exactly about this? I mean what > >> Stephane always opposes in namespaces/environment discussions. And I > think > >> that this problem is ortogonal to namespaces/environments support. Do > you > >> agree? Do you know about such reseach in smalltalk? > >> > >> Little conclusion about such module system (if we can named it such > way?) > >> and what it is required from pharo: > >> > >> - ability to get in image different versions of same package. > >> - separated class (global) dictionaries (multiple Smalltalk's) per > package > >> version. Maybe it can be named Module. So let's think about Module as > >> unique Package+Version pair which contains all globals specific to this > >> version and all dependent other Modules. > >> - each Module knows it dependencies from other Modules, This information > >> can be retreived from configuration. > >> - each method and class should know from which project version (module) > it > >> was loaded. > >> - inside any methods compiler should resolve class names based on Module > >> dependencies information. Compiler should lookup actual class objects > from > >> module dependencies hierarchy. So no global Smalltak for compiler. But > >> Smalltalk can be stay in system as default core Module. > >> - If you want to use class which presents in two loaded versions of same > >> package you should resolve conflict manually. Such action should add > >> dependency to Module of your code. > >> - Module can't have dependencies of two Modules of same package. It > means > >> that code of your project can use only version of some dependant class. > I > >> think it is essential restriction of Modules system. > >> > >> Main thing which Module system can get to us is ability to safelly load > any > >> versions of our projects and use it. It is not matter how old this code. > >> System just loads old version of pharo core for example. Existed pharo > core > >> will continue works correctly. > >> > >> So what you think about it? > >> > >> Best regards, > >> Denis > > > > > >

Feb. 4, 2013