Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!cornell!batcomputer!itsgw!steinmetz!uunet!dalcs!aucs!831059l
From: 831059l@aucs.UUCP (Langlois)
Newsgroups: comp.lang.smalltalk
Subject: Differencs between Smalltalk/V and Smalltalk/V286
Message-ID: <1424@aucs.UUCP>
Date: 4 Dec 88 21:41:27 GMT
Reply-To: 831059l@aucs.UUCP (Langlois)
Organization: School of Computer Science, Acadia Univ., Nova Scotia
Lines: 88


	As I mentioned in an earlier posting, I had a few problems getting
a small working simulation in Smalltalk/V to work in Smalltalk/V286. Quite
simply, the same class and methods that worked in Smalltalk/V didn't work
in Smalltalk/V286. The main loop which kept the simulation going in 
Smalltalk/V was in method proceed in class Simulation was as follows:

	proceed
	    [eventQueue isEmpty]
	        whileFalse: [currentEntity := eventQueue removeFirst.
	                     time := currentEntity time.
	                     currentEntity semaphore signal]

Looking at this method you might think that I would have to give up the 
processor at some point in the whileFalse: message to let the entities that
are signalled get a change to execute. That is what I thought also when I 
first implemented the method proceed. I wanted to see what happened if I 
didn't give up the processor so I removed an expression after the last in
the block which sent yield to Processor. In Smalltalk/V it still worked so
I permanently removed the expression because, why send it if it doesn't make
any difference. In Smalltalk/V286 the Processor must be told to yield the
current process for the simulation to work properly, so proceed must be
changed as follows:

	proceed
	    [eventQueue isEmpty]
                 whileFalse: [currentEntity := eventQueue removeFirst.
                              time := currentEntity time.
                              currentEntity semaphore signal.
			      Processor yield]

	Now, if your curious as to how I found this out, well I executed 
the simulation under the new V286 debugger and it worked just fine. I tried
it again without the debugger and it didn't work. When the debugger steps
through the code it must give each process waiting a change to execute,      
taking in account priority and the amount of time spent waiting, every time
it passes control to a process and then interrupts again. In Smalltalk/V
when a semaphore is signalled, the processor must be sent the message yield
to give the process that was signalled a change to take over the processor.
In Smalltalk/V286 this must not be the case, the current process continues
to execute until you tell it to give up the processor.

	The following code also worked fine in Smalltalk/V but caused a
debugger window to pop up with the label "value" not understood:

	probabilityTrue: theProbability
	    theProbability < 0.0 | theProbability > 1.0
	        ifTrue: [self error: 'Probability must be >= 0.0 and <= 1.0']
	        ifFalse: [^self new setProbability: theProbability]

The or "|" causes problem. In Smalltalk/V286, an instance of class False
tries to send the message or: with the argument theProbability which is
then sent the message value which is does not understand because it is
an instance of class Float = 0.5. Smalltalk/V286 routes the shorthand
for "|" through the or: selector while in Smalltalk/V this is not done.
or: is implemented as follows:

	or: aBlock
	    ^aBlock value

I inserted a self halt in this message in Smalltalk/V to try and intercept
but the self halt was never executed. Smalltalk/V either has different order
of evaluation or uses another way to implement "|". By changing the precedence
with parentheses as follows, Smalltalk/V286 can execute the method correctly:
 
	probabilityTrue: theProbability
	    (theProbability < 0.0) | (theProbability > 1.0)
	        ifTrue: [self error: 'Probability must be >= 0.0 and <= 1.0']
	        ifFalse: [^self new setProbability: theProbability]

In Smalltalk/V the evaluation seems to have the two comparisons execute first
and then the result of the second is sent to the first. In Smalltalk/V286
a strict left to right evaluation seems to occur.

	I read the back of the Smalltalk/V286 manual and under the heading
"What is Smalltalk/V 286?" one the items was "Compatibility with Smalltalk/V,
the PC version."
	These are the only differences I have noticed or cared about because
they affected my work. Other than the headache of having to find things like
this, Smalltalk/V 286 is much better than its predecessor.

Steven Langlois     UUCP:     {uunet|watmath|utai|garfield}!dalcs!aucs!831059l
Acadia University   BITNET:   Steven@Acadia
Wolfville, NS       Internet: Steven%Acadia.BITNET@CUNYVM.CUNY.EDU
CANADA  B0P 1X0