"Andreas Raab" <Andreas.Raab at gmx.de> is claimed by the authorities to have written:

> > (123 primitiveValueUninterruptably)"@@@: Remove this when all VMs have
[snip]
> 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.
Ah yes, of course; fortunately I'm aiming these changes at the VI4 so
backwards compatability isn't much of a problem. Do you remember what
needs doing in the image to remove it? I'm feeling far too lazy to work
it out for myself if there is any chance of somebody already knowing the
answer. Too many airplanes to build...
> 
> >  "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)
D'oh, typo (yes, I still haven't got the copy buffer integrated
properly. Shameful, I know)
> 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.
Excellent. I suggest that the vm plugin manipluation prims can do the
same, move them from 570 down somewhere. There's no direct users that
appear to have any problem with changing the numbers.
> 
> > 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).
Very true, but there's so often somebody with strong views on these
things. Maybe it's time to make a DisplayPlugin to go with the
SurfacePlugin.

tim
-- 
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Useful random insult:- In serious need of attitude adjustment.