[Uim] Standalone scm file crashing GTK

[Jon Babcock]

David Oftedal wrote:

> I now decided to model my romaja scm file after PY.scm so it wouldn't 
> have to depend on hangul.scm anymore. This was easier said than done, 
> because every time I add it to loader.scm, all GTK+ 2 apps start 
> segfaulting. Here are the important bits of the file:

I have been having the same problem trying to load pyunihan.scm. I got 
seg faults regardless of the actual content of pyunihan.scm. (Once, I 
even renamed PY.scm and got a seg fault.) But it's not totally consistent.

I reduced pyunihan.scm to this tiny version:

(define pyunihan-rule
   '(((("a"))("吖" "啊" "嗄" "腌" "錒" "锕" "阿"))
)
   )

(require "generic.scm")
;;
(define pyunihan-init-handler
   (lambda (id arg)
     (let* ((c (find-context id))
            (cc (context-data c)))
       (set-context-data!
        c
        (generic-context-new pyunihan-rule #f))
       ())))

(generic-register-im
  'pyunihan "zh_CN" "UTF8" pyunihan-init-handler)


Somehow loader.scm accepted this short version of pyunihan.scm and 
didn't crash.

When I added just one more pinyin syllable, 'ai', the candidate list was 
still restricted to 'a' only! No candidates for 'ai' appeared. (I 
restart the gnome app each time before trying the new version of 
pyunihan.scm) Uim was not using the new pyunihan.scm file, it seemed, 
but using a previous version of it. This is like what I experienced 
before, where uim was finding a kanji as a candidate *that was not in 
the current pyunihan.scm file*.

Is something referencing this file (besides /etc/gtk-2.0/gtk.immodules)?

Does loader.scm not like UTF-8-encoded files?

Thanks for the new releases of uim. It's very satisfying to see uim 
progressing so nicely.

Jon

-- 
Jon Babcock <jonatkanjidotcom>