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

Re: [Pharo-dev] sunit failures vs errors

by Sven Van Caekenberghe

Maybe we should not throw away the distinction, I am used to it as well. But what Camillo means, I think, is that in the end it does not matter. For example, if I have a unit test for some object's #printString both the case where is does no longer return what I expect and the case that it suddenly throws an error mean the same thing: the object's #printString is broken. Sven On 10 Jul 2013, at 13:55, Frank Shearar <frank.shearar(a)gmail.com> wrote: > On 10 July 2013 12:47, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> On 2013-07-10, at 13:32, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>> Precisely. There is a huge difference between invalidating a known contract (i.e., failure) and raising an unexpected error (i.e., error). >> >> In which sense? >> As a programmer I have to tackle them both the same way: start debugging. >> >> I really do not see the difference. In both cases the code does not behave as expected. > > Yes, you do need to approach the problem in the same way - open the > debugger - but I don't think that's sufficient reason to lose the > distinction. Implementing a new feature also involves opening a > debugger, but we keep the distinction between "writing new code" and > "debugging existing code". > >> One might even say that there is a global contract that the code does not raise exceptions. > > That last part's not true. I don't know what "global" means, but lots > of code will explicitly have as its contract "halt and catch fire". > >> Tackling the failures first is purely a habit induced by the existing system that errors are worse than failures > > Maybe, but it's still a useful distinction. "Oh, this feature broke" > isn't the same as "hang on, that's a brand new bug". > > frank >

July 10, 2013

[update 3.0] #30263

by Marcus Denker

30263 ----- 11142 For 3.0: 11102 FileSystemError https://pharo.fogbugz.com/f/cases/1114 10466 Better interruption https://pharo.fogbugz.com/f/cases/10466 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Morphic-Base-MarcusDenker.42.… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Kernel-MarcusDenker.1514.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/FileSystem-Disk-MarcusDenker.… http://smalltalkhub.com/mc/Pharo/Pharo30/main/FileSystem-Core-MarcusDenker.…

July 10, 2013

Re: [Pharo-dev] sunit failures vs errors

by Frank Shearar

On 10 July 2013 12:47, Camillo Bruni <camillobruni(a)gmail.com> wrote: > On 2013-07-10, at 13:32, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> Precisely. There is a huge difference between invalidating a known contract (i.e., failure) and raising an unexpected error (i.e., error). > > In which sense? > As a programmer I have to tackle them both the same way: start debugging. > > I really do not see the difference. In both cases the code does not behave as expected. Yes, you do need to approach the problem in the same way - open the debugger - but I don't think that's sufficient reason to lose the distinction. Implementing a new feature also involves opening a debugger, but we keep the distinction between "writing new code" and "debugging existing code". > One might even say that there is a global contract that the code does not raise exceptions. That last part's not true. I don't know what "global" means, but lots of code will explicitly have as its contract "halt and catch fire". > Tackling the failures first is purely a habit induced by the existing system that errors are worse than failures Maybe, but it's still a useful distinction. "Oh, this feature broke" isn't the same as "hang on, that's a brand new bug". frank

July 10, 2013

Re: [Pharo-dev] sunit failures vs errors

by Camillo Bruni

On 2013-07-10, at 13:32, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Precisely. There is a huge difference between invalidating a known contract (i.e., failure) and raising an unexpected error (i.e., error). In which sense? As a programmer I have to tackle them both the same way: start debugging. I really do not see the difference. In both cases the code does not behave as expected. One might even say that there is a global contract that the code does not raise exceptions. Tackling the failures first is purely a habit induced by the existing system that errors are worse than failures

July 10, 2013

Re: [Pharo-dev] [update 2.0] #20612

by Tudor Girba

Thank you! Doru On Jul 10, 2013, at 10:36 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > 20612 > ----- > > 10569 Backport 2.0: Better Interrruptionche > https://pharo.fogbugz.com/f/cases/10569 > > 10940 Backport 2.0: 10925 Use caching in Gofer > https://pharo.fogbugz.com/f/cases/10940 > > Diff information: > http://ss3.gemstone.com/ss/Pharo20/Monticello-MarcusDenker.782.diff > http://ss3.gemstone.com/ss/Pharo20/Kernel-MarcusDenker.1350.diff > http://ss3.gemstone.com/ss/Pharo20/Gofer-Core-MarcusDenker.194.diff > > -- www.tudorgirba.com "What is more important: To be happy, or to make happy?"

July 10, 2013

Re: [Pharo-dev] sunit failures vs errors

by Tudor Girba

Precisely. There is a huge difference between invalidating a known contract (i.e., failure) and raising an unexpected error (i.e., error). Please do not do away with this distinction. Cheers, Doru On Jul 10, 2013, at 10:34 AM, Damien Cassou <damien.cassou(a)gmail.com> wrote: > > On Wed, Jul 10, 2013 at 8:16 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > I use them. I always fix the red tests first because they are mostly easier to fix and some of them lead to yellow tests > > I agree with you. I tend to do that as well. > > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without losing enthusiasm." > Winston Churchill -- www.tudorgirba.com "Beauty is where we see it."

July 10, 2013

Re: [Pharo-dev] [Vm-dev] Re: thisContext usecases

by Igor Stasenko

On 10 July 2013 00:03, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > On Tue, Jul 9, 2013 at 1:27 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> On 9 July 2013 10:15, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: >> > Hello pharoers, >> > >> > Recently I have been looking at the Pharo thisContext capabilities, in order >> > to perhaps one day in the far future edit its implementation with the Pharo >> > dev team. Nothing is planned or confirmed, it is just to discuss. >> > >> > A context has instances variables (method closureOrNil receiver stackp >> > sender pc) and holds the arguments and temporaries. >> > >> > Now I'd like to know what context's state do we modify, and what states are >> > just internal representations ? >> > >> > For example, it seems that you can do 'thisContext receiver: #foo', but you >> > cannot with Cog. >> > >> > SomeClass>>foo >> > thisContext receiver: #foo. >> > ^ self >> > >> > In workspace, evaluating: >> > 1 to: 5 do: [:i | Transcript show: SomeClass new foo ] >> > >> > Transcript result (with Cog): >> > foo >> > foo >> > a SomeClass >> > a SomeClass >> > a SomeClass >> > >> > Transcript result (with Stack or Vanilla): >> > foo >> > foo >> > foo >> > foo >> > foo >> > >> > Now as no one has ever complained, I guess this feature is not used. >> > >> > As far as I know, the real use cases of the context seems to be: >> > - setting and gettings temporaries >> > - setting and getting the sender of a context >> > - setting and getting the pc >> > - getting method, closureOrNil, receiver, stackp, arguments but NOT setting >> > them >> > >> > Now setting the sender of a context seems to be used only in two cases: >> > - continuations (as seaside continuations) >> > - exception implementation >> > >> > So imagine that in the future you would have a context that can be accessed >> > in read-only, where you could only: >> > - set the temporaries (but not arguments) >> > - set the pc (or something equivalent, as set the currently executed ast >> > node) >> > - use continuations (exceptions can be implemented on top of continuations) >> > >> > I would like to know if there are things that you do now and that you would >> > not be able to do with a context like that. For non meta developer (like >> > enterprise app developer) I guess it will not change anything, but I want to >> > know if you implemented a framework as seaside, does it requires other >> > things from the context and why ? >> > >> >> To my thinking playing with pc is awfully evil, it should be >> read-only, only to allow debugger >> to map it to source code. Same goes for stack pointer. > > > There are good uses for this I just used it to implement basic-block coverage for methods. One can use it for exception handling (mustBeBoolean etc). I'm always wary of introducing restrictions when the system has worked fine without them for years. One exception recently was in adding bounds checking to CompiledMethod>>at:put: so one could not change arbitrary bytes in the literals via at:put:. But this was adding safety, not adding a restriction. I see no harm in allowing one to assign the pc. It is unsafe, and the system will likely crash if you get it wrong. But it is also potentially useful (e.g. I've used it to do a prototype of tail-recursion elimination). So let's be laissez faire, unless the freedoms in question really do only do harm. > Apparently one should know what he doing, when assigning to context's pc. And that's the reason why it considered 'evil' :) To me this is strange way to program: context just reflecting activation of your program, so if you changing pc, you changing the flow of your program. Isn't it would be wiser in such case to just change the original program to make it behave like you want, instead of hacking it via setting context's pc? Of course, there is exceptions like tail-recursion elimination, which you cannot implement by changing code in your program. > >> >> >> Setting receiver is less evil and it may work, if receiver belongs to >> same inheritance chain >> as compiled method's class. But it should not be set without checking this. >> >> And for method's temps, it is fine. >> >> > Thanks for answering, >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > > > > -- > best, > Eliot > -- Best regards, Igor Stasenko.

July 10, 2013

Re: [Pharo-dev] should:raise:description:

by Camille Teruel

On 10 juil. 2013, at 11:24, Camillo Bruni wrote: > > On 2013-07-10, at 08:05, Max Leske <maxleske(a)gmail.com> wrote: > >> >> On 09.07.2013, at 23:28, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> >>> >>> On 2013-07-09, at 21:23, Frank Shearar <frank.shearar(a)gmail.com> wrote: >>> >>>> On 9 July 2013 19:45, Camillo Bruni <camillobruni(a)gmail.com> wrote: >>>>> 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 >>>> >>>> In case (a) I would actually expect to see something like: "message. >>>> Unexpected Error raised: 'error message'". >>>> >>>> In case (b) I'd want to see "message: no Halt raised" >>>> >>>> I can't think of why you would want a description for a success case, >>>> so #4 just seems weird! >>> >>> exactly! :) I agree on that ;). Now the question is on how to properly fix this >>> for debugging. Since you actually want to debug on the unexpected Exception in >>> case a)... >> >> >> YESSSS!! That's about the thing I hate the most about SUnit: if a testrun fails because #should: fails, the signaler context is gone. That's SO ANNYOING! > > I managed to solve this by added Exception >> #signalIn: aContext, like that I can signal > an AssertionFailure with the proper error message in place of the original error. so you get > 1) a proper error message in the debugger and test output > 2) the debugger opens at the very place the original exception was signaled :) Excellent !! Have you checked that it doesn't break the create button in case of DNU?

July 10, 2013

Re: [Pharo-dev] should:raise:description:

by Camillo Bruni

On 2013-07-10, at 08:05, Max Leske <maxleske(a)gmail.com> wrote: > > On 09.07.2013, at 23:28, Camillo Bruni <camillobruni(a)gmail.com> wrote: > >> >> On 2013-07-09, at 21:23, Frank Shearar <frank.shearar(a)gmail.com> wrote: >> >>> On 9 July 2013 19:45, Camillo Bruni <camillobruni(a)gmail.com> wrote: >>>> 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 >>> >>> In case (a) I would actually expect to see something like: "message. >>> Unexpected Error raised: 'error message'". >>> >>> In case (b) I'd want to see "message: no Halt raised" >>> >>> I can't think of why you would want a description for a success case, >>> so #4 just seems weird! >> >> exactly! :) I agree on that ;). Now the question is on how to properly fix this >> for debugging. Since you actually want to debug on the unexpected Exception in >> case a)... > > > YESSSS!! That's about the thing I hate the most about SUnit: if a testrun fails because #should: fails, the signaler context is gone. That's SO ANNYOING! I managed to solve this by added Exception >> #signalIn: aContext, like that I can signal an AssertionFailure with the proper error message in place of the original error. so you get 1) a proper error message in the debugger and test output 2) the debugger opens at the very place the original exception was signaled :)

July 10, 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=linu… 1 regressions found. Tests.CodeImport.ChunkImportTestCase.testImportAClassCategory

July 10, 2013