Hi,
I heard that people got a new problem in inputting Japanese text into Scratch 1.4 running on Raspberry Pi OS after, or around the version 2020-08-20. I would like to take a look at it but it might involve recompiling and generating the VM with debugging info. Last time I looked into it was years and years ago and I need to basically make a fresh start.
Is the process of making NuSqeauk VM For Raspberry Pi up to date and straightforward? Can people point me to the right point to start?
Thanks!
-- -- Yoshiki
Hi Yoshiki,
On Wed, Oct 21, 2020 at 10:14 AM Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
Hi,
I heard that people got a new problem in inputting Japanese text into Scratch 1.4 running on Raspberry Pi OS after, or around the version 2020-08-20. I would like to take a look at it but it might involve recompiling and generating the VM with debugging info. Last time I looked into it was years and years ago and I need to basically make a fresh start.
Is the process of making NuSqeauk VM For Raspberry Pi up to date and straightforward? Can people point me to the right point to start?
Making a Cog VM for Raspberry pi is straight-forward. Clone opensmalltalk-vm. cd to build.linux64ARMv8, read the HowToBuild, cd to build.linux64ARMv8/squeak.cog.spur/build.debug, or build.linux64ARMv8/squeak.stack.spur/build.debug, then run ./mvm
_,,,^..^,,,_ best, Eliot
Hi Eliot,
For build.linux64ARMv8/squeak.cog.spur/build.debug, i get the following error. I think I followed the steps in the instructions, including running updateSCCSVersion and mvm. How can I fix it?
/home/pi/opensmalltalk-vm/spur64src/vm/cogit.c:22:3: error: #error As yet no Cogit implementation appears to exist for your platform.
# error As yet no Cogit implementation appears to exist for your platform.
^~~~~
/home/pi/opensmalltalk-vm/spur64src/vm/cogit.c:23:3: error: #error Consider implementing it, starting by adding a subclass of CogAbstractInstruction.
# error Consider implementing it, starting by adding a subclass of CogAbstractInstruction.
^~~~~
make[1]: *** [Makefile:207: cogit.o]
On Wed, Oct 21, 2020 at 10:21 AM Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Yoshiki,
On Wed, Oct 21, 2020 at 10:14 AM Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
Hi,
I heard that people got a new problem in inputting Japanese text into Scratch 1.4 running on Raspberry Pi OS after, or around the version 2020-08-20. I would like to take a look at it but it might involve recompiling and generating the VM with debugging info. Last time I looked into it was years and years ago and I need to basically make a fresh start.
Is the process of making NuSqeauk VM For Raspberry Pi up to date and straightforward? Can people point me to the right point to start?
Making a Cog VM for Raspberry pi is straight-forward. Clone opensmalltalk-vm. cd to build.linux64ARMv8, read the HowToBuild, cd to build.linux64ARMv8/squeak.cog.spur/build.debug, or build.linux64ARMv8/squeak.stack.spur/build.debug, then run ./mvm
_,,,^..^,,,_ best, Eliot
OK, included is a zip of the 5.1 test/dev image I made some time back. Just open Dock->Apps->Scratch. The preferences are possibly not your taste since they're mine but I think you can fix that easily enough.
[EDIT - mail system refused it so on it's way in a direct email to Yoshiki]
This is a *32* bit image ready to run on a *32* bit release of Raspberry PI OS. Do not try to make a 64 bit ARM v8 image and expect this to run. Indeed, currently the 64bit ARM v8 VM will not run on Raspberry PI OS 64 because it needs some of the write/read/execute code memory area magic fixing. Make a 32 bit VM for plain old ARMv6.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Science is imagination equipped with grappling hooks.
I still have not managed to compile the VM from the latest source on Raspberry Pi 4 yet, I was experimenting from the Squeak side (Thanks Tim). The bug manifests this way:
As you can see, nextEventFromQueue is modified to show a keystroke event to Transcript. I launch the image, enable FCITX, and type one character (あ). In the normal case, it would show only one question mark in the transcript. But at some random times, in this movie the second time, the exact same sequence gives the image two question marks, with the second one having a bogus key value. (The value changes at random.)
I suspect that the use of malloc() and sizeof in x2sqKeyCompositionInput or such might be ending up with a wrong alignment or such and a character becomes two. Worst, it is a bug in X11... Then it'd be harder to fix...
On Sat, Oct 24, 2020 at 1:59 PM Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
Hi Eliot,
For build.linux64ARMv8/squeak.cog.spur/build.debug, i get the following error. I think I followed the steps in the instructions, including running updateSCCSVersion and mvm. How can I fix it?
/home/pi/opensmalltalk-vm/spur64src/vm/cogit.c:22:3: error: #error As yet no Cogit implementation appears to exist for your platform.
# error As yet no Cogit implementation appears to exist for your platform.
^~~~~
/home/pi/opensmalltalk-vm/spur64src/vm/cogit.c:23:3: error: #error Consider implementing it, starting by adding a subclass of CogAbstractInstruction.
# error Consider implementing it, starting by adding a subclass of CogAbstractInstruction.
^~~~~
make[1]: *** [Makefile:207: cogit.o]
On Wed, Oct 21, 2020 at 10:21 AM Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Yoshiki,
On Wed, Oct 21, 2020 at 10:14 AM Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
Hi,
I heard that people got a new problem in inputting Japanese text into Scratch 1.4 running on Raspberry Pi OS after, or around the version 2020-08-20. I would like to take a look at it but it might involve recompiling and generating the VM with debugging info. Last time I looked into it was years and years ago and I need to basically make a fresh start.
Is the process of making NuSqeauk VM For Raspberry Pi up to date and straightforward? Can people point me to the right point to start?
Making a Cog VM for Raspberry pi is straight-forward. Clone opensmalltalk-vm. cd to build.linux64ARMv8, read the HowToBuild, cd to build.linux64ARMv8/squeak.cog.spur/build.debug, or build.linux64ARMv8/squeak.stack.spur/build.debug, then run ./mvm
_,,,^..^,,,_ best, Eliot
-- -- Yoshiki
And I tried a few more things by checking out the last release tag 202003021730 or try opensmalltalk-vm/build.linuxARMv6/squeak.cog.spur/build.debug but those attempts did not work. For the latter got this error:
In file included from /usr/include/features.h:424,
from /usr/include/pthread.h:21,
from /home/pi/opensmalltalk-vm/platforms/unix/vm/sqPlatformSpecific.h:62,
from /home/pi/opensmalltalk-vm/platforms/Cross/vm/sqAssert.h:16,
from /home/pi/opensmalltalk-vm/platforms/unix/vm/aio.c:35:
/usr/include/stdio.h:721:12: error: conflicting types for ‘fseeko’
extern int __REDIRECT (fseeko,
^~~~~~~~~~
In file included from /home/pi/opensmalltalk-vm/platforms/Cross/vm/sqAssert.h:16,
from /home/pi/opensmalltalk-vm/platforms/unix/vm/aio.c:35:
/home/pi/opensmalltalk-vm/platforms/unix/vm/sqPlatformSpecific.h:109:22: note: previous declaration \
of ‘fseeko’ was here
#define fseek(s,o,w) fseeko(s,o,w)
^~~~~~
On Sat, Oct 24, 2020 at 1:59 PM Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
Hi Eliot,
For build.linux64ARMv8/squeak.cog.spur/build.debug, i get the following error. I think I followed the steps in the instructions, including running updateSCCSVersion and mvm. How can I fix it?
/home/pi/opensmalltalk-vm/spur64src/vm/cogit.c:22:3: error: #error As yet no Cogit implementation appears to exist for your platform.
# error As yet no Cogit implementation appears to exist for your platform.
^~~~~
/home/pi/opensmalltalk-vm/spur64src/vm/cogit.c:23:3: error: #error Consider implementing it, starting by adding a subclass of CogAbstractInstruction.
# error Consider implementing it, starting by adding a subclass of CogAbstractInstruction.
^~~~~
make[1]: *** [Makefile:207: cogit.o]
On Wed, Oct 21, 2020 at 10:21 AM Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Yoshiki,
On Wed, Oct 21, 2020 at 10:14 AM Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
Hi,
I heard that people got a new problem in inputting Japanese text into Scratch 1.4 running on Raspberry Pi OS after, or around the version 2020-08-20. I would like to take a look at it but it might involve recompiling and generating the VM with debugging info. Last time I looked into it was years and years ago and I need to basically make a fresh start.
Is the process of making NuSqeauk VM For Raspberry Pi up to date and straightforward? Can people point me to the right point to start?
Making a Cog VM for Raspberry pi is straight-forward. Clone opensmalltalk-vm. cd to build.linux64ARMv8, read the HowToBuild, cd to build.linux64ARMv8/squeak.cog.spur/build.debug, or build.linux64ARMv8/squeak.stack.spur/build.debug, then run ./mvm
_,,,^..^,,,_ best, Eliot
-- -- Yoshiki
For the /build.linuxARMv6/squeak.cog.spur/build.debug case, a hack I did was like this:
diff --git a/platforms/unix/vm/sqPlatformSpecific.h b/platforms/unix/vm/sqPlatformSpecific.h
index 268593673..bfb57257b 100644
--- a/platforms/unix/vm/sqPlatformSpecific.h
+++ b/platforms/unix/vm/sqPlatformSpecific.h
@@ -105,8 +105,8 @@ extern void sqFilenameFromString(char *uxName, sqInt stNameIndex, int sqNameLeng
#undef sqFTruncate
/* sqFTruncate should return 0 on success, ftruncate does also */
#define sqFTruncate(f,o) ftruncate(fileno(f), o)
-#define ftell(s) ftello(s)
-#define fseek(s,o,w) fseeko(s,o,w)
+// #define ftell(s) ftello(s)
+// #define fseek(s,o,w) fseeko(s,o,w)
#if defined(__GNUC__)
# if !defined(VM_LABEL)
diff --git a/spur64src/vm/cogit.c b/spur64src/vm/cogit.c
index d62b05f40..e1c14a021 100644
--- a/spur64src/vm/cogit.c
+++ b/spur64src/vm/cogit.c
@@ -6,6 +6,8 @@
# define SysV 1
#endif
+#define __arm64__
+
#if defined(__arm64__) || defined(__aarch64__) || defined(__ARM_ARCH_ISA_A64) || defined(ARM64) || defined(ARMv8)
and this produced a runnable VM on Raspberry Pi4
On Sat, Oct 24, 2020 at 4:41 PM Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
And I tried a few more things by checking out the last release tag 202003021730 or try opensmalltalk-vm/build.linuxARMv6/squeak.cog.spur/build.debug but those attempts did not work. For the latter got this error:
In file included from /usr/include/features.h:424,
from /usr/include/pthread.h:21, from/home/pi/opensmalltalk-vm/platforms/unix/vm/sqPlatformSpecific.h:62,
from/home/pi/opensmalltalk-vm/platforms/Cross/vm/sqAssert.h:16,
from /home/pi/opensmalltalk-vm/platforms/unix/vm/aio.c:35:/usr/include/stdio.h:721:12: error: conflicting types for ‘fseeko’
extern int __REDIRECT (fseeko,
^~~~~~~~~~In file included from /home/pi/opensmalltalk-vm/platforms/Cross/vm/sqAssert.h:16,
from /home/pi/opensmalltalk-vm/platforms/unix/vm/aio.c:35:/home/pi/opensmalltalk-vm/platforms/unix/vm/sqPlatformSpecific.h:109:22: note: previous declaration \
of ‘fseeko’ was here
#define fseek(s,o,w) fseeko(s,o,w)
^~~~~~On Sat, Oct 24, 2020 at 1:59 PM Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
Hi Eliot,
For build.linux64ARMv8/squeak.cog.spur/build.debug, i get the following error. I think I followed the steps in the instructions, including running updateSCCSVersion and mvm. How can I fix it?
/home/pi/opensmalltalk-vm/spur64src/vm/cogit.c:22:3: error: #error As yet no Cogit implementation appears to exist for your platform.
# error As yet no Cogit implementation appears to exist for your platform.
^~~~~
/home/pi/opensmalltalk-vm/spur64src/vm/cogit.c:23:3: error: #error Consider implementing it, starting by adding a subclass of CogAbstractInstruction.
# error Consider implementing it, starting by adding a subclass of CogAbstractInstruction.
^~~~~
make[1]: *** [Makefile:207: cogit.o]
On Wed, Oct 21, 2020 at 10:21 AM Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Yoshiki,
On Wed, Oct 21, 2020 at 10:14 AM Yoshiki Ohshima < Yoshiki.Ohshima@acm.org> wrote:
Hi,
I heard that people got a new problem in inputting Japanese text into Scratch 1.4 running on Raspberry Pi OS after, or around the version 2020-08-20. I would like to take a look at it but it might involve recompiling and generating the VM with debugging info. Last time I looked into it was years and years ago and I need to basically make a fresh start.
Is the process of making NuSqeauk VM For Raspberry Pi up to date and straightforward? Can people point me to the right point to start?
Making a Cog VM for Raspberry pi is straight-forward. Clone opensmalltalk-vm. cd to build.linux64ARMv8, read the HowToBuild, cd to build.linux64ARMv8/squeak.cog.spur/build.debug, or build.linux64ARMv8/squeak.stack.spur/build.debug, then run ./mvm
_,,,^..^,,,_ best, Eliot
-- -- Yoshiki
-- -- Yoshiki
The previous one was just a hack but I think I found the real problem. It was about the variable symbolic, that gets symbolic key code *when* it is needed has to be zero'ed out when it is not needed.
The diff is attached... I'll a make pull request if that helps.
On Sat, Oct 24, 2020 at 5:32 PM Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
For the /build.linuxARMv6/squeak.cog.spur/build.debug case, a hack I did was like this:
diff --git a/platforms/unix/vm/sqPlatformSpecific.h b/platforms/unix/vm/sqPlatformSpecific.h
index 268593673..bfb57257b 100644
--- a/platforms/unix/vm/sqPlatformSpecific.h
+++ b/platforms/unix/vm/sqPlatformSpecific.h
@@ -105,8 +105,8 @@ extern void sqFilenameFromString(char *uxName, sqInt stNameIndex, int sqNameLeng
#undef sqFTruncate
/* sqFTruncate should return 0 on success, ftruncate does also */
#define sqFTruncate(f,o) ftruncate(fileno(f), o)
-#define ftell(s) ftello(s)
-#define fseek(s,o,w) fseeko(s,o,w)
+// #define ftell(s) ftello(s)
+// #define fseek(s,o,w) fseeko(s,o,w)
#if defined(__GNUC__)
# if !defined(VM_LABEL)
diff --git a/spur64src/vm/cogit.c b/spur64src/vm/cogit.c
index d62b05f40..e1c14a021 100644
--- a/spur64src/vm/cogit.c
+++ b/spur64src/vm/cogit.c
@@ -6,6 +6,8 @@
# define SysV 1
#endif
+#define __arm64__
#if defined(__arm64__) || defined(__aarch64__) || defined(__ARM_ARCH_ISA_A64) || defined(ARM64) || defined(ARMv8)
and this produced a runnable VM on Raspberry Pi4
On Sat, Oct 24, 2020 at 4:41 PM Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
And I tried a few more things by checking out the last release tag 202003021730 or try opensmalltalk-vm/build.linuxARMv6/squeak.cog.spur/build.debug but those attempts did not work. For the latter got this error:
In file included from /usr/include/features.h:424,
from /usr/include/pthread.h:21, from/home/pi/opensmalltalk-vm/platforms/unix/vm/sqPlatformSpecific.h:62,
from/home/pi/opensmalltalk-vm/platforms/Cross/vm/sqAssert.h:16,
from/home/pi/opensmalltalk-vm/platforms/unix/vm/aio.c:35:
/usr/include/stdio.h:721:12: error: conflicting types for ‘fseeko’
extern int __REDIRECT (fseeko,
^~~~~~~~~~In file included from /home/pi/opensmalltalk-vm/platforms/Cross/vm/sqAssert.h:16,
from/home/pi/opensmalltalk-vm/platforms/unix/vm/aio.c:35:
/home/pi/opensmalltalk-vm/platforms/unix/vm/sqPlatformSpecific.h:109:22: note: previous declaration \
of ‘fseeko’ was here
#define fseek(s,o,w) fseeko(s,o,w)
^~~~~~On Sat, Oct 24, 2020 at 1:59 PM Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
Hi Eliot,
For build.linux64ARMv8/squeak.cog.spur/build.debug, i get the following error. I think I followed the steps in the instructions, including running updateSCCSVersion and mvm. How can I fix it?
/home/pi/opensmalltalk-vm/spur64src/vm/cogit.c:22:3: error: #error As yet no Cogit implementation appears to exist for your platform.
# error As yet no Cogit implementation appears to exist for your platform.
^~~~~
/home/pi/opensmalltalk-vm/spur64src/vm/cogit.c:23:3: error: #error Consider implementing it, starting by adding a subclass of CogAbstractInstruction.
# error Consider implementing it, starting by adding a subclass of CogAbstractInstruction.
^~~~~
make[1]: *** [Makefile:207: cogit.o]
On Wed, Oct 21, 2020 at 10:21 AM Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Yoshiki,
On Wed, Oct 21, 2020 at 10:14 AM Yoshiki Ohshima < Yoshiki.Ohshima@acm.org> wrote:
Hi,
I heard that people got a new problem in inputting Japanese text into Scratch 1.4 running on Raspberry Pi OS after, or around the version 2020-08-20. I would like to take a look at it but it might involve recompiling and generating the VM with debugging info. Last time I looked into it was years and years ago and I need to basically make a fresh start.
Is the process of making NuSqeauk VM For Raspberry Pi up to date and straightforward? Can people point me to the right point to start?
Making a Cog VM for Raspberry pi is straight-forward. Clone opensmalltalk-vm. cd to build.linux64ARMv8, read the HowToBuild, cd to build.linux64ARMv8/squeak.cog.spur/build.debug, or build.linux64ARMv8/squeak.stack.spur/build.debug, then run ./mvm
_,,,^..^,,,_ best, Eliot
-- -- Yoshiki
-- -- Yoshiki
-- -- Yoshiki
Hi Yoshiki,
on my Mac patch isn't smart enough to decode a git diff. Can you just email me your platforms/unix/vm-display-X11/sqUnixX11.c and I'll integrate? Thanks!
On Tue, Oct 27, 2020 at 8:21 AM Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
The previous one was just a hack but I think I found the real problem. It was about the variable symbolic, that gets symbolic key code *when* it is needed has to be zero'ed out when it is not needed.
The diff is attached... I'll a make pull request if that helps.
On Sat, Oct 24, 2020 at 5:32 PM Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
For the /build.linuxARMv6/squeak.cog.spur/build.debug case, a hack I did was like this:
diff --git a/platforms/unix/vm/sqPlatformSpecific.h b/platforms/unix/vm/sqPlatformSpecific.h
index 268593673..bfb57257b 100644
--- a/platforms/unix/vm/sqPlatformSpecific.h
+++ b/platforms/unix/vm/sqPlatformSpecific.h
@@ -105,8 +105,8 @@ extern void sqFilenameFromString(char *uxName, sqInt stNameIndex, int sqNameLeng
#undef sqFTruncate
/* sqFTruncate should return 0 on success, ftruncate does also */
#define sqFTruncate(f,o) ftruncate(fileno(f), o)
-#define ftell(s) ftello(s)
-#define fseek(s,o,w) fseeko(s,o,w)
+// #define ftell(s) ftello(s)
+// #define fseek(s,o,w) fseeko(s,o,w)
#if defined(__GNUC__)
# if !defined(VM_LABEL)
diff --git a/spur64src/vm/cogit.c b/spur64src/vm/cogit.c
index d62b05f40..e1c14a021 100644
--- a/spur64src/vm/cogit.c
+++ b/spur64src/vm/cogit.c
@@ -6,6 +6,8 @@
# define SysV 1
#endif
+#define __arm64__
#if defined(__arm64__) || defined(__aarch64__) || defined(__ARM_ARCH_ISA_A64) || defined(ARM64) || defined(ARMv8)
and this produced a runnable VM on Raspberry Pi4
On Sat, Oct 24, 2020 at 4:41 PM Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
And I tried a few more things by checking out the last release tag 202003021730 or try opensmalltalk-vm/build.linuxARMv6/squeak.cog.spur/build.debug but those attempts did not work. For the latter got this error:
In file included from /usr/include/features.h:424,
from /usr/include/pthread.h:21, from/home/pi/opensmalltalk-vm/platforms/unix/vm/sqPlatformSpecific.h:62,
from/home/pi/opensmalltalk-vm/platforms/Cross/vm/sqAssert.h:16,
from/home/pi/opensmalltalk-vm/platforms/unix/vm/aio.c:35:
/usr/include/stdio.h:721:12: error: conflicting types for ‘fseeko’
extern int __REDIRECT (fseeko,
^~~~~~~~~~In file included from /home/pi/opensmalltalk-vm/platforms/Cross/vm/sqAssert.h:16,
from/home/pi/opensmalltalk-vm/platforms/unix/vm/aio.c:35:
/home/pi/opensmalltalk-vm/platforms/unix/vm/sqPlatformSpecific.h:109:22: note: previous declaration \
of ‘fseeko’ was here
#define fseek(s,o,w) fseeko(s,o,w)
^~~~~~On Sat, Oct 24, 2020 at 1:59 PM Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
Hi Eliot,
For build.linux64ARMv8/squeak.cog.spur/build.debug, i get the following error. I think I followed the steps in the instructions, including running updateSCCSVersion and mvm. How can I fix it?
/home/pi/opensmalltalk-vm/spur64src/vm/cogit.c:22:3: error: #error As yet no Cogit implementation appears to exist for your platform.
# error As yet no Cogit implementation appears to exist for your platform.
^~~~~
/home/pi/opensmalltalk-vm/spur64src/vm/cogit.c:23:3: error: #error Consider implementing it, starting by adding a subclass of CogAbstractInstruction.
# error Consider implementing it, starting by adding a subclass of CogAbstractInstruction.
^~~~~
make[1]: *** [Makefile:207: cogit.o]
On Wed, Oct 21, 2020 at 10:21 AM Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Yoshiki,
On Wed, Oct 21, 2020 at 10:14 AM Yoshiki Ohshima < Yoshiki.Ohshima@acm.org> wrote:
Hi,
I heard that people got a new problem in inputting Japanese text into Scratch 1.4 running on Raspberry Pi OS after, or around the version 2020-08-20. I would like to take a look at it but it might involve recompiling and generating the VM with debugging info. Last time I looked into it was years and years ago and I need to basically make a fresh start.
Is the process of making NuSqeauk VM For Raspberry Pi up to date and straightforward? Can people point me to the right point to start?
Making a Cog VM for Raspberry pi is straight-forward. Clone opensmalltalk-vm. cd to build.linux64ARMv8, read the HowToBuild, cd to build.linux64ARMv8/squeak.cog.spur/build.debug, or build.linux64ARMv8/squeak.stack.spur/build.debug, then run ./mvm
_,,,^..^,,,_ best, Eliot
-- -- Yoshiki
-- -- Yoshiki
-- -- Yoshiki
-- -- Yoshiki
I have a branch on a clone on github:
https://github.com/yoshikiohshima/opensmalltalk-vm/tree/composition-input-fi...
It might be easier to pull from this? Separately, I'll mail you sqUnixX11.c.
On Tue, Oct 27, 2020 at 9:58 AM Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Yoshiki,
on my Mac patch isn't smart enough to decode a git diff. Can you justemail me your platforms/unix/vm-display-X11/sqUnixX11.c and I'll integrate? Thanks!
On Tue, Oct 27, 2020 at 8:21 AM Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
The previous one was just a hack but I think I found the real problem. It was about the variable symbolic, that gets symbolic key code *when* it is needed has to be zero'ed out when it is not needed.
The diff is attached... I'll a make pull request if that helps.
On Sat, Oct 24, 2020 at 5:32 PM Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
For the /build.linuxARMv6/squeak.cog.spur/build.debug case, a hack I did was like this:
diff --git a/platforms/unix/vm/sqPlatformSpecific.h b/platforms/unix/vm/sqPlatformSpecific.h
index 268593673..bfb57257b 100644
--- a/platforms/unix/vm/sqPlatformSpecific.h
+++ b/platforms/unix/vm/sqPlatformSpecific.h
@@ -105,8 +105,8 @@ extern void sqFilenameFromString(char *uxName, sqInt stNameIndex, int sqNameLeng
#undef sqFTruncate
/* sqFTruncate should return 0 on success, ftruncate does also */
#define sqFTruncate(f,o) ftruncate(fileno(f), o)
-#define ftell(s) ftello(s)
-#define fseek(s,o,w) fseeko(s,o,w)
+// #define ftell(s) ftello(s)
+// #define fseek(s,o,w) fseeko(s,o,w)
#if defined(__GNUC__)
# if !defined(VM_LABEL)
diff --git a/spur64src/vm/cogit.c b/spur64src/vm/cogit.c
index d62b05f40..e1c14a021 100644
--- a/spur64src/vm/cogit.c
+++ b/spur64src/vm/cogit.c
@@ -6,6 +6,8 @@
# define SysV 1
#endif
+#define __arm64__
#if defined(__arm64__) || defined(__aarch64__) || defined(__ARM_ARCH_ISA_A64) || defined(ARM64) || defined(ARMv8)
and this produced a runnable VM on Raspberry Pi4
On Sat, Oct 24, 2020 at 4:41 PM Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
And I tried a few more things by checking out the last release tag 202003021730 or try opensmalltalk-vm/build.linuxARMv6/squeak.cog.spur/build.debug but those attempts did not work. For the latter got this error:
In file included from /usr/include/features.h:424,
from /usr/include/pthread.h:21, from/home/pi/opensmalltalk-vm/platforms/unix/vm/sqPlatformSpecific.h:62,
from/home/pi/opensmalltalk-vm/platforms/Cross/vm/sqAssert.h:16,
from/home/pi/opensmalltalk-vm/platforms/unix/vm/aio.c:35:
/usr/include/stdio.h:721:12: error: conflicting types for ‘fseeko’
extern int __REDIRECT (fseeko,
^~~~~~~~~~In file included from /home/pi/opensmalltalk-vm/platforms/Cross/vm/sqAssert.h:16,
from/home/pi/opensmalltalk-vm/platforms/unix/vm/aio.c:35:
/home/pi/opensmalltalk-vm/platforms/unix/vm/sqPlatformSpecific.h:109:22: note: previous declaration \
of ‘fseeko’ was here
#define fseek(s,o,w) fseeko(s,o,w)
^~~~~~On Sat, Oct 24, 2020 at 1:59 PM Yoshiki Ohshima < Yoshiki.Ohshima@acm.org> wrote:
Hi Eliot,
For build.linux64ARMv8/squeak.cog.spur/build.debug, i get the following error. I think I followed the steps in the instructions, including running updateSCCSVersion and mvm. How can I fix it?
/home/pi/opensmalltalk-vm/spur64src/vm/cogit.c:22:3: error: #error As yet no Cogit implementation appears to exist for your platform.
# error As yet no Cogit implementation appears to exist for your platform.
^~~~~
/home/pi/opensmalltalk-vm/spur64src/vm/cogit.c:23:3: error: #error Consider implementing it, starting by adding a subclass of CogAbstractInstruction.
# error Consider implementing it, starting by adding a subclass of CogAbstractInstruction.
^~~~~
make[1]: *** [Makefile:207: cogit.o]
On Wed, Oct 21, 2020 at 10:21 AM Eliot Miranda < eliot.miranda@gmail.com> wrote:
Hi Yoshiki,
On Wed, Oct 21, 2020 at 10:14 AM Yoshiki Ohshima < Yoshiki.Ohshima@acm.org> wrote:
> > Hi, > > I heard that people got a new problem in inputting Japanese text > into Scratch 1.4 running on Raspberry Pi OS after, or around the version > 2020-08-20. I would like to take a look at it but it might involve > recompiling and generating the VM with debugging info. Last time I looked > into it was years and years ago and I need to basically make a fresh start. > > Is the process of making NuSqeauk VM For Raspberry Pi up to date and > straightforward? Can people point me to the right point to start? >
Making a Cog VM for Raspberry pi is straight-forward. Clone opensmalltalk-vm. cd to build.linux64ARMv8, read the HowToBuild, cd to build.linux64ARMv8/squeak.cog.spur/build.debug, or build.linux64ARMv8/squeak.stack.spur/build.debug, then run ./mvm
_,,,^..^,,,_ best, Eliot
-- -- Yoshiki
-- -- Yoshiki
-- -- Yoshiki
-- -- Yoshiki
-- _,,,^..^,,,_ best, Eliot
Hi Yoshiki, what you could do is 1) revert the changes to sqPlatformSpecific.h (fseek, ftell) since we have a working workaround now 2) just create a pull request from the github web interface (that's rather easy) It will be very easy for us to integrate (one click), and we'll keep your authorship.
Le mar. 27 oct. 2020 à 18:02, Yoshiki Ohshima Yoshiki.Ohshima@acm.org a écrit :
I have a branch on a clone on github:
https://github.com/yoshikiohshima/opensmalltalk-vm/tree/composition-input-fi...
It might be easier to pull from this? Separately, I'll mail you sqUnixX11.c.
On Tue, Oct 27, 2020 at 9:58 AM Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Yoshiki,
on my Mac patch isn't smart enough to decode a git diff. Can youjust email me your platforms/unix/vm-display-X11/sqUnixX11.c and I'll integrate? Thanks!
On Tue, Oct 27, 2020 at 8:21 AM Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
The previous one was just a hack but I think I found the real problem. It was about the variable symbolic, that gets symbolic key code *when* it is needed has to be zero'ed out when it is not needed.
The diff is attached... I'll a make pull request if that helps.
On Sat, Oct 24, 2020 at 5:32 PM Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
For the /build.linuxARMv6/squeak.cog.spur/build.debug case, a hack I did was like this:
diff --git a/platforms/unix/vm/sqPlatformSpecific.h b/platforms/unix/vm/sqPlatformSpecific.h
index 268593673..bfb57257b 100644
--- a/platforms/unix/vm/sqPlatformSpecific.h
+++ b/platforms/unix/vm/sqPlatformSpecific.h
@@ -105,8 +105,8 @@ extern void sqFilenameFromString(char *uxName, sqInt stNameIndex, int sqNameLeng
#undef sqFTruncate
/* sqFTruncate should return 0 on success, ftruncate does also */
#define sqFTruncate(f,o) ftruncate(fileno(f), o)
-#define ftell(s) ftello(s)
-#define fseek(s,o,w) fseeko(s,o,w)
+// #define ftell(s) ftello(s)
+// #define fseek(s,o,w) fseeko(s,o,w)
#if defined(__GNUC__)
# if !defined(VM_LABEL)
diff --git a/spur64src/vm/cogit.c b/spur64src/vm/cogit.c
index d62b05f40..e1c14a021 100644
--- a/spur64src/vm/cogit.c
+++ b/spur64src/vm/cogit.c
@@ -6,6 +6,8 @@
# define SysV 1
#endif
+#define __arm64__
#if defined(__arm64__) || defined(__aarch64__) || defined(__ARM_ARCH_ISA_A64) || defined(ARM64) || defined(ARMv8)
and this produced a runnable VM on Raspberry Pi4
On Sat, Oct 24, 2020 at 4:41 PM Yoshiki Ohshima < Yoshiki.Ohshima@acm.org> wrote:
And I tried a few more things by checking out the last release tag 202003021730 or try opensmalltalk-vm/build.linuxARMv6/squeak.cog.spur/build.debug but those attempts did not work. For the latter got this error:
In file included from /usr/include/features.h:424,
from /usr/include/pthread.h:21, from/home/pi/opensmalltalk-vm/platforms/unix/vm/sqPlatformSpecific.h:62,
from/home/pi/opensmalltalk-vm/platforms/Cross/vm/sqAssert.h:16,
from/home/pi/opensmalltalk-vm/platforms/unix/vm/aio.c:35:
/usr/include/stdio.h:721:12: error: conflicting types for ‘fseeko’
extern int __REDIRECT (fseeko,
^~~~~~~~~~In file included from /home/pi/opensmalltalk-vm/platforms/Cross/vm/sqAssert.h:16,
from/home/pi/opensmalltalk-vm/platforms/unix/vm/aio.c:35:
/home/pi/opensmalltalk-vm/platforms/unix/vm/sqPlatformSpecific.h:109:22: note: previous declaration \
of ‘fseeko’ was here
#define fseek(s,o,w) fseeko(s,o,w)
^~~~~~On Sat, Oct 24, 2020 at 1:59 PM Yoshiki Ohshima < Yoshiki.Ohshima@acm.org> wrote:
Hi Eliot,
For build.linux64ARMv8/squeak.cog.spur/build.debug, i get the following error. I think I followed the steps in the instructions, including running updateSCCSVersion and mvm. How can I fix it?
/home/pi/opensmalltalk-vm/spur64src/vm/cogit.c:22:3: error: #error As yet no Cogit implementation appears to exist for your platform.
# error As yet no Cogit implementation appears to exist for your platform.
^~~~~
/home/pi/opensmalltalk-vm/spur64src/vm/cogit.c:23:3: error: #error Consider implementing it, starting by adding a subclass of CogAbstractInstruction.
# error Consider implementing it, starting by adding a subclass of CogAbstractInstruction.
^~~~~
make[1]: *** [Makefile:207: cogit.o]
On Wed, Oct 21, 2020 at 10:21 AM Eliot Miranda < eliot.miranda@gmail.com> wrote:
> > Hi Yoshiki, > > On Wed, Oct 21, 2020 at 10:14 AM Yoshiki Ohshima < > Yoshiki.Ohshima@acm.org> wrote: > >> >> Hi, >> >> I heard that people got a new problem in inputting Japanese text >> into Scratch 1.4 running on Raspberry Pi OS after, or around the version >> 2020-08-20. I would like to take a look at it but it might involve >> recompiling and generating the VM with debugging info. Last time I looked >> into it was years and years ago and I need to basically make a fresh start. >> >> Is the process of making NuSqeauk VM For Raspberry Pi up to date >> and straightforward? Can people point me to the right point to start? >> > > Making a Cog VM for Raspberry pi is straight-forward. Clone > opensmalltalk-vm. cd to build.linux64ARMv8, read the HowToBuild, cd to build.linux64ARMv8/squeak.cog.spur/build.debug, > or build.linux64ARMv8/squeak.stack.spur/build.debug, then run ./mvm > > _,,,^..^,,,_ > best, Eliot >
-- -- Yoshiki
-- -- Yoshiki
-- -- Yoshiki
-- -- Yoshiki
-- _,,,^..^,,,_ best, Eliot
-- -- Yoshiki
Ah too late, Eliot was faster, hit the pull request next time :)
Le mar. 27 oct. 2020 à 18:43, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> a écrit :
Hi Yoshiki, what you could do is
- revert the changes to sqPlatformSpecific.h (fseek, ftell) since we have
a working workaround now 2) just create a pull request from the github web interface (that's rather easy) It will be very easy for us to integrate (one click), and we'll keep your authorship.
Le mar. 27 oct. 2020 à 18:02, Yoshiki Ohshima Yoshiki.Ohshima@acm.org a écrit :
I have a branch on a clone on github:
https://github.com/yoshikiohshima/opensmalltalk-vm/tree/composition-input-fi...
It might be easier to pull from this? Separately, I'll mail you sqUnixX11.c.
On Tue, Oct 27, 2020 at 9:58 AM Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Yoshiki,
on my Mac patch isn't smart enough to decode a git diff. Can youjust email me your platforms/unix/vm-display-X11/sqUnixX11.c and I'll integrate? Thanks!
On Tue, Oct 27, 2020 at 8:21 AM Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
The previous one was just a hack but I think I found the real problem. It was about the variable symbolic, that gets symbolic key code *when* it is needed has to be zero'ed out when it is not needed.
The diff is attached... I'll a make pull request if that helps.
On Sat, Oct 24, 2020 at 5:32 PM Yoshiki Ohshima < Yoshiki.Ohshima@acm.org> wrote:
For the /build.linuxARMv6/squeak.cog.spur/build.debug case, a hack I did was like this:
diff --git a/platforms/unix/vm/sqPlatformSpecific.h b/platforms/unix/vm/sqPlatformSpecific.h
index 268593673..bfb57257b 100644
--- a/platforms/unix/vm/sqPlatformSpecific.h
+++ b/platforms/unix/vm/sqPlatformSpecific.h
@@ -105,8 +105,8 @@ extern void sqFilenameFromString(char *uxName, sqInt stNameIndex, int sqNameLeng
#undef sqFTruncate
/* sqFTruncate should return 0 on success, ftruncate does also */
#define sqFTruncate(f,o) ftruncate(fileno(f), o)
-#define ftell(s) ftello(s)
-#define fseek(s,o,w) fseeko(s,o,w)
+// #define ftell(s) ftello(s)
+// #define fseek(s,o,w) fseeko(s,o,w)
#if defined(__GNUC__)
# if !defined(VM_LABEL)
diff --git a/spur64src/vm/cogit.c b/spur64src/vm/cogit.c
index d62b05f40..e1c14a021 100644
--- a/spur64src/vm/cogit.c
+++ b/spur64src/vm/cogit.c
@@ -6,6 +6,8 @@
# define SysV 1
#endif
+#define __arm64__
#if defined(__arm64__) || defined(__aarch64__) || defined(__ARM_ARCH_ISA_A64) || defined(ARM64) || defined(ARMv8)
and this produced a runnable VM on Raspberry Pi4
On Sat, Oct 24, 2020 at 4:41 PM Yoshiki Ohshima < Yoshiki.Ohshima@acm.org> wrote:
And I tried a few more things by checking out the last release tag 202003021730 or try opensmalltalk-vm/build. linuxARMv6/squeak.cog.spur/build.debug but those attempts did not work. For the latter got this error:
In file included from /usr/include/features.h:424,
from /usr/include/pthread.h:21, from/home/pi/opensmalltalk-vm/platforms/unix/vm/sqPlatformSpecific.h:62,
from/home/pi/opensmalltalk-vm/platforms/Cross/vm/sqAssert.h:16,
from/home/pi/opensmalltalk-vm/platforms/unix/vm/aio.c:35:
/usr/include/stdio.h:721:12: error: conflicting types for ‘fseeko’
extern int __REDIRECT (fseeko,
^~~~~~~~~~In file included from /home/pi/opensmalltalk-vm/platforms/Cross/vm/sqAssert.h:16,
from/home/pi/opensmalltalk-vm/platforms/unix/vm/aio.c:35:
/home/pi/opensmalltalk-vm/platforms/unix/vm/sqPlatformSpecific.h:109:22: note: previous declaration \
of ‘fseeko’ was here
#define fseek(s,o,w) fseeko(s,o,w)
^~~~~~On Sat, Oct 24, 2020 at 1:59 PM Yoshiki Ohshima < Yoshiki.Ohshima@acm.org> wrote:
> Hi Eliot, > > For build.linux64ARMv8/squeak.cog.spur/build.debug, i get the > following error. I think I followed the steps in the instructions, > including running updateSCCSVersion and mvm. How can I fix it? > > /home/pi/opensmalltalk-vm/spur64src/vm/cogit.c:22:3: error: #error > As yet no Cogit implementation appears to exist for your platform. > > # error As yet no Cogit implementation appears to exist for your > platform. > > ^~~~~ > > /home/pi/opensmalltalk-vm/spur64src/vm/cogit.c:23:3: error: #error > Consider implementing it, starting by adding a subclass of > CogAbstractInstruction. > > # error Consider implementing it, starting by adding a subclass of > CogAbstractInstruction. > > ^~~~~ > > make[1]: *** [Makefile:207: cogit.o] > > On Wed, Oct 21, 2020 at 10:21 AM Eliot Miranda < > eliot.miranda@gmail.com> wrote: > >> >> Hi Yoshiki, >> >> On Wed, Oct 21, 2020 at 10:14 AM Yoshiki Ohshima < >> Yoshiki.Ohshima@acm.org> wrote: >> >>> >>> Hi, >>> >>> I heard that people got a new problem in inputting Japanese text >>> into Scratch 1.4 running on Raspberry Pi OS after, or around the version >>> 2020-08-20. I would like to take a look at it but it might involve >>> recompiling and generating the VM with debugging info. Last time I looked >>> into it was years and years ago and I need to basically make a fresh start. >>> >>> Is the process of making NuSqeauk VM For Raspberry Pi up to date >>> and straightforward? Can people point me to the right point to start? >>> >> >> Making a Cog VM for Raspberry pi is straight-forward. Clone >> opensmalltalk-vm. cd to build.linux64ARMv8, read the HowToBuild, cd to build.linux64ARMv8/squeak.cog.spur/build.debug, >> or build.linux64ARMv8/squeak.stack.spur/build.debug, then run ./mvm >> >> _,,,^..^,,,_ >> best, Eliot >> > > > -- > -- Yoshiki > >
-- -- Yoshiki
-- -- Yoshiki
-- -- Yoshiki
-- _,,,^..^,,,_ best, Eliot
-- -- Yoshiki
Thanks! Maybe I should not have sent a separate email to Eliot ^^;
On Tue, Oct 27, 2020 at 10:46 AM Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
Ah too late, Eliot was faster, hit the pull request next time :)
Le mar. 27 oct. 2020 à 18:43, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> a écrit :
Hi Yoshiki, what you could do is
- revert the changes to sqPlatformSpecific.h (fseek, ftell) since we
have a working workaround now 2) just create a pull request from the github web interface (that's rather easy) It will be very easy for us to integrate (one click), and we'll keep your authorship.
Le mar. 27 oct. 2020 à 18:02, Yoshiki Ohshima Yoshiki.Ohshima@acm.org a écrit :
I have a branch on a clone on github:
https://github.com/yoshikiohshima/opensmalltalk-vm/tree/composition-input-fi...
It might be easier to pull from this? Separately, I'll mail you sqUnixX11.c.
On Tue, Oct 27, 2020 at 9:58 AM Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Yoshiki,
on my Mac patch isn't smart enough to decode a git diff. Can youjust email me your platforms/unix/vm-display-X11/sqUnixX11.c and I'll integrate? Thanks!
On Tue, Oct 27, 2020 at 8:21 AM Yoshiki Ohshima < Yoshiki.Ohshima@acm.org> wrote:
The previous one was just a hack but I think I found the real problem. It was about the variable symbolic, that gets symbolic key code *when* it is needed has to be zero'ed out when it is not needed.
The diff is attached... I'll a make pull request if that helps.
On Sat, Oct 24, 2020 at 5:32 PM Yoshiki Ohshima < Yoshiki.Ohshima@acm.org> wrote:
For the /build.linuxARMv6/squeak.cog.spur/build.debug case, a hack I did was like this:
diff --git a/platforms/unix/vm/sqPlatformSpecific.h b/platforms/unix/vm/sqPlatformSpecific.h
index 268593673..bfb57257b 100644
--- a/platforms/unix/vm/sqPlatformSpecific.h
+++ b/platforms/unix/vm/sqPlatformSpecific.h
@@ -105,8 +105,8 @@ extern void sqFilenameFromString(char *uxName, sqInt stNameIndex, int sqNameLeng
#undef sqFTruncate
/* sqFTruncate should return 0 on success, ftruncate does also */
#define sqFTruncate(f,o) ftruncate(fileno(f), o)
-#define ftell(s) ftello(s)
-#define fseek(s,o,w) fseeko(s,o,w)
+// #define ftell(s) ftello(s)
+// #define fseek(s,o,w) fseeko(s,o,w)
#if defined(__GNUC__)
# if !defined(VM_LABEL)
diff --git a/spur64src/vm/cogit.c b/spur64src/vm/cogit.c
index d62b05f40..e1c14a021 100644
--- a/spur64src/vm/cogit.c
+++ b/spur64src/vm/cogit.c
@@ -6,6 +6,8 @@
# define SysV 1
#endif
+#define __arm64__
#if defined(__arm64__) || defined(__aarch64__) || defined(__ARM_ARCH_ISA_A64) || defined(ARM64) || defined(ARMv8)
and this produced a runnable VM on Raspberry Pi4
On Sat, Oct 24, 2020 at 4:41 PM Yoshiki Ohshima < Yoshiki.Ohshima@acm.org> wrote:
> And I tried a few more things by checking out the last release tag > 202003021730 or try opensmalltalk-vm/build. > linuxARMv6/squeak.cog.spur/build.debug but those attempts did not > work. For the latter got this error: > > In file included from /usr/include/features.h:424, > > from /usr/include/pthread.h:21, > > from > /home/pi/opensmalltalk-vm/platforms/unix/vm/sqPlatformSpecific.h:62, > > from > /home/pi/opensmalltalk-vm/platforms/Cross/vm/sqAssert.h:16, > > from > /home/pi/opensmalltalk-vm/platforms/unix/vm/aio.c:35: > > /usr/include/stdio.h:721:12: error: conflicting types for ‘fseeko’ > > extern int __REDIRECT (fseeko, > > ^~~~~~~~~~ > > In file included from > /home/pi/opensmalltalk-vm/platforms/Cross/vm/sqAssert.h:16, > > from > /home/pi/opensmalltalk-vm/platforms/unix/vm/aio.c:35: > > /home/pi/opensmalltalk-vm/platforms/unix/vm/sqPlatformSpecific.h:109:22: > note: previous declaration \ > > of ‘fseeko’ was here > > #define fseek(s,o,w) fseeko(s,o,w) > > ^~~~~~ > > > > > On Sat, Oct 24, 2020 at 1:59 PM Yoshiki Ohshima < > Yoshiki.Ohshima@acm.org> wrote: > >> Hi Eliot, >> >> For build.linux64ARMv8/squeak.cog.spur/build.debug, i get the >> following error. I think I followed the steps in the instructions, >> including running updateSCCSVersion and mvm. How can I fix it? >> >> /home/pi/opensmalltalk-vm/spur64src/vm/cogit.c:22:3: error: #error >> As yet no Cogit implementation appears to exist for your platform. >> >> # error As yet no Cogit implementation appears to exist for your >> platform. >> >> ^~~~~ >> >> /home/pi/opensmalltalk-vm/spur64src/vm/cogit.c:23:3: error: #error >> Consider implementing it, starting by adding a subclass of >> CogAbstractInstruction. >> >> # error Consider implementing it, starting by adding a subclass >> of CogAbstractInstruction. >> >> ^~~~~ >> >> make[1]: *** [Makefile:207: cogit.o] >> >> On Wed, Oct 21, 2020 at 10:21 AM Eliot Miranda < >> eliot.miranda@gmail.com> wrote: >> >>> >>> Hi Yoshiki, >>> >>> On Wed, Oct 21, 2020 at 10:14 AM Yoshiki Ohshima < >>> Yoshiki.Ohshima@acm.org> wrote: >>> >>>> >>>> Hi, >>>> >>>> I heard that people got a new problem in inputting Japanese text >>>> into Scratch 1.4 running on Raspberry Pi OS after, or around the version >>>> 2020-08-20. I would like to take a look at it but it might involve >>>> recompiling and generating the VM with debugging info. Last time I looked >>>> into it was years and years ago and I need to basically make a fresh start. >>>> >>>> Is the process of making NuSqeauk VM For Raspberry Pi up to date >>>> and straightforward? Can people point me to the right point to start? >>>> >>> >>> Making a Cog VM for Raspberry pi is straight-forward. Clone >>> opensmalltalk-vm. cd to build.linux64ARMv8, read the HowToBuild, cd to build.linux64ARMv8/squeak.cog.spur/build.debug, >>> or build.linux64ARMv8/squeak.stack.spur/build.debug, then run >>> ./mvm >>> >>> _,,,^..^,,,_ >>> best, Eliot >>> >> >> >> -- >> -- Yoshiki >> >> > > -- > -- Yoshiki > >
-- -- Yoshiki
-- -- Yoshiki
-- _,,,^..^,,,_ best, Eliot
-- -- Yoshiki
On Tue, Oct 27, 2020 at 11:14 AM Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
Thanks! Maybe I should not have sent a separate email to Eliot ^^;
Don't sweat it :-) Fixes gratefully received :-) Thanks *very* much for attending to the input issue. Much appreciated.
On Tue, Oct 27, 2020 at 10:46 AM Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
Ah too late, Eliot was faster, hit the pull request next time :)
Le mar. 27 oct. 2020 à 18:43, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> a écrit :
Hi Yoshiki, what you could do is
- revert the changes to sqPlatformSpecific.h (fseek, ftell) since we
have a working workaround now 2) just create a pull request from the github web interface (that's rather easy) It will be very easy for us to integrate (one click), and we'll keep your authorship.
Le mar. 27 oct. 2020 à 18:02, Yoshiki Ohshima Yoshiki.Ohshima@acm.org a écrit :
I have a branch on a clone on github:
https://github.com/yoshikiohshima/opensmalltalk-vm/tree/composition-input-fi...
It might be easier to pull from this? Separately, I'll mail you sqUnixX11.c.
On Tue, Oct 27, 2020 at 9:58 AM Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Yoshiki,
on my Mac patch isn't smart enough to decode a git diff. Can youjust email me your platforms/unix/vm-display-X11/sqUnixX11.c and I'll integrate? Thanks!
On Tue, Oct 27, 2020 at 8:21 AM Yoshiki Ohshima < Yoshiki.Ohshima@acm.org> wrote:
The previous one was just a hack but I think I found the real problem. It was about the variable symbolic, that gets symbolic key code *when* it is needed has to be zero'ed out when it is not needed.
The diff is attached... I'll a make pull request if that helps.
On Sat, Oct 24, 2020 at 5:32 PM Yoshiki Ohshima < Yoshiki.Ohshima@acm.org> wrote:
> For the /build.linuxARMv6/squeak.cog.spur/build.debug case, a hack > I did was like this: > > diff --git a/platforms/unix/vm/sqPlatformSpecific.h > b/platforms/unix/vm/sqPlatformSpecific.h > > index 268593673..bfb57257b 100644 > > --- a/platforms/unix/vm/sqPlatformSpecific.h > > +++ b/platforms/unix/vm/sqPlatformSpecific.h > > @@ -105,8 +105,8 @@ extern void sqFilenameFromString(char *uxName, > sqInt stNameIndex, int sqNameLeng > > #undef sqFTruncate > > /* sqFTruncate should return 0 on success, ftruncate does also */ > > #define sqFTruncate(f,o) ftruncate(fileno(f), o) > > -#define ftell(s) ftello(s) > > -#define fseek(s,o,w) fseeko(s,o,w) > > +// #define ftell(s) ftello(s) > > +// #define fseek(s,o,w) fseeko(s,o,w) > > > #if defined(__GNUC__) > > # if !defined(VM_LABEL) > > diff --git a/spur64src/vm/cogit.c b/spur64src/vm/cogit.c > > index d62b05f40..e1c14a021 100644 > > --- a/spur64src/vm/cogit.c > > +++ b/spur64src/vm/cogit.c > > @@ -6,6 +6,8 @@ > > # define SysV 1 > > #endif > > > +#define __arm64__ > > + > > #if defined(__arm64__) || defined(__aarch64__) || > defined(__ARM_ARCH_ISA_A64) || defined(ARM64) || defined(ARMv8) > > > and this produced a runnable VM on Raspberry Pi4 > > On Sat, Oct 24, 2020 at 4:41 PM Yoshiki Ohshima < > Yoshiki.Ohshima@acm.org> wrote: > >> And I tried a few more things by checking out the last release tag >> 202003021730 or try opensmalltalk-vm/build. >> linuxARMv6/squeak.cog.spur/build.debug but those attempts did not >> work. For the latter got this error: >> >> In file included from /usr/include/features.h:424, >> >> from /usr/include/pthread.h:21, >> >> from >> /home/pi/opensmalltalk-vm/platforms/unix/vm/sqPlatformSpecific.h:62, >> >> from >> /home/pi/opensmalltalk-vm/platforms/Cross/vm/sqAssert.h:16, >> >> from >> /home/pi/opensmalltalk-vm/platforms/unix/vm/aio.c:35: >> >> /usr/include/stdio.h:721:12: error: conflicting types for ‘fseeko’ >> >> extern int __REDIRECT (fseeko, >> >> ^~~~~~~~~~ >> >> In file included from >> /home/pi/opensmalltalk-vm/platforms/Cross/vm/sqAssert.h:16, >> >> from >> /home/pi/opensmalltalk-vm/platforms/unix/vm/aio.c:35: >> >> /home/pi/opensmalltalk-vm/platforms/unix/vm/sqPlatformSpecific.h:109:22: >> note: previous declaration \ >> >> of ‘fseeko’ was here >> >> #define fseek(s,o,w) fseeko(s,o,w) >> >> ^~~~~~ >> >> >> >> >> On Sat, Oct 24, 2020 at 1:59 PM Yoshiki Ohshima < >> Yoshiki.Ohshima@acm.org> wrote: >> >>> Hi Eliot, >>> >>> For build.linux64ARMv8/squeak.cog.spur/build.debug, i get the >>> following error. I think I followed the steps in the instructions, >>> including running updateSCCSVersion and mvm. How can I fix it? >>> >>> /home/pi/opensmalltalk-vm/spur64src/vm/cogit.c:22:3: error: #error >>> As yet no Cogit implementation appears to exist for your platform. >>> >>> # error As yet no Cogit implementation appears to exist for your >>> platform. >>> >>> ^~~~~ >>> >>> /home/pi/opensmalltalk-vm/spur64src/vm/cogit.c:23:3: error: #error >>> Consider implementing it, starting by adding a subclass of >>> CogAbstractInstruction. >>> >>> # error Consider implementing it, starting by adding a subclass >>> of CogAbstractInstruction. >>> >>> ^~~~~ >>> >>> make[1]: *** [Makefile:207: cogit.o] >>> >>> On Wed, Oct 21, 2020 at 10:21 AM Eliot Miranda < >>> eliot.miranda@gmail.com> wrote: >>> >>>> >>>> Hi Yoshiki, >>>> >>>> On Wed, Oct 21, 2020 at 10:14 AM Yoshiki Ohshima < >>>> Yoshiki.Ohshima@acm.org> wrote: >>>> >>>>> >>>>> Hi, >>>>> >>>>> I heard that people got a new problem in inputting Japanese text >>>>> into Scratch 1.4 running on Raspberry Pi OS after, or around the version >>>>> 2020-08-20. I would like to take a look at it but it might involve >>>>> recompiling and generating the VM with debugging info. Last time I looked >>>>> into it was years and years ago and I need to basically make a fresh start. >>>>> >>>>> Is the process of making NuSqeauk VM For Raspberry Pi up to date >>>>> and straightforward? Can people point me to the right point to start? >>>>> >>>> >>>> Making a Cog VM for Raspberry pi is straight-forward. Clone >>>> opensmalltalk-vm. cd to build.linux64ARMv8, read the HowToBuild, cd to build.linux64ARMv8/squeak.cog.spur/build.debug, >>>> or build.linux64ARMv8/squeak.stack.spur/build.debug, then run >>>> ./mvm >>>> >>>> _,,,^..^,,,_ >>>> best, Eliot >>>> >>> >>> >>> -- >>> -- Yoshiki >>> >>> >> >> -- >> -- Yoshiki >> >> > > -- > -- Yoshiki > >
-- -- Yoshiki
-- _,,,^..^,,,_ best, Eliot
-- -- Yoshiki
-- -- Yoshiki
Come to think of it, a better fix for a problem like this one:
KeySym symbolic; int keyCode= x2sqKey(&evt->xkey, &symbolic); int ucs4= xkeysym2ucs4(symbolic);
was (obviously) to change the first line to:
KeySym symbolic= 0;
rather than to try to store 0 into *symbolic on the callee side. (A professor of my college days once told us that "most bugs are related to uninitialized variables." I should've known better.)
When I get around to it, I'll make another change and this time make a pull request.
On Tue, Oct 27, 2020 at 11:43 AM Eliot Miranda eliot.miranda@gmail.com wrote:
On Tue, Oct 27, 2020 at 11:14 AM Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
Thanks! Maybe I should not have sent a separate email to Eliot ^^;
Don't sweat it :-) Fixes gratefully received :-) Thanks *very* much for attending to the input issue. Much appreciated.
On Tue, Oct 27, 2020 at 10:46 AM Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
Ah too late, Eliot was faster, hit the pull request next time :)
Le mar. 27 oct. 2020 à 18:43, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> a écrit :
Hi Yoshiki, what you could do is
- revert the changes to sqPlatformSpecific.h (fseek, ftell) since we
have a working workaround now 2) just create a pull request from the github web interface (that's rather easy) It will be very easy for us to integrate (one click), and we'll keep your authorship.
Le mar. 27 oct. 2020 à 18:02, Yoshiki Ohshima Yoshiki.Ohshima@acm.org a écrit :
I have a branch on a clone on github:
https://github.com/yoshikiohshima/opensmalltalk-vm/tree/composition-input-fi...
It might be easier to pull from this? Separately, I'll mail you sqUnixX11.c.
On Tue, Oct 27, 2020 at 9:58 AM Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Yoshiki,
on my Mac patch isn't smart enough to decode a git diff. Can youjust email me your platforms/unix/vm-display-X11/sqUnixX11.c and I'll integrate? Thanks!
On Tue, Oct 27, 2020 at 8:21 AM Yoshiki Ohshima < Yoshiki.Ohshima@acm.org> wrote:
> > The previous one was just a hack but I think I found the real > problem. It was about the variable symbolic, that gets symbolic key code > *when* it is needed has to be zero'ed out when it is not needed. > > The diff is attached... I'll a make pull request if that helps. > > On Sat, Oct 24, 2020 at 5:32 PM Yoshiki Ohshima < > Yoshiki.Ohshima@acm.org> wrote: > >> For the /build.linuxARMv6/squeak.cog.spur/build.debug case, a >> hack I did was like this: >> >> diff --git a/platforms/unix/vm/sqPlatformSpecific.h >> b/platforms/unix/vm/sqPlatformSpecific.h >> >> index 268593673..bfb57257b 100644 >> >> --- a/platforms/unix/vm/sqPlatformSpecific.h >> >> +++ b/platforms/unix/vm/sqPlatformSpecific.h >> >> @@ -105,8 +105,8 @@ extern void sqFilenameFromString(char *uxName, >> sqInt stNameIndex, int sqNameLeng >> >> #undef sqFTruncate >> >> /* sqFTruncate should return 0 on success, ftruncate does also */ >> >> #define sqFTruncate(f,o) ftruncate(fileno(f), o) >> >> -#define ftell(s) ftello(s) >> >> -#define fseek(s,o,w) fseeko(s,o,w) >> >> +// #define ftell(s) ftello(s) >> >> +// #define fseek(s,o,w) fseeko(s,o,w) >> >> >> #if defined(__GNUC__) >> >> # if !defined(VM_LABEL) >> >> diff --git a/spur64src/vm/cogit.c b/spur64src/vm/cogit.c >> >> index d62b05f40..e1c14a021 100644 >> >> --- a/spur64src/vm/cogit.c >> >> +++ b/spur64src/vm/cogit.c >> >> @@ -6,6 +6,8 @@ >> >> # define SysV 1 >> >> #endif >> >> >> +#define __arm64__ >> >> + >> >> #if defined(__arm64__) || defined(__aarch64__) || >> defined(__ARM_ARCH_ISA_A64) || defined(ARM64) || defined(ARMv8) >> >> >> and this produced a runnable VM on Raspberry Pi4 >> >> On Sat, Oct 24, 2020 at 4:41 PM Yoshiki Ohshima < >> Yoshiki.Ohshima@acm.org> wrote: >> >>> And I tried a few more things by checking out the last release tag >>> 202003021730 or try opensmalltalk-vm/build. >>> linuxARMv6/squeak.cog.spur/build.debug but those attempts did not >>> work. For the latter got this error: >>> >>> In file included from /usr/include/features.h:424, >>> >>> from /usr/include/pthread.h:21, >>> >>> from >>> /home/pi/opensmalltalk-vm/platforms/unix/vm/sqPlatformSpecific.h:62, >>> >>> from >>> /home/pi/opensmalltalk-vm/platforms/Cross/vm/sqAssert.h:16, >>> >>> from >>> /home/pi/opensmalltalk-vm/platforms/unix/vm/aio.c:35: >>> >>> /usr/include/stdio.h:721:12: error: conflicting types for ‘fseeko’ >>> >>> extern int __REDIRECT (fseeko, >>> >>> ^~~~~~~~~~ >>> >>> In file included from >>> /home/pi/opensmalltalk-vm/platforms/Cross/vm/sqAssert.h:16, >>> >>> from >>> /home/pi/opensmalltalk-vm/platforms/unix/vm/aio.c:35: >>> >>> /home/pi/opensmalltalk-vm/platforms/unix/vm/sqPlatformSpecific.h:109:22: >>> note: previous declaration \ >>> >>> of ‘fseeko’ was here >>> >>> #define fseek(s,o,w) fseeko(s,o,w) >>> >>> ^~~~~~ >>> >>> >>> >>> >>> On Sat, Oct 24, 2020 at 1:59 PM Yoshiki Ohshima < >>> Yoshiki.Ohshima@acm.org> wrote: >>> >>>> Hi Eliot, >>>> >>>> For build.linux64ARMv8/squeak.cog.spur/build.debug, i get the >>>> following error. I think I followed the steps in the instructions, >>>> including running updateSCCSVersion and mvm. How can I fix it? >>>> >>>> /home/pi/opensmalltalk-vm/spur64src/vm/cogit.c:22:3: error: >>>> #error As yet no Cogit implementation appears to exist for your platform. >>>> >>>> # error As yet no Cogit implementation appears to exist for >>>> your platform. >>>> >>>> ^~~~~ >>>> >>>> /home/pi/opensmalltalk-vm/spur64src/vm/cogit.c:23:3: error: >>>> #error Consider implementing it, starting by adding a subclass of >>>> CogAbstractInstruction. >>>> >>>> # error Consider implementing it, starting by adding a subclass >>>> of CogAbstractInstruction. >>>> >>>> ^~~~~ >>>> >>>> make[1]: *** [Makefile:207: cogit.o] >>>> >>>> On Wed, Oct 21, 2020 at 10:21 AM Eliot Miranda < >>>> eliot.miranda@gmail.com> wrote: >>>> >>>>> >>>>> Hi Yoshiki, >>>>> >>>>> On Wed, Oct 21, 2020 at 10:14 AM Yoshiki Ohshima < >>>>> Yoshiki.Ohshima@acm.org> wrote: >>>>> >>>>>> >>>>>> Hi, >>>>>> >>>>>> I heard that people got a new problem in inputting Japanese >>>>>> text into Scratch 1.4 running on Raspberry Pi OS after, or around the >>>>>> version 2020-08-20. I would like to take a look at it but it might involve >>>>>> recompiling and generating the VM with debugging info. Last time I looked >>>>>> into it was years and years ago and I need to basically make a fresh start. >>>>>> >>>>>> Is the process of making NuSqeauk VM For Raspberry Pi up to >>>>>> date and straightforward? Can people point me to the right point to start? >>>>>> >>>>> >>>>> Making a Cog VM for Raspberry pi is straight-forward. Clone >>>>> opensmalltalk-vm. cd to build.linux64ARMv8, read the HowToBuild, cd to build.linux64ARMv8/squeak.cog.spur/build.debug, >>>>> or build.linux64ARMv8/squeak.stack.spur/build.debug, then run >>>>> ./mvm >>>>> >>>>> _,,,^..^,,,_ >>>>> best, Eliot >>>>> >>>> >>>> >>>> -- >>>> -- Yoshiki >>>> >>>> >>> >>> -- >>> -- Yoshiki >>> >>> >> >> -- >> -- Yoshiki >> >> > > -- > -- Yoshiki > >
-- _,,,^..^,,,_ best, Eliot
-- -- Yoshiki
-- -- Yoshiki
-- _,,,^..^,,,_ best, Eliot
Hi Yoshiki,
On Oct 28, 2020, at 8:34 AM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
Come to think of it, a better fix for a problem like this one:
KeySym symbolic; int keyCode= x2sqKey(&evt->xkey, &symbolic); int ucs4= xkeysym2ucs4(symbolic);
was (obviously) to change the first line to:
KeySym symbolic= 0;
rather than to try to store 0 into *symbolic on the callee side. (A professor of my college days once told us that "most bugs are related to uninitialized variables." I should've known better.)
I had exactly this bug in the win32 CameraPlugin the other day. And it didn’t surface until shutting down the plugin on exiting the system. C, what a love/hate relationship it engenders :-)
When I get around to it, I'll make another change and this time make a pull request.
Or if you’d like I could invite you to become a committer and then you could avoid the pull request.
On Tue, Oct 27, 2020 at 11:43 AM Eliot Miranda eliot.miranda@gmail.com wrote:
On Tue, Oct 27, 2020 at 11:14 AM Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
Thanks! Maybe I should not have sent a separate email to Eliot ^^;
Don't sweat it :-) Fixes gratefully received :-) Thanks *very* much for attending to the input issue. Much appreciated.
On Tue, Oct 27, 2020 at 10:46 AM Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
Ah too late, Eliot was faster, hit the pull request next time :)
Le mar. 27 oct. 2020 à 18:43, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com a écrit : Hi Yoshiki, what you could do is
- revert the changes to sqPlatformSpecific.h (fseek, ftell) since we have a working workaround now
- just create a pull request from the github web interface (that's rather easy)
It will be very easy for us to integrate (one click), and we'll keep your authorship.
Le mar. 27 oct. 2020 à 18:02, Yoshiki Ohshima Yoshiki.Ohshima@acm.org a écrit :
I have a branch on a clone on github:
https://github.com/yoshikiohshima/opensmalltalk-vm/tree/composition-input-fi...
It might be easier to pull from this? Separately, I'll mail you sqUnixX11.c.
> On Tue, Oct 27, 2020 at 9:58 AM Eliot Miranda eliot.miranda@gmail.com wrote: > > Hi Yoshiki, > > on my Mac patch isn't smart enough to decode a git diff. Can you just email me your platforms/unix/vm-display-X11/sqUnixX11.c and I'll integrate? Thanks! > > On Tue, Oct 27, 2020 at 8:21 AM Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote: >> >> The previous one was just a hack but I think I found the real problem. It was about the variable symbolic, that gets symbolic key code *when* it is needed has to be zero'ed out when it is not needed. >> >> The diff is attached... I'll a make pull request if that helps. >> >>> On Sat, Oct 24, 2020 at 5:32 PM Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote: >>> For the /build.linuxARMv6/squeak.cog.spur/build.debug case, a hack I did was like this: >>> >>> diff --git a/platforms/unix/vm/sqPlatformSpecific.h b/platforms/unix/vm/sqPlatformSpecific.h >>> index 268593673..bfb57257b 100644 >>> --- a/platforms/unix/vm/sqPlatformSpecific.h >>> +++ b/platforms/unix/vm/sqPlatformSpecific.h >>> @@ -105,8 +105,8 @@ extern void sqFilenameFromString(char *uxName, sqInt stNameIndex, int sqNameLeng >>> #undef sqFTruncate >>> /* sqFTruncate should return 0 on success, ftruncate does also */ >>> #define sqFTruncate(f,o) ftruncate(fileno(f), o) >>> -#define ftell(s) ftello(s) >>> -#define fseek(s,o,w) fseeko(s,o,w) >>> +// #define ftell(s) ftello(s) >>> +// #define fseek(s,o,w) fseeko(s,o,w) >>> >>> #if defined(__GNUC__) >>> # if !defined(VM_LABEL) >>> diff --git a/spur64src/vm/cogit.c b/spur64src/vm/cogit.c >>> index d62b05f40..e1c14a021 100644 >>> --- a/spur64src/vm/cogit.c >>> +++ b/spur64src/vm/cogit.c >>> @@ -6,6 +6,8 @@ >>> # define SysV 1 >>> #endif >>> >>> +#define __arm64__ >>> + >>> #if defined(__arm64__) || defined(__aarch64__) || defined(__ARM_ARCH_ISA_A64) || defined(ARM64) || defined(ARMv8) >>> >>> and this produced a runnable VM on Raspberry Pi4 >>> >>>> On Sat, Oct 24, 2020 at 4:41 PM Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote: >>>> And I tried a few more things by checking out the last release tag 202003021730 or try opensmalltalk-vm/build.linuxARMv6/squeak.cog.spur/build.debug but those attempts did not work. For the latter got this error: >>>> >>>> In file included from /usr/include/features.h:424, >>>> from /usr/include/pthread.h:21, >>>> from /home/pi/opensmalltalk-vm/platforms/unix/vm/sqPlatformSpecific.h:62, >>>> from /home/pi/opensmalltalk-vm/platforms/Cross/vm/sqAssert.h:16, >>>> from /home/pi/opensmalltalk-vm/platforms/unix/vm/aio.c:35: >>>> /usr/include/stdio.h:721:12: error: conflicting types for ‘fseeko’ >>>> extern int __REDIRECT (fseeko, >>>> ^~~~~~~~~~ >>>> In file included from /home/pi/opensmalltalk-vm/platforms/Cross/vm/sqAssert.h:16, >>>> from /home/pi/opensmalltalk-vm/platforms/unix/vm/aio.c:35: >>>> /home/pi/opensmalltalk-vm/platforms/unix/vm/sqPlatformSpecific.h:109:22: note: previous declaration \ >>>> of ‘fseeko’ was here >>>> #define fseek(s,o,w) fseeko(s,o,w) >>>> ^~~~~~ >>>> >>>> >>>> >>>>> On Sat, Oct 24, 2020 at 1:59 PM Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote: >>>>> Hi Eliot, >>>>> >>>>> For build.linux64ARMv8/squeak.cog.spur/build.debug, i get the following error. I think I followed the steps in the instructions, including running updateSCCSVersion and mvm. How can I fix it? >>>>> >>>>> /home/pi/opensmalltalk-vm/spur64src/vm/cogit.c:22:3: error: #error As yet no Cogit implementation appears to exist for your platform. >>>>> # error As yet no Cogit implementation appears to exist for your platform. >>>>> ^~~~~ >>>>> /home/pi/opensmalltalk-vm/spur64src/vm/cogit.c:23:3: error: #error Consider implementing it, starting by adding a subclass of CogAbstractInstruction. >>>>> # error Consider implementing it, starting by adding a subclass of CogAbstractInstruction. >>>>> ^~~~~ >>>>> make[1]: *** [Makefile:207: cogit.o] >>>>> >>>>>> On Wed, Oct 21, 2020 at 10:21 AM Eliot Miranda eliot.miranda@gmail.com wrote: >>>>>> >>>>>> Hi Yoshiki, >>>>>> >>>>>>> On Wed, Oct 21, 2020 at 10:14 AM Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I heard that people got a new problem in inputting Japanese text into Scratch 1.4 running on Raspberry Pi OS after, or around the version 2020-08-20. I would like to take a look at it but it might involve recompiling and generating the VM with debugging info. Last time I looked into it was years and years ago and I need to basically make a fresh start. >>>>>>> >>>>>>> Is the process of making NuSqeauk VM For Raspberry Pi up to date and straightforward? Can people point me to the right point to start? >>>>>> >>>>>> Making a Cog VM for Raspberry pi is straight-forward. Clone opensmalltalk-vm. cd to build.linux64ARMv8, read the HowToBuild, cd to build.linux64ARMv8/squeak.cog.spur/build.debug, or build.linux64ARMv8/squeak.stack.spur/build.debug, then run ./mvm >>>>>> >>>>>> _,,,^..^,,,_ >>>>>> best, Eliot >>>>> >>>>> >>>>> -- >>>>> -- Yoshiki >>>>> >>>> >>>> >>>> -- >>>> -- Yoshiki >>>> >>> >>> >>> -- >>> -- Yoshiki >>> >> >> >> -- >> -- Yoshiki >> > > > -- > _,,,^..^,,,_ > best, Eliot
-- -- Yoshiki
-- -- Yoshiki
-- _,,,^..^,,,_ best, Eliot
-- -- Yoshiki
Ok!
I did make a pull request but then merged it by myself. Next thing for me to try is to build linux64ARMv8.
On Wed, Oct 28, 2020 at 8:47 AM Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Yoshiki,
On Oct 28, 2020, at 8:34 AM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
Come to think of it, a better fix for a problem like this one:
KeySym symbolic; int keyCode= x2sqKey(&evt->xkey, &symbolic); int ucs4= xkeysym2ucs4(symbolic);
was (obviously) to change the first line to:
KeySym symbolic= 0;
rather than to try to store 0 into *symbolic on the callee side. (A professor of my college days once told us that "most bugs are related to uninitialized variables." I should've known better.)
I had exactly this bug in the win32 CameraPlugin the other day. And it didn’t surface until shutting down the plugin on exiting the system. C, what a love/hate relationship it engenders :-)
When I get around to it, I'll make another change and this time make a pull request.
Or if you’d like I could invite you to become a committer and then you could avoid the pull request.
On Tue, Oct 27, 2020 at 11:43 AM Eliot Miranda eliot.miranda@gmail.com wrote:
On Tue, Oct 27, 2020 at 11:14 AM Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
Thanks! Maybe I should not have sent a separate email to Eliot ^^;
Don't sweat it :-) Fixes gratefully received :-) Thanks *very* much for attending to the input issue. Much appreciated.
On Tue, Oct 27, 2020 at 10:46 AM Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
Ah too late, Eliot was faster, hit the pull request next time :)
Le mar. 27 oct. 2020 à 18:43, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> a écrit :
Hi Yoshiki, what you could do is
- revert the changes to sqPlatformSpecific.h (fseek, ftell) since we
have a working workaround now 2) just create a pull request from the github web interface (that's rather easy) It will be very easy for us to integrate (one click), and we'll keep your authorship.
Le mar. 27 oct. 2020 à 18:02, Yoshiki Ohshima Yoshiki.Ohshima@acm.org a écrit :
I have a branch on a clone on github:
https://github.com/yoshikiohshima/opensmalltalk-vm/tree/composition-input-fi...
It might be easier to pull from this? Separately, I'll mail you sqUnixX11.c.
On Tue, Oct 27, 2020 at 9:58 AM Eliot Miranda < eliot.miranda@gmail.com> wrote:
> > Hi Yoshiki, > > on my Mac patch isn't smart enough to decode a git diff. Can > you just email me your platforms/unix/vm-display-X11/sqUnixX11.c and I'll > integrate? Thanks! > > On Tue, Oct 27, 2020 at 8:21 AM Yoshiki Ohshima < > Yoshiki.Ohshima@acm.org> wrote: > >> >> The previous one was just a hack but I think I found the real >> problem. It was about the variable symbolic, that gets symbolic key code >> *when* it is needed has to be zero'ed out when it is not needed. >> >> The diff is attached... I'll a make pull request if that helps. >> >> On Sat, Oct 24, 2020 at 5:32 PM Yoshiki Ohshima < >> Yoshiki.Ohshima@acm.org> wrote: >> >>> For the /build.linuxARMv6/squeak.cog.spur/build.debug case, a >>> hack I did was like this: >>> >>> diff --git a/platforms/unix/vm/sqPlatformSpecific.h >>> b/platforms/unix/vm/sqPlatformSpecific.h >>> >>> index 268593673..bfb57257b 100644 >>> >>> --- a/platforms/unix/vm/sqPlatformSpecific.h >>> >>> +++ b/platforms/unix/vm/sqPlatformSpecific.h >>> >>> @@ -105,8 +105,8 @@ extern void sqFilenameFromString(char >>> *uxName, sqInt stNameIndex, int sqNameLeng >>> >>> #undef sqFTruncate >>> >>> /* sqFTruncate should return 0 on success, ftruncate does also */ >>> >>> #define sqFTruncate(f,o) ftruncate(fileno(f), o) >>> >>> -#define ftell(s) ftello(s) >>> >>> -#define fseek(s,o,w) fseeko(s,o,w) >>> >>> +// #define ftell(s) ftello(s) >>> >>> +// #define fseek(s,o,w) fseeko(s,o,w) >>> >>> >>> #if defined(__GNUC__) >>> >>> # if !defined(VM_LABEL) >>> >>> diff --git a/spur64src/vm/cogit.c b/spur64src/vm/cogit.c >>> >>> index d62b05f40..e1c14a021 100644 >>> >>> --- a/spur64src/vm/cogit.c >>> >>> +++ b/spur64src/vm/cogit.c >>> >>> @@ -6,6 +6,8 @@ >>> >>> # define SysV 1 >>> >>> #endif >>> >>> >>> +#define __arm64__ >>> >>> + >>> >>> #if defined(__arm64__) || defined(__aarch64__) || >>> defined(__ARM_ARCH_ISA_A64) || defined(ARM64) || defined(ARMv8) >>> >>> >>> and this produced a runnable VM on Raspberry Pi4 >>> >>> On Sat, Oct 24, 2020 at 4:41 PM Yoshiki Ohshima < >>> Yoshiki.Ohshima@acm.org> wrote: >>> >>>> And I tried a few more things by checking out the last release >>>> tag 202003021730 or try opensmalltalk-vm/build. >>>> linuxARMv6/squeak.cog.spur/build.debug but those attempts did >>>> not work. For the latter got this error: >>>> >>>> In file included from /usr/include/features.h:424, >>>> >>>> from /usr/include/pthread.h:21, >>>> >>>> from >>>> /home/pi/opensmalltalk-vm/platforms/unix/vm/sqPlatformSpecific.h:62, >>>> >>>> from >>>> /home/pi/opensmalltalk-vm/platforms/Cross/vm/sqAssert.h:16, >>>> >>>> from >>>> /home/pi/opensmalltalk-vm/platforms/unix/vm/aio.c:35: >>>> >>>> /usr/include/stdio.h:721:12: error: conflicting types for ‘fseeko’ >>>> >>>> extern int __REDIRECT (fseeko, >>>> >>>> ^~~~~~~~~~ >>>> >>>> In file included from >>>> /home/pi/opensmalltalk-vm/platforms/Cross/vm/sqAssert.h:16, >>>> >>>> from >>>> /home/pi/opensmalltalk-vm/platforms/unix/vm/aio.c:35: >>>> >>>> /home/pi/opensmalltalk-vm/platforms/unix/vm/sqPlatformSpecific.h:109:22: >>>> note: previous declaration \ >>>> >>>> of ‘fseeko’ was here >>>> >>>> #define fseek(s,o,w) fseeko(s,o,w) >>>> >>>> ^~~~~~ >>>> >>>> >>>> >>>> >>>> On Sat, Oct 24, 2020 at 1:59 PM Yoshiki Ohshima < >>>> Yoshiki.Ohshima@acm.org> wrote: >>>> >>>>> Hi Eliot, >>>>> >>>>> For build.linux64ARMv8/squeak.cog.spur/build.debug, i get the >>>>> following error. I think I followed the steps in the instructions, >>>>> including running updateSCCSVersion and mvm. How can I fix it? >>>>> >>>>> /home/pi/opensmalltalk-vm/spur64src/vm/cogit.c:22:3: error: >>>>> #error As yet no Cogit implementation appears to exist for your platform. >>>>> >>>>> # error As yet no Cogit implementation appears to exist for >>>>> your platform. >>>>> >>>>> ^~~~~ >>>>> >>>>> /home/pi/opensmalltalk-vm/spur64src/vm/cogit.c:23:3: error: >>>>> #error Consider implementing it, starting by adding a subclass of >>>>> CogAbstractInstruction. >>>>> >>>>> # error Consider implementing it, starting by adding a >>>>> subclass of CogAbstractInstruction. >>>>> >>>>> ^~~~~ >>>>> >>>>> make[1]: *** [Makefile:207: cogit.o] >>>>> >>>>> On Wed, Oct 21, 2020 at 10:21 AM Eliot Miranda < >>>>> eliot.miranda@gmail.com> wrote: >>>>> >>>>>> >>>>>> Hi Yoshiki, >>>>>> >>>>>> On Wed, Oct 21, 2020 at 10:14 AM Yoshiki Ohshima < >>>>>> Yoshiki.Ohshima@acm.org> wrote: >>>>>> >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I heard that people got a new problem in inputting Japanese >>>>>>> text into Scratch 1.4 running on Raspberry Pi OS after, or around the >>>>>>> version 2020-08-20. I would like to take a look at it but it might involve >>>>>>> recompiling and generating the VM with debugging info. Last time I looked >>>>>>> into it was years and years ago and I need to basically make a fresh start. >>>>>>> >>>>>>> Is the process of making NuSqeauk VM For Raspberry Pi up to >>>>>>> date and straightforward? Can people point me to the right point to start? >>>>>>> >>>>>> >>>>>> Making a Cog VM for Raspberry pi is straight-forward. Clone >>>>>> opensmalltalk-vm. cd to build.linux64ARMv8, read the HowToBuild, cd to build.linux64ARMv8/squeak.cog.spur/build.debug, >>>>>> or build.linux64ARMv8/squeak.stack.spur/build.debug, then run >>>>>> ./mvm >>>>>> >>>>>> _,,,^..^,,,_ >>>>>> best, Eliot >>>>>> >>>>> >>>>> >>>>> -- >>>>> -- Yoshiki >>>>> >>>>> >>>> >>>> -- >>>> -- Yoshiki >>>> >>>> >>> >>> -- >>> -- Yoshiki >>> >>> >> >> -- >> -- Yoshiki >> >> > > -- > _,,,^..^,,,_ > best, Eliot >
-- -- Yoshiki
-- -- Yoshiki
-- _,,,^..^,,,_ best, Eliot
-- -- Yoshiki
As for linux64ARMv8, I had to hack like this (The below is somewhat inconsistent but you'll get an idea) to get it produce a VM:
It looks like an issue of missing compiler macros for the architecture. The hack to sqUnixHeartbeat.c is likely to be wrong... the asm code specified for __ARM_ARCHI_ISA_A64 does not compile.
----------------------------------------------- diff --git a/platforms/Cross/vm/sqAtomicOps.h b/platforms/Cross/vm/sqAtomicOps.h index ff5d3fdd7..96abe3a22 100644 --- a/platforms/Cross/vm/sqAtomicOps.h +++ b/platforms/Cross/vm/sqAtomicOps.h @@ -203,7 +203,7 @@ AtomicGet(__int64 *target)
# else /* TARGET_OS_IS_IPHONE elif x86 variants etc */
-#if defined(__arm__) && (defined(__ARM_ARCH_6__) || defined(__ARM_ARCH_7A__)) +#if defined(__arm__) && (defined(__ARM_ARCH_6__) || defined(__ARM_ARCH_7A__)) || 1 /* tpr - this is code intended for the Raspberry Pi Raspbian OS * We'll experimentally trust in our MMU to keep 64bit accesses atomic */ # define get64(variable) variable diff --git a/platforms/unix/vm/sqUnixHeartbeat.c b/platforms/unix/vm/sqUnixHeartbeat.c index e9e3545fa..a526b4515 100644 --- a/platforms/unix/vm/sqUnixHeartbeat.c +++ b/platforms/unix/vm/sqUnixHeartbeat.c @@ -183,7 +183,7 @@ ioHighResClock(void) : "rdx"); #elif defined(__ARM_ARCH_ISA_A64) || defined(__arm64__) || defined(__aarch64__) || defined(ARM64) __asm__ __volatile__ ("MRS X0, CNTVCT_EL0"); -#elif defined(__arm__) && (defined(__ARM_ARCH_6__) || defined(__ARM_ARCH_7A__)) +#elif defined(__arm__) && (defined(__ARM_ARCH_6__) || defined(__ARM_ARCH_7A__)) || 1 /* tpr - do nothing for now; needs input from eliot to decide further */ /* Tim, not sure I have input beyond: Is there a 64-bit clock on ARM? If so, access it here :-) diff --git a/spur64src/vm/cogit.c b/spur64src/vm/cogit.c index d62b05f40..110685ac4 100644 --- a/spur64src/vm/cogit.c +++ b/spur64src/vm/cogit.c @@ -6,6 +6,8 @@ # define SysV 1 #endif
+#define __arm64__ 1 + #if defined(__arm64__) || defined(__aarch64__) || defined(__ARM_ARCH_ISA_A64) || defined(ARM64) || defined(ARMv8)
# include "cogitARMv8.c" diff --git a/src/plugins/SqueakFFIPrims/SqueakFFIPrims.c b/src/plugins/SqueakFFIPrims/SqueakFFIPrims.c index 2878f9529..a0e5e0596 100644 --- a/src/plugins/SqueakFFIPrims/SqueakFFIPrims.c +++ b/src/plugins/SqueakFFIPrims/SqueakFFIPrims.c @@ -7,7 +7,7 @@ # define ARM32FFIPlugin_exports SqueakFFIPrims_exports # include "ARM32FFIPlugin.c"
-#elif defined(__ARM_ARCH_ISA_A64) || defined(__aarch64__) || defined(__arm64__) || defined(ARM64) || defined(_M_ARM64) +#elif defined(__ARM_ARCH_ISA_A64) || defined(__aarch64__) || defined(__arm64__) || defined(ARM64) || defined(_M_ARM64) || 1
# define ARM64FFIPlugin_exports SqueakFFIPrims_exports # include "ARM64FFIPlugin.c"
On Wed, Oct 28, 2020 at 9:24 AM Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
Ok!
I did make a pull request but then merged it by myself. Next thing for me to try is to build linux64ARMv8.
On Wed, Oct 28, 2020 at 8:47 AM Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Yoshiki,
On Oct 28, 2020, at 8:34 AM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
Come to think of it, a better fix for a problem like this one:
KeySym symbolic; int keyCode= x2sqKey(&evt->xkey, &symbolic); int ucs4= xkeysym2ucs4(symbolic);
was (obviously) to change the first line to:
KeySym symbolic= 0;
rather than to try to store 0 into *symbolic on the callee side. (A professor of my college days once told us that "most bugs are related to uninitialized variables." I should've known better.)
I had exactly this bug in the win32 CameraPlugin the other day. And it didn’t surface until shutting down the plugin on exiting the system. C, what a love/hate relationship it engenders :-)
When I get around to it, I'll make another change and this time make a pull request.
Or if you’d like I could invite you to become a committer and then you could avoid the pull request.
On Tue, Oct 27, 2020 at 11:43 AM Eliot Miranda eliot.miranda@gmail.com wrote:
On Tue, Oct 27, 2020 at 11:14 AM Yoshiki Ohshima < Yoshiki.Ohshima@acm.org> wrote:
Thanks! Maybe I should not have sent a separate email to Eliot ^^;
Don't sweat it :-) Fixes gratefully received :-) Thanks *very* much for attending to the input issue. Much appreciated.
On Tue, Oct 27, 2020 at 10:46 AM Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
Ah too late, Eliot was faster, hit the pull request next time :)
Le mar. 27 oct. 2020 à 18:43, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> a écrit :
Hi Yoshiki, what you could do is
- revert the changes to sqPlatformSpecific.h (fseek, ftell) since we
have a working workaround now 2) just create a pull request from the github web interface (that's rather easy) It will be very easy for us to integrate (one click), and we'll keep your authorship.
Le mar. 27 oct. 2020 à 18:02, Yoshiki Ohshima < Yoshiki.Ohshima@acm.org> a écrit :
> > I have a branch on a clone on github: > > > https://github.com/yoshikiohshima/opensmalltalk-vm/tree/composition-input-fi... > > It might be easier to pull from this? Separately, I'll mail you > sqUnixX11.c. > > On Tue, Oct 27, 2020 at 9:58 AM Eliot Miranda < > eliot.miranda@gmail.com> wrote: > >> >> Hi Yoshiki, >> >> on my Mac patch isn't smart enough to decode a git diff. Can >> you just email me your platforms/unix/vm-display-X11/sqUnixX11.c and I'll >> integrate? Thanks! >> >> On Tue, Oct 27, 2020 at 8:21 AM Yoshiki Ohshima < >> Yoshiki.Ohshima@acm.org> wrote: >> >>> >>> The previous one was just a hack but I think I found the real >>> problem. It was about the variable symbolic, that gets symbolic key code >>> *when* it is needed has to be zero'ed out when it is not needed. >>> >>> The diff is attached... I'll a make pull request if that helps. >>> >>> On Sat, Oct 24, 2020 at 5:32 PM Yoshiki Ohshima < >>> Yoshiki.Ohshima@acm.org> wrote: >>> >>>> For the /build.linuxARMv6/squeak.cog.spur/build.debug case, a >>>> hack I did was like this: >>>> >>>> diff --git a/platforms/unix/vm/sqPlatformSpecific.h >>>> b/platforms/unix/vm/sqPlatformSpecific.h >>>> >>>> index 268593673..bfb57257b 100644 >>>> >>>> --- a/platforms/unix/vm/sqPlatformSpecific.h >>>> >>>> +++ b/platforms/unix/vm/sqPlatformSpecific.h >>>> >>>> @@ -105,8 +105,8 @@ extern void sqFilenameFromString(char >>>> *uxName, sqInt stNameIndex, int sqNameLeng >>>> >>>> #undef sqFTruncate >>>> >>>> /* sqFTruncate should return 0 on success, ftruncate does also >>>> */ >>>> >>>> #define sqFTruncate(f,o) ftruncate(fileno(f), o) >>>> >>>> -#define ftell(s) ftello(s) >>>> >>>> -#define fseek(s,o,w) fseeko(s,o,w) >>>> >>>> +// #define ftell(s) ftello(s) >>>> >>>> +// #define fseek(s,o,w) fseeko(s,o,w) >>>> >>>> >>>> #if defined(__GNUC__) >>>> >>>> # if !defined(VM_LABEL) >>>> >>>> diff --git a/spur64src/vm/cogit.c b/spur64src/vm/cogit.c >>>> >>>> index d62b05f40..e1c14a021 100644 >>>> >>>> --- a/spur64src/vm/cogit.c >>>> >>>> +++ b/spur64src/vm/cogit.c >>>> >>>> @@ -6,6 +6,8 @@ >>>> >>>> # define SysV 1 >>>> >>>> #endif >>>> >>>> >>>> +#define __arm64__ >>>> >>>> + >>>> >>>> #if defined(__arm64__) || defined(__aarch64__) || >>>> defined(__ARM_ARCH_ISA_A64) || defined(ARM64) || defined(ARMv8) >>>> >>>> >>>> and this produced a runnable VM on Raspberry Pi4 >>>> >>>> On Sat, Oct 24, 2020 at 4:41 PM Yoshiki Ohshima < >>>> Yoshiki.Ohshima@acm.org> wrote: >>>> >>>>> And I tried a few more things by checking out the last release >>>>> tag 202003021730 or try opensmalltalk-vm/build. >>>>> linuxARMv6/squeak.cog.spur/build.debug but those attempts did >>>>> not work. For the latter got this error: >>>>> >>>>> In file included from /usr/include/features.h:424, >>>>> >>>>> from /usr/include/pthread.h:21, >>>>> >>>>> from >>>>> /home/pi/opensmalltalk-vm/platforms/unix/vm/sqPlatformSpecific.h:62, >>>>> >>>>> from >>>>> /home/pi/opensmalltalk-vm/platforms/Cross/vm/sqAssert.h:16, >>>>> >>>>> from >>>>> /home/pi/opensmalltalk-vm/platforms/unix/vm/aio.c:35: >>>>> >>>>> /usr/include/stdio.h:721:12: error: conflicting types for >>>>> ‘fseeko’ >>>>> >>>>> extern int __REDIRECT (fseeko, >>>>> >>>>> ^~~~~~~~~~ >>>>> >>>>> In file included from >>>>> /home/pi/opensmalltalk-vm/platforms/Cross/vm/sqAssert.h:16, >>>>> >>>>> from >>>>> /home/pi/opensmalltalk-vm/platforms/unix/vm/aio.c:35: >>>>> >>>>> /home/pi/opensmalltalk-vm/platforms/unix/vm/sqPlatformSpecific.h:109:22: >>>>> note: previous declaration \ >>>>> >>>>> of ‘fseeko’ was here >>>>> >>>>> #define fseek(s,o,w) fseeko(s,o,w) >>>>> >>>>> ^~~~~~ >>>>> >>>>> >>>>> >>>>> >>>>> On Sat, Oct 24, 2020 at 1:59 PM Yoshiki Ohshima < >>>>> Yoshiki.Ohshima@acm.org> wrote: >>>>> >>>>>> Hi Eliot, >>>>>> >>>>>> For build.linux64ARMv8/squeak.cog.spur/build.debug, i get the >>>>>> following error. I think I followed the steps in the instructions, >>>>>> including running updateSCCSVersion and mvm. How can I fix it? >>>>>> >>>>>> /home/pi/opensmalltalk-vm/spur64src/vm/cogit.c:22:3: error: >>>>>> #error As yet no Cogit implementation appears to exist for your platform. >>>>>> >>>>>> # error As yet no Cogit implementation appears to exist for >>>>>> your platform. >>>>>> >>>>>> ^~~~~ >>>>>> >>>>>> /home/pi/opensmalltalk-vm/spur64src/vm/cogit.c:23:3: error: >>>>>> #error Consider implementing it, starting by adding a subclass of >>>>>> CogAbstractInstruction. >>>>>> >>>>>> # error Consider implementing it, starting by adding a >>>>>> subclass of CogAbstractInstruction. >>>>>> >>>>>> ^~~~~ >>>>>> >>>>>> make[1]: *** [Makefile:207: cogit.o] >>>>>> >>>>>> On Wed, Oct 21, 2020 at 10:21 AM Eliot Miranda < >>>>>> eliot.miranda@gmail.com> wrote: >>>>>> >>>>>>> >>>>>>> Hi Yoshiki, >>>>>>> >>>>>>> On Wed, Oct 21, 2020 at 10:14 AM Yoshiki Ohshima < >>>>>>> Yoshiki.Ohshima@acm.org> wrote: >>>>>>> >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> I heard that people got a new problem in inputting Japanese >>>>>>>> text into Scratch 1.4 running on Raspberry Pi OS after, or around the >>>>>>>> version 2020-08-20. I would like to take a look at it but it might involve >>>>>>>> recompiling and generating the VM with debugging info. Last time I looked >>>>>>>> into it was years and years ago and I need to basically make a fresh start. >>>>>>>> >>>>>>>> Is the process of making NuSqeauk VM For Raspberry Pi up to >>>>>>>> date and straightforward? Can people point me to the right point to start? >>>>>>>> >>>>>>> >>>>>>> Making a Cog VM for Raspberry pi is straight-forward. Clone >>>>>>> opensmalltalk-vm. cd to build.linux64ARMv8, read the HowToBuild, cd to build.linux64ARMv8/squeak.cog.spur/build.debug, >>>>>>> or build.linux64ARMv8/squeak.stack.spur/build.debug, then run >>>>>>> ./mvm >>>>>>> >>>>>>> _,,,^..^,,,_ >>>>>>> best, Eliot >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> -- Yoshiki >>>>>> >>>>>> >>>>> >>>>> -- >>>>> -- Yoshiki >>>>> >>>>> >>>> >>>> -- >>>> -- Yoshiki >>>> >>>> >>> >>> -- >>> -- Yoshiki >>> >>> >> >> -- >> _,,,^..^,,,_ >> best, Eliot >> > > > -- > -- Yoshiki > >
-- -- Yoshiki
-- _,,,^..^,,,_ best, Eliot
-- -- Yoshiki
-- -- Yoshiki
Weird - I didn't have to change anything to get it to compile, but it won't run on Raspberry Pi OS 64 yet because of the write/execute address flimflammery that Eliot has had to mess with.
On 2020-10-28, at 12:59 PM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
As for linux64ARMv8, I had to hack like this (The below is somewhat inconsistent but you'll get an idea) to get it produce a VM:
It looks like an issue of missing compiler macros for the architecture. The hack to sqUnixHeartbeat.c is likely to be wrong... the asm code specified for __ARM_ARCHI_ISA_A64 does not compile.
diff --git a/platforms/Cross/vm/sqAtomicOps.h b/platforms/Cross/vm/sqAtomicOps.h index ff5d3fdd7..96abe3a22 100644 --- a/platforms/Cross/vm/sqAtomicOps.h +++ b/platforms/Cross/vm/sqAtomicOps.h @@ -203,7 +203,7 @@ AtomicGet(__int64 *target)
# else /* TARGET_OS_IS_IPHONE elif x86 variants etc */
-#if defined(__arm__) && (defined(__ARM_ARCH_6__) || defined(__ARM_ARCH_7A__)) +#if defined(__arm__) && (defined(__ARM_ARCH_6__) || defined(__ARM_ARCH_7A__)) || 1 /* tpr - this is code intended for the Raspberry Pi Raspbian OS
- We'll experimentally trust in our MMU to keep 64bit accesses atomic */
# define get64(variable) variable diff --git a/platforms/unix/vm/sqUnixHeartbeat.c b/platforms/unix/vm/sqUnixHeartbeat.c index e9e3545fa..a526b4515 100644 --- a/platforms/unix/vm/sqUnixHeartbeat.c +++ b/platforms/unix/vm/sqUnixHeartbeat.c @@ -183,7 +183,7 @@ ioHighResClock(void) : "rdx"); #elif defined(__ARM_ARCH_ISA_A64) || defined(__arm64__) || defined(__aarch64__) || defined(ARM64) __asm__ __volatile__ ("MRS X0, CNTVCT_EL0"); -#elif defined(__arm__) && (defined(__ARM_ARCH_6__) || defined(__ARM_ARCH_7A__)) +#elif defined(__arm__) && (defined(__ARM_ARCH_6__) || defined(__ARM_ARCH_7A__)) || 1 /* tpr - do nothing for now; needs input from eliot to decide further */ /* Tim, not sure I have input beyond: Is there a 64-bit clock on ARM? If so, access it here :-) diff --git a/spur64src/vm/cogit.c b/spur64src/vm/cogit.c index d62b05f40..110685ac4 100644 --- a/spur64src/vm/cogit.c +++ b/spur64src/vm/cogit.c @@ -6,6 +6,8 @@ # define SysV 1 #endif
+#define __arm64__ 1
#if defined(__arm64__) || defined(__aarch64__) || defined(__ARM_ARCH_ISA_A64) || defined(ARM64) || defined(ARMv8)
# include "cogitARMv8.c" diff --git a/src/plugins/SqueakFFIPrims/SqueakFFIPrims.c b/src/plugins/SqueakFFIPrims/SqueakFFIPrims.c index 2878f9529..a0e5e0596 100644 --- a/src/plugins/SqueakFFIPrims/SqueakFFIPrims.c +++ b/src/plugins/SqueakFFIPrims/SqueakFFIPrims.c @@ -7,7 +7,7 @@ # define ARM32FFIPlugin_exports SqueakFFIPrims_exports # include "ARM32FFIPlugin.c"
-#elif defined(__ARM_ARCH_ISA_A64) || defined(__aarch64__) || defined(__arm64__) || defined(ARM64) || defined(_M_ARM64) +#elif defined(__ARM_ARCH_ISA_A64) || defined(__aarch64__) || defined(__arm64__) || defined(ARM64) || defined(_M_ARM64) || 1
# define ARM64FFIPlugin_exports SqueakFFIPrims_exports # include "ARM64FFIPlugin.c"
On Wed, Oct 28, 2020 at 9:24 AM Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote: Ok!
I did make a pull request but then merged it by myself. Next thing for me to try is to build linux64ARMv8.
On Wed, Oct 28, 2020 at 8:47 AM Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Yoshiki,
On Oct 28, 2020, at 8:34 AM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
Come to think of it, a better fix for a problem like this one:
KeySym symbolic; int keyCode= x2sqKey(&evt->xkey, &symbolic); int ucs4= xkeysym2ucs4(symbolic);
was (obviously) to change the first line to:
KeySym symbolic= 0;
rather than to try to store 0 into *symbolic on the callee side. (A professor of my college days once told us that "most bugs are related to uninitialized variables." I should've known better.)
I had exactly this bug in the win32 CameraPlugin the other day. And it didn’t surface until shutting down the plugin on exiting the system. C, what a love/hate relationship it engenders :-)
When I get around to it, I'll make another change and this time make a pull request.
Or if you’d like I could invite you to become a committer and then you could avoid the pull request.
On Tue, Oct 27, 2020 at 11:43 AM Eliot Miranda eliot.miranda@gmail.com wrote:
On Tue, Oct 27, 2020 at 11:14 AM Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
Thanks! Maybe I should not have sent a separate email to Eliot ^^;
Don't sweat it :-) Fixes gratefully received :-) Thanks *very* much for attending to the input issue. Much appreciated.
On Tue, Oct 27, 2020 at 10:46 AM Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
Ah too late, Eliot was faster, hit the pull request next time :)
Le mar. 27 oct. 2020 à 18:43, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com a écrit : Hi Yoshiki, what you could do is
- revert the changes to sqPlatformSpecific.h (fseek, ftell) since we have a working workaround now
- just create a pull request from the github web interface (that's rather easy)
It will be very easy for us to integrate (one click), and we'll keep your authorship.
Le mar. 27 oct. 2020 à 18:02, Yoshiki Ohshima Yoshiki.Ohshima@acm.org a écrit :
I have a branch on a clone on github:
https://github.com/yoshikiohshima/opensmalltalk-vm/tree/composition-input-fi...
It might be easier to pull from this? Separately, I'll mail you sqUnixX11.c.
On Tue, Oct 27, 2020 at 9:58 AM Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Yoshiki,
on my Mac patch isn't smart enough to decode a git diff. Can you just email me your platforms/unix/vm-display-X11/sqUnixX11.c and I'll integrate? Thanks!On Tue, Oct 27, 2020 at 8:21 AM Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
The previous one was just a hack but I think I found the real problem. It was about the variable symbolic, that gets symbolic key code *when* it is needed has to be zero'ed out when it is not needed.
The diff is attached... I'll a make pull request if that helps.
On Sat, Oct 24, 2020 at 5:32 PM Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote: For the /build.linuxARMv6/squeak.cog.spur/build.debug case, a hack I did was like this:
diff --git a/platforms/unix/vm/sqPlatformSpecific.h b/platforms/unix/vm/sqPlatformSpecific.h index 268593673..bfb57257b 100644 --- a/platforms/unix/vm/sqPlatformSpecific.h +++ b/platforms/unix/vm/sqPlatformSpecific.h @@ -105,8 +105,8 @@ extern void sqFilenameFromString(char *uxName, sqInt stNameIndex, int sqNameLeng #undef sqFTruncate /* sqFTruncate should return 0 on success, ftruncate does also */ #define sqFTruncate(f,o) ftruncate(fileno(f), o) -#define ftell(s) ftello(s) -#define fseek(s,o,w) fseeko(s,o,w) +// #define ftell(s) ftello(s) +// #define fseek(s,o,w) fseeko(s,o,w)
#if defined(__GNUC__) # if !defined(VM_LABEL) diff --git a/spur64src/vm/cogit.c b/spur64src/vm/cogit.c index d62b05f40..e1c14a021 100644 --- a/spur64src/vm/cogit.c +++ b/spur64src/vm/cogit.c @@ -6,6 +6,8 @@ # define SysV 1 #endif
+#define __arm64__
#if defined(__arm64__) || defined(__aarch64__) || defined(__ARM_ARCH_ISA_A64) || defined(ARM64) || defined(ARMv8)
and this produced a runnable VM on Raspberry Pi4
On Sat, Oct 24, 2020 at 4:41 PM Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote: And I tried a few more things by checking out the last release tag 202003021730 or try opensmalltalk-vm/build.linuxARMv6/squeak.cog.spur/build.debug but those attempts did not work. For the latter got this error:
In file included from /usr/include/features.h:424, from /usr/include/pthread.h:21, from /home/pi/opensmalltalk-vm/platforms/unix/vm/sqPlatformSpecific.h:62, from /home/pi/opensmalltalk-vm/platforms/Cross/vm/sqAssert.h:16, from /home/pi/opensmalltalk-vm/platforms/unix/vm/aio.c:35: /usr/include/stdio.h:721:12: error: conflicting types for ‘fseeko’ extern int __REDIRECT (fseeko, ^~~~~~~~~~ In file included from /home/pi/opensmalltalk-vm/platforms/Cross/vm/sqAssert.h:16, from /home/pi/opensmalltalk-vm/platforms/unix/vm/aio.c:35: /home/pi/opensmalltalk-vm/platforms/unix/vm/sqPlatformSpecific.h:109:22: note: previous declaration \ of ‘fseeko’ was here #define fseek(s,o,w) fseeko(s,o,w) ^~~~~~
On Sat, Oct 24, 2020 at 1:59 PM Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote: Hi Eliot,
For build.linux64ARMv8/squeak.cog.spur/build.debug, i get the following error. I think I followed the steps in the instructions, including running updateSCCSVersion and mvm. How can I fix it?
/home/pi/opensmalltalk-vm/spur64src/vm/cogit.c:22:3: error: #error As yet no Cogit implementation appears to exist for your platform. # error As yet no Cogit implementation appears to exist for your platform. ^~~~~ /home/pi/opensmalltalk-vm/spur64src/vm/cogit.c:23:3: error: #error Consider implementing it, starting by adding a subclass of CogAbstractInstruction. # error Consider implementing it, starting by adding a subclass of CogAbstractInstruction. ^~~~~ make[1]: *** [Makefile:207: cogit.o]
On Wed, Oct 21, 2020 at 10:21 AM Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Yoshiki,
On Wed, Oct 21, 2020 at 10:14 AM Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
Hi,
I heard that people got a new problem in inputting Japanese text into Scratch 1.4 running on Raspberry Pi OS after, or around the version 2020-08-20. I would like to take a look at it but it might involve recompiling and generating the VM with debugging info. Last time I looked into it was years and years ago and I need to basically make a fresh start.
Is the process of making NuSqeauk VM For Raspberry Pi up to date and straightforward? Can people point me to the right point to start?
Making a Cog VM for Raspberry pi is straight-forward. Clone opensmalltalk-vm. cd to build.linux64ARMv8, read the HowToBuild, cd to build.linux64ARMv8/squeak.cog.spur/build.debug, or build.linux64ARMv8/squeak.stack.spur/build.debug, then run ./mvm
_,,,^..^,,,_ best, Eliot
-- -- Yoshiki
-- -- Yoshiki
-- -- Yoshiki
-- -- Yoshiki
-- _,,,^..^,,,_ best, Eliot
-- -- Yoshiki
-- -- Yoshiki
-- _,,,^..^,,,_ best, Eliot
-- -- Yoshiki
-- -- Yoshiki
-- -- Yoshiki
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful Latin Phrases:- Cave ne ante ullas catapultas ambules = If I were you, I wouldn't walk in front of any catapults.
Hi Yoshiki,
On Wed, Oct 28, 2020 at 12:59 PM Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
As for linux64ARMv8, I had to hack like this (The below is somewhat inconsistent but you'll get an idea) to get it produce a VM:
It looks like an issue of missing compiler macros for the architecture. The hack to sqUnixHeartbeat.c is likely to be wrong... the asm code specified for __ARM_ARCHI_ISA_A64 does not compile.
diff --git a/platforms/Cross/vm/sqAtomicOps.h b/platforms/Cross/vm/sqAtomicOps.h index ff5d3fdd7..96abe3a22 100644 --- a/platforms/Cross/vm/sqAtomicOps.h +++ b/platforms/Cross/vm/sqAtomicOps.h @@ -203,7 +203,7 @@ AtomicGet(__int64 *target)
# else /* TARGET_OS_IS_IPHONE elif x86 variants etc */
-#if defined(__arm__) && (defined(__ARM_ARCH_6__) || defined(__ARM_ARCH_7A__)) +#if defined(__arm__) && (defined(__ARM_ARCH_6__) || defined(__ARM_ARCH_7A__)) || 1 /* tpr - this is code intended for the Raspberry Pi Raspbian OS
- We'll experimentally trust in our MMU to keep 64bit accesses atomic */
# define get64(variable) variable diff --git a/platforms/unix/vm/sqUnixHeartbeat.c b/platforms/unix/vm/sqUnixHeartbeat.c index e9e3545fa..a526b4515 100644 --- a/platforms/unix/vm/sqUnixHeartbeat.c +++ b/platforms/unix/vm/sqUnixHeartbeat.c @@ -183,7 +183,7 @@ ioHighResClock(void) : "rdx"); #elif defined(__ARM_ARCH_ISA_A64) || defined(__arm64__) || defined(__aarch64__) || defined(ARM64) __asm__ __volatile__ ("MRS X0, CNTVCT_EL0"); -#elif defined(__arm__) && (defined(__ARM_ARCH_6__) || defined(__ARM_ARCH_7A__)) +#elif defined(__arm__) && (defined(__ARM_ARCH_6__) || defined(__ARM_ARCH_7A__)) || 1 /* tpr - do nothing for now; needs input from eliot to decide further */ /* Tim, not sure I have input beyond: Is there a 64-bit clock on ARM? If so, access it here :-) diff --git a/spur64src/vm/cogit.c b/spur64src/vm/cogit.c index d62b05f40..110685ac4 100644 --- a/spur64src/vm/cogit.c +++ b/spur64src/vm/cogit.c @@ -6,6 +6,8 @@ # define SysV 1 #endif
+#define __arm64__ 1
#if defined(__arm64__) || defined(__aarch64__) || defined(__ARM_ARCH_ISA_A64) || defined(ARM64) || defined(ARMv8)
# include "cogitARMv8.c" diff --git a/src/plugins/SqueakFFIPrims/SqueakFFIPrims.c b/src/plugins/SqueakFFIPrims/SqueakFFIPrims.c index 2878f9529..a0e5e0596 100644 --- a/src/plugins/SqueakFFIPrims/SqueakFFIPrims.c +++ b/src/plugins/SqueakFFIPrims/SqueakFFIPrims.c @@ -7,7 +7,7 @@ # define ARM32FFIPlugin_exports SqueakFFIPrims_exports # include "ARM32FFIPlugin.c"
-#elif defined(__ARM_ARCH_ISA_A64) || defined(__aarch64__) || defined(__arm64__) || defined(ARM64) || defined(_M_ARM64) +#elif defined(__ARM_ARCH_ISA_A64) || defined(__aarch64__) || defined(__arm64__) || defined(ARM64) || defined(_M_ARM64) || 1
# define ARM64FFIPlugin_exports SqueakFFIPrims_exports # include "ARM64FFIPlugin.c"
If you do $ cc -dM -E - </dev/null what predefined identifying macros do you get for aarch64/armv8? Then I can add them to the set tested in cogit.c
On Wed, Oct 28, 2020 at 9:24 AM Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
Ok!
I did make a pull request but then merged it by myself. Next thing for me to try is to build linux64ARMv8.
On Wed, Oct 28, 2020 at 8:47 AM Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Yoshiki,
On Oct 28, 2020, at 8:34 AM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
Come to think of it, a better fix for a problem like this one:
KeySym symbolic; int keyCode= x2sqKey(&evt->xkey, &symbolic); int ucs4= xkeysym2ucs4(symbolic);
was (obviously) to change the first line to:
KeySym symbolic= 0;
rather than to try to store 0 into *symbolic on the callee side. (A professor of my college days once told us that "most bugs are related to uninitialized variables." I should've known better.)
I had exactly this bug in the win32 CameraPlugin the other day. And it didn’t surface until shutting down the plugin on exiting the system. C, what a love/hate relationship it engenders :-)
When I get around to it, I'll make another change and this time make a pull request.
Or if you’d like I could invite you to become a committer and then you could avoid the pull request.
On Tue, Oct 27, 2020 at 11:43 AM Eliot Miranda eliot.miranda@gmail.com wrote:
On Tue, Oct 27, 2020 at 11:14 AM Yoshiki Ohshima < Yoshiki.Ohshima@acm.org> wrote:
Thanks! Maybe I should not have sent a separate email to Eliot ^^;
Don't sweat it :-) Fixes gratefully received :-) Thanks *very* much for attending to the input issue. Much appreciated.
On Tue, Oct 27, 2020 at 10:46 AM Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
Ah too late, Eliot was faster, hit the pull request next time :)
Le mar. 27 oct. 2020 à 18:43, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> a écrit :
> Hi Yoshiki, > what you could do is > 1) revert the changes to sqPlatformSpecific.h (fseek, ftell) since > we have a working workaround now > 2) just create a pull request from the github web interface (that's > rather easy) > It will be very easy for us to integrate (one click), and we'll keep > your authorship. > > Le mar. 27 oct. 2020 à 18:02, Yoshiki Ohshima < > Yoshiki.Ohshima@acm.org> a écrit : > >> >> I have a branch on a clone on github: >> >> >> https://github.com/yoshikiohshima/opensmalltalk-vm/tree/composition-input-fi... >> >> It might be easier to pull from this? Separately, I'll mail you >> sqUnixX11.c. >> >> On Tue, Oct 27, 2020 at 9:58 AM Eliot Miranda < >> eliot.miranda@gmail.com> wrote: >> >>> >>> Hi Yoshiki, >>> >>> on my Mac patch isn't smart enough to decode a git diff. Can >>> you just email me your platforms/unix/vm-display-X11/sqUnixX11.c and I'll >>> integrate? Thanks! >>> >>> On Tue, Oct 27, 2020 at 8:21 AM Yoshiki Ohshima < >>> Yoshiki.Ohshima@acm.org> wrote: >>> >>>> >>>> The previous one was just a hack but I think I found the real >>>> problem. It was about the variable symbolic, that gets symbolic key code >>>> *when* it is needed has to be zero'ed out when it is not needed. >>>> >>>> The diff is attached... I'll a make pull request if that helps. >>>> >>>> On Sat, Oct 24, 2020 at 5:32 PM Yoshiki Ohshima < >>>> Yoshiki.Ohshima@acm.org> wrote: >>>> >>>>> For the /build.linuxARMv6/squeak.cog.spur/build.debug case, a >>>>> hack I did was like this: >>>>> >>>>> diff --git a/platforms/unix/vm/sqPlatformSpecific.h >>>>> b/platforms/unix/vm/sqPlatformSpecific.h >>>>> >>>>> index 268593673..bfb57257b 100644 >>>>> >>>>> --- a/platforms/unix/vm/sqPlatformSpecific.h >>>>> >>>>> +++ b/platforms/unix/vm/sqPlatformSpecific.h >>>>> >>>>> @@ -105,8 +105,8 @@ extern void sqFilenameFromString(char >>>>> *uxName, sqInt stNameIndex, int sqNameLeng >>>>> >>>>> #undef sqFTruncate >>>>> >>>>> /* sqFTruncate should return 0 on success, ftruncate does also >>>>> */ >>>>> >>>>> #define sqFTruncate(f,o) ftruncate(fileno(f), o) >>>>> >>>>> -#define ftell(s) ftello(s) >>>>> >>>>> -#define fseek(s,o,w) fseeko(s,o,w) >>>>> >>>>> +// #define ftell(s) ftello(s) >>>>> >>>>> +// #define fseek(s,o,w) fseeko(s,o,w) >>>>> >>>>> >>>>> #if defined(__GNUC__) >>>>> >>>>> # if !defined(VM_LABEL) >>>>> >>>>> diff --git a/spur64src/vm/cogit.c b/spur64src/vm/cogit.c >>>>> >>>>> index d62b05f40..e1c14a021 100644 >>>>> >>>>> --- a/spur64src/vm/cogit.c >>>>> >>>>> +++ b/spur64src/vm/cogit.c >>>>> >>>>> @@ -6,6 +6,8 @@ >>>>> >>>>> # define SysV 1 >>>>> >>>>> #endif >>>>> >>>>> >>>>> +#define __arm64__ >>>>> >>>>> + >>>>> >>>>> #if defined(__arm64__) || defined(__aarch64__) || >>>>> defined(__ARM_ARCH_ISA_A64) || defined(ARM64) || defined(ARMv8) >>>>> >>>>> >>>>> and this produced a runnable VM on Raspberry Pi4 >>>>> >>>>> On Sat, Oct 24, 2020 at 4:41 PM Yoshiki Ohshima < >>>>> Yoshiki.Ohshima@acm.org> wrote: >>>>> >>>>>> And I tried a few more things by checking out the last release >>>>>> tag 202003021730 or try opensmalltalk-vm/build. >>>>>> linuxARMv6/squeak.cog.spur/build.debug but those attempts did >>>>>> not work. For the latter got this error: >>>>>> >>>>>> In file included from /usr/include/features.h:424, >>>>>> >>>>>> from /usr/include/pthread.h:21, >>>>>> >>>>>> from >>>>>> /home/pi/opensmalltalk-vm/platforms/unix/vm/sqPlatformSpecific.h:62, >>>>>> >>>>>> from >>>>>> /home/pi/opensmalltalk-vm/platforms/Cross/vm/sqAssert.h:16, >>>>>> >>>>>> from >>>>>> /home/pi/opensmalltalk-vm/platforms/unix/vm/aio.c:35: >>>>>> >>>>>> /usr/include/stdio.h:721:12: error: conflicting types for >>>>>> ‘fseeko’ >>>>>> >>>>>> extern int __REDIRECT (fseeko, >>>>>> >>>>>> ^~~~~~~~~~ >>>>>> >>>>>> In file included from >>>>>> /home/pi/opensmalltalk-vm/platforms/Cross/vm/sqAssert.h:16, >>>>>> >>>>>> from >>>>>> /home/pi/opensmalltalk-vm/platforms/unix/vm/aio.c:35: >>>>>> >>>>>> /home/pi/opensmalltalk-vm/platforms/unix/vm/sqPlatformSpecific.h:109:22: >>>>>> note: previous declaration \ >>>>>> >>>>>> of ‘fseeko’ was here >>>>>> >>>>>> #define fseek(s,o,w) fseeko(s,o,w) >>>>>> >>>>>> ^~~~~~ >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Sat, Oct 24, 2020 at 1:59 PM Yoshiki Ohshima < >>>>>> Yoshiki.Ohshima@acm.org> wrote: >>>>>> >>>>>>> Hi Eliot, >>>>>>> >>>>>>> For build.linux64ARMv8/squeak.cog.spur/build.debug, i get the >>>>>>> following error. I think I followed the steps in the instructions, >>>>>>> including running updateSCCSVersion and mvm. How can I fix it? >>>>>>> >>>>>>> /home/pi/opensmalltalk-vm/spur64src/vm/cogit.c:22:3: error: >>>>>>> #error As yet no Cogit implementation appears to exist for your platform. >>>>>>> >>>>>>> # error As yet no Cogit implementation appears to exist for >>>>>>> your platform. >>>>>>> >>>>>>> ^~~~~ >>>>>>> >>>>>>> /home/pi/opensmalltalk-vm/spur64src/vm/cogit.c:23:3: error: >>>>>>> #error Consider implementing it, starting by adding a subclass of >>>>>>> CogAbstractInstruction. >>>>>>> >>>>>>> # error Consider implementing it, starting by adding a >>>>>>> subclass of CogAbstractInstruction. >>>>>>> >>>>>>> ^~~~~ >>>>>>> >>>>>>> make[1]: *** [Makefile:207: cogit.o] >>>>>>> >>>>>>> On Wed, Oct 21, 2020 at 10:21 AM Eliot Miranda < >>>>>>> eliot.miranda@gmail.com> wrote: >>>>>>> >>>>>>>> >>>>>>>> Hi Yoshiki, >>>>>>>> >>>>>>>> On Wed, Oct 21, 2020 at 10:14 AM Yoshiki Ohshima < >>>>>>>> Yoshiki.Ohshima@acm.org> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I heard that people got a new problem in inputting Japanese >>>>>>>>> text into Scratch 1.4 running on Raspberry Pi OS after, or around the >>>>>>>>> version 2020-08-20. I would like to take a look at it but it might involve >>>>>>>>> recompiling and generating the VM with debugging info. Last time I looked >>>>>>>>> into it was years and years ago and I need to basically make a fresh start. >>>>>>>>> >>>>>>>>> Is the process of making NuSqeauk VM For Raspberry Pi up to >>>>>>>>> date and straightforward? Can people point me to the right point to start? >>>>>>>>> >>>>>>>> >>>>>>>> Making a Cog VM for Raspberry pi is straight-forward. Clone >>>>>>>> opensmalltalk-vm. cd to build.linux64ARMv8, read the HowToBuild, cd to build.linux64ARMv8/squeak.cog.spur/build.debug, >>>>>>>> or build.linux64ARMv8/squeak.stack.spur/build.debug, then >>>>>>>> run ./mvm >>>>>>>> >>>>>>>> _,,,^..^,,,_ >>>>>>>> best, Eliot >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> -- Yoshiki >>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> -- Yoshiki >>>>>> >>>>>> >>>>> >>>>> -- >>>>> -- Yoshiki >>>>> >>>>> >>>> >>>> -- >>>> -- Yoshiki >>>> >>>> >>> >>> -- >>> _,,,^..^,,,_ >>> best, Eliot >>> >> >> >> -- >> -- Yoshiki >> >>
-- -- Yoshiki
-- _,,,^..^,,,_ best, Eliot
-- -- Yoshiki
-- -- Yoshiki
-- -- Yoshiki
I may be simply on a wrong OS. The main reason for me to dive in again was to fix it for Raspberry Pi OS users:
https://www.raspberrypi.org/downloads/raspberry-pi-os/
but then it simply is not a 64bit OS I gather. It's just the compiler on targets 32 bit. Sorry for a confusion. The following is the results from
cc -dM -E - </dev/null | grep ARM #define __ARM_SIZEOF_WCHAR_T 4 #define __ARM_FEATURE_SAT 1 #define __ARM_ARCH_ISA_ARM 1 #define __ARMEL__ 1 #define __ARM_FEATURE_UNALIGNED 1 #define __ARM_FP 12 #define __ARM_SIZEOF_MINIMAL_ENUM 4 #define __ARM_PCS_VFP 1 #define __ARM_FEATURE_LDREX 4 #define __ARM_FEATURE_QBIT 1 #define __ARM_ARCH_6__ 1 #define __ARM_32BIT_STATE 1 #define __ARM_FEATURE_CLZ 1 #define __ARM_ARCH_ISA_THUMB 1 #define __ARM_ARCH 6 #define __ARM_FEATURE_SIMD32 1 #define __ARM_FEATURE_COPROC 15 #define __ARM_EABI__ 1 #define __ARM_FEATURE_DSP 1
On Wed, Oct 28, 2020 at 3:58 PM Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Yoshiki,
On Wed, Oct 28, 2020 at 12:59 PM Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
As for linux64ARMv8, I had to hack like this (The below is somewhat inconsistent but you'll get an idea) to get it produce a VM:
It looks like an issue of missing compiler macros for the architecture. The hack to sqUnixHeartbeat.c is likely to be wrong... the asm code specified for __ARM_ARCHI_ISA_A64 does not compile.
diff --git a/platforms/Cross/vm/sqAtomicOps.h b/platforms/Cross/vm/sqAtomicOps.h index ff5d3fdd7..96abe3a22 100644 --- a/platforms/Cross/vm/sqAtomicOps.h +++ b/platforms/Cross/vm/sqAtomicOps.h @@ -203,7 +203,7 @@ AtomicGet(__int64 *target)
# else /* TARGET_OS_IS_IPHONE elif x86 variants etc */
-#if defined(__arm__) && (defined(__ARM_ARCH_6__) || defined(__ARM_ARCH_7A__)) +#if defined(__arm__) && (defined(__ARM_ARCH_6__) || defined(__ARM_ARCH_7A__)) || 1 /* tpr - this is code intended for the Raspberry Pi Raspbian OS
- We'll experimentally trust in our MMU to keep 64bit accesses atomic */
# define get64(variable) variable diff --git a/platforms/unix/vm/sqUnixHeartbeat.c b/platforms/unix/vm/sqUnixHeartbeat.c index e9e3545fa..a526b4515 100644 --- a/platforms/unix/vm/sqUnixHeartbeat.c +++ b/platforms/unix/vm/sqUnixHeartbeat.c @@ -183,7 +183,7 @@ ioHighResClock(void) : "rdx"); #elif defined(__ARM_ARCH_ISA_A64) || defined(__arm64__) || defined(__aarch64__) || defined(ARM64) __asm__ __volatile__ ("MRS X0, CNTVCT_EL0"); -#elif defined(__arm__) && (defined(__ARM_ARCH_6__) || defined(__ARM_ARCH_7A__)) +#elif defined(__arm__) && (defined(__ARM_ARCH_6__) || defined(__ARM_ARCH_7A__)) || 1 /* tpr - do nothing for now; needs input from eliot to decide further */ /* Tim, not sure I have input beyond: Is there a 64-bit clock on ARM? If so, access it here :-) diff --git a/spur64src/vm/cogit.c b/spur64src/vm/cogit.c index d62b05f40..110685ac4 100644 --- a/spur64src/vm/cogit.c +++ b/spur64src/vm/cogit.c @@ -6,6 +6,8 @@ # define SysV 1 #endif
+#define __arm64__ 1
#if defined(__arm64__) || defined(__aarch64__) || defined(__ARM_ARCH_ISA_A64) || defined(ARM64) || defined(ARMv8)
# include "cogitARMv8.c" diff --git a/src/plugins/SqueakFFIPrims/SqueakFFIPrims.c b/src/plugins/SqueakFFIPrims/SqueakFFIPrims.c index 2878f9529..a0e5e0596 100644 --- a/src/plugins/SqueakFFIPrims/SqueakFFIPrims.c +++ b/src/plugins/SqueakFFIPrims/SqueakFFIPrims.c @@ -7,7 +7,7 @@ # define ARM32FFIPlugin_exports SqueakFFIPrims_exports # include "ARM32FFIPlugin.c"
-#elif defined(__ARM_ARCH_ISA_A64) || defined(__aarch64__) || defined(__arm64__) || defined(ARM64) || defined(_M_ARM64) +#elif defined(__ARM_ARCH_ISA_A64) || defined(__aarch64__) || defined(__arm64__) || defined(ARM64) || defined(_M_ARM64) || 1
# define ARM64FFIPlugin_exports SqueakFFIPrims_exports # include "ARM64FFIPlugin.c"
If you do $ cc -dM -E - </dev/null what predefined identifying macros do you get for aarch64/armv8? Then I can add them to the set tested in cogit.c
On Wed, Oct 28, 2020 at 9:24 AM Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
Ok!
I did make a pull request but then merged it by myself. Next thing for me to try is to build linux64ARMv8.
On Wed, Oct 28, 2020 at 8:47 AM Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Yoshiki,
On Oct 28, 2020, at 8:34 AM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
Come to think of it, a better fix for a problem like this one:
KeySym symbolic; int keyCode= x2sqKey(&evt->xkey, &symbolic); int ucs4= xkeysym2ucs4(symbolic);
was (obviously) to change the first line to:
KeySym symbolic= 0;
rather than to try to store 0 into *symbolic on the callee side. (A professor of my college days once told us that "most bugs are related to uninitialized variables." I should've known better.)
I had exactly this bug in the win32 CameraPlugin the other day. And it didn’t surface until shutting down the plugin on exiting the system. C, what a love/hate relationship it engenders :-)
When I get around to it, I'll make another change and this time make a pull request.
Or if you’d like I could invite you to become a committer and then you could avoid the pull request.
On Tue, Oct 27, 2020 at 11:43 AM Eliot Miranda eliot.miranda@gmail.com wrote:
On Tue, Oct 27, 2020 at 11:14 AM Yoshiki Ohshima < Yoshiki.Ohshima@acm.org> wrote:
Thanks! Maybe I should not have sent a separate email to Eliot ^^;
Don't sweat it :-) Fixes gratefully received :-) Thanks *very* much for attending to the input issue. Much appreciated.
On Tue, Oct 27, 2020 at 10:46 AM Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
> > Ah too late, Eliot was faster, hit the pull request next time :) > > Le mar. 27 oct. 2020 à 18:43, Nicolas Cellier < > nicolas.cellier.aka.nice@gmail.com> a écrit : > >> Hi Yoshiki, >> what you could do is >> 1) revert the changes to sqPlatformSpecific.h (fseek, ftell) since >> we have a working workaround now >> 2) just create a pull request from the github web interface (that's >> rather easy) >> It will be very easy for us to integrate (one click), and we'll >> keep your authorship. >> >> Le mar. 27 oct. 2020 à 18:02, Yoshiki Ohshima < >> Yoshiki.Ohshima@acm.org> a écrit : >> >>> >>> I have a branch on a clone on github: >>> >>> >>> https://github.com/yoshikiohshima/opensmalltalk-vm/tree/composition-input-fi... >>> >>> It might be easier to pull from this? Separately, I'll mail you >>> sqUnixX11.c. >>> >>> On Tue, Oct 27, 2020 at 9:58 AM Eliot Miranda < >>> eliot.miranda@gmail.com> wrote: >>> >>>> >>>> Hi Yoshiki, >>>> >>>> on my Mac patch isn't smart enough to decode a git diff. Can >>>> you just email me your platforms/unix/vm-display-X11/sqUnixX11.c and I'll >>>> integrate? Thanks! >>>> >>>> On Tue, Oct 27, 2020 at 8:21 AM Yoshiki Ohshima < >>>> Yoshiki.Ohshima@acm.org> wrote: >>>> >>>>> >>>>> The previous one was just a hack but I think I found the real >>>>> problem. It was about the variable symbolic, that gets symbolic key code >>>>> *when* it is needed has to be zero'ed out when it is not needed. >>>>> >>>>> The diff is attached... I'll a make pull request if that helps. >>>>> >>>>> On Sat, Oct 24, 2020 at 5:32 PM Yoshiki Ohshima < >>>>> Yoshiki.Ohshima@acm.org> wrote: >>>>> >>>>>> For the /build.linuxARMv6/squeak.cog.spur/build.debug case, a >>>>>> hack I did was like this: >>>>>> >>>>>> diff --git a/platforms/unix/vm/sqPlatformSpecific.h >>>>>> b/platforms/unix/vm/sqPlatformSpecific.h >>>>>> >>>>>> index 268593673..bfb57257b 100644 >>>>>> >>>>>> --- a/platforms/unix/vm/sqPlatformSpecific.h >>>>>> >>>>>> +++ b/platforms/unix/vm/sqPlatformSpecific.h >>>>>> >>>>>> @@ -105,8 +105,8 @@ extern void sqFilenameFromString(char >>>>>> *uxName, sqInt stNameIndex, int sqNameLeng >>>>>> >>>>>> #undef sqFTruncate >>>>>> >>>>>> /* sqFTruncate should return 0 on success, ftruncate does >>>>>> also */ >>>>>> >>>>>> #define sqFTruncate(f,o) ftruncate(fileno(f), o) >>>>>> >>>>>> -#define ftell(s) ftello(s) >>>>>> >>>>>> -#define fseek(s,o,w) fseeko(s,o,w) >>>>>> >>>>>> +// #define ftell(s) ftello(s) >>>>>> >>>>>> +// #define fseek(s,o,w) fseeko(s,o,w) >>>>>> >>>>>> >>>>>> #if defined(__GNUC__) >>>>>> >>>>>> # if !defined(VM_LABEL) >>>>>> >>>>>> diff --git a/spur64src/vm/cogit.c b/spur64src/vm/cogit.c >>>>>> >>>>>> index d62b05f40..e1c14a021 100644 >>>>>> >>>>>> --- a/spur64src/vm/cogit.c >>>>>> >>>>>> +++ b/spur64src/vm/cogit.c >>>>>> >>>>>> @@ -6,6 +6,8 @@ >>>>>> >>>>>> # define SysV 1 >>>>>> >>>>>> #endif >>>>>> >>>>>> >>>>>> +#define __arm64__ >>>>>> >>>>>> + >>>>>> >>>>>> #if defined(__arm64__) || defined(__aarch64__) || >>>>>> defined(__ARM_ARCH_ISA_A64) || defined(ARM64) || defined(ARMv8) >>>>>> >>>>>> >>>>>> and this produced a runnable VM on Raspberry Pi4 >>>>>> >>>>>> On Sat, Oct 24, 2020 at 4:41 PM Yoshiki Ohshima < >>>>>> Yoshiki.Ohshima@acm.org> wrote: >>>>>> >>>>>>> And I tried a few more things by checking out the last release >>>>>>> tag 202003021730 or try opensmalltalk-vm/build. >>>>>>> linuxARMv6/squeak.cog.spur/build.debug but those attempts did >>>>>>> not work. For the latter got this error: >>>>>>> >>>>>>> In file included from /usr/include/features.h:424, >>>>>>> >>>>>>> from /usr/include/pthread.h:21, >>>>>>> >>>>>>> from >>>>>>> /home/pi/opensmalltalk-vm/platforms/unix/vm/sqPlatformSpecific.h:62, >>>>>>> >>>>>>> from >>>>>>> /home/pi/opensmalltalk-vm/platforms/Cross/vm/sqAssert.h:16, >>>>>>> >>>>>>> from >>>>>>> /home/pi/opensmalltalk-vm/platforms/unix/vm/aio.c:35: >>>>>>> >>>>>>> /usr/include/stdio.h:721:12: error: conflicting types for >>>>>>> ‘fseeko’ >>>>>>> >>>>>>> extern int __REDIRECT (fseeko, >>>>>>> >>>>>>> ^~~~~~~~~~ >>>>>>> >>>>>>> In file included from >>>>>>> /home/pi/opensmalltalk-vm/platforms/Cross/vm/sqAssert.h:16, >>>>>>> >>>>>>> from >>>>>>> /home/pi/opensmalltalk-vm/platforms/unix/vm/aio.c:35: >>>>>>> >>>>>>> /home/pi/opensmalltalk-vm/platforms/unix/vm/sqPlatformSpecific.h:109:22: >>>>>>> note: previous declaration \ >>>>>>> >>>>>>> of ‘fseeko’ was here >>>>>>> >>>>>>> #define fseek(s,o,w) fseeko(s,o,w) >>>>>>> >>>>>>> ^~~~~~ >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Sat, Oct 24, 2020 at 1:59 PM Yoshiki Ohshima < >>>>>>> Yoshiki.Ohshima@acm.org> wrote: >>>>>>> >>>>>>>> Hi Eliot, >>>>>>>> >>>>>>>> For build.linux64ARMv8/squeak.cog.spur/build.debug, i get >>>>>>>> the following error. I think I followed the steps in the instructions, >>>>>>>> including running updateSCCSVersion and mvm. How can I fix it? >>>>>>>> >>>>>>>> /home/pi/opensmalltalk-vm/spur64src/vm/cogit.c:22:3: error: >>>>>>>> #error As yet no Cogit implementation appears to exist for your platform. >>>>>>>> >>>>>>>> # error As yet no Cogit implementation appears to exist for >>>>>>>> your platform. >>>>>>>> >>>>>>>> ^~~~~ >>>>>>>> >>>>>>>> /home/pi/opensmalltalk-vm/spur64src/vm/cogit.c:23:3: error: >>>>>>>> #error Consider implementing it, starting by adding a subclass of >>>>>>>> CogAbstractInstruction. >>>>>>>> >>>>>>>> # error Consider implementing it, starting by adding a >>>>>>>> subclass of CogAbstractInstruction. >>>>>>>> >>>>>>>> ^~~~~ >>>>>>>> >>>>>>>> make[1]: *** [Makefile:207: cogit.o] >>>>>>>> >>>>>>>> On Wed, Oct 21, 2020 at 10:21 AM Eliot Miranda < >>>>>>>> eliot.miranda@gmail.com> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> Hi Yoshiki, >>>>>>>>> >>>>>>>>> On Wed, Oct 21, 2020 at 10:14 AM Yoshiki Ohshima < >>>>>>>>> Yoshiki.Ohshima@acm.org> wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> I heard that people got a new problem in inputting Japanese >>>>>>>>>> text into Scratch 1.4 running on Raspberry Pi OS after, or around the >>>>>>>>>> version 2020-08-20. I would like to take a look at it but it might involve >>>>>>>>>> recompiling and generating the VM with debugging info. Last time I looked >>>>>>>>>> into it was years and years ago and I need to basically make a fresh start. >>>>>>>>>> >>>>>>>>>> Is the process of making NuSqeauk VM For Raspberry Pi up to >>>>>>>>>> date and straightforward? Can people point me to the right point to start? >>>>>>>>>> >>>>>>>>> >>>>>>>>> Making a Cog VM for Raspberry pi is straight-forward. Clone >>>>>>>>> opensmalltalk-vm. cd to build.linux64ARMv8, read the HowToBuild, cd to build.linux64ARMv8/squeak.cog.spur/build.debug, >>>>>>>>> or build.linux64ARMv8/squeak.stack.spur/build.debug, then >>>>>>>>> run ./mvm >>>>>>>>> >>>>>>>>> _,,,^..^,,,_ >>>>>>>>> best, Eliot >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> -- Yoshiki >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> -- Yoshiki >>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> -- Yoshiki >>>>>> >>>>>> >>>>> >>>>> -- >>>>> -- Yoshiki >>>>> >>>>> >>>> >>>> -- >>>> _,,,^..^,,,_ >>>> best, Eliot >>>> >>> >>> >>> -- >>> -- Yoshiki >>> >>>
-- -- Yoshiki
-- _,,,^..^,,,_ best, Eliot
-- -- Yoshiki
-- -- Yoshiki
-- -- Yoshiki
-- _,,,^..^,,,_ best, Eliot
On Wed, Oct 28, 2020 at 4:06 PM Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
I may be simply on a wrong OS. The main reason for me to dive in again was to fix it for Raspberry Pi OS users:
https://www.raspberrypi.org/downloads/raspberry-pi-os/
but then it simply is not a 64bit OS I gather. It's just the compiler on targets 32 bit. Sorry for a confusion. The following is the results from
cc -dM -E - </dev/null | grep ARM
Forgive me pushing, but can you also send the result of cc -dM -E - </dev/null | grep -i arm ? And the 64-bit ones are *way* faster and cheap...
Tim, what do you get for the same on raspbian?
#define __ARM_SIZEOF_WCHAR_T 4 #define __ARM_FEATURE_SAT 1 #define __ARM_ARCH_ISA_ARM 1 #define __ARMEL__ 1 #define __ARM_FEATURE_UNALIGNED 1 #define __ARM_FP 12 #define __ARM_SIZEOF_MINIMAL_ENUM 4 #define __ARM_PCS_VFP 1 #define __ARM_FEATURE_LDREX 4 #define __ARM_FEATURE_QBIT 1 #define __ARM_ARCH_6__ 1 #define __ARM_32BIT_STATE 1 #define __ARM_FEATURE_CLZ 1 #define __ARM_ARCH_ISA_THUMB 1 #define __ARM_ARCH 6 #define __ARM_FEATURE_SIMD32 1 #define __ARM_FEATURE_COPROC 15 #define __ARM_EABI__ 1 #define __ARM_FEATURE_DSP 1
On Wed, Oct 28, 2020 at 3:58 PM Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Yoshiki,
On Wed, Oct 28, 2020 at 12:59 PM Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
As for linux64ARMv8, I had to hack like this (The below is somewhat inconsistent but you'll get an idea) to get it produce a VM:
It looks like an issue of missing compiler macros for the architecture. The hack to sqUnixHeartbeat.c is likely to be wrong... the asm code specified for __ARM_ARCHI_ISA_A64 does not compile.
diff --git a/platforms/Cross/vm/sqAtomicOps.h b/platforms/Cross/vm/sqAtomicOps.h index ff5d3fdd7..96abe3a22 100644 --- a/platforms/Cross/vm/sqAtomicOps.h +++ b/platforms/Cross/vm/sqAtomicOps.h @@ -203,7 +203,7 @@ AtomicGet(__int64 *target)
# else /* TARGET_OS_IS_IPHONE elif x86 variants etc */
-#if defined(__arm__) && (defined(__ARM_ARCH_6__) || defined(__ARM_ARCH_7A__)) +#if defined(__arm__) && (defined(__ARM_ARCH_6__) || defined(__ARM_ARCH_7A__)) || 1 /* tpr - this is code intended for the Raspberry Pi Raspbian OS
- We'll experimentally trust in our MMU to keep 64bit accesses atomic
*/ # define get64(variable) variable diff --git a/platforms/unix/vm/sqUnixHeartbeat.c b/platforms/unix/vm/sqUnixHeartbeat.c index e9e3545fa..a526b4515 100644 --- a/platforms/unix/vm/sqUnixHeartbeat.c +++ b/platforms/unix/vm/sqUnixHeartbeat.c @@ -183,7 +183,7 @@ ioHighResClock(void) : "rdx"); #elif defined(__ARM_ARCH_ISA_A64) || defined(__arm64__) || defined(__aarch64__) || defined(ARM64) __asm__ __volatile__ ("MRS X0, CNTVCT_EL0"); -#elif defined(__arm__) && (defined(__ARM_ARCH_6__) || defined(__ARM_ARCH_7A__)) +#elif defined(__arm__) && (defined(__ARM_ARCH_6__) || defined(__ARM_ARCH_7A__)) || 1 /* tpr - do nothing for now; needs input from eliot to decide further */ /* Tim, not sure I have input beyond: Is there a 64-bit clock on ARM? If so, access it here :-) diff --git a/spur64src/vm/cogit.c b/spur64src/vm/cogit.c index d62b05f40..110685ac4 100644 --- a/spur64src/vm/cogit.c +++ b/spur64src/vm/cogit.c @@ -6,6 +6,8 @@ # define SysV 1 #endif
+#define __arm64__ 1
#if defined(__arm64__) || defined(__aarch64__) || defined(__ARM_ARCH_ISA_A64) || defined(ARM64) || defined(ARMv8)
# include "cogitARMv8.c" diff --git a/src/plugins/SqueakFFIPrims/SqueakFFIPrims.c b/src/plugins/SqueakFFIPrims/SqueakFFIPrims.c index 2878f9529..a0e5e0596 100644 --- a/src/plugins/SqueakFFIPrims/SqueakFFIPrims.c +++ b/src/plugins/SqueakFFIPrims/SqueakFFIPrims.c @@ -7,7 +7,7 @@ # define ARM32FFIPlugin_exports SqueakFFIPrims_exports # include "ARM32FFIPlugin.c"
-#elif defined(__ARM_ARCH_ISA_A64) || defined(__aarch64__) || defined(__arm64__) || defined(ARM64) || defined(_M_ARM64) +#elif defined(__ARM_ARCH_ISA_A64) || defined(__aarch64__) || defined(__arm64__) || defined(ARM64) || defined(_M_ARM64) || 1
# define ARM64FFIPlugin_exports SqueakFFIPrims_exports # include "ARM64FFIPlugin.c"
If you do $ cc -dM -E - </dev/null what predefined identifying macros do you get for aarch64/armv8? Then I can add them to the set tested in cogit.c
On Wed, Oct 28, 2020 at 9:24 AM Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
Ok!
I did make a pull request but then merged it by myself. Next thing for me to try is to build linux64ARMv8.
On Wed, Oct 28, 2020 at 8:47 AM Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Yoshiki,
On Oct 28, 2020, at 8:34 AM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
Come to think of it, a better fix for a problem like this one:
KeySym symbolic; int keyCode= x2sqKey(&evt->xkey, &symbolic); int ucs4= xkeysym2ucs4(symbolic);
was (obviously) to change the first line to:
KeySym symbolic= 0;
rather than to try to store 0 into *symbolic on the callee side. (A professor of my college days once told us that "most bugs are related to uninitialized variables." I should've known better.)
I had exactly this bug in the win32 CameraPlugin the other day. And it didn’t surface until shutting down the plugin on exiting the system. C, what a love/hate relationship it engenders :-)
When I get around to it, I'll make another change and this time make a pull request.
Or if you’d like I could invite you to become a committer and then you could avoid the pull request.
On Tue, Oct 27, 2020 at 11:43 AM Eliot Miranda < eliot.miranda@gmail.com> wrote:
On Tue, Oct 27, 2020 at 11:14 AM Yoshiki Ohshima < Yoshiki.Ohshima@acm.org> wrote:
> > Thanks! Maybe I should not have sent a separate email to Eliot ^^; >
Don't sweat it :-) Fixes gratefully received :-) Thanks *very* much for attending to the input issue. Much appreciated.
> > On Tue, Oct 27, 2020 at 10:46 AM Nicolas Cellier < > nicolas.cellier.aka.nice@gmail.com> wrote: > >> >> Ah too late, Eliot was faster, hit the pull request next time :) >> >> Le mar. 27 oct. 2020 à 18:43, Nicolas Cellier < >> nicolas.cellier.aka.nice@gmail.com> a écrit : >> >>> Hi Yoshiki, >>> what you could do is >>> 1) revert the changes to sqPlatformSpecific.h (fseek, ftell) since >>> we have a working workaround now >>> 2) just create a pull request from the github web interface >>> (that's rather easy) >>> It will be very easy for us to integrate (one click), and we'll >>> keep your authorship. >>> >>> Le mar. 27 oct. 2020 à 18:02, Yoshiki Ohshima < >>> Yoshiki.Ohshima@acm.org> a écrit : >>> >>>> >>>> I have a branch on a clone on github: >>>> >>>> >>>> https://github.com/yoshikiohshima/opensmalltalk-vm/tree/composition-input-fi... >>>> >>>> It might be easier to pull from this? Separately, I'll mail you >>>> sqUnixX11.c. >>>> >>>> On Tue, Oct 27, 2020 at 9:58 AM Eliot Miranda < >>>> eliot.miranda@gmail.com> wrote: >>>> >>>>> >>>>> Hi Yoshiki, >>>>> >>>>> on my Mac patch isn't smart enough to decode a git diff. >>>>> Can you just email me your platforms/unix/vm-display-X11/sqUnixX11.c and >>>>> I'll integrate? Thanks! >>>>> >>>>> On Tue, Oct 27, 2020 at 8:21 AM Yoshiki Ohshima < >>>>> Yoshiki.Ohshima@acm.org> wrote: >>>>> >>>>>> >>>>>> The previous one was just a hack but I think I found the real >>>>>> problem. It was about the variable symbolic, that gets symbolic key code >>>>>> *when* it is needed has to be zero'ed out when it is not needed. >>>>>> >>>>>> The diff is attached... I'll a make pull request if that helps. >>>>>> >>>>>> On Sat, Oct 24, 2020 at 5:32 PM Yoshiki Ohshima < >>>>>> Yoshiki.Ohshima@acm.org> wrote: >>>>>> >>>>>>> For the /build.linuxARMv6/squeak.cog.spur/build.debug case, >>>>>>> a hack I did was like this: >>>>>>> >>>>>>> diff --git a/platforms/unix/vm/sqPlatformSpecific.h >>>>>>> b/platforms/unix/vm/sqPlatformSpecific.h >>>>>>> >>>>>>> index 268593673..bfb57257b 100644 >>>>>>> >>>>>>> --- a/platforms/unix/vm/sqPlatformSpecific.h >>>>>>> >>>>>>> +++ b/platforms/unix/vm/sqPlatformSpecific.h >>>>>>> >>>>>>> @@ -105,8 +105,8 @@ extern void sqFilenameFromString(char >>>>>>> *uxName, sqInt stNameIndex, int sqNameLeng >>>>>>> >>>>>>> #undef sqFTruncate >>>>>>> >>>>>>> /* sqFTruncate should return 0 on success, ftruncate does >>>>>>> also */ >>>>>>> >>>>>>> #define sqFTruncate(f,o) ftruncate(fileno(f), o) >>>>>>> >>>>>>> -#define ftell(s) ftello(s) >>>>>>> >>>>>>> -#define fseek(s,o,w) fseeko(s,o,w) >>>>>>> >>>>>>> +// #define ftell(s) ftello(s) >>>>>>> >>>>>>> +// #define fseek(s,o,w) fseeko(s,o,w) >>>>>>> >>>>>>> >>>>>>> #if defined(__GNUC__) >>>>>>> >>>>>>> # if !defined(VM_LABEL) >>>>>>> >>>>>>> diff --git a/spur64src/vm/cogit.c b/spur64src/vm/cogit.c >>>>>>> >>>>>>> index d62b05f40..e1c14a021 100644 >>>>>>> >>>>>>> --- a/spur64src/vm/cogit.c >>>>>>> >>>>>>> +++ b/spur64src/vm/cogit.c >>>>>>> >>>>>>> @@ -6,6 +6,8 @@ >>>>>>> >>>>>>> # define SysV 1 >>>>>>> >>>>>>> #endif >>>>>>> >>>>>>> >>>>>>> +#define __arm64__ >>>>>>> >>>>>>> + >>>>>>> >>>>>>> #if defined(__arm64__) || defined(__aarch64__) || >>>>>>> defined(__ARM_ARCH_ISA_A64) || defined(ARM64) || >>>>>>> defined(ARMv8) >>>>>>> >>>>>>> >>>>>>> and this produced a runnable VM on Raspberry Pi4 >>>>>>> >>>>>>> On Sat, Oct 24, 2020 at 4:41 PM Yoshiki Ohshima < >>>>>>> Yoshiki.Ohshima@acm.org> wrote: >>>>>>> >>>>>>>> And I tried a few more things by checking out the last >>>>>>>> release tag 202003021730 or try opensmalltalk-vm/build. >>>>>>>> linuxARMv6/squeak.cog.spur/build.debug but those attempts >>>>>>>> did not work. For the latter got this error: >>>>>>>> >>>>>>>> In file included from /usr/include/features.h:424, >>>>>>>> >>>>>>>> from /usr/include/pthread.h:21, >>>>>>>> >>>>>>>> from >>>>>>>> /home/pi/opensmalltalk-vm/platforms/unix/vm/sqPlatformSpecific.h:62, >>>>>>>> >>>>>>>> from >>>>>>>> /home/pi/opensmalltalk-vm/platforms/Cross/vm/sqAssert.h:16, >>>>>>>> >>>>>>>> from >>>>>>>> /home/pi/opensmalltalk-vm/platforms/unix/vm/aio.c:35: >>>>>>>> >>>>>>>> /usr/include/stdio.h:721:12: error: conflicting types for >>>>>>>> ‘fseeko’ >>>>>>>> >>>>>>>> extern int __REDIRECT (fseeko, >>>>>>>> >>>>>>>> ^~~~~~~~~~ >>>>>>>> >>>>>>>> In file included from >>>>>>>> /home/pi/opensmalltalk-vm/platforms/Cross/vm/sqAssert.h:16, >>>>>>>> >>>>>>>> from >>>>>>>> /home/pi/opensmalltalk-vm/platforms/unix/vm/aio.c:35: >>>>>>>> >>>>>>>> /home/pi/opensmalltalk-vm/platforms/unix/vm/sqPlatformSpecific.h:109:22: >>>>>>>> note: previous declaration \ >>>>>>>> >>>>>>>> of ‘fseeko’ was here >>>>>>>> >>>>>>>> #define fseek(s,o,w) fseeko(s,o,w) >>>>>>>> >>>>>>>> ^~~~~~ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Sat, Oct 24, 2020 at 1:59 PM Yoshiki Ohshima < >>>>>>>> Yoshiki.Ohshima@acm.org> wrote: >>>>>>>> >>>>>>>>> Hi Eliot, >>>>>>>>> >>>>>>>>> For build.linux64ARMv8/squeak.cog.spur/build.debug, i get >>>>>>>>> the following error. I think I followed the steps in the instructions, >>>>>>>>> including running updateSCCSVersion and mvm. How can I fix it? >>>>>>>>> >>>>>>>>> /home/pi/opensmalltalk-vm/spur64src/vm/cogit.c:22:3: error: >>>>>>>>> #error As yet no Cogit implementation appears to exist for your platform. >>>>>>>>> >>>>>>>>> # error As yet no Cogit implementation appears to exist >>>>>>>>> for your platform. >>>>>>>>> >>>>>>>>> ^~~~~ >>>>>>>>> >>>>>>>>> /home/pi/opensmalltalk-vm/spur64src/vm/cogit.c:23:3: error: >>>>>>>>> #error Consider implementing it, starting by adding a subclass of >>>>>>>>> CogAbstractInstruction. >>>>>>>>> >>>>>>>>> # error Consider implementing it, starting by adding a >>>>>>>>> subclass of CogAbstractInstruction. >>>>>>>>> >>>>>>>>> ^~~~~ >>>>>>>>> >>>>>>>>> make[1]: *** [Makefile:207: cogit.o] >>>>>>>>> >>>>>>>>> On Wed, Oct 21, 2020 at 10:21 AM Eliot Miranda < >>>>>>>>> eliot.miranda@gmail.com> wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Hi Yoshiki, >>>>>>>>>> >>>>>>>>>> On Wed, Oct 21, 2020 at 10:14 AM Yoshiki Ohshima < >>>>>>>>>> Yoshiki.Ohshima@acm.org> wrote: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> I heard that people got a new problem in inputting >>>>>>>>>>> Japanese text into Scratch 1.4 running on Raspberry Pi OS after, or around >>>>>>>>>>> the version 2020-08-20. I would like to take a look at it but it might >>>>>>>>>>> involve recompiling and generating the VM with debugging info. Last time >>>>>>>>>>> I looked into it was years and years ago and I need to basically make a >>>>>>>>>>> fresh start. >>>>>>>>>>> >>>>>>>>>>> Is the process of making NuSqeauk VM For Raspberry Pi up >>>>>>>>>>> to date and straightforward? Can people point me to the right point to >>>>>>>>>>> start? >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Making a Cog VM for Raspberry pi is straight-forward. >>>>>>>>>> Clone opensmalltalk-vm. cd to build.linux64ARMv8, read the HowToBuild, cd >>>>>>>>>> to build.linux64ARMv8/squeak.cog.spur/build.debug, or build.linux64ARMv8/squeak.stack.spur/build.debug, >>>>>>>>>> then run ./mvm >>>>>>>>>> >>>>>>>>>> _,,,^..^,,,_ >>>>>>>>>> best, Eliot >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> -- Yoshiki >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> -- Yoshiki >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> -- Yoshiki >>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> -- Yoshiki >>>>>> >>>>>> >>>>> >>>>> -- >>>>> _,,,^..^,,,_ >>>>> best, Eliot >>>>> >>>> >>>> >>>> -- >>>> -- Yoshiki >>>> >>>> > > -- > -- Yoshiki > >
-- _,,,^..^,,,_ best, Eliot
-- -- Yoshiki
-- -- Yoshiki
-- -- Yoshiki
-- _,,,^..^,,,_ best, Eliot
-- -- Yoshiki
The result from:
cc -dM -E - </dev/null | grep -i arm
is shown below. There is only one non uppercase value:
#define __ARM_SIZEOF_WCHAR_T 4
#define __ARM_FEATURE_SAT 1
#define __ARM_ARCH_ISA_ARM 1
#define __ARMEL__ 1
#define __ARM_FEATURE_UNALIGNED 1
#define __ARM_FP 12
#define __ARM_SIZEOF_MINIMAL_ENUM 4
#define __ARM_PCS_VFP 1
#define __ARM_FEATURE_LDREX 4
#define __ARM_FEATURE_QBIT 1
#define __ARM_ARCH_6__ 1
#define __ARM_32BIT_STATE 1
#define __ARM_FEATURE_CLZ 1
#define __ARM_ARCH_ISA_THUMB 1
#define __ARM_ARCH 6
#define __arm__ 1
#define __ARM_FEATURE_SIMD32 1
#define __ARM_FEATURE_COPROC 15
#define __ARM_EABI__ 1
#define __ARM_FEATURE_DSP 1
On Wed, Oct 28, 2020 at 4:17 PM Eliot Miranda eliot.miranda@gmail.com wrote:
On Wed, Oct 28, 2020 at 4:06 PM Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
I may be simply on a wrong OS. The main reason for me to dive in again was to fix it for Raspberry Pi OS users:
https://www.raspberrypi.org/downloads/raspberry-pi-os/
but then it simply is not a 64bit OS I gather. It's just the compiler on targets 32 bit. Sorry for a confusion. The following is the results from
cc -dM -E - </dev/null | grep ARM
Forgive me pushing, but can you also send the result of cc -dM -E - </dev/null | grep -i arm ? And the 64-bit ones are *way* faster and cheap...
Tim, what do you get for the same on raspbian?
#define __ARM_SIZEOF_WCHAR_T 4 #define __ARM_FEATURE_SAT 1 #define __ARM_ARCH_ISA_ARM 1 #define __ARMEL__ 1 #define __ARM_FEATURE_UNALIGNED 1 #define __ARM_FP 12 #define __ARM_SIZEOF_MINIMAL_ENUM 4 #define __ARM_PCS_VFP 1 #define __ARM_FEATURE_LDREX 4 #define __ARM_FEATURE_QBIT 1 #define __ARM_ARCH_6__ 1 #define __ARM_32BIT_STATE 1 #define __ARM_FEATURE_CLZ 1 #define __ARM_ARCH_ISA_THUMB 1 #define __ARM_ARCH 6 #define __ARM_FEATURE_SIMD32 1 #define __ARM_FEATURE_COPROC 15 #define __ARM_EABI__ 1 #define __ARM_FEATURE_DSP 1
On Wed, Oct 28, 2020 at 3:58 PM Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Yoshiki,
On Wed, Oct 28, 2020 at 12:59 PM Yoshiki Ohshima < Yoshiki.Ohshima@acm.org> wrote:
As for linux64ARMv8, I had to hack like this (The below is somewhat inconsistent but you'll get an idea) to get it produce a VM:
It looks like an issue of missing compiler macros for the architecture. The hack to sqUnixHeartbeat.c is likely to be wrong... the asm code specified for __ARM_ARCHI_ISA_A64 does not compile.
diff --git a/platforms/Cross/vm/sqAtomicOps.h b/platforms/Cross/vm/sqAtomicOps.h index ff5d3fdd7..96abe3a22 100644 --- a/platforms/Cross/vm/sqAtomicOps.h +++ b/platforms/Cross/vm/sqAtomicOps.h @@ -203,7 +203,7 @@ AtomicGet(__int64 *target)
# else /* TARGET_OS_IS_IPHONE elif x86 variants etc */
-#if defined(__arm__) && (defined(__ARM_ARCH_6__) || defined(__ARM_ARCH_7A__)) +#if defined(__arm__) && (defined(__ARM_ARCH_6__) || defined(__ARM_ARCH_7A__)) || 1 /* tpr - this is code intended for the Raspberry Pi Raspbian OS
- We'll experimentally trust in our MMU to keep 64bit accesses atomic
*/ # define get64(variable) variable diff --git a/platforms/unix/vm/sqUnixHeartbeat.c b/platforms/unix/vm/sqUnixHeartbeat.c index e9e3545fa..a526b4515 100644 --- a/platforms/unix/vm/sqUnixHeartbeat.c +++ b/platforms/unix/vm/sqUnixHeartbeat.c @@ -183,7 +183,7 @@ ioHighResClock(void) : "rdx"); #elif defined(__ARM_ARCH_ISA_A64) || defined(__arm64__) || defined(__aarch64__) || defined(ARM64) __asm__ __volatile__ ("MRS X0, CNTVCT_EL0"); -#elif defined(__arm__) && (defined(__ARM_ARCH_6__) || defined(__ARM_ARCH_7A__)) +#elif defined(__arm__) && (defined(__ARM_ARCH_6__) || defined(__ARM_ARCH_7A__)) || 1 /* tpr - do nothing for now; needs input from eliot to decide further */ /* Tim, not sure I have input beyond: Is there a 64-bit clock on ARM? If so, access it here :-) diff --git a/spur64src/vm/cogit.c b/spur64src/vm/cogit.c index d62b05f40..110685ac4 100644 --- a/spur64src/vm/cogit.c +++ b/spur64src/vm/cogit.c @@ -6,6 +6,8 @@ # define SysV 1 #endif
+#define __arm64__ 1
#if defined(__arm64__) || defined(__aarch64__) || defined(__ARM_ARCH_ISA_A64) || defined(ARM64) || defined(ARMv8)
# include "cogitARMv8.c" diff --git a/src/plugins/SqueakFFIPrims/SqueakFFIPrims.c b/src/plugins/SqueakFFIPrims/SqueakFFIPrims.c index 2878f9529..a0e5e0596 100644 --- a/src/plugins/SqueakFFIPrims/SqueakFFIPrims.c +++ b/src/plugins/SqueakFFIPrims/SqueakFFIPrims.c @@ -7,7 +7,7 @@ # define ARM32FFIPlugin_exports SqueakFFIPrims_exports # include "ARM32FFIPlugin.c"
-#elif defined(__ARM_ARCH_ISA_A64) || defined(__aarch64__) || defined(__arm64__) || defined(ARM64) || defined(_M_ARM64) +#elif defined(__ARM_ARCH_ISA_A64) || defined(__aarch64__) || defined(__arm64__) || defined(ARM64) || defined(_M_ARM64) || 1
# define ARM64FFIPlugin_exports SqueakFFIPrims_exports # include "ARM64FFIPlugin.c"
If you do $ cc -dM -E - </dev/null what predefined identifying macros do you get for aarch64/armv8? Then I can add them to the set tested in cogit.c
On Wed, Oct 28, 2020 at 9:24 AM Yoshiki Ohshima < Yoshiki.Ohshima@acm.org> wrote:
Ok!
I did make a pull request but then merged it by myself. Next thing for me to try is to build linux64ARMv8.
On Wed, Oct 28, 2020 at 8:47 AM Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Yoshiki,
On Oct 28, 2020, at 8:34 AM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
Come to think of it, a better fix for a problem like this one:
KeySym symbolic; int keyCode= x2sqKey(&evt->xkey, &symbolic); int ucs4= xkeysym2ucs4(symbolic);
was (obviously) to change the first line to:
KeySym symbolic= 0;
rather than to try to store 0 into *symbolic on the callee side. (A professor of my college days once told us that "most bugs are related to uninitialized variables." I should've known better.)
I had exactly this bug in the win32 CameraPlugin the other day. And it didn’t surface until shutting down the plugin on exiting the system. C, what a love/hate relationship it engenders :-)
When I get around to it, I'll make another change and this time make a pull request.
Or if you’d like I could invite you to become a committer and then you could avoid the pull request.
On Tue, Oct 27, 2020 at 11:43 AM Eliot Miranda < eliot.miranda@gmail.com> wrote:
> > > > On Tue, Oct 27, 2020 at 11:14 AM Yoshiki Ohshima < > Yoshiki.Ohshima@acm.org> wrote: > >> >> Thanks! Maybe I should not have sent a separate email to Eliot ^^; >> > > Don't sweat it :-) Fixes gratefully received :-) Thanks *very* > much for attending to the input issue. Much appreciated. > >> >> On Tue, Oct 27, 2020 at 10:46 AM Nicolas Cellier < >> nicolas.cellier.aka.nice@gmail.com> wrote: >> >>> >>> Ah too late, Eliot was faster, hit the pull request next time :) >>> >>> Le mar. 27 oct. 2020 à 18:43, Nicolas Cellier < >>> nicolas.cellier.aka.nice@gmail.com> a écrit : >>> >>>> Hi Yoshiki, >>>> what you could do is >>>> 1) revert the changes to sqPlatformSpecific.h (fseek, ftell) >>>> since we have a working workaround now >>>> 2) just create a pull request from the github web interface >>>> (that's rather easy) >>>> It will be very easy for us to integrate (one click), and we'll >>>> keep your authorship. >>>> >>>> Le mar. 27 oct. 2020 à 18:02, Yoshiki Ohshima < >>>> Yoshiki.Ohshima@acm.org> a écrit : >>>> >>>>> >>>>> I have a branch on a clone on github: >>>>> >>>>> >>>>> https://github.com/yoshikiohshima/opensmalltalk-vm/tree/composition-input-fi... >>>>> >>>>> It might be easier to pull from this? Separately, I'll mail you >>>>> sqUnixX11.c. >>>>> >>>>> On Tue, Oct 27, 2020 at 9:58 AM Eliot Miranda < >>>>> eliot.miranda@gmail.com> wrote: >>>>> >>>>>> >>>>>> Hi Yoshiki, >>>>>> >>>>>> on my Mac patch isn't smart enough to decode a git diff. >>>>>> Can you just email me your platforms/unix/vm-display-X11/sqUnixX11.c and >>>>>> I'll integrate? Thanks! >>>>>> >>>>>> On Tue, Oct 27, 2020 at 8:21 AM Yoshiki Ohshima < >>>>>> Yoshiki.Ohshima@acm.org> wrote: >>>>>> >>>>>>> >>>>>>> The previous one was just a hack but I think I found the real >>>>>>> problem. It was about the variable symbolic, that gets symbolic key code >>>>>>> *when* it is needed has to be zero'ed out when it is not needed. >>>>>>> >>>>>>> The diff is attached... I'll a make pull request if that helps. >>>>>>> >>>>>>> On Sat, Oct 24, 2020 at 5:32 PM Yoshiki Ohshima < >>>>>>> Yoshiki.Ohshima@acm.org> wrote: >>>>>>> >>>>>>>> For the /build.linuxARMv6/squeak.cog.spur/build.debug case, >>>>>>>> a hack I did was like this: >>>>>>>> >>>>>>>> diff --git a/platforms/unix/vm/sqPlatformSpecific.h >>>>>>>> b/platforms/unix/vm/sqPlatformSpecific.h >>>>>>>> >>>>>>>> index 268593673..bfb57257b 100644 >>>>>>>> >>>>>>>> --- a/platforms/unix/vm/sqPlatformSpecific.h >>>>>>>> >>>>>>>> +++ b/platforms/unix/vm/sqPlatformSpecific.h >>>>>>>> >>>>>>>> @@ -105,8 +105,8 @@ extern void sqFilenameFromString(char >>>>>>>> *uxName, sqInt stNameIndex, int sqNameLeng >>>>>>>> >>>>>>>> #undef sqFTruncate >>>>>>>> >>>>>>>> /* sqFTruncate should return 0 on success, ftruncate does >>>>>>>> also */ >>>>>>>> >>>>>>>> #define sqFTruncate(f,o) ftruncate(fileno(f), o) >>>>>>>> >>>>>>>> -#define ftell(s) ftello(s) >>>>>>>> >>>>>>>> -#define fseek(s,o,w) fseeko(s,o,w) >>>>>>>> >>>>>>>> +// #define ftell(s) ftello(s) >>>>>>>> >>>>>>>> +// #define fseek(s,o,w) fseeko(s,o,w) >>>>>>>> >>>>>>>> >>>>>>>> #if defined(__GNUC__) >>>>>>>> >>>>>>>> # if !defined(VM_LABEL) >>>>>>>> >>>>>>>> diff --git a/spur64src/vm/cogit.c b/spur64src/vm/cogit.c >>>>>>>> >>>>>>>> index d62b05f40..e1c14a021 100644 >>>>>>>> >>>>>>>> --- a/spur64src/vm/cogit.c >>>>>>>> >>>>>>>> +++ b/spur64src/vm/cogit.c >>>>>>>> >>>>>>>> @@ -6,6 +6,8 @@ >>>>>>>> >>>>>>>> # define SysV 1 >>>>>>>> >>>>>>>> #endif >>>>>>>> >>>>>>>> >>>>>>>> +#define __arm64__ >>>>>>>> >>>>>>>> + >>>>>>>> >>>>>>>> #if defined(__arm64__) || defined(__aarch64__) || >>>>>>>> defined(__ARM_ARCH_ISA_A64) || defined(ARM64) || >>>>>>>> defined(ARMv8) >>>>>>>> >>>>>>>> >>>>>>>> and this produced a runnable VM on Raspberry Pi4 >>>>>>>> >>>>>>>> On Sat, Oct 24, 2020 at 4:41 PM Yoshiki Ohshima < >>>>>>>> Yoshiki.Ohshima@acm.org> wrote: >>>>>>>> >>>>>>>>> And I tried a few more things by checking out the last >>>>>>>>> release tag 202003021730 or try opensmalltalk-vm/build. >>>>>>>>> linuxARMv6/squeak.cog.spur/build.debug but those attempts >>>>>>>>> did not work. For the latter got this error: >>>>>>>>> >>>>>>>>> In file included from /usr/include/features.h:424, >>>>>>>>> >>>>>>>>> from /usr/include/pthread.h:21, >>>>>>>>> >>>>>>>>> from >>>>>>>>> /home/pi/opensmalltalk-vm/platforms/unix/vm/sqPlatformSpecific.h:62, >>>>>>>>> >>>>>>>>> from >>>>>>>>> /home/pi/opensmalltalk-vm/platforms/Cross/vm/sqAssert.h:16, >>>>>>>>> >>>>>>>>> from >>>>>>>>> /home/pi/opensmalltalk-vm/platforms/unix/vm/aio.c:35: >>>>>>>>> >>>>>>>>> /usr/include/stdio.h:721:12: error: conflicting types for >>>>>>>>> ‘fseeko’ >>>>>>>>> >>>>>>>>> extern int __REDIRECT (fseeko, >>>>>>>>> >>>>>>>>> ^~~~~~~~~~ >>>>>>>>> >>>>>>>>> In file included from >>>>>>>>> /home/pi/opensmalltalk-vm/platforms/Cross/vm/sqAssert.h:16, >>>>>>>>> >>>>>>>>> from >>>>>>>>> /home/pi/opensmalltalk-vm/platforms/unix/vm/aio.c:35: >>>>>>>>> >>>>>>>>> /home/pi/opensmalltalk-vm/platforms/unix/vm/sqPlatformSpecific.h:109:22: >>>>>>>>> note: previous declaration \ >>>>>>>>> >>>>>>>>> of ‘fseeko’ was here >>>>>>>>> >>>>>>>>> #define fseek(s,o,w) fseeko(s,o,w) >>>>>>>>> >>>>>>>>> ^~~~~~ >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Sat, Oct 24, 2020 at 1:59 PM Yoshiki Ohshima < >>>>>>>>> Yoshiki.Ohshima@acm.org> wrote: >>>>>>>>> >>>>>>>>>> Hi Eliot, >>>>>>>>>> >>>>>>>>>> For build.linux64ARMv8/squeak.cog.spur/build.debug, i get >>>>>>>>>> the following error. I think I followed the steps in the instructions, >>>>>>>>>> including running updateSCCSVersion and mvm. How can I fix it? >>>>>>>>>> >>>>>>>>>> /home/pi/opensmalltalk-vm/spur64src/vm/cogit.c:22:3: error: >>>>>>>>>> #error As yet no Cogit implementation appears to exist for your platform. >>>>>>>>>> >>>>>>>>>> # error As yet no Cogit implementation appears to exist >>>>>>>>>> for your platform. >>>>>>>>>> >>>>>>>>>> ^~~~~ >>>>>>>>>> >>>>>>>>>> /home/pi/opensmalltalk-vm/spur64src/vm/cogit.c:23:3: error: >>>>>>>>>> #error Consider implementing it, starting by adding a subclass of >>>>>>>>>> CogAbstractInstruction. >>>>>>>>>> >>>>>>>>>> # error Consider implementing it, starting by adding a >>>>>>>>>> subclass of CogAbstractInstruction. >>>>>>>>>> >>>>>>>>>> ^~~~~ >>>>>>>>>> >>>>>>>>>> make[1]: *** [Makefile:207: cogit.o] >>>>>>>>>> >>>>>>>>>> On Wed, Oct 21, 2020 at 10:21 AM Eliot Miranda < >>>>>>>>>> eliot.miranda@gmail.com> wrote: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Hi Yoshiki, >>>>>>>>>>> >>>>>>>>>>> On Wed, Oct 21, 2020 at 10:14 AM Yoshiki Ohshima < >>>>>>>>>>> Yoshiki.Ohshima@acm.org> wrote: >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> I heard that people got a new problem in inputting >>>>>>>>>>>> Japanese text into Scratch 1.4 running on Raspberry Pi OS after, or around >>>>>>>>>>>> the version 2020-08-20. I would like to take a look at it but it might >>>>>>>>>>>> involve recompiling and generating the VM with debugging info. Last time >>>>>>>>>>>> I looked into it was years and years ago and I need to basically make a >>>>>>>>>>>> fresh start. >>>>>>>>>>>> >>>>>>>>>>>> Is the process of making NuSqeauk VM For Raspberry Pi up >>>>>>>>>>>> to date and straightforward? Can people point me to the right point to >>>>>>>>>>>> start? >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Making a Cog VM for Raspberry pi is straight-forward. >>>>>>>>>>> Clone opensmalltalk-vm. cd to build.linux64ARMv8, read the HowToBuild, cd >>>>>>>>>>> to build.linux64ARMv8/squeak.cog.spur/build.debug, or build.linux64ARMv8/squeak.stack.spur/build.debug, >>>>>>>>>>> then run ./mvm >>>>>>>>>>> >>>>>>>>>>> _,,,^..^,,,_ >>>>>>>>>>> best, Eliot >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> -- Yoshiki >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> -- Yoshiki >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> -- Yoshiki >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> -- Yoshiki >>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> _,,,^..^,,,_ >>>>>> best, Eliot >>>>>> >>>>> >>>>> >>>>> -- >>>>> -- Yoshiki >>>>> >>>>> >> >> -- >> -- Yoshiki >> >> > > -- > _,,,^..^,,,_ > best, Eliot >
-- -- Yoshiki
-- -- Yoshiki
-- -- Yoshiki
-- _,,,^..^,,,_ best, Eliot
-- -- Yoshiki
-- _,,,^..^,,,_ best, Eliot
On 2020-10-28, at 4:17 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
cc -dM -E - </dev/null | grep -i arm
On a Pi 4 running the *32 bit default Raspbian* I get - #define __ARM_SIZEOF_WCHAR_T 4 #define __ARM_FEATURE_SAT 1 #define __ARM_ARCH_ISA_ARM 1 #define __ARMEL__ 1 #define __ARM_FEATURE_UNALIGNED 1 #define __ARM_FP 12 #define __ARM_SIZEOF_MINIMAL_ENUM 4 #define __ARM_PCS_VFP 1 #define __ARM_FEATURE_LDREX 4 #define __ARM_FEATURE_QBIT 1 #define __ARM_ARCH_6__ 1 #define __ARM_32BIT_STATE 1 #define __ARM_FEATURE_CLZ 1 #define __ARM_ARCH_ISA_THUMB 1 #define __ARM_ARCH 6 #define __arm__ 1 #define __ARM_FEATURE_SIMD32 1 #define __ARM_FEATURE_COPROC 15 #define __ARM_EABI__ 1 #define __ARM_FEATURE_DSP 1
On a Pi 4 running *64 bit Gentoo* I get - #define __ARM_SIZEOF_WCHAR_T 4 #define __ARM_FEATURE_IDIV 1 #define __ARM_FP 14 #define __ARM_SIZEOF_MINIMAL_ENUM 4 #define __ARM_FEATURE_FMA 1 #define __ARM_ALIGN_MAX_PWR 28 #define __ARM_FP16_FORMAT_IEEE 1 #define __ARM_FP16_ARGS 1 #define __ARM_FEATURE_CLZ 1 #define __ARM_64BIT_STATE 1 #define __ARM_ARCH_PROFILE 65 #define __ARM_PCS_AAPCS64 1 #define __ARM_ARCH 8 #define __ARM_FEATURE_UNALIGNED 1 #define __ARM_ARCH_8A 1 #define __ARM_NEON 1 #define __ARM_ALIGN_MAX_STACK_PWR 16 #define __ARM_FEATURE_NUMERIC_MAXMIN 1 #define __ARM_ARCH_ISA_A64 1
This same Gentoo reports mprotect(x,y,PROT_READ | PROT_EXEC): Permission denied when I try to run the 64 bit ARM VM.
I could have sworn I had a uSD with Raspbian64 on it but it seems not. I'll make one and test on that again.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Has a one-way ticket on the Disoriented Express.
On 2020-10-28, at 4:34 PM, tim Rowledge tim@rowledge.org wrote:
I could have sworn I had a uSD with Raspbian64 on it but it seems not. I'll make one and test on that again.
Loaded and updated at last - Pi 4 with 64 bit Raspberry Pi OS:
#define __ARM_SIZEOF_WCHAR_T 4 #define __ARM_FEATURE_UNALIGNED 1 #define __ARM_FEATURE_IDIV 1 #define __ARM_FP 14 #define __ARM_ALIGN_MAX_STACK_PWR 16 #define __ARM_SIZEOF_MINIMAL_ENUM 4 #define __ARM_ALIGN_MAX_PWR 28 #define __ARM_FP16_FORMAT_IEEE 1 #define __ARM_FP16_ARGS 1 #define __ARM_FEATURE_FMA 1 #define __ARM_64BIT_STATE 1 #define __ARM_ARCH_PROFILE 65 #define __ARM_PCS_AAPCS64 1 #define __ARM_FEATURE_CLZ 1 #define __ARM_ARCH 8 #define __ARM_ARCH_8A 1 #define __ARM_NEON 1 #define __ARM_FEATURE_NUMERIC_MAXMIN 1 #define __ARM_ARCH_ISA_A64 1
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Oxymorons: Religious tolerance
On 2020-10-28, at 4:05 PM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
I may be simply on a wrong OS. The main reason for me to dive in again was to fix it for Raspberry Pi OS users:
https://www.raspberrypi.org/downloads/raspberry-pi-os/
but then it simply is not a 64bit OS I gather. It's just the compiler on targets 32 bit.
Ah, you're making a mistake made by many.
The Pi 4 (and indeed 3+, 3 and even the 2) have ARMv8 cpus. *BUT* Raspbian is a 32bit OS using the v7 support in the ARM A53 & A72 cores. A lot of people have posted questions asking if they have been sold a 'fake' Pi after seeing that the API for querying the processor type tells them they have a 32 bit v7. That is actually an upstream Debian issue not under the control of RPF at all.
So the squeak vm supplied for the current default Raspbian (or rather, recently renamed, Raspberry Pi OS) is a 32 bit version as built in the opensmalltalk-vm ▸ build.linux32ARMv6 ▸ squeak.stack.spur tree.
There *is* a 64 bit version of Raspberry PI OS that is currently in late-beta. That would need a VM from the opensmalltalk-vm ▸ build.linux32ARMv6 ▸ squeak.stack.spur tree and of course a 64 bit image. That VMworks on *some* OS but not others due to some issue with the permission bits for memory being messed around in the name of some sort of security waffle. Eliot has made it work for at least some cases - Manjaro, for example. It still needs sorting out for the Pi 64bit OS.
As soon as you have a 32bit vm that handled the Japanese input stuff ok, let me know and I'll do a build and ask RPF to upload it. I don't know how many people still use it on any sort of regular basis but it certainly isn't 0, which is gratifying.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim On a clear disk you can seek forever...
On 29/10/20 4:52 am, tim Rowledge wrote:
There*is* a 64 bit version of Raspberry PI OS that is currently in late-beta. That would need a VM from the opensmalltalk-vm ▸ build.linux32ARMv6 ▸ squeak.stack.spur tree and of course a 64 bit image.
Ubuntu released their 64-bit desktop versions for Raspberry Pi 4 just last week:
https://ubuntu.com/raspberry-pi
introduction and installation https://youtu.be/0pT4-RcTERU
direct link http://cdimage.ubuntu.com/ubuntu/releases/20.10/release/
HTH .. Subbu
Hi Yoshiki, Tim, Subbu,
ARMv8 is cool; but Linux is a hydra. In getting the JIT to work with ARMv8 I went with the first full 64-bit ARMv8 platform I could access, Manjaro on Raspberry Pi 4. I now also have an Apple Silicon Mac Mini.
The OS can impose radically different constraints on the JIT. In Mankato it is impossible to derive an executable region from mmap that is at the same time writable. On MacOS it is possible, but the VM needs a capability conveyed through its Info.plist and baked in when the app bundle is signed.
Other linuxes for Pi4 May impose different constraints. As I only have these two variants I need your help in dealing with differing constraints on these other platforms.
So what of these constraints? Manjaro’s prevents one from simply allocating the code zone as read+write+execute. So I have to allocate it read+execute and map it elsewhere in the address space as read+write and do all code zone modification (code generation, send-site editing/dynamic-linking/garbage-collection updating, compaction) through this second mapping. To enable that scheme the VM must be compiled with -DDUAL_MAPPED_CODE_ZONE=1. This is enabled in the mvm scripts in build.linux64ARMv8/squeak.cog.spur. I need to know if the dual mapping scheme is needed on other 64-bit distros.
So can you take a look, try both variants and report back? The allocation of the code zone and it’s remapping is done via mmap calls in platforms/unix/vm/sqUnixSpurMemory.c.
I have a small C test file that I used to experiment with copying a function into mmapped executable memory that I can post if you need to investigate why mmap might refuse to map write+execute and try and evade the restrictions it imposes.
_,,,^..^,,,_ (phone)
On Oct 29, 2020, at 3:29 AM, K K Subbu kksubbu.ml@gmail.com wrote:
On 29/10/20 4:52 am, tim Rowledge wrote:
There*is* a 64 bit version of Raspberry PI OS that is currently in late-beta. That would need a VM from the opensmalltalk-vm ▸ build.linux32ARMv6 ▸ squeak.stack.spur tree and of course a 64 bit image.
Ubuntu released their 64-bit desktop versions for Raspberry Pi 4 just last week:
https://ubuntu.com/raspberry-pi
introduction and installation https://youtu.be/0pT4-RcTERU
direct link http://cdimage.ubuntu.com/ubuntu/releases/20.10/release/
HTH .. Subbu
On 29/10/20 9:01 pm, Eliot Miranda wrote:
The OS can impose radically different constraints on the JIT. In Mankato it is impossible to derive an executable region from mmap that is at the same time writable. On MacOS it is possible, but the VM needs a capability conveyed through its Info.plist and baked in when the app bundle is signed.
doesn't PROT_EXEC imply PROT_READ? a region with write|exec would essentially be equivalent to an unprotected one.
Other linuxes for Pi4 May impose different constraints. As I only have these two variants I need your help in dealing with differing constraints on these other platforms.
I don't have a RP 4 board to test the Ubuntu aarch64 (COVID-19 lockdown constraints). Sorry :-(.
Regards .. Subbu
On Oct 30, 2020, at 4:39 AM, K K Subbu kksubbu.ml@gmail.com wrote:
On 29/10/20 9:01 pm, Eliot Miranda wrote:
The OS can impose radically different constraints on the JIT. In Mankato it is impossible to derive an executable region from mmap that is at the same time writable. On MacOS it is possible, but the VM needs a capability conveyed through its Info.plist and baked in when the app bundle is signed.
doesn't PROT_EXEC imply PROT_READ? a region with write|exec would essentially be equivalent to an unprotected one.
I believe not. I think an instruction fetch is different at the bus level from a normal read. I could be wrong. There are strong security reasons why this should be the case.
The manual page says
The protections (region accessibility) are specified in the prot argument by or'ing the following values:
PROT_NONE Pages may not be accessed. PROT_READ Pages may be read. PROT_WRITE Pages may be written. PROT_EXEC Pages may be executed.
Note that, due to hardware limitations, on some platforms PROT_WRITE may imply PROT_READ, and PROT_READ may imply PROT_EXEC. Portable programs should not rely on these flags being separately enforcable.
Note that it does *not* say that due to hardware limitations PROT_EXEC may imply PROT_READ :-)
Other linuxes for Pi4 May impose different constraints. As I only have these two variants I need your help in dealing with differing constraints on these other platforms.
I don't have a RP 4 board to test the Ubuntu aarch64 (COVID-19 lockdown constraints). Sorry :-(.
They're inexpensive and fun.
Regards .. Subbu
On 30. Oct 2020, at 19:39, Eliot Miranda eliot.miranda@gmail.com wrote:
The OS can impose radically different constraints on the JIT. In Mankato it is impossible to derive an executable region from mmap that is at the same time writable. On MacOS it is possible, but the VM needs a capability conveyed through its Info.plist and baked in when the app bundle is signed.
In OpenBSD, your _filesystem_ must allow write&exectute-pages otherwise your program is killed when trying to mprotect a page w&x.
-t
On 2020-10-29, at 3:29 AM, K K Subbu kksubbu.ml@gmail.com wrote:
On 29/10/20 4:52 am, tim Rowledge wrote:
There*is* a 64 bit version of Raspberry PI OS that is currently in late-beta. That would need a VM from the opensmalltalk-vm ▸ build.linux32ARMv6 ▸ squeak.stack.spur tree and of course a 64 bit image.
Ubuntu released their 64-bit desktop versions for Raspberry Pi 4 just last week:
Yeah, I saw that on the Pi forum. The bad news is that it includes that *appalling* UI, one that should never, ever, have seen the light of pixels. And unless there is some core OS difference it will presumably cause the same rtprio problem that the i7 version is causing...
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim A)bort, R)etry, I)nfluence with large hammer.
Yup. I just needed to fall into the same trap...
Now that we have an improved version of the VM, what is the "rest" of procedure to get the next version of Raspberry Pi OS to have the updated VM and installation? Somebody would make an apt package?
On Wed, Oct 28, 2020 at 4:22 PM tim Rowledge tim@rowledge.org wrote:
On 2020-10-28, at 4:05 PM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org
wrote:
I may be simply on a wrong OS. The main reason for me to dive in again
was to fix it for Raspberry Pi OS users:
https://www.raspberrypi.org/downloads/raspberry-pi-os/
but then it simply is not a 64bit OS I gather. It's just the compiler on
targets 32 bit.
Ah, you're making a mistake made by many.
The Pi 4 (and indeed 3+, 3 and even the 2) have ARMv8 cpus. *BUT* Raspbian is a 32bit OS using the v7 support in the ARM A53 & A72 cores. A lot of people have posted questions asking if they have been sold a 'fake' Pi after seeing that the API for querying the processor type tells them they have a 32 bit v7. That is actually an upstream Debian issue not under the control of RPF at all.
So the squeak vm supplied for the current default Raspbian (or rather, recently renamed, Raspberry Pi OS) is a 32 bit version as built in the opensmalltalk-vm ▸ build.linux32ARMv6 ▸ squeak.stack.spur tree.
There *is* a 64 bit version of Raspberry PI OS that is currently in late-beta. That would need a VM from the opensmalltalk-vm ▸ build.linux32ARMv6 ▸ squeak.stack.spur tree and of course a 64 bit image. That VMworks on *some* OS but not others due to some issue with the permission bits for memory being messed around in the name of some sort of security waffle. Eliot has made it work for at least some cases - Manjaro, for example. It still needs sorting out for the Pi 64bit OS.
As soon as you have a 32bit vm that handled the Japanese input stuff ok, let me know and I'll do a build and ask RPF to upload it. I don't know how many people still use it on any sort of regular basis but it certainly isn't 0, which is gratifying.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim On a clear disk you can seek forever...
On 2020-11-04, at 8:28 AM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
Yup. I just needed to fall into the same trap...
Life is full of silly traps.
Now that we have an improved version of the VM, what is the "rest" of procedure to get the next version of Raspberry Pi OS to have the updated VM and installation? Somebody would make an apt package?
What we do is make sure I can build an identical and working VM, I put together a new 5.3 based NuScratch image, we test it a bit, I pass the vm & image to RPF and they do the rest of the magic.
And of course, some documentation about how to make use of the new inputs is needed. Are there any changes to any of the translation files required? Anything else needing attention?
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Fractured Idiom:- IDIOS AMIGOS - We're wild and crazy guys!
Hi Tim,
This is probably a fix we'd do on the image side, but one thing Abe-san mentioned was that the first time playing a sound takes longer as it would be initializing the sound system. Maybe we can play a silent sound (like the sound of one hand clapping) at the start up time anyway as many Scratch projects involve sound anyway.
On Wed, Nov 4, 2020 at 1:50 PM tim Rowledge tim@rowledge.org wrote:
On 2020-11-04, at 8:28 AM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org
wrote:
Yup. I just needed to fall into the same trap...
Life is full of silly traps.
Now that we have an improved version of the VM, what is the "rest" of
procedure to get the next version of Raspberry Pi OS to have the updated VM and installation? Somebody would make an apt package?
What we do is make sure I can build an identical and working VM, I put together a new 5.3 based NuScratch image, we test it a bit, I pass the vm & image to RPF and they do the rest of the magic.
And of course, some documentation about how to make use of the new inputs is needed. Are there any changes to any of the translation files required? Anything else needing attention?
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Fractured Idiom:- IDIOS AMIGOS - We're wild and crazy guys!
On 2020-11-05, at 7:58 PM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
This is probably a fix we'd do on the image side, but one thing Abe-san mentioned was that the first time playing a sound takes longer as it would be initializing the sound system.
Ah, yes, that problem. It's basically a result of the utterly pathetic sound capabilities of linuxes. The 'fun' we had with pulseaudio and so on... (un)happy days.
Maybe we can play a silent sound (like the sound of one hand clapping) at the start up time anyway as many Scratch projects involve sound anyway.
There was, at some point, a Very Good Reason for using the 'stop sounds when done' preference. IIRC there was something about hissing background noises? We can certainly try again and see if the march of time has improved things.
There is also (as I've just been reminded by the very famous Scratcher Simon Walters) still the ancient bug of odd morph clipping when dropping a block onto another block to add it to the script. Never did manage to solve that one and it doesn't happen when you try to degub it... if anyone has any ideas...
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: SDD: Scratch Disk and Die
Another thing Abe-san told me is that the font rendering result is not good, as if anti-aliasing is not giving the right alpha. I have not looked into it but sounds like an annoying problem.
On Fri, Nov 6, 2020 at 11:21 AM tim Rowledge tim@rowledge.org wrote:
On 2020-11-05, at 7:58 PM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org
wrote:
This is probably a fix we'd do on the image side, but one thing Abe-san
mentioned was that the first time playing a sound takes longer as it would be initializing the sound system.
Ah, yes, that problem. It's basically a result of the utterly pathetic sound capabilities of linuxes. The 'fun' we had with pulseaudio and so on... (un)happy days.
Maybe we can play a silent sound (like the sound of one hand clapping)
at the start up time anyway as many Scratch projects involve sound anyway.
There was, at some point, a Very Good Reason for using the 'stop sounds when done' preference. IIRC there was something about hissing background noises? We can certainly try again and see if the march of time has improved things.
There is also (as I've just been reminded by the very famous Scratcher Simon Walters) still the ancient bug of odd morph clipping when dropping a block onto another block to add it to the script. Never did manage to solve that one and it doesn't happen when you try to degub it... if anyone has any ideas...
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: SDD: Scratch Disk and Die
On 2020-10-28, at 9:24 AM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
Ok!
I did make a pull request but then merged it by myself. Next thing for me to try is to build linux64ARMv8.
Assuming you do get a working ARMv8 VM, you *should* find that loading NuScratch from SqueakMap works.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Cashtration (n.): The act of buying a house, which renders the subject financially impotent for an indefinite period.
On 2020-10-28, at 8:34 AM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
(A professor of my college days once told us that "most bugs are related to uninitialized variables." I should've known better.)
AKA - Constants aren't. Variables won't.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Oxymorons: Religious tolerance
Hi Yoshiki,
On Sat, Oct 24, 2020 at 2:00 PM Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
Hi Eliot,
For build.linux64ARMv8/squeak.cog.spur/build.debug, i get the following error. I think I followed the steps in the instructions, including running updateSCCSVersion and mvm. How can I fix it?
I don't understand. It's there:
$ git remote get-url origin https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ git status On branch Cog Your branch is up-to-date with 'origin/Cog'. $ git log spur64src/vm/cogitARMv8.c commit 883fab5c30cff36aeb93129030e8f7bfa692a697 Author: Eliot Miranda eliot.miranda@gmail.com Date: Sat Oct 17 19:27:21 2020 -0700
etc
maybe you're on a different branch?
/home/pi/opensmalltalk-vm/spur64src/vm/cogit.c:22:3: error: #error As yet no Cogit implementation appears to exist for your platform.
# error As yet no Cogit implementation appears to exist for your platform.
^~~~~
/home/pi/opensmalltalk-vm/spur64src/vm/cogit.c:23:3: error: #error Consider implementing it, starting by adding a subclass of CogAbstractInstruction.
# error Consider implementing it, starting by adding a subclass of CogAbstractInstruction.
^~~~~
make[1]: *** [Makefile:207: cogit.o]
On Wed, Oct 21, 2020 at 10:21 AM Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Yoshiki,
On Wed, Oct 21, 2020 at 10:14 AM Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
Hi,
I heard that people got a new problem in inputting Japanese text into Scratch 1.4 running on Raspberry Pi OS after, or around the version 2020-08-20. I would like to take a look at it but it might involve recompiling and generating the VM with debugging info. Last time I looked into it was years and years ago and I need to basically make a fresh start.
Is the process of making NuSqeauk VM For Raspberry Pi up to date and straightforward? Can people point me to the right point to start?
Making a Cog VM for Raspberry pi is straight-forward. Clone opensmalltalk-vm. cd to build.linux64ARMv8, read the HowToBuild, cd to build.linux64ARMv8/squeak.cog.spur/build.debug, or build.linux64ARMv8/squeak.stack.spur/build.debug, then run ./mvm
_,,,^..^,,,_ best, Eliot
Hi Eliot,
On Sat, Oct 24, 2020 at 5:45 PM Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Yoshiki,
On Sat, Oct 24, 2020 at 2:00 PM Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
Hi Eliot,
For build.linux64ARMv8/squeak.cog.spur/build.debug, i get the following error. I think I followed the steps in the instructions, including running updateSCCSVersion and mvm. How can I fix it?
I don't understand. It's there:
$ git remote get-url origin https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ git status On branch Cog Your branch is up-to-date with 'origin/Cog'. $ git log spur64src/vm/cogitARMv8.c commit 883fab5c30cff36aeb93129030e8f7bfa692a697 Author: Eliot Miranda eliot.miranda@gmail.com Date: Sat Oct 17 19:27:21 2020 -0700
etc
maybe you're on a different branch?
The last commit (two commits) on the branch I am working with is like this:
commit 4f54eed845a8daef7681d17c01f004c3a7b50c9d
Author: Nicolas Cellier nicolas.cellier.aka.nice@gmail.com
Date: Fri Oct 23 22:46:36 2020 +0200
Fix https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/531
The return type of `currentUTCMicroseconds` was lost.
For some reason, the cygwin/mingw takes this compilation path
`#else // _WIN32_WINNT >= _WIN32_WINNT_WIN8`
commit efb4b1c82fd81798221d9811faa65f7bfb9c71be
Author: Eliot Miranda eliot.miranda@gmail.com
Date: Tue Oct 20 19:01:17 2020 -0700
Add stdio.h to sqWin32NewNet.c for its debug printing.
And I do see 883fab5c30cff36 in the ancestor chain. Maybe a macro name like __arm64__ or __arm_something__ is missing or different?
For the composition input problem, I have a hacky version of code that makes it not crash. It comes down to the line:
/* 24-bit UCS */ - if ((keysym & 0xff000000) == 0x01000000) return keysym & 0x00ffffff; + if ((keysym & 0xff000000) == 0x01000000) { + return 0; // keysym & 00x00ffffff; + }
I cannot tell when it gets "24-bit UCS" as keysym... keysym often does not store a code point like that, if I'm not mistaken.
There are other problems which I believe I introduced while ago to misunderstood a debugging macro DCONV_FPRINTF(), which adds stderr as the first argument but many calls to it were adding stderr by themselves.
Hi Yoshiki, Eliot, I confirm the problem, 32 bit linux build fails, on x86 too. it appears on travis log: https://travis-ci.org/github/OpenSmalltalk/opensmalltalk-vm/jobs/738800749
In file included from /usr/include/features.h:367:0,
from /usr/include/pthread.h:21,
from /home/travis/build/OpenSmalltalk/opensmalltalk-vm/platforms/unix/vm/sqPlatformSpecific.h:62,
from /home/travis/build/OpenSmalltalk/opensmalltalk-vm/platforms/Cross/vm/sqAssert.h:16,
from /home/travis/build/OpenSmalltalk/opensmalltalk-vm/platforms/unix/vm/aio.c:35:
/usr/include/stdio.h:781:12: error: conflicting types for ‘fseeko’
extern int __REDIRECT (fseeko,
^
In file included from /home/travis/build/OpenSmalltalk/opensmalltalk-vm/platforms/Cross/vm/sqAssert.h:16:0,
from /home/travis/build/OpenSmalltalk/opensmalltalk-vm/platforms/unix/vm/aio.c:35:
/home/travis/build/OpenSmalltalk/opensmalltalk-vm/platforms/unix/vm/sqPlatformSpecific.h:109:22: note: previous declaration of ‘fseeko’ was here
#define fseek(s,o,w) fseeko(s,o,w)
^
In file included from /usr/include/features.h:367:0,
from /usr/include/pthread.h:21,
from /home/travis/build/OpenSmalltalk/opensmalltalk-vm/platforms/unix/vm/sqPlatformSpecific.h:62,
from /home/travis/build/OpenSmalltalk/opensmalltalk-vm/platforms/Cross/vm/sqAssert.h:16,
from /home/travis/build/OpenSmalltalk/opensmalltalk-vm/platforms/unix/vm/aio.c:35:
/usr/include/stdio.h:784:18: error: conflicting types for ‘ftello’
extern __off64_t __REDIRECT (ftello, (FILE *__stream), ftello64);
^
In file included from /home/travis/build/OpenSmalltalk/opensmalltalk-vm/platforms/Cross/vm/sqAssert.h:16:0,
from /home/travis/build/OpenSmalltalk/opensmalltalk-vm/platforms/unix/vm/aio.c:35:
/home/travis/build/OpenSmalltalk/opensmalltalk-vm/platforms/unix/vm/sqPlatformSpecific.h:108:18: note: previous declaration of ‘ftello’ was here
#define ftell(s) ftello(s)
^
Makefile:252: recipe for target 'aio.o' failed
We are doing horrible things with C macro : #define ftell(s) ftello(s) because ftell is a different function with its own signature. If we include stdio.h AFTER this macro, then we are causing big trouble mixing the signatures... We can cheat as long as we do not get caught... It seems to me that we are caught red-handed! Compilation appears to pass on x64 linux.
Le dim. 25 oct. 2020 à 21:59, Yoshiki Ohshima Yoshiki.Ohshima@acm.org a écrit :
Hi Eliot,
On Sat, Oct 24, 2020 at 5:45 PM Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Yoshiki,
On Sat, Oct 24, 2020 at 2:00 PM Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
Hi Eliot,
For build.linux64ARMv8/squeak.cog.spur/build.debug, i get the following error. I think I followed the steps in the instructions, including running updateSCCSVersion and mvm. How can I fix it?
I don't understand. It's there:
$ git remote get-url origin https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ git status On branch Cog Your branch is up-to-date with 'origin/Cog'. $ git log spur64src/vm/cogitARMv8.c commit 883fab5c30cff36aeb93129030e8f7bfa692a697 Author: Eliot Miranda eliot.miranda@gmail.com Date: Sat Oct 17 19:27:21 2020 -0700
etc
maybe you're on a different branch?
The last commit (two commits) on the branch I am working with is like this:
commit 4f54eed845a8daef7681d17c01f004c3a7b50c9d
Author: Nicolas Cellier nicolas.cellier.aka.nice@gmail.com
Date: Fri Oct 23 22:46:36 2020 +0200
Fix https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/531 The return type of `currentUTCMicroseconds` was lost. For some reason, the cygwin/mingw takes this compilation path `#else // _WIN32_WINNT >= _WIN32_WINNT_WIN8`commit efb4b1c82fd81798221d9811faa65f7bfb9c71be
Author: Eliot Miranda eliot.miranda@gmail.com
Date: Tue Oct 20 19:01:17 2020 -0700
Add stdio.h to sqWin32NewNet.c for its debug printing.And I do see 883fab5c30cff36 in the ancestor chain. Maybe a macro name like __arm64__ or __arm_something__ is missing or different?
For the composition input problem, I have a hacky version of code that makes it not crash. It comes down to the line:
/* 24-bit UCS */
- if ((keysym & 0xff000000) == 0x01000000) return keysym & 0x00ffffff;
- if ((keysym & 0xff000000) == 0x01000000) {
- return 0; // keysym & 00x00ffffff;
- }
I cannot tell when it gets "24-bit UCS" as keysym... keysym often does not store a code point like that, if I'm not mistaken.
There are other problems which I believe I introduced while ago to misunderstood a debugging macro DCONV_FPRINTF(), which adds stderr as the first argument but many calls to it were adding stderr by themselves.
-- -- Yoshiki
Hi Nicolas,
On Oct 25, 2020, at 2:49 PM, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
Hi Yoshiki, Eliot, I confirm the problem, 32 bit linux build fails, on x86 too. it appears on travis log: https://travis-ci.org/github/OpenSmalltalk/opensmalltalk-vm/jobs/738800749 In file included from /usr/include/features.h:367:0, from /usr/include/pthread.h:21, from /home/travis/build/OpenSmalltalk/opensmalltalk-vm/platforms/unix/vm/sqPlatformSpecific.h:62, from /home/travis/build/OpenSmalltalk/opensmalltalk-vm/platforms/Cross/vm/sqAssert.h:16, from /home/travis/build/OpenSmalltalk/opensmalltalk-vm/platforms/unix/vm/aio.c:35: /usr/include/stdio.h:781:12: error: conflicting types for ‘fseeko’ extern int __REDIRECT (fseeko, ^ In file included from /home/travis/build/OpenSmalltalk/opensmalltalk-vm/platforms/Cross/vm/sqAssert.h:16:0, from /home/travis/build/OpenSmalltalk/opensmalltalk-vm/platforms/unix/vm/aio.c:35: /home/travis/build/OpenSmalltalk/opensmalltalk-vm/platforms/unix/vm/sqPlatformSpecific.h:109:22: note: previous declaration of ‘fseeko’ was here #define fseek(s,o,w) fseeko(s,o,w) ^ In file included from /usr/include/features.h:367:0, from /usr/include/pthread.h:21, from /home/travis/build/OpenSmalltalk/opensmalltalk-vm/platforms/unix/vm/sqPlatformSpecific.h:62, from /home/travis/build/OpenSmalltalk/opensmalltalk-vm/platforms/Cross/vm/sqAssert.h:16, from /home/travis/build/OpenSmalltalk/opensmalltalk-vm/platforms/unix/vm/aio.c:35: /usr/include/stdio.h:784:18: error: conflicting types for ‘ftello’ extern __off64_t __REDIRECT (ftello, (FILE *__stream), ftello64); ^ In file included from /home/travis/build/OpenSmalltalk/opensmalltalk-vm/platforms/Cross/vm/sqAssert.h:16:0, from /home/travis/build/OpenSmalltalk/opensmalltalk-vm/platforms/unix/vm/aio.c:35: /home/travis/build/OpenSmalltalk/opensmalltalk-vm/platforms/unix/vm/sqPlatformSpecific.h:108:18: note: previous declaration of ‘ftello’ was here #define ftell(s) ftello(s)
Right. These macros have to go. They are examples of the counter argument to Tobias’s “include sqConfig.h first” suggestion and shows why it can’t work. C headers don’t provide encapsulation, therefore a hack (such as the above define) which works in one release may break in another.
a) we have to change our client code to adapt to the platform, not the other way around. We can do this with macros, but they must come *after* system headers not before.
b) this implies that at the very least HAS_CONFIG_H must be defined in the compiler command line either as -UHAS_CONFIG_H, -DHAS_CONFIG_H, or my preference -DHAS_CONFIG_H=0 or -DHAS_CONFIG_H=1 since #if HAS_CONFIG_H is more concise and precise than
#ifdef HAS_CONFIG_H/#if defined( HAS_CONFIG_H)
c) I have realized (thanks David) that static line functions are often better than macros. They’re more powerful and more debuggable (in the debug build).
Makefile:252: recipe for target 'aio.o' failed
We are doing horrible things with C macro : #define ftell(s) ftello(s) because ftell is a different function with its own signature. If we include stdio.h AFTER this macro, then we are causing big trouble mixing the signatures... We can cheat as long as we do not get caught... It seems to me that we are caught red-handed! Compilation appears to pass on x64 linux.
Le dim. 25 oct. 2020 à 21:59, Yoshiki Ohshima Yoshiki.Ohshima@acm.org a écrit :
Hi Eliot,
On Sat, Oct 24, 2020 at 5:45 PM Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Yoshiki,
On Sat, Oct 24, 2020 at 2:00 PM Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
Hi Eliot,
For build.linux64ARMv8/squeak.cog.spur/build.debug, i get the following error. I think I followed the steps in the instructions, including running updateSCCSVersion and mvm. How can I fix it?
I don't understand. It's there:
$ git remote get-url origin https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ git status On branch Cog Your branch is up-to-date with 'origin/Cog'. $ git log spur64src/vm/cogitARMv8.c commit 883fab5c30cff36aeb93129030e8f7bfa692a697 Author: Eliot Miranda eliot.miranda@gmail.com Date: Sat Oct 17 19:27:21 2020 -0700
etc
maybe you're on a different branch?
The last commit (two commits) on the branch I am working with is like this:
commit 4f54eed845a8daef7681d17c01f004c3a7b50c9d Author: Nicolas Cellier nicolas.cellier.aka.nice@gmail.com Date: Fri Oct 23 22:46:36 2020 +0200
Fix https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/531 The return type of `currentUTCMicroseconds` was lost. For some reason, the cygwin/mingw takes this compilation path `#else // _WIN32_WINNT >= _WIN32_WINNT_WIN8`commit efb4b1c82fd81798221d9811faa65f7bfb9c71be Author: Eliot Miranda eliot.miranda@gmail.com Date: Tue Oct 20 19:01:17 2020 -0700
Add stdio.h to sqWin32NewNet.c for its debug printing.And I do see 883fab5c30cff36 in the ancestor chain. Maybe a macro name like __arm64__ or __arm_something__ is missing or different?
For the composition input problem, I have a hacky version of code that makes it not crash. It comes down to the line:
/* 24-bit UCS */
- if ((keysym & 0xff000000) == 0x01000000) return keysym & 0x00ffffff;
- if ((keysym & 0xff000000) == 0x01000000) {
- return 0; // keysym & 00x00ffffff;
- }
I cannot tell when it gets "24-bit UCS" as keysym... keysym often does not store a code point like that, if I'm not mistaken.
There are other problems which I believe I introduced while ago to misunderstood a debugging macro DCONV_FPRINTF(), which adds stderr as the first argument but many calls to it were adding stderr by themselves.
-- -- Yoshiki
Hi Eliot,
Le lun. 26 oct. 2020 à 03:52, Eliot Miranda eliot.miranda@gmail.com a écrit :
Hi Nicolas,
On Oct 25, 2020, at 2:49 PM, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
Hi Yoshiki, Eliot, I confirm the problem, 32 bit linux build fails, on x86 too. it appears on travis log: https://travis-ci.org/github/OpenSmalltalk/opensmalltalk-vm/jobs/738800749
In file included from /usr/include/features.h:367:0,
from /usr/include/pthread.h:21, from /home/travis/build/OpenSmalltalk/opensmalltalk-vm/platforms/unix/vm/sqPlatformSpecific.h:62, from /home/travis/build/OpenSmalltalk/opensmalltalk-vm/platforms/Cross/vm/sqAssert.h:16, from /home/travis/build/OpenSmalltalk/opensmalltalk-vm/platforms/unix/vm/aio.c:35:/usr/include/stdio.h:781:12: error: conflicting types for ‘fseeko’
extern int __REDIRECT (fseeko,
^In file included from /home/travis/build/OpenSmalltalk/opensmalltalk-vm/platforms/Cross/vm/sqAssert.h:16:0,
from /home/travis/build/OpenSmalltalk/opensmalltalk-vm/platforms/unix/vm/aio.c:35:/home/travis/build/OpenSmalltalk/opensmalltalk-vm/platforms/unix/vm/sqPlatformSpecific.h:109:22: note: previous declaration of ‘fseeko’ was here
#define fseek(s,o,w) fseeko(s,o,w)
^In file included from /usr/include/features.h:367:0,
from /usr/include/pthread.h:21, from /home/travis/build/OpenSmalltalk/opensmalltalk-vm/platforms/unix/vm/sqPlatformSpecific.h:62, from /home/travis/build/OpenSmalltalk/opensmalltalk-vm/platforms/Cross/vm/sqAssert.h:16, from /home/travis/build/OpenSmalltalk/opensmalltalk-vm/platforms/unix/vm/aio.c:35:/usr/include/stdio.h:784:18: error: conflicting types for ‘ftello’
extern __off64_t __REDIRECT (ftello, (FILE *__stream), ftello64);
^In file included from /home/travis/build/OpenSmalltalk/opensmalltalk-vm/platforms/Cross/vm/sqAssert.h:16:0,
from /home/travis/build/OpenSmalltalk/opensmalltalk-vm/platforms/unix/vm/aio.c:35:/home/travis/build/OpenSmalltalk/opensmalltalk-vm/platforms/unix/vm/sqPlatformSpecific.h:108:18: note: previous declaration of ‘ftello’ was here
#define ftell(s) ftello(s)
Right. These macros have to go. They are examples of the counter argument to Tobias’s “include sqConfig.h first” suggestion and shows why it can’t work. C headers don’t provide encapsulation, therefore a hack (such as the above define) which works in one release may break in another.
+1. In the meantime, I have published a simple workaround that works,
https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/1fde5ab77f6b4ef6770...
a) we have to change our client code to adapt to the platform, not the
other way around. We can do this with macros, but they must come *after* system headers not before.
b) this implies that at the very least HAS_CONFIG_H must be defined in the compiler command line either as -UHAS_CONFIG_H, -DHAS_CONFIG_H, or my preference -DHAS_CONFIG_H=0 or -DHAS_CONFIG_H=1 since #if HAS_CONFIG_H is more concise and precise than
#ifdef HAS_CONFIG_H/#if defined( HAS_CONFIG_H)
c) I have realized (thanks David) that static line functions are often better than macros. They’re more powerful and more debuggable (in the debug build).
OK, let's use modern C features
Makefile:252: recipe for target 'aio.o' failed
We are doing horrible things with C macro : #define ftell(s) ftello(s) because ftell is a different function with its own signature. If we include stdio.h AFTER this macro, then we are causing big trouble mixing the signatures... We can cheat as long as we do not get caught... It seems to me that we are caught red-handed! Compilation appears to pass on x64 linux.
Le dim. 25 oct. 2020 à 21:59, Yoshiki Ohshima Yoshiki.Ohshima@acm.org a écrit :
Hi Eliot,
On Sat, Oct 24, 2020 at 5:45 PM Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Yoshiki,
On Sat, Oct 24, 2020 at 2:00 PM Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
Hi Eliot,
For build.linux64ARMv8/squeak.cog.spur/build.debug, i get the following error. I think I followed the steps in the instructions, including running updateSCCSVersion and mvm. How can I fix it?
I don't understand. It's there:
$ git remote get-url origin https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ git status On branch Cog Your branch is up-to-date with 'origin/Cog'. $ git log spur64src/vm/cogitARMv8.c commit 883fab5c30cff36aeb93129030e8f7bfa692a697 Author: Eliot Miranda eliot.miranda@gmail.com Date: Sat Oct 17 19:27:21 2020 -0700
etc
maybe you're on a different branch?
The last commit (two commits) on the branch I am working with is like this:
commit 4f54eed845a8daef7681d17c01f004c3a7b50c9d
Author: Nicolas Cellier nicolas.cellier.aka.nice@gmail.com
Date: Fri Oct 23 22:46:36 2020 +0200
Fix https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/531 The return type of `currentUTCMicroseconds` was lost. For some reason, the cygwin/mingw takes this compilation path `#else // _WIN32_WINNT >= _WIN32_WINNT_WIN8`commit efb4b1c82fd81798221d9811faa65f7bfb9c71be
Author: Eliot Miranda eliot.miranda@gmail.com
Date: Tue Oct 20 19:01:17 2020 -0700
Add stdio.h to sqWin32NewNet.c for its debug printing.And I do see 883fab5c30cff36 in the ancestor chain. Maybe a macro name like __arm64__ or __arm_something__ is missing or different?
For the composition input problem, I have a hacky version of code that makes it not crash. It comes down to the line:
/* 24-bit UCS */
- if ((keysym & 0xff000000) == 0x01000000) return keysym & 0x00ffffff;
- if ((keysym & 0xff000000) == 0x01000000) {
- return 0; // keysym & 00x00ffffff;
- }
I cannot tell when it gets "24-bit UCS" as keysym... keysym often does not store a code point like that, if I'm not mistaken.
There are other problems which I believe I introduced while ago to misunderstood a debugging macro DCONV_FPRINTF(), which adds stderr as the first argument but many calls to it were adding stderr by themselves.
-- -- Yoshiki
Hi - we were just talking about you at the squeak board meeting :-)
On 2020-10-21, at 10:14 AM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote: I heard that people got a new problem in inputting Japanese text into Scratch 1.4 running on Raspberry Pi OS after, or around the version 2020-08-20. I would like to take a look at it but it might involve recompiling and generating the VM with debugging info. Last time I looked into it was years and years ago and I need to basically make a fresh start.
Is the process of making NuSqeauk VM For Raspberry Pi up to date and straightforward? Can people point me to the right point to start?
You shouldn't need to do anything special with the VM as far as I remember; I'll try to dig into my notes to see what I might have done. What I *do* recall is some problem with the X input method application - I managed to make it work at some point but then it catastrophically interfered with some other important thing. According to my ancient email archive I had quite a few messages with you and Kazuhiro-san to make this (almost) work in mid-2106. Something about an 'ibus' compositor window?
Building the VM is completely vanilla; clone the opensmalltalk vm repository, run Eliot's magic scripts to build the VMMaker image if you need to do any serious development work, or just run the 'mvm' scripts in the relevant directory to build from the current sources. On a Pi4 it only takes a couple of minutes.
Ah - here's something to do with it - in /usr/bin/squeak
# see if the XMODIFIERS stuff is being used # CURRENTLY DISABLED # serious problem in the keypress handling is causedby invoking it #if echo $XMODIFIERS | grep '@im=' > /dev/null; then # COMPIN="-compositioninput" #fi
So, one question is whether the current VM even has that cmdline option. And whether the applicable X input tool is available. Ah-hah - another old email -
ibus ibus-anthy ttf-kochi-gothic xfonts-intl-japanese xfonts-intl-japanese-big xfonts-kaname
- some libraries that needed to be installed.
The current NuScratch image is included in the Raspberry Pi OS releases and *shouldn't* need any changes in order to work with the compositioninput stuff, at least as well or badly as it ever did. The VM included is certainly a few years old but it is a Cog/Spur system and the image will happily run on a latest VM. I will someday make a new release for RPF but they're all into the JS/HTML Scratch3 now.
Making a new NuScratch image is, I hope, decently explained in the package on squeaksource, with some more info on the swiki at http://wiki.squeak.org/squeak/1263 and http://wiki.squeak.org/squeak/6604
Hope that helps a bit - let me know!
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Fractured Idiom:- PORTE-KOCHERE - Sacramental wine
On Wed, Oct 21, 2020 at 12:23 PM tim Rowledge tim@rowledge.org wrote:
Hi - we were just talking about you at the squeak board meeting :-)
On 2020-10-21, at 10:14 AM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org
wrote:
I heard that people got a new problem in inputting Japanese text into
Scratch 1.4 running on Raspberry Pi OS after, or around the version 2020-08-20. I would like to take a look at it but it might involve recompiling and generating the VM with debugging info. Last time I looked into it was years and years ago and I need to basically make a fresh start.
Is the process of making NuSqeauk VM For Raspberry Pi up to date and
straightforward? Can people point me to the right point to start?
You shouldn't need to do anything special with the VM as far as I remember; I'll try to dig into my notes to see what I might have done. What I *do* recall is some problem with the X input method application - I managed to make it work at some point but then it catastrophically interfered with some other important thing. According to my ancient email archive I had quite a few messages with you and Kazuhiro-san to make this (almost) work in mid-2106. Something about an 'ibus' compositor window?
It is about ibus (and related input method, and somehow it started throwing random (that is, not always repeatable) errors in the 2020-08-20 Raspberry Pi OS. Yes, I remember some issues last time around, but I don't remember the conclusion, and I have to suspect that I did not really follow through.
Building the VM is completely vanilla; clone the opensmalltalk vm
repository, run Eliot's magic scripts to build the VMMaker image if you need to do any serious development work, or just run the 'mvm' scripts in the relevant directory to build from the current sources. On a Pi4 it only takes a couple of minutes.
Thanks!
Ah - here's something to do with it - in /usr/bin/squeak
# see if the XMODIFIERS stuff is being used # CURRENTLY DISABLED # serious problem in the keypress handling is causedby invoking it #if echo $XMODIFIERS | grep '@im=' > /dev/null; then # COMPIN="-compositioninput" #fi
So, one question is whether the current VM even has that cmdline option. And whether the applicable X input tool is available. Ah-hah - another old email -
ibus ibus-anthy ttf-kochi-gothic xfonts-intl-japanese xfonts-intl-japanese-big xfonts-kaname
- some libraries that needed to be installed.
The current NuScratch image is included in the Raspberry Pi OS releases and *shouldn't* need any changes in order to work with the compositioninput stuff, at least as well or badly as it ever did. The VM included is certainly a few years old but it is a Cog/Spur system and the image will happily run on a latest VM. I will someday make a new release for RPF but they're all into the JS/HTML Scratch3 now.
Making a new NuScratch image is, I hope, decently explained in the package on squeaksource, with some more info on the swiki at http://wiki.squeak.org/squeak/1263 and http://wiki.squeak.org/squeak/6604
Hope that helps a bit - let me know!
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Fractured Idiom:- PORTE-KOCHERE - Sacramental wine
Hi,
I reproduced the bug. If there is a version of an equivalent image but with .changes file available, that would be really good. The system browser in the image is having trouble accepting a changed method if I just try to modify in the image.. (Or is there a better way to do it?)
Thanks!
On Wed, Oct 21, 2020 at 12:23 PM tim Rowledge tim@rowledge.org wrote:
Hi - we were just talking about you at the squeak board meeting :-)
On 2020-10-21, at 10:14 AM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org
wrote:
I heard that people got a new problem in inputting Japanese text into
Scratch 1.4 running on Raspberry Pi OS after, or around the version 2020-08-20. I would like to take a look at it but it might involve recompiling and generating the VM with debugging info. Last time I looked into it was years and years ago and I need to basically make a fresh start.
Is the process of making NuSqeauk VM For Raspberry Pi up to date and
straightforward? Can people point me to the right point to start?
You shouldn't need to do anything special with the VM as far as I remember; I'll try to dig into my notes to see what I might have done. What I *do* recall is some problem with the X input method application - I managed to make it work at some point but then it catastrophically interfered with some other important thing. According to my ancient email archive I had quite a few messages with you and Kazuhiro-san to make this (almost) work in mid-2106. Something about an 'ibus' compositor window?
Building the VM is completely vanilla; clone the opensmalltalk vm repository, run Eliot's magic scripts to build the VMMaker image if you need to do any serious development work, or just run the 'mvm' scripts in the relevant directory to build from the current sources. On a Pi4 it only takes a couple of minutes.
Ah - here's something to do with it - in /usr/bin/squeak
# see if the XMODIFIERS stuff is being used # CURRENTLY DISABLED # serious problem in the keypress handling is causedby invoking it #if echo $XMODIFIERS | grep '@im=' > /dev/null; then # COMPIN="-compositioninput" #fi
So, one question is whether the current VM even has that cmdline option. And whether the applicable X input tool is available. Ah-hah - another old email -
ibus ibus-anthy ttf-kochi-gothic xfonts-intl-japanese xfonts-intl-japanese-big xfonts-kaname
- some libraries that needed to be installed.
The current NuScratch image is included in the Raspberry Pi OS releases and *shouldn't* need any changes in order to work with the compositioninput stuff, at least as well or badly as it ever did. The VM included is certainly a few years old but it is a Cog/Spur system and the image will happily run on a latest VM. I will someday make a new release for RPF but they're all into the JS/HTML Scratch3 now.
Making a new NuScratch image is, I hope, decently explained in the package on squeaksource, with some more info on the swiki at http://wiki.squeak.org/squeak/1263 and http://wiki.squeak.org/squeak/6604
Hope that helps a bit - let me know!
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Fractured Idiom:- PORTE-KOCHERE - Sacramental wine
vm-dev@lists.squeakfoundation.org
-
Eliot Miranda -
K K Subbu -
Nicolas Cellier -
tim Rowledge -
Tobias Pape -
Yoshiki Ohshima