I am slowly working my way up.  Most of the problems was about getting
the right environment variables for right processes, including the X
Server and Squeak.  I now get vanilla UTF32 values for characters I
type into the scim preedit window on Squeak.

The big question now is on the image side.  We used to have
StrikeFontSet as the default font and it was tad easier to just load
language specific fonts into the image.

At the same time, the clients' need here for me this time around
(i.e., make Squeak on raspi support Japanese input, I'd side step all
regular Squeak stuff and minimum changes.  I am inclined to take this
path now.

Tim, is there a repo of the NuScratch that is used in the NuScratch image?

On Wed, May 11, 2016 at 1:24 PM, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> Hi Yoshiki,
>
>> On May 11, 2016, at 1:20 PM, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>>
>> Hi Yoshiki,
>>
>>>> On May 11, 2016, at 11:52 AM, Yoshiki Ohshima <Yoshiki.Ohshima at acm.org> wrote:
>>>>
>>>>> On Tue, May 10, 2016 at 7:37 AM, Bert Freudenberg <bert at freudenbergs.de> wrote:
>>>>> On 10.05.2016, at 02:23, Yoshiki Ohshima <Yoshiki.Ohshima at acm.org> wrote:
>>>>>
>>>>> On Mon, May 9, 2016 at 10:35 AM, Yoshiki Ohshima
>>>>> <Yoshiki.Ohshima at acm.org> wrote:
>>>>>> The VM still does not display anything in the white window after I did
>>>>>> apt-get dist-upgrade, and copy the .sources file to the same directly.
>>>>>> (But I did not have an egg this morning).  I'll try some display
>>>>>> options.  But also, it appears that the source code for the Cog seems
>>>>>> to have the part I wrote for the composition input.  The goal may be
>>>>>> nearer than I originally thought.
>>>>>
>>>>> It may not as closer than I thought, however.  The world evolved to
>>>>> use ibus; we'd need to add some more stuff, such as DBus...  I'll
>>>>> report more tomorrow.
>>>>
>>>> Doesn’t ibus generate “old” X events, too? The README suggests this should work:
>>>>
>>>>       XMODIFIERS="@im=ibus" squeak
>>>>
>>>> ... which we could put in the startup script.
>>>
>>> This does not quite work.  And also Abe-san says that I'd better make
>>> it work with scim first so I am taking that path now.
>>>
>>> BTW, I have a long standing question of the development process.  I
>>> create a VM by doing ./mvm, which creates display drivers and VM in
>>> one way or another, and installs them to products directory somewhere
>>> upthere.  I have trouble seeing my changes to code gets reflected
>>> sometimes.  (Say, I change a printf message somehwere in sqUnixX11.c,
>>> run mvm and invoke the squeak shell script in
>>> products/cogspurlinuxhtARM/ but it seems to pick up a different binary
>>> from somewhere else.
>>
>> It shouldn't.  That's where the resulting binary gets installed (or a debug build in products/debug/cogspurlinuxhtARM etc).
>>
>>>
>>> What do people do to make the debug cycle go faster on Linux?
>>
>> That's what I've been using, and I find it unsatisfactory too.  I don't like the automake system and want to replace the whole thing with Gnu make makefiles (as is used in the win32 and MacOS builds) which would result in more sharing between the production, assert and debug builds plus accurate dependency information for reliable compilation, and the possibility of making a valid cogspurlinuxhtARM directory tree in the build directory and hence (again as I do in the win32 and MacOS builds) running the executable in the build directory instead of from products.
>
> And I forgot to say that indeed sqUnixX11.c is one of the files that suffers from inaccurate dependency info because it includes sqUnixEvent.c and sqUnixXdnd.c but the dependency isn't reflected in the makefiles :-(
>
>>
>>> -- Yoshiki
>>
>> _,,,^..^,,,_ (phone)
>



-- 
-- Yoshiki