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

Re: [Pharo-dev] PhExample repository

by Tudor Girba

On Jul 10, 2013, at 2:50 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > Which one is the right repository? > > http://smalltalkhub.com/#!/~PharoExtras/Phexample > > or > > http://smalltalkhub.com/#!/~Phexample/Phexample This one. Doru > And if they are copies of each other could you please change one of those to include a comment/pointer that the other one is in use? > > Norbert > -- www.tudorgirba.com "One cannot do more than one can do."

July 10, 2013

PhExample repository

by Norbert Hartl

Which one is the right repository? http://smalltalkhub.com/#!/~PharoExtras/Phexample or http://smalltalkhub.com/#!/~Phexample/Phexample And if they are copies of each other could you please change one of those to include a comment/pointer that the other one is in use? Norbert

July 10, 2013

Re: [Pharo-dev] sunit failures vs errors

by Tudor Girba

Hi, On Jul 10, 2013, at 1:47 PM, 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? In the sense that they express two distinct classes of problems. > As a programmer I have to tackle them both the same way: start debugging. Yes, but not all debugging is created equal :) > 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. Yes, but then what is the point of explicit assertions? :) > Tackling the failures first is purely a habit induced by the existing system that errors are worse than failures Actually, it is the other way around :). Errors are much faster to fix than failures. Errors are often caused by bad initializations and you can see it rather fast when you see the exceptions. On the other hand, failures are often more sensitive to the deep semantics of your code and that is why they require more time to get fixed. Cheers, Doru -- www.tudorgirba.com "Presenting is storytelling."

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=mac/… 1 regressions found. Tests.CodeImport.ChunkImportTestCase.testImportAClassCategory

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=win/… 1 regressions found. Zinc.Tests.ZnServerTests.testEntityTooLarge

July 10, 2013

Re: [Pharo-dev] sunit failures vs errors

by HernÃ¡n Morales Durand

Error â defect in the human thought process made while trying to understand given information, solve problems, or to use methods and tools. In the context of software requirements specifications, an error is a basic misconception of the actual needs of a user or customer. Fault â concrete manifestation of an error within the software. One error may cause several faults, and various errors may cause identical faults. Failure â departure of the operational software system behavior from user expected requirements. A particular failure may be caused by several faults and some faults may never cause a failure. IEEE Std 610.12-1990, IEEE Standard Glossary of Software Engineering Terminology, 1990. A systematic literature review to identify and classify software requirement errors. Gursimran Singh Walia, Jeffrey C. Carver. Information and Software Technology, 2009. El 10/07/2013 8:47, Camillo Bruni escribiÃ³: > 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] sunit failures vs errors

by Frank Shearar

On 10 July 2013 13:18, Camillo Bruni <camillobruni(a)gmail.com> wrote: > On 2013-07-10, at 14:09, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> 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. > > Exactly, in the end you can perfectly deduce the type of failing test by the thrown error, no? "In the end" isn't the same as being able to prioritise debugging. Most people think (judging by the participants in this thread at least) that unexpected test failures - errors - are more important than mere failures. frank

July 10, 2013

Re: [Pharo-dev] [update 3.0] #30263

by Marcus Denker

On Jul 10, 2013, at 2:06 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > 30263 > ----- > > 11142 For 3.0: 11102 FileSystemError > https://pharo.fogbugz.com/f/cases/1114 > This seems to fail on the mac, and the windows build is not finishing since 14minutes. I think I will revert the update. Marcus

July 10, 2013

Re: [Pharo-dev] sunit failures vs errors

by Camillo Bruni

On 2013-07-10, at 14:09, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > 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. Exactly, in the end you can perfectly deduce the type of failing test by the thrown error, no?

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=mac/… 2 regressions found. Tests.Polymorph.Widgets.FileDialogWindowTest.testIssue6406 Tests.Release.ReleaseTest.testObsoleteClasses

July 10, 2013