Gauche 0.9.5以前のバグ
hamayama(2016/10/04 08:20:59 UTC): インストール実施しました。
Windows 8.1 (64bit) : 64bit 版と 32bit 版のインストーラでインストール
Windows XP SP3 : 32bit 版のインストーラでインストール
以下は気が付いた点です。
(1)share/info フォルダが作成されない
(2)32bit版の libgcc_s_dw2-1.dll への依存
Gauche 本体は -static-libgcc が効いていますが、
libcharset-1.dll, libiconv-2.dll, zlib1.dll が依存していました。。。
このため、このファイルが存在しないPC上で、(use gauche.charconv) や (use rfc.zlib) を実行すると、エラーが発生します。
64bit版の方は問題ありません。(古い MinGW.org のときもこの依存はありませんでした)
対策としては、libgcc_s_dw2-1.dll をインストーラに含めることでしょうか。
(3)Windows 上でトップレベルコマンドの ,sh が機能しない
これはプルリクエスト送信してみます。
(4)gosh.exe のファイルサイズが大きくなった?
動作には問題なさそうですが。。。
hamayama(2016/08/11 14:21:55 UTC):インストールしてみました。
Windows 8.1 (64bit) : 64bit 版と 32bit 版のインストーラでインストール OK
Windows XP SP3 : 32bit 版のインストーラでインストール OK
以下は気が付いた点です。
(1)インストール時のメッセージ
Windows 8.1 (64bit) へのインストールで、以下のメッセージが出る。
「Windows によって PC が保護されました : Windows SmartScreen は認識されないアプリの起動を停止しました。
このアプリを実行すると、PC に問題が起こる可能性があります。」
詳細情報 → 実行 をクリックすれば問題なくインストールできる。
(2)bin フォルダの dll その1
libcharset-1.dll libiconv-2.dll zlib1.dll が足りないと思ったが、なくても動いた。。。
((use gauche.charconv) (use rfc.zlib) また depends.exe 等でも確認)
自分の環境でビルドすると これらの dll が必要なので、スタティックリンクされているもよう。
(3)bin フォルダの dll その2
libwinpthread-1.dll は、このインストーラでは不要かもしれない。
ただし、一般ユーザーが、MinGW-w64 の posix スレッド版でコンパイルした gosh.exe を、
上書きするかもしれないので、入れておいてもよいのかもしれない。
(MSYS2 で MinGW-w64 の toolchain を普通に入れると、posix スレッド版になるので。。。)
/mingw64/x86_64-w64-mingw32/lib/libz.a /mingw64/x86_64-w64-mingw32/lib/libiconv.a /mingw32/i686-w64-mingw32/lib/libz.a /mingw32/i686-w64-mingw32/lib/libiconv.a特に後から選んで入れた覚えがないので、mingw-w64を入れたときに自動的に入ったんだと思うんですが、hamayamaさんの環境はダイナミックリンクになるというのがちょっと謎です。
/mingw64/lib/libiconv.a /mingw64/lib/libiconv.dll.a /mingw64/lib/zlib.a /mingw64/lib/zlib.dll.a /mingw32/lib/libiconv.a /mingw32/lib/libiconv.dll.a /mingw32/lib/zlib.a /mingw32/lib/zlib.dll.aまた、pacman -Qs iconv と pacman -Qs zlib の実行結果は以下となっていました。
local/libiconv 1.14-2 (libraries)
Libiconv is a conversion library
local/mingw-w64-i686-libiconv 1.14-5 (mingw-w64-i686)
Character encoding conversion library (mingw-w64)
local/mingw-w64-x86_64-libiconv 1.14-5 (mingw-w64-x86_64)
Character encoding conversion library (mingw-w64)
local/mingw-w64-i686-zlib 1.2.8-9
Compression library implementing the deflate compression method found in
gzip and PKZIP (mingw-w64)
local/mingw-w64-x86_64-zlib 1.2.8-9
Compression library implementing the deflate compression method found in
gzip and PKZIP (mingw-w64)
local/perl 5.22.0-2 (base-devel)
A highly capable, feature-rich programming language
local/zlib 1.2.8-3 (libraries)
Compression library implementing the deflate compression method found in
gzip and PKZIP
あと、気になったのが、libiconv のライセンスですが、LGPL v2 のようで、local/libiconv 1.14-2 (libraries)とlocal/zlib 1.2.8-3 (libraries)だけだったんでこれがスタティックライブラリかな。スタティックとダイナミックが両方あるときはダイナミックが優先されるので、何かの依存関係の都合でダイナミックライブラリがインストールされると状況が変わるのかも。(ビルドには都合悪い話ですが)
hamayama(2016/07/31 13:40:27 UTC): niconico-seiga-downloader で SEGV する件、
32bit 版では再現しました。64bit 版でコンパイルすると発生しないので、何か違いがあるのかと。。。
hamayama(2016/07/31 15:57:24 UTC):再現する最小のプログラム。
(use rfc.tls) (make-tls)
hamayama(2016/08/01 13:32:05 UTC):
(1) MSYS2/MinGW-w64 の 64bit 版でコンパイルした rfc--tls.dll → OK
(2) MSYS2/MinGW-w64 の 64bit 版でコンパイルした ssltest.exe → OK
(3) MSYS2/MinGW-w64 の 32bit 版でコンパイルした rfc--tls.dll → NG
(4) MSYS2/MinGW-w64 の 32bit 版でコンパイルした ssltest.exe → OK
(5) MinGW (32bitのみ) でコンパイルした rfc--tls.dll → OK
(6) MinGW (32bitのみ) でコンパイルした ssltest.exe → OK
ということで、(3) だけが NG のようです。
メモリやレジスタが上書きされるのか、gdb で追いかけられないような動作をします。
exe にすると OK なので make check では検出されません。
何か dll のコンパイルオプションが足りないのか。。。
32bit 版の動作する方の rfc--tls.dll をコピーすれば、とりあえずは動くようですが。。。
hamayama(2016/07/30 16:06:32 UTC):以下のように R7RSのライブラリで、define に展開されるようなマクロを定義します。
(define-library (test-lib)
(export my-define)
(import (scheme base))
(begin
(define-syntax my-define
(syntax-rules ()
((_ var expr)
(begin
(define var expr)
var))))
))
そして、以下のようにこのライブラリを使うプログラムを作成します。
(import (scheme base)) (import (only (gauche base) add-load-path use print)) (add-load-path "." :relative) (import (test-lib)) ;(use test-mod) (define (f) (my-define x 100) (+ x 1)) (print (f))
このプログラムを実行すると、以下のエラーが出ます。
*** ERROR: syntax-error: the form can appear only in the toplevel: (#<identifier
test-lib##<identifier test-lib#define.2d13860>.2d13500> x 100)
While compiling "./test.scm" at line 7: (define (f) (my-define x 100) (+ x 1
))
While loading "./test.scm" at line 9
条件としては、
(1) ライブラリ中のマクロの定義で、define を begin で囲っている。
(2) ライブラリを使うプログラム側で、内部 define になるような位置でマクロを使用している。
(3) R7RS のライブラリのときにだけ発生する。Gauche のモジュールにした場合には発生しない。
があるようです。
Shiro(2016/08/06 07:44:14 UTC): 何らかの原因で識別子の同一性判定に失敗しているんですが、まだ原因が絞り込めていません。 次のリリースには積み残すかもしれないので、https://github.com/shirok/Gauche/issues/221 でトラックします。
hamayama(2016/07/13 13:04:29 UTC):Windows環境では、最近追加された run-process-pipeline のテストでエラーになります。
少し調べたのですが、原因はよく分かりませんでした。
(テストの (grep "bana") の部分を ,(cmd grep "bana") のように置き換えると、
プロセス2個まではいけるようでしたが、プロセス3個だとデッドロックしました。
Windows のパイプに何か問題があるのかもしれない。。。)
hamayama(2016/07/13 13:04:29 UTC):Boehm GC v7.4.4 への更新により、gctest が FAIL するようになりました。
とりあえずの対策として、tools/gc-configure.gnu-gauche.in の
--enable-large-config \
という行の下に、
--enable-gcj-support=no \
という行を追加したところ、gctest が PASS するようになりました。
(GCJ サポートとは、GNU Compiler for Java に対応するための機能のようです。
この機能のテストで、Segmentation Fault が発生していました。(ただし、発生しないときもある。。。))
irori(2016/03/18 11:26:08 UTC): 以下のようなtest.scmを用意して (require "./test.scm") すると返ってこなくなります。0.9.5_pre1 HEAD でも発生しました。
(use gauche.collection) (define foo (map (lambda (x) x) '(1 2 3)))
#<module gauche>にロードするかというと、
define-moduleもしくはdefine-libraryフォームが無条件で見えて欲しいから
(現在のモジュールにロードする場合、これらの束縛が見えなかったり別の意味になってる可能性がある)。
しかし、requireされるファイルがこのいずれのフォームも使わずにべたにuseや
defineを使うと、#<module gauche>が汚染されちゃうわけだ。
最も安全なのはrequireの度に#<module gauche>を継承する一時モジュールを
作ることだろうけど、ほぼ確実に毎回捨てられるのに作るのも無駄な感じだなあ。
妥協案はrequireのベースになるモジュールを専用にひとつ作っておいてそれを使うことだけど、
それでもuseやdefineのべた書きがあるとそのモジュールが汚染されてゆくから
やっぱり予期せぬ干渉が起こり得るか…
Shiro(2016/03/24 01:41:56 UTC): 直した https://github.com/shirok/Gauche/commit/3b7dacd029e4ca5ca39e1d8d07d0c1626329c29f
hamayama(2016/01/15 14:06:34 UTC):MSYS2/MinGW-w64 (64bit/32bit), MinGW (32bit) 等でインストールできる
gdbm は、どれもWindows上で正常に動作しないようです。
現状、mingw-dist.sh の configure オプションでは、--with-dbm=ndbm,odbm として、gdbm を外しています。
gdbm にWindows用のパッチを当てて使用可能にした場合には、上記オプションを削除して再ビルドが必要です。
以下のパッチがあるもよう(詳細未確認)。
(1)hamayama(2015/11/16 11:25:05 UTC): ext/tls/Makefile.in の更新により、
MinGW (32bit) 環境で、tlsのテストに失敗するようになりました。
pwd を pwd -W にする必要があるのと、kick_openssl の前の sh が消えたのが原因のようです。
(2)hamayama(2016/01/15 14:06:34 UTC):MSYS2/MinGW-w64 (64bit/32bit) 環境下で、tls のテストが固まる。
どうも openssl.exe の種類によって、OKのものとNGのものがあるようです(詳細原因不明)。
c:\msys64\mingw64\bin\openssl.exe ==> NG c:\msys64\mingw32\bin\openssl.exe ==> NG c:\msys64\usr\bin\openssl.exe ==> OK
NGのものを消すかリネームすれば、テストが成功するようになります。
(参考URL : http://stackoverflow.com/questions/9450120/openssl-hangs-and-does-not-exit )
hamayama(2015/10/10 01:34:47 UTC):コミット 33e9d16 (2015-10-9) で、トップフォルダの configure.ac が、
autoconf の v2.69 以上を要求するようになりました。
しかし MinGW (32bit) では v2.68 のようです (./DIST gen でエラーになります) 。
他にも configure.ac がいくつかあり、要求するバージョンはまちまちのようです。
./configure.ac → AC_PREREQ([2.69]) ./examples/mqueue-cpp/configure.ac → AC_PREREQ(2.54) ./examples/spigot/configure.ac → AC_PREREQ(2.54) ./ext/template.configure.ac → AC_PREREQ(2.54) ./gc/configure.ac → AC_PREREQ(2.61) ./gc/libatomic_ops\configure.ac → AC_PREREQ(2.61)
バージョンによって書式が異なったりするとやっかいだと思うのですが、
このあたり最低どのバージョンの autoconf が想定されていますでしょうか。
unsigned long → uintptr_tにする? sigset_t, truncate, ftruncate, timespec, execvp, mkstemp, arith.h, gdbm, tls に問題あり /c/msys64/mingw64/bin/grep.exe にバグがある(configureが無限ループする)ので消す スレッドモデル、例外処理、最適化オプション、依存DLLについて要調査。実力のある人が時間をかければ、できるのでしょうが。。。
hamayama(2015/08/25 15:55:06 UTC):不具合という訳ではありませんが。。。
cond-expand で一致する条件がなかった場合には、Unfulfilled cond-expand というエラーが発生します。
このため、例えば、
(cond-expand [gauche.os.windows (Windows専用の処理)])
のように書くと、Windows以外の環境では、エラーが発生して動かないプログラムになってしまいます。
(自分の環境(Windows)では動くので、なかなか気が付かない)
このような場合は、
(cond-expand [gauche.os.windows (Windows専用の処理)] [else])
のように else 節を書いておく必要があるようです。
cond と同じだと思っていて痛い目にあったので、
cond-expand は一致する条件がなかった場合にはエラーになることを、ユーザリファレンスに記述してほしいです。
hamayama(2015/08/25 14:24:47 UTC):「2015-7-15 REPL to skip trailing newline (1fdc908)」 のコミットで、以下の問題が出ています。
(1)CTRL-Cで終了しない(2回押すと終了する)
(2)read-line等で入力時の改行を無視するように処理が追加されているが、
Windowsコンソールでは改行がCR+LFであるため、無視できていない。
interactive.scm のパッチは以下です。
改行がCRのみのシステムもあるようなので、一部パッチを修正しました。hamayama(2015/08/26 09:49:24 UTC)
--- interactive_orig.scm 2015-08-23 04:14:06 +0900
+++ interactive.scm 2015-08-26 18:33:29 +0900
@@ -247,13 +247,15 @@
(null? (cddr expr)))
(handle-toplevel-command (cadr expr) (read-line))
(begin
- (%skip-trailing-ws)
+ (if (not (eof-object? expr)) (%skip-trailing-ws))
expr))))
(define (%skip-trailing-ws)
(if (byte-ready?)
(let1 b (peek-byte)
(cond [(memv b '(9 32)) (read-byte) (%skip-trailing-ws)]
+ [(eqv? b 13) (read-byte)
+ (if (and (byte-ready?) (eqv? (peek-byte) 10)) (read-byte))]
[(eqv? b 10) (read-byte)]
[else #t]))
#t))
--- vport_orig.c 2015-08-23 04:14:06 +0900
+++ vport.c 2015-08-29 03:49:54 +0900
@@ -106,7 +106,7 @@
to pushback multiple bytes. */
Scm_UngetbUnsafe(buf[i], p);
}
- return buf[0];
+ return (unsigned char)buf[0];
} else {
ScmObj b = Scm_ApplyRec(data->getb_proc, SCM_NIL);
if (!SCM_INTP(b)) return EOF;
hamayama(2015/08/25 10:15:33 UTC):Windows 8.1 (64bit), MinGW (32bit) 環境で、
コミット 9995b47 (2015-8-23) をビルドして、
make check を行うと、以下のエラーが検出されました。
Testing numbers ... failed. discrepancies found. Errors are: test exact (greatest-fixnum): expects 536870912 => got 536870911 test round->exact: expects 536870912 => got 536870911 test floor->exact: expects 536870912 => got 536870911 test ceiling->exact: expects 536870912 => got 536870911 test truncate->exact: expects 536870912 => got 536870911 Total: 15546 tests, 15541 passed, 5 failed, 0 aborted.
これらのテストは、
「2015-7-21 Fix exact for inexact integer around SCM_SMALL_INT_MAX or LONG_MAX (923cc9b)」
で追加されています。
long型のサイズが64ビットだと (exact (inexact (greatest-fixnum))) が 誤差の関係で 1 増加するが、
long型のサイズが32ビットだと増加しないということでしょうか。。。
これらのテストは、Gauche v0.9.4 で実行しても結果は 536870911 になります。
hamayama(2015/06/30 15:23:42 UTC):プルリクエストの #52 でエンバグしました(このプルリクエストを作成したのは私です。。。)。
現象は、古いMinGW(32bit)環境(2014-12-29より前?)でビルドすると、
*** Unhandled error occurred during reporting an error. Process aborted.
となって起動しない gosh.exe ができてしまうというものです。
原因は、プルリクエストの #52 で、win-compat.h に #include <tchar.h> を追加したところ、
_T マクロが Unicode 非対応になってしまったためです。
Windows には Unicode 対応を指示するシンボルに UNICODE と _UNICODE の2種類があり、
両方とも定義しないと、Unicode 対応/非対応が混在してしまうようです。
最新のMinGWでは、UNICODE と _UNICODE のどちらかが定義されていれば、もう一方も
定義されるように _mingw.h で対策されているため、問題が発生しませんでした。
対策としては、win-compat.h に 以下のパッチを当てれば、古いMinGW環境でも正常にビルドできるようになります。
もう少し自分で動作確認してから、再度プルリクエストを作成しようと思います。
--- win-compat_orig.h 2015-06-30 18:42:27 +0900 +++ win-compat.h 2015-06-30 23:31:48 +0900 @@ -18,6 +18,10 @@ #define WINVER 0x0500 /* we support Windows 2000 or later */ #endif /*WINVER*/ +#if defined(UNICODE) && !defined(_UNICODE) +#define _UNICODE /* Windows needs both UNICODE and _UNICODE */ +#endif /* UNICODE && !_UNICODE */ + #include <winsock2.h> /* MinGW needs this before windows.h */ #include <windows.h> #include <shlwapi.h>
#ifndef _T #define _T(x) TEXT(x) /* unicode macro */ #endif /* _T */
hamayama(2015/06/27 05:34:17 UTC):この問題はすでに修正されていますが、はまる場合があるので記述しておきます。
「2015-5-21 Save closure formals in procedure-info (c426bf3)」
のコミットで、Gaucheのセルフビルドが失敗するようになります。これは、
「2015-5-24 Fix self build issue introduced with closure argument info (edc43ec)」
のコミットで修正されていますが、
セルフビルドができない状態では、このコミットをビルドすることもできないため、
以後、ずっと最新版をビルドできない状況におちいります。
対策としては、一度 Gauche v0.9.4 に戻してから、最新版をビルドすれば、セルフビルドが可能な状態に戻ります。
Gauche scheme shell, version 0.9.4 [utf-8,wthreads], i686-pc-mingw32で以下のような障害に遭遇しました
gosh> (rxmatch #/.+/ (file->string "weak.c")) *** ERROR: stack overrun during matching regexp #/.+/
weak.cはgauche/src/weak.c(15463バイト)
2015/06/20 06:09:12 UTC
;; rep-whileはバックトラックしないはず gosh> (regexp-ast #/.+/) (0 #f (rep-while 1 #f any)) ;; でもVMアセンブリはTRYが入っちゃってる gosh> ((with-module gauche.internal %regexp-dump) #/.+/) Regexp 0x9d7a00: (flags=00000000) laset = #f must = (none) 0 BEGIN 0 2 ANY 3 TRY 10 6 ANY 7 JUMP 3 10 END 0 12 SUCCESS #<undef>
hamayama(2015/06/13 13:14:55 UTC):Windows 8.1 (64bit), MinGW (32bit) 環境でエラーになった点などです。
(1)Gauche-gl v0.6 (0a15fc2) のコンパイルでエラーになる
Gauche v0.9.5_pre1 で uvector のライブラリファイル名が変わった。
→ configure.ac 内の -lgauche-uvector を -lgauche--uvector に手作業で置換した。
(自動で切り換わるようになるとありがたいが。。。)
あとは以下の手順でコンパイルできた。
bash cd /c/work/Gauche-gl ./DIST gen ./configure --with-glut=mingw-static make make install # (コマンドプロンプトを管理者として実行しないとmkstempエラー) make check
(2)付属のサンプルで実行エラー1
examples/glbook/example13-3.scm の gl-rect の呼び出しでSEGVエラーになる。
→ src/gl-lib.stub を以下のように修正したら直った。
--- gl-lib_orig.stub 2014-12-29 21:55:10 +0900
+++ gl-lib.stub 2015-06-12 22:33:40 +0900
@@ -475,17 +475,17 @@
(unless (and (SCM_F32VECTORP v2) (== (SCM_F32VECTOR_SIZE v2) 2))
(goto badarg2))
(glRectfv (SCM_F32VECTOR_ELEMENTS v1) (SCM_F32VECTOR_ELEMENTS v2))]
- [(SCM_F64VECTOR_SIZE v1)
+ [(SCM_F64VECTORP v1)
(unless (== (SCM_F64VECTOR_SIZE v1) 2) (goto badarg1))
(unless (and (SCM_F64VECTORP v2) (== (SCM_F64VECTOR_SIZE v2) 2))
(goto badarg2))
(glRectdv (SCM_F64VECTOR_ELEMENTS v1) (SCM_F64VECTOR_ELEMENTS v2))]
- [(SCM_S32VECTOR_SIZE v1)
+ [(SCM_S32VECTORP v1)
(unless (== (SCM_S32VECTOR_SIZE v1) 2) (goto badarg1))
(unless (and (SCM_S32VECTORP v2) (== (SCM_S32VECTOR_SIZE v2) 2))
(goto badarg2))
(glRectiv (SCM_S32VECTOR_ELEMENTS v1) (SCM_S32VECTOR_ELEMENTS v2))]
- [(SCM_S16VECTOR_SIZE v1)
+ [(SCM_S16VECTORP v1)
(unless (== (SCM_S16VECTOR_SIZE v1) 2) (goto badarg1))
(unless (and (SCM_S16VECTORP v2) (== (SCM_S16VECTOR_SIZE v2) 2))
(goto badarg2))
(3)付属のサンプルで実行エラー2
examples/glbook/example9-4.scm の gl-tex-image-3d の呼び出しでSEGVエラーになる。
examples/slbook/ogl2brick/ogl2brick.scm の gl-create-shader-object-arb の呼び出しでSEGVエラーになる。
examples/slbook/ogl2particle/ogl2particle.scm の gl-create-shader-object-arb の呼び出しでSEGVエラーになる。
→ これらの機能はOpenGLの拡張機能になるらしく、glewInit を呼び出すことで使えるようになるらしい。
Gauche-gl では、glut-init の中で glewInit を呼び出すようになっている。
しかし glewInit は、glutCreateWindow を呼び出した後でないと、成功しないもよう。
ためしに glew-init という手続きを追加して、各サンプルでは glut-create-window の後で
この手続きを呼び出すようにしたところ、動作するようになった。
作成した src/glut-lib.stub example9-4.scm ogl2brick.scm ogl2particle.scm のパッチは以下です。
https://gist.github.com/Hamayama/583f6f226238948ec18e
ユーザが気を付けて glew-init を呼び出さないといけないので、よい解決策ではないかもしれません。
現行の glut-init の中でダミーウィンドウを生成して、glewInit を実行することも考えたのですが、
実際に使うウィンドウと同じI/Fが取得できるとは限らないらしく、これは断念しました。
参考URL:
http://glew.sourceforge.net/basic.html
https://stackoverflow.com/questions/24245481/glteximage3d-throws-exception
https://stackoverflow.com/questions/27236906/glewinit-and-glew-arb-xxx-failure-in-client-program
hamayama(2015/06/13 13:14:55 UTC)
(4)付属のサンプルの examples/glbook/example7-2.scm で、画面をマウスクリックするたびに描画が右方向にずれていく
→ disp の先頭に gl-load-identity を追加したら直った。
hamayama(2015/06/27 05:01:58 UTC)
(5)ログ取得の手続きで化けた文字が返ることがある
ログ取得(gl-get-info-log-arb)の手続きで、OpenGLのドライバが文字列長0を送ってきた場合に、ヌル終端していない文字列を返しているため。
hamayama(2015/06/28 12:20:44 UTC)
(6)glut-main-loop を使用しているプログラムで、コールバック内でエラーを起こすと、Gauche が異常終了する。
例えば、以下のようなプログラムで、disp, reshape, keyboard等の コールバック手続きの中でエラーを起こすと、
Windowsのメッセージボックスが出て異常終了します。
(define (main args) (glut-init args) (glut-init-display-mode (logior GLUT_DOUBLE GLUT_RGB GLUT_DEPTH)) (glut-init-window-size 480 480) (glut-init-window-position 100 100) (glut-create-window "planet") (init) (glut-display-func disp) (glut-reshape-func reshape) (glut-keyboard-func keyboard) (glut-timer-func *wait* timer 0) (glut-main-loop) 0)
ここで glut-main-loop のところで以下のようにエラーをトラップするようにすると、正常に終了するようになります。
(guard (ex (else (report-error ex) (exit 0)))
(glut-main-loop))
本件は、glut-main-loop が exit 以外で止められないことが原因と思われます。
hamayama(2015/07/24 09:08:37 UTC)(2016/01/15 14:06:34 UTC)
hamayama(2015/05/09 03:49:35 UTC):長い文字列の追加で文字列長が負になります。
例えば、
(string-length (string-append (make-string 536870911) (make-string 10)))
を実行すると -536870903 と表示されます。
ユニフォームベクタの場合は、
(use gauche.uvector) (u8vector-length (u8vector-append (make-u8vector 536870911) (make-u8vector 10)))
を実行すると、
*** ERROR: small integer required, but got 536870921
のように長さがチェックされています。
確認環境は Windows 8.1 (64bit) です。
hamayama(2015/05/09 03:49:35 UTC):MinGW (32bit) でコンパイルしたところエラーが2つでました。
以下のページの「4.」と「5.」の内容になります。
https://gist.github.com/Hamayama/19d7e779cec0480af0cf
「4.」はMinGW (32bit) に MemoryBarrier 関数が存在しないというものです。
「5.」はMinGW (32bit) の ランタイムのバージョンアップで生じた問題です。
確認環境は Windows 8.1 (64bit) です。
(1) wthread.h で InterLockExchange は InterlockedExchange が正しい ( lock が小文字でさらに ed が付く)
(2) gauche.h で #include <gauche/wthread.h> より後に #include <gauche/system.h> があるので、ScmTimeSpec の未定義エラーになる。
#include の順番を入れ替えると、今度は別の未定義エラーが出る。。。
とりあえず ScmTimeSpec の定義だけを #include <gauche/wthread.h> の前にコピーしたら、コンパイル、テストは通った。
( Total: 15428 tests, 15428 passed, 0 failed, 0 aborted. )
また、以下はエラーではありませんが、気になったところです。
(3) Gauche のソースを timespec で検索すると、
queue.scm mutex.c threads.c pthread.h uthread.h wthread.h に見つかった。
これらは問題なし? (未使用?)
(4) Gauche の gc のソースを timespec と nanosleep で検索すると、
pthread_stop_world.c pthread_support.c libatomic_ops\src\atomic_ops.c libatomic_ops\src\config.h に見つかった。
これらは問題なし? (未使用?)
hamayama(2015/02/27 15:28:27 UTC):Windows版でシステムエラーが発生したときには、
GetLastError() でエラーコードを取得しますが、その取得前の
ScmVM *vm = Scm_VM(); という行のところで、エラーコードがリセットされます。
この行を後ろに持っていくと、エラーコードがとれるようになりますが、今度は
FormatMessage() が日本語を返すため、コマンドプロンプトで文字化けします。
英語で表示するように指定しようとしましたが、環境によっては英語のエラーメッセージテーブルが
存在しないようです。また strerror() に変更すると、対応していないエラーがあるようです。
結局、エラーコードをそのまま表示するようにしてみました。
作成した error.c のパッチは以下です。
https://gist.github.com/Hamayama/d86b1c66040c23e7bb35
(Gauche v0.9.5-pre1 2015-2-24 時点に対するパッチとなっています)
hamayama(2015/05/09 03:49:35 UTC):いろいろあって時間が経ちましたが、エラーメッセージの表示を試みるようにしてみました。
変更した error.c のパッチは以下です。
https://gist.github.com/Hamayama/d86b1c66040c23e7bb35
例えば、
(use os.windows) (sys-get-std-handle 0)
とすると、自分の環境(Windows 8.1 (64bit))では、
*** SYSTEM-ERROR: GetStdHandle failed: The handle is invalid. (error code = 6)
のように表示されます。
齊藤 (2015/03/06 05:06:55 UTC) : 表題の通り、このふたつは使ったときにエラーになるのでパッチを作りました。
diff --git a/ext/peg/peg.scm b/ext/peg/peg.scm
index 3e02764..0b4592a 100644
--- a/ext/peg/peg.scm
+++ b/ext/peg/peg.scm
@@ -663,7 +663,7 @@
(if (parse-success? r)
(let loop ([r1 r] [v1 v] [s1 s])
(receive (r2 v2 s2) (($do [proc op] [v parse]
- ($return (proc v1 v)))
+ ($return (list proc v1 v)))
s1)
(if (parse-success? r2)
(loop r2 v2 s2)
@@ -677,7 +677,7 @@
(($do (h parse)
($or ($try ($do [proc op]
[t loop]
- ($return (proc h t))))
+ ($return (list proc h t))))
($return h)))
s)))
hamayama(2015/02/27 15:28:27 UTC):Windowsコンソール処理の修正と追加です。
test.scm に項目を追加して os.windows のAPIは一通り動作確認しました。
(自動で確認できない項目は今はコメントアウトしています)
確認環境は Windows 8 (64bit) です。
作成した console.stub, windows.scm, test.scm, win-compat.h のパッチは以下です。
https://gist.github.com/Hamayama/1e119ab425bde2a4120b
(Gauche v0.9.5-pre1 2015-2-24 時点に対するパッチとなっています)
(1)sys-create-console-screen-buffer で 第1引数に GENERIC_READ を指定するとエラーになる
→ GENERIC_READ が int の 0x80000000 と定義されており、uint の範囲外でエラーになるので、
第1引数を uint から int に変更した。
(2)sys-scroll-console-screen-buffer でエラーになる
→ 引数のチェックで条件が逆になっている。(unless → when)
→ clip-rectangle が #f のときは API 呼び出しの引数を NULL にする必要がある。
(3)sys-read-console-output-character
→ len+1 のオーバーフローチェック追加。
→ nul文字終端は、読み込んだ要素数+1の場所に入れるようにした。
(4)sys-write-console と sys-write-console-output-character
→ サロゲートペアの文字のときに短いサイズで出力してしまうので、
_tcslen() で長さを取得するようにした。
( win-compat.h には tchar.h のインクルードを追加 )
(5)引数や戻り値の型を一部見直し(int → uint 等)
(6)sys-set-console-title を追加した ( windows.scm にも export を追加 )
hamayama(2015/01/21 15:12:08 UTC):不具合というわけではありませんが。。。
ユーザリファレンスで、新しい方を使うように書いてあるものがあります。
例えば、以下があります。
補間文字列の書式 #`"～" → #"～" (v0.9.4から?)
ユニフォームベクタ read-block → read-uvector (v0.9.4から?) read-block! → read-uvector! (v0.9.4から?) write-block → write-uvector (v0.9.4から?)
しかし、新しい書き方をすると、旧バージョンでは逆に動かなくなります。
このような項目では、移行の判断ができるように、
新しい書き方が使えるようになったバージョンが明記されていてほしいです。
hamayama(2014/11/03 15:08:37 UTC):ユーザリファレンスの「6.14 ベクタ」の vector->string の説明が、
「文字のベクタをリストに変換」となっていますが「文字のベクタを文字列に変換」と思います。
また、vector->string の使用例が vector->list の使用例と同じになっています。
また、その下の (coerce-to <strin> vector) の部分で <string> の g が抜けています。
hamayama(2014/09/20 05:25:47 UTC):ユーザリファレンスの「4.1 字句構造」の「拡張された#構文」のところで、
「#`」が文字列の補間となっていますが、「#"」が新しい書式のようです。
(ここの一覧では「#"」は未使用と書かれています)
hamayama(2014/09/20 05:25:47 UTC):ローカルスコープの先頭以外にdefineを書くとエラーになりますが、
defineをトップレベルにしか置けないようなエラーメッセージになっていて少し迷いました。
また、ユーザリファレンスの「4.10 定義」のdefineのところをみると、
defineをローカルスコープの中に置けることは書いてありますが、先頭になければならないことは
書かれていないため、そこでもまた少し悩みました。
(define (f) (print "abc") ; ←これがあるとエラー (define x 100) (print x)) *** ERROR: Compile Error: syntax-error: the form can appear only in the toplevel : (define x 100)
h(2014/09/12 06:38:56 UTC): ext/windows/console.stub の SetConsoleScreenBufferSize で、
ハンドル h を Scm_WinHandle で囲めば動くようです。
--- console.stub.orig 2014-09-12 15:09:50 +0900
+++ console.stub 2014-09-12 15:13:41 +0900
@@ -235,7 +235,7 @@
(define-cproc sys-set-screen-buffer-size (h x::<short> y::<short>) ::<void>
(let* ([c::COORD])
(= (ref c X) x (ref c Y) y)
- (check (SetConsoleScreenBufferSize h c))))
+ (check (SetConsoleScreenBufferSize (Scm_WinHandle h '#f) c))))
;;
;; Console input