Squeak-dev January 1999

squeak-dev@lists.squeakfoundation.org

143 participants
293 discussions

Re: Bug Involving Modified #to:by:do:
by R. A. Harmon 31 Jan '99

31 Jan '99

At 08:13 PM 1/30/99 -0600, you wrote: >>I also need to change "something" to handle my implementation of >>ScaledDecimal step or by parameters. The following snippet shows an example >>of the odd results currently produced: >> >> | x | x := OrderedCollection new. >> (1/2) to: 5.5s2 by: 2.0 do: [ :n | x add: n]. ^x asArray >> "-> ((1/2) + 2.5 4.5 )" >> >>The Interval elements should all be Float as the default conversion of >>Fraction operation Float is Float. > >I'm not sure why you say they should all be Float. The starting value of >the to:by:do: is the initial value. No operation is performed upon it, >so there is no chance for it to be converted to some other Number class. [snip] My interpretation of the following from the proposed ANSI standard document is that they should all be converted. I'd better confirm this is correct. 5.6.2.39 Message: to: stop by: step do: operation .. . . Definition: <number> .. . . The elements must all conform to either the receiver's or step's protocol, according to the Default Conversion Table. .. . . -- Richard A. Harmon "The only good zombie is a dead zombie" harmonra(a)webname.com E. G. McCarthy

1 0

Subclassing problem in Graphics-Files and MM-Flash-Imports categories.
by Bill Cattey 31 Jan '99

31 Jan '99

Summary: FlashJPEGDecoder gets called from ImageReadWriter with a RWBinaryOrTextStream (or sometimes a StandardFileStream) but is expecting a FlashFileStream in order to find nextByte method. I need a work around for this impossible state of affairs brought on by the unhappy reordering of subclasses brought on by my adding a new subclass to ImageReadWriter in trying to teach Scamper about X bitmaps. Some of these streams define next ^nextByte others define nextByte ^next others leave it to their superclass. I'm very confused, and would be grateful for help out of the maze. Detail: Today I spent many hours trying to figure out why I could not resume play with my XBMReadWriter subclass of ImageReadWriter. The only thing that changed was that I switched from the Sun at the office to the Linux box at home. For some reason, every time I loaded my XBMReadWriter class, ImageReadWriter quit being able to understand gif files. As near as I can tell, by adding the XBMReadWriter I have changed the order of subclassing such that 'ImageReadWriter formFromStream:' now does 'detect' in a toxic order: ImageReadWriter formFromStream: grabs hold of FlashJPEGDecoder because it is the deepest JPEGReadWriter subclass. FlashJPEGDecoder is sent 'understandsImageFormat' it has no such method and goes to its superclass for it. JPEGReadWriter receives 'understandsImageFormat' it sends 'self next'. FlashJPEGDecoder receives the 'next' message. inside 'next' FlashJPEGDecoder sends 'stream nextByte' The stream handed to ImageReadWriter is not a FlashFileStream it has never heard of the nextByte method defined by FlashFileStream. BOOM. Polymorphism eats its tail and collapses upon itself. Any suggestions how to route around this? Interestingly, the error is most often NOT caught by a debugger, but ends up as TEXT in Scamper: "Message not understood: nextByte" in place of the image in the document morph. The lion's share of my time was spent in learning how to thin-slice my way through the debugger with self halt. such that the system would actually choke on the offending code in an observable manner. That time was not wasted, though. I understand rather a LOT more about squeak. Word to the wise: Don't step the debugger across a call to a file readin sub-process. LaLa Land or core dump are the only observed results. I would have had an easier time if I'd taken smaller bites on the problem, and learned how to call ImageReadWriter directly from a workspace. I know how to do that now too. :-) -wdc

1 0

Re: Bug Involving Modified #to:by:do:
by Tim Olson 31 Jan '99

31 Jan '99

>I also need to change "something" to handle my implementation of >ScaledDecimal step or by parameters. The following snippet shows an example >of the odd results currently produced: > > | x | x := OrderedCollection new. > (1/2) to: 5.5s2 by: 2.0 do: [ :n | x add: n]. ^x asArray > "-> ((1/2) + 2.5 4.5 )" > >The Interval elements should all be Float as the default conversion of >Fraction operation Float is Float. I'm not sure why you say they should all be Float. The starting value of the to:by:do: is the initial value. No operation is performed upon it, so there is no chance for it to be converted to some other Number class. >Is there some reason that nextValue should be set before checking for the >error? Will I step on something if I swap it and check for the error before >setting nextValue? Nope; I just did so because it moved all the tests together. -- tim

1 0

Re: Bug Involving Modified #to:by:do:
by R. A. Harmon 31 Jan '99

31 Jan '99

At 09:08 AM 1/30/99 -0600, Tim Olson wrote: >Richard Harmon wrote: > >>I modified Number 'intervals' #to:by:do: method by adding at the beginning: >> >> step = 0 ifTrue: [ >> ^self error: 'step must be non-zero.' >> ]. >> >> >>then evaluated: >> >> 5 to: 1 by: 0 do: [ :n | ^#bogus]. >> >>it returns bogus. > > >Ralph Johnson replied: > >>Traditionally to:do: is optimized by the compiler when you send >>it to a number, so the to:do: method is never called. I bet that >>Squeak does the same thing with to:by:do:. The problem is that >>you are catching the compiler cheating. > > >Yep; there is a hint in the beginning of the method that Richard modified >that states this. Richard, the compiler macro-expansions (inlined code) >are in the MessageNode class (macro transformations category). If you >want to continue to play with this, here is a change to the to:by:do >transformation that causes it to not in-line if the step amount is zero. [change snipped] [embarrassment mode on] I even dutifully incorporated said hint into to my own comments! Thanks for the delicate way you pointed it out. I sometimes get so busy chopping off branches, I don't notice I'm sitting on the one I'm chopping off. What are you going to do with a guy like that? You give him Squeak, comment pitfalls, and he eats the floppy disk! [embarrassment mode off] Thanks for the change. It worked like a champ. I wanted to modify #to:by:do: for ANSI to signal an exception if step is zero. I also need to change "something" to handle my implementation of ScaledDecimal step or by parameters. The following snippet shows an example of the odd results currently produced: | x | x := OrderedCollection new. (1/2) to: 5.5s2 by: 2.0 do: [ :n | x add: n]. ^x asArray "-> ((1/2) + 2.5 4.5 )" The Interval elements should all be Float as the default conversion of Fraction operation Float is Float. I didn't spot anything obvious. Is that "something" going to get REAL complicated or is there a relatively simple fix? Is there some reason that nextValue should be set before checking for the error? Will I step on something if I swap it and check for the error before setting nextValue? !Number methodsFor: 'intervals' stamp: 'tao 1/30/1999 08:58'! to: stop by: step do: aBlock "Normally compiled in-line, and therefore not overridable. Evaluate aBlock for each element of the interval (self to: stop by: step)." | nextValue | nextValue _ self. step = 0 ifTrue: [self error: 'step must be non-zero']. I do appreciate the help folks. -- Richard A. Harmon "The only good zombie is a dead zombie" harmonra(a)webname.com E. G. McCarthy

1 0

Is Squeak tail recursive?
by amoroso＠mclink.it 30 Jan '99

30 Jan '99

Does the Squeak compiler generate properly tail recursive code? Paolo -- Paolo Amoroso <amoroso(a)mclink.it>

2 3

Fixes to InterpreterSimulator for Squeak 2.3
by Greg & Cindy Gritton 30 Jan '99

30 Jan '99

After updating to Squeak 2.3, Squeak would no longer simulate itself using the InterpreterSimulator. I fixed some bugs and it now works for me. There were two bugs: 1. fetchNextBytecode was added to the bytecode methods in the interpreter. However, it was still present in the testStep method in InterpreterSimulator. This resulted in advancing 2 bytes instead of 1. I moved it from testStep to testStart. 2. primitiveShortAt had been added to the interpreter which used inline (textual) C code to get a short from an address. I copied the same method to InterpreterSimulator, changing the C code to a call to halfWordAt:, and added halfWordAt: and halfWordAt:put: to InterpreterSimulator and InterpreterSimulatorLSB. (InterpreterSimulatorLSB is a new class added by Tim Rowledge to simulate Squeak on little-endian systems. It is available at http://sumeru.stanford.EDU/tim/pooters/SqFiles/deltas/VMsimulator.6Nov.cs ) File-ins follow. Greg Gritton gritton(a)ibm.net !InterpreterSimulator methodsFor: 'testing' stamp: 'GVG 1/21/1999 18:26'! test self testStart. [true] whileTrue: [ self testStep]. self testEnd ! ! !InterpreterSimulator methodsFor: 'testing' stamp: 'GVG 1/27/1999 19:57'! testStart Transcript clear. byteCount _ 0. self internalizeIPandSP. currentBytecode _ self fetchByte. ! ! !InterpreterSimulator methodsFor: 'memory access' stamp: 'GVG 1/27/1999 20:47'! primitiveShortAt "Treat the receiver, which can be indexible by either bytes or words, as an array of signed 16-bit values. Return the contents of the given index. Note that the index specifies the i-th 16-bit entry, not the i-th byte or word." | index rcvr sz addr value | index _ self stackIntegerValue: 0. rcvr _ self stackValue: 1. self success: ((self isIntegerObject: rcvr) not and: [self isWordsOrBytes: rcvr]). successFlag ifFalse: [ ^ nil ]. sz _ ((self sizeBitsOf: rcvr) - BaseHeaderSize) // 2. "number of 16-bit fields" self success: ((index >= 1) and: [index <= sz]). successFlag ifTrue: [ addr _ rcvr + BaseHeaderSize + (2 * (index - 1)). value _ self halfWordAt: addr. self pop: 2. "pop rcvr, index" self pushInteger: value. "push element value" ]. ! ! !InterpreterSimulator methodsFor: 'memory access' stamp: 'GVG 1/27/1999 20:41'! halfWordAt: byteAddress "Return the half-word at byteAddress which must be even." | lowBits | lowBits _ byteAddress bitAnd: 2. ^((self longAt: byteAddress - lowBits) bitShift: (lowBits - 2) * 8) bitAnd: 16rFFFF ! ! !InterpreterSimulator methodsFor: 'memory access' stamp: 'GVG 1/27/1999 20:43'! halfWordAt: byteAddress put: halfWord | longWord shift lowBits | lowBits _ byteAddress bitAnd: 2. longWord _ self longAt: byteAddress - lowBits. shift _ (2 - lowBits) * 8. longWord _ longWord - (longWord bitAnd: (16rFFFF bitShift: shift)) + (halfWord bitShift: shift). self longAt: byteAddress put: longWord ! ! !InterpreterSimulatorLSB methodsFor: 'memory access' stamp: 'GVG 1/27/1999 20:43'! halfWordAt: byteAddress | lowBits | lowBits _ byteAddress bitAnd: 2. ^((self longAt: byteAddress - lowBits) bitShift: (0 - lowBits) * 8) bitAnd: 16rFFFF! ! !InterpreterSimulatorLSB methodsFor: 'memory access' stamp: 'GVG 1/27/1999 21:30'! halfWordAt: byteAddress put: halfWord | longWord shift lowBits | lowBits _ byteAddress bitAnd: 2. longWord _ self longAt: byteAddress - lowBits. shift _ lowBits * 8. longWord _ longWord - (longWord bitAnd: (16rFFFF bitShift: shift)) + (halfWord bitShift: shift). self longAt: byteAddress - lowBits put: longWord ! !

1 0

re: scamper
by thomas k. 30 Jan '99

30 Jan '99

Dan, Many thanks; that was the ticket. I was used to opening Morphic and selecting Scamper from the pop-up menu. thomas k. ________________________________________________________ NetZero - We believe in a FREE Internet. Shouldn't you? Get your FREE Internet Access and Email at http://www.netzero.net/download.html

1 0

Re: Bug Involving Modified #to:by:do:
by Tim Olson 30 Jan '99

30 Jan '99

Richard Harmon wrote: >I modified Number 'intervals' #to:by:do: method by adding at the beginning: > > step = 0 ifTrue: [ > ^self error: 'step must be non-zero.' > ]. > > >then evaluated: > > 5 to: 1 by: 0 do: [ :n | ^#bogus]. > >it returns bogus. Ralph Johnson replied: >Traditionally to:do: is optimized by the compiler when you send >it to a number, so the to:do: method is never called. I bet that >Squeak does the same thing with to:by:do:. The problem is that >you are catching the compiler cheating. Yep; there is a hint in the beginning of the method that Richard modified that states this. Richard, the compiler macro-expansions (inlined code) are in the MessageNode class (macro transformations category). If you want to continue to play with this, here is a change to the to:by:do transformation that causes it to not in-line if the step amount is zero. 'From Squeak 2.3 of January 14, 1999 on 30 January 1999 at 8:59:33 am'! !MessageNode methodsFor: 'macro transformations' stamp: 'tao 1/30/1999 08:56'! transformToDo: encoder " var _ rcvr. L1: [var <= arg1] Bfp(L2) [block body. var _ var + inc] Jmp(L1) L2: " | limit increment block initStmt test incStmt limitInit blockVar | "First check for valid arguments" ((arguments last isMemberOf: BlockNode) and: [arguments last numberOfArguments = 1]) ifFalse: [^ false]. arguments last firstArgument isVariableReference ifFalse: [^ false]. "As with debugger remote vars" arguments size = 3 ifTrue: [increment _ arguments at: 2. (increment isConstantNumber and: [increment literalValue ~= 0]) ifFalse: [^ false]] ifFalse: [increment _ encoder encodeLiteral: 1]. arguments size < 3 ifTrue: "transform to full form" [selector _ SelectorNode new key: #to:by:do: code: #macro]. "Now generate auxiliary structures" block _ arguments last. blockVar _ block firstArgument. initStmt _ AssignmentNode new variable: blockVar value: receiver. limit _ arguments at: 1. limit isVariableReference | limit isConstantNumber ifTrue: [limitInit _ nil] ifFalse: "Need to store limit in a var" [limit _ encoder autoBind: blockVar key , 'LimiT'. limit scope: -2. "Already done parsing block" limitInit _ AssignmentNode new variable: limit value: (arguments at: 1)]. test _ MessageNode new receiver: blockVar selector: (increment key > 0 ifTrue: [#<=] ifFalse: [#>=]) arguments: (Array with: limit) precedence: precedence from: encoder. incStmt _ AssignmentNode new variable: blockVar value: (MessageNode new receiver: blockVar selector: #+ arguments: (Array with: increment) precedence: precedence from: encoder). arguments _ (Array with: limit with: increment with: block) , (Array with: initStmt with: test with: incStmt with: limitInit). ^ true! ! !Number methodsFor: 'intervals' stamp: 'tao 1/30/1999 08:58'! to: stop by: step do: aBlock "Normally compiled in-line, and therefore not overridable. Evaluate aBlock for each element of the interval (self to: stop by: step)." | nextValue | nextValue _ self. step = 0 ifTrue: [self error: 'step must be non-zero']. step < 0 ifTrue: [[stop <= nextValue] whileTrue: [aBlock value: nextValue. nextValue _ nextValue + step]] ifFalse: [[stop >= nextValue] whileTrue: [aBlock value: nextValue. nextValue _ nextValue + step]]! ! -- tim

1 0

Re: Bug Involving Modified #to:by:do:
by Ralph Johnson 30 Jan '99

30 Jan '99

Traditionally to:do: is optimized by the compiler when you send it to a number, so the to:do: method is never called. I bet that Squeak does the same thing with to:by:do:. The problem is that you are catching the compiler cheating. -Ralph

1 0

Bug Involving Modified #to:by:do:
by R. A. Harmon 30 Jan '99

30 Jan '99

I modified Number 'intervals' #to:by:do: method by adding at the beginning: step = 0 ifTrue: [ ^self error: 'step must be non-zero.' ]. then evaluated: 5 to: 1 by: 0 do: [ :n | ^#bogus]. it returns bogus. I don't know what is going wrong where. I suspect some of those blue collar boys in the bowels of Squeak are taking an extra long coffee break or day dreaming. -- Richard A. Harmon "The only good zombie is a dead zombie" harmonra(a)webname.com E. G. McCarthy

1 0

Jump to page: