Hello Chris,

On Fri, Oct 26, 2018 at 9:27 PM Chris Muller asqueaker@gmail.com wrote:

One of Squeak's coolest projects ever, thanks Nikolay!

One question, sorry I didn't try but will it work in 64-bit Squeak and, if not, why not and when will it?

Yes, actually it should. I just have updated Open Croquet integration with support of SmallFloat64 class, which is used by default on 64 bit Squeak. I have tested this on Windows'10 with http://files.squeak.org/5.2/Squeak5.2-18225-64bit/Squeak5.2-18225-64bit-2018... and Croquet works. Don't forget to enable B3DXUsesOpenGL=1 in Squeak.ini for OpenGL.

Here is the preloaded 64 bit image: https://www.krestianstvo.org/sdk/croquet/Squeak5.2-18225-64bit-Croquet-Image... or do (Installer fromUrl: ' http://sdk.krestianstvo.org/sdk/croquet/croquet-sn.4.mcm') install.

As for macOS, there is seems to be a problem with the B3DAcceleratorPlugin for 64 bit, which constantly craches the VM. May be somebody had a success of running B3DAcceleratorPlugin with OpenGL on 64 bit Squeak for macOS?

Best regards, Nikolai

Thanks!

On Thu, Oct 25, 2018 at 9:47 PM Nikolay Suslov nsuslovi@gmail.com wrote:

...

Hi all,

I'm pleased to announce, that the experimental version of Open Croquet for Squeak (https://blog.krestianstvo.org/en/open-croquet-for-squeak-6/) is now updated to the recent Squeak 5.2 (32bit) http://files.squeak.org/5.2/Squeak5.2-18225-32bit. This update includes critical FIX for the Croquet's IslandReader, which is related to the new Squeak image segment loader code. The included Croquet demos have become usable in network scenarios, but with some requirements: For replication to work, a participant must run a Master of the selected demo at least once on its image (for example doing: CroquetMaster new openInWorld). Then that participant could connect to any running Master on a network (for example doing: CroquetParticipant new openInWorld). In the future updates this will be fixed.

*Preloaded images:*

• All-In-One Squeak 5.2 VM with preloaded Open Croquet image and content:

https://www.krestianstvo.org/sdk/croquet/Squeak5.2-18225-32bit-All-in-One-Cr...

• Only Squeak 5.2 with image with preloaded Open Croquet:

https://www.krestianstvo.org/sdk/croquet/Squeak5.2-18225-32bit-Croquet-Image...

• Only content (Textures, Models, etc.):

https://www.krestianstvo.org/sdk/croquet/Content.zip

*Loading manually:*

(Installer fromUrl: ' http://sdk.krestianstvo.org/sdk/croquet/croquet-sn.3.mcm') install. Don't forget to download and extract 'Only content https://www.krestianstvo.org/sdk/croquet/Content.zip' package to /Contents/Resources/ folder.

*How to use it on the network:*

If Master wanted to be discoverable, it's network address must be specified here: CroquetHarness dispatcherAddress. Participant should specify a Master's network address here: CroquetHarness defaultBroadcaster.

Here is the screenshot of one Master (on macOS) and two Participants (on Windows and macOS) collaborating together.

[image: Screenshot-croquet.jpg]

Best reagards, Nikolai

Hello Eliot,

I am very inspired by the new Squeak 5.2 VM and its amazing speed! Just dreaming of having Open Croquet working on it. And now after first early steps of porting from Squeak 4.x, even without formal tests, it is seen how much faster Open Croquet demos are working.

On Sat, Oct 27, 2018 at 7:48 PM Eliot Miranda eliot.miranda@gmail.com wrote:

Hi Nikolay,

On Oct 25, 2018, at 7:47 PM, Nikolay Suslov nsuslovi@gmail.com wrote:

Hi all,

I'm pleased to announce, that the experimental version of Open Croquet for Squeak (https://blog.krestianstvo.org/en/open-croquet-for-squeak-6/) is now updated to the recent Squeak 5.2 (32bit) http://files.squeak.org/5.2/Squeak5.2-18225-32bit.

Great news, thank you!

This update includes critical FIX for the Croquet's IslandReader, which is related to the new Squeak image segment loader code.

Can you explain what the bug was, and what is the fix?

Actually, this fix is in adapting the IslandReader segment loading methods to the new behaviour of '#primitiveLoadSegmentFrom: segmentWordArray outPointers: outPointerArray': "Upon successful completion, the wordArray will have been becomed into anArray of the loaded objects." In original Open Croquet for Squeak 4.x, 'IslandReader>>#loadSegmentFromData: segmentWordArray outPointers: outPointerArray' traversing the loaded WordArrayForSegment with #nextObject for post-sending startUp message to objects ('#startUpInIslandReader: reader'). But, in Squeak 5.2 it should uses an array of the loaded objects, instead WordArrayForSegment object. That's it.

Best regards, Nikolai

The included Croquet demos have become usable in network scenarios, but with some requirements: For replication to work, a participant must run a Master of the selected demo at least once on its image (for example doing: CroquetMaster new openInWorld). Then that participant could connect to any running Master on a network (for example doing: CroquetParticipant new openInWorld). In the future updates this will be fixed.

*Preloaded images:*

• All-In-One Squeak 5.2 VM with preloaded Open Croquet image and content:

https://www.krestianstvo.org/sdk/croquet/Squeak5.2-18225-32bit-All-in-One-Cr...

• Only Squeak 5.2 with image with preloaded Open Croquet:

https://www.krestianstvo.org/sdk/croquet/Squeak5.2-18225-32bit-Croquet-Image...

• Only content (Textures, Models, etc.):

https://www.krestianstvo.org/sdk/croquet/Content.zip

*Loading manually:*

(Installer fromUrl: ' http://sdk.krestianstvo.org/sdk/croquet/croquet-sn.3.mcm') install. Don't forget to download and extract 'Only content https://www.krestianstvo.org/sdk/croquet/Content.zip' package to /Contents/Resources/ folder.

*How to use it on the network:*

If Master wanted to be discoverable, it's network address must be specified here: CroquetHarness dispatcherAddress. Participant should specify a Master's network address here: CroquetHarness defaultBroadcaster.

Here is the screenshot of one Master (on macOS) and two Participants (on Windows and macOS) collaborating together.

<Screenshot-croquet.jpg>

Best reagards, Nikolai

On Sat, Oct 27, 2018 at 4:42 PM tim Rowledge tim@rowledge.org wrote:

Trying this out on a Raspberry Pi (obviously). First major problem is that

OGLUnix>>openGLLibraryName ^Smalltalk osVersion = 'linux' ifTrue: ['libGL.so.1'] ifFalse: ['GL'] has a #'' (apparently a ByteSymbol with just char value 0 in it) at the end of the method ; which of course a BlockClosure does not understand.

After 'fixing' that it goes on a little until we get to OpenGL>>#glMatrixMode: glMatrixMode: mode "This method was automatically generated." "void glMatrixMode(GLenum mode);" <apicall: void 'glMatrixMode' (ulong) module: '#openGLLibraryName'> ^self externalCallFailed

The" module: '#openGLLibraryName'>" looks a bit odd to me... shouldn't that have been recompiled to use the real library name?

Yes, but it doesn't change the source code. Follow the senders of openGLLibraryName to see the magic.

- Bert -

On Mon, Oct 29, 2018 at 5:49 PM tim Rowledge tim@rowledge.org wrote:

...

On 2018-10-29, at 12:26 PM, Bert Freudenberg bert@freudenbergs.de

wrote:

...

On Sat, Oct 27, 2018 at 4:42 PM tim Rowledge tim@rowledge.org wrote: Trying this out on a Raspberry Pi (obviously). First major problem is that

OGLUnix>>openGLLibraryName ^Smalltalk osVersion = 'linux' ifTrue: ['libGL.so.1'] ifFalse: ['GL']

It's actually a bit worse - the osVersion returned by Raspbian is 'linux-gnu' - so I tried changing that to openGLLibraryName ^(Smalltalk osVersion beginsWith: 'linux') ifTrue: ['libGL.so.1'] ifFalse: ['GL'] which got a bit further.

...

has a #'' (apparently a ByteSymbol with just char value 0 in it) at the

end of the method ; which of course a BlockClosure does not understand.

...

[snip]

...

The" module: '#openGLLibraryName'>" looks a bit odd to me... shouldn't

that have been recompiled to use the real library name?

...

Yes, but it doesn't change the source code. Follow the senders of

openGLLibraryName to see the magic.

OK, so it's supposed to send #openGLLibraryName at some startup point. Very clever.

Yep, in OpenGL>>initialize it calls "self privateInstallLibrary: self openGLLibraryName." which patches the library name into all compiled FFI methods.

Unfortunately it appears something else goes wrong pretty quickly and

OGLExtManager>>#loadExtension: uses glExtGetProcAddress: which even decompiled says <cdecl: ulong 'glXGetProcAddressARB' (char*) module: 'GL'> Which doesn't seem right. Should it also use the #openGLLibraryName thing?

Ah, that seems to be an actual bug.

#privateInstallLibrary: does not go into the subclasses. In OGLWin32, that method has the correct 'opengl32.dll' module. OGLMacOSX uses a different mechanism entirely. And OGLUnix relies on "GL" linking to the right thing.

So I'd say in privateInstallLibrary: we need to patch both OpenGL and OGLUnix.

- Bert -