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