#open, close, pipeの簡単なテストプログラム作りました＞https://gist.github.com/2816543 #このプログラムをGaucheと同じ環境（mingw で gcc pipe.c -Wl,--subsystem,windows ）でコンパイルして実行しました。
#そうすると、ソースの思惑通りに、openでfd0 = 0, fd1 = 1, fd2 = 2が確保されて、pipeは、pipe(4,5), pipe(6,8), pipe(9,10)を返しています。
#Gaucheのソースで、実際にpipeを作っているところはどこでしょうか。
#system.cのint pipe(int fd[])で作成した物を、そのままwin_prepare_handlesで使っているのでしょうか。
#もう少し追ってみます。
#0 の open は成功しているけど 1 2 は失敗しているとか．
##shiroさんに追いつきました。gosh-noconsole.exeだと、_pipeが(1, 2)、(4, 5)、(6, 7)を返してきてますね。このペアの片方だけが、win_prepare_handlesへ行くと。
#HEADで、gcのテストがひとつコケる(on Mac OS X 10.7.4 11E53)のはわたしんとこだけですかね?
#mach_msg failed in GC_mprotect_thread_notify
/bin/sh: line 1: 73366 Abort trap: 6 ${dir}$tst
FAIL: gctest#Testing control ... failed.
discrepancies found. Errors are:
test shutdown check: expects finished => got #f
#同じく10.7.4ですが違うとこですね
#FreeBSDでは起きないな...
#>enami それが失敗してないんですよ。
#それ、Gaucheのテストですよね? 私の方でコケてるのは、その前段にある、Boehm-gcのテストです。
#>(び) HEADは7544e34?
#gcは問題なしです。MacOSX, Ubuntu 12.04共
#7544e34です
#7544e347566e336908ad380c8f0afda9ca1725fd
#です
#ふーむ。gc/configure.acが変わってるんですが、./DIST genからやりました? > (び)、maruさん
#gauche-config --reconfigure | sh からだとmake中にエラーになるのでmaintainer-cleanして./DIST genからやり直してます
#同じく、make-maintainer-cleanしてからですね。
#むー、どういう違いだろう。その一つ前のコミット(78912e4)ならどちらもok?
#ひょっとして、gccじゃないとだめなのかしら
#と考えて、CC=clangを外してビルドしてみています。
#関係なかった...
#78912e4で再度試します
#Total: 12834 tests, 12834 passed, 0 failed, 0 aborted.
#git reset --hard HEAD^ してからだと完走しますね(MacOSX)
#78912e4です
#同じく。78912e4では、gcのテストのfailはなくなります。
#ふーむ。7544e34 の事実上の唯一の違いはgc/configure.acでAC_DEFINE(HANDLE_FORK)がイネーブルされていることなんですが、これをdnl AC_DEFINE(HANDLE_FORK) とコメントアウトするとどうなりますか。test/system.scm の"GC in forked process"がfailする(もしくはsystemのテストがabortするかハングするか) になるんじゃないかと予想しますがいかが。
#diff --git a/gc/configure.ac b/gc/configure.ac
index 43ae3ff..9b5e8ba 100644
--- a/gc/configure.ac
+++ b/gc/configure.ac
@@ -736,7 +736,7 @@ dnl [SK] this is _required_ to make Gauche work correctly.
CFLAGS="$CFLAGS -DDONT_ADD_BYTE_AT_END"
AC_DEFINE(LARGE_CONFIG)
dnl [SK] needed at least on OSX 10.7.3
-AC_DEFINE(HANDLE_FORK)
+dnl AC_DEFINE(HANDLE_FORK)
AC_SUBST(UNWINDLIBS)
#Testing system ... thread_suspend failed
#ここでハングアップぽいですね
#gcのテストは完走しましたが、同じところでハングアップしてます
#test GC in forked process, expects "done" ==>
#Testing system ... thread_suspend failed
画面にこう表示されてますが、src/test.logには出てません。
#おっけー。それは想定内です。そのバグを直すためのHANDLE_FORKだったのですが、まだ不十分ってことですね。
#gctestの結果の差が気になる...
#何でこっちでは出ないんでしょうね
#うん。不思議。
#たまにしかコケないのならまだしも、100%再現してるんですよ...
#スンマセン。会議の準備があるのでレスできなくなります
#仕事しろ＞ｵﾚ
#とりあえずHANDLE_FORKはundefしといて、gcの開発の方の様子見かなあ。
#HANDLE_FORKはrevertしました (9d8e11c)。
#ビルド中です
#全テスト通りました。
#lispの学習の障害としてカッコがよく取り上げられるのですが、英語の苦手な私個人の経験ではLAMBDAという「らむぶだ」としか読めない単語が出てくることではないかと思います。^を短さのために導入したということですが、学習コストも下げたと考えます。わたしだけのことなのかと思っていたら、同じようなことを考えているひとはいたようです： http://anond.hatelabo.jp/20090831000005 #何がひっかかるかってのは難しいですね。そこを乗り越えちゃうと忘れちゃうから。私はアセンブラとBASIC独学の後、学校でPascalやって、C言語はその次だったんですが、C言語のソースを見て「うわ、記号ばっかりでわかんねー」と思ったのを覚えてます(APLくらいになると逆にわからなさが魅力だったりしますが)。 ^もある程度慣れが必要じゃないかなあ。
#Pascal... タイプ初心者にprocedureはキツかった...
#RT : shiro: 何がひっかかるかってのは難しいですね。そこを乗り越えちゃうと忘れちゃうから。私はアセンブラとBASIC独学の後、学校でPascalやって、C言語はその次だったんですが、C言語のソースを見て「うわ、記号ばっかりでわかんねー ...
#波長の意味で変数にlambdaと名前をつけたら、違和感をずっと感じてしまったことがあるので、結局慣れだと思います。
#RT : yamasushi: lispの学習の障害としてカッコがよく取り上げられるのですが、英語の苦手な私個人の経験ではLAMBDAという「らむぶだ」としか読めない単語が出てくることではないかと思います。^を短さのために導入したということです ...
#no-consoleの件です。
#init_consoleの中でopen三回した後に、_pipeを3回呼ぶと、(3,4) (5,6) (7,8)が得られます。
#そのまま実行を続けて、CreateProcessの為のwin_prepare_handlesから呼ばれる_pipeは、(1, 2) (10, 11) (12, 13)を返します。
#init_consoleからwin_prepare_handlesの間に問題ありますね。
#お昼休みデバッグ終了。
#わたしはLとRが出てくるキーワードには必ずつまずいてしまいます。FORTRANのEQUIVALENCEなどはスペルでつまずきます。(その邪悪な動作でもつまずきますけども。)
#うまく発音できない音は文字の上でもうまく覚えられないようです。いまでもlambdaをラムダと読むのに抵抗があります。clojureがfnを採用していると知ったときには、海外のひともlambdaが苦手なのかなと思いました。
#lambdaは単に長いからじゃないですかね > fn。私はlambdaの発音には全然違和感ないんですが、発音といえばpteranodonには抵抗あります (あれはプテラノドンだろう!) pseudoとかpsychiatricとかpneumoniaには抵抗がないんで、どういう経緯で覚えたかが影響するのかも。
#足らな丼なのか…
#>natsutan ありがとうございます。どっかでcloseしちゃってるってことかなあ。
#あーわかった! Schemeのstdinとstderrをtrapper portで置き換えちゃってるから、元々NULLに向けてopenされてたポートがgcされて1と
#2がcloseされてるんだ。
#良かったです。
#> shiroさん
#この件で、まだお手伝いできる事ありますか？
#今最終チェックをしてコミットしようとしているところなので、コミットしたらpullしてテストして頂ければ。一応手元では動いてますが。
#了解です。
#pushしました (70f34e4)
#コマンドラインから、c:\MinGW\msys\1.0\local\bin\gosh-noconsole.exe button.scm と実行すると期待通りに動きます。しかし、エクスプローラーからbutton.scmを右クリックし、プログラムから開くで新しいgosh-noconsole.exeを選ぶと、上手く行かないです。
#一瞬何かウインドウが出て、wishのコンソールが出てきます。（パイプが繋がっていない時と同じ症状）
#コマンドラインからgosh-noconsole.exe の場合、Tkのボタンが表示されて、ボタンを押した時点で新しいウィンドウが開きYeah!と表示されます。
#うぐ。なかなか手強いのう。
#ごめんなさい。Windowsの関連づけの問題っぽいですね。もう少しお待ちください
#こちらでは、インストールすればscmファイルダブルクリックで動きました。
#C:\Program Files (x86) 以下にある古いgosh-noconsole.exe の名前を変えると、右クリックからmingw以下の新しいgosh-noconsole.exe が選べなくなってしまったので、古い方のgosh-noconsole.exe を起動してます。C:\Program Files (x86)以下にコピーしてもう一度やってみます。
#インストールしないと、tk.scmを見つけられないんじゃないかな。あ、ちなみにコピーする時はlibgauche-0.9.dllもお願いします。
#はい
#sh src/mingw-dist.sh を走らせているので少々おまちください
#動きました。
#sh src/mingw-dist.sh で出来たGaucheフォルダーをそのままC:\Program Files (x86)の下にコピーして、tk.scmをshare\gauche-0.9\site\libに置けばOKでした。
#>shiroさん
#ありがとうざいました。
#やたー。こういうトラブルシューティングのためには、スクリプトファイルを与えてgosh-noconsole.exeを起動した時にすぐエラー出力が消えるんでなくて窓を残せた方がいいなあ。何でもかんでもMessageBox出すとそれはそれでうざいのだけれど。
#DESTDIR絡みのビルドの問題が初めてGaucheをインストールする人にとってけっこう面倒なので、これまでのfixをまとめた0.9.3.3を出しました。
Gauche > Archives > 2012/05/28