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)