名前空間を実装したので、自分で自分をコンパイルすることができるようになったはず。 ...だが上手くいかないのでデバッグする。

上手くいかない

readerのテストがエラーになる。ただし他のテストは正常。

$ ./proto ~/repos/yuni/tests/lib/miniread0.sps > self.txt
-> Trying "/home/oku/repos/yuniribbit-proto/runtime/yunitest/mini.sls" -> Trying "/home/oku/repos/yuniribbit-proto/yunitest/mini.sls" -> Trying "/home/oku/repos/yuni/external/yunitest/mini.sls" -> Trying "/home/oku/repos/yuni/lib/yunitest/mini.sls" Error:
  0: "a"
  1: "unknown char literal"
Aborted (core dumped)

string-length の結果がおかしい。。？

"a" は (= 1 (string-length s)) が成立するはずなので、 error に行くのはおかしい。

... そもそも、 Trying... の出力の末尾には改行が入るはずなのに改行が入っていない。

$ ./proto ~/repos/yuni/tests/lib/miniread0.sps > base.txt
-> Trying "/home/oku/repos/yuniribbit-proto/runtime/yunitest/mini.sls"
-> Trying "/home/oku/repos/yuniribbit-proto/yunitest/mini.sls"
-> Trying "/home/oku/repos/yuni/external/yunitest/mini.sls"
-> Trying "/home/oku/repos/yuni/lib/yunitest/mini.sls"

okuoku

シリアライズがおかしい

改行を出力する newline 手続きは

のように実装されている。つまり、文字リテラルがおかしい。。？

(import (yuni scheme)
        (yuni io drypack))


(let ((p (open-output-bytevector)))
 (drypack-put p #\newline)
 (write (get-output-bytevector p)))

(exit 0)

これが

#u8(5 4 4 1 0 0 0 0 0 0 0)

本来は:

#u8(5 4 4 1 0 0 0 0 0 0 10)

となる。はず。確かに、

(write (char->integer #\newline))

とすると 0 が出力される。。つまり、readerが正しく文字リテラルを読めていない = Ribbonでコンパイル後のreaderをシリアライズすると壊れる と考えられる。今まではGaucheでシリアライズしたことしかない。

okuoku

定数テーブルから値が脱落している

シリアライズされた結果を比較してみると、ライブラリ (r7c-io writer datum) をGaucheでコンパイルした場合

       () 1 0 3 2 5 4 6 #\space " . " #f 8 7 "\\a" "\\b" 9 "\\t"
       10 "\\n" 13 "\\d" 34 "\\\"" 92
       "\\\\" "()" "#<eof-object>" "#t" "#f" quote #\'
       quasiquote #\` unquote #\, unquote-splicing #\@ "Unexpected" #\( #\)
       #\# #\u #\8 #\" #\\ "#<procedure>" "#<port>" "#<unknown>" -2 #t

となっているものが、Ribbonでは、

       () 1 0 3 2 5 4 6 #\space " . " #f 8 7 "\\a" "\\b" 9 "\\t"
       "\\n" "\\d" "\\\"" 
       "\\\\" "()" "#<eof-object>" "#t" "#f" quote #\'
       quasiquote #\`unquote #\, unquote-splicing #\@ "Unexpected" #\( #\)
       #\# #\u #\8 #\" #\\ "#<procedure>" "#<port>" "#<unknown>" -2 #t

のように、数値 10 13 34 92 が抜けている。

該当するコードは:

... これ 16進数値リテラルが正常に読めてない な。。

実装した。真面目なnumber readerを書かないといけないけどサボっている。。

よもやテストされていないとは。。

今回のような比較ができるように、どの処理系で出力してもシリアライズ結果が一致するようにした。 hashtable-keys や hashtable-entries の出力順は順不同(unordered)なので、最悪実行のたびに結果が違ってしまう可能性がある。