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

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

Re: [Pharo-project] BTree packaging

by Miguel Enrique CobÃ¡ Martinez

El mar, 16-03-2010 a las 13:16 -0500, Chris Muller escribiÃ³: > 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? > -1 to add it to PharoCore. The aim is to reduce package and load them when necessary, as stand-alone package or as a dependency for another package. The reasons are the same to the integration of Lukas' generator code to squeak. It is a one more thing to watch for updates in maintaining the core image. If it is external and have a ConfigurationOfXXX then it can be loaded when needed. Maybe can be added if enough quorum, to the ConfigurationOfPharo package in order to be loaded in a development, end user oriented Pharo image. There we can have all the packages we want. http://code.google.com/p/pharo/wiki/Packages Cheers > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Miguel CobÃ¡ http://miguel.leugim.com.mx

March 17, 2010

Re: [Pharo-project] Case statement and lazy comparison in Pharo

by Richard Durr

cool :D On Tue, Mar 16, 2010 at 3:58 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > + 1 > > On Mar 15, 2010, at 11:26 PM, Michael Roberts wrote: > >> I would try and reduce the number of branches first. you can use guard >> conditions to exit early. >> >> This is not necessarily exact below, but you hopefully get the idea... >> >> (self currentRow == sortedRows last and: [self currentCell isNil]) >> Â Â Â ifTrue: [^self navigationKey: event] >> >> self currentRow ifNil: [^self]. >> >> self currentCell ifNil: >> Â Â Â [^self setCurrentRowToNext] >> >> self setCurrentCellToNext. >> >> self currentCell ifNil: [^self]. >> >> self currentCell performKeyFocus: event inCellBounds: >> Â Â Â (self pvtGetCellBounds: self currentCell) >> >> >> A different approach entirely is to have an object(s) that represents >> the nil state for the row and cell. That way you are not checking >> constantly for it being nil, and perhaps you can dispatch some >> behaviour to it. >> >> cheers, >> Mike >> >> On Mon, Mar 15, 2010 at 9:49 PM, nullPointer <epicfan(a)gmail.com> wrote: >>> >>> Well, perhaps is a theme worked in another times but... is possible for Pharo >>> have a basic Case or elseIf statement? I know is easy create you own >>> structure control, but not is more useful have a "standard" for everybody? >>> IÂ´m tired of write code like that... >>> >>> Â Â Â Â Â Â Â Â Â Â Â Â (self currentRow == sortedRows last and: [ self >>> currentCell isNil ]) ifTrue: >>> Â Â Â Â Â Â Â Â Â Â Â Â [ >>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â self navigationKey: event >>> Â Â Â Â Â Â Â Â Â Â Â Â ] >>> Â Â Â Â Â Â Â Â Â Â Â Â ifFalse: >>> Â Â Â Â Â Â Â Â Â Â Â Â [ >>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â (self currentRow notNil and: [ self currentCell isNil ]) ifTrue: >>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â [ >>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â self setCurrentRowToNext. >>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ] >>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ifFalse: >>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â [ >>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â (self currentRow notNil and: [ self currentCell notNil ]) ifTrue: >>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â [ >>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â self setCurrentCellToNext. >>> >>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â self currentCell notNil ifTrue: >>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â [ >>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â self currentCell performKeyFocus: event inCellBounds: (self >>> pvtGetCellBounds: self currentCell). >>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ]. >>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ]. >>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ]. >>> Â Â Â Â Â Â Â Â Â Â Â Â ]. >>> >>> >>> Write code with that format is pathetical :( >>> >>> Is valid too have a "and" and "or" lazy? Exists a not lazy with #& and #| Â , >>> but could exists an #&& and #|| Â . Is more easy... >>> >>> Â Â Â value1 == value2 and:[ <condition> ] and: [<condition>] ...... >>> >>> or >>> >>> Â Â value1 == value2 && <condition> && <condition> ......... ??? >>> >>> Well, perhaps is a stupid question but I miss a more complete way for write >>> code. If in Smalltalk is possible do easy that and include it in "core" why >>> not do it? >>> >>> Is a reasonable desire :) >>> >>> Regards >>> >>> >>> >>> >>> >>> >>> -- >>> View this message in context: http://n4.nabble.com/Case-statement-and-lazy-comparison-in-Pharo-tp1594080p… >>> 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 16, 2010