April 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Help fixing tests

by Mariano Martinez Peck

In Pharo core, it is sometimes green and sometime yellow I put some flags and see this: cdNO: 3933 clsNo: 1955 metaclsNo: 1977 clsNo + metaclsNo: 3932 ------------------------------- cdNO: 3935 clsNo: 1956 metaclsNo: 1978 clsNo + metaclsNo: 3934 ------------------------------- cdNO: 3937 clsNo: 1957 metaclsNo: 1979 clsNo + metaclsNo: 3936 ------------------------------- cdNO: 3938 clsNo: 1958 metaclsNo: 1980 clsNo + metaclsNo: 3938 ------------------------------- cdNO: 3941 clsNo: 1959 metaclsNo: 1981 clsNo + metaclsNo: 3940 ------------------------------- cdNO: 3943 clsNo: 1960 metaclsNo: 1982 clsNo + metaclsNo: 3942 ------------------------------- cdNO: 3945 clsNo: 1961 metaclsNo: 1983 clsNo + metaclsNo: 3944 ------------------------------- cdNO: 3947 clsNo: 1962 metaclsNo: 1984 clsNo + metaclsNo: 3946 ------------------------------- On Fri, Apr 10, 2009 at 9:06 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > I think this is related to what Lukas said in the other mail. I can > reproduce what Sted says in Pharo core, but in last pharo-dev, it works ok. > I tried to run several times the tests but are green all the time. > > Cheers, > > Mariano > > > On Fri, Apr 10, 2009 at 4:28 PM, Damien Cassou <damien.cassou(a)gmail.com>wrote: > >> issue #727 >> >> On Fri, Apr 10, 2009 at 7:27 PM, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr> wrote: >> > When running the kernelTest-Classes >> > testClassDescriptionallSubInstances is yellow but when run >> > individually green. >> > >> > Anybody want to look at it? >> > >> > Stef >> > >> > _______________________________________________ >> > Pharo-project mailing list >> > Pharo-project(a)lists.gforge.inria.fr >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >> >> >> >> -- >> Damien Cassou >> http://damiencassou.seasidehosting.st >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >

April 11, 2009

Re: [Pharo-project] Multiple issues with class definition

by Marcus Denker

On 10.04.2009, at 11:29, Igor Stasenko wrote: > 2009/4/10 Marcus Denker <denker(a)acm.org>: >> >> On 10.04.2009, at 05:34, Igor Stasenko wrote: >> >>> Another funny thing that i found, that you can actually do: >>> >>> | string | >>> string := 'Blabla'. >>> Object subclass: string >>> instanceVariableNames: '' >>> classVariableNames: '' >>> poolDictionaries: '' >>> category: 'Whatever'. >>> >>> Smalltalk at: string " returns a class you just defined." >>> >> >> Yes, reflectively generating classes is what the browser does. And in >> addition, >> it is useful for tests. Or in general meta-programming tricks of the >> evil kind. >> (e.g. eToys used it to create on-the-fly classes for it's prototype- >> like object >> model. In most of these cases, it is better to use anonymous >> Behaviors, than you don't >> see them in the browser at all). >> > > Right, but for common case, this should be errorneous? No? > At least Smalltalk>>#at:put: should check that key is symbol. > Ups. I did not realize the string vs. symbol problem... I blame that on the jet-lag ;-) Maybe Smalltalk>>#at:put: could do an #asSymbol? But in general, the whole structural model is not checked too much for consistency. If you do wrong, it will be wrong. Marcus -- Marcus Denker - http://marcusdenker.de PLEIAD Lab - Computer Science Department (DCC) - University of Chile

April 11, 2009

Re: [Pharo-project] Help fixing tests

by Mariano Martinez Peck

I think this is related to what Lukas said in the other mail. I can reproduce what Sted says in Pharo core, but in last pharo-dev, it works ok. I tried to run several times the tests but are green all the time. Cheers, Mariano On Fri, Apr 10, 2009 at 4:28 PM, Damien Cassou <damien.cassou(a)gmail.com>wrote: > issue #727 > > On Fri, Apr 10, 2009 at 7:27 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: > > When running the kernelTest-Classes > > testClassDescriptionallSubInstances is yellow but when run > > individually green. > > > > Anybody want to look at it? > > > > Stef > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 11, 2009

Re: [Pharo-project] i can has TestCase>>#assert:equals: ?

by Damien Cassou

On Fri, Apr 10, 2009 at 9:06 PM, Oscar Nierstrasz <oscar(a)iam.unibe.ch> wrote: > 90% of my tests just test equality of a result to an expected value, > so I waste time trying to find out what the mismatch is. Â Would be > nice to have this method in SUnit: > > assert: result equals: expected > Â result = expected > Â Â ifFalse: [self signalFailure: 'Assertion failed: (' , result > asString , ') ~= (' , expected asString , ')'] > > Does anyone see a downside, or possible improvements? No, there is no downside and no possible improvement. All other xUnit frameworks have that for a long time. I think Keith's version of SUnit has that too. -- Damien Cassou http://damiencassou.seasidehosting.st

April 10, 2009

Re: [Pharo-project] i can has TestCase>>#assert:equals: ?

by Michael Roberts

I have used something similar elsewhere. +1 in general. The only gotcha is making sure people don't use it for comparing doubles. If there are not methods already I would add some form of assert:equals:tolerance: or something like that. cheers, Mike On Fri, Apr 10, 2009 at 8:06 PM, Oscar Nierstrasz <oscar(a)iam.unibe.ch> wrote: > > Hi folks, > > 90% of my tests just test equality of a result to an expected value, > so I waste time trying to find out what the mismatch is. Â Would be > nice to have this method in SUnit: > > assert: result equals: expected > Â result = expected > Â Â ifFalse: [self signalFailure: 'Assertion failed: (' , result > asString , ') ~= (' , expected asString , ')'] > > Does anyone see a downside, or possible improvements? > > - on > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 10, 2009

Re: [Pharo-project] MessageTally a bit broken due to closure

by Damien Cassou

Issue #726 On Fri, Apr 10, 2009 at 7:28 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > was working before closure > Â Â Â Â MessageTally tallySends: [3.14159 printString] > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Damien Cassou http://damiencassou.seasidehosting.st

April 10, 2009

Re: [Pharo-project] Help fixing tests

by Damien Cassou

issue #727 On Fri, Apr 10, 2009 at 7:27 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > When running the kernelTest-Classes > testClassDescriptionallSubInstances is yellow but when run > individually green. > > Anybody want to look at it? > > Stef > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Damien Cassou http://damiencassou.seasidehosting.st

April 10, 2009

[Pharo-project] i can has TestCase>>#assert:equals: ?

by Oscar Nierstrasz

Hi folks, 90% of my tests just test equality of a result to an expected value, so I waste time trying to find out what the mismatch is. Would be nice to have this method in SUnit: assert: result equals: expected result = expected ifFalse: [self signalFailure: 'Assertion failed: (' , result asString , ') ~= (' , expected asString , ')'] Does anyone see a downside, or possible improvements? - on

April 10, 2009

Re: [Pharo-project] SUnit GUI

by Lukas Renggli

> is it normal that when one doubleclick on an yellow item in the list > it does not open a debugger? No, that's not normal. Right now I can think of two possible causes: - The test is not deterministic or has side effects that cause it to sometimes fail and sometimes pass. - Another reason that I recently noticed is related to exceptions and how SUnit runs the tests. When a test is run (when you click on run) the code is wrapped into an [ ... ] on: Error do: ..., thus catching all exceptions. When a test is debugged (when you click on an item on the list) the code is not wrapped in such a handler assuming that this would cause the system to open a debugger. However, depending on the exception raised this causes a custom default action to be evaluated and the test does not fail anymore. Many file-related exceptions have such a default behavior. Oscar recently reported an issue on this: <http://code.google.com/p/pharo/issues/detail?id=698>. I wonder why this only appeared now? Was there anything changed related to SUnit or Exceptions? Lukas -- Lukas Renggli http://www.lukas-renggli.ch

April 10, 2009

[Pharo-project] SUnit GUI

by StÃ©phane Ducasse

lukas is it normal that when one doubleclick on an yellow item in the list it does not open a debugger? Stef

April 10, 2009