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.
Which kinda defeats the original "deploy everywhere that Squeak works” philosophy.
L
On Oct 22, 2018, at 4:36 PM, David T. Lewis lewis@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
Hi,
For what it's worth the dynamic libraries in /System/Library/Frameworks/[OpenGL.framework/Libraries/*](http://OpenGL.framework/Libraries/*)%C2%A0are all both 32 and 64 bit. So that means that one could write a 64 bit OpenGL plugin etc and use it from a 64 bit Squeak.
All Apple has said is "OpenGL is depreciated." They have been very closed mouth about when it will be removed. One guesses that the next version after Mojave will not have the 32 bit libraries regardless of OpenGL or not.
If I would bet they will not remove OpenGL but they will get increasingly strident with the warning messages in Xcode etc, and, eventually give a pop-up like we've been getting for 32 bit apps. I'm betting that new App Store approvals won't happen with OpenGL but we don't care about that.
cheers
bruce
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.
Which kinda defeats the original "deploy everywhere that Squeak works” philosophy.
L
On Oct 22, 2018, at 4:36 PM, David T. Lewis 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/
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
Hi Lawson,
On Mon, Oct 22, 2018 at 5:28 PM LawsonEnglish LEnglish5@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 representations
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 :-)
L
On Oct 22, 2018, at 4:36 PM, David T. Lewis lewis@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/%3E
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
squeak-dev@lists.squeakfoundation.org
-
Bruce O'Neel -
Eliot Miranda -
LawsonEnglish