nuSqueak source
Locked
 
|
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 <[hidden email]> wrote:
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 |
|
|
In reply to this post by Yoshiki Ohshima-3
Hi - we were just talking about you at the squeak board meeting :-) > On 2020-10-21, at 10:14 AM, Yoshiki Ohshima <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim Fractured Idiom:- PORTE-KOCHERE - Sacramental wine |
|
|
On Wed, Oct 21, 2020 at 12:23 PM tim Rowledge <[hidden email]> wrote:
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!
-- Yoshiki |
|
|
In reply to this post by timrowledge
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 <[hidden email]> wrote:
-- Yoshiki
|
|
|
In reply to this post by Eliot Miranda-2
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 <[hidden email]> wrote:
-- Yoshiki
|
|
|
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; [hidden email]; http://www.rowledge.org/tim Science is imagination equipped with grappling hooks. |
|
|
In reply to this post by Yoshiki Ohshima-3
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: https://youtu.be/HUieqOpD2k0 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 <[hidden email]> wrote:
-- Yoshiki
|
|
|
In reply to this post by Yoshiki Ohshima-3
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 <[hidden email]> wrote:
-- 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 <[hidden email]> wrote:
-- Yoshiki
|
|
|
In reply to this post by Yoshiki Ohshima-3
Hi Yoshiki, On Sat, Oct 24, 2020 at 2:00 PM Yoshiki Ohshima <[hidden email]> wrote:
I don't understand. It's there: $ git remote get-url origin $ 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 <[hidden email]> Date: Sat Oct 17 19:27:21 2020 -0700 etc maybe you're on a different branch?
_,,,^..^,,,_ best, Eliot |
|
|
Hi Eliot, On Sat, Oct 24, 2020 at 5:45 PM Eliot Miranda <[hidden email]> wrote:
The last commit (two commits) on the branch I am working with is like this: commit 4f54eed845a8daef7681d17c01f004c3a7b50c9d Author: Nicolas Cellier <[hidden email]> 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 <[hidden email]> 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 |
diff (6K) |
|
Hi Yoshiki, Eliot, I confirm the problem, 32 bit linux build fails, on x86 too. it appears on travis log:
Makefile:252: recipe for target 'aio.o' failedWe 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 <[hidden email]> a écrit :
|
|
|
Hi Nicolas, On Oct 25, 2020, at 2:49 PM, Nicolas Cellier <[hidden email]> wrote:
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).
|
|
|
Hi Eliot, Le lun. 26 oct. 2020 à 03:52, Eliot Miranda <[hidden email]> a écrit :
+1. In the meantime, I have published a simple workaround that works,
OK, let's use modern C features
|
|
|
In reply to this post by Yoshiki Ohshima-3
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 <[hidden email]> wrote:
-- 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 <[hidden email]> wrote:
_,,,^..^,,,_ best, Eliot |
|
|
I have a branch on a clone on github: 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 <[hidden email]> wrote:
-- Yoshiki
|
|
|
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 <[hidden email]> a écrit :
|
|
|
Ah too late, Eliot was faster, hit the pull request next time :) Le mar. 27 oct. 2020 à 18:43, Nicolas Cellier <[hidden email]> a écrit :
|
| Free forum by Nabble | Edit this page |