Oh pooh.
Download the release zip; extract, cd into the directory, run ./squeak.sh; boom.
The image is fine and runs OK with a slightly older VM build (5.0-201912311458).
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful Latin Phrases:- Mellita, domi adsum. = Honey, I'm home.
Hi Tim, Is it 5.3 or updated 6.0?
Le dim. 8 mars 2020 à 07:10, tim Rowledge tim@rowledge.org a écrit :
Oh pooh.
Download the release zip; extract, cd into the directory, run ./squeak.sh; boom.
The image is fine and runs OK with a slightly older VM build (5.0-201912311458).
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful Latin Phrases:- Mellita, domi adsum. = Honey, I'm home.
Hi,
I have the same result. Download the release to my Pi3, unzip, run, crash on startup.
The stack VM I built about 1 March works fine.
cheesr
bruce
What's a viable solution? Revert the ARMv6 VM to the one we used for Squeak 5.2?
Fabio
On Sun, 8 Mar 2020 at 10:01 am, Bruce O'Neel bruce.oneel@pckswarms.ch wrote:
Hi,
I have the same result. Download the release to my Pi3, unzip, run, crash on startup.
The stack VM I built about 1 March works fine.
cheesr
bruce
*08 March 2020 09:41 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com nicolas.cellier.aka.nice@gmail.com> wrote:*
Hi Tim, Is it 5.3 or updated 6.0?
Le dim. 8 mars 2020 à 07:10, tim Rowledge tim@rowledge.org a écrit :
Oh pooh.
Download the release zip; extract, cd into the directory, run ./squeak.sh; boom.
The image is fine and runs OK with a slightly older VM build (5.0-201912311458).
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful Latin Phrases:- Mellita, domi adsum. = Honey, I'm home.
<>
Hi all, several questions: - what test do we pass on CI for ARM? - can we debug it from the VMSimulator? I have compiled the GdbArmPlugin on macos, but I do not know how to force the simulator to use ISA ARMv5... What is the incantation?
Le dim. 8 mars 2020 à 10:10, Fabio Niephaus lists@fniephaus.com a écrit :
What's a viable solution? Revert the ARMv6 VM to the one we used for Squeak 5.2?
Fabio
On Sun, 8 Mar 2020 at 10:01 am, Bruce O'Neel bruce.oneel@pckswarms.ch wrote:
Hi,
I have the same result. Download the release to my Pi3, unzip, run, crash on startup.
The stack VM I built about 1 March works fine.
cheesr
bruce
*08 March 2020 09:41 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com nicolas.cellier.aka.nice@gmail.com> wrote:*
Hi Tim, Is it 5.3 or updated 6.0?
Le dim. 8 mars 2020 à 07:10, tim Rowledge tim@rowledge.org a écrit :
Oh pooh.
Download the release zip; extract, cd into the directory, run ./squeak.sh; boom.
The image is fine and runs OK with a slightly older VM build (5.0-201912311458).
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful Latin Phrases:- Mellita, domi adsum. = Honey, I'm home.
<>
On 2020-03-08, at 12:41 AM, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
Hi Tim, Is it 5.3 or updated 6.0?
The crash.dmp is fairly helpful here- downloaded package is for Squeak5.3-19431-32bit-202003021730-ARMv6
The specific VM - Squeak VM version: 5.0-202003021730 Tue Mar 3 09:42:45 UTC 2020 gcc 4.9.2 [Production Spur VM] Built from: CoInterpreter VMMaker.oscog-nice.2712 uuid: da64ef0b-fb0a-4770-ac16-f9b448234615 Mar 3 2020 With: StackToRegisterMappingCogit VMMaker.oscog-eem.2719 uuid: e40f3e94-3a54-411b-9613-5d19114ea131 Mar 3 2020 Revision: VM: 202003021730 https://github.com/OpenSmalltalk/opensmalltalk-vm.git Date: Mon Mar 2 18:30:55 2020 CommitHash: 6a0bc96 Plugins: 202003021730 https://github.com/OpenSmalltalk/opensmalltalk-vm.git Build host: Linux travis-job-97835d24-79f4-41d1-b7e9-c81bd8bf7149 4.4.0-104-generic #127~14.04.1-Ubuntu SMP Mon Dec 11 12:44:15 UTC 2017 armv7l GNU/Linux plugin path: /home/pi/Documents/Squeak/Squeak5.3-19431-32bit-202003021730-ARMv6/bin/ [default: /home/pi/Documents/Squeak/Squeak5.3-19431-32bit-202003021730-ARMv6/bin/]
The image is the absolute plain release image; it crashes so immediately that there isn't time to change anything at all.
From the stack etc it looks as if something within SmalltalkImage>setGCParameters (so immediately after the return from snapshot primitive) calls vsprintf() and has a little conniption. Not clear whether the issue is in the vmParameterAt: or the vmParameterAt:put: yet.
I'll try to peek at the vm code later but I'm pretty swamped right now.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim fallacio (n): speaking logical fallacies
On Sun, 8 Mar 2020 at 8:12 pm, tim Rowledge tim@rowledge.org wrote:
On 2020-03-08, at 12:41 AM, Nicolas Cellier <
nicolas.cellier.aka.nice@gmail.com> wrote:
Hi Tim, Is it 5.3 or updated 6.0?
The crash.dmp is fairly helpful here- downloaded package is for Squeak5.3-19431-32bit-202003021730-ARMv6
The specific VM - Squeak VM version: 5.0-202003021730 Tue Mar 3 09:42:45 UTC 2020 gcc 4.9.2 [Production Spur VM] Built from: CoInterpreter VMMaker.oscog-nice.2712 uuid: da64ef0b-fb0a-4770-ac16-f9b448234615 Mar 3 2020 With: StackToRegisterMappingCogit VMMaker.oscog-eem.2719 uuid: e40f3e94-3a54-411b-9613-5d19114ea131 Mar 3 2020 Revision: VM: 202003021730 https://github.com/OpenSmalltalk/opensmalltalk-vm.git Date: Mon Mar 2 18:30:55 2020 CommitHash: 6a0bc96 Plugins: 202003021730 https://github.com/OpenSmalltalk/opensmalltalk-vm.git Build host: Linux travis-job-97835d24-79f4-41d1-b7e9-c81bd8bf7149 4.4.0-104-generic #127~14.04.1-Ubuntu SMP Mon Dec 11 12:44:15 UTC 2017 armv7l GNU/Linux plugin path: /home/pi/Documents/Squeak/Squeak5.3-19431-32bit-202003021730-ARMv6/bin/ [default: /home/pi/Documents/Squeak/Squeak5.3-19431-32bit-202003021730-ARMv6/bin/]
The image is the absolute plain release image; it crashes so immediately that there isn't time to change anything at all.
We could just ship an older VM, right? I think it's fine to regenerate the ARMv6 bundles, especially if they are DOA anyway.
Fabio
From the stack etc it looks as if something within SmalltalkImage>setGCParameters (so immediately after the return from snapshot primitive) calls vsprintf() and has a little conniption. Not clear whether the issue is in the vmParameterAt: or the vmParameterAt:put: yet.
I'll try to peek at the vm code later but I'm pretty swamped right now.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim fallacio (n): speaking logical fallacies
I've just tested on a slightly older Raspbian install (the prior 'Stretch' version as opposed to the current 'Buster') and the crash.dmp is identical. So it's not a new OS issue.
On 2020-03-08, at 1:32 PM, Fabio Niephaus lists@fniephaus.com wrote:
We could just ship an older VM, right? I think it's fine to regenerate the ARMv6 bundles, especially if they are DOA anyway.
Well we could but I'd far rather know the cause. IIRC the release VM for ARMv6 is currently built using a cross-compiler- is that right?
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Programmer: One who is too lacking in people skills to be a software engineer.
On 2020-03-08, at 12:12 PM, tim Rowledge tim@rowledge.org wrote:
From the stack etc it looks as if something within SmalltalkImage>setGCParameters (so immediately after the return from snapshot primitive) calls vsprintf() and has a little conniption. Not clear whether the issue is in the vmParameterAt: or the vmParameterAt:put: yet.
OK, no particular helpful news from looking at the VM generated code; the vmParameterAt:put: case would seem to be using the code in src/vm/cointerp.c ll: 55603-8 where I see no plausible connection to vsprintf(). Sigh.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Don't document the program; program the document.
Hi, I have simulated the VM (nightly, it's too long),
| cos | cos := CogVMSimulator newWithOptions: #(Cogit StackToRegisterMappingCogit ObjectMemory Spur32BitCoMemoryManager ISA ARMv5 ). cos desiredNumStackPages: 8. cos openOn: 'Squeak5.3-19431-32bit.image'. cos openAsMorph; run
It starts normally thru simulator (I don't attach the screen snapshot, but it takes more than 2G byteCodes/241k sends to obtain the preference wizard)
Could the crash be related to the cross-compiler? Is it gcc or clang currently for ARM builds? On macos, -fsanitize=undefined notices a few unaligned memory access... Could it be a clue?
Le lun. 9 mars 2020 à 02:17, tim Rowledge tim@rowledge.org a écrit :
On 2020-03-08, at 12:12 PM, tim Rowledge tim@rowledge.org wrote:
From the stack etc it looks as if something within
SmalltalkImage>setGCParameters (so immediately after the return from snapshot primitive) calls vsprintf() and has a little conniption. Not clear whether the issue is in the vmParameterAt: or the vmParameterAt:put: yet.
OK, no particular helpful news from looking at the VM generated code; the vmParameterAt:put: case would seem to be using the code in src/vm/cointerp.c ll: 55603-8 where I see no plausible connection to vsprintf(). Sigh.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Don't document the program; program the document.
From extracts of the travis log
https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/jobs/657397531, I see that:
- we compile with gcc
gcc -std=gnu99 -g -O2 -DNDEBUG -DDEBUGVM=0 -DI_REALLY_DONT_CARE_HOW_UNSAFE_THIS_IS -DUSE_MIDI_ALSA -DCOGMTVM=0 -Wall -pthread -DLSB_FIRST=1 -march=armv6 -mfpu=vfp -mfloat-abi=hard -Wno-missing-braces -Wno-unknown-pragmas -Wno-unused-value -Wno-unused-label -Wno-unused-function -Wno-unused-variable -Wno-unused-but-set-variable -DHAVE_CONFIG_H -DSQUEAK_BUILTIN_PLUGIN snip...
- it is a rather old version
$ gcc --version
gcc (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4
- we do not seem to run tests for arm (would require setting up emulation on the CI for example qemu like https://www.tomaz.me/2013/12/02/running-travis-ci-tests-on-arm.html)
Le mer. 11 mars 2020 à 08:39, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> a écrit :
Hi, I have simulated the VM (nightly, it's too long),
| cos | cos := CogVMSimulator newWithOptions: #(Cogit StackToRegisterMappingCogit ObjectMemory Spur32BitCoMemoryManager ISA ARMv5 ). cos desiredNumStackPages: 8. cos openOn: 'Squeak5.3-19431-32bit.image'. cos openAsMorph; run
It starts normally thru simulator (I don't attach the screen snapshot, but it takes more than 2G byteCodes/241k sends to obtain the preference wizard)
Could the crash be related to the cross-compiler? Is it gcc or clang currently for ARM builds? On macos, -fsanitize=undefined notices a few unaligned memory access... Could it be a clue?
Le lun. 9 mars 2020 à 02:17, tim Rowledge tim@rowledge.org a écrit :
On 2020-03-08, at 12:12 PM, tim Rowledge tim@rowledge.org wrote:
From the stack etc it looks as if something within
SmalltalkImage>setGCParameters (so immediately after the return from snapshot primitive) calls vsprintf() and has a little conniption. Not clear whether the issue is in the vmParameterAt: or the vmParameterAt:put: yet.
OK, no particular helpful news from looking at the VM generated code; the vmParameterAt:put: case would seem to be using the code in src/vm/cointerp.c ll: 55603-8 where I see no plausible connection to vsprintf(). Sigh.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Don't document the program; program the document.
I'm not uptodate, it seems that Travis has more to offer: https://blog.travis-ci.com/2019-10-07-multi-cpu-architecture-support
Le mer. 11 mars 2020 à 11:38, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> a écrit :
From extracts of the travis log https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/jobs/657397531, I see that:
- we compile with gcc
gcc -std=gnu99 -g -O2 -DNDEBUG -DDEBUGVM=0 -DI_REALLY_DONT_CARE_HOW_UNSAFE_THIS_IS -DUSE_MIDI_ALSA -DCOGMTVM=0 -Wall -pthread -DLSB_FIRST=1 -march=armv6 -mfpu=vfp -mfloat-abi=hard -Wno-missing-braces -Wno-unknown-pragmas -Wno-unused-value -Wno-unused-label -Wno-unused-function -Wno-unused-variable -Wno-unused-but-set-variable -DHAVE_CONFIG_H -DSQUEAK_BUILTIN_PLUGIN snip...
- it is a rather old version
$ gcc --version
gcc (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4
- we do not seem to run tests for arm (would require setting up emulation
on the CI for example qemu like https://www.tomaz.me/2013/12/02/running-travis-ci-tests-on-arm.html)
Le mer. 11 mars 2020 à 08:39, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> a écrit :
Hi, I have simulated the VM (nightly, it's too long),
| cos | cos := CogVMSimulator newWithOptions: #(Cogit StackToRegisterMappingCogit ObjectMemory Spur32BitCoMemoryManager ISA ARMv5 ). cos desiredNumStackPages: 8. cos openOn: 'Squeak5.3-19431-32bit.image'. cos openAsMorph; run
It starts normally thru simulator (I don't attach the screen snapshot, but it takes more than 2G byteCodes/241k sends to obtain the preference wizard)
Could the crash be related to the cross-compiler? Is it gcc or clang currently for ARM builds? On macos, -fsanitize=undefined notices a few unaligned memory access... Could it be a clue?
Le lun. 9 mars 2020 à 02:17, tim Rowledge tim@rowledge.org a écrit :
On 2020-03-08, at 12:12 PM, tim Rowledge tim@rowledge.org wrote:
From the stack etc it looks as if something within
SmalltalkImage>setGCParameters (so immediately after the return from snapshot primitive) calls vsprintf() and has a little conniption. Not clear whether the issue is in the vmParameterAt: or the vmParameterAt:put: yet.
OK, no particular helpful news from looking at the VM generated code; the vmParameterAt:put: case would seem to be using the code in src/vm/cointerp.c ll: 55603-8 where I see no plausible connection to vsprintf(). Sigh.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Don't document the program; program the document.
My bad, it sounds OK for armV8, not so for v6... https://docs.travis-ci.com/user/multi-cpu-architectures/
Le mer. 11 mars 2020 à 11:43, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> a écrit :
I'm not uptodate, it seems that Travis has more to offer: https://blog.travis-ci.com/2019-10-07-multi-cpu-architecture-support
Le mer. 11 mars 2020 à 11:38, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> a écrit :
From extracts of the travis log https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/jobs/657397531, I see that:
- we compile with gcc
gcc -std=gnu99 -g -O2 -DNDEBUG -DDEBUGVM=0 -DI_REALLY_DONT_CARE_HOW_UNSAFE_THIS_IS -DUSE_MIDI_ALSA -DCOGMTVM=0 -Wall -pthread -DLSB_FIRST=1 -march=armv6 -mfpu=vfp -mfloat-abi=hard -Wno-missing-braces -Wno-unknown-pragmas -Wno-unused-value -Wno-unused-label -Wno-unused-function -Wno-unused-variable -Wno-unused-but-set-variable -DHAVE_CONFIG_H -DSQUEAK_BUILTIN_PLUGIN snip...
- it is a rather old version
$ gcc --version
gcc (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4
- we do not seem to run tests for arm (would require setting up emulation
on the CI for example qemu like https://www.tomaz.me/2013/12/02/running-travis-ci-tests-on-arm.html)
Le mer. 11 mars 2020 à 08:39, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> a écrit :
Hi, I have simulated the VM (nightly, it's too long),
| cos | cos := CogVMSimulator newWithOptions: #(Cogit StackToRegisterMappingCogit ObjectMemory Spur32BitCoMemoryManager ISA ARMv5 ). cos desiredNumStackPages: 8. cos openOn: 'Squeak5.3-19431-32bit.image'. cos openAsMorph; run
It starts normally thru simulator (I don't attach the screen snapshot, but it takes more than 2G byteCodes/241k sends to obtain the preference wizard)
Could the crash be related to the cross-compiler? Is it gcc or clang currently for ARM builds? On macos, -fsanitize=undefined notices a few unaligned memory access... Could it be a clue?
Le lun. 9 mars 2020 à 02:17, tim Rowledge tim@rowledge.org a écrit :
On 2020-03-08, at 12:12 PM, tim Rowledge tim@rowledge.org wrote:
From the stack etc it looks as if something within
SmalltalkImage>setGCParameters (so immediately after the return from snapshot primitive) calls vsprintf() and has a little conniption. Not clear whether the issue is in the vmParameterAt: or the vmParameterAt:put: yet.
OK, no particular helpful news from looking at the VM generated code; the vmParameterAt:put: case would seem to be using the code in src/vm/cointerp.c ll: 55603-8 where I see no plausible connection to vsprintf(). Sigh.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Don't document the program; program the document.
Are we not able to connect up a Pi to be used for these auto-builds? Or does it require machines at 'their' location (whoever 'they' is?)
On 2020-03-11, at 11:08 AM, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
My bad, it sounds OK for armV8, not so for v6... https://docs.travis-ci.com/user/multi-cpu-architectures/
Le mer. 11 mars 2020 à 11:43, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com a écrit : I'm not uptodate, it seems that Travis has more to offer: https://blog.travis-ci.com/2019-10-07-multi-cpu-architecture-support
Le mer. 11 mars 2020 à 11:38, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com a écrit : From extracts of the travis log https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/jobs/657397531, I see that:
- we compile with gcc
gcc -std=gnu99 -g -O2 -DNDEBUG -DDEBUGVM=0 -DI_REALLY_DONT_CARE_HOW_UNSAFE_THIS_IS -DUSE_MIDI_ALSA -DCOGMTVM=0 -Wall -pthread -DLSB_FIRST=1 -march=armv6 -mfpu=vfp -mfloat-abi=hard -Wno-missing-braces -Wno-unknown-pragmas -Wno-unused-value -Wno-unused-label -Wno-unused-function -Wno-unused-variable -Wno-unused-but-set-variable -DHAVE_CONFIG_H -DSQUEAK_BUILTIN_PLUGIN snip...
- it is a rather old version
$ gcc --version gcc (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4
- we do not seem to run tests for arm (would require setting up emulation on the CI for example qemu like https://www.tomaz.me/2013/12/02/running-travis-ci-tests-on-arm.html)
Le mer. 11 mars 2020 à 08:39, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com a écrit : Hi, I have simulated the VM (nightly, it's too long),
| cos | cos := CogVMSimulator newWithOptions: #(Cogit StackToRegisterMappingCogit ObjectMemory Spur32BitCoMemoryManager ISA ARMv5 ). cos desiredNumStackPages: 8. cos openOn: 'Squeak5.3-19431-32bit.image'. cos openAsMorph; run
It starts normally thru simulator (I don't attach the screen snapshot, but it takes more than 2G byteCodes/241k sends to obtain the preference wizard)
Could the crash be related to the cross-compiler? Is it gcc or clang currently for ARM builds? On macos, -fsanitize=undefined notices a few unaligned memory access... Could it be a clue?
Le lun. 9 mars 2020 à 02:17, tim Rowledge tim@rowledge.org a écrit :
On 2020-03-08, at 12:12 PM, tim Rowledge tim@rowledge.org wrote:
From the stack etc it looks as if something within SmalltalkImage>setGCParameters (so immediately after the return from snapshot primitive) calls vsprintf() and has a little conniption. Not clear whether the issue is in the vmParameterAt: or the vmParameterAt:put: yet.
OK, no particular helpful news from looking at the VM generated code; the vmParameterAt:put: case would seem to be using the code in src/vm/cointerp.c ll: 55603-8 where I see no plausible connection to vsprintf(). Sigh.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Don't document the program; program the document.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- A one-bit brain with a parity error.
I'm willing to do PI builds but for ARMv7 not v6.
cheers
bruce
Are we not able to connect up a Pi to be used for these auto-builds? Or does it require machines at 'their' location (whoever 'they' is?)
On 2020-03-11, at 11:08 AM, Nicolas Cellier wrote:
My bad, it sounds OK for armV8, not so for v6... https://docs.travis-ci.com/user/multi-cpu-architectures/
Le mer. 11 mars 2020 à 11:43, Nicolas Cellier a écrit : I'm not uptodate, it seems that Travis has more to offer: https://blog.travis-ci.com/2019-10-07-multi-cpu-architecture-support
Le mer. 11 mars 2020 à 11:38, Nicolas Cellier a écrit : From extracts of the travis log https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/jobs/657397531, I see that:
- we compile with gcc
gcc -std=gnu99 -g -O2 -DNDEBUG -DDEBUGVM=0 -DI_REALLY_DONT_CARE_HOW_UNSAFE_THIS_IS -DUSE_MIDI_ALSA -DCOGMTVM=0 -Wall -pthread -DLSB_FIRST=1 -march=armv6 -mfpu=vfp -mfloat-abi=hard -Wno-missing-braces -Wno-unknown-pragmas -Wno-unused-value -Wno-unused-label -Wno-unused-function -Wno-unused-variable -Wno-unused-but-set-variable -DHAVE_CONFIG_H -DSQUEAK_BUILTIN_PLUGIN snip...
- it is a rather old version
$ gcc --version gcc (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4
- we do not seem to run tests for arm (would require setting up emulation on the CI for example qemu like https://www.tomaz.me/2013/12/02/running-travis-ci-tests-on-arm.html)
Le mer. 11 mars 2020 à 08:39, Nicolas Cellier a écrit : Hi, I have simulated the VM (nightly, it's too long),
| cos | cos := CogVMSimulator newWithOptions: #(Cogit StackToRegisterMappingCogit ObjectMemory Spur32BitCoMemoryManager ISA ARMv5 ). cos desiredNumStackPages: 8. cos openOn: 'Squeak5.3-19431-32bit.image'. cos openAsMorph; run
It starts normally thru simulator (I don't attach the screen snapshot, but it takes more than 2G byteCodes/241k sends to obtain the preference wizard)
Could the crash be related to the cross-compiler? Is it gcc or clang currently for ARM builds? On macos, -fsanitize=undefined notices a few unaligned memory access... Could it be a clue?
Le lun. 9 mars 2020 à 02:17, tim Rowledge a écrit :
On 2020-03-08, at 12:12 PM, tim Rowledge wrote:
From the stack etc it looks as if something within SmalltalkImage>setGCParameters (so immediately after the return from snapshot primitive) calls vsprintf() and has a little conniption. Not clear whether the issue is in the vmParameterAt: or the vmParameterAt:put: yet.
OK, no particular helpful news from looking at the VM generated code; the vmParameterAt:put: case would seem to be using the code in src/vm/cointerp.c ll: 55603-8 where I see no plausible connection to vsprintf(). Sigh.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Don't document the program; program the document.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- A one-bit brain with a parity error.
If one has any Pi model it is best to use the default flags wrt architecture when compiling C; that way it will run on any Pi from the original (I still have a working example!) to a Pi 4 (when running the default Raspbian 32bit release). When the ARMv8/AARCH64 VM is released we will have a quite different set of issues to enjoy fixing.
On 2020-03-11, at 11:48 AM, Bruce O'Neel bruce.oneel@pckswarms.ch wrote:
I'm willing to do PI builds but for ARMv7 not v6.
cheers
bruce
11 March 2020 19:20 tim Rowledge tim@rowledge.org wrote: Are we not able to connect up a Pi to be used for these auto-builds? Or does it require machines at 'their' location (whoever 'they' is?)
On 2020-03-11, at 11:08 AM, Nicolas Cellier wrote:
My bad, it sounds OK for armV8, not so for v6... https://docs.travis-ci.com/user/multi-cpu-architectures/
Le mer. 11 mars 2020 à 11:43, Nicolas Cellier a écrit : I'm not uptodate, it seems that Travis has more to offer: https://blog.travis-ci.com/2019-10-07-multi-cpu-architecture-support
Le mer. 11 mars 2020 à 11:38, Nicolas Cellier a écrit : From extracts of the travis log https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/jobs/657397531, I see that:
- we compile with gcc
gcc -std=gnu99 -g -O2 -DNDEBUG -DDEBUGVM=0 -DI_REALLY_DONT_CARE_HOW_UNSAFE_THIS_IS -DUSE_MIDI_ALSA -DCOGMTVM=0 -Wall -pthread -DLSB_FIRST=1 -march=armv6 -mfpu=vfp -mfloat-abi=hard -Wno-missing-braces -Wno-unknown-pragmas -Wno-unused-value -Wno-unused-label -Wno-unused-function -Wno-unused-variable -Wno-unused-but-set-variable -DHAVE_CONFIG_H -DSQUEAK_BUILTIN_PLUGIN snip...
- it is a rather old version
$ gcc --version gcc (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4
- we do not seem to run tests for arm (would require setting up emulation on the CI for example qemu like https://www.tomaz.me/2013/12/02/running-travis-ci-tests-on-arm.html)
Le mer. 11 mars 2020 à 08:39, Nicolas Cellier a écrit : Hi, I have simulated the VM (nightly, it's too long),
| cos | cos := CogVMSimulator newWithOptions: #(Cogit StackToRegisterMappingCogit ObjectMemory Spur32BitCoMemoryManager ISA ARMv5 ). cos desiredNumStackPages: 8. cos openOn: 'Squeak5.3-19431-32bit.image'. cos openAsMorph; run
It starts normally thru simulator (I don't attach the screen snapshot, but it takes more than 2G byteCodes/241k sends to obtain the preference wizard)
Could the crash be related to the cross-compiler? Is it gcc or clang currently for ARM builds? On macos, -fsanitize=undefined notices a few unaligned memory access... Could it be a clue?
Le lun. 9 mars 2020 à 02:17, tim Rowledge a écrit :
On 2020-03-08, at 12:12 PM, tim Rowledge wrote:
From the stack etc it looks as if something within SmalltalkImage>setGCParameters (so immediately after the return from snapshot primitive) calls vsprintf() and has a little conniption. Not clear whether the issue is in the vmParameterAt: or the vmParameterAt:put: yet.
OK, no particular helpful news from looking at the VM generated code; the vmParameterAt:put: case would seem to be using the code in src/vm/cointerp.c ll: 55603-8 where I see no plausible connection to vsprintf(). Sigh.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Don't document the program; program the document.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- A one-bit brain with a parity error.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Common sense – so rare it’s a goddam superpower
Hi,
Ok. My build which doesn't do anything special shows this:
squeak: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 3.2.0, BuildID[sha1]=42e5a7da9312a9fbc187ff9f1390d4637b21ddf8, not stripped
I was more worried about testing, ie, if I build it on a PI3+ I wouldn't be confident that it ran on earlier ones without testing.
cheers
bruce
If one has any Pi model it is best to use the default flags wrt architecture when compiling C; that way it will run on any Pi from the original (I still have a working example!) to a Pi 4 (when running the default Raspbian 32bit release). When the ARMv8/AARCH64 VM is released we will have a quite different set of issues to enjoy fixing.
On 2020-03-11, at 11:48 AM, Bruce O'Neel wrote:
I'm willing to do PI builds but for ARMv7 not v6.
cheers
bruce
11 March 2020 19:20 tim Rowledge wrote: Are we not able to connect up a Pi to be used for these auto-builds? Or does it require machines at 'their' location (whoever 'they' is?)
On 2020-03-11, at 11:08 AM, Nicolas Cellier wrote:
My bad, it sounds OK for armV8, not so for v6... https://docs.travis-ci.com/user/multi-cpu-architectures/
Le mer. 11 mars 2020 à 11:43, Nicolas Cellier a écrit : I'm not uptodate, it seems that Travis has more to offer: https://blog.travis-ci.com/2019-10-07-multi-cpu-architecture-support
Le mer. 11 mars 2020 à 11:38, Nicolas Cellier a écrit : From extracts of the travis log https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/jobs/657397531, I see that:
- we compile with gcc
gcc -std=gnu99 -g -O2 -DNDEBUG -DDEBUGVM=0 -DI_REALLY_DONT_CARE_HOW_UNSAFE_THIS_IS -DUSE_MIDI_ALSA -DCOGMTVM=0 -Wall -pthread -DLSB_FIRST=1 -march=armv6 -mfpu=vfp -mfloat-abi=hard -Wno-missing-braces -Wno-unknown-pragmas -Wno-unused-value -Wno-unused-label -Wno-unused-function -Wno-unused-variable -Wno-unused-but-set-variable -DHAVE_CONFIG_H -DSQUEAK_BUILTIN_PLUGIN snip...
- it is a rather old version
$ gcc --version gcc (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4
- we do not seem to run tests for arm (would require setting up emulation on the CI for example qemu like https://www.tomaz.me/2013/12/02/running-travis-ci-tests-on-arm.html)
Le mer. 11 mars 2020 à 08:39, Nicolas Cellier a écrit : Hi, I have simulated the VM (nightly, it's too long),
| cos | cos := CogVMSimulator newWithOptions: #(Cogit StackToRegisterMappingCogit ObjectMemory Spur32BitCoMemoryManager ISA ARMv5 ). cos desiredNumStackPages: 8. cos openOn: 'Squeak5.3-19431-32bit.image'. cos openAsMorph; run
It starts normally thru simulator (I don't attach the screen snapshot, but it takes more than 2G byteCodes/241k sends to obtain the preference wizard)
Could the crash be related to the cross-compiler? Is it gcc or clang currently for ARM builds? On macos, -fsanitize=undefined notices a few unaligned memory access... Could it be a clue?
Le lun. 9 mars 2020 à 02:17, tim Rowledge a écrit :
On 2020-03-08, at 12:12 PM, tim Rowledge wrote:
From the stack etc it looks as if something within SmalltalkImage>setGCParameters (so immediately after the return from snapshot primitive) calls vsprintf() and has a little conniption. Not clear whether the issue is in the vmParameterAt: or the vmParameterAt:put: yet.
OK, no particular helpful news from looking at the VM generated code; the vmParameterAt:put: case would seem to be using the code in src/vm/cointerp.c ll: 55603-8 where I see no plausible connection to vsprintf(). Sigh.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Don't document the program; program the document.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- A one-bit brain with a parity error.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Common sense – so rare it’s a goddam superpower
On 2020-03-12, at 12:50 PM, Bruce O'Neel bruce.oneel@pckswarms.ch wrote:
Hi,
Ok. My build which doesn't do anything special shows this:
squeak: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 3.2.0, BuildID[sha1]=42e5a7da9312a9fbc187ff9f1390d4637b21ddf8, not stripped
I was more worried about testing, ie, if I build it on a PI3+ I wouldn't be confident that it ran on earlier ones without testing.
No problem; build on any Raspbian and will run on any Pi running Raspbian. It will be interesting to see how backward compatibility will be handled when RPF do decide to produce a 64bit Raspbian. There is an experimental 64 bit kernel that can support a 32bit userland and as 64 bit userland that can be run with nspawn or some similar named magic.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Fractured Idiom:- J'Y SUIS, J'Y PESTES - I can stay for the weekend
A bit of downloading and testing suggests that the 201912311458 build on bintray is the last one that actually works for ARMlinunx.
The next one - 202001240142 is a broken archive (45 bytes!) and all more recent ones segafault on startup.
Eliot & I spent a little time last night trying to work out what has happened and it appears to be a bit of a mess. We can't build a current VM because something has stopped the 'asasm' assembler tool working; we get an interesting
Fatal error: Failed to get ELF handle asasm: Error when writing object file 'BitBltArmSimdAlphaBlend.o'.
... that neither of us has ever seen before. That makes it really hard to use gdb to investigate what is going on.
More as it happens...
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful Latin Phrases:- Recedite, plebes! Gero rem imperialem! = Stand aside plebians! I am on imperial business.
On 2020-03-13, at 6:56 PM, tim Rowledge tim@rowledge.org wrote:
More as it happens...
Well, wasn't *that* fun.
a) sometihng 'interesting' has happened to the CIFS setup connecting my Pi to my iMac; somehow new files (as in stuff downloaded from github or files created and saved by the Pi) cannot be seen by *some* programs; like the asasm assembler for the fast bitblt code. This is goinf to be interesting to find a fix for.
b) as a workaround I copied the vm source tree onto my Pi SSD. Just in case it triggers any idea about the CIFS stuff I'll mention that it failed to handle the directory links relating to the alsa lib stuff
c) As best I recall the makefile/config stuff used to check for openGL include files and wouldn't try to make the B3DAcceleratorPlugin if they were absent. The current makefile tried to make it and that stalled the make and caused assorted other annoyance.
d) after installing (most of) the libraries listed in the HowToBuild (because libgl-mesa-dev is not found?), a clean build makes a vm that fails in the same way as the release vm
So at least we can now debug...
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Only playing with 51 cards.
Hi,
It looks like
sudo apt-get install libgl1-mesa-dev
replaces
sudo apt-get install libgl-mesa-dev
I'm guessing...
cheers
bruce
On 2020-03-13, at 6:56 PM, tim Rowledge wrote:
More as it happens...
Well, wasn't *that* fun.
a) sometihng 'interesting' has happened to the CIFS setup connecting my Pi to my iMac; somehow new files (as in stuff downloaded from github or files created and saved by the Pi) cannot be seen by *some* programs; like the asasm assembler for the fast bitblt code. This is goinf to be interesting to find a fix for.
b) as a workaround I copied the vm source tree onto my Pi SSD. Just in case it triggers any idea about the CIFS stuff I'll mention that it failed to handle the directory links relating to the alsa lib stuff
c) As best I recall the makefile/config stuff used to check for openGL include files and wouldn't try to make the B3DAcceleratorPlugin if they were absent. The current makefile tried to make it and that stalled the make and caused assorted other annoyance.
d) after installing (most of) the libraries listed in the HowToBuild (because libgl-mesa-dev is not found?), a clean build makes a vm that fails in the same way as the release vm
So at least we can now debug...
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Only playing with 51 cards.
On 2020-03-15, at 1:11 PM, Bruce O'Neel bruce.oneel@pckswarms.ch wrote:
Hi,
It looks like
sudo apt-get install libgl1-mesa-dev
replaces
sudo apt-get install libgl-mesa-dev
Looks like it; at least it built ok. Eventually we'll see if it works!
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Oxymorons: Act naturally
Hi,
So since I can seem to build things on my PI, I spent last evening running git bisects. What that came up with was below. The first bad commit does seem like somewhere things could go bad with 32 vs 64 bit, and, possibly unaligned access? Our main test case are the x86 and the x86-64 machines which are famous for doing unaligned access with few complaints. Now this claims that as of ARMv6 unaligned access is allowed and done in hardware. One wonders if it is completely correctly done, and, this isn't something in Debian/Raspberian, or the hardware, or ????
Of course, that might be a rabbit hole as well.
cheers
bruce /work/share/tmp/opensmalltalk-vm$ git bisect good
f5ec3f4fa2b61af86bbc2b82a1dabe5bfafe8f4e is the first bad commit
commit f5ec3f4fa2b61af86bbc2b82a1dabe5bfafe8f4e
Date: Wed Jan 8 10:55:18 2020 +0000
Fix type inconsistencies (int vs sqInt) (#464)
* Fix type inconsistencies (int vs sqInt)
Found by trying to compile with LTO enabled.
The VM compiles with the updated types on linux with or without LTO enabled (the LTO VM is not functional).
Didn't test with the OSes but changed the declarations in their files.
Affected functions:
- primInIOProcessEventsFlagAddress
- ioGatherEntropy
- GetAttributeString
- primitivePluginBrowserReady
- primitivePluginDestroyRequest
- primitivePluginRequestFileHandle
- primitivePluginRequestState
- primitivePluginRequestURL
- primitivePluginRequestURLStream
- primitivePluginPostURL
* Include sqMemoryAccess.h to have sqInt defined
:040000 040000 1488890eae3ef3147710b08b2cdf07b98e57b763 d6f7b25507a86fe9c5e618ccd03088598d9bc852 Mplatforms
:040000 040000 97c8f9d7a00839fa93d472a8840abec8c42ff45c 1e678e1e08e5badd258cce1a4a20d5c6243b39a8 Msrc
Last good commit
commit 0b4551db2e5c00f67502250d0336757ed12ab096
Merge: f219b7218 afbf9e015
Date: Mon Jan 6 17:08:45 2020 +0100
Merge pull request #466 from OpenSmalltalk/dtl/build-script-patch [ci skip]
Fix image MC loading glitch in image build scripts when checking pack…
With the last good commit I have a working ARM COG vm.
Image ----- /work/share/tmp/Squeak5.3-19431-32bit.image Squeak5.3 latest update: #19431 Current Change Set: HomeProject Image format 6521 (32 bit)
Virtual Machine --------------- /work/share/tmp/opensmalltalk-vm/build.linux32ARMv6/[squeak.cog.spur/build/squeak](http://squeak.cog.spur/build/squeak) Open Smalltalk Cog[Spur] VM [CoInterpreterPrimitives VMMaker.oscog-eem.2597] Unix built on Mar 16 2020 09:27:25 Compiler: 6.3.0 20170516 platform sources revision VM: 202001061608 :/work/share/tmp/opensmalltalk-vm Date: Mon Jan 6 17:08:45 2020 CommitHash: 0b4551db2 Plugins: 202001061608 :/work/share/tmp/opensmalltalk-vm CoInterpreter VMMaker.oscog-eem.2597 uuid: 7a69be2e-f0d0-4d41-9854-65432d621fed Mar 16 2020 StackToRegisterMappingCogit VMMaker.oscog-eem.2597 uuid: 7a69be2e-f0d0-4d41-9854-65432d621fed Mar 16 2020
To Build A Similar Virtual Machine ---------------------------------- Visit [https://github.com/OpenSmalltalk/opensmalltalk-vm%5D(https://github.com/Open...); follow the "Clone or download" instructions, then read the top-level README.md and HowToBuild files in the top-level build directory for your platform(s), build.macos64x64/HowToBuild, build.win32x86/HowToBuild, etc.
Image ----- /work/share/tmp/Squeak6.0alpha-19511-32bit.image Squeak6.0alpha latest update: #19511 Current Change Set: HomeProject Image format 6521 (32 bit)
Virtual Machine --------------- /work/share/tmp/opensmalltalk-vm/build.linux32ARMv6/[squeak.cog.spur/build/squeak](http://squeak.cog.spur/build/squeak) Open Smalltalk Cog[Spur] VM [CoInterpreterPrimitives VMMaker.oscog-eem.2597] Unix built on Mar 16 2020 09:27:25 Compiler: 6.3.0 20170516 platform sources revision VM: 202001061608 :/work/share/tmp/opensmalltalk-vm Date: Mon Jan 6 17:08:45 2020 CommitHash: 0b4551db2 Plugins: 202001061608 :/work/share/tmp/opensmalltalk-vm CoInterpreter VMMaker.oscog-eem.2597 uuid: 7a69be2e-f0d0-4d41-9854-65432d621fed Mar 16 2020 StackToRegisterMappingCogit VMMaker.oscog-eem.2597 uuid: 7a69be2e-f0d0-4d41-9854-65432d621fed Mar 16 2020
To Build A Similar Virtual Machine ---------------------------------- Visit [https://github.com/OpenSmalltalk/opensmalltalk-vm%5D(https://github.com/Open...); follow the "Clone or download" instructions, then read the top-level README.md and HowToBuild files in the top-level build directory for your platform(s), build.macos64x64/HowToBuild, build.win32x86/HowToBuild, etc.
Tiny Benchmarks --------------- 320,000,000 bytecodes/sec; 19,000,000 sends/sec
On 2020-03-15, at 1:11 PM, Bruce O'Neel wrote:
Hi,
It looks like
sudo apt-get install libgl1-mesa-dev
replaces
sudo apt-get install libgl-mesa-dev
Looks like it; at least it built ok. Eventually we'll see if it works!
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Oxymorons: Act naturally
HI,
If one wants to run this version you can download it from here.
[http://www.pckswarms.ch/arm/squeak.cog.spur_linux32ARMv6_20200106170845-all....)
Do not that the normal rules apply about downloading and running random programs off the internet.
% shasum -a 256 squeak.cog.spur_linux32ARMv6_20200106170845-all.tar.bz2
f3408bc075754a98b5656d7ccde3f3cad29d481940c4ec55ba80d721b0b940fa squeak.cog.spur_linux32ARMv6_20200106170845-all.tar.bz2
cheers
bruce
Hmm, the "bad" commit just replace int by sqInt which are equivalent on 32bits VM, I do not see what could go wrong on this side... It also include sqMemoryAccess.h, could it be that some macro in this file override an existing one? Is there any warning related in the LOG file?
In such case, what we can do is to compiled -Wall and diff the warning LOG produced by the two versions (good and bad).
Le lun. 16 mars 2020 à 10:35, Bruce O'Neel bruce.oneel@pckswarms.ch a écrit :
HI,
If one wants to run this version you can download it from here.
http://www.pckswarms.ch/arm/squeak.cog.spur_linux32ARMv6_20200106170845-all....
Do not that the normal rules apply about downloading and running random programs off the internet.
% shasum -a 256 squeak.cog.spur_linux32ARMv6_20200106170845-all.tar.bz2
f3408bc075754a98b5656d7ccde3f3cad29d481940c4ec55ba80d721b0b940fa squeak.cog.spur_linux32ARMv6_20200106170845-all.tar.bz2
cheers
bruce
*16 March 2020 09:55 "Bruce O'Neel" <bruce.oneel@pckswarms.ch bruce.oneel@pckswarms.ch> wrote:*
Hi,
So since I can seem to build things on my PI, I spent last evening running git bisects. What that came up with was below. The first bad commit does seem like somewhere things could go bad with 32 vs 64 bit, and, possibly unaligned access? Our main test case are the x86 and the x86-64 machines which are famous for doing unaligned access with few complaints.
Now this http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka15414.htm... claims that as of ARMv6 unaligned access is allowed and done in hardware. One wonders if it is completely correctly done, and, this isn't something in Debian/Raspberian, or the hardware, or ????
Of course, that might be a rabbit hole as well.
cheers
bruce
/work/share/tmp/opensmalltalk-vm$ git bisect good
f5ec3f4fa2b61af86bbc2b82a1dabe5bfafe8f4e is the first bad commit
commit f5ec3f4fa2b61af86bbc2b82a1dabe5bfafe8f4e
Author: smalltalking leves@caesar.elte.hu
Date: Wed Jan 8 10:55:18 2020 +0000
Fix type inconsistencies (int vs sqInt) (#464) * Fix type inconsistencies (int vs sqInt) Found by trying to compile with LTO enabled. The VM compiles with the updated types on linux with or without LTOenabled (the LTO VM is not functional).
Didn't test with the OSes but changed the declarations in their files. Affected functions: - primInIOProcessEventsFlagAddress - ioGatherEntropy - GetAttributeString - primitivePluginBrowserReady - primitivePluginDestroyRequest - primitivePluginRequestFileHandle - primitivePluginRequestState - primitivePluginRequestURL - primitivePluginRequestURLStream - primitivePluginPostURL * Include sqMemoryAccess.h to have sqInt defined:040000 040000 1488890eae3ef3147710b08b2cdf07b98e57b763 d6f7b25507a86fe9c5e618ccd03088598d9bc852 M platforms
:040000 040000 97c8f9d7a00839fa93d472a8840abec8c42ff45c 1e678e1e08e5badd258cce1a4a20d5c6243b39a8 M src
Last good commit
commit 0b4551db2e5c00f67502250d0336757ed12ab096
Merge: f219b7218 afbf9e015
Author: Fabio Niephaus code@fniephaus.com
Date: Mon Jan 6 17:08:45 2020 +0100
Merge pull request #466 from OpenSmalltalk/dtl/build-script-patch [ciskip]
Fix image MC loading glitch in image build scripts when checking pack…With the last good commit I have a working ARM COG vm.
Image
/work/share/tmp/Squeak5.3-19431-32bit.image Squeak5.3 latest update: #19431 Current Change Set: HomeProject Image format 6521 (32 bit)
Virtual Machine
/work/share/tmp/opensmalltalk-vm/build.linux32ARMv6/ squeak.cog.spur/build/squeak Open Smalltalk Cog[Spur] VM [CoInterpreterPrimitives VMMaker.oscog-eem.2597] Unix built on Mar 16 2020 09:27:25 Compiler: 6.3.0 20170516 platform sources revision VM: 202001061608 :/work/share/tmp/opensmalltalk-vm Date: Mon Jan 6 17:08:45 2020 CommitHash: 0b4551db2 Plugins: 202001061608 :/work/share/tmp/opensmalltalk-vm CoInterpreter VMMaker.oscog-eem.2597 uuid: 7a69be2e-f0d0-4d41-9854-65432d621fed Mar 16 2020 StackToRegisterMappingCogit VMMaker.oscog-eem.2597 uuid: 7a69be2e-f0d0-4d41-9854-65432d621fed Mar 16 2020
To Build A Similar Virtual Machine
Visit https://github.com/OpenSmalltalk/opensmalltalk-vm; follow the "Clone or download" instructions, then read the top-level README.md and HowToBuild files in the top-level build directory for your platform(s), build.macos64x64/HowToBuild, build.win32x86/HowToBuild, etc.
Image
/work/share/tmp/Squeak6.0alpha-19511-32bit.image Squeak6.0alpha latest update: #19511 Current Change Set: HomeProject Image format 6521 (32 bit)
Virtual Machine
/work/share/tmp/opensmalltalk-vm/build.linux32ARMv6/ squeak.cog.spur/build/squeak Open Smalltalk Cog[Spur] VM [CoInterpreterPrimitives VMMaker.oscog-eem.2597] Unix built on Mar 16 2020 09:27:25 Compiler: 6.3.0 20170516 platform sources revision VM: 202001061608 :/work/share/tmp/opensmalltalk-vm Date: Mon Jan 6 17:08:45 2020 CommitHash: 0b4551db2 Plugins: 202001061608 :/work/share/tmp/opensmalltalk-vm CoInterpreter VMMaker.oscog-eem.2597 uuid: 7a69be2e-f0d0-4d41-9854-65432d621fed Mar 16 2020 StackToRegisterMappingCogit VMMaker.oscog-eem.2597 uuid: 7a69be2e-f0d0-4d41-9854-65432d621fed Mar 16 2020
To Build A Similar Virtual Machine
Visit https://github.com/OpenSmalltalk/opensmalltalk-vm; follow the "Clone or download" instructions, then read the top-level README.md and HowToBuild files in the top-level build directory for your platform(s), build.macos64x64/HowToBuild, build.win32x86/HowToBuild, etc.
Tiny Benchmarks
320,000,000 bytecodes/sec; 19,000,000 sends/sec
*15 March 2020 23:39 tim Rowledge <tim@rowledge.org tim@rowledge.org> wrote:*
On 2020-03-15, at 1:11 PM, Bruce O'Neel wrote:
Hi,
It looks like
sudo apt-get install libgl1-mesa-dev
replaces
sudo apt-get install libgl-mesa-dev
Looks like it; at least it built ok. Eventually we'll see if it works!
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Oxymorons: Act naturally
<>
Hi Bruce,
(cc'd vm-dev list) That looks interesting. If you have a look at the output of
git diff 0b4551db2e5c00f67502250d0336757ed12ab096 f5ec3f4fa2b61af86bbc2b82a1dabe5bfafe8f4e
you'll see that only the type declarations of a few methods changed, and the only change is that int was rewritten to sqInt. On 32-bit platforms sqInt is int, so that commit should make no difference at all. (just saw that Nicolas had a look at this as well)
Are you sure that's the first bad commit?
The next commit (0f0b5324b6e41cda7f92c335d45e563d41285ccd) contains multiple arm specific changes according to its message. E.g.:
Fix old bug in ARM32 LoadEffectiveAddressMwrR Improve the ARM32 trampoline marshalling code fractionally.
A number of small improvements to context creation as part of
reversing the
order of comparison of the SPReg with anythin g else, to suit ARMv8.
Get the ARMv5 "stop" instruction (BKPT) correct.
Which version of gcc did you use to compile the VM?
Levente
On Mon, 16 Mar 2020, Bruce O'Neel wrote:
Hi,
So since I can seem to build things on my PI, I spent last evening running git bisects. What that came up with was below. The first bad commit does seem like somewhere things could go bad with 32 vs 64 bit, and, possibly unaligned access? Our main test case are the x86 and the x86-64 machines which are famous for doing unaligned access with few complaints.
Now this http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka15414.htm... that as of ARMv6 unaligned access is allowed and done in hardware. One wonders if it is completely correctly done, and, this isn't something in Debian/Raspberian, or the hardware, or ????
Of course, that might be a rabbit hole as well.
cheers
bruce
/work/share/tmp/opensmalltalk-vm$ git bisect good
f5ec3f4fa2b61af86bbc2b82a1dabe5bfafe8f4e is the first bad commit
commit f5ec3f4fa2b61af86bbc2b82a1dabe5bfafe8f4e
Author: smalltalking leves@caesar.elte.hu
Date: Wed Jan 8 10:55:18 2020 +0000
Fix type inconsistencies (int vs sqInt) (#464)
* Fix type inconsistencies (int vs sqInt)
Found by trying to compile with LTO enabled.
The VM compiles with the updated types on linux with or without LTO enabled (the LTO VM is not functional).
Didn't test with the OSes but changed the declarations in their files.
Affected functions:
- primInIOProcessEventsFlagAddress
- ioGatherEntropy
- GetAttributeString
- primitivePluginBrowserReady
- primitivePluginDestroyRequest
- primitivePluginRequestFileHandle
- primitivePluginRequestState
- primitivePluginRequestURL
- primitivePluginRequestURLStream
- primitivePluginPostURL
* Include sqMemoryAccess.h to have sqInt defined
:040000 040000 1488890eae3ef3147710b08b2cdf07b98e57b763 d6f7b25507a86fe9c5e618ccd03088598d9bc852 M platforms
:040000 040000 97c8f9d7a00839fa93d472a8840abec8c42ff45c 1e678e1e08e5badd258cce1a4a20d5c6243b39a8 M src
Last good commit
commit 0b4551db2e5c00f67502250d0336757ed12ab096
Merge: f219b7218 afbf9e015
Author: Fabio Niephaus code@fniephaus.com
Date: Mon Jan 6 17:08:45 2020 +0100
Merge pull request #466 from OpenSmalltalk/dtl/build-script-patch [ci skip]
Fix image MC loading glitch in image build scripts when checking pack…
With the last good commit I have a working ARM COG vm.
Image
/work/share/tmp/Squeak5.3-19431-32bit.image Squeak5.3 latest update: #19431 Current Change Set: HomeProject Image format 6521 (32 bit)
Virtual Machine
/work/share/tmp/opensmalltalk-vm/build.linux32ARMv6/squeak.cog.spur/build/squeak Open Smalltalk Cog[Spur] VM [CoInterpreterPrimitives VMMaker.oscog-eem.2597] Unix built on Mar 16 2020 09:27:25 Compiler: 6.3.0 20170516 platform sources revision VM: 202001061608 :/work/share/tmp/opensmalltalk-vm Date: Mon Jan 6 17:08:45 2020 CommitHash: 0b4551db2 Plugins: 202001061608 :/work/share/tmp/opensmalltalk-vm CoInterpreter VMMaker.oscog-eem.2597 uuid: 7a69be2e-f0d0-4d41-9854-65432d621fed Mar 16 2020 StackToRegisterMappingCogit VMMaker.oscog-eem.2597 uuid: 7a69be2e-f0d0-4d41-9854-65432d621fed Mar 16 2020
To Build A Similar Virtual Machine
Visit https://github.com/OpenSmalltalk/opensmalltalk-vm; follow the "Clone or download" instructions, then read the top-level README.md and HowToBuild files in the top-level build directory for your platform(s), build.macos64x64/HowToBuild, build.win32x86/HowToBuild, etc.
Image
/work/share/tmp/Squeak6.0alpha-19511-32bit.image Squeak6.0alpha latest update: #19511 Current Change Set: HomeProject Image format 6521 (32 bit)
Virtual Machine
/work/share/tmp/opensmalltalk-vm/build.linux32ARMv6/squeak.cog.spur/build/squeak Open Smalltalk Cog[Spur] VM [CoInterpreterPrimitives VMMaker.oscog-eem.2597] Unix built on Mar 16 2020 09:27:25 Compiler: 6.3.0 20170516 platform sources revision VM: 202001061608 :/work/share/tmp/opensmalltalk-vm Date: Mon Jan 6 17:08:45 2020 CommitHash: 0b4551db2 Plugins: 202001061608 :/work/share/tmp/opensmalltalk-vm CoInterpreter VMMaker.oscog-eem.2597 uuid: 7a69be2e-f0d0-4d41-9854-65432d621fed Mar 16 2020 StackToRegisterMappingCogit VMMaker.oscog-eem.2597 uuid: 7a69be2e-f0d0-4d41-9854-65432d621fed Mar 16 2020
To Build A Similar Virtual Machine
Visit https://github.com/OpenSmalltalk/opensmalltalk-vm; follow the "Clone or download" instructions, then read the top-level README.md and HowToBuild files in the top-level build directory for your platform(s), build.macos64x64/HowToBuild, build.win32x86/HowToBuild, etc.
Tiny Benchmarks
320,000,000 bytecodes/sec; 19,000,000 sends/sec
15 March 2020 23:39 tim Rowledge tim@rowledge.org wrote:
On 2020-03-15, at 1:11 PM, Bruce O'Neel wrote:
Hi,
It looks like
sudo apt-get install libgl1-mesa-dev
replaces
sudo apt-get install libgl-mesa-dev
Looks like it; at least it built ok. Eventually we'll see if it works!
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Oxymorons: Act naturally
(cc'd vm-dev for real)
On Mon, 16 Mar 2020, Levente Uzonyi wrote:
Hi Bruce,
(cc'd vm-dev list) That looks interesting. If you have a look at the output of
git diff 0b4551db2e5c00f67502250d0336757ed12ab096 f5ec3f4fa2b61af86bbc2b82a1dabe5bfafe8f4e
you'll see that only the type declarations of a few methods changed, and the only change is that int was rewritten to sqInt. On 32-bit platforms sqInt is int, so that commit should make no difference at all. (just saw that Nicolas had a look at this as well)
Are you sure that's the first bad commit?
The next commit (0f0b5324b6e41cda7f92c335d45e563d41285ccd) contains multiple arm specific changes according to its message. E.g.:
Fix old bug in ARM32 LoadEffectiveAddressMwrR Improve the ARM32 trampoline marshalling code fractionally.
A number of small improvements to context creation as part of
reversing the
order of comparison of the SPReg with anythin g else, to suit ARMv8.
Get the ARMv5 "stop" instruction (BKPT) correct.
Which version of gcc did you use to compile the VM?
Levente
On Mon, 16 Mar 2020, Bruce O'Neel wrote:
Hi,
So since I can seem to build things on my PI, I spent last evening running git bisects. What that came up with was below. The first bad commit does seem like somewhere things could go bad with 32 vs 64 bit, and, possibly unaligned access? Our main test case are the x86 and the x86-64 machines which are famous for doing unaligned access with few complaints.
Now this http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka15414.htm... that as of ARMv6 unaligned access is allowed and done in hardware. One wonders if it is completely correctly done, and, this isn't something in Debian/Raspberian, or the hardware, or ????
Of course, that might be a rabbit hole as well.
cheers
bruce
/work/share/tmp/opensmalltalk-vm$ git bisect good
f5ec3f4fa2b61af86bbc2b82a1dabe5bfafe8f4e is the first bad commit
commit f5ec3f4fa2b61af86bbc2b82a1dabe5bfafe8f4e
Author: smalltalking leves@caesar.elte.hu
Date: Wed Jan 8 10:55:18 2020 +0000
Fix type inconsistencies (int vs sqInt) (#464)
* Fix type inconsistencies (int vs sqInt)
Found by trying to compile with LTO enabled.
The VM compiles with the updated types on linux with or without LTO enabled (the LTO VM is not functional).
Didn't test with the OSes but changed the declarations in their files.
Affected functions:
- primInIOProcessEventsFlagAddress
- ioGatherEntropy
- GetAttributeString
- primitivePluginBrowserReady
- primitivePluginDestroyRequest
- primitivePluginRequestFileHandle
- primitivePluginRequestState
- primitivePluginRequestURL
- primitivePluginRequestURLStream
- primitivePluginPostURL
* Include sqMemoryAccess.h to have sqInt defined
:040000 040000 1488890eae3ef3147710b08b2cdf07b98e57b763 d6f7b25507a86fe9c5e618ccd03088598d9bc852 M platforms
:040000 040000 97c8f9d7a00839fa93d472a8840abec8c42ff45c 1e678e1e08e5badd258cce1a4a20d5c6243b39a8 M src
Last good commit
commit 0b4551db2e5c00f67502250d0336757ed12ab096
Merge: f219b7218 afbf9e015
Author: Fabio Niephaus code@fniephaus.com
Date: Mon Jan 6 17:08:45 2020 +0100
Merge pull request #466 from OpenSmalltalk/dtl/build-script-patch [ci skip]
Fix image MC loading glitch in image build scripts when checking pack…
With the last good commit I have a working ARM COG vm.
Image
/work/share/tmp/Squeak5.3-19431-32bit.image Squeak5.3 latest update: #19431 Current Change Set: HomeProject Image format 6521 (32 bit)
Virtual Machine
/work/share/tmp/opensmalltalk-vm/build.linux32ARMv6/squeak.cog.spur/build/squeak Open Smalltalk Cog[Spur] VM [CoInterpreterPrimitives VMMaker.oscog-eem.2597] Unix built on Mar 16 2020 09:27:25 Compiler: 6.3.0 20170516 platform sources revision VM: 202001061608 :/work/share/tmp/opensmalltalk-vm Date: Mon Jan 6 17:08:45 2020 CommitHash: 0b4551db2 Plugins: 202001061608 :/work/share/tmp/opensmalltalk-vm CoInterpreter VMMaker.oscog-eem.2597 uuid: 7a69be2e-f0d0-4d41-9854-65432d621fed Mar 16 2020 StackToRegisterMappingCogit VMMaker.oscog-eem.2597 uuid: 7a69be2e-f0d0-4d41-9854-65432d621fed Mar 16 2020
To Build A Similar Virtual Machine
Visit https://github.com/OpenSmalltalk/opensmalltalk-vm; follow the "Clone or download" instructions, then read the top-level README.md and HowToBuild files in the top-level build directory for your platform(s), build.macos64x64/HowToBuild, build.win32x86/HowToBuild, etc.
Image
/work/share/tmp/Squeak6.0alpha-19511-32bit.image Squeak6.0alpha latest update: #19511 Current Change Set: HomeProject Image format 6521 (32 bit)
Virtual Machine
/work/share/tmp/opensmalltalk-vm/build.linux32ARMv6/squeak.cog.spur/build/squeak Open Smalltalk Cog[Spur] VM [CoInterpreterPrimitives VMMaker.oscog-eem.2597] Unix built on Mar 16 2020 09:27:25 Compiler: 6.3.0 20170516 platform sources revision VM: 202001061608 :/work/share/tmp/opensmalltalk-vm Date: Mon Jan 6 17:08:45 2020 CommitHash: 0b4551db2 Plugins: 202001061608 :/work/share/tmp/opensmalltalk-vm CoInterpreter VMMaker.oscog-eem.2597 uuid: 7a69be2e-f0d0-4d41-9854-65432d621fed Mar 16 2020 StackToRegisterMappingCogit VMMaker.oscog-eem.2597 uuid: 7a69be2e-f0d0-4d41-9854-65432d621fed Mar 16 2020
To Build A Similar Virtual Machine
Visit https://github.com/OpenSmalltalk/opensmalltalk-vm; follow the "Clone or download" instructions, then read the top-level README.md and HowToBuild files in the top-level build directory for your platform(s), build.macos64x64/HowToBuild, build.win32x86/HowToBuild, etc.
Tiny Benchmarks
320,000,000 bytecodes/sec; 19,000,000 sends/sec
15 March 2020 23:39 tim Rowledge tim@rowledge.org wrote:
On 2020-03-15, at 1:11 PM, Bruce O'Neel wrote:
Hi,
It looks like
sudo apt-get install libgl1-mesa-dev
replaces
sudo apt-get install libgl-mesa-dev
Looks like it; at least it built ok. Eventually we'll see if it works!
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Oxymorons: Act naturally
Thanks for banging on the bisect thing Bruce. I gave up yesterday when cloning the repository to my Pi was running. Well, crawling, at the time.
On 2020-03-16, at 9:33 AM, Levente Uzonyi leves@caesar.elte.hu wrote:
Fix old bug in ARM32 LoadEffectiveAddressMwrR
Looking back at a last November version of cogitARMv5.c and the implementation/translation of LoadEffectiveAddressMwrR I see that there seems now to be a missing calculation of the immediate5 and rot5 in
5259: /* begin machineCodeAt:put: */ aWord42 = addrnimmror(self_in_dispatchConcretize, destReg1, srcReg9, immediate5, rot5);
by comparison in the (working) older file it is
5158: rot4 = 32 - i4; immediate4 = (((usqInt) offset27) >> i4) | ((offset27 << (32 - i4)) & 0xFFFFFFFFU); /* begin machineCodeAt:put: */ aWord37 = addrnimmror(self_in_dispatchConcretize, destReg1, srcReg7, immediate4, ((sqInt)((usqInt)(rot4) << 1)));
A bit of scanning shows immediate5 is never set, which rarely works out well...
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful Latin Phrases:- Vacca foeda = Stupid cow
As a side issue here, does anyone have a pointer to an intelligible document about using git? I've tried assorted sources and so far none of it really makes a lot of sense. I can manage a `git clone URL` and that's about it. How can I get a particular historical version, for example?
Are any of the dummies guide or similar things available online? A good tutorial?
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim You never finish a program, you just stop working on it.
tim Rowledge tim@rowledge.org schrieb am Mo., 16. März 2020, 18:47:
I can manage a `git clone URL` and that's about it. How can I get a particular historical version, for example?
After the clone, you can do (in the cloned directory)
git checkout <commit-id/sha-1>
And your directory will contain the tree as it was at that version.
(If you want to use this clone for further work, you must go back to a branch before you create new commits: git checkout <branchname>)
It looks like sometihng caused the CogARMCompiler>>#rotateable8bitImmediate:ifTrue:ifFalse: to get translated in a way that messes up the block args for the falseBlock (which are supposed to be the requird rotation and immediate values.
What we get is /* begin rotateable8bitImmediate:ifTrue:ifFalse: */ if ((offset27 & 0xFF) == offset27) { /* begin machineCodeAt:put: */ aWord42 = addrnimmror(self_in_dispatchConcretize, destReg1, srcReg9, immediate5, rot5); ((self_in_dispatchConcretize->machineCode))[0 / 4] = aWord42; return 4; } for (i5 = 2; i5 <= 30; i5 += 2) { if ((offset27 & (((0xFFU << i5) & 0xFFFFFFFFU) | (((usqInt)(0xFF)) >> (32 - i5)))) == offset27) { /* begin machineCodeAt:put: */ aWord42 = addrnimmror(self_in_dispatchConcretize, destReg1, srcReg9, immediate5, rot5); ((self_in_dispatchConcretize->machineCode))[0 / 4] = aWord42; return 4; } } ... when we should get more like -
/* begin rotateable8bitImmediate:ifTrue:ifFalse: */ if ((offset27 & 0xFF) == offset27) { /* begin machineCodeAt:put: */ aWord37 = addrnimmror(self_in_dispatchConcretize, destReg1, srcReg7, offset27, 0U << 1); ((self_in_dispatchConcretize->machineCode))[0 / 4] = aWord37; (self_in_dispatchConcretize->machineCodeSize) = 4; goto l204; } for (i4 = 2; i4 <= 30; i4 += 2) { if ((offset27 & (((0xFFU << i4) & 0xFFFFFFFFU) | (((usqInt) 0xFF) >> (32 - i4)))) == offset27) {
>> rot4 = 32 - i4; <<<<<<<<<<< >> immediate4 = (((usqInt) offset27) >> i4) | ((offset27 << (32 - i4)) & 0xFFFFFFFFU); <<<<<<<<<<<
/* begin machineCodeAt:put: */ aWord37 = addrnimmror(self_in_dispatchConcretize, destReg1, srcReg7, immediate4, ((sqInt)((usqInt)(rot4) << 1))); ((self_in_dispatchConcretize->machineCode))[0 / 4] = aWord37; (self_in_dispatchConcretize->machineCodeSize) = 4; goto l204; } } (ignoring for a moment the desired change in the last couple of lines)
The actual code for CogARMCompiler>>#rotateable8bitImmediate:ifTrue:ifFalse: hasn't changed since 2015 so it's some other part of the system at fault. Do I recall correctly that some changes were recently made in the translator stuff for type-fiddling?
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Don't diddle code to make it faster; find a better algorithm.
Hi,
Something to remember about git bisect is that it's a binary search.
You give it a working version, I chose one from 31 May 2019, and a broken one, current, and it does the binary search where it makes a checkout the current one, and, you build and test. Then you say that it's good or bad.
But...... And this is very important. You have to say that a version is bad if it does not produce a working binary. The assumption is that there is one broken commit, and, therefore a binary search will work.
It assumes that the problem is below, with Y means good and N means bad.
YYYYYYYYYYYYYYYYNNNNNNNNN
It will find the transition between Y and N correctly. If on the other hand you have something like this, again with Y is good and N is bad:
YYYYYYYYYYYYYNNNNNNNNNNYYNNN
It will find likely find the first transition of Y to N, not the second which is the one you want to find. It would depend totally on which start point one chooses.
I can rerun bisect with a different start and see what happens. Since I'm Day Drinking, sorry, working from home, I can setup the build system next to my work computer and run it that way.
cheers
bruce
P.S. If you want to try this at home, I do
untar an existing checkout from sometime in march. build, confirm it fails.
git bisect start git bisect bad git bisect good somecheckoutthatisthoughttowork
Now rerun the build and check, if it's good
git bisect good
and if bad then
git bisect bad
after a few seconds it will move you to the next version to check, and, you can rebuild again.
Repeat until either of the good/bad git bisect commands tells you which is the first bad checkout.
cheers
bruce
Hi All,
apologies; this is my bug. Having revived my Raspberry 3 build machine I've just reproduced the crash and can see that it's a code generator bug. The very first JITted method executed answers SmalltalkImage current. The code generated for this should be
0x4018e8: ldr r0, [pc, #8] ; 0x4018f8 0x4018ec: ldr r7, [r0, #8] 0x4018f0: mov r5, r7 0x4018f4: mov pc, lr
but is alas
0x4018e8: ldr r0, [pc, #8] ; 0x4018f8 0x4018ec: ldr r7, [r0, #-0] 0x4018f0: mov r5, r7 0x4018f4: mov pc, lr
I have to find out why this does't fail in the simulator (or find out that it does and that my recollection of having tested 32-bit ARM recently is, in fact, a self-serving hallucination). Hopefully normal service should be restored presently. But it does mean releasing an updated Squeak5.3 release with a fixed VM. Again, apologies.
On Sat, Mar 7, 2020 at 10:10 PM tim Rowledge tim@rowledge.org wrote:
Oh pooh.
Download the release zip; extract, cd into the directory, run ./squeak.sh; boom.
The image is fine and runs OK with a slightly older VM build (5.0-201912311458).
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful Latin Phrases:- Mellita, domi adsum. = Honey, I'm home.
Hi All,
interesting. Indeed the simulator generates the correct code, and the image is functional:
00001cdc: ldr r0, [pc, #8] ; 0x0000000000001cec a(n) Global 00001ce0: ldr r7, [r0, #12] 00001ce4: mov r5, r7 00001ce8: mov pc, lr
So there's a Slang bug.
On Tue, Mar 17, 2020 at 5:34 PM Eliot Miranda eliot.miranda@gmail.com wrote:
Hi All,
apologies; this is my bug. Having revived my Raspberry 3 buildmachine I've just reproduced the crash and can see that it's a code generator bug. The very first JITted method executed answers SmalltalkImage current. The code generated for this should be
0x4018e8: ldr r0, [pc, #8] ; 0x4018f8 0x4018ec: ldr r7, [r0, #8] 0x4018f0: mov r5, r7 0x4018f4: mov pc, lr
but is alas
0x4018e8: ldr r0, [pc, #8] ; 0x4018f8 0x4018ec: ldr r7, [r0, #-0] 0x4018f0: mov r5, r7 0x4018f4: mov pc, lr
I have to find out why this does't fail in the simulator (or find out that it does and that my recollection of having tested 32-bit ARM recently is, in fact, a self-serving hallucination). Hopefully normal service should be restored presently. But it does mean releasing an updated Squeak5.3 release with a fixed VM. Again, apologies.
On Sat, Mar 7, 2020 at 10:10 PM tim Rowledge tim@rowledge.org wrote:
Oh pooh.
Download the release zip; extract, cd into the directory, run ./squeak.sh; boom.
The image is fine and runs OK with a slightly older VM build (5.0-201912311458).
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful Latin Phrases:- Mellita, domi adsum. = Honey, I'm home.
-- _,,,^..^,,,_ best, Eliot
On Tue, Mar 17, 2020 at 7:56 PM Eliot Miranda eliot.miranda@gmail.com wrote:
Hi All,
interesting. Indeed the simulator generates the correct code, and theimage is functional:
00001cdc: ldr r0, [pc, #8] ; 0x0000000000001cec a(n) Global 00001ce0: ldr r7, [r0, #12] 00001ce4: mov r5, r7 00001ce8: mov pc, lr
So there's a Slang bug.
fixed in VMMaker.oscog-eem.2728.mcz
On Tue, Mar 17, 2020 at 5:34 PM Eliot Miranda eliot.miranda@gmail.com wrote:
Hi All,
apologies; this is my bug. Having revived my Raspberry 3 buildmachine I've just reproduced the crash and can see that it's a code generator bug. The very first JITted method executed answers SmalltalkImage current. The code generated for this should be
0x4018e8: ldr r0, [pc, #8] ; 0x4018f8 0x4018ec: ldr r7, [r0, #8] 0x4018f0: mov r5, r7 0x4018f4: mov pc, lr
but is alas
0x4018e8: ldr r0, [pc, #8] ; 0x4018f8 0x4018ec: ldr r7, [r0, #-0] 0x4018f0: mov r5, r7 0x4018f4: mov pc, lr
I have to find out why this does't fail in the simulator (or find out that it does and that my recollection of having tested 32-bit ARM recently is, in fact, a self-serving hallucination). Hopefully normal service should be restored presently. But it does mean releasing an updated Squeak5.3 release with a fixed VM. Again, apologies.
On Sat, Mar 7, 2020 at 10:10 PM tim Rowledge tim@rowledge.org wrote:
Oh pooh.
Download the release zip; extract, cd into the directory, run ./squeak.sh; boom.
The image is fine and runs OK with a slightly older VM build (5.0-201912311458).
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful Latin Phrases:- Mellita, domi adsum. = Honey, I'm home.
-- _,,,^..^,,,_ best, Eliot
-- _,,,^..^,,,_ best, Eliot
HI,
I've built with this version:
commit 102b0fa831e2f793620a9a4cf94369d696e7920f Author: Eliot Miranda Date: Tue Mar 17 19:01:16 2020 -0700
CogVM source as per VMMaker.oscog-eem.2728
And it builds and runs on Arm32. Seems ok though without a giant amount of checking.
Thanks!!!!
cheers
bruce
Now that I've said that, the About dialog is bizarre. The fonts seem wrong, kind of Klingon like.
The other tools seem to have sensible fonts.
Hi Bruce,
On Mar 18, 2020, at 8:35 AM, Bruce O'Neel bruce.oneel@pckswarms.ch wrote:
Now that I've said that, the About dialog is bizarre. The fonts seem wrong, kind of Klingon like.
The easiest way to see this is in the fixed pitch fonts in the About Squeak SystemReporter, eg select the VM Stats tab. I discussed this with Tim yesterday evening. I expect this is to do with the ARM BitBLT assembler. Easy to check. We just build without the optimized assembler and see what things look like.
The other tools seem to have sensible fonts.
18 March 2020 15:26 "Bruce O'Neel" bruce.oneel@pckswarms.ch wrote: HI,
I've built with this version:
commit 102b0fa831e2f793620a9a4cf94369d696e7920f Author: Eliot Miranda eliot.miranda@gmail.com Date: Tue Mar 17 19:01:16 2020 -0700
CogVM source as per VMMaker.oscog-eem.2728And it builds and runs on Arm32. Seems ok though without a giant amount of checking.
Thanks!!!!
cheers
bruce
18 March 2020 03:58 Eliot Miranda eliot.miranda@gmail.com wrote:
On Tue, Mar 17, 2020 at 7:56 PM Eliot Miranda eliot.miranda@gmail.com wrote: Hi All,
interesting. Indeed the simulator generates the correct code, and the image is functional:00001cdc: ldr r0, [pc, #8] ; 0x0000000000001cec a(n) Global 00001ce0: ldr r7, [r0, #12] 00001ce4: mov r5, r7 00001ce8: mov pc, lr
So there's a Slang bug.
fixed in VMMaker.oscog-eem.2728.mcz
On Tue, Mar 17, 2020 at 5:34 PM Eliot Miranda eliot.miranda@gmail.com wrote: Hi All,
apologies; this is my bug. Having revived my Raspberry 3 build machine I've just reproduced the crash and can see that it's a code generator bug. The very first JITted method executed answers SmalltalkImage current. The code generated for this should be0x4018e8: ldr r0, [pc, #8] ; 0x4018f8 0x4018ec: ldr r7, [r0, #8] 0x4018f0: mov r5, r7 0x4018f4: mov pc, lr
but is alas
0x4018e8: ldr r0, [pc, #8] ; 0x4018f8 0x4018ec: ldr r7, [r0, #-0] 0x4018f0: mov r5, r7 0x4018f4: mov pc, lr
I have to find out why this does't fail in the simulator (or find out that it does and that my recollection of having tested 32-bit ARM recently is, in fact, a self-serving hallucination). Hopefully normal service should be restored presently. But it does mean releasing an updated Squeak5.3 release with a fixed VM. Again, apologies.
On Sat, Mar 7, 2020 at 10:10 PM tim Rowledge tim@rowledge.org wrote: Oh pooh.
Download the release zip; extract, cd into the directory, run ./squeak.sh; boom.
The image is fine and runs OK with a slightly older VM build (5.0-201912311458).
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful Latin Phrases:- Mellita, domi adsum. = Honey, I'm home.
--
_,,,^..^,,,_ best, Eliot
--
_,,,^..^,,,_ best, Eliot
--
_,,,^..^,,,_ best, Eliot <>
<>
I've just built plain and debug on my Pi 3B+ and it works fine; no strange fonts or anything like that. TinyBenchmarks run from the About... tool gives the usual results.
The assembler problem I had been seeing the other day turns out to be a side-effect of some *really* strange CIFS network file system issue; I can no longer compiile from sources on my iMac read by the Pi using a CIFS connection setup that has worked for at least 5 years. Anyone actually knowledgable about that sort of thing?
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Gotta run, the cat's caught in the printer.
On 2020-03-18, at 8:34 AM, Bruce O'Neel bruce.oneel@pckswarms.ch wrote:
Now that I've said that, the About dialog is bizarre. The fonts seem wrong, kind of Klingon like.
The other tools seem to have sensible fonts.
Are you still seeing this? I can't replicate at all.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Half the people you know are below average.
HI,
Attached is a screen shot. In all cases I'm working over X11. This screenshot is from a windows system with MobaXterm. But the XQuartz display is identical.
If you don't see this one an attached display, then I would be tempted to say go with this.
BTW, it looks more readable shrunk down than it does on a retina display.
 cheers
bruce
On 2020-03-18, at 8:34 AM, Bruce O'Neel wrote:
Now that I've said that, the About dialog is bizarre. The fonts seem wrong, kind of Klingon like.
The other tools seem to have sensible fonts.
Are you still seeing this? I can't replicate at all.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Half the people you know are below average.
On Mar 19, 2020, at 3:14 AM, Bruce O'Neel bruce.oneel@pckswarms.ch wrote:
HI,
Attached is a screen shot. In all cases I'm working over X11. This screenshot is from a windows system with MobaXterm. But the XQuartz display is identical.
If you don't see this one an attached display, then I would be tempted to say go with this.
BTW, it looks more readable shrunk down than it does on a retina display.
<SQ.png>
cheers
bruce
19 March 2020 00:18 tim Rowledge tim@rowledge.org wrote:
On 2020-03-18, at 8:34 AM, Bruce O'Neel wrote:
Now that I've said that, the About dialog is bizarre. The fonts seem wrong, kind of Klingon like.
The other tools seem to have sensible fonts.
Are you still seeing this? I can't replicate at all.
I see exactly what Bruce sees and I’m also using an X11 server on my Mac. Tim, what’s your display configuration? Are you using an X11 server on the pi3 itself?
I’ll test my pi3 with a tethered display and local X11 server and see if it’s different.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Half the people you know are below average.
On 2020-03-19, at 7:04 AM, Eliot Miranda eliot.miranda@gmail.com wrote:
On Mar 19, 2020, at 3:14 AM, Bruce O'Neel bruce.oneel@pckswarms.ch wrote:
HI,
Attached is a screen shot. In all cases I'm working over X11. This screenshot is from a windows system with MobaXterm. But the XQuartz display is identical.
My system looks like this -
Are you still seeing this? I can't replicate at all.
I see exactly what Bruce sees and I’m also using an X11 server on my Mac. Tim, what’s your display configuration? Are you using an X11 server on the pi3 itself?
I’ll test my pi3 with a tethered display and local X11 server and see if it’s different.
I use the built in VNC system on the Pi, and a copy of RealVNC on my iMac. I'd say this looks like a problem in the X11 related stuff, though what on earth could make it only affect fixed width fonts? What happens if you use cmd-k to change the font? I'm not at all sure I can imagine any bitblt problem that could only mess up fixed width fonts
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim "How many Ringworld Engineers does it take to change a lightbulb?” "Thirty. Hey, moving suns around isn't easy..."
Hi,
If I change to say Bitmap Dejavu sans it looks good.
Cycling through the font list with Cmd K all the fonts that begin BitstreamVeraSans are Klingon, and ComicSansMS is the same though for ComicSans that's not a great loss.
cheers
bruce
On 2020-03-19, at 11:38 AM, Bruce O'Neel bruce.oneel@pckswarms.ch wrote:
Hi,
If I change to say Bitmap Dejavu sans it looks good.
Cycling through the font list with Cmd K all the fonts that begin BitstreamVeraSans are Klingon, and ComicSansMS is the same though for ComicSans that's not a great loss.
That's .... ridiculous. I can use any of the fonts and they all look fine.
We do (as an aside) have a problem with the TextStyles in that something got messed up a few releases ago and doesn't seem to be fixed yet. Probably we need to rebuld and incorporate a few new free fonts (it's not like there aren't plenty available)
Are you able to try the direct display or VNC stuff?
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim AAAAAA - American Association Against Acronym Abuse Anonymous
HI,
On 2020-03-19, at 11:38 AM, Bruce O'Neel wrote:
Hi,
If I change to say Bitmap Dejavu sans it looks good.
Cycling through the font list with Cmd K all the fonts that begin BitstreamVeraSans are Klingon, and ComicSansMS is the same though for ComicSans that's not a great loss.
That's .... ridiculous. I can use any of the fonts and they all look fine.
We do (as an aside) have a problem with the TextStyles in that something got messed up a few releases ago and doesn't seem to be fixed yet. Probably we need to rebuld and incorporate a few new free fonts (it's not like there aren't plenty available)
Are you able to try the direct display or VNC stuff?
I specialize in ridiculous. Good news, I guess, is that I dug up a monitor, and, walked it downstairs with a keyboard and mouse and attached it. The effect with the BitstreamVeraSans and ComicSans fonts are the same. Maybe it likes serfed fonts?
So that means that it is not some funky X11 over the wire problem with the Mac and Windows X11 servers problem. That's good.
I have no idea then why. Are these fonts part of the image? Is it some funky binary format that for some reason Coq is mis-reading?
I built a stack VM and I get the same result with a Squeak 5.3 image.
Just so we're clear I'm working with this version:
commit 102b0fa831e2f793620a9a4cf94369d696e7920f Author: Eliot Miranda Date: Tue Mar 17 19:01:16 2020 -0700
CogVM source as per VMMaker.oscog-eem.2728
cheers
bruce> tim
-- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim AAAAAA - American Association Against Acronym Abuse Anonymous
On 2020-03-20, at 6:16 AM, Bruce O'Neel bruce.oneel@pckswarms.ch wrote:
I specialize in ridiculous. Good news, I guess, is that I dug up a monitor, and, walked it downstairs with a keyboard and mouse and attached it. The effect with the BitstreamVeraSans and ComicSans fonts are the same. Maybe it likes serfed fonts?
I'm completely baffled by this. I don't get this effect with any ARM vm that I have that actually runs, with any image I have.
So that means that it is not some funky X11 over the wire problem with the Mac and Windows X11 servers problem. That's good.
Guess so, though it just makes life weirder.
I have no idea then why. Are these fonts part of the image? Is it some funky binary format that for some reason Coq is mis-reading?
Yes, the font glyphs are in-image. We've been using these ones for goodness knows how many years.
I built a stack VM and I get the same result with a Squeak 5.3 image.
There*shouldn't* be any difference between the stack & cog vms.
You could try building a VM with the fastbitblt turned off I suppose - a quick hack is to find the BITBLT_FLAGS= -DENABLE_FAST_BLT and related lines in the Makefile in you squeak.cog.spur/build directory. I haven't actually built an ARM vm without that in years so I don't know it it even still works.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim It is easier to change the specification to fit the program than vice versa.
Hi Tim and others.
Let's think about this a little differently.
What do we know:
1. You, Ellot and I can build the VM on our respective PIs. 2. In general this VM works fine, the only seemingly difference is on a few fonts. This, of course, is bizarre. 3. We must be either seeing a difference in hardware, or in software, or in firmware.
Now we start guessing.
1. I use my PI as a server. I installed Raspberian about 12 months ago, and, the only packages installed on top are samba, and then the 11 packages to make Squeak build. I'm lazy, I have not checked to see if there was a firmware update nor I have I updated firmware. 2. I don't know about Ellot, but I have the impression you Tim use your PI more, right? Do you have more packages installed? 3. Or, maybe it's some difference in hardware. My Pi 3 was bought in early 2019 and has the following dmesg bits.
[ 0.000000] Linux version 4.19.66-v7+ (dom@buildbot) (gcc version 4.9.3 (crosstool-NG crosstool-ng-1.22.0-88-g8460611)) #1253 SMP Thu Aug 15 11:49:46 BST 2019
[ 0.000000] CPU: ARMv7 Processor [410fd034] revision 4 (ARMv7), cr=10c5383d
[ 0.000000] CPU: div instructions available: patching division code
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[ 0.000000] OF: fdt: Machine model: Raspberry Pi 3 Model B Plus Rev 1.3
[ 0.002345] CPU: Testing write buffer coherency: ok
[ 0.002830] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
[ 0.003495] Setting up static identity map for 0x100000 - 0x10003c
[ 0.003662] rcu: Hierarchical SRCU implementation.
[ 0.004476] smp: Bringing up secondary CPUs ...
[ 0.005337] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
[ 0.006262] CPU2: thread -1, cpu 2, socket 0, mpidr 80000002
[ 0.007124] CPU3: thread -1, cpu 3, socket 0, mpidr 80000003
[ 0.007246] smp: Brought up 1 node, 4 CPUs
[ 0.007326] SMP: Total of 4 processors activated (153.60 BogoMIPS).
[ 0.007350] CPU: All CPU(s) started in HYP mode.
[ 0.007371] CPU: Virtualization extensions available.
[ 0.008364] devtmpfs: initialized
[ 0.021572] VFP support v0.3: implementor 41 architecture 3 part 40 variant 3 rev 4
[ 0.090300] raspberrypi-firmware soc:firmware: Attached to firmware from 2019-08-15 12:06, variant start
[ 0.100128] raspberrypi-firmware soc:firmware: Firmware hash is 0e6daa5106dd4164474616408e0dc24f997ffcf3
[ 0.234849] bcm2708_fb soc:fb: FB found 1 display(s)
[ 0.245052] Console: switching to colour frame buffer device 80x30
[ 0.252763] bcm2708_fb soc:fb: Registered framebuffer for display 0, size 640x480
[ 0.260129] bcm2835-rng 3f104000.rng: hwrng registered
[ 0.263319] vc-mem: phys_addr:0x00000000 mem_base=0x3ec00000 mem_size:0x40000000(1024 MiB)
[ 0.269633] vc-sm: Videocore shared memory driver
I have a PI2 sitting around here somewhere. I'll see if I can get that running...
Any other ideas?
Thanks.
bruce
Hi,
Tired with the PI2. Good news/bad news, it's not hardware or firmware. I see the same results.
So clearly the VM I've built.
cheers
bruce
Hi
On 21.03.2020, at 10:51, Bruce O'Neel bruce.oneel@pckswarms.ch wrote:
Hi,
Tired with the PI2. Good news/bad news, it's not hardware or firmware. I see the same results.
So clearly the VM I've built.
now I get what you mean.
The non-bitmap variant uses the Balloon-engine to do the rendering of the ttf curves to bits. Didn't we change something regarding this lately?
Best regard -Tobas
cheers
bruce
21 March 2020 10:03 "Bruce O'Neel" bruce.oneel@pckswarms.ch wrote: Hi Tim and others.
Let's think about this a little differently.
What do we know:
- You, Ellot and I can build the VM on our respective PIs.
- In general this VM works fine, the only seemingly difference is on a few fonts. This, of course, is bizarre.
- We must be either seeing a difference in hardware, or in software, or in firmware.
Now we start guessing.
- I use my PI as a server. I installed Raspberian about 12 months ago, and, the only packages installed on top are samba, and then the 11 packages to make Squeak build. I'm lazy, I have not checked to see if there was a firmware update nor I have I updated firmware.
- I don't know about Ellot, but I have the impression you Tim use your PI more, right? Do you have more packages installed?
- Or, maybe it's some difference in hardware. My Pi 3 was bought in early 2019 and has the following dmesg bits.
[ 0.000000] Linux version 4.19.66-v7+ (dom@buildbot) (gcc version 4.9.3 (crosstool-NG crosstool-ng-1.22.0-88-g8460611)) #1253 SMP Thu Aug 15 11:49:46 BST 2019 [ 0.000000] CPU: ARMv7 Processor [410fd034] revision 4 (ARMv7), cr=10c5383d [ 0.000000] CPU: div instructions available: patching division code [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [ 0.000000] OF: fdt: Machine model: Raspberry Pi 3 Model B Plus Rev 1.3
[ 0.002345] CPU: Testing write buffer coherency: ok [ 0.002830] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000 [ 0.003495] Setting up static identity map for 0x100000 - 0x10003c [ 0.003662] rcu: Hierarchical SRCU implementation. [ 0.004476] smp: Bringing up secondary CPUs ... [ 0.005337] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001 [ 0.006262] CPU2: thread -1, cpu 2, socket 0, mpidr 80000002 [ 0.007124] CPU3: thread -1, cpu 3, socket 0, mpidr 80000003 [ 0.007246] smp: Brought up 1 node, 4 CPUs [ 0.007326] SMP: Total of 4 processors activated (153.60 BogoMIPS). [ 0.007350] CPU: All CPU(s) started in HYP mode. [ 0.007371] CPU: Virtualization extensions available. [ 0.008364] devtmpfs: initialized [ 0.021572] VFP support v0.3: implementor 41 architecture 3 part 40 variant 3 rev 4
[ 0.090300] raspberrypi-firmware soc:firmware: Attached to firmware from 2019-08-15 12:06, variant start [ 0.100128] raspberrypi-firmware soc:firmware: Firmware hash is 0e6daa5106dd4164474616408e0dc24f997ffcf3
[ 0.234849] bcm2708_fb soc:fb: FB found 1 display(s) [ 0.245052] Console: switching to colour frame buffer device 80x30 [ 0.252763] bcm2708_fb soc:fb: Registered framebuffer for display 0, size 640x480 [ 0.260129] bcm2835-rng 3f104000.rng: hwrng registered [ 0.263319] vc-mem: phys_addr:0x00000000 mem_base=0x3ec00000 mem_size:0x40000000(1024 MiB) [ 0.269633] vc-sm: Videocore shared memory driver
I have a PI2 sitting around here somewhere. I'll see if I can get that running...
Any other ideas?
Thanks.
bruce
21 March 2020 01:07 tim Rowledge tim@rowledge.org wrote:
On 2020-03-20, at 6:16 AM, Bruce O'Neel wrote:
I specialize in ridiculous. Good news, I guess, is that I dug up a monitor, and, walked it downstairs with a keyboard and mouse and attached it. The effect with the BitstreamVeraSans and ComicSans fonts are the same. Maybe it likes serfed fonts?
I'm completely baffled by this. I don't get this effect with any ARM vm that I have that actually runs, with any image I have.
So that means that it is not some funky X11 over the wire problem with the Mac and Windows X11 servers problem. That's good.
Guess so, though it just makes life weirder.
I have no idea then why. Are these fonts part of the image? Is it some funky binary format that for some reason Coq is mis-reading?
Yes, the font glyphs are in-image. We've been using these ones for goodness knows how many years.
I built a stack VM and I get the same result with a Squeak 5.3 image.
There*shouldn't* be any difference between the stack & cog vms.
You could try building a VM with the fastbitblt turned off I suppose - a quick hack is to find the BITBLT_FLAGS= -DENABLE_FAST_BLT and related lines in the Makefile in you squeak.cog.spur/build directory. I haven't actually built an ARM vm without that in years so I don't know it it even still works.
tim
I've now tried the vm I built on a Pi4 (32bit Raspbian Buster) with the release 5.3 image and it is fine (and fast!). No weird fonts; tried every combo I could manage wrt font/style.
I'll email the zipped VM directly to Bruce & Eliot for comparison.
On 2020-03-21, at 3:00 AM, Tobias Pape Das.Linux@gmx.de wrote:
Hi
On 21.03.2020, at 10:51, Bruce O'Neel bruce.oneel@pckswarms.ch wrote:
Hi,
Tired with the PI2. Good news/bad news, it's not hardware or firmware. I see the same results.
So clearly the VM I've built.
now I get what you mean.
The non-bitmap variant uses the Balloon-engine to do the rendering of the ttf curves to bits. Didn't we change something regarding this lately?
But even if we did, did we re-create the glyphs for the fonts? Fairly sure not.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Compatible: Gracefully accepts erroneous data from any source.
Hi,
Good news, playing with
--enable-fast-bitblt
and
--disable-fast-bitblt
does work in that it builds a working VM.
Good news/bad news, it does not change the font problem. So that's not the problem.
cheers
bruce
On 22.03.2020, at 16:31, Bruce O'Neel bruce.oneel@pckswarms.ch wrote:
Hi,
Good news, playing with
--enable-fast-bitblt
and
--disable-fast-bitblt
does work in that it builds a working VM.
Good news/bad news, it does not change the font problem. So that's not the problem.
Good news, in some way… -t
cheers
bruce
21 March 2020 01:07 tim Rowledge tim@rowledge.org wrote:
On 2020-03-20, at 6:16 AM, Bruce O'Neel wrote:
I specialize in ridiculous. Good news, I guess, is that I dug up a monitor, and, walked it downstairs with a keyboard and mouse and attached it. The effect with the BitstreamVeraSans and ComicSans fonts are the same. Maybe it likes serfed fonts?
I'm completely baffled by this. I don't get this effect with any ARM vm that I have that actually runs, with any image I have.
So that means that it is not some funky X11 over the wire problem with the Mac and Windows X11 servers problem. That's good.
Guess so, though it just makes life weirder.
I have no idea then why. Are these fonts part of the image? Is it some funky binary format that for some reason Coq is mis-reading?
Yes, the font glyphs are in-image. We've been using these ones for goodness knows how many years.
I built a stack VM and I get the same result with a Squeak 5.3 image.
There*shouldn't* be any difference between the stack & cog vms.
You could try building a VM with the fastbitblt turned off I suppose - a quick hack is to find the BITBLT_FLAGS= -DENABLE_FAST_BLT and related lines in the Makefile in you squeak.cog.spur/build directory. I haven't actually built an ARM vm without that in years so I don't know it it even still works.
tim
Hi Bruce,
On Mar 22, 2020, at 8:31 AM, Bruce O'Neel bruce.oneel@pckswarms.ch wrote:
Hi,
Good news, playing with
--enable-fast-bitblt
and
--disable-fast-bitblt
does work in that it builds a working VM.
Good news/bad news, it does not change the font problem. So that's not the problem.
Great news. We now know it is an X11 problem and can stop worrying about the fast BitBLT code. Thanks.
cheers
bruce
21 March 2020 01:07 tim Rowledge tim@rowledge.org wrote:
On 2020-03-20, at 6:16 AM, Bruce O'Neel wrote:
I specialize in ridiculous. Good news, I guess, is that I dug up a monitor, and, walked it downstairs with a keyboard and mouse and attached it. The effect with the BitstreamVeraSans and ComicSans fonts are the same. Maybe it likes serfed fonts?
I'm completely baffled by this. I don't get this effect with any ARM vm that I have that actually runs, with any image I have.
So that means that it is not some funky X11 over the wire problem with the Mac and Windows X11 servers problem. That's good.
Guess so, though it just makes life weirder.
I have no idea then why. Are these fonts part of the image? Is it some funky binary format that for some reason Coq is mis-reading?
Yes, the font glyphs are in-image. We've been using these ones for goodness knows how many years.
I built a stack VM and I get the same result with a Squeak 5.3 image.
There*shouldn't* be any difference between the stack & cog vms.
You could try building a VM with the fastbitblt turned off I suppose - a quick hack is to find the BITBLT_FLAGS= -DENABLE_FAST_BLT and related lines in the Makefile in you squeak.cog.spur/build directory. I haven't actually built an ARM vm without that in years so I don't know it it even still works.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim It is easier to change the specification to fit the program than vice versa.
Hi all, I observe similar font problems on windows spur32 VM/image
[image: image.png]
Virtual Machine --------------- Open Smalltalk Cog[Spur] VM [CoInterpreterPrimitives VMMaker.oscog-eem.2731] Win32 built on Mar 23 2020 22:15:31 CET Compiler: 7.4.0 platform sources revision VM: 202003220256 Date: Sat Mar 21 19:56:35 2020 CommitHash: b85570231 Plugins: 202003220256 CoInterpreter VMMaker.oscog-eem.2731 uuid: 3c8dda9e-4706-4c3d-8c58-a284c47f5705 Mar 23 2020 StackToRegisterMappingCogit VMMaker.oscog-eem.2731 uuid: 3c8dda9e-4706-4c3d-8c58-a284c47f5705 Mar 23 2020
Le dim. 22 mars 2020 à 22:50, Eliot Miranda eliot.miranda@gmail.com a écrit :
Hi Bruce,
On Mar 22, 2020, at 8:31 AM, Bruce O'Neel bruce.oneel@pckswarms.ch wrote:
Hi,
Good news, playing with
--enable-fast-bitblt
and
--disable-fast-bitblt
does work in that it builds a working VM.
Good news/bad news, it does not change the font problem. So that's not the problem.
Great news. We now know it is an X11 problem and can stop worrying about the fast BitBLT code. Thanks.
cheers
bruce
*21 March 2020 01:07 tim Rowledge <tim@rowledge.org tim@rowledge.org> wrote:*
On 2020-03-20, at 6:16 AM, Bruce O'Neel wrote:
I specialize in ridiculous. Good news, I guess, is that I dug up a
monitor, and, walked it downstairs with a keyboard and mouse and attached it. The effect with the BitstreamVeraSans and ComicSans fonts are the same. Maybe it likes serfed fonts?
I'm completely baffled by this. I don't get this effect with any ARM vm that I have that actually runs, with any image I have.
So that means that it is not some funky X11 over the wire problem with
the Mac and Windows X11 servers problem. That's good.
Guess so, though it just makes life weirder.
I have no idea then why. Are these fonts part of the image? Is it some
funky binary format that for some reason Coq is mis-reading?
Yes, the font glyphs are in-image. We've been using these ones for goodness knows how many years.
I built a stack VM and I get the same result with a Squeak 5.3 image.
There*shouldn't* be any difference between the stack & cog vms.
You could try building a VM with the fastbitblt turned off I suppose - a quick hack is to find the BITBLT_FLAGS= -DENABLE_FAST_BLT and related lines in the Makefile in you squeak.cog.spur/build directory. I haven't actually built an ARM vm without that in years so I don't know it it even still works.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim It is easier to change the specification to fit the program than vice versa.
Hmm, it looks like I broke the signedBitShift: by omission (I did not update it, and it now calls updated bitShift:...)
[minY > lastY and:[fwDy >= 0]] whileTrue:[ lastX := lastX + ((fwDx + 16r8000) signedBitShift: -16). lastY := lastY + ((fwDy + 16r8000) signedBitShift: -16). fwDx := fwDx + (updateData at: GBUpdateDDX). fwDy := fwDy + (updateData at: GBUpdateDDY). ].
==>
@@ -13423,8 +13423,8 @@ stepToNextBezier(void) minY = (workBuffer[GWCurrentY]) * 256; while ((minY > lastY) && (fwDy >= 0)) { - lastX += ((signed)(fwDx + 32768) >> 16); - lastY += ((signed)(fwDy + 32768) >> 16); + lastX += (((usqInt)((fwDx + 32768))) >> 16); + lastY += (((usqInt)((fwDy + 32768))) >> 16); fwDx += updateData[GBUpdateDDX]; fwDy += updateData[GBUpdateDDY]; }
Le lun. 23 mars 2020 à 23:33, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> a écrit :
Hi all, I observe similar font problems on windows spur32 VM/image
[image: image.png]
Virtual Machine
Open Smalltalk Cog[Spur] VM [CoInterpreterPrimitives VMMaker.oscog-eem.2731] Win32 built on Mar 23 2020 22:15:31 CET Compiler: 7.4.0 platform sources revision VM: 202003220256 Date: Sat Mar 21 19:56:35 2020 CommitHash: b85570231 Plugins: 202003220256 CoInterpreter VMMaker.oscog-eem.2731 uuid: 3c8dda9e-4706-4c3d-8c58-a284c47f5705 Mar 23 2020 StackToRegisterMappingCogit VMMaker.oscog-eem.2731 uuid: 3c8dda9e-4706-4c3d-8c58-a284c47f5705 Mar 23 2020
Le dim. 22 mars 2020 à 22:50, Eliot Miranda eliot.miranda@gmail.com a écrit :
Hi Bruce,
On Mar 22, 2020, at 8:31 AM, Bruce O'Neel bruce.oneel@pckswarms.ch wrote:
Hi,
Good news, playing with
--enable-fast-bitblt
and
--disable-fast-bitblt
does work in that it builds a working VM.
Good news/bad news, it does not change the font problem. So that's not the problem.
Great news. We now know it is an X11 problem and can stop worrying about the fast BitBLT code. Thanks.
cheers
bruce
*21 March 2020 01:07 tim Rowledge <tim@rowledge.org tim@rowledge.org> wrote:*
On 2020-03-20, at 6:16 AM, Bruce O'Neel wrote:
I specialize in ridiculous. Good news, I guess, is that I dug up a
monitor, and, walked it downstairs with a keyboard and mouse and attached it. The effect with the BitstreamVeraSans and ComicSans fonts are the same. Maybe it likes serfed fonts?
I'm completely baffled by this. I don't get this effect with any ARM vm that I have that actually runs, with any image I have.
So that means that it is not some funky X11 over the wire problem with
the Mac and Windows X11 servers problem. That's good.
Guess so, though it just makes life weirder.
I have no idea then why. Are these fonts part of the image? Is it some
funky binary format that for some reason Coq is mis-reading?
Yes, the font glyphs are in-image. We've been using these ones for goodness knows how many years.
I built a stack VM and I get the same result with a Squeak 5.3 image.
There*shouldn't* be any difference between the stack & cog vms.
You could try building a VM with the fastbitblt turned off I suppose - a quick hack is to find the BITBLT_FLAGS= -DENABLE_FAST_BLT and related lines in the Makefile in you squeak.cog.spur/build directory. I haven't actually built an ARM vm without that in years so I don't know it it even still works.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim It is easier to change the specification to fit the program than vice versa.
Ah no, my bad, this is a horrible copy/paste error! https://source.squeak.org/VMMaker/VMMaker.oscog-nice.2732.diff Eliot, could you regenerate the VM/plugins?
Le mar. 24 mars 2020 à 00:31, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> a écrit :
Hmm, it looks like I broke the signedBitShift: by omission (I did not update it, and it now calls updated bitShift:...)
[minY > lastY and:[fwDy >= 0]] whileTrue:[ lastX := lastX + ((fwDx + 16r8000) signedBitShift: -16). lastY := lastY + ((fwDy + 16r8000) signedBitShift: -16). fwDx := fwDx + (updateData at: GBUpdateDDX). fwDy := fwDy + (updateData at: GBUpdateDDY). ].
==>
@@ -13423,8 +13423,8 @@ stepToNextBezier(void) minY = (workBuffer[GWCurrentY]) * 256; while ((minY > lastY) && (fwDy >= 0)) {
lastX += ((signed)(fwDx + 32768) >> 16);lastY += ((signed)(fwDy + 32768) >> 16);
lastX += (((usqInt)((fwDx + 32768))) >> 16);lastY += (((usqInt)((fwDy + 32768))) >> 16); fwDx += updateData[GBUpdateDDX]; fwDy += updateData[GBUpdateDDY]; }Le lun. 23 mars 2020 à 23:33, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> a écrit :
Hi all, I observe similar font problems on windows spur32 VM/image
[image: image.png]
Virtual Machine
Open Smalltalk Cog[Spur] VM [CoInterpreterPrimitives VMMaker.oscog-eem.2731] Win32 built on Mar 23 2020 22:15:31 CET Compiler: 7.4.0 platform sources revision VM: 202003220256 Date: Sat Mar 21 19:56:35 2020 CommitHash: b85570231 Plugins: 202003220256 CoInterpreter VMMaker.oscog-eem.2731 uuid: 3c8dda9e-4706-4c3d-8c58-a284c47f5705 Mar 23 2020 StackToRegisterMappingCogit VMMaker.oscog-eem.2731 uuid: 3c8dda9e-4706-4c3d-8c58-a284c47f5705 Mar 23 2020
Le dim. 22 mars 2020 à 22:50, Eliot Miranda eliot.miranda@gmail.com a écrit :
Hi Bruce,
On Mar 22, 2020, at 8:31 AM, Bruce O'Neel bruce.oneel@pckswarms.ch wrote:
Hi,
Good news, playing with
--enable-fast-bitblt
and
--disable-fast-bitblt
does work in that it builds a working VM.
Good news/bad news, it does not change the font problem. So that's not the problem.
Great news. We now know it is an X11 problem and can stop worrying about the fast BitBLT code. Thanks.
cheers
bruce
*21 March 2020 01:07 tim Rowledge <tim@rowledge.org tim@rowledge.org> wrote:*
On 2020-03-20, at 6:16 AM, Bruce O'Neel wrote:
I specialize in ridiculous. Good news, I guess, is that I dug up a
monitor, and, walked it downstairs with a keyboard and mouse and attached it. The effect with the BitstreamVeraSans and ComicSans fonts are the same. Maybe it likes serfed fonts?
I'm completely baffled by this. I don't get this effect with any ARM vm that I have that actually runs, with any image I have.
So that means that it is not some funky X11 over the wire problem with
the Mac and Windows X11 servers problem. That's good.
Guess so, though it just makes life weirder.
I have no idea then why. Are these fonts part of the image? Is it some
funky binary format that for some reason Coq is mis-reading?
Yes, the font glyphs are in-image. We've been using these ones for goodness knows how many years.
I built a stack VM and I get the same result with a Squeak 5.3 image.
There*shouldn't* be any difference between the stack & cog vms.
You could try building a VM with the fastbitblt turned off I suppose - a quick hack is to find the BITBLT_FLAGS= -DENABLE_FAST_BLT and related lines in the Makefile in you squeak.cog.spur/build directory. I haven't actually built an ARM vm without that in years so I don't know it it even still works.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim It is easier to change the specification to fit the program than vice versa.
Should be fixed by https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/3fa41faef52a157954d...
Le mar. 24 mars 2020 à 00:45, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> a écrit :
Ah no, my bad, this is a horrible copy/paste error! https://source.squeak.org/VMMaker/VMMaker.oscog-nice.2732.diff Eliot, could you regenerate the VM/plugins?
Le mar. 24 mars 2020 à 00:31, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> a écrit :
Hmm, it looks like I broke the signedBitShift: by omission (I did not update it, and it now calls updated bitShift:...)
[minY > lastY and:[fwDy >= 0]] whileTrue:[ lastX := lastX + ((fwDx + 16r8000) signedBitShift: -16). lastY := lastY + ((fwDy + 16r8000) signedBitShift: -16). fwDx := fwDx + (updateData at: GBUpdateDDX). fwDy := fwDy + (updateData at: GBUpdateDDY). ].
==>
@@ -13423,8 +13423,8 @@ stepToNextBezier(void) minY = (workBuffer[GWCurrentY]) * 256; while ((minY > lastY) && (fwDy >= 0)) {
lastX += ((signed)(fwDx + 32768) >> 16);lastY += ((signed)(fwDy + 32768) >> 16);
lastX += (((usqInt)((fwDx + 32768))) >> 16);lastY += (((usqInt)((fwDy + 32768))) >> 16); fwDx += updateData[GBUpdateDDX]; fwDy += updateData[GBUpdateDDY]; }Le lun. 23 mars 2020 à 23:33, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> a écrit :
Hi all, I observe similar font problems on windows spur32 VM/image
[image: image.png]
Virtual Machine
Open Smalltalk Cog[Spur] VM [CoInterpreterPrimitives VMMaker.oscog-eem.2731] Win32 built on Mar 23 2020 22:15:31 CET Compiler: 7.4.0 platform sources revision VM: 202003220256 Date: Sat Mar 21 19:56:35 2020 CommitHash: b85570231 Plugins: 202003220256 CoInterpreter VMMaker.oscog-eem.2731 uuid: 3c8dda9e-4706-4c3d-8c58-a284c47f5705 Mar 23 2020 StackToRegisterMappingCogit VMMaker.oscog-eem.2731 uuid: 3c8dda9e-4706-4c3d-8c58-a284c47f5705 Mar 23 2020
Le dim. 22 mars 2020 à 22:50, Eliot Miranda eliot.miranda@gmail.com a écrit :
Hi Bruce,
On Mar 22, 2020, at 8:31 AM, Bruce O'Neel bruce.oneel@pckswarms.ch wrote:
Hi,
Good news, playing with
--enable-fast-bitblt
and
--disable-fast-bitblt
does work in that it builds a working VM.
Good news/bad news, it does not change the font problem. So that's not the problem.
Great news. We now know it is an X11 problem and can stop worrying about the fast BitBLT code. Thanks.
cheers
bruce
*21 March 2020 01:07 tim Rowledge <tim@rowledge.org tim@rowledge.org> wrote:*
On 2020-03-20, at 6:16 AM, Bruce O'Neel wrote:
I specialize in ridiculous. Good news, I guess, is that I dug up a
monitor, and, walked it downstairs with a keyboard and mouse and attached it. The effect with the BitstreamVeraSans and ComicSans fonts are the same. Maybe it likes serfed fonts?
I'm completely baffled by this. I don't get this effect with any ARM vm that I have that actually runs, with any image I have.
So that means that it is not some funky X11 over the wire problem
with the Mac and Windows X11 servers problem. That's good.
Guess so, though it just makes life weirder.
I have no idea then why. Are these fonts part of the image? Is it
some funky binary format that for some reason Coq is mis-reading?
Yes, the font glyphs are in-image. We've been using these ones for goodness knows how many years.
I built a stack VM and I get the same result with a Squeak 5.3 image.
There*shouldn't* be any difference between the stack & cog vms.
You could try building a VM with the fastbitblt turned off I suppose - a quick hack is to find the BITBLT_FLAGS= -DENABLE_FAST_BLT and related lines in the Makefile in you squeak.cog.spur/build directory. I haven't actually built an ARM vm without that in years so I don't know it it even still works.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim It is easier to change the specification to fit the program than vice versa.
Hi,
Thanks!!!
This works perfectly for me.
cheers
bruce
Hi Tim,
On Sun, Mar 22, 2020 at 2:50 PM Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Bruce,
On Mar 22, 2020, at 8:31 AM, Bruce O'Neel bruce.oneel@pckswarms.ch wrote:
Hi,
Good news, playing with
--enable-fast-bitblt
and
--disable-fast-bitblt
does work in that it builds a working VM.
Good news/bad news, it does not change the font problem. So that's not the problem.
Great news. We now know it is an X11 problem and can stop worrying about the fast BitBLT code. Thanks.
Looks like the problem, or at least a version of the problem, is nothing to do with X11. If I open an About Squeak System Reporter in the simulator (64-bits x64) I see the fixed pitch font corruption we saw on X11 on ARM. So it looks tile the issue is actually in BitBlt itself.
[image: SysRepFixedPitch.png]
cheers
bruce
*21 March 2020 01:07 tim Rowledge <tim@rowledge.org tim@rowledge.org> wrote:*
On 2020-03-20, at 6:16 AM, Bruce O'Neel wrote:
I specialize in ridiculous. Good news, I guess, is that I dug up a
monitor, and, walked it downstairs with a keyboard and mouse and attached it. The effect with the BitstreamVeraSans and ComicSans fonts are the same. Maybe it likes serfed fonts?
I'm completely baffled by this. I don't get this effect with any ARM vm that I have that actually runs, with any image I have.
So that means that it is not some funky X11 over the wire problem with
the Mac and Windows X11 servers problem. That's good.
Guess so, though it just makes life weirder.
I have no idea then why. Are these fonts part of the image? Is it some
funky binary format that for some reason Coq is mis-reading?
Yes, the font glyphs are in-image. We've been using these ones for goodness knows how many years.
I built a stack VM and I get the same result with a Squeak 5.3 image.
There*shouldn't* be any difference between the stack & cog vms.
You could try building a VM with the fastbitblt turned off I suppose - a quick hack is to find the BITBLT_FLAGS= -DENABLE_FAST_BLT and related lines in the Makefile in you squeak.cog.spur/build directory. I haven't actually built an ARM vm without that in years so I don't know it it even still works.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim It is easier to change the specification to fit the program than vice versa.
Hi Eliot, already fixed by https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/3fa41faef52a157954d...
Le dim. 26 avr. 2020 à 22:44, Eliot Miranda eliot.miranda@gmail.com a écrit :
Hi Tim,
On Sun, Mar 22, 2020 at 2:50 PM Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Bruce,
On Mar 22, 2020, at 8:31 AM, Bruce O'Neel bruce.oneel@pckswarms.ch wrote:
Hi,
Good news, playing with
--enable-fast-bitblt
and
--disable-fast-bitblt
does work in that it builds a working VM.
Good news/bad news, it does not change the font problem. So that's not the problem.
Great news. We now know it is an X11 problem and can stop worrying about the fast BitBLT code. Thanks.
Looks like the problem, or at least a version of the problem, is nothing to do with X11. If I open an About Squeak System Reporter in the simulator (64-bits x64) I see the fixed pitch font corruption we saw on X11 on ARM. So it looks tile the issue is actually in BitBlt itself.
[image: SysRepFixedPitch.png]
cheers
bruce
*21 March 2020 01:07 tim Rowledge <tim@rowledge.org tim@rowledge.org> wrote:*
On 2020-03-20, at 6:16 AM, Bruce O'Neel wrote:
I specialize in ridiculous. Good news, I guess, is that I dug up a
monitor, and, walked it downstairs with a keyboard and mouse and attached it. The effect with the BitstreamVeraSans and ComicSans fonts are the same. Maybe it likes serfed fonts?
I'm completely baffled by this. I don't get this effect with any ARM vm that I have that actually runs, with any image I have.
So that means that it is not some funky X11 over the wire problem with
the Mac and Windows X11 servers problem. That's good.
Guess so, though it just makes life weirder.
I have no idea then why. Are these fonts part of the image? Is it some
funky binary format that for some reason Coq is mis-reading?
Yes, the font glyphs are in-image. We've been using these ones for goodness knows how many years.
I built a stack VM and I get the same result with a Squeak 5.3 image.
There*shouldn't* be any difference between the stack & cog vms.
You could try building a VM with the fastbitblt turned off I suppose - a quick hack is to find the BITBLT_FLAGS= -DENABLE_FAST_BLT and related lines in the Makefile in you squeak.cog.spur/build directory. I haven't actually built an ARM vm without that in years so I don't know it it even still works.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim It is easier to change the specification to fit the program than vice versa.
-- _,,,^..^,,,_ best, Eliot
and https://source.squeak.org/VMMaker/VMMaker.oscog-nice.2732.diff
Le dim. 26 avr. 2020 à 22:48, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> a écrit :
Hi Eliot, already fixed by https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/3fa41faef52a157954d...
Le dim. 26 avr. 2020 à 22:44, Eliot Miranda eliot.miranda@gmail.com a écrit :
Hi Tim,
On Sun, Mar 22, 2020 at 2:50 PM Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Bruce,
On Mar 22, 2020, at 8:31 AM, Bruce O'Neel bruce.oneel@pckswarms.ch wrote:
Hi,
Good news, playing with
--enable-fast-bitblt
and
--disable-fast-bitblt
does work in that it builds a working VM.
Good news/bad news, it does not change the font problem. So that's not the problem.
Great news. We now know it is an X11 problem and can stop worrying about the fast BitBLT code. Thanks.
Looks like the problem, or at least a version of the problem, is nothing to do with X11. If I open an About Squeak System Reporter in the simulator (64-bits x64) I see the fixed pitch font corruption we saw on X11 on ARM. So it looks tile the issue is actually in BitBlt itself.
[image: SysRepFixedPitch.png]
cheers
bruce
*21 March 2020 01:07 tim Rowledge <tim@rowledge.org tim@rowledge.org> wrote:*
On 2020-03-20, at 6:16 AM, Bruce O'Neel wrote:
I specialize in ridiculous. Good news, I guess, is that I dug up a
monitor, and, walked it downstairs with a keyboard and mouse and attached it. The effect with the BitstreamVeraSans and ComicSans fonts are the same. Maybe it likes serfed fonts?
I'm completely baffled by this. I don't get this effect with any ARM vm that I have that actually runs, with any image I have.
So that means that it is not some funky X11 over the wire problem with
the Mac and Windows X11 servers problem. That's good.
Guess so, though it just makes life weirder.
I have no idea then why. Are these fonts part of the image? Is it some
funky binary format that for some reason Coq is mis-reading?
Yes, the font glyphs are in-image. We've been using these ones for goodness knows how many years.
I built a stack VM and I get the same result with a Squeak 5.3 image.
There*shouldn't* be any difference between the stack & cog vms.
You could try building a VM with the fastbitblt turned off I suppose - a quick hack is to find the BITBLT_FLAGS= -DENABLE_FAST_BLT and related lines in the Makefile in you squeak.cog.spur/build directory. I haven't actually built an ARM vm without that in years so I don't know it it even still works.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim It is easier to change the specification to fit the program than vice versa.
-- _,,,^..^,,,_ best, Eliot
On Apr 26, 2020, at 1:50 PM, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote: and https://source.squeak.org/VMMaker/VMMaker.oscog-nice.2732.diff
Thanks!!
Le dim. 26 avr. 2020 à 22:48, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com a écrit : Hi Eliot, already fixed by https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/3fa41faef52a157954d...
Le dim. 26 avr. 2020 à 22:44, Eliot Miranda eliot.miranda@gmail.com a écrit : Hi Tim,
On Sun, Mar 22, 2020 at 2:50 PM Eliot Miranda eliot.miranda@gmail.com wrote: Hi Bruce,
On Mar 22, 2020, at 8:31 AM, Bruce O'Neel bruce.oneel@pckswarms.ch wrote: Hi,
Good news, playing with
--enable-fast-bitblt
and
--disable-fast-bitblt
does work in that it builds a working VM.
Good news/bad news, it does not change the font problem. So that's not the problem.
Great news. We now know it is an X11 problem and can stop worrying about the fast BitBLT code. Thanks.
Looks like the problem, or at least a version of the problem, is nothing to do with X11. If I open an About Squeak System Reporter in the simulator (64-bits x64) I see the fixed pitch font corruption we saw on X11 on ARM. So it looks tile the issue is actually in BitBlt itself.
<SysRepFixedPitch.png>
cheers
bruce
21 March 2020 01:07 tim Rowledge tim@rowledge.org wrote:
On 2020-03-20, at 6:16 AM, Bruce O'Neel wrote:
I specialize in ridiculous. Good news, I guess, is that I dug up a monitor, and, walked it downstairs with a keyboard and mouse and attached it. The effect with the BitstreamVeraSans and ComicSans fonts are the same. Maybe it likes serfed fonts?
I'm completely baffled by this. I don't get this effect with any ARM vm that I have that actually runs, with any image I have.
So that means that it is not some funky X11 over the wire problem with the Mac and Windows X11 servers problem. That's good.
Guess so, though it just makes life weirder.
I have no idea then why. Are these fonts part of the image? Is it some funky binary format that for some reason Coq is mis-reading?
Yes, the font glyphs are in-image. We've been using these ones for goodness knows how many years.
I built a stack VM and I get the same result with a Squeak 5.3 image.
There*shouldn't* be any difference between the stack & cog vms.
You could try building a VM with the fastbitblt turned off I suppose - a quick hack is to find the BITBLT_FLAGS= -DENABLE_FAST_BLT and related lines in the Makefile in you squeak.cog.spur/build directory. I haven't actually built an ARM vm without that in years so I don't know it it even still works.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim It is easier to change the specification to fit the program than vice versa.
-- _,,,^..^,,,_ best, Eliot
Hi all!
So it looks tile the issue is actually in BitBlt itself.
It's funny how the fixed font in Squeak's About dialog keeps on documenting such issues. This is like the third or fourth case we had in the last year. :-)
Best, Marcel Am 26.04.2020 22:45:02 schrieb Eliot Miranda eliot.miranda@gmail.com: Hi Tim,
On Sun, Mar 22, 2020 at 2:50 PM Eliot Miranda <eliot.miranda@gmail.com [mailto:eliot.miranda@gmail.com]> wrote:
Hi Bruce, On Mar 22, 2020, at 8:31 AM, Bruce O'Neel <bruce.oneel@pckswarms.ch [mailto:bruce.oneel@pckswarms.ch]> wrote: Hi,
Good news, playing with
--enable-fast-bitblt
and
--disable-fast-bitblt
does work in that it builds a working VM.
Good news/bad news, it does not change the font problem. So that's not the problem.
Great news. We now know it is an X11 problem and can stop worrying about the fast BitBLT code. Thanks.
Looks like the problem, or at least a version of the problem, is nothing to do with X11. If I open an About Squeak System Reporter in the simulator (64-bits x64) I see the fixed pitch font corruption we saw on X11 on ARM. So it looks tile the issue is actually in BitBlt itself.
[SysRepFixedPitch.png]
cheers
bruce
21 March 2020 01:07 tim Rowledge <tim@rowledge.org [mailto:tim@rowledge.org]> wrote:
On 2020-03-20, at 6:16 AM, Bruce O'Neel wrote:
I specialize in ridiculous. Good news, I guess, is that I dug up a monitor, and, walked it downstairs with a keyboard and mouse and attached it. The effect with the BitstreamVeraSans and ComicSans fonts are the same. Maybe it likes serfed fonts?
I'm completely baffled by this. I don't get this effect with any ARM vm that I have that actually runs, with any image I have.
So that means that it is not some funky X11 over the wire problem with the Mac and Windows X11 servers problem. That's good.
Guess so, though it just makes life weirder.
I have no idea then why. Are these fonts part of the image? Is it some funky binary format that for some reason Coq is mis-reading?
Yes, the font glyphs are in-image. We've been using these ones for goodness knows how many years.
I built a stack VM and I get the same result with a Squeak 5.3 image.
There*shouldn't* be any difference between the stack & cog vms.
You could try building a VM with the fastbitblt turned off I suppose -
a quick hack is to find the BITBLT_FLAGS= -DENABLE_FAST_BLT and related lines in the Makefile in you squeak.cog.spur/build directory. I haven't actually built an ARM vm without that in years so I don't know it it even still works.
tim
--
tim Rowledge; tim@rowledge.org [mailto:tim@rowledge.org]; http://www.rowledge.org/tim [http://www.rowledge.org/tim]
It is easier to change the specification to fit the program than vice versa.
--
_,,,^..^,,,_
best, Eliot
squeak-dev@lists.squeakfoundation.org
-
Bruce O'Neel -
Eliot Miranda -
Fabio Niephaus -
Jakob Reschke -
Levente Uzonyi -
Marcel Taeumel -
Nicolas Cellier -
tim Rowledge -
Tobias Pape