Hi Guillermo, On Sun, Mar 18, 2012 at 5:46 PM, Guillermo Polito <guillermopolito@gmail.com
wrote:
What about changing #recreateSpecialObjectsArray so having in mind some classes like Bitmap or Display may not be in the kernel? This only changes some lines like:
... newArray at: 5 put: (self at: #Bitmap ifAbsent: [ nil ]).
...
newArray at: 13 put: (self at: #Point ifAbsent: [ nil ]).
...
newArray at: 15 put: (self at: #Display ifAbsent: [ nil ]).
...
newArray at: 34 put: (self at: #Point ifPresent: [ :cls | 0@0] ifAbsent: [ nil ]).
The last one isn't used in Cog (in fact indices 32, 33 & 34 are unused) and probably unused in the Interpreter. David? You may be able to get away with making Bitmap and DIsplay optional. But Point is dug pretty deep into the VM. Point is used for the special selector send bytecodes for #x, #y & #@. For #x & #y there's a check that the class of the receiver is Point, and if so, evaluate in-line. So that is fine; if Point is nil then #x will get sent, rather than evaluated inline. But if the system sends #@ it'll likely crash, trying to create an object whose class is nil. To do what you're proposing properly the VM would need to be modified to be safe. We should perhaps discuss what the right approach is. e.g. if Point is in fact nil then #x #y and #@ would all slow down slightly in normal use checking for the possibility of Point being nil. This isn't an issue in Cog since these messages are compiled to regular sends; but t=in the regular interpreter and the StackInterpreter (used on e.g. Android) it may be. A different approach might be to move these classes to Kernel, or to provide rump classes that raise errors when used, e.g. newArray at: 13 put: (self at: #Point ifAbsent: [ RumpPoint ]). (the rump of something being what's left when you take everything away, rump = behind, bottom etc)
Does anyone know if this should this break something?
Guille
-- best, Eliot