December 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Issue with gofer/metacello

by StÃ©phane Ducasse

Yes I'm losing my time trying to rescue a proposal we should sent and I wonder what I'm doing because the acceptance rate are null. Stef On Dec 28, 2009, at 4:20 PM, Dale Henrichs wrote: > Stef, > > The moving sands are one of the costs of advancement ... I'm more upset that _I_ don't have time to solve the dang problems than I am that the problems are appearing ... all of the changes have been for good reasons and over time I have been removing code from Metacello as Gofer has expanded it's functionality... > > Gotta love the holidays:) > > Dale > ----- "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> wrote: > > | On Dec 27, 2009, at 11:38 PM, Dale Henrichs wrote: > | > | > Gofer-dkh.105 or whichever later version predates the move of the > | instance variable would get Metacello back into a bootable form for > | all versions of Pharo. > | > > | > I agree that for 1.0 a stable version of Gofer be chosen ... I'm > | trying to restrict the current Metacello changes to avoid significant > | API changes, but every time Gofer moves out from under me, I'm forced > | into making fundamental changes. > | > | Yes! > | I would like to have gofer stable in 1.0 and the same in 1.1 > | Sorry for the moving sands ;( > | Stef > | > | > Dale > | > ----- "Lukas Renggli" <renggli(a)gmail.com> wrote: > | > > | > | >> | | >> After proceeding these warnings, I have a rollback: MNU > | > | >> | | >> GoferPackageReference class>>name:repository: > | > | >> | | > > | > | >> | | > Can you evaluate > | > | >> | | > > | > | >> | | > [ Gofer gofer load ] > | > | >> | | > on: Error > | > | >> | | > do: [ :err | err retry ]. > | > | >> | | > Gofer gofer recompile. > | > | >> | | > > | > | >> | | > ? I don't have any senders of #name:repository: to > | > | >> | | > GoferPackageReference. > | > | > | > | We can remove the deprecated warnings, but that will not solve > | the > | > | real problem. Metacello is using some internal parts of Gofer > | that > | > | had > | > | to be changed to properly support fetch/push operations on > | multiple > | > | repositories. > | > | > | > | People have to stick with an old version of Gofer/Monticello. > | That's > | > | the same as with Pharo 1.1: Do not use the latest one. > | > | > | > | 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 > | > > | > _______________________________________________ > | > Pharo-project mailing list > | > Pharo-project(a)lists.gforge.inria.fr > | > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 28, 2009

Re: [Pharo-project] Issue with gofer/metacello

by Dale Henrichs

Stef, The moving sands are one of the costs of advancement ... I'm more upset that _I_ don't have time to solve the dang problems than I am that the problems are appearing ... all of the changes have been for good reasons and over time I have been removing code from Metacello as Gofer has expanded it's functionality... Gotta love the holidays:) Dale ----- "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> wrote: | On Dec 27, 2009, at 11:38 PM, Dale Henrichs wrote: | | > Gofer-dkh.105 or whichever later version predates the move of the | instance variable would get Metacello back into a bootable form for | all versions of Pharo. | > | > I agree that for 1.0 a stable version of Gofer be chosen ... I'm | trying to restrict the current Metacello changes to avoid significant | API changes, but every time Gofer moves out from under me, I'm forced | into making fundamental changes. | | Yes! | I would like to have gofer stable in 1.0 and the same in 1.1 | Sorry for the moving sands ;( | Stef | | > Dale | > ----- "Lukas Renggli" <renggli(a)gmail.com> wrote: | > | > | >> | | >> After proceeding these warnings, I have a rollback: MNU | > | >> | | >> GoferPackageReference class>>name:repository: | > | >> | | > | > | >> | | > Can you evaluate | > | >> | | > | > | >> | | > [ Gofer gofer load ] | > | >> | | > on: Error | > | >> | | > do: [ :err | err retry ]. | > | >> | | > Gofer gofer recompile. | > | >> | | > | > | >> | | > ? I don't have any senders of #name:repository: to | > | >> | | > GoferPackageReference. | > | | > | We can remove the deprecated warnings, but that will not solve | the | > | real problem. Metacello is using some internal parts of Gofer | that | > | had | > | to be changed to properly support fetch/push operations on | multiple | > | repositories. | > | | > | People have to stick with an old version of Gofer/Monticello. | That's | > | the same as with Pharo 1.1: Do not use the latest one. | > | | > | 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 | > | > _______________________________________________ | > Pharo-project mailing list | > Pharo-project(a)lists.gforge.inria.fr | > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 28, 2009

Re: [Pharo-project] moose collection extensions

by StÃ©phane Ducasse

>> Levente you should realize that these methods have been defined and used >> more than a couple of years ago. > > Most of the methods I suggested were added to squeak long before they started working on the project. I do not understand what you want to say but this is not important. We were working on vw in 1996 -> 2008 for Moose. So probably some came for Squeak. What I want to say is that judging is always driven by a context. > I don't think that growing a Set is faster than growing an Array, then converting it to a Set, but let's see the numbers: > > "Prepare an array with 10000 elements, each element is an array with one integer. 10% is duplicate." > data := (1 to: 9000) collect: [ :each | { SmallInteger maxVal atRandom } ]. > data := data, (data last: 1000). > data := data shuffled. > > (1 to: 10) collect: [ :run | > [ (data gather: [ :each | each ]) asSet ] timeToRun ]. ===> #(14 15 14 15 14 14 15 14 15 14). > > (1 to: 10) collect: [ :run | > [ data flatCollectAsSet: [ :each | each ] ] timeToRun ]. ===> #(29 29 29 28 29 28 28 29 29 29) This is something I can understand. So we will fix that. stef

Dec. 28, 2009

Re: [Pharo-project] External projects

by StÃ©phane Ducasse

I think that we should have a group of people controling integration. Stef > Hello all, > > I just noticed that the December web image (12.2) cannot open context menus for want of #isMethodNode and #isClassNode. > > When I last built an image, Citezen's installation was pointing to what I am told is an old copy of RIO which is broken on Windows. apparently this is not pharo's fault. > OS Process did not load cleanly. Bill what we are trying to with metacello is to have configuration of working packages. > Do we have a plan to fix such things? There is an obvious tradeoff between using the external code in its ideally up-to-date state and having something that is known to work. Yes Now can you report your problem is a way that we can reproduce them? > At a minimum, we might have a section on the Wiki dedicated to workarounds for loading packages with problems on Pharo. PackagesTestedInPharo is close; the Notes column might link to package-specific notes elsewhere on th wiki?? In some cases (e.g. the context menus), we should probably have needed methods added to each image as it is built to avoid giving a broken image to new users. > > Bill > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 28, 2009

Re: [Pharo-project] moose collection extensions

by Levente Uzonyi

On Mon, 28 Dec 2009, StÃ©phane Ducasse wrote: > Levente you should realize that these methods have been defined and used > more than a couple of years ago. Most of the methods I suggested were added to squeak long before they started working on the project. > They are used by a cool group of programmer and the infrastructure of Moose since > also a couple of years so I would not call them useless misleading I guess I missed a comma here, I meant useless or misleading. > but thanks for you analysis :) > > It is time to rewrite them. > But flatCollect: and flatCollectAsSet: names are more important than their implementation. > >>> I just checked these and most of them are useless misleading or duplicate, like: >> >> Collection >> >> #collectAsSet: -> #collect:as: (ok, it's new in pharo) >> #equalsTo: >> misleading name, #containsSameElementsAs: would be better IMO >> #(1 1 2) equalsTo: #(2 1 1) ===> true > > Yes I do not really like it > >> #flatCollect: -> #gather: > > the problem is that gather: does not convey its intention. > flatCollect: is much much better. > >> #flatCollectAsSet: -> #gather: + #asSet > > Is it not faster? > I don't think that growing a Set is faster than growing an Array, then converting it to a Set, but let's see the numbers: "Prepare an array with 10000 elements, each element is an array with one integer. 10% is duplicate." data := (1 to: 9000) collect: [ :each | { SmallInteger maxVal atRandom } ]. data := data, (data last: 1000). data := data shuffled. (1 to: 10) collect: [ :run | [ (data gather: [ :each | each ]) asSet ] timeToRun ]. ===> #(14 15 14 15 14 14 15 14 15 14). (1 to: 10) collect: [ :run | [ data flatCollectAsSet: [ :each | each ] ] timeToRun ]. ===> #(29 29 29 28 29 28 28 29 29 29) Levente >> #flatten -- >> misleading name, since it doesn't change the object, but returns >> a new array and it's only flattening one level which is what #gather: >> does. Tthere's a proper #flattened implementation in squeak treated >> inbox if you're interested. (guess why it's not in the trunk) >> #groupBy: -> #groupBy:having: >> #sum: -> #detectSum: >> >> Symbol >> >> #value (same as super) >> >> SequenceableCollection >> >> #shuffle -> #shuffled >> >> OrderedCollection >> >> #removeAtIndex: -> #removeAt: >> >> (-> means that the extension on the left is the same as or worse than >> the already existing method(s) on the right) >> >> I guess you should shrink this package. :) >> >> >> Levente_______________________________________________ >> 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 >

Dec. 28, 2009

Re: [Pharo-project] When writing comment, do you use 1st person?

by Peter Hugosson-Miller

On Mon, Dec 28, 2009 at 5:56 AM, Martin McClure <martin(a)hand2mouse.com>wrote: > Adrian Kuhn wrote: > > Martin McClure <martin@...> writes: > > > >> Actually, I usually do prefer to use first person when writing Smalltalk > >> comments. I find that anthropomorphizing objects helps to think in an > >> object-oriented way. > > > > Thanks everyone for all the answers so far! > > > > One of the things that keep confusing me is whether the I refers to the > class, > > the object or (in a method comment) to the method or even the method > > activation? For example in Randal's example, there it is the the > behavior > > *class* speaking in first person. Whereas to my understanding in > > *object*-oriented programming the objects should talk be first person > (not the > > classes). > > > > Even more confusing, I have also seen comments where the it was the > object or > > the methods. Or most confusing, an amalgamation of both, as eg in "I > return my > > first element" where to be precise the method activation returns the > first > > element of the object. So shouldn't it either be "(When activiated) > Returns my > > first element" or "I return the first element of my reciever"? > > > > This is not an academic example. When I started to write comments for > SUnit, I > > got actually confused. When writing (instance/class) methods comments, > to whom > > does the "I" refer to? > > > > Good points. Existing comments are not always consistent. > > In my opinion, "I" should always refer to an object. Which object? > "Self" within the current context. In an instance-side method comment, > "I" is the receiver of the message. In a class-side method comment, "I" > is the class. In a class comment, it's a little less clear, but probably > "I" should be the class in that case. > I often write "My instances" for class comments. > I'd probably write the above example imperatively, something like > "Answer my first element". > > In Smalltalk, I also tend to prefer "answer" over "return", and I tend > to talk about "messages" instead of "methods" unless explicitly dealing > with method objects. > > Regards, > > -Martin > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Cheers, Peter

Dec. 28, 2009

[Pharo-project] External projects

by Schwab,Wilhelm K

Hello all, I just noticed that the December web image (12.2) cannot open context menus for want of #isMethodNode and #isClassNode. When I last built an image, Citezen's installation was pointing to what I am told is an old copy of RIO which is broken on Windows. OS Process did not load cleanly. Do we have a plan to fix such things? There is an obvious tradeoff between using the external code in its ideally up-to-date state and having something that is known to work. At a minimum, we might have a section on the Wiki dedicated to workarounds for loading packages with problems on Pharo. PackagesTestedInPharo is close; the Notes column might link to package-specific notes elsewhere on th wiki?? In some cases (e.g. the context menus), we should probably have needed methods added to each image as it is built to avoid giving a broken image to new users. Bill

Dec. 28, 2009

Re: [Pharo-project] akuhn/SUnit, christmas edition :)

by Mariano Martinez Peck

On Mon, Dec 28, 2009 at 2:27 AM, Adrian Kuhn <akuhn(a)iam.unibe.ch> wrote: > Name: SUnit-AdrianKuhn.115 > Author: AdrianKuhn > Time: 28 December 2009, 2:22:16 am > UUID: 21af8078-0c75-4323-89aa-5f0142fa09d4 > Ancestors: SUnit-AdrianKuhn.114 > > Takes #expectedFailure into account. > > As required by Mariano Martinez Peck on the mailing list. He > uses the #expectedFailure method to dynamically create > expected failures, rather than a fixed set of failures as is > stored in stored history. > > > Hi Adrian! Thanks for trying to fix this. However, I can still reproduce the problem. I put a halt in my expectedFailures method and it is being called, here: importExpectedFailures: aTestClass aTestClass new expectedFailures do: [ :each | self testFinished: (TestFinished new testClass: aTestClass; selector: each; outcome: TestFinished failures; yourself) ] The iteration throught the do: seems to be ok, but I don't know why, the tests are still considered as error (red) instead of expectedFailures in green. Is correct to put "outcome: TestFinished failures;" ??? I guess it would be something like "outcome: TestFInished expectedFailures" but I look in the class side methods of TestFInished and I only see passed, failure and error. Let me know if I can test something more. The versions I am using are: SUnit-AdrianKuhn.116 SUnitGUI-AdrianKuhn.58 Cheers Mariano > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 28, 2009

Re: [Pharo-project] [squeak-dev] Re: Some questions about new traits (Crismas edition) ; )

by StÃ©phane Ducasse

for 1.1 Gofer new squeaksource: 'NanoTraits'; package: 'NanoTraits-Kernel'; package: 'NanoTraits-Tests'; load NanoTrait install I got a DNU ClassDescription traitImpl is not know. ClassDescription>>traitImpl ^NanoTrait uses: aTraitComposition | newTraits | newTraits := ((aTraitComposition isKindOf: NanoTrait) or: [ aTraitComposition isKindOf: NanoTraitTransformation]) aTraitComposition isKindOf: NanoTrait orOf: NanoTraitTransformation does not exist anymore in pharo :) luckily! Behavior class>>installTraitsFrom: aTraitComposition ... self traitComposition removeTraitUser: self. -> DNU removeTraitUser: Some comments I got just reading the code and eating. Difficult to write in mails because this is more like metathoughts about the overall design space (not only NT) but kernel, Btrait and NTraits. - I tried to understand what is the benefit to have NTdescription and NClassTrait subclass of ClassDescription. I think that this is a pity that the interface of the existing kernel and BTrait could not Now what I would really like to see is the impact on the tools (I imagine that andreas design is better for that and I would like to understand what are the underlying invariant of the tools that Btraits broke. I imagine that Btrait interface is not that far from NTrait now the point is probably that the fact that NT inherits some not necessary behavior from ClassDescription fulfills better the tool invariant. - I have the impression that the design of adrian was less backwards and more here is a "new" kernel and tools were shaken. - something that I would like to see fixed in traits is the problem with the superclass Igor once you remove the non traits related classes: Trait-Requires Trait-LocalSends Traits-Kernel => 5 classes Traits-Composition => 7 (and I imagine that we could do a pass to clean method) so all in all we may have 15 classes in total (exception included). Issue 1706: Clean Traits implementation http://code.google.com/p/pharo/issues/detail?id=1706 Back latexing pffffff :(

Dec. 28, 2009

Re: [Pharo-project] akuhn/SUnit, chrisma edition :)

by Mariano Martinez Peck

On Mon, Dec 28, 2009 at 12:33 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > > > On Mon, Dec 28, 2009 at 1:57 AM, Adrian Kuhn <akuhn(a)iam.unibe.ch> wrote: > >> Mariano Martinez Peck <marianopeck@...> writes: >> >> > Adrian: Can I still bother you with new requirements ? jajaja >> >> Your welcome :) >> >> > First of all, thank you very much for putting a context menu when you >> press >> > "right button" over a failing or error test. I really hate when it was >> run >> > again instead of opening a context menu. Now, I noticed that you open a >> menu >> > with the options "History" "Store..." and "Show progress". >> >> The history menu should *only* show up when you right-click in the colored >> status bar, but not on failure and error list. Can you conform that? >> > > I think that yes :) I attach an screenshot. Tell me is that's fine. > In that screenshot you can see also the error tests that actually are > expectedFailures and with the previous version of Sunit, the were green. > I now tested with your latests commits and it seems to work ok. Only the items "Browse" and "Debug" are shown over a failure/error test. And the other three ("History" "Store..." and "Show progress".) are only in the status bar :) > > >> >> > I really love one item more called "browse it" and that opens a System >> > Browser with that class, with that test method selected. What do you >> think? >> >> Awesome idea, I'll add that. >> >> > Excellent :) > > >> PS, I was also thinking about a 'step through test' option that open a >> debugger >> at the start of the test, rather than at the failing assertions. Will add >> that >> to the same menu... >> >> > Yes, that's cool also. Many times I have to go to the assertion and then a > restart in the debugger. > > Thank you very much. > > Mariano > > --AA >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >

Dec. 28, 2009