Open Croquet will ahve issues in next version of Mac OS X
Locked
Open Croquet will ahve issues in next version of Mac OS X
 
|
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. 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 |
Re: Open Croquet will ahve issues in next version of Mac OS X
|
|
LawsonEnglish wrote:
> 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. > +1 -- Please report bounces from this address to [hidden email] Powers are not rights. |
Re: Open Croquet will ahve issues in next version of Mac OS X
|
|
In reply to this post by LawsonEnglish
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 > |
Re: Open Croquet will ahve issues in next version of Mac OS X
|
|
In reply to this post by LawsonEnglish
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 <[hidden email]> 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 >> > > |
Re: Open Croquet will ahve issues in next version of Mac OS X
|
|
In reply to this post by LawsonEnglish
That should have read: because every *client* generates exactly the same… L [even my typos have typos] |
Re: Open Croquet will ahve issues in next version of Mac OS X
|
|
In reply to this post by LawsonEnglish
Hi, For what it's worth the dynamic libraries in /System/Library/Frameworks/OpenGL.framework/Libraries/* are 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 23 October 2018 02:28 LawsonEnglish <[hidden email]> wrote:
|
Re: Open Croquet will ahve issues in next version of Mac OS X
|
|
In reply to this post by LawsonEnglish
Hello Lawson, Thanks for raising that question about 64 bit future of Open Croquet and Mac OS X support. I have tested the possibility of running Open Croquet on recent 64 bit version of Squeak 5.2. And it seems to be working, on Windows at least. Due to the B3DAccelerator and Croquet plugins, which are available in recent Squeak 64 bit VMs (there are still some issues with B3DAccelerator plugin on macOS). Here is preloaded image for Squeak: https://www.krestianstvo.org/sdk/croquet/Squeak5.2-18225-64bit-Croquet-Image.zip Yes, you are right, that replication from participant running Croquet 64 bit image onto participant with 32 bit image or vice versa will not work properly by default. What is about supporting of 3D graphics in future versions of macOS, may be the time is coming to think about Metal FFI bindings. And yes, potentially this integration should work on Pharo too. Best regards, Nikolai On Mon, Oct 22, 2018 at 11:24 PM LawsonEnglish <[hidden email]> wrote:
|
Re: Open Croquet will ahve issues in next version of Mac OS X
|
|
In reply to this post by LawsonEnglish
Hi Lawson, On Mon, Oct 22, 2018 at 5:28 PM LawsonEnglish <[hidden email]> 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. 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 _,,,^..^,,,_ best, Eliot |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |