- Pharo-dev - lists.pharo.org

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

Re: [Pharo-project] BTree packaging

by Lukas Renggli

> 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

March 17, 2010

Re: [Pharo-project] packages :)

by Igor Stasenko

On 17 March 2010 08:35, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 16 March 2010 19:00, Tudor Girba <tudor.girba(a)gmail.com> wrote: >> Hi, >> >> To get it: >> Gofer new >> Â Â Â Â squeaksource: 'PharoTaskForces'; >> Â Â Â Â package: 'RPackageAll'; >> Â Â Â Â load. >> > I tried to do that in core image, > and found that it having unresolved dependencies on: > MorhTreeModel > and > MorphTreeNodeModel > > what package i need for them? > Oh, sorry, it was wrong image (1.0). >> To get a super-simple browser that shows extensions in italics: >> >> Gofer new >> Â Â Â Â squeaksource: 'glamoroust'; >> Â Â Â Â package: 'ConfigurationOfGlamoroust'; >> Â Â Â Â load. >> (Smalltalk at: #ConfigurationOfGlamoroust) perform: #loadDefault. >> >> >> To execute it on a super simple package structure: >> RMockFilledPackageOrganizer fillUp. >> (Smalltalk at: #GTCoder) openOn: RMockFilledPackageOrganizer default >> >> Cheers, >> Doru >> >> >> On 16 Mar 2010, at 17:23, Lukas Renggli wrote: >> >>> Can you provide a Gofer expression to load it? >>> >>> Lukas >>> >>> On 16 March 2010 17: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 >>>> >>> >>> >>> >>> -- >>> 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 >> >> "Reasonable is what we are accustomed with." >> >> >> _______________________________________________ >> 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. > -- Best regards, Igor Stasenko AKA sig.

March 17, 2010

Re: [Pharo-project] packages :)

by Igor Stasenko

On 16 March 2010 19:00, Tudor Girba <tudor.girba(a)gmail.com> wrote: > Hi, > > To get it: > Gofer new > Â Â Â Â squeaksource: 'PharoTaskForces'; > Â Â Â Â package: 'RPackageAll'; > Â Â Â Â load. > I tried to do that in core image, and found that it having unresolved dependencies on: MorhTreeModel and MorphTreeNodeModel what package i need for them? > To get a super-simple browser that shows extensions in italics: > > Gofer new > Â Â Â Â squeaksource: 'glamoroust'; > Â Â Â Â package: 'ConfigurationOfGlamoroust'; > Â Â Â Â load. > (Smalltalk at: #ConfigurationOfGlamoroust) perform: #loadDefault. > > > To execute it on a super simple package structure: > RMockFilledPackageOrganizer fillUp. > (Smalltalk at: #GTCoder) openOn: RMockFilledPackageOrganizer default > > Cheers, > Doru > > > On 16 Mar 2010, at 17:23, Lukas Renggli wrote: > >> Can you provide a Gofer expression to load it? >> >> Lukas >> >> On 16 March 2010 17: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 >>> >> >> >> >> -- >> 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 > > "Reasonable is what we are accustomed with." > > > _______________________________________________ > 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

Re: [Pharo-project] squeaksource is down....

by Serge Stinckwich

I see on https://gforge.inria.fr/ : Pharo is the 5th most downloaded project ! On Tue, Mar 16, 2010 at 9:20 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > I asked to see if we can have a support for a webdav server for pharo core packages here but > they are flooded ... > Because I imagine that the pharo folder is getting to explode one of these days. > > Stef > On Mar 15, 2010, at 8:51 AM, Geert Claes wrote: > >> >> on another note ... SqueakSource probably needs an overhaul doesn't it ... >> whatever happened to SourceTalk? >> -- >> View this message in context: http://n4.nabble.com/squeaksource-is-down-tp1592562p1593040.html >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> >> _______________________________________________ >> 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 > -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Smalltalkers do: [:it | All with: Class, (And love: it)] http://doesnotunderstand.org/

March 17, 2010

Re: [Pharo-project] BTree packaging

by Chris Muller

Ok, I just saw that Pharo has Collections-This and Collectoins-That. So I can understand why you said Collections-BTree fits right in nicely. So maybe if Squeak renamed "Collections" similarly to what Pharo did, MC allows a dash in a package name and treats it as one unique name? On Tue, Mar 16, 2010 at 8:03 PM, Chris Muller <asqueaker(a)gmail.com> wrote: > -1 from me too about including it in Pharo or any other image. Â I don't > want to include BTree in any image. > > I was just asking about the naming. Â Since Squeak has a package called > Collections, loading BTree in Squeak makes that package dirty. > > Now, I agree there is a nostalgic element about that, and is the > original name that Avi gave it. Â However, I suspect the "Collections" > category of Squeak was there long before BTree came about. Â There > seems to be consensus that no one thinks BTree belongs in a base > image, and so it seems inappropriate to for an external package to > "invade" the namespace of such a general category, "Collections". > Perhaps, Avi wouldn't mind if the package were renamed to simply BTree > instead of Collections-BTree. > > I really think there are rewards to be harvested by our practicing > considerate collaboration and synergy between the communities. > > Â - Chris > > On Tue, Mar 16, 2010 at 3:27 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> >> On Mar 16, 2010, at 7:16 PM, Chris Muller wrote: >> >>> Hi Lukas, are there plans to include BTree standard in the Pharo >>> image? Â I was just wondering whether that was why the package is named >>> Collections-BTree, or if you would renaming it to simply BTree. >>> >>> It's mostly intangible that I have a dirty Collections package in many >>> image (because I often use BTree). Â Except that, I do find myself >>> sometimes checking in Monticello, "did I change something in >>> Collections? Â Oh, no, it's just BTree.. Â Or is it? Â Let me scroll this >>> list to be sure....." Â :) Â Kind of inconvenient, kind of inconsistent >>> for an external package. Â What do you think? >> >> MC is from time to time marking dirty packages are not. >> But in your case is it that? Or is there some methods compiled? >> >> For the inclusion into pharo here is my take: >> Â Â Â Â - if this is important for some internal applications we can >> Â Â Â Â the idea is that we copy but lukas keeps control and we merge from time to time >> Â Â Â Â as we do with gofer. >> >> Â Â Â Â - Now our goal is to make Pharo-Core smaller and smaller (but slowly) >> Â Â Â Â so probably BTree should not be in the core but it could be a package to load into >> Â Â Â Â the pharo (core + maintained by us package) or Pharo-dev (core+ maintainedby us + external). >> >> Â Â Â Â Now once we get a nice map of published packages for a release (aka universe browser) >> Â Â Â Â it should be easier for people to find/load.... packages. >> >> Stef >> _______________________________________________ >> 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 Carla F. Griggio

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 >

March 17, 2010

Re: [Pharo-project] BTree packaging

by Chris Muller

-1 from me too about including it in Pharo or any other image. I don't want to include BTree in any image. I was just asking about the naming. Since Squeak has a package called Collections, loading BTree in Squeak makes that package dirty. Now, I agree there is a nostalgic element about that, and is the original name that Avi gave it. However, I suspect the "Collections" category of Squeak was there long before BTree came about. There seems to be consensus that no one thinks BTree belongs in a base image, and so it seems inappropriate to for an external package to "invade" the namespace of such a general category, "Collections". Perhaps, Avi wouldn't mind if the package were renamed to simply BTree instead of Collections-BTree. I really think there are rewards to be harvested by our practicing considerate collaboration and synergy between the communities. - Chris On Tue, Mar 16, 2010 at 3:27 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Mar 16, 2010, at 7:16 PM, Chris Muller wrote: > >> Hi Lukas, are there plans to include BTree standard in the Pharo >> image? Â I was just wondering whether that was why the package is named >> Collections-BTree, or if you would renaming it to simply BTree. >> >> It's mostly intangible that I have a dirty Collections package in many >> image (because I often use BTree). Â Except that, I do find myself >> sometimes checking in Monticello, "did I change something in >> Collections? Â Oh, no, it's just BTree.. Â Or is it? Â Let me scroll this >> list to be sure....." Â :) Â Kind of inconvenient, kind of inconsistent >> for an external package. Â What do you think? > > MC is from time to time marking dirty packages are not. > But in your case is it that? Or is there some methods compiled? > > For the inclusion into pharo here is my take: > Â Â Â Â - if this is important for some internal applications we can > Â Â Â Â the idea is that we copy but lukas keeps control and we merge from time to time > Â Â Â Â as we do with gofer. > > Â Â Â Â - Now our goal is to make Pharo-Core smaller and smaller (but slowly) > Â Â Â Â so probably BTree should not be in the core but it could be a package to load into > Â Â Â Â the pharo (core + maintained by us package) or Pharo-dev (core+ maintainedby us + external). > > Â Â Â Â Now once we get a nice map of published packages for a release (aka universe browser) > Â Â Â Â it should be easier for people to find/load.... packages. > > Stef > _______________________________________________ > 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 csrabak＠bol.com.br

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

March 17, 2010