Odd 'dead' primitives

Andreas Raab Andreas.Raab at gmx.de
Thu Oct 17 22:46:31 UTC 2002


Tim,

> (123 primitiveValueUninterruptably)"@@@: Remove this when all VMs have
> support" - there is a method calling this prim in
> BlockContext>ifProperUnwindSupportedElseSignalAboutToReturn 
> and another in BlockContext>valueUninterruptably

Right. If you run a current image on a way-back-vm you'll be in
seriously trouble if your image can't figure out if the "new" unwind
semantics are supported or not. I tried to get rid of this entire
nuisance but the problem with people using older VMs were too big to
just ignore them. That's why there's this "if present send #value and
otherwise fail and run all of the old stuff" primitive. I can't say if
that's still a problem these days but I wouldn't bet on it.

>  "NOTE: When removing the obsolete indexed primitives,
>  the following two should go become #primitiveIntegerAt/atPut"
>  (147 primitiveObsoloteIndexedPrimitive) "primitiveReadJoystick"
>  (147 primitiveObsoleteIndexedPrimitive) "primitiveWarpBits"
>  - which reads a bit oddly and makes little sense to me, as if it got
>  reformatted by prettyprint sometime.

Except that the first primitive index should be 146 (in my image it is)
everything's fine with it. If you look at

	"File Primitives (150-169) - NO LONGER INDEXED"
	(150 164 primitiveObsoleteIndexedPrimitive)
	(165 primitiveIntegerAt)		"hacked in here for now"
	(166 primitiveIntegerAtPut)

then it's pretty clear that the integerAt:[put:] primitives should not
be where they are right now - in particular not if the prims 143-145 are
already special at[put] versions. So the comment means put
integerAt:[put:] into primitives 146/147 if there ever comes a time when
we can do it safely.

> In addition, there are a mere ten prims with no module name, eight
> relating to the webbrowser plugin stuff plus #actualScreenDepth and
> #disablePowerManager. Anyone have strong thoughts on which 
> plugins might be better homes for them?

Not really. The browser stuff should probably go someplace separate and
all of the display stuff ought to be its own plugin anyways (but you
know all this).

Cheers,
  - Andreas




More information about the Squeak-dev mailing list