[Vm-dev] nuSqueak source

Eliot Miranda eliot.miranda at gmail.com
Wed Oct 28 23:17:08 UTC 2020 

On Wed, Oct 28, 2020 at 4:06 PM Yoshiki Ohshima <Yoshiki.Ohshima at 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 at gmail.com>
> wrote:
>
>>
>> Hi Yoshiki,
>>
>> On Wed, Oct 28, 2020 at 12:59 PM Yoshiki Ohshima <Yoshiki.Ohshima at 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 at 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 at gmail.com>
>>>> wrote:
>>>>
>>>>>
>>>>> Hi Yoshiki,
>>>>>
>>>>> On Oct 28, 2020, at 8:34 AM, Yoshiki Ohshima <Yoshiki.Ohshima at 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 at gmail.com> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Oct 27, 2020 at 11:14 AM Yoshiki Ohshima <
>>>>>> Yoshiki.Ohshima at 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 at 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 at 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 at acm.org> a écrit :
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I have a branch on a clone on github:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> https://github.com/yoshikiohshima/opensmalltalk-vm/tree/composition-input-fix-2020-Oct
>>>>>>>>>>
>>>>>>>>>> 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 at 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 at 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 at 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 at 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 at 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 at gmail.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Hi Yoshiki,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Wed, Oct 21, 2020 at 10:14 AM Yoshiki Ohshima <
>>>>>>>>>>>>>>>> Yoshiki.Ohshima at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20201028/479340e6/attachment-0001.html>

More information about the Vm-dev mailing list