May 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Messy Configurations

by Dale K. Henrichs

May 23, 2013

Re: [Pharo-dev] Messy Configurations

by Dale K. Henrichs

----- Original Message ----- | From: "Camillo Bruni" <camillobruni(a)gmail.com> | To: pharo-dev(a)lists.pharo.org | Sent: Wednesday, May 22, 2013 8:53:31 AM | Subject: [Pharo-dev] Messy Configurations | | I recently spent some time to revise how to write Metacello | Configurations. | | Observation: | ============ | - many configurations are quite a mess | - many configurations duplicate code internally | - many configurations have archived development versions | | | For Pharo 3.0 I made a new Configuration template which improves and | documents | these observed points in quite some detail. Simply load a new 3.0 | image and | create a new configuration from the monticello working copy browser. | | Solution: | ========= | - specify external projects in separate, reusable methods | - only have ONE development version you regularly update | - do not use version numbers for the development version | - only make a version number when you release something stable AKA | not #development | - name the baseline after the first version that introduces it | | | | What do you think? Cami, I don't want to discount your frustration with the complexity of Metacello configurations and looking at your sample configurations you have definitely come up with a cleaner structure for the code ... But, (there always is a _but_) ... Metacello configurations are not really code ... they are specifications ... Metacello configurations are closer to XML files than they are to Smalltalk classes ... XML files are "read" by tools and "written" by tools ... You can hand edit an XML file to produce a pleasing structure for human readability, but when a tool gets ahold of the file and rewrites the XML file, all of the fancy hand editing disappears ... The same thing will happen with configurations ... you can restructure the code in your configuration using nicely structured methods, etc, however, if you use a tool to add/manipulate your configuration, all of the fancy "formatting" will be lost and the tool will write out a monolithic single method representation of your specification (leaving the rest of the configuration methods untouched) ... With that said, it is conceivable that a crop of tools can be written to produce "better structured configurations" ... meaningful pragmas could be invented so that tools and humans could both be aware of the "project methods" and other components that you've added ... but that is up to the tool builders ... Dale

May 23, 2013

Re: [Pharo-dev] MC Filetree -- missing FiletreeURL ?

by Dale K. Henrichs

May 23, 2013

Re: [Pharo-dev] Halt subclass: #AssertionFailure

by Camillo Bruni

On 2013-05-23, at 16:37, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 23 May 2013, at 16:34, Camillo Bruni <camillobruni(a)gmail.com> wrote: > >> >> On 2013-05-23, at 16:26, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >>> >>> On 23 May 2013, at 15:59, Camillo Bruni <camillobruni(a)gmail.com> wrote: >>> >>>> why? To me this does not make sense. I'd expect >>>> >>>> Error subclass: #AssertionFailure >>> >>> Yeah, I have asked myself the same question quite often. >>> >>> I often write self assert: <some condition> in production code, but then an #on:do: handler specifying only Error won't catch the AssertionFailure exceptions. >> >> exactly! I'm going to propose a fix, because I hate to write Error,AssertionFailure :P >> >>> I would guess it has something to do with SUnit logic ? >> >> >> Must be some strange leftover, since in interactive mode there is no distinction between Halt and any other Error. > > But doesn't TestRunner react differently on AssertionError as opposed to other Errors ? The former are called 'Failures', the latter 'Errors'... I just checked. Using Halt and AssertionFailures directly in a test does mark the test as a failure, but it doesn't change anything on the existing #assert: inside testcases directly. Before: RBFormatterTests>>#testHalt Halt RBFormatterTests>>#testAssertionFailure AssertionFailure RBFormatterTests>>#testAssert TestFailure: Assertion failed After: RBFormatterTests>>#testHalt Halt RBFormatterTests>>#testAssertionFailure AssertionFailure RBFormatterTests>>#testAssert TestFailure: Assertion failed The only difference is in UI mode, when there is an AssertionFailure the test wasn't immediately marked RED. IMO this is not correct, as a failing assertion anywhere outside the code is an Error. But that was the case before (on the command line). So I would apply this change and maybe improve SUnit to deal with AssertionFailures from outside TestCases

May 23, 2013

Re: [Pharo-dev] Halt subclass: #AssertionFailure

by Sven Van Caekenberghe

On 23 May 2013, at 16:34, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > On 2013-05-23, at 16:26, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> >> On 23 May 2013, at 15:59, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> >>> why? To me this does not make sense. I'd expect >>> >>> Error subclass: #AssertionFailure >> >> Yeah, I have asked myself the same question quite often. >> >> I often write self assert: <some condition> in production code, but then an #on:do: handler specifying only Error won't catch the AssertionFailure exceptions. > > exactly! I'm going to propose a fix, because I hate to write Error,AssertionFailure :P > >> I would guess it has something to do with SUnit logic ? > > > Must be some strange leftover, since in interactive mode there is no distinction between Halt and any other Error. But doesn't TestRunner react differently on AssertionError as opposed to other Errors ? The former are called 'Failures', the latter 'Errors'...

May 23, 2013

Re: [Pharo-dev] Halt subclass: #AssertionFailure

by Camillo Bruni

On 2013-05-23, at 16:26, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 23 May 2013, at 15:59, Camillo Bruni <camillobruni(a)gmail.com> wrote: > >> why? To me this does not make sense. I'd expect >> >> Error subclass: #AssertionFailure > > Yeah, I have asked myself the same question quite often. > > I often write self assert: <some condition> in production code, but then an #on:do: handler specifying only Error won't catch the AssertionFailure exceptions. exactly! I'm going to propose a fix, because I hate to write Error,AssertionFailure :P > I would guess it has something to do with SUnit logic ? Must be some strange leftover, since in interactive mode there is no distinction between Halt and any other Error.

May 23, 2013

Re: [Pharo-dev] Halt subclass: #AssertionFailure

by Sven Van Caekenberghe

On 23 May 2013, at 15:59, Camillo Bruni <camillobruni(a)gmail.com> wrote: > why? To me this does not make sense. I'd expect > > Error subclass: #AssertionFailure Yeah, I have asked myself the same question quite often. I often write self assert: <some condition> in production code, but then an #on:do: handler specifying only Error won't catch the AssertionFailure exceptions. I would guess it has something to do with SUnit logic ? Sven

May 23, 2013

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/./label=wi… 3 regressions found. FuelTests.FLMethodContextSerializationTest.testDoIt Tests.Release.ReleaseTest.testObsoleteBehaviors Tests.Release.ReleaseTest.testObsoleteClasses

May 23, 2013

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/./label=ma… 3 regressions found. FuelTests.FLMethodContextSerializationTest.testDoIt Tests.Release.ReleaseTest.testObsoleteBehaviors Tests.Release.ReleaseTest.testObsoleteClasses

May 23, 2013

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/./label=li… 3 regressions found. FuelTests.FLMethodContextSerializationTest.testDoIt Tests.Release.ReleaseTest.testObsoleteBehaviors Tests.Release.ReleaseTest.testObsoleteClasses

May 23, 2013