March 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] packages :)

by Lukas Renggli

On 17 March 2010 09:39, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >>> Having two dictionaries for methods makes it extremely >>> difficult to move stuff around because always 4 separate cases need to >>> be handled. >> >> I also do not like this part either. > > Lukas this is exactly as in RBEnvironment as you suggested when you visited me. > If you do not want to hold on class object but name as dictionary key > you do not want to have a key that is 'Point class' because you end up been forced > to do a lot of string matching shit. Now this is really simple and fast. > >> The model does not store compiled methods, or classes. It only stores symbols. > > I prefer that ;) Sorry, I mis-inspected the object model. Forget all I said in that paragraph, it is invalid. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

March 17, 2010

Re: [Pharo-project] BTree packaging

by StÃ©phane Ducasse

Thanks for the reminded. I was confused at a certain point thinking that - was not a special character.... I hate this system. Stef On Mar 17, 2010, at 8:02 AM, Lukas Renggli wrote: >> So maybe if Squeak renamed "Collections" similarly to what Pharo did, > > I don't mind if you commit the package under a new name. I wasn't > aware that Squeak has a different package structure for collections. > >> MC allows a dash in a package name and treats it as one unique name? > > The important thing is that the name of a package is not a prefix of > another package (like the package 'Collection' is a prefix of > 'Collection-BTree'). The actual code that tests for this is: > > PackageInfo>>category: categoryName matches: prefix > ^ categoryName notNil and: [categoryName = prefix or: > [categoryName beginsWith: prefix, '-']] > > In Pharo people seem to avoid the use of dashes in package names. > > In Seaside we extensively use dashes as a tag to differentiate > tests/examples and platform dependent code while keeping the package > name the "same": http://code.google.com/p/seaside/wiki/PackageNaming > > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 17, 2010

Re: [Pharo-project] A challenge for us

by StÃ©phane Ducasse

It would be good to start checking for example the date and time tests. For example the readFrom: methods are ugly and it would be nice to access the tests and complement it if necessary. Adding nice categories and not as yet unclassified or Testing would be good. Stef On Mar 17, 2010, at 2:23 AM, Carla F. Griggio wrote: > Same here. > Sounds nice to start cooperating. How can I help? > > On Tue, Mar 16, 2010 at 10:28 PM, <csrabak(a)bol.com.br> wrote: > If I understand correctly, i.e., committing to one task per month I'm more than willing to help. > > What would be the protocol to cooperate on this? > > -- > Cesar Rabak > > > Em 16/03/2010 04:21, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr > escreveu: > Hi > > I would like to initiative a task (monthly) for us. I would like to get really good tests coverage > for some of the core classes. For example Date, Time, Duration, DateAndTime. > This is really important in the long term to get sure that we identify bugs as soon as they appear. > > It would be really good if we could get team up and fix that together. Does anybody want to help? > > I started to fix some bugs there and write more tests in the process of fixing tests. > > Stef > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 17, 2010

Re: [Pharo-project] packages :)

by StÃ©phane Ducasse

On Mar 17, 2010, at 9:23 AM, Lukas Renggli wrote: >> It tries to work with methods and classes through symbolic names.. and >> you immediately end up with >> gemmorage of a need to keep separate 'core' and 'extension' , 'meta' >> and 'instance-side' methods in your model. > > Yes, that's what I suggested, merge the extension and core dictionaries. I do not see how? without first class class and no string match: '* class' ? I'm curious >> I don't know what is the purpose of making a package to be a dead >> piece of flesh, which reflects own organization by using symbols, >> instead of real objects? Who are you trying to deceive with that? > > Incremental development. Separation of concerns. > > If the package would contain the real classes and real methods one had > to change (literally) thousands of places in the system. Igor what happen when your class change shape. I do not know if it is becomed but if it is not we are in trouble. >> > RPackage is about a PackageInfo replacement, not about a namespace > implementation. Arguably namespacing is something entirely different. Yes >> But if you don't that , you model will remain a piece of flesh, >> without skeleton - it can't move , it can only lie on the ground and >> rot :) > > I suggested Stef to look at the environments in the refactoring > engine. They are a proven implementation for more than 10 years, they > work very efficiently with numerous GUIs (OB, VisualWorks, VisualAge), > and have been applied in many different scenarios (introspection, > reflection, refactorings, changes, lint, virtual code, ...). This is what I did. Now in RB they do not deal with extensions. >> I don't understand, why to not work with actual objects, instead of >> names? Please enlighten me, why you want to refer to objects >> indirectly and leaving to somethings else in the system to decide how >> these names turned into a real objects. >> What is the benefit of having such indirect model? > > What would a method object refer to other than its class and its > selector? Is the introduction of another layer of objects that > duplicates Class, PseudoClass, MCClassDefinition, RBClass and > CompiledMethod, MethodReference, MCMethodDefinition, RBMethod > reasonable? > > Remember, this is just the internal implementation. I agree that to > the outside a package should be represented using dedicated objects. > > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 17, 2010

Re: [Pharo-project] packages :)

by StÃ©phane Ducasse

On Mar 17, 2010, at 8:32 AM, Igor Stasenko wrote: > Hi Stef, > > i took a look on your implementation and i don't like it. :) Ok fair My first implementation was holding classes and objects and people did not like it either. > It tries to work with methods and classes through symbolic names.. The first implementation was only holding classes and compiled methods/methodreferences and the problems is that you cannot reason about off-line system. Lukas told me ok this is not good because of that. Look at RBEnvironment. So I rewrote everything 3 times. So I'm started to get bored. > I don't know what is the purpose of making a package to be a dead > piece of flesh, which reflects own organization by using symbols, > instead of real objects? Who are you trying to deceive with that? Off image package manipulation. > If you remember, i put some thoughts about packages here before. And even implemented a prototype package model myself (did you looked at > it?). Now where is the code? What is the cost to find all the extendingClasses, if a method is included in a packages, classes extensions, how do we hook event for classremoval, classaddition, without raising multiple times the same. > My concepts is simple and object-oriented (instead of > symbolic-names oriented ;) ) : > If we take a most abstract and stripped down concept then, in order to > define a package, we need just two things: > - a set of objects , which belong to that package > - and a namespace (name->object), where name is a symbol and object is > one of the objects, which > belong to package. > > note, that there is no any 'methods' or 'classes' . It is just objects > and names. And then you can start adding flesh on that skeleton by > implementing things , like covenient adding/defining/lookup classes, > methods , etc etc. > But if you don't that , you model will remain a piece of flesh, > without skeleton - it can't move , it can only lie on the ground and > rot :) > > I don't understand, why to not work with actual objects, instead of > names? Please enlighten me, why you want to refer to objects > indirectly and leaving to somethings else in the system to decide how > these names turned into a real objects. > What is the benefit of having such indirect model? We could create package and manipulate them even if they are not in the image. > In such form, a package becomes only a view of something which already > exists in a system without it. It doesn't defining a domain space - > just reflecting existing one (a years-old existing system organization > (classes and methods)). Exactly. But if you want to introduce Package then a method should know its package (which I did in my first implementation). > And thus, you will have a hard times when you would want to migrate to > a new system organization, because all levers of control lying > elsewhere, instead in a package itself. Did not get this one. > > > On 16 March 2010 18:21, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> Hi >> >> I started to reimplement the package class is did because the previous one was a bit messy. >> I'm currently migrating old the tests to the new implementation and for now I have around 93% coverage. >> I started to build a stupid browser to check my api. >> Doru started to code a Glamour browser to see if this was ok. >> >> Now I would really like if >> - somebody could have a look at the code >> - develop a simple package browser showing class extensions (it would help me to define >> a good api to walk though a package). I started to use Momo and this is why I reimplemented the class >> but so far I get nearly the same interface and I think that I can do better. >> >> Of course there are comments and tests so if one of you want to join we could do remote pair coding to be able >> to release a first version. So far >> - integration with MC >> - migrating from packageInfo >> - event notification >> are missing. >> >> Stef >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 17, 2010

Re: [Pharo-project] packages :)

by StÃ©phane Ducasse

>> Having two dictionaries for methods makes it extremely >> difficult to move stuff around because always 4 separate cases need to >> be handled. > > I also do not like this part either. Lukas this is exactly as in RBEnvironment as you suggested when you visited me. If you do not want to hold on class object but name as dictionary key you do not want to have a key that is 'Point class' because you end up been forced to do a lot of string matching shit. Now this is really simple and fast. > The model does not store compiled methods, or classes. It only stores symbols. I prefer that ;) > >> - The browser displays nicely the extended classes, but for the >> methods I don't see the protocols and the complete set of selectors >> implemented. I think these things should be part of the browser, >> otherwise we don't see if the package model can answer these queries >> quick enough. > > I agree, but this was just a quick thing to see what kind of navigation methods are needed to get the classes and methods. Categories are still to be added. > >> - The browser displays extension methods on both instance and >> class-side. When browsing an extended class, the extensions are not >> displayed. > > Yes, these were bugs :). I tried to fix these, but I think I bumped into other problems, so I will stop for now. Like what? > > Cheers, > Doru > >> That's it for the moment. I see a cool model emerging :-) >> >> Lukas >> >> -- >> Lukas Renggli >> http://www.lukas-renggli.ch >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > www.tudorgirba.com > > "Sometimes the best solution is not the best solution." > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 17, 2010

Re: [Pharo-project] packages :)

by StÃ©phane Ducasse

On Mar 16, 2010, at 9:50 PM, Lukas Renggli wrote: > I have some comments, to both the package implementation and the > Glamour browser. The other browser didn't work, I guess I miss some > extra package. > > - I used the code below to import the existing packages into the new > model. Maybe something like this should be included on the class side > of RPackageOrganizer to have a realistic model? > > | package | > PackageOrganizer default packages > do: [ :info | > package := RPackage2 named: info packageName. > info classes do: [ :each | package addClassDefinition: each ]. > info coreMethods do: [ :each | > each isValid > ifTrue: [ package addMethod: each compiledMethod isExtension: false ] ]. > info extensionMethods do: [ :each | > each isValid > ifTrue: [ package addMethod: each compiledMethod isExtension: true ] ] ] > displayingProgress: 'Importing' > > Then I opened the glamour browser using: > > GTCoder openOn: RPackageOrganizer default > > - I find it quite strange that I have to declare if a method is an > extension or not. Isn't a that obvious when looking at the defined > classes? Historically it was like you said in implementation 1 and 2, then I removed the defined classes (implementation 3), then I realized oops shit, we can have package with class but no methods (and in this case we should always when removing a method check if this is the last one and if there is none in the metaclass to trigger a classremoved event), so I reintroduced defined classes as a separate data (implementation 4 = now). Now I think that we should remove isExtension to go back to the first implementation. I guess that this is a todo > Having two dictionaries for methods makes it extremely > difficult to move stuff around because always 4 separate cases need to > be handled. I discussed that point with doru when you went off your office. > > - The fact that compiled methods are stored in the model is very > dangerous. There should not be or doru changes my code!!! > You might hold onto compiled methods that have long been > replaced with other ones. Just by playing a bit with the model I run > into that situation (I don't know how). I think just keeping the > selector internally would be much safer and solve all kinds of > troubles (exactly like this is done for the classes). but this is like that. Doru? > You'll have to > check anyway if the method is still present when you iterate over the > methods. A single use of #doSilently: (and there are lots of them in > the image) can completely screw up the complete package model. > > - The browser displays nicely the extended classes, but for the > methods I don't see the protocols and the complete set of selectors > implemented. I think these things should be part of the browser, > otherwise we don't see if the package model can answer these queries > quick enough. > > - The browser displays extension methods on both instance and > class-side. When browsing an extended class, the extensions are not > displayed. > > That's it for the moment. I see a cool model emerging :-) > > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 17, 2010

Re: [Pharo-project] classNameCache/classNames problem

by StÃ©phane Ducasse

Thanks pavel the Smalltalk -> SmalltalkImage current is not finished so any fix is welcomed. I have some admin work today and will try to find soem times to fix that. > I tried to run tests in Pharo 1.1 #11275 and then I got an error when > trying to open Message Names. The reason is that if you evaluate > > Smalltalk classNames includes: #C1 > > you got true so Smalltalk classNames includes it however it is not > present in Smalltalk globals. After Smalltalk flushClassNameCache the > problem disapeared. > > If I tried to create a class named SomeClass, the result was: > > Smalltalk classNames includes: #SomeClass -> false > Smalltalk globals at: #SomeClass -> SomeClass > > I had to remove Object>>#initialExtent because of neverending > deperecation warning (a methods tries respondsTo: #initialExtent on a > model. Oh yesssss. ARGH. My mistake. Indeed some models should not implement intialExtent and it falls back on Object.... stupid me. but this is strange because I run all the tests and besides > I don't know which one because Recent Submissions doesn't work > because of method reference > AutoGeneratedClassForTestingSystemChanges>>#Comment anwered nil on > actualClass message) > > -- Pavel > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 17, 2010

Re: [Pharo-project] packages :)

by Lukas Renggli

> It tries to work with methods and classes through symbolic names.. and > you immediately end up with > gemmorage of a need to keep separate 'core' and 'extension' , 'meta' > and 'instance-side' methods in your model. Yes, that's what I suggested, merge the extension and core dictionaries. > I don't know what is the purpose of making a package to be a dead > piece of flesh, which reflects own organization by using symbols, > instead of real objects? Who are you trying to deceive with that? Incremental development. Separation of concerns. If the package would contain the real classes and real methods one had to change (literally) thousands of places in the system. > If you remember, i put some thoughts about packages here before. And > even implemented a prototype package model myself (did you looked at > it?). My concepts is simple and object-oriented (instead of > symbolic-names oriented ;) ) : Where? > If we take a most abstract and stripped down concept then, in order to > define a package, we need just two things: > - a set of objects , which belong to that package > - and a namespace (name->object), where name is a symbol and object is > one of the objects, which > belong to package. RPackage is about a PackageInfo replacement, not about a namespace implementation. Arguably namespacing is something entirely different. > But if you don't that , you model will remain a piece of flesh, > without skeleton - it can't move , it can only lie on the ground and > rot :) I suggested Stef to look at the environments in the refactoring engine. They are a proven implementation for more than 10 years, they work very efficiently with numerous GUIs (OB, VisualWorks, VisualAge), and have been applied in many different scenarios (introspection, reflection, refactorings, changes, lint, virtual code, ...). > I don't understand, why to not work with actual objects, instead of > names? Please enlighten me, why you want to refer to objects > indirectly and leaving to somethings else in the system to decide how > these names turned into a real objects. > What is the benefit of having such indirect model? What would a method object refer to other than its class and its selector? Is the introduction of another layer of objects that duplicates Class, PseudoClass, MCClassDefinition, RBClass and CompiledMethod, MethodReference, MCMethodDefinition, RBMethod reasonable? Remember, this is just the internal implementation. I agree that to the outside a package should be represented using dedicated objects. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

March 17, 2010

Re: [Pharo-project] packages :)

by Igor Stasenko

Hi Stef, i took a look on your implementation and i don't like it. :) It tries to work with methods and classes through symbolic names.. and you immediately end up with gemmorage of a need to keep separate 'core' and 'extension' , 'meta' and 'instance-side' methods in your model. By looking at: addSelector: aSelector ofClass: aClass "Add the method to the receiver. If the class is not locally defined in that package then the method is defined as a method extension: ie extending another package. The method is not added to the class." aClass isMeta ifTrue: [(metaclassSelectors at: aClass soleInstance name asSymbol ifAbsentPut: [Set new]) add: aSelector.] ifFalse: [(classSelectors at: aClass name asSymbol ifAbsentPut: [Set new]) add: aSelector.]. This approach, from very starting, unnecessary complexifies the model, and requires a lot of glue code. I don't know what is the purpose of making a package to be a dead piece of flesh, which reflects own organization by using symbols, instead of real objects? Who are you trying to deceive with that? If you remember, i put some thoughts about packages here before. And even implemented a prototype package model myself (did you looked at it?). My concepts is simple and object-oriented (instead of symbolic-names oriented ;) ) : If we take a most abstract and stripped down concept then, in order to define a package, we need just two things: - a set of objects , which belong to that package - and a namespace (name->object), where name is a symbol and object is one of the objects, which belong to package. note, that there is no any 'methods' or 'classes' . It is just objects and names. And then you can start adding flesh on that skeleton by implementing things , like covenient adding/defining/lookup classes, methods , etc etc. But if you don't that , you model will remain a piece of flesh, without skeleton - it can't move , it can only lie on the ground and rot :) I don't understand, why to not work with actual objects, instead of names? Please enlighten me, why you want to refer to objects indirectly and leaving to somethings else in the system to decide how these names turned into a real objects. What is the benefit of having such indirect model? In such form, a package becomes only a view of something which already exists in a system without it. It doesn't defining a domain space - just reflecting existing one (a years-old existing system organization (classes and methods)). And thus, you will have a hard times when you would want to migrate to a new system organization, because all levers of control lying elsewhere, instead in a package itself. On 16 March 2010 18:21, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi > > I started to reimplement the package class is did because the previous one was a bit messy. > I'm currently migrating old the tests to the new implementation and for now I have around 93% coverage. > I started to build a stupid browser to check my api. > Doru started to code a Glamour browser to see if this was ok. > > Now I would really like if > Â Â Â Â - somebody could have a look at the code > Â Â Â Â - develop a simple package browser showing class extensions (it would help me to define > Â Â Â Â a good api to walk though a package). I started to use Momo and this is why I reimplemented the class > Â Â Â Â but so far I get nearly the same interface and I think that I can do better. > > Of course there are comments and tests so if one of you want to join we could do remote pair coding to be able > to release a first version. So far > Â Â Â Â - integration with MC > Â Â Â Â - migrating from packageInfo > Â Â Â Â - event notification > Â Â Â Â are missing. > > Stef > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

March 17, 2010