June 2011 - Pharo-dev - lists.pharo.org

[Pharo-project] [COTDC] 74 - MorphTreeNodeMorph

by laurent laffont

Today: MorphTreeNodeMorph Comment Of The Day Contest - One Day One Comment Rules: #1: Each day a not commented class is elected. Each day the best comment will be integrated with name of the author(s). #2: If you cannot comment it, deprecate it. Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest Laurent

June 21, 2011

Re: [Pharo-project] [COTDC] 73 - MorphTreeNodeModel

by laurent laffont

On Mon, Jun 20, 2011 at 8:33 PM, laurent laffont <laurent.laffont(a)gmail.com>wrote: > Today: MorphTreeNodeModel > I wrap an item to be displayed in a TreeMorph, so I can answers content and representation in a polymorphic way. My hierarchy usually follows TreeMorphModel one. Laurent. > > (and sorry for last days lazyness on this ...) > > > Comment Of The Day Contest - One Day One Comment > Rules: > #1: Each day a not commented class is elected. Each day the best comment > will be integrated with name of the author(s). > #2: If you cannot comment it, deprecate it. > Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest > > Laurent >

June 21, 2011

Re: [Pharo-project] #assert:equals: feels backwards

by laurent laffont

On Tue, Jun 21, 2011 at 7:16 PM, Sean P. DeNigris <sean(a)clipperadams.com>wrote: > In my unit test, I want to make sure that my output equals the > expectedOutput, but: > TestCase>>assert: expected equals: actual > > It feels wrong to me. It seems that I want to make an assertion about my > class's behavior and I would like to write: > self assert: output equals: expectedOutput. > > What do you all think? > Personnally I prefer assert: expected equals: actual because the first thing I have to think about is what I expect, not how to get it. So for me it feels more natural to write it this way. Laurent. > > Thanks. > Sean > > -- > View this message in context: > http://forum.world.st/assert-equals-feels-backwards-tp3614760p3614760.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >

June 21, 2011

Re: [Pharo-project] #assert:equals: feels backwards

by Hernan Wilkinson

yes, there was. It is like that because that is how it is in JUnit.... everybody agreed it was rare and if I'm not wrong, was going to be changed On Tue, Jun 21, 2011 at 4:56 PM, Guillermo Polito <guillermopolito(a)gmail.com > wrote: > I remember a thread about this not long ago... Try searching the history > :) > > Guille > > > On Tue, Jun 21, 2011 at 2:16 PM, Sean P. DeNigris <sean(a)clipperadams.com>wrote: > >> In my unit test, I want to make sure that my output equals the >> expectedOutput, but: >> TestCase>>assert: expected equals: actual >> >> It feels wrong to me. It seems that I want to make an assertion about my >> class's behavior and I would like to write: >> self assert: output equals: expectedOutput. >> >> What do you all think? >> >> Thanks. >> Sean >> >> -- >> View this message in context: >> http://forum.world.st/assert-equals-feels-backwards-tp3614760p3614760.html >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> >> > -- *HernÃ¡n Wilkinson Agile Software Development, Teaching & Coaching Mobile: +54 - 911 - 4470 - 7207 email: hernan.wilkinson(a)10Pines.com site: http://www.10Pines.com <http://www.10pines.com/>* Address: Paraguay 523, Floor 7 N, Buenos Aires, Argentina

June 21, 2011

Re: [Pharo-project] #assert:equals: feels backwards

by Hernan Wilkinson

> > > PS: Ok, I know, there is the error string. > that nobody never reads :-) I think in Smalltalk it does not make too much sense to have assert:equals:, like you say, it does not add value... but in those "parenthesis languages" were number are not objects and etc... well, they need it :-) > > On 21 June 2011 22:45, Max Leske <maxleske(a)gmail.com> wrote: > > +1 > > > > > > On 21.06.2011, at 19:16, Sean P. DeNigris wrote: > > > >> In my unit test, I want to make sure that my output equals the > >> expectedOutput, but: > >> TestCase>>assert: expected equals: actual > >> > >> It feels wrong to me. It seems that I want to make an assertion about my > >> class's behavior and I would like to write: > >> self assert: output equals: expectedOutput. > >> > >> What do you all think? > >> > >> Thanks. > >> Sean > >> > >> -- > >> View this message in context: > http://forum.world.st/assert-equals-feels-backwards-tp3614760p3614760.html > >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >> > > > > > > > > > > -- > Lukas Renggli > www.lukas-renggli.ch > > -- *HernÃ¡n Wilkinson Agile Software Development, Teaching & Coaching Mobile: +54 - 911 - 4470 - 7207 email: hernan.wilkinson(a)10Pines.com site: http://www.10Pines.com <http://www.10pines.com/>* Address: Paraguay 523, Floor 7 N, Buenos Aires, Argentina

June 21, 2011

Re: [Pharo-project] #assert:equals: feels backwards

by Guillermo Polito

I remember a thread about this not long ago... Try searching the history :) Guille On Tue, Jun 21, 2011 at 2:16 PM, Sean P. DeNigris <sean(a)clipperadams.com>wrote: > In my unit test, I want to make sure that my output equals the > expectedOutput, but: > TestCase>>assert: expected equals: actual > > It feels wrong to me. It seems that I want to make an assertion about my > class's behavior and I would like to write: > self assert: output equals: expectedOutput. > > What do you all think? > > Thanks. > Sean > > -- > View this message in context: > http://forum.world.st/assert-equals-feels-backwards-tp3614760p3614760.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >

June 21, 2011

Re: [Pharo-project] #assert:equals: feels backwards

by Lukas Renggli

Why don't you just use #assert: and #=? This is much shorter and the description string is not really worth the troubles, isn't it :-) Lukas PS: Ok, I know, there is the error string. On 21 June 2011 22:45, Max Leske <maxleske(a)gmail.com> wrote: > +1 > > > On 21.06.2011, at 19:16, Sean P. DeNigris wrote: > >> In my unit test, I want to make sure that my output equals the >> expectedOutput, but: >> Â Â TestCase>>assert: expected equals: actual >> >> It feels wrong to me. It seems that I want to make an assertion about my >> class's behavior and I would like to write: >> Â Â self assert: output equals: expectedOutput. >> >> What do you all think? >> >> Thanks. >> Sean >> >> -- >> View this message in context: http://forum.world.st/assert-equals-feels-backwards-tp3614760p3614760.html >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> > > > -- Lukas Renggli www.lukas-renggli.ch

June 21, 2011

Re: [Pharo-project] [squeak-dev] Re: initial Spoon modularization

by Chris Muller

Really fascinating Craig, congratulations! > Â Â Seriously, the main point in being small is making it easier to > understand the whole system. I want to enable anyone who's interested to > learn how everything fits together, and not wonder why something is there. Not only that, but is this also a practical way to make a small, special-purpose image? For example, what would it take to imprint onto your 300K image from, say, a standard Squeak 4.2 image, just the methods needed to run one method specified by the user, which would cause all kinds of other methods to be faulted into the target image, but still end up with considerably less than the entirety of the 4.2 image? - Chris

June 21, 2011

Re: [Pharo-project] #assert:equals: feels backwards

by Max Leske

+1 On 21.06.2011, at 19:16, Sean P. DeNigris wrote: > In my unit test, I want to make sure that my output equals the > expectedOutput, but: > TestCase>>assert: expected equals: actual > > It feels wrong to me. It seems that I want to make an assertion about my > class's behavior and I would like to write: > self assert: output equals: expectedOutput. > > What do you all think? > > Thanks. > Sean > > -- > View this message in context: http://forum.world.st/assert-equals-feels-backwards-tp3614760p3614760.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

June 21, 2011

Re: [Pharo-project] PharoKernel 13269

by StÃ©phane Ducasse

what we should pay attention (to be verified) is that igor told me that he does not understand why the latest code of the vm published by eliot does not include some fixes he did for 1.2. May be the code was never integrated. In addition the latest vm produced by eliot does not include a long list of fixes made by igor and mariano. Igor asked in the vm mailing-list what will happen to his changes and there were no reaction so far. So we should pay attention that using the latest vm from eliot may also break our system. We should also think about the fact that may be we will have to burn igor's time to merge vm fixes when other people don't do it. I asked igor to continue to work on the windows build because we want to run regression tests at the VM level. We should be able to trace vm changes and control the impact they have on us and not run after different versions and releases. To have a process in a sense. Stef yeah.. harmonization, it would be good, Eliot if you take a look of changes made in VMMaker-oscog-MarianoMartinezPeck.66 and integrate them, so we will use common version. They have a common ancestor - VMMaker-oscog.54 Without this all of the following work will be lost: Name: VMMaker-oscog-IgorStasenko.54 Author: IgorStasenko Time: 23 March 2011, 5:30:42 pm UUID: c98a0b6c-7f68-4af7-9012-85d3dfdf29ae Ancestors: VMMaker-oscog-IgorStasenko.53 - added disabling module loading support Name: VMMaker-oscog.dtl.56 Author: dtl Time: 4 April 2011, 10:06:00.292 pm UUID: c1d30608-00e8-53b7-209a-34f7a46c1508 Ancestors: VMMaker-IgorStasenko.55 Add tests from VMMaker trunk to document various issues and verify presence of primitives. Name: VMMaker-oscog.dtl.57 Author: dtl Time: 11 April 2011, 10:13:51.668 pm UUID: c1d30608-04dd-53b7-209a-34f7a46c1508 Ancestors: VMMaker-oscog.dtl.56 Generate C code for #repeat. Implementation by Igor Stasenko and Nicolas Cellier. Name: VMMaker-oscog-dtl.58 Author: dtl Time: 17 April 2011, 10:22:12.174 pm UUID: c1d30608-04b3-a5b7-20ca-2bf7a46c1508 Ancestors: VMMaker-oscog-dtl.57, VMMaker-oscog.dtl.57 Merge VMMaker-oscog.dtl.57 Generate C code for #repeat. Implementation by Igor Stasenko and Nicolas Cellier. Name: VMMaker-oscog-dtl.59 Author: dtl Time: 17 April 2011, 10:32:55.018 pm UUID: c1d30608-042d-4bb7-20ca-2bf7a46c1508 Ancestors: VMMaker-oscog-dtl.58 Merge VMMaker-oscog.dtl.58, and add #primitiveImageFormatVersion Add primitiveMillisecondClockMask, an optional named primitive used in conjunction with primitiveMillisecondClock for duration calculations. The image assumes a value for this constant that is assumed to correspond to the actual value used in the VM. This primitive permits the VM to report the actual value being used. Add primitiveImageFormatVersion, an optional named primitive answering the image format number of the current image. This is the value stored in the first word of an image file header when the image is saved, and possibly modified on image load if the VM adds or removes capabilities for the running image. This primitive was added to VMMaker trunk in VMMaker-dtl.169. Rationale: supports float word order handing for image segments, reference http://lists.squeakfoundation.org/pipermail/vm-dev/2011-April/007712.html Name: VMMaker-oscog-dtl.64 Author: dtl Time: 21 April 2011, 8:24:32.46 pm UUID: c1d30608-30ec-50b7-208a-31f7a46c1508 Ancestors: VMMaker-oscog-dtl.59 Re-save from VMMaker-oscog-EstebanLorenzano.62 because VMMaker-oscog-dtl.61 and VMMaker-oscog-dtl.60 were saved without correct ancestry. This version incorporates the changes from VMMaker-oscog-EstebanLorenzano.62, VMMaker-oscog-dtl.61, and VMMaker-oscog-dtl.60. Name: VMMaker-oscog-EstebanLorenzano.62 -added ClipboardExtendedPlugin as a regular plugin (taken from the InterpreterVM branch) I don't know if it works right now, but at least it compiles :) Name: VMMaker-oscog-dtl.61 A second batch of updates from VMM trunk, primarily cosmetic but also a class comment update and a couple of methods that had not previously been pragmatized in oscog. Name: VMMaker-oscog-dtl.60 These changes are methods from the main VMM branch for which <#var:#type:> declarations have been formatted with proper spacing. By updating these in the oscog branch, all of these methods are identical in both branches. All changes are cosmetic (no functional changes to the methods). Name: VMMaker-oscog-MarianoMartinezPeck.65 Author: MarianoMartinezPeck Time: 23 April 2011, 1:50:19 pm UUID: 944f5c54-f2f5-4cc7-b693-b4db9320cff8 Ancestors: VMMaker-oscog-dtl.64 blah Name: VMMaker-oscog-MarianoMartinezPeck.66 Author: MarianoMartinezPeck Time: 23 April 2011, 2:17:26 pm UUID: 97bab5b0-51d6-4deb-8b58-5bcedd4747dc Ancestors: VMMaker-oscog-MarianoMartinezPeck.65 Adapt VMMakerTool so that it doesnt try to register in the menu if TheWorldMenu is not present, like the case of Pharo. This change was already integrated in the main trunk of VMMaker but since Eliot forked VMMaker-oscog before that, it was not there. It doesn't affect Squeak -- Best regards, Igor Stasenko AKA sig.

June 21, 2011