John M McIntosh wrote:
At 4:01 AM +0100 12/28/01, Stephan Rudlof wrote:
Which source code? The ST #assert: throws an exception and therefore halts the program, what is quiet similar to my assert (I admit that the ST one is not as radical).
I don't want to ride the horse to death (correct?). If you and others are lucky with it, let it be #sqAssert:. But then populate please (e.g. by ST and/or Swiki docu), that it is *forbidden* to use an assert() function like the ST #assert: in Slang, since it would conflict with the Unix one (after C code generation). Otherwise others could easily walk into the same trap (mostly it would work with their platform, but not with all).
Is this a compromise?
Yes, it's quite workable. Now if someone wants to resubmit a change set to clean this up, that would be great.
Note the usages below.
It would seem that BalloonEngineSimulation>>assert: should really use the Object>>assert: which means some changes because one expects a block, the other a boolean. Which is correct is a question? SUnit expects a boolean, perhaps our usage on Object as a block should change to avoid confusion.
Perhaps a better name for the plugin assert is sqPluginAssert? I'm also assuming this could be folded into InterpreterPlugin? Printing a message, is ok, but I wonder if we want to also print a stack trace too before doing the exit(1), or is that a primitiveFail and return we want (I suspect so?) This implies doing a return will be ok, or do we need sqPluginAssertExit & sqPluginAssertReturn?
TestCase>>assert: aBoolean aBoolean ifFalse: [self signalFailure: 'Assertion failed']
Object>>assert: aBlock "Throw an assertion error if aBlock does not evaluates to true."
aBlock value ifFalse: [AssertionFailure signal: 'Assertion failed']
BalloonEngineSimulation>>assert: bool bool ifFalse:[^self error:'Assertion failed'].
LargeIntegersPlugin>>assert: aBool self debugCode: [aBool ifFalse: [self msg: 'Assertion failed!'. self cCode: 'exit(1)' inSmalltalk: [interpreterProxy primitiveFail. self halt]]. ^ true]
My last [ENH] suggestion was to kick this >>assert: and to use a modified one: TestInterpreterPlugin>> sqAssert: aBool self debugCode: [aBool ifFalse: [self error: 'Assertion failed!']. ^ aBool]
This eliminates any assert() calls in production code and results in an exit() call (see error() in interp.c) with call stack printing for debug code.
See TIPlugin-cleanup-sr.1.cs.gz in mail subjected [ENH] TestInterpreterPlugin-cleanup-sr .
For me this is a simple variant for developer code and *documentation* purposes (>>sqAssert:'s say something about the semantics of the code!). The question remains if it makes sense to provide a more complicated variant with >>primitiveFail semantics. For me the simple one is at least a good start.
Greetings,
Stephan
--
=========================================================================== John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================