[squeak-dev] Open Croquet will ahve issues in next version of Mac OS X

Eliot Miranda eliot.miranda at gmail.com
Sun Oct 28 19:11:20 UTC 2018

Hi Lawson,

On Mon, Oct 22, 2018 at 5:28 PM LawsonEnglish <LEnglish5 at cox.net> wrote:

> Well, the OpenGL plugin itself isn’t 64-bit last I checked, and I’m not
> sure what else. Croquet/Cobalt may auto-install stuff that I never noticed.
> There’s also an issue with Croquet/Cobalt only working properly because
> every vlirny generates exactly the same (bit-identical) values in every
> possible respect.
> Integer handling  (and 32-bit floating point) in 32-bit vs 64-bit squeak
> may break that. It may be possible to create “proxy” classes for integers
> and floats and use those in both 32-bit and 64-bit Croquet, and allow the
> objects on the client-side resolve any oddness, but as it stands now, my
> understanding is that a SmallInteger on a 32-bit VM isn't the same as a
> SmallInteger on a 64-bit VM and that is an automatic fail for the paradigm
> that Croquet is based on, so simply updating Croquet to 64-bit will
> automatically make it incompatible with 32-bit Croquet.

Maybe, maybe not.  First, Smalltalk's integer arithmetic model is infinite
precision.  So integer calculations in 16-bit Smalltalk-80, 32-bit
Smalltalk-80 or 64-bit Smalltalk-80 *should* produce the same results,
except for representation.  So while the range of SmallIntegers in each is
different, the results should be equivalent.  Hence, provided that the
serialization/deserialization marshaling correctly converts representations
between the systems we should still be able to do computations that appear
to be bit identical in the different width implementations.  As an
existence proof, people routinely contribute to Squeak trunk from either
32-bit or 64-bit Spur images according to preference and so far we have not
had a single issue of a commit on a 32-bit system breaking a 64-bit system
or vice verse.  Monticello packages committed on one width appear to one
seamlessly loadable on the other width.  recently we have also managed to
pull off the same level off compatibility with ImageSegments,
interpretively loading 32-bit segments into a 64-bit system and vice verse.

However, there are clearly things one  must not do to preserve the
portability of code across different work widths.  One must not write code
such as
    result class == SmallFloat64 ifTrue: [#bitch] ifFalse: [#moan]
So as far as Croquet/Cobalt goes, being able to connect 32-bit and 64-bit
systems within the same session will require
- correct marshaling of types affected by word width to map correctly into
the relevant representations
- bit identical implementation of arithmetic (particularly floating point)
across different systems and word widths
- avoiding writing code that responds differently to different

But in building the 32-bit/64-bit our architecture I took care that mapping
from 32-bit I'm ages to 64-bit images is completely automated and
predictable. And, were it useful, one could write a 64-bit to 32-bit image
converter such that 64-bit => 32-bit => 64-bit is idempotent.  [One cannot
say that 32-bit => 64-bit => 32-bit is bit identical because even though
the initial and final 32-bit images would have exactly the same objects in
them they could occur in different orders, because in converting a specific
32 to 61 bit LargePositiveInteger or LargeNegativeInteger to a 61-bit
SmallInteger and back, the final 32 to 61 bit LargePositiveInteger or
LargeNegativeInteger would likely end up in a different part of the heap
than it had started in.  But one could say that 64-bit => 32-bit => 64-bit
=> 32-bit would produce bit identical 32-bit images]

Which kinda defeats the original "deploy everywhere that Squeak works”
> philosophy.

It may do; it may not.  At Qwaq we insisted that everyone in the same
session use exactly the same build. But I expect that automatically
producing a 64-bit version from a 32-bit build, or vice verse, would indeed
produce compatible images.  Of course we won't know for sure until we try

> > On Oct 22, 2018, at 4:36 PM, David T. Lewis <lewis at mail.msen.com> wrote:
> >
> > Hi Lawson,
> >
> > On Mon, Oct 22, 2018 at 01:24:16PM -0700, LawsonEnglish wrote:
> >> https://blog.krestianstvo.org/en/open-croquet-for-squeak-6/ <
> https://blog.krestianstvo.org/en/open-croquet-for-squeak-6/>
> >>
> >>
> >> This sounds really cool, but there???s an issue coming up:
> >>
> >> Apple is doing away with ANY support for 32-bit apps and plugins and of
> course, Croquet is built for 32-bits and uses 32-bit plugins all over the
> place.
> >>
> >
> > We collectively have a good deal of experience in updating plugins
> > for 64 bits, and of course the VMs (the "application") are already
> > there. Can you remind us what plugins are needed for Croquet that are
> > not already in the supported VMs?
> >
> > Thanks,
> > Dave
> >
> >
> >
> >>
> >>
> >> Croquet could STILL be the killer-app for Smalltalk even though it
> never realized its potential in the past, and it won???t be able to if
> something isn???t done about the looming 32-bit vs 64-bit issue.
> >>
> >> Need I point out that it should work on Pharo just the same way it does
> on Squeak?
> >>
> >> L
> >>
> >
> >

best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20181028/8182ae9e/attachment.html>

More information about the Squeak-dev mailing list