[Vm-dev] Next Release Candidate?

[Marcel Taeumel]

Hi Eliot --

> My feeling is that we should fix all of these, and include the primitive suspend fix. I shall refrain from making any changes other than in fixing these four issues.

Let's do that. There is still time. :-) I updated the squeak-app bundling to be able to include any tagged OSVM version. So we can continue testing both vm and bundles. The current bundles include the VM tag 202112201228.

http://files.squeak.org/trunk/Squeak6.0alpha-20966-64bit/Squeak6.0alpha-20966-64bit-202112201228-macOS.dmg

http://files.squeak.org/trunk/Squeak6.0alpha-20966-64bit/Squeak6.0alpha-20966-64bit-202112201228-Linux-x64.tar.gz

http://files.squeak.org/trunk/Squeak6.0alpha-20966-64bit/Squeak6.0alpha-20966-64bit-202112201228-Linux-ARMv8.tar.gz

http://files.squeak.org/trunk/Squeak6.0alpha-20966-64bit/Squeak6.0alpha-20966-64bit-202112201228-Windows-x64.zip


http://files.squeak.org/trunk/Squeak6.0alpha-20966-64bit/


Best,
Marcel
Am 06.01.2022 16:55:22 schrieb Eliot Miranda <eliot.miranda at gmail.com>:


On Jan 6, 2022, at 7:05 AM, Marcel Taeumel <marcel.taeumel at hpi.de> wrote:




Hi all --

Well, I figured that the pre-compiled (default) manifest only bothers 32-bit builds for Windows because there we use gcc instead of clang. I am still trying to understand how we can fix the 32-bit builds for Windows in this regard. Just deleting

msys64/mingw32/i686-w64-mingw32/lib/default-manifest.o


does not do the trick as the linking step (ld) will fail quite early [1]:

i686-w64-mingw32-gcc -o mkNamedPrims.exe -mconsole -m32 ../../../platforms/win32/util/mkNamedPrims.c
C:/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/10.3.0/../../../../i686-w64-mingw32/bin/ld.exe: cannot find default-manifest.o: No such file or directory
collect2.exe: error: ld returned 1 exit status
make: *** [../common/Makefile:221: mkNamedPrims.exe] Error 1

***

So, the question is: Should I try to fix this and then make another release candidate, which would include the already pushed [2] SqueakSSL fixes for Ubuntu 16 as well? Or should we keep the current one? What about that hard-to-reproduce/debug BitBlt segfault [3]? Hmm...

My feeling is that we should fix all of these, and include the primitive suspend fix.  I shall refrain from making any changes other than in fixing these four issues.


Best,
Marcel

[1] https://github.com/msys2/MSYS2-packages/issues/454
[2] https://github.com/OpenSmalltalk/opensmalltalk-vm/commits/Cog
[3] http://lists.squeakfoundation.org/pipermail/squeak-dev/2021-December/217834.html


Am 27.12.2021 10:20:57 schrieb Marcel Taeumel <marcel.taeumel at hpi.de>:

Hi all --

There will be another release candidate because our current build system for Windows (i.e., MSYS+MinGW) hard-codes a manifest into the executable, which prevents us from enabling High-DPI-Awareness.

Stay tuned.

Best,
Marcel

Am 20.12.2021 15:31:00 schrieb Marcel Taeumel <marcel.taeumel at hpi.de>:

Hi all --

Here is the next release candidate:
https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202112201228 [https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202112201228]


Note that the macOS build artifacts are still unsigned and not notarized but will be as soon as I attach those to our squeak-app bundling job [1], which produces ready-to-run artifacts [2]. So, if you cannot manage to execute the macOS artifacts in this form, please report, compile yourself, and/or wait for a separate notification on the squeak-app bundles.

Best,
Marcel

[1] https://github.com/squeak-smalltalk/squeak-app/actions
[2] http://files.squeak.org/trunk/




Am 09.12.2021 10:57:56 schrieb Marcel Taeumel <marcel.taeumel at hpi.de>:

Hi all --

Please test this VM version:
https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202112022203 [https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/202112022203]


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

Best,
Marcel


Am 01.12.2021 10:38:47 schrieb Marcel Taeumel <marcel.taeumel at hpi.de>:
Hi all --

What's you overall feeling of having a new release candidate of the OSVM?

Overall pace has been decreasing during the last weeks. Maybe this is a good time then? Latest commit was about 10 hours ago. So, wait for 2-3 days and then tag that version, produce binaries and test those?

Best,
Marcel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20220106/b7302101/attachment-0001.html>