The VM included in the 5.3 package for the ARM linux systems is fatally broken due to a code generator bug; we had various discussions about the issue in mid-March. We also noticed a problem with the bitBLT code for all platforms that was fixed by VMMaker.oscog-nice.2732
We really need to push the magic buttons to replace the ARM package in order for it to run at all; updating the other platforms to fix bitBLT would be nice. A quick test of the next available VM on bintray suggests that the https://bintray.com/opensmalltalk/vm/download_file?file_path=squeak.cog.spur... version is functional - but maybe we want to use the latest?
What needs doing to solve this for the download page?
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- On permanent leave of absence from his senses.
Hi Tim!
Yes, let's make a new VM release to be used in Squeak 5.3 and 6.0alpha. I think we should start this dicussion on vm-dev, so I cross-post this.
Once we find a new candidate that was build after March 24 to fix the ARM bug you mentioned, we can update the CI and the bundles. (https://github.com/OpenSmalltalk/opensmalltalk-vm/releases [https://github.com/OpenSmalltalk/opensmalltalk-vm/releases])
That new release will then be copied over to the CI's base files: http://files.squeak.org/base/ [http://files.squeak.org/base/]
Once the new bundles are produced... http://files.squeak.org/5.3/ [http://files.squeak.org/5.3/]
http://files.squeak.org/6.0alpha/ [http://files.squeak.org/6.0alpha/] ...we can update squeak.org.
But first things first: We need to find a new release candidate for the VM to be tested at least a week. Tim proposed the following version:
202003291024
Eliot? Nicolas? Any thoughts on this?
Best, Marcel Am 18.04.2020 01:43:32 schrieb tim Rowledge tim@rowledge.org: The VM included in the 5.3 package for the ARM linux systems is fatally broken due to a code generator bug; we had various discussions about the issue in mid-March. We also noticed a problem with the bitBLT code for all platforms that was fixed by VMMaker.oscog-nice.2732
We really need to push the magic buttons to replace the ARM package in order for it to run at all; updating the other platforms to fix bitBLT would be nice. A quick test of the next available VM on bintray suggests that the https://bintray.com/opensmalltalk/vm/download_file?file_path=squeak.cog.spur... version is functional - but maybe we want to use the latest?
What needs doing to solve this for the download page?
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- On permanent leave of absence from his senses.
On Mon, Apr 20, 2020 at 8:39 AM Marcel Taeumel marcel.taeumel@hpi.de wrote:
Hi Tim!
Yes, let's make a new VM release to be used in Squeak 5.3 and 6.0alpha. I think we should start this dicussion on vm-dev, so I cross-post this.
Once we find a new candidate that was build after March 24 to fix the ARM bug you mentioned, we can update the CI and the bundles. ( https://github.com/OpenSmalltalk/opensmalltalk-vm/releases)
That new release will then be copied over to the CI's base files: http://files.squeak.org/base/
Once the new bundles are produced... http://files.squeak.org/5.3/ http://files.squeak.org/6.0alpha/ ...we can update squeak.org.
But first things first: We need to find a new release candidate for the VM to be tested at least a week. Tim proposed the following version:
202003291024
Eliot? Nicolas? Any thoughts on this?
Can we please use
CoInterpreter VMMaker.oscog-eem.2741 uuid: 809e8b1f-fe07-4d33-bfc1-db9e5ab13a99 Apr 15 2020 StackToRegisterMappingCogit VMMaker.oscog-eem.2739 uuid: b15f5d3d-0493-4edc-a9d3-4775bb9a21e5 Apr 15 2020 VM: 202004192151 CommitHash: 6e5241e
?
This has this one change that I'd like to be in the VM:
Spur: Make sure that becomeForward: answers a useful error code for read-only targets (when copyHash is true).
Best, Marcel
Am 18.04.2020 01:43:32 schrieb tim Rowledge tim@rowledge.org: The VM included in the 5.3 package for the ARM linux systems is fatally broken due to a code generator bug; we had various discussions about the issue in mid-March. We also noticed a problem with the bitBLT code for all platforms that was fixed by VMMaker.oscog-nice.2732
We really need to push the magic buttons to replace the ARM package in order for it to run at all; updating the other platforms to fix bitBLT would be nice. A quick test of the next available VM on bintray suggests that the https://bintray.com/opensmalltalk/vm/download_file?file_path=squeak.cog.spur... version is functional - but maybe we want to use the latest?
What needs doing to solve this for the download page?
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- On permanent leave of absence from his senses.
Hi Eliot.
Can we please use ... 202004192151 ...
Let's start running some tests with on this one.
Best, Marcel Am 21.04.2020 06:44:36 schrieb Eliot Miranda eliot.miranda@gmail.com:
On Mon, Apr 20, 2020 at 8:39 AM Marcel Taeumel <marcel.taeumel@hpi.de [mailto:marcel.taeumel@hpi.de]> wrote:
Hi Tim!
Yes, let's make a new VM release to be used in Squeak 5.3 and 6.0alpha. I think we should start this dicussion on vm-dev, so I cross-post this.
Once we find a new candidate that was build after March 24 to fix the ARM bug you mentioned, we can update the CI and the bundles. (https://github.com/OpenSmalltalk/opensmalltalk-vm/releases [https://github.com/OpenSmalltalk/opensmalltalk-vm/releases])
That new release will then be copied over to the CI's base files: http://files.squeak.org/base/ [http://files.squeak.org/base/]
Once the new bundles are produced... http://files.squeak.org/5.3/ [http://files.squeak.org/5.3/]
http://files.squeak.org/6.0alpha/ [http://files.squeak.org/6.0alpha/] ...we can update squeak.org [http://squeak.org].
But first things first: We need to find a new release candidate for the VM to be tested at least a week. Tim proposed the following version:
202003291024
Eliot? Nicolas? Any thoughts on this?
Can we please use
CoInterpreter VMMaker.oscog-eem.2741 uuid: 809e8b1f-fe07-4d33-bfc1-db9e5ab13a99 Apr 15 2020
StackToRegisterMappingCogit VMMaker.oscog-eem.2739 uuid: b15f5d3d-0493-4edc-a9d3-4775bb9a21e5 Apr 15 2020 VM: 202004192151 CommitHash: 6e5241e ?
This has this one change that I'd like to be in the VM:
Spur: Make sure that becomeForward: answers a useful error code for read-only targets (when copyHash is true).
Best, Marcel Am 18.04.2020 01:43:32 schrieb tim Rowledge <tim@rowledge.org [mailto:tim@rowledge.org]>: The VM included in the 5.3 package for the ARM linux systems is fatally broken due to a code generator bug; we had various discussions about the issue in mid-March. We also noticed a problem with the bitBLT code for all platforms that was fixed by VMMaker.oscog-nice.2732
We really need to push the magic buttons to replace the ARM package in order for it to run at all; updating the other platforms to fix bitBLT would be nice. A quick test of the next available VM on bintray suggests that the https://bintray.com/opensmalltalk/vm/download_file?file_path=squeak.cog.spur... [https://bintray.com/opensmalltalk/vm/download_file?file_path=squeak.cog.spur...] version is functional - but maybe we want to use the latest?
What needs doing to solve this for the download page?
tim -- tim Rowledge; tim@rowledge.org [mailto:tim@rowledge.org]; http://www.rowledge.org/tim [http://www.rowledge.org/tim] Useful random insult:- On permanent leave of absence from his senses.
--
_,,,^..^,,,_
best, Eliot
Well, there are no builds for that version. Are you referring to the build 202004210425? https://bintray.com/opensmalltalk/vm/cog/202004210425#files [https://bintray.com/opensmalltalk/vm/cog/202004210425#files]
So, that would be like bleeding edge, right? Are there any experiments going in these days? Could someone sum up what happened since mid March there?
Best, Marcel Am 21.04.2020 15:04:39 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hi Eliot.
Can we please use ... 202004192151 ...
Let's start running some tests with on this one.
Best, Marcel Am 21.04.2020 06:44:36 schrieb Eliot Miranda eliot.miranda@gmail.com:
On Mon, Apr 20, 2020 at 8:39 AM Marcel Taeumel <marcel.taeumel@hpi.de [mailto:marcel.taeumel@hpi.de]> wrote:
Hi Tim!
Yes, let's make a new VM release to be used in Squeak 5.3 and 6.0alpha. I think we should start this dicussion on vm-dev, so I cross-post this.
Once we find a new candidate that was build after March 24 to fix the ARM bug you mentioned, we can update the CI and the bundles. (https://github.com/OpenSmalltalk/opensmalltalk-vm/releases [https://github.com/OpenSmalltalk/opensmalltalk-vm/releases])
That new release will then be copied over to the CI's base files: http://files.squeak.org/base/ [http://files.squeak.org/base/]
Once the new bundles are produced... http://files.squeak.org/5.3/ [http://files.squeak.org/5.3/]
http://files.squeak.org/6.0alpha/ [http://files.squeak.org/6.0alpha/] ...we can update squeak.org [http://squeak.org].
But first things first: We need to find a new release candidate for the VM to be tested at least a week. Tim proposed the following version:
202003291024
Eliot? Nicolas? Any thoughts on this?
Can we please use
CoInterpreter VMMaker.oscog-eem.2741 uuid: 809e8b1f-fe07-4d33-bfc1-db9e5ab13a99 Apr 15 2020
StackToRegisterMappingCogit VMMaker.oscog-eem.2739 uuid: b15f5d3d-0493-4edc-a9d3-4775bb9a21e5 Apr 15 2020 VM: 202004192151 CommitHash: 6e5241e ?
This has this one change that I'd like to be in the VM:
Spur: Make sure that becomeForward: answers a useful error code for read-only targets (when copyHash is true).
Best, Marcel Am 18.04.2020 01:43:32 schrieb tim Rowledge <tim@rowledge.org [mailto:tim@rowledge.org]>: The VM included in the 5.3 package for the ARM linux systems is fatally broken due to a code generator bug; we had various discussions about the issue in mid-March. We also noticed a problem with the bitBLT code for all platforms that was fixed by VMMaker.oscog-nice.2732
We really need to push the magic buttons to replace the ARM package in order for it to run at all; updating the other platforms to fix bitBLT would be nice. A quick test of the next available VM on bintray suggests that the https://bintray.com/opensmalltalk/vm/download_file?file_path=squeak.cog.spur... [https://bintray.com/opensmalltalk/vm/download_file?file_path=squeak.cog.spur...] version is functional - but maybe we want to use the latest?
What needs doing to solve this for the download page?
tim -- tim Rowledge; tim@rowledge.org [mailto:tim@rowledge.org]; http://www.rowledge.org/tim [http://www.rowledge.org/tim] Useful random insult:- On permanent leave of absence from his senses.
--
_,,,^..^,,,_
best, Eliot
Hi Marcel,
On Tue, Apr 21, 2020 at 6:10 AM Marcel Taeumel marcel.taeumel@hpi.de wrote:
Well, there are no builds for that version. Are you referring to the build 202004210425? https://bintray.com/opensmalltalk/vm/cog/202004210425#files
So, that would be like bleeding edge, right? Are there any experiments going in these days? Could someone sum up what happened since mid March there?
Things are pretty stable. There was one major change to how the VM moves from machine code into the interpreter, replacing a setjmp/longjmp pair with a much lighter-weight "jump-call with substituted return address". But this "just works". We're able to perform experments without disturbinf=g trunk. SO for example, adding makefiles to allow building of the VM under clang-cl.exe on Windows was done without affecting the other builds at all.
Best, Marcel
Am 21.04.2020 15:04:39 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hi Eliot.
Can we please use ... 202004192151 ...
Let's start running some tests with on this one.
Best, Marcel
Am 21.04.2020 06:44:36 schrieb Eliot Miranda eliot.miranda@gmail.com:
On Mon, Apr 20, 2020 at 8:39 AM Marcel Taeumel marcel.taeumel@hpi.de wrote:
Hi Tim!
Yes, let's make a new VM release to be used in Squeak 5.3 and 6.0alpha. I think we should start this dicussion on vm-dev, so I cross-post this.
Once we find a new candidate that was build after March 24 to fix the ARM bug you mentioned, we can update the CI and the bundles. ( https://github.com/OpenSmalltalk/opensmalltalk-vm/releases)
That new release will then be copied over to the CI's base files: http://files.squeak.org/base/
Once the new bundles are produced... http://files.squeak.org/5.3/ http://files.squeak.org/6.0alpha/ ...we can update squeak.org.
But first things first: We need to find a new release candidate for the VM to be tested at least a week. Tim proposed the following version:
202003291024
Eliot? Nicolas? Any thoughts on this?
Can we please use
CoInterpreter VMMaker.oscog-eem.2741 uuid: 809e8b1f-fe07-4d33-bfc1-db9e5ab13a99 Apr 15 2020 StackToRegisterMappingCogit VMMaker.oscog-eem.2739 uuid: b15f5d3d-0493-4edc-a9d3-4775bb9a21e5 Apr 15 2020 VM: 202004192151 CommitHash: 6e5241e
?
This has this one change that I'd like to be in the VM:
Spur: Make sure that becomeForward: answers a useful error code forread-only targets (when copyHash is true).
Best, Marcel
Am 18.04.2020 01:43:32 schrieb tim Rowledge tim@rowledge.org: The VM included in the 5.3 package for the ARM linux systems is fatally broken due to a code generator bug; we had various discussions about the issue in mid-March. We also noticed a problem with the bitBLT code for all platforms that was fixed by VMMaker.oscog-nice.2732
We really need to push the magic buttons to replace the ARM package in order for it to run at all; updating the other platforms to fix bitBLT would be nice. A quick test of the next available VM on bintray suggests that the https://bintray.com/opensmalltalk/vm/download_file?file_path=squeak.cog.spur... version is functional - but maybe we want to use the latest?
What needs doing to solve this for the download page?
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- On permanent leave of absence from his senses.
-- _,,,^..^,,,_ best, Eliot
Hi Eliot,
thank you. That's good news. :-)
Best, Marcel Am 22.04.2020 02:12:27 schrieb Eliot Miranda eliot.miranda@gmail.com: Hi Marcel,
On Tue, Apr 21, 2020 at 6:10 AM Marcel Taeumel <marcel.taeumel@hpi.de [mailto:marcel.taeumel@hpi.de]> wrote:
Well, there are no builds for that version. Are you referring to the build 202004210425? https://bintray.com/opensmalltalk/vm/cog/202004210425#files [https://bintray.com/opensmalltalk/vm/cog/202004210425#files]
So, that would be like bleeding edge, right? Are there any experiments going in these days? Could someone sum up what happened since mid March there?
Things are pretty stable. There was one major change to how the VM moves from machine code into the interpreter, replacing a setjmp/longjmp pair with a much lighter-weight "jump-call with substituted return address". But this "just works". We're able to perform experments without disturbinf=g trunk. SO for example, adding makefiles to allow building of the VM under clang-cl.exe on Windows was done without affecting the other builds at all.
Best, Marcel Am 21.04.2020 15:04:39 schrieb Marcel Taeumel <marcel.taeumel@hpi.de [mailto:marcel.taeumel@hpi.de]>: Hi Eliot.
Can we please use ... 202004192151 ...
Let's start running some tests with on this one.
Best, Marcel Am 21.04.2020 06:44:36 schrieb Eliot Miranda <eliot.miranda@gmail.com [mailto:eliot.miranda@gmail.com]>:
On Mon, Apr 20, 2020 at 8:39 AM Marcel Taeumel <marcel.taeumel@hpi.de [mailto:marcel.taeumel@hpi.de]> wrote:
Hi Tim!
Yes, let's make a new VM release to be used in Squeak 5.3 and 6.0alpha. I think we should start this dicussion on vm-dev, so I cross-post this.
Once we find a new candidate that was build after March 24 to fix the ARM bug you mentioned, we can update the CI and the bundles. (https://github.com/OpenSmalltalk/opensmalltalk-vm/releases [https://github.com/OpenSmalltalk/opensmalltalk-vm/releases])
That new release will then be copied over to the CI's base files: http://files.squeak.org/base/ [http://files.squeak.org/base/]
Once the new bundles are produced... http://files.squeak.org/5.3/ [http://files.squeak.org/5.3/]
http://files.squeak.org/6.0alpha/ [http://files.squeak.org/6.0alpha/] ...we can update squeak.org [http://squeak.org].
But first things first: We need to find a new release candidate for the VM to be tested at least a week. Tim proposed the following version:
202003291024
Eliot? Nicolas? Any thoughts on this?
Can we please use
CoInterpreter VMMaker.oscog-eem.2741 uuid: 809e8b1f-fe07-4d33-bfc1-db9e5ab13a99 Apr 15 2020
StackToRegisterMappingCogit VMMaker.oscog-eem.2739 uuid: b15f5d3d-0493-4edc-a9d3-4775bb9a21e5 Apr 15 2020 VM: 202004192151 CommitHash: 6e5241e ?
This has this one change that I'd like to be in the VM:
Spur: Make sure that becomeForward: answers a useful error code for read-only targets (when copyHash is true).
Best, Marcel Am 18.04.2020 01:43:32 schrieb tim Rowledge <tim@rowledge.org [mailto:tim@rowledge.org]>: The VM included in the 5.3 package for the ARM linux systems is fatally broken due to a code generator bug; we had various discussions about the issue in mid-March. We also noticed a problem with the bitBLT code for all platforms that was fixed by VMMaker.oscog-nice.2732
We really need to push the magic buttons to replace the ARM package in order for it to run at all; updating the other platforms to fix bitBLT would be nice. A quick test of the next available VM on bintray suggests that the https://bintray.com/opensmalltalk/vm/download_file?file_path=squeak.cog.spur... [https://bintray.com/opensmalltalk/vm/download_file?file_path=squeak.cog.spur...] version is functional - but maybe we want to use the latest?
What needs doing to solve this for the download page?
tim -- tim Rowledge; tim@rowledge.org [mailto:tim@rowledge.org]; http://www.rowledge.org/tim [http://www.rowledge.org/tim] Useful random insult:- On permanent leave of absence from his senses.
--
_,,,^..^,,,_
best, Eliot
--
_,,,^..^,,,_
best, Eliot
... followed by some bad news: No, 202004210425 won't do it: https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/488 [https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/488]
Best, Marcel Am 22.04.2020 09:09:23 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hi Eliot,
thank you. That's good news. :-)
Best, Marcel Am 22.04.2020 02:12:27 schrieb Eliot Miranda eliot.miranda@gmail.com: Hi Marcel,
On Tue, Apr 21, 2020 at 6:10 AM Marcel Taeumel <marcel.taeumel@hpi.de [mailto:marcel.taeumel@hpi.de]> wrote:
Well, there are no builds for that version. Are you referring to the build 202004210425? https://bintray.com/opensmalltalk/vm/cog/202004210425#files [https://bintray.com/opensmalltalk/vm/cog/202004210425#files]
So, that would be like bleeding edge, right? Are there any experiments going in these days? Could someone sum up what happened since mid March there?
Things are pretty stable. There was one major change to how the VM moves from machine code into the interpreter, replacing a setjmp/longjmp pair with a much lighter-weight "jump-call with substituted return address". But this "just works". We're able to perform experments without disturbinf=g trunk. SO for example, adding makefiles to allow building of the VM under clang-cl.exe on Windows was done without affecting the other builds at all.
Best, Marcel Am 21.04.2020 15:04:39 schrieb Marcel Taeumel <marcel.taeumel@hpi.de [mailto:marcel.taeumel@hpi.de]>: Hi Eliot.
Can we please use ... 202004192151 ...
Let's start running some tests with on this one.
Best, Marcel Am 21.04.2020 06:44:36 schrieb Eliot Miranda <eliot.miranda@gmail.com [mailto:eliot.miranda@gmail.com]>:
On Mon, Apr 20, 2020 at 8:39 AM Marcel Taeumel <marcel.taeumel@hpi.de [mailto:marcel.taeumel@hpi.de]> wrote:
Hi Tim!
Yes, let's make a new VM release to be used in Squeak 5.3 and 6.0alpha. I think we should start this dicussion on vm-dev, so I cross-post this.
Once we find a new candidate that was build after March 24 to fix the ARM bug you mentioned, we can update the CI and the bundles. (https://github.com/OpenSmalltalk/opensmalltalk-vm/releases [https://github.com/OpenSmalltalk/opensmalltalk-vm/releases])
That new release will then be copied over to the CI's base files: http://files.squeak.org/base/ [http://files.squeak.org/base/]
Once the new bundles are produced... http://files.squeak.org/5.3/ [http://files.squeak.org/5.3/]
http://files.squeak.org/6.0alpha/ [http://files.squeak.org/6.0alpha/] ...we can update squeak.org [http://squeak.org].
But first things first: We need to find a new release candidate for the VM to be tested at least a week. Tim proposed the following version:
202003291024
Eliot? Nicolas? Any thoughts on this?
Can we please use
CoInterpreter VMMaker.oscog-eem.2741 uuid: 809e8b1f-fe07-4d33-bfc1-db9e5ab13a99 Apr 15 2020
StackToRegisterMappingCogit VMMaker.oscog-eem.2739 uuid: b15f5d3d-0493-4edc-a9d3-4775bb9a21e5 Apr 15 2020 VM: 202004192151 CommitHash: 6e5241e ?
This has this one change that I'd like to be in the VM:
Spur: Make sure that becomeForward: answers a useful error code for read-only targets (when copyHash is true).
Best, Marcel Am 18.04.2020 01:43:32 schrieb tim Rowledge <tim@rowledge.org [mailto:tim@rowledge.org]>: The VM included in the 5.3 package for the ARM linux systems is fatally broken due to a code generator bug; we had various discussions about the issue in mid-March. We also noticed a problem with the bitBLT code for all platforms that was fixed by VMMaker.oscog-nice.2732
We really need to push the magic buttons to replace the ARM package in order for it to run at all; updating the other platforms to fix bitBLT would be nice. A quick test of the next available VM on bintray suggests that the https://bintray.com/opensmalltalk/vm/download_file?file_path=squeak.cog.spur... [https://bintray.com/opensmalltalk/vm/download_file?file_path=squeak.cog.spur...] version is functional - but maybe we want to use the latest?
What needs doing to solve this for the download page?
tim -- tim Rowledge; tim@rowledge.org [mailto:tim@rowledge.org]; http://www.rowledge.org/tim [http://www.rowledge.org/tim] Useful random insult:- On permanent leave of absence from his senses.
--
_,,,^..^,,,_
best, Eliot
--
_,,,^..^,,,_
best, Eliot
Hi all!
I will now test 202004292351 [https://bintray.com/opensmalltalk/vm/cog/202004292351%5D%C2%A0as a release candidate for a new VM release to be also used in Squeak 5.3 to fix ARM support.
Best, Marcel Am 22.04.2020 10:31:29 schrieb Marcel Taeumel marcel.taeumel@hpi.de: ... followed by some bad news: No, 202004210425 won't do it: https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/488 [https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/488]
Best, Marcel Am 22.04.2020 09:09:23 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hi Eliot,
thank you. That's good news. :-)
Best, Marcel Am 22.04.2020 02:12:27 schrieb Eliot Miranda eliot.miranda@gmail.com: Hi Marcel,
On Tue, Apr 21, 2020 at 6:10 AM Marcel Taeumel <marcel.taeumel@hpi.de [mailto:marcel.taeumel@hpi.de]> wrote:
Well, there are no builds for that version. Are you referring to the build 202004210425? https://bintray.com/opensmalltalk/vm/cog/202004210425#files [https://bintray.com/opensmalltalk/vm/cog/202004210425#files]
So, that would be like bleeding edge, right? Are there any experiments going in these days? Could someone sum up what happened since mid March there?
Things are pretty stable. There was one major change to how the VM moves from machine code into the interpreter, replacing a setjmp/longjmp pair with a much lighter-weight "jump-call with substituted return address". But this "just works". We're able to perform experments without disturbinf=g trunk. SO for example, adding makefiles to allow building of the VM under clang-cl.exe on Windows was done without affecting the other builds at all.
Best, Marcel Am 21.04.2020 15:04:39 schrieb Marcel Taeumel <marcel.taeumel@hpi.de [mailto:marcel.taeumel@hpi.de]>: Hi Eliot.
Can we please use ... 202004192151 ...
Let's start running some tests with on this one.
Best, Marcel Am 21.04.2020 06:44:36 schrieb Eliot Miranda <eliot.miranda@gmail.com [mailto:eliot.miranda@gmail.com]>:
On Mon, Apr 20, 2020 at 8:39 AM Marcel Taeumel <marcel.taeumel@hpi.de [mailto:marcel.taeumel@hpi.de]> wrote:
Hi Tim!
Yes, let's make a new VM release to be used in Squeak 5.3 and 6.0alpha. I think we should start this dicussion on vm-dev, so I cross-post this.
Once we find a new candidate that was build after March 24 to fix the ARM bug you mentioned, we can update the CI and the bundles. (https://github.com/OpenSmalltalk/opensmalltalk-vm/releases [https://github.com/OpenSmalltalk/opensmalltalk-vm/releases])
That new release will then be copied over to the CI's base files: http://files.squeak.org/base/ [http://files.squeak.org/base/]
Once the new bundles are produced... http://files.squeak.org/5.3/ [http://files.squeak.org/5.3/]
http://files.squeak.org/6.0alpha/ [http://files.squeak.org/6.0alpha/] ...we can update squeak.org [http://squeak.org].
But first things first: We need to find a new release candidate for the VM to be tested at least a week. Tim proposed the following version:
202003291024
Eliot? Nicolas? Any thoughts on this?
Can we please use
CoInterpreter VMMaker.oscog-eem.2741 uuid: 809e8b1f-fe07-4d33-bfc1-db9e5ab13a99 Apr 15 2020
StackToRegisterMappingCogit VMMaker.oscog-eem.2739 uuid: b15f5d3d-0493-4edc-a9d3-4775bb9a21e5 Apr 15 2020 VM: 202004192151 CommitHash: 6e5241e ?
This has this one change that I'd like to be in the VM:
Spur: Make sure that becomeForward: answers a useful error code for read-only targets (when copyHash is true).
Best, Marcel Am 18.04.2020 01:43:32 schrieb tim Rowledge <tim@rowledge.org [mailto:tim@rowledge.org]>: The VM included in the 5.3 package for the ARM linux systems is fatally broken due to a code generator bug; we had various discussions about the issue in mid-March. We also noticed a problem with the bitBLT code for all platforms that was fixed by VMMaker.oscog-nice.2732
We really need to push the magic buttons to replace the ARM package in order for it to run at all; updating the other platforms to fix bitBLT would be nice. A quick test of the next available VM on bintray suggests that the https://bintray.com/opensmalltalk/vm/download_file?file_path=squeak.cog.spur... [https://bintray.com/opensmalltalk/vm/download_file?file_path=squeak.cog.spur...] version is functional - but maybe we want to use the latest?
What needs doing to solve this for the download page?
tim -- tim Rowledge; tim@rowledge.org [mailto:tim@rowledge.org]; http://www.rowledge.org/tim [http://www.rowledge.org/tim] Useful random insult:- On permanent leave of absence from his senses.
--
_,,,^..^,,,_
best, Eliot
--
_,,,^..^,,,_
best, Eliot
Looks good so far for Squeak 5.3 on a Surface Pro 6 (Windows 10). Only that AllocationTest >> #testOutOfMemorySignal is still an issue. But that's independent from this VM version.
Best, Marcel Am 30.04.2020 09:59:33 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hi all!
I will now test 202004292351 [https://bintray.com/opensmalltalk/vm/cog/202004292351%5D%C2%A0as a release candidate for a new VM release to be also used in Squeak 5.3 to fix ARM support.
Best, Marcel Am 22.04.2020 10:31:29 schrieb Marcel Taeumel marcel.taeumel@hpi.de: ... followed by some bad news: No, 202004210425 won't do it: https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/488 [https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/488]
Best, Marcel Am 22.04.2020 09:09:23 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hi Eliot,
thank you. That's good news. :-)
Best, Marcel Am 22.04.2020 02:12:27 schrieb Eliot Miranda eliot.miranda@gmail.com: Hi Marcel,
On Tue, Apr 21, 2020 at 6:10 AM Marcel Taeumel <marcel.taeumel@hpi.de [mailto:marcel.taeumel@hpi.de]> wrote:
Well, there are no builds for that version. Are you referring to the build 202004210425? https://bintray.com/opensmalltalk/vm/cog/202004210425#files [https://bintray.com/opensmalltalk/vm/cog/202004210425#files]
So, that would be like bleeding edge, right? Are there any experiments going in these days? Could someone sum up what happened since mid March there?
Things are pretty stable. There was one major change to how the VM moves from machine code into the interpreter, replacing a setjmp/longjmp pair with a much lighter-weight "jump-call with substituted return address". But this "just works". We're able to perform experments without disturbinf=g trunk. SO for example, adding makefiles to allow building of the VM under clang-cl.exe on Windows was done without affecting the other builds at all.
Best, Marcel Am 21.04.2020 15:04:39 schrieb Marcel Taeumel <marcel.taeumel@hpi.de [mailto:marcel.taeumel@hpi.de]>: Hi Eliot.
Can we please use ... 202004192151 ...
Let's start running some tests with on this one.
Best, Marcel Am 21.04.2020 06:44:36 schrieb Eliot Miranda <eliot.miranda@gmail.com [mailto:eliot.miranda@gmail.com]>:
On Mon, Apr 20, 2020 at 8:39 AM Marcel Taeumel <marcel.taeumel@hpi.de [mailto:marcel.taeumel@hpi.de]> wrote:
Hi Tim!
Yes, let's make a new VM release to be used in Squeak 5.3 and 6.0alpha. I think we should start this dicussion on vm-dev, so I cross-post this.
Once we find a new candidate that was build after March 24 to fix the ARM bug you mentioned, we can update the CI and the bundles. (https://github.com/OpenSmalltalk/opensmalltalk-vm/releases [https://github.com/OpenSmalltalk/opensmalltalk-vm/releases])
That new release will then be copied over to the CI's base files: http://files.squeak.org/base/ [http://files.squeak.org/base/]
Once the new bundles are produced... http://files.squeak.org/5.3/ [http://files.squeak.org/5.3/]
http://files.squeak.org/6.0alpha/ [http://files.squeak.org/6.0alpha/] ...we can update squeak.org [http://squeak.org].
But first things first: We need to find a new release candidate for the VM to be tested at least a week. Tim proposed the following version:
202003291024
Eliot? Nicolas? Any thoughts on this?
Can we please use
CoInterpreter VMMaker.oscog-eem.2741 uuid: 809e8b1f-fe07-4d33-bfc1-db9e5ab13a99 Apr 15 2020
StackToRegisterMappingCogit VMMaker.oscog-eem.2739 uuid: b15f5d3d-0493-4edc-a9d3-4775bb9a21e5 Apr 15 2020 VM: 202004192151 CommitHash: 6e5241e ?
This has this one change that I'd like to be in the VM:
Spur: Make sure that becomeForward: answers a useful error code for read-only targets (when copyHash is true).
Best, Marcel Am 18.04.2020 01:43:32 schrieb tim Rowledge <tim@rowledge.org [mailto:tim@rowledge.org]>: The VM included in the 5.3 package for the ARM linux systems is fatally broken due to a code generator bug; we had various discussions about the issue in mid-March. We also noticed a problem with the bitBLT code for all platforms that was fixed by VMMaker.oscog-nice.2732
We really need to push the magic buttons to replace the ARM package in order for it to run at all; updating the other platforms to fix bitBLT would be nice. A quick test of the next available VM on bintray suggests that the https://bintray.com/opensmalltalk/vm/download_file?file_path=squeak.cog.spur... [https://bintray.com/opensmalltalk/vm/download_file?file_path=squeak.cog.spur...] version is functional - but maybe we want to use the latest?
What needs doing to solve this for the download page?
tim -- tim Rowledge; tim@rowledge.org [mailto:tim@rowledge.org]; http://www.rowledge.org/tim [http://www.rowledge.org/tim] Useful random insult:- On permanent leave of absence from his senses.
--
_,,,^..^,,,_
best, Eliot
--
_,,,^..^,,,_
best, Eliot
On 2020-04-30, at 12:59 AM, Marcel Taeumel marcel.taeumel@hpi.de wrote:
Hi all!
I will now test 202004292351 as a release candidate for a new VM release to be also used in Squeak 5.3 to fix ARM support.
It looks 'mostly OK' to me. a) it doesn't segfault on startup; always a bonus. b) tinyBenchmarks are typical, so likely no broken cog mechanism c) running the full test suite - 4726 run, 38 expected failures, 5 failures, 17 errors.
The 6 failures include - TextAnchorTest>>#testResizeAnchoredMorph (anchoredMorph is shadowed and the self assert: priorExtent y + 15 equals: textMorph height. fails because priorExtent is 84 and textMorph height is 84 - so adding 15 isn't a happy maker
- HashedCollectionTest>>#testSizeFor fails because the very first value tested is 0 and we end up noticing the 0.0 / 5 is not > than 0.75.
- IntervalTest>>#testIntervalOfFloatLast fails because of floating point insanity. Will we ever be able to trust them?
- IntervalTest>>#testIntervalOfFloatReversed & #testSurprisingFuzzyInclusionBehavior same basic issue
The errors -
- AllocationTest>>#testOutOfMemorySignal fails to set the free space limit of 1.5 GB on a 4GB Pi
- 3 Decompiler tests fail because somebody thought using _ for := is still acceptable a million years after we changed that.
- DecompilerTests>>#testDecompilerInClassesVAtoVM fails because the first assert has conniptions over the tempVector having voted for trump
- 12 SqueakSSLTests fail because they know it would be annoying. Only the #testFaceBookAPI passes, which is also to be annoying.
Only the SSL failures seem like a potential problem here - does it indicate the plugin is borked?
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim "How many Trinoc does it take to change a lightbulb?” "Why do you want to know about our maintenance schedules? Are you planning to attack us in the dark?"
On 2020-05-06, at 5:55 PM, tim Rowledge tim@rowledge.org wrote:
Only the SSL failures seem like a potential problem here - does it indicate the plugin is borked?
D'oh - or is the example cert file in SqueakSSL out of date etc?
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim The world will end in 5 minutes. Please log out.
On 2020-05-06, at 6:02 PM, tim Rowledge tim@rowledge.org wrote:
On 2020-05-06, at 5:55 PM, tim Rowledge tim@rowledge.org wrote:
Only the SSL failures seem like a potential problem here - does it indicate the plugin is borked?
D'oh - or is the example cert file in SqueakSSL out of date etc?
Ah, maybe...
$ openssl x509 -in /Users/tim/Desktop/SqueakSSLCert.pem -----BEGIN CERTIFICATE----- MIICxTCCAi6gAwIBAgIJAN/0HUpkM5dvMA0GCSqGSIb3DQEBBQUAMEwxCzAJBgNV BAYTAkdCMRIwEAYDVQQIEwlCZXJrc2hpcmUxEDAOBgNVBAcTB05ld2J1cnkxFzAV BgNVBAoTDk15IENvbXBhbnkgTHRkMB4XDTExMDYwNjE0MzcyMFoXDTEyMDYwNTE0 MzcyMFowTDELMAkGA1UEBhMCR0IxEjAQBgNVBAgTCUJlcmtzaGlyZTEQMA4GA1UE BxMHTmV3YnVyeTEXMBUGA1UEChMOTXkgQ29tcGFueSBMdGQwgZ8wDQYJKoZIhvcN AQEBBQADgY0AMIGJAoGBAOcK/+DEMJvbKrXmqQ3Bi10w4d9brT0KTvB/CNWDNI2D 4fD7VHj6StaFhGxahdlRzL3E8L1aGcUIWKNydE5xanu8HJW6QWRU9iDOTU4EVPjz hkIsGZ7TwaotLNmuOC7tzVi7kz0xlB1ko5sG9nMMWye8Vxx8zsbmZf8WABNqxhot AgMBAAGjga4wgaswHQYDVR0OBBYEFGFwXmx2B6FB25yKMBm6g884lB2xMHwGA1Ud IwR1MHOAFGFwXmx2B6FB25yKMBm6g884lB2xoVCkTjBMMQswCQYDVQQGEwJHQjES MBAGA1UECBMJQmVya3NoaXJlMRAwDgYDVQQHEwdOZXdidXJ5MRcwFQYDVQQKEw5N eSBDb21wYW55IEx0ZIIJAN/0HUpkM5dvMAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcN AQEFBQADgYEAbjMF7YzNQGovKD4NRjsnnKzQnUCTw6UquY2Oz/5SeLcPfLm8DudF qppAjJjNpAgYC0yWoWcIxatYF/AsgGc2WL3hzI8oK7by6STfVi5RfLA6jS7lIDOv 4BUVsWZKADbEPsfiwed9b9MLLx8gpLLBrrr2rZpSyeDu4v16haV6wg8= -----END CERTIFICATE----- Diziet:~ tim$ openssl x509 -in /Users/tim/Desktop/SqueakSSLCert.pem -text Certificate: Data: Version: 3 (0x2) Serial Number: 16137555570121217903 (0xdff41d4a6433976f) Signature Algorithm: sha1WithRSAEncryption Issuer: C=GB, ST=Berkshire, L=Newbury, O=My Company Ltd Validity Not Before: Jun 6 14:37:20 2011 GMT Not After : Jun 5 14:37:20 2012 GMT Subject: C=GB, ST=Berkshire, L=Newbury, O=My Company Ltd
Tell me if I'm losing track of dates in the current crisis but I think Jun 2012 might have passed.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: IKI: Ignore Keyboard Input
On 07.05.2020, at 03:11, tim Rowledge tim@rowledge.org wrote:
On 2020-05-06, at 6:02 PM, tim Rowledge tim@rowledge.org wrote:
On 2020-05-06, at 5:55 PM, tim Rowledge tim@rowledge.org wrote:
Only the SSL failures seem like a potential problem here - does it indicate the plugin is borked?
D'oh - or is the example cert file in SqueakSSL out of date etc?
Ah, maybe...
$ openssl x509 -in /Users/tim/Desktop/SqueakSSLCert.pem -----BEGIN CERTIFICATE----- MIICxTCCAi6gAwIBAgIJAN/0HUpkM5dvMA0GCSqGSIb3DQEBBQUAMEwxCzAJBgNV BAYTAkdCMRIwEAYDVQQIEwlCZXJrc2hpcmUxEDAOBgNVBAcTB05ld2J1cnkxFzAV BgNVBAoTDk15IENvbXBhbnkgTHRkMB4XDTExMDYwNjE0MzcyMFoXDTEyMDYwNTE0 MzcyMFowTDELMAkGA1UEBhMCR0IxEjAQBgNVBAgTCUJlcmtzaGlyZTEQMA4GA1UE BxMHTmV3YnVyeTEXMBUGA1UEChMOTXkgQ29tcGFueSBMdGQwgZ8wDQYJKoZIhvcN AQEBBQADgY0AMIGJAoGBAOcK/+DEMJvbKrXmqQ3Bi10w4d9brT0KTvB/CNWDNI2D 4fD7VHj6StaFhGxahdlRzL3E8L1aGcUIWKNydE5xanu8HJW6QWRU9iDOTU4EVPjz hkIsGZ7TwaotLNmuOC7tzVi7kz0xlB1ko5sG9nMMWye8Vxx8zsbmZf8WABNqxhot AgMBAAGjga4wgaswHQYDVR0OBBYEFGFwXmx2B6FB25yKMBm6g884lB2xMHwGA1Ud IwR1MHOAFGFwXmx2B6FB25yKMBm6g884lB2xoVCkTjBMMQswCQYDVQQGEwJHQjES MBAGA1UECBMJQmVya3NoaXJlMRAwDgYDVQQHEwdOZXdidXJ5MRcwFQYDVQQKEw5N eSBDb21wYW55IEx0ZIIJAN/0HUpkM5dvMAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcN AQEFBQADgYEAbjMF7YzNQGovKD4NRjsnnKzQnUCTw6UquY2Oz/5SeLcPfLm8DudF qppAjJjNpAgYC0yWoWcIxatYF/AsgGc2WL3hzI8oK7by6STfVi5RfLA6jS7lIDOv 4BUVsWZKADbEPsfiwed9b9MLLx8gpLLBrrr2rZpSyeDu4v16haV6wg8= -----END CERTIFICATE----- Diziet:~ tim$ openssl x509 -in /Users/tim/Desktop/SqueakSSLCert.pem -text Certificate: Data: Version: 3 (0x2) Serial Number: 16137555570121217903 (0xdff41d4a6433976f) Signature Algorithm: sha1WithRSAEncryption Issuer: C=GB, ST=Berkshire, L=Newbury, O=My Company Ltd Validity Not Before: Jun 6 14:37:20 2011 GMT Not After : Jun 5 14:37:20 2012 GMT Subject: C=GB, ST=Berkshire, L=Newbury, O=My Company Ltd
Tell me if I'm losing track of dates in the current crisis but I think Jun 2012 might have passed.
I'd be rather impressed if the cert check suddenly passed on openssl :D ;) -t
Hey Tim!
Any updates on VM https://bintray.com/opensmalltalk/vm/cog/202004292351 [https://bintray.com/opensmalltalk/vm/cog/202004292351%5D%C2%A0? Would it work for 5.3 on ARM?
Best, Marcel Am 07.05.2020 09:32:01 schrieb Tobias Pape das.linux@gmx.de:
On 07.05.2020, at 03:11, tim Rowledge wrote:
On 2020-05-06, at 6:02 PM, tim Rowledge wrote:
On 2020-05-06, at 5:55 PM, tim Rowledge wrote:
Only the SSL failures seem like a potential problem here - does it indicate the plugin is borked?
D'oh - or is the example cert file in SqueakSSL out of date etc?
Ah, maybe...
$ openssl x509 -in /Users/tim/Desktop/SqueakSSLCert.pem -----BEGIN CERTIFICATE----- MIICxTCCAi6gAwIBAgIJAN/0HUpkM5dvMA0GCSqGSIb3DQEBBQUAMEwxCzAJBgNV BAYTAkdCMRIwEAYDVQQIEwlCZXJrc2hpcmUxEDAOBgNVBAcTB05ld2J1cnkxFzAV BgNVBAoTDk15IENvbXBhbnkgTHRkMB4XDTExMDYwNjE0MzcyMFoXDTEyMDYwNTE0 MzcyMFowTDELMAkGA1UEBhMCR0IxEjAQBgNVBAgTCUJlcmtzaGlyZTEQMA4GA1UE BxMHTmV3YnVyeTEXMBUGA1UEChMOTXkgQ29tcGFueSBMdGQwgZ8wDQYJKoZIhvcN AQEBBQADgY0AMIGJAoGBAOcK/+DEMJvbKrXmqQ3Bi10w4d9brT0KTvB/CNWDNI2D 4fD7VHj6StaFhGxahdlRzL3E8L1aGcUIWKNydE5xanu8HJW6QWRU9iDOTU4EVPjz hkIsGZ7TwaotLNmuOC7tzVi7kz0xlB1ko5sG9nMMWye8Vxx8zsbmZf8WABNqxhot AgMBAAGjga4wgaswHQYDVR0OBBYEFGFwXmx2B6FB25yKMBm6g884lB2xMHwGA1Ud IwR1MHOAFGFwXmx2B6FB25yKMBm6g884lB2xoVCkTjBMMQswCQYDVQQGEwJHQjES MBAGA1UECBMJQmVya3NoaXJlMRAwDgYDVQQHEwdOZXdidXJ5MRcwFQYDVQQKEw5N eSBDb21wYW55IEx0ZIIJAN/0HUpkM5dvMAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcN AQEFBQADgYEAbjMF7YzNQGovKD4NRjsnnKzQnUCTw6UquY2Oz/5SeLcPfLm8DudF qppAjJjNpAgYC0yWoWcIxatYF/AsgGc2WL3hzI8oK7by6STfVi5RfLA6jS7lIDOv 4BUVsWZKADbEPsfiwed9b9MLLx8gpLLBrrr2rZpSyeDu4v16haV6wg8= -----END CERTIFICATE----- Diziet:~ tim$ openssl x509 -in /Users/tim/Desktop/SqueakSSLCert.pem -text Certificate: Data: Version: 3 (0x2) Serial Number: 16137555570121217903 (0xdff41d4a6433976f) Signature Algorithm: sha1WithRSAEncryption Issuer: C=GB, ST=Berkshire, L=Newbury, O=My Company Ltd Validity Not Before: Jun 6 14:37:20 2011 GMT Not After : Jun 5 14:37:20 2012 GMT Subject: C=GB, ST=Berkshire, L=Newbury, O=My Company Ltd
Tell me if I'm losing track of dates in the current crisis but I think Jun 2012 might have passed.
I'd be rather impressed if the cert check suddenly passed on openssl :D ;) -t
On 2020-05-15, at 1:13 AM, Marcel Taeumel marcel.taeumel@hpi.de wrote:
Hey Tim!
Any updates on VM https://bintray.com/opensmalltalk/vm/cog/202004292351 ? Would it work for 5.3 on ARM?
Well, it works pretty well. I was doing all those tests last week/end though and there is the potential issue of the socket tests that fail (despite the fact that evidently sockets mostly work since I can do MC stuff!) etc.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Debugger: A tool that substitutes afterthought for forethought.
squeak-dev@lists.squeakfoundation.org
-
Eliot Miranda -
Marcel Taeumel -
tim Rowledge -
Tobias Pape