- Pharo-dev - lists.pharo.org

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

by Alexandre Bergel

SUnit should have this methods for years Alexandre On 10 Apr 2009, at 21:06, Oscar Nierstrasz 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 > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 11, 2009

Re: [Pharo-project] status of split join in pharo

by Oscar Nierstrasz

Hi Syef, ;-) I am going over the two split-join implementations, merging functionality, generalizing and making the interfaces consistent. About your proposal: splitOn: should always return an OrderedCollection containing elements of the same type as the receiver. 'banana' splitOn: 'an' -> an OrderedCollection('b' '' 'a') It doesn't make sense for this to return a String. When joining, of course the original type should be returned no matter what kind of sequenceable collection was split. I am preparing tests for all the cases. - on On Apr 5, 2009, at 10:33, StÃ©phane Ducasse wrote: > then I have a question what splitBy: returns? > does it return a collection that is the same kind of the receiver? > Why do you hard code an OrderedCollection in splitBySubCollection: > aSplitter. > self species would do it too? > Syef

April 11, 2009

Re: [Pharo-project] Help fixing tests

by John M McIntosh

In my past dealings with insanity like this is that Sunits for a test case run technically in no particular order. However if you have cases where a test case A alters things for B, then you get failure if B runs before A. The order is dependent on how the set is created. Also there can be issues if things like File Handles are over- allocated and you then rely on finalization to fix things, which could interfere with things er it's hard to explain, but once you see it, you know. Technically this should not be a problem but as you see well something is funky. What I'd suggest is print the context at the point of error in the SUnit error handler so you can get some understanding of the failure case. Smalltalk logError:'Fatal error: Sunit Fialed' inContext: thisContext to: 'SqueakDebugXXXX.log'. I also altered errorReportOn: to slop more data out, in Tweak based system it's not uncommon to have stack nesting of > 100 methods. Never can have enough debug data at hand. Contextpart>>errorReportOn: strm "Write a detailed error report on the stack (above me) on a stream. For both the error file, and emailing a bug report. Suppress any errors while getting printStrings. Limit the length." | cnt aContext startPos | strm print: Date today; space; print: Time now; cr. strm cr. strm nextPutAll: 'VM: '; nextPutAll: SmalltalkImage current platformName asString; nextPutAll: ' - '; nextPutAll: SmalltalkImage current platformSubtype asString; nextPutAll: ' - '; nextPutAll: SmalltalkImage current osVersion asString; nextPutAll: ' - '; nextPutAll: SmalltalkImage current vmVersion asString; cr. strm nextPutAll: 'Image: '; nextPutAll: SystemVersion current version asString; nextPutAll: ' ['; nextPutAll: SmalltalkImage current lastUpdateString asString; nextPutAll: ']'; cr. strm cr. SecurityManager default printStateOn: strm. "Note: The following is an open-coded version of ContextPart>>stackOfSize: since this method may be called during a low space condition and we might run out of space for allocating the full stack." cnt := 0. startPos := strm position. aContext := self. [aContext notNil and: [(cnt := cnt + 1) < 40]] whileTrue: [aContext printDetails: strm. "variable values" strm cr. aContext := aContext sender]. strm cr; nextPutAll: '--- The full stack ---'; cr. aContext := self. cnt := 0. [aContext == nil] whileFalse: [cnt := cnt + 1. cnt = 40 ifTrue: [strm nextPutAll: ' - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -'; cr]. strm print: aContext; cr. "just class>>selector" strm position > (startPos+150000) ifTrue: [strm nextPutAll: '...etc...'. ^ self]. "exit early" cnt > 200 ifTrue: [strm nextPutAll: '-- and more not shown --'. ^ self]. aContext := aContext sender]. On 10-Apr-09, at 5:19 PM, Mariano Martinez Peck wrote: > In Pharo core, it is sometimes green and sometime yellow > > I put some flags and see this: > \\ -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ======================================================================== -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

April 11, 2009

Re: [Pharo-project] Closure compiler

by Michael van der Gulik

On 4/9/09, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> >>> New name: yes. >> >> Umm... HannanCompiler (after the original author?). > > umm..... rot and dead compiler that marcus resurrected That was an inappropriate and unhelpful comment. Gulik. -- http://gulik.pbwiki.com/

April 11, 2009

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