Hi,

I've done light testing on Linux x86-64, Arm64, and Arm32.

With the exception of removing

--enable-fast-bitblt

in

opensmalltalk-vm/building/linux32ARMv6/squeak.cog.spur/build [http://squeak.cog.spur/build]

/mvm

all seems fine.

The --enable-fast-bitblt is getting the wrong code because on my Arm32 system it is running Raspberry Pi OS from November.  And this is a 64 bit kernel so both the arch command and uname -m return aarch64, but it is a 32 bit userland.

So the logic as to which fast bitblt to pick is wrong and it tries to build the 64 bit one.  Chaos ensues.

I don't see this as a big deal since building on an older Arm32 Raspberry pi will do the right thing.

cheers

bruce

On 2023-11-21T19:15:53.000+01:00, Juan Vuletich juan@cuis.st wrote:

-------------------------   Hi Marcel,    On 11/21/2023 2:02 PM, Taeumel, Marcel wrote:

...

Hi all --       Please test this VM version (includes a small change log):    https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202311211431   [https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202311211431]      Choose your preferred platform. Focus on cog.spur flavors for   64-bit machines.       Thank you!       Best,    Marcel

Thank you very much for this! We'll be testing them with Cuis.    Cheers,    --   Juan Vuletich  cuis.st [http://cuis.st]  github.com/jvuletich [http://github.com/jvuletich]  researchgate.net/profile/Juan-Vuletich [http://researchgate.net/profile/Juan-Vuletich]  independent.academia.edu/JuanVuletich [http://independent.academia.edu/JuanVuletich]  patents.justia.com/inventor/juan-manuel-vuletich [http://patents.justia.com/inventor/juan-manuel-vuletich]  linkedin.com/in/juan-vuletich-75611b3 [http://linkedin.com/in/juan-vuletich-75611b3]  twitter.com/JuanVuletich [http://twitter.com/JuanVuletich]

On 11/21/2023 3:25 PM, Juan Vuletich wrote:

Hi Marcel,

When running on an Intel Mac with latest OS, the command shell window where I start the VM + Cuis shows this message: "WARNING: Secure coding is not enabled for restorable state! Enable secure coding by implementing NSApplicationDelegate.applicationSupportsSecureRestorableState: and returning YES."

This has been so for some time, after some MacOS update. I guess this is a harmless annoyance from Apple, and not a bug in the VM at all. Still, it would be nice if there was a way to avoid it.

Thanks!

On 11/21/2023 2:02 PM, Taeumel, Marcel wrote:

...

Hi all --

Please test this VM version (includes a small change log): https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202311211431

Choose your preferred platform. Focus on cog.spur flavors for 64-bit machines.

Thank you!

Best, Marcel

-- Juan Vuletich cuis.st github.com/jvuletich researchgate.net/profile/Juan-Vuletich independent.academia.edu/JuanVuletich patents.justia.com/inventor/juan-manuel-vuletich linkedin.com/in/juan-vuletich-75611b3 twitter.com/JuanVuletich

It should be enough to implement NSApplicationDelegate.applicationSupportsSecureRestorableState: returning NO, right?

Thanks,

Aha!

I am pretty sure that such backwards compatible binaries will not expose this API for newer OS versions... even if technically there in the binary.

It is Objective-C, not C. Tobias reminded me. :-) It's kind of message sending. So this should work, even if compiled on an older (pre-12) macOS. I will not touch the .h to avoid compilation issues on newer macOS platforms. That particular interface might be private anyway.

Best, Marcel

Am 11.12.2023 11:43:38 schrieb Marcel marcel.taeumel@hpi.uni-potsdam.de:

Hi Juan --

The binaries we build and share are for macOS 10.9+ (Intel) or macOS 11+ (ARM).

Yes, I can implement applicationSupportsSecureRestorableState, returning YES because we do not do custom save/restore and thus can let macOS handle it.

However, I cannot test the binary as I have no macOS12+Intel combination at my service. I am pretty sure that such backwards compatible binaries will not expose this API for newer OS versions... even if technically there in the binary.

Do you know how this mechanism works? Can I build for a pre-12 macOS and still provide an answer to that check in a 12+ macOS? Does it scan the binary for symbols? Does modern xcode used in an old macOS have some special measures for this?

Hmm...

Best, Marcel

Am 21.11.2023 20:19:39 schrieb Juan Vuletich juan@cuis.st:

On 11/21/2023 3:25 PM, Juan Vuletich wrote: Hi Marcel,

When running on an Intel Mac with latest OS, the command shell window where I start the VM + Cuis shows this message: "WARNING: Secure coding is not enabled for restorable state! Enable secure coding by implementing NSApplicationDelegate.applicationSupportsSecureRestorableState: and returning YES."

This has been so for some time, after some MacOS update. I guess this is a harmless annoyance from Apple, and not a bug in the VM at all. Still, it would be nice if there was a way to avoid it.

Thanks!

On 11/21/2023 2:02 PM, Taeumel, Marcel wrote:

Hi all --

Please test this VM version (includes a small change log): https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202311211431

Choose your preferred platform. Focus on cog.spur flavors for 64-bit machines.

Thank you!

Best, Marcel

-- Juan Vuletich cuis.st github.com/jvuletich researchgate.net/profile/Juan-Vuletich independent.academia.edu/JuanVuletich patents.justia.com/inventor/juan-manuel-vuletich linkedin.com/in/juan-vuletich-75611b3 twitter.com/JuanVuletich

It should be enough to implement NSApplicationDelegate.applicationSupportsSecureRestorableState: returning NO, right?

Thanks,

-- Juan Vuletich cuis.st github.com/jvuletich researchgate.net/profile/Juan-Vuletich independent.academia.edu/JuanVuletich patents.justia.com/inventor/juan-manuel-vuletich linkedin.com/in/juan-vuletich-75611b3 twitter.com/JuanVuletich

Aha!

If this was in a Cuis image, that image probably did not get the fix we did in DisplayScreen >> restore

restore | priorBits | priorBits := bits. "Must avoid to be GC'ed!" self setExtent: self class actualScreenSize depth: self nativeDepth. self beDisplay. priorBits := nil. "Documentation only." Project current ifNotNil: [:p| p displaySizeChanged].

For Cuis 5.0 and Cuis 6.0, this fix should probably be in DisplayScreen >> setExtent:depth:, where bits is cleared and thus can be GC'ed .

No, this cannot be fixed only in the VM platform code. The image allocates memory for the bits and communicates a pointer to that to the platform code via #beDisplay. Whenever those bits change, new bits must be communicated via #beDisplay *before* the GC collects the old bits. Image code must ensure that with a strong reference.

Well, this is no new behavior. The issue can also occur with the 2022-06 OSVM. But it is (still) rare. Probably related to how much old space the image uses. Definitely GC-related.

Best, Marcel

Am 06.12.2023 21:12:16 schrieb Eliot Miranda eliot.miranda@gmail.com:

Hi Marcel,

Thank you very much for making us aware of this!

Indeed I was not aware of the "new" requirement to call #beDisplay whenever Display bits change, and to keep the old instance around until this is done.

I'll do the appropriate changes to Cuis soon, hopefully tomorrow.

BTW, I guess this means that the Display bits are also pinned by the VM upon calling #beDisplay, right? Otherwise the GC would move them, and the crash would happen all the time.

Thanks a lot!

Cheers,

On 12/9/2023 4:29 AM, Taeumel, Marcel wrote:

If I remember correctly, the change to the macOS Metal support in OSVM (2022-06) was like this:

• use event mechanism (i.e. paint events) instead of raw Metal

pipeline to avoid locking image performance to 60 FPS max

• OSVM does a lot of "event pumping" at unexpected places, probably in

support of an input-event semaphore and thus a reactive in-image GUI framework (instead of cyclic Morphic, which polls events on its own)

Now the issue is with resizing DisplayScreen, which happens on snapshotting. There, bits get minimized to not have, e.g., 4K forms (8 meg?) in the file but only a smaller representative. And this is where the GC might collect those 8 meg, the VM does not know about the new bits yet, but unexpected "event pumping" triggers a repaint event via metal and thus a dangling "bits" pointer is processed in our metal backend. The VM crashes.

See the wording "does not slow down VM interpreter loop" here:

• https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/620

Those bits in DisplayScreen must be protected whenever screen-extent is changed from within the image such as on snapshotting.

Best, Marcel

...

Am 07.12.2023 13:10:22 schrieb Marcel marcel.taeumel@hpi.uni-potsdam.de:

Aha!

If this was in a Cuis image, that image probably did not get the fix we did in DisplayScreen >> restore

*restore* |priorBits| priorBits*:=*bits./"Must avoid to be GC'ed!"/ selfsetExtent:selfclassactualScreenSizedepth:selfnativeDepth. selfbeDisplay. priorBits*:=*nil./"Documentation only."/ ProjectcurrentifNotNil:[:p|pdisplaySizeChanged].

For Cuis 5.0 and Cuis 6.0, this fix should probably be in DisplayScreen >> setExtent:depth:, where bits is cleared and thus can be GC'ed .

No, this cannot be fixed only in the VM platform code. The image allocates memory for the bits and communicates a pointer to that to the platform code via #beDisplay. Whenever those bits change, new bits must be communicated via #beDisplay *before* the GC collects the old bits. Image code must ensure that with a strong reference.

Well, this is no new behavior. The issue can also occur with the 2022-06 OSVM. But it is (still) rare. Probably related to how much old space the image uses. Definitely GC-related.

Best, Marcel

...

Am 06.12.2023 21:12:16 schrieb Eliot Miranda eliot.miranda@gmail.com:

Yes, bits get pinned via beDisplay. We just have to ensure strong references from within the image.

Best, Marcel

________________________________ From: Juan Vuletich juan@cuis.st Sent: Sunday, December 10, 2023 2:45:47 PM To: Open Smalltalk Virtual Machine Development Discussion vm-dev@lists.squeakfoundation.org Cc: Taeumel, Marcel Marcel.Taeumel@hpi.de Subject: Re: [Vm-dev] Re: Please test | Relase candidate for OSVM 2023

Hi Marcel,

Thank you very much for making us aware of this!

Indeed I was not aware of the "new" requirement to call #beDisplay whenever Display bits change, and to keep the old instance around until this is done.

I'll do the appropriate changes to Cuis soon, hopefully tomorrow.

BTW, I guess this means that the Display bits are also pinned by the VM upon calling #beDisplay, right? Otherwise the GC would move them, and the crash would happen all the time.

Thanks a lot!

Cheers,

On 12/9/2023 4:29 AM, Taeumel, Marcel wrote:

If I remember correctly, the change to the macOS Metal support in OSVM (2022-06) was like this: - use event mechanism (i.e. paint events) instead of raw Metal pipeline to avoid locking image performance to 60 FPS max - OSVM does a lot of "event pumping" at unexpected places, probably in support of an input-event semaphore and thus a reactive in-image GUI framework (instead of cyclic Morphic, which polls events on its own)

Now the issue is with resizing DisplayScreen, which happens on snapshotting. There, bits get minimized to not have, e.g., 4K forms (8 meg?) in the file but only a smaller representative. And this is where the GC might collect those 8 meg, the VM does not know about the new bits yet, but unexpected "event pumping" triggers a repaint event via metal and thus a dangling "bits" pointer is processed in our metal backend. The VM crashes.

See the wording "does not slow down VM interpreter loop" here: - https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/620

Those bits in DisplayScreen must be protected whenever screen-extent is changed from within the image such as on snapshotting.

Best, Marcel

Am 07.12.2023 13:10:22 schrieb Marcel marcel.taeumel@hpi.uni-potsdam.demailto:marcel.taeumel@hpi.uni-potsdam.de:

Aha!

If this was in a Cuis image, that image probably did not get the fix we did in DisplayScreen >> restore

restore | priorBits | priorBits := bits. "Must avoid to be GC'ed!" self setExtent: self class actualScreenSize depth: self nativeDepth. self beDisplay. priorBits := nil. "Documentation only." Project current ifNotNil: [:p| p displaySizeChanged].

For Cuis 5.0 and Cuis 6.0, this fix should probably be in DisplayScreen >> setExtent:depth:, where bits is cleared and thus can be GC'ed .

No, this cannot be fixed only in the VM platform code. The image allocates memory for the bits and communicates a pointer to that to the platform code via #beDisplay. Whenever those bits change, new bits must be communicated via #beDisplay *before* the GC collects the old bits. Image code must ensure that with a strong reference.

Well, this is no new behavior. The issue can also occur with the 2022-06 OSVM. But it is (still) rare. Probably related to how much old space the image uses. Definitely GC-related.

Best, Marcel

Am 06.12.2023 21:12:16 schrieb Eliot Miranda eliot.miranda@gmail.commailto:eliot.miranda@gmail.com:

-- Juan Vuletich cuis.st github.com/jvuletich researchgate.net/profile/Juan-Vuletich independent.academia.edu/JuanVuletich patents.justia.com/inventor/juan-manuel-vuletich linkedin.com/in/juan-vuletich-75611b3 twitter.com/JuanVuletich

Please remember Ubuntu 18 has reached "normal" EOL in April already:

https://ubuntu.com/blog/ubuntu-18-04-eol-for-devices

And it ships with Glibc 2.27 (Even debian buster has 2.28…)

If we want to support older GLIBCen, we have to do strange dances: - for example, explicitly marking symbols to use "old" versoines ones https://web.archive.org/web/20160107032111/http://www.trevorpounds.com/blog/... (this seems excessive) (but pepople seem to have managed that: https://stackoverflow.com/a/69139182 ) - link statically, but that is, imho a Very Bad Idea™ - Kill the version info and cross fingers: https://stackoverflow.com/a/73388939 - Build on ubuntu 18.04. I don't know whether github still has this for runners…

it's messy

best regards -Tobias

On 28. Nov 2023, at 17:38, christoph.thiede@student.hpi.uni-potsdam.de christoph.thiede@student.hpi.uni-potsdam.de wrote:

Hi there,

happy to report a green bar for SimulationStudio under 6.0 using the new VM on Windows 10 22H2 (squeak.cog.spur_win64x64).

However, I cannot start the VM on WSL 1/Ubuntu 18.04 (squeak.cog.spur_linux64x64):

$ squeak /path/to/squeak60.image /usr/bin/squeak/lib/squeak/5.0-202311211431-64bit/squeak: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by /usr/bin/squeak/lib/squeak/5.0-202311211431-64bit/squeak)

With the previous VM, I did not have this issue.

$ file /usr/bin/squeak/lib/squeak/5.0-202311211431-64bit/squeak /usr/bin/squeak/lib/squeak/5.0-202311211431-64bit/squeak: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=db26fa3de79c67698b6850c38f487f719f2afd9c, for GNU/Linux 3.2.0, with debug_info, not stripped $ file /usr/bin/squeak.bak20231128/lib/squeak/5.0-202204190959-64bit/squeak /usr/bin/squeak.bak20231128/lib/squeak/5.0-202204190959-64bit/squeak: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=c7e8211b70431cf23cd03d1531d6b82f16366438, with debug_info, not stripped

Should the VM work out of the box without installing extra dependencies? If yes, could there something be missing in the build process? If not, can we please make the documentation on how to install the missing dependencies very accessible (e.g., include a readme in the VM bundles)?

Best, Christoph

---

Sent from Squeak Inbox Talk

On 2023-11-21T17:02:16+00:00, marcel.taeumel@hpi.de wrote:

...

Hi all --

Please test this VM version (includes a small change log): https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202311211431

Choose your preferred platform. Focus on cog.spur flavors for 64-bit machines.

Thank you!

Best, Marcel

I updated the change log with some compatibility notes: https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202311211431

For older systems, OSVM needs to be built manually. But it should be possible.

Best, Marcel

Am 29.11.2023 08:50:44 schrieb Taeumel, Marcel marcel.taeumel@hpi.de:

We build with 20.04. No older runners available on GitHub. We should drop support for 18.04 ... 😎

________________________________ From: Tobias Pape Das.Linux@gmx.de Sent: Tuesday, November 28, 2023 9:46:16 PM To: Open Smalltalk Virtual Machine Development Discussion vm-dev@lists.squeakfoundation.org Subject: [Vm-dev] Re: Please test | Relase candidate for OSVM 2023

Please remember Ubuntu 18 has reached "normal" EOL in April already:

https://ubuntu.com/blog/ubuntu-18-04-eol-for-devices

And it ships with Glibc 2.27 (Even debian buster has 2.28…)

If we want to support older GLIBCen, we have to do strange dances: - for example, explicitly marking symbols to use "old" versoines ones https://web.archive.org/web/20160107032111/http://www.trevorpounds.com/blog/... (this seems excessive) (but pepople seem to have managed that: https://stackoverflow.com/a/69139182 ) - link statically, but that is, imho a Very Bad Idea™ - Kill the version info and cross fingers: https://stackoverflow.com/a/73388939 - Build on ubuntu 18.04. I don't know whether github still has this for runners…

it's messy

best regards -Tobias

On 28. Nov 2023, at 17:38, christoph.thiede@student.hpi.uni-potsdam.de christoph.thiede@student.hpi.uni-potsdam.de wrote:

Hi there,

happy to report a green bar for SimulationStudio under 6.0 using the new VM on Windows 10 22H2 (squeak.cog.spur_win64x64).

However, I cannot start the VM on WSL 1/Ubuntu 18.04 (squeak.cog.spur_linux64x64):

$ squeak /path/to/squeak60.image /usr/bin/squeak/lib/squeak/5.0-202311211431-64bit/squeak: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by /usr/bin/squeak/lib/squeak/5.0-202311211431-64bit/squeak)

With the previous VM, I did not have this issue.

$ file /usr/bin/squeak/lib/squeak/5.0-202311211431-64bit/squeak /usr/bin/squeak/lib/squeak/5.0-202311211431-64bit/squeak: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=db26fa3de79c67698b6850c38f487f719f2afd9c, for GNU/Linux 3.2.0, with debug_info, not stripped $ file /usr/bin/squeak.bak20231128/lib/squeak/5.0-202204190959-64bit/squeak /usr/bin/squeak.bak20231128/lib/squeak/5.0-202204190959-64bit/squeak: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=c7e8211b70431cf23cd03d1531d6b82f16366438, with debug_info, not stripped

Should the VM work out of the box without installing extra dependencies? If yes, could there something be missing in the build process? If not, can we please make the documentation on how to install the missing dependencies very accessible (e.g., include a readme in the VM bundles)?

Best, Christoph

---

Sent from Squeak Inbox Talk

On 2023-11-21T17:02:16+00:00, marcel.taeumel@hpi.de wrote:

...

Hi all --

Please test this VM version (includes a small change log): https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202311211431

Choose your preferred platform. Focus on cog.spur flavors for 64-bit machines.

Thank you!

Best, Marcel

Happy to report that I was able to build the new OSVM RC on Ubuntu 18.04 myself and reproduce a green bar for SimulationStudio under WSL 1.

Best, Christoph

--- Sent from Squeak Inbox Talk

On 2023-11-28T17:38:57+01:00, christoph.thiede@student.hpi.uni-potsdam.de wrote:

Hi there,

happy to report a green bar for SimulationStudio under 6.0 using the new VM on Windows 10 22H2 (squeak.cog.spur_win64x64).

However, I cannot start the VM on WSL 1/Ubuntu 18.04 (squeak.cog.spur_linux64x64):

$ squeak /path/to/squeak60.image /usr/bin/squeak/lib/squeak/5.0-202311211431-64bit/squeak: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by /usr/bin/squeak/lib/squeak/5.0-202311211431-64bit/squeak)

With the previous VM, I did not have this issue.

$ file /usr/bin/squeak/lib/squeak/5.0-202311211431-64bit/squeak /usr/bin/squeak/lib/squeak/5.0-202311211431-64bit/squeak: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=db26fa3de79c67698b6850c38f487f719f2afd9c, for GNU/Linux 3.2.0, with debug_info, not stripped $ file /usr/bin/squeak.bak20231128/lib/squeak/5.0-202204190959-64bit/squeak /usr/bin/squeak.bak20231128/lib/squeak/5.0-202204190959-64bit/squeak: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=c7e8211b70431cf23cd03d1531d6b82f16366438, with debug_info, not stripped

Should the VM work out of the box without installing extra dependencies? If yes, could there something be missing in the build process? If not, can we please make the documentation on how to install the missing dependencies very accessible (e.g., include a readme in the VM bundles)?

Best, Christoph

---

Sent from Squeak Inbox Talk

On 2023-11-21T17:02:16+00:00, marcel.taeumel(a)hpi.de wrote:

...

Hi all --

Please test this VM version (includes a small change log): https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202311211431

Choose your preferred platform. Focus on cog.spur flavors for 64-bit machines.

Thank you!

Best, Marcel

Hi Bernhard --

Yes, this looks like some kind of memory corruption. Maybe you could set up a little test script that does that md5 hashing extensively and mix it up with snapshotPrimitive ?

Best, Marcel

Am 30.11.2023 09:30:10 schrieb Bernhard Pieber bernhard@pieber.com:

Hi Marcel,

FWIW, I had another crash during the same use case. Maybe the crash_2023-11-27.dmp is somewhat helpful.

Cheers, Bernhard

Am 26.11.2023 um 22:50 schrieb Bernhard Pieber bernhard@pieber.com:

Hi Marcel,

Thank you for building the release candidate. I just used the squeak.cog.spur_macos64x64 VM with the latest Cuis image for several hours. When I tried to save and quit the VM it crashed, see attachment. It seems to have saved the image correctly before the crash.

I used OSProcess extensively to call md5 to calculate file hashes. I ran into a lot of OSProcess errors. Maybe the crash has something to do with this.

Cheers, Bernhard

Am 21.11.2023 um 18:02 schrieb Taeumel, Marcel Marcel.Taeumel@hpi.de:

Hi all --

Please test this VM version (includes a small change log): https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202311211431

Choose your preferred platform. Focus on cog.spur flavors for 64-bit machines.

Thank you!

Best, Marcel

Thanks Marcel,

I'm testing them for the upcoming release of Cuis 6.1. BTW, it is at https://github.com/jvuletich/CuisExperiments004 . Everybody is welcome to try it and five feedback.

Cheers,

On 12/20/2023 12:03 PM, Taeumel, Marcel wrote:

Hi all --

There is a new release candidate OSVM 2023.12! :-)

Please test this VM version (includes a small change log): _https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202312181441_

Choose your preferred platform. Focus on cog.spur flavors for 64-bit machines.

Thank you!

Best, Marcel

...

Am 21.11.2023 18:02:11 schrieb Marcel marcel.taeumel@hpi.uni-potsdam.de:

Hi all --

Please test this VM version (includes a small change log): https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202311211431

Choose your preferred platform. Focus on cog.spur flavors for 64-bit machines.

Thank you!

Best, Marcel