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

should:raise:description:

by Camillo Bruni

I continue my rant with should:raise:description: a) self should: [ Error signal: 'error message' ] raise: Halt description: 'message'. b) self should: [ 1 + 2 ] raise: Halt description: 'message'. In the first case you do not get the 'message' but 'error message'. In the second case you get the 'message'. Does the description make sense in this case? 1. if you signal Halt everything is fine 2. Every other case is a failure 3. In case a) an internal failure happens so the test fails anyway, fine, but no description 4. A strange? case where the tests actually DO pass but we nevertheless want to print a description. Can anybody give me a convincing case for 4? Sorry, after this I will stop :D

July 9, 2013

Re: [Pharo-dev] the return of the strange methods

by Camille Teruel

On 9 juil. 2013, at 18:42, Esteban Lorenzano wrote: > Even more important, IMHO: allowing those methods to exists is to validate an anti-pattern: if you have an specific error to throw, you should create a specific descendant of Error, not just throw Error with an explanation. > > So, +A LOT to remove them. Agree Moreover, I really don't see why we should have a special assertion for auditing the description of an Error. If you begin like that you end up with tons of highly specific assertion for tons of specific objects: self assert: aCollection hasSizeLowerThan: 10. self assert: aPoint isBelow: 2@3. self assert: myDomainObject satisfiesSomeDomainSpecificConstraintParametrizedBy: anObject and: anotherObject ... No way! > > Esteban > > On Jul 9, 2013, at 5:42 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > >> They may be useful. Imagine you are too lazy to create a subclass of Error, but not lazy enough to create a test and copy paste a String. >> Then you write in your method: >> self error: 'some strange error happened' >> And you can test it: >> self shouldnt: [ "some strange code" ] raise: Error whoseDescriptionIncludes: 'some strange error happened' description: 'the strange error did not happen ! That's strange' >> >> Seriously, as you saw these methods are used only in their tests. I guess you can remove them. Open fogz bug ? >> >> >> 2013/7/9 Frank Shearar <frank.shearar(a)gmail.com> >> On 9 July 2013 16:24, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> > Survey: who uses the following methods? and if yes why? >> > >> > - shouldnt: aBlock raise: anExceptionalEvent whoseDescriptionDoesNotInclude: subString description: aString >> > - shouldnt: aBlock raise: anExceptionalEvent whoseDescriptionIncludes: subString description: aString >> > >> > I honestly cannot wrap my head around these two methods. >> >> They show that the code in the block raises an _informative_ >> exception. So you get a FileNotFound exception... but what was the >> missing file? I don't know! Noone bothered to mention it! >> >> frank >> >> >

July 9, 2013

Re: [Pharo-dev] the return of the strange methods

by Camillo Bruni

On 2013-07-09, at 18:48, Frank Shearar <frank.shearar(a)gmail.com> wrote: > On 9 July 2013 17:42, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> Even more important, IMHO: allowing those methods to exists is to validate >> an anti-pattern: if you have an specific error to throw, you should create a >> specific descendant of Error, not just throw Error with an explanation. >> >> So, +A LOT to remove them. > > No. Failing to specify your error messages is a colossal fail. And if > you don't _test_ your error messages, how are you going to know you > haven't just made your error messages utterly useless in that last > refactoring? That is a separate test for your Exception: MyExceptionTest >> testMessage | message | message := self targetClass new description. ... I don't see the point in testing the description string somewhere else... > And no, checking that your KeyNotFound exception's #key is correctly > set is insufficient, because you then _presume_ that the process of > reporting the exception actually bothers to record that and doesn't > just say "a KeyNotFound". I do not fully see the point of testing that a certain exception is not signaled. 1. if an exception is signaled the test will fail anyways 2. if exceptions are signaled you can easily test that using something like: self should: [ .. ] raise: (NotFound, ZeroDivide, ...) 3. If you have a test that returns different exceptions in the tests you have nondeterminism, so that basically invalidates point 2. 3. Since you have deterministic tests you know that only one kind of error is signaled hence it suffices to use the #should:raise:... methods. Hence, I really do not see the point of the complex #shouldnt:raise:whoseDescriptionIncludes: 1. #shouldnt:raise: is more less fine. Though I would expect it ignore all the other errors thrown, which it doesn't essentially limiting the use of this method. 2. #shouldnt:raise:whoseDescriptionIncludes: is too complex. 3. #shouldnt:raise:whoseDescriptionDoesNotIncludes: essentially reads like a double negation which confuses the hell out of me ----------------------------------------------------------------------------------------- Example: -------- self shouldnt: [ ... ] raise: MyException whoseDescriptionIncludes: 'PING'. What does that mean for the following blocks? 1. [ Error signal ] 2. [ Error signal: 'PING' ] 3. [ MyException signal ] 4. [ MyException signal: 'PING' ] 3 and 4 definitely fail, I assume 1 fails too, and the only one left is case 2. And the monstrous #shouldnt:raise:whoseDescriptionDoesNotInclude: will only pass in case 1? ----------------------------------------------------------------------------------------- In any case, nobody uses the complex #shouldnt:raise:whose* methods so I am removing them and simplify the implementation of TAssertable.

July 9, 2013

Re: [Pharo-dev] the return of the strange methods

by Camillo Bruni

On 2013-07-09, at 17:30, Frank Shearar <frank.shearar(a)gmail.com> wrote: > On 9 July 2013 16:24, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> Survey: who uses the following methods? and if yes why? >> >> - shouldnt: aBlock raise: anExceptionalEvent whoseDescriptionDoesNotInclude: subString description: aString >> - shouldnt: aBlock raise: anExceptionalEvent whoseDescriptionIncludes: subString description: aString >> >> I honestly cannot wrap my head around these two methods. > > They show that the code in the block raises an _informative_ > exception. So you get a FileNotFound exception... but what was the > missing file? I don't know! Noone bothered to mention it! no it is #shouldnt: it is the inverse. the #should:... handler methods are fine, but these specific two methods are just insane. I tried to reimplement them without looking at the original definition and I cannot come up with something that matches the name :) so there is definitely something wrong with it.

July 9, 2013

Re: [Pharo-dev] [ANN] Pharo VM now building on Pharo 2.0

by Esteban Lorenzano

On Jul 8, 2013, at 11:08 PM, phil(a)highoctane.be wrote: > I'll have to try that. > > How to run an interpreter in there? Is it possible? no idea i didn't compile an interpreter since a while. It is in my todo list, but with a priority really low :) Why do you need an interpretervm? Esteban > > Phil > > > > On Mon, Jul 8, 2013 at 9:06 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi, > > Today I migrated the jenkins jobs for building the PharoVM to 2.0. > Objectively, nothing changes for the VM users, but is important to move the infrastructure according to our yearly releases. > For those who are creating their own VMs and stuff, now you can move to 2.0 too, there is no need to keep using 1.4. > > jenkins builds are, as always, at: > https://ci.inria.fr/pharo/view/VM/job/PharoVM/ > > (windows build is broken due a know problem in the windows slave, not related with the VM build itself) > > Thanks Guille for doing the work and Camillo for the support :) > > Esteban >

July 9, 2013

Re: [Pharo-dev] the return of the strange methods

by Frank Shearar

On 9 July 2013 17:42, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Even more important, IMHO: allowing those methods to exists is to validate > an anti-pattern: if you have an specific error to throw, you should create a > specific descendant of Error, not just throw Error with an explanation. > > So, +A LOT to remove them. No. Failing to specify your error messages is a colossal fail. And if you don't _test_ your error messages, how are you going to know you haven't just made your error messages utterly useless in that last refactoring? And no, checking that your KeyNotFound exception's #key is correctly set is insufficient, because you then _presume_ that the process of reporting the exception actually bothers to record that and doesn't just say "a KeyNotFound". By all means use a proper exception that captures semantic meaning. But, please, PLEASE actually test your logging. frank > Esteban > > On Jul 9, 2013, at 5:42 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > They may be useful. Imagine you are too lazy to create a subclass of Error, > but not lazy enough to create a test and copy paste a String. > Then you write in your method: > self error: 'some strange error happened' > And you can test it: > self shouldnt: [ "some strange code" ] raise: Error > whoseDescriptionIncludes: 'some strange error happened' description: 'the > strange error did not happen ! That's strange' > > Seriously, as you saw these methods are used only in their tests. I guess > you can remove them. Open fogz bug ? > > > 2013/7/9 Frank Shearar <frank.shearar(a)gmail.com> >> >> On 9 July 2013 16:24, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> > Survey: who uses the following methods? and if yes why? >> > >> > - shouldnt: aBlock raise: anExceptionalEvent >> > whoseDescriptionDoesNotInclude: subString description: aString >> > - shouldnt: aBlock raise: anExceptionalEvent whoseDescriptionIncludes: >> > subString description: aString >> > >> > I honestly cannot wrap my head around these two methods. >> >> They show that the code in the block raises an _informative_ >> exception. So you get a FileNotFound exception... but what was the >> missing file? I don't know! Noone bothered to mention it! >> >> frank >> > >

July 9, 2013

Re: [Pharo-dev] the return of the strange methods

by Esteban Lorenzano

Even more important, IMHO: allowing those methods to exists is to validate an anti-pattern: if you have an specific error to throw, you should create a specific descendant of Error, not just throw Error with an explanation. So, +A LOT to remove them. Esteban On Jul 9, 2013, at 5:42 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > They may be useful. Imagine you are too lazy to create a subclass of Error, but not lazy enough to create a test and copy paste a String. > Then you write in your method: > self error: 'some strange error happened' > And you can test it: > self shouldnt: [ "some strange code" ] raise: Error whoseDescriptionIncludes: 'some strange error happened' description: 'the strange error did not happen ! That's strange' > > Seriously, as you saw these methods are used only in their tests. I guess you can remove them. Open fogz bug ? > > > 2013/7/9 Frank Shearar <frank.shearar(a)gmail.com> > On 9 July 2013 16:24, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > Survey: who uses the following methods? and if yes why? > > > > - shouldnt: aBlock raise: anExceptionalEvent whoseDescriptionDoesNotInclude: subString description: aString > > - shouldnt: aBlock raise: anExceptionalEvent whoseDescriptionIncludes: subString description: aString > > > > I honestly cannot wrap my head around these two methods. > > They show that the code in the block raises an _informative_ > exception. So you get a FileNotFound exception... but what was the > missing file? I don't know! Noone bothered to mention it! > > frank > >

July 9, 2013

Re: [Pharo-dev] the return of the strange methods

by Frank Shearar

On 9 July 2013 16:42, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > They may be useful. Imagine you are too lazy to create a subclass of Error, > but not lazy enough to create a test and copy paste a String. > Then you write in your method: > self error: 'some strange error happened' > And you can test it: > self shouldnt: [ "some strange code" ] raise: Error > whoseDescriptionIncludes: 'some strange error happened' description: 'the > strange error did not happen ! That's strange' > > Seriously, as you saw these methods are used only in their tests. I guess > you can remove them. Open fogz bug ? If something should not raise a KeyNotFound exception, which would you regard as more useful: "KeyNotFound" or "'foo' key not found" ? frank > 2013/7/9 Frank Shearar <frank.shearar(a)gmail.com> >> >> On 9 July 2013 16:24, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> > Survey: who uses the following methods? and if yes why? >> > >> > - shouldnt: aBlock raise: anExceptionalEvent >> > whoseDescriptionDoesNotInclude: subString description: aString >> > - shouldnt: aBlock raise: anExceptionalEvent whoseDescriptionIncludes: >> > subString description: aString >> > >> > I honestly cannot wrap my head around these two methods. >> >> They show that the code in the block raises an _informative_ >> exception. So you get a FileNotFound exception... but what was the >> missing file? I don't know! Noone bothered to mention it! >> >> frank >> >

July 9, 2013

Re: [Pharo-dev] the return of the strange methods

by Max Leske

On 09.07.2013, at 17:42, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > They may be useful. Imagine you are too lazy to create a subclass of Error, but not lazy enough to create a test and copy paste a String. > Then you write in your method: > self error: 'some strange error happened' > And you can test it: > self shouldnt: [ "some strange code" ] raise: Error whoseDescriptionIncludes: 'some strange error happened' description: 'the strange error did not happen ! That's strange' > > Seriously, as you saw these methods are used only in their tests. I guess you can remove them. Open fogz bug ? +1 > > > 2013/7/9 Frank Shearar <frank.shearar(a)gmail.com> > On 9 July 2013 16:24, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > Survey: who uses the following methods? and if yes why? > > > > - shouldnt: aBlock raise: anExceptionalEvent whoseDescriptionDoesNotInclude: subString description: aString > > - shouldnt: aBlock raise: anExceptionalEvent whoseDescriptionIncludes: subString description: aString > > > > I honestly cannot wrap my head around these two methods. > > They show that the code in the block raises an _informative_ > exception. So you get a FileNotFound exception... but what was the > missing file? I don't know! Noone bothered to mention it! > > frank > >

July 9, 2013

Re: [Pharo-dev] [ANN] Amber 0.11.0 released!

by Norbert Hartl

Cool. I like the more frequent releases. And I'm happy that within the next two weeks I'll be able to work on it again. Norbert Am 09.07.2013 um 16:25 schrieb Nicolas Petton <petton.nicolas(a)gmail.com>: > Amber 0.11.0 released! > > * About the release > > Three months have passed and we are happy to announce the release > of Amber 0.11.0! > > Some numbers about this release: 433 commits by 13 committers, > increasing the number of core committers to 25. 50 unit tests > were added to the kernel, bringing us to 313 unit tests in total. > Since the last release 60 issues were closed, bringing us to 499 > issues closed. > > This release includes a lot of bug fixes, improvements to the > CLI, as well as a preview of the next IDE, named Helios. Amber > now also uses a CI server [1]. > > To try the Helios, the new IDE, open the helios.html page, or > evaluate in any other amber page `amber.loadHelios()`. > > The compiler also received some improvements, especially > regarding message send optimisations and super sends. > > Here's the list of commits and closed issues: > https://github.com/amber-smalltalk/amber/commits/master > https://github.com/amber-smalltalk/amber/issues?direction=desc&sort=updated… > > There is a lot more to come with Helios, a stepping debugger > based on the AST is in progress and currently in the 'debugger' > branch on GitHub. > > * Installing Amber from NPM > > To install amber from NPM, run > > npm install amber > > > * Migration from Amber 0.10.0 > > Amber compiled code should be compatible with Amber 0.10.0, but > recompiling is needed in order to get contexts working: > > Compiler new recompile: (Package named: 'MyPackage') classes. > (Package named: 'MyPackage') commit > > > * API changes > > 0.11.0: > > * AnnouncementSubscription use #valuable: instead of #block: (deprecated) > * AbstractCodeGenerator inherits from Object, not NodeVisitor > * Object>>printString > * replace >>printString with >>printOn: > * replace >>storeString with >>printString > * PackageLoader is now PackageHandler (>>commit: >>setupPackagenamed:prefix: >>ajaxPutAt:data: > * Package>>fetch: is now Package>>load: > * Package>>fetch:prefix: is now Package>>load:prefix: > * Queue>>front replaced by Queue>>next > * Queue>>frontIfAbsent: replaced by Queue>>nextIfAbsent: > * Queue>>back: replaced by Queue>>nextPut: > * smalltalk.addMethod() does not use explicit JS selector > * JSObjectProxy>>canForwardMessage: replaced by use of JSObjectProxy>>lookupProperty: with asJavaScriptSelector > * JSObjectProxy>>forwardMessage: replaced by explicit JSObjectProxy>>forwardMessage:withArguments: > * String>>asJavaScriptSelector moved to Kernel-Objects package > > + Object>>asString > + Object>>putOn: > + String>>isVowel > + Collection>>putOn: > + CharacterArray>>putOn: > + Stream>><< > + Stream>>write > + SequenceableCollection>>newStream > + SequenceableCollection>>readStream > + SequenceableCollection>>stream > + SequenceableCollection>>streamClass > + SequenceableCollection>>writeStream > + Collection>>isImmutable > + Stream>>nextPutString: > + StringStream>>nextPutString: > + JSStream>>nextPutClassRefFunction: > + String>>crlfSanitized > + inlined Block now also responds to >>value: > + Parser: split literal into runtimeLiteral and parseTimeLiteral > + Parser: write #(4 #(5 6 #()) 7) as #(4 (5 6 ()) 7) > + Parser: write #(#on:do: #Object) as #(on:do: Object) > + Parser: Symbols for binarie selectores > + Package>>commit > + AIContext>>initializeLocals > + ASTInterpreter>>withBlockContext: > + smalltalk.allSelectors() > + Object>>isCompiledMethod > + Object>>isPackage > + Object>>isBehavior > + ClassMoved Announcemen class > + Behavior>>includesBehavior: > + Environment>>classes > + Environment>>allSelectors > + Environment>>removeProtocol: > + Environment>>renameProtocol:to:in: > + CompiledMethod>>protocol: > + Smalltalk>>globalJsVariables > + Smalltalk>>addGlobalJsVariable: > + Smalltalk>>deleteGlobalJsVariable: > > > - Object>>storeOn: > - Object>>log:block: > - Object>>printNl > - Compiler-IR.st >>javascriptSelector > - Compiler-IR.st >>nextPutVar: > - Kernel-Collections.st >>asSuperSelector > - Collection>>readStream > - Collection>>stream > - Collection>>streamClass > - Collection>>writeStream > - Symbol class (replaced with String) > - IRInlinedNonLocalReturn class > - IRInlinedSend>>nonLocalReturnInliner > - IRNonLocalReturnInliner class > - Package>>dependencies > - Package>>dependencies: > - Package>>properties > - Package>>jsProperties > - Package>>jsProperties: > - Package>>propertiesAsJSON > - Package>>propertyAt: > - Package>>propertyAt:ifAbsent: > - Package>>propertyAt:put: > - Browser>>ajaxPutAt:data: > > > We hope you join us in developing Amber and having fun! Fork at > github, join in #amber-lang on freenode and hop onto the mailing > list. > > The Amber crew > > [1] https://travis-ci.org/amber-smalltalk/amber

July 9, 2013