#S 式でフォーマットが記述できると便利そうですねぇ。Perl の pack はたまーに使いたくなることがありますが、そのたびによくわからなくて悩んでます。
#プログラム的にバイナリパーザを生成したい場合 (プロトコル記述からアクセサを生成するとか)、まあ直接binary.io手続きの呼び出しを生成してもいいんですが、間にDSLでワンクッション入ると何かと扱いやすいだろうなと思って.
#コンパイラの出すデバッグ情報からバイナリ構造体へのアクセサを作るとか。
#おおお。
##ソースを見ると本当にぜんぶ Scheme で書いてありました。
#Mac OS Xには標準でMecabが入ってることに気がついた
#びっくり
#ほんとに、オープンソースソフトウェアてんこ盛りで出荷してんだな
#ないぶてきに
#ことえりが使ってるとか？
#どうなんだろうね
#入ったのは10.5かららしい(10.5のSDKにしか入ってないっぽい)
#Spotlightとかで使ってるのかなぁ
#しめじ使うならソフトウェアキーボードのままがいいな。
#googleあっぷえんじん使ってみた。自動的にスケールできるのはいいね
#お金はかかるが
#アカウント管理はGmailのアカウントが使えるし、永続化もできる。リクエスト/レスポンスが30秒以内なのでCometはできないが
###$300なら欲しいかも
##OSが起動するとWebKitをカスタマイズしたブラウザが起動する。Chrome OSを先取りしている。
#Mingw で 無理矢理 Pthread を有効にして Gauche をビルドしてみた。 簡単なテストだとちゃんと機能しているっぽい。
#mingwでってことはWindowsのCreateThread()使ったってことかな。
#windows native threadでboehm gcは動いてるはずで、mingwでサポートされなかったのは単にconfigure時にwindows threadを使うようにする手間をかけてないだけのような気がする。
#あれ、でもmutexとかcondition variableはどうしてるんだろ。
#mingwってpthread_mutexのエミュレーションコードとか入ってたっけ?
#Gauche に入ってる gauche.thread のテストは全て OK になりましたよ。
#Boehm GC は少し弄りましたけど、 Windows の pthread は pthread_t が構造体になってる関係でちょろちょろひっかかっただけでした。 修正箇所はそんなに多くなかったです。
#しかし、試行錯誤でテキトーに弄ってしまったので、どこをどう弄ったのやら…。
#windowsそのものはpthread互換層を提供してないと思うんですが、POSIX Threads for Win32とか入れてます? それともmingwの方でそれを取り込んでるのかな
##これを使いました。
#ああ、わかりました。
###あ、POSIX Threads for Win32はプリコンパイルされたDLLを使いました? それとも自前でコンパイルしました?
#POSIX Threads for Win32は内部でCreateThread()を呼んでるはずなんですが、Boehm GCはそれをフックする必要があるはず。
#自前でコンパイルしましたけど、全く手を加えずに素直にコンパイルしました。 < POSIX Threads for Win32
#Boehm GC はマクロでうまいことやってフックしてたんじゃなかったかと…。 Pthread のビルド時にも何か必要なんですかね？
#あらためて確認してみるとフックできてないような気が。
#Boehm GC の gc_pthread_redirects.h が読まれていれば大丈夫なはず…
#ソースコードの字面で pthread_create になってるところがバイナリでは GC_pthread_create を呼んでることになってるのでフックできてるっぽい。
#thread が動くならひょっとして Kahua が動かないかなーと思って試してみたら fcntl 未サポート λ...
#あっそうか。GC_CreateThreadが呼ばれなくても、GC_pthread_createを呼ぶ→Boehm GC内で処理→POSIX thread for win32のpthread_createが呼ばれる→CreateThreadが呼ばれる、ということになるのでBoehm GC的には問題ないのか。
#ということはがんばってmingw版をwindows threadに対応させるよりも、pthreads-win32を同梱してしまうほうが近道かもしれませんね。LGPLみたいだし。
#fcntl については LibGW32C for Windows ってのが参考になるかと思って眺めてたんですが、これは単純には使えなさそうです。
##static int do_fcntl (int fd, int cmd, void *arg) って関数があるんですが…
#この関数の中に
#if (sizeof (*arg) == sizeof (struct flock64)) {
struct flock64 *fl = arg;
return lock64 (fd, cmd, fl);
}
else if (sizeof (*arg) == sizeof (struct flock)) {
struct flock *fl = arg;
return lock (fd, cmd, fl);
}
else {
__set_errno (EINVAL);
return -1;
}#void* のサイズとっても...
#もしかして gcc の拡張かと思って思わず確認してみたりしたけど、やっぱり間違いですよね。これ。
#あれ、そりゃ変ですね。
#そこはfcntlをエミュレートするよりも、ファイルのロックをos independentに行う中間層を作って、Kahuaをそっちに対応させるというのが筋のような気がする
#os independentなファイルのロックについては前から懸案事項ではあるんですが、下位層によって微妙にセマンティクスが変わってくるのでうまいセマンティクスを考えてるとこで止まってます。
#そうですね。 ファイルのロックは微妙に違うとは言えども大抵サポートしてるはずですが、 fcntl の形で抽象化するのは非現実的かもしれません。
#おお＞Posix Threads for Win32
#そんなものがあったのかー。
#Mosh では無駄に（？）Thread や Mutex、条件変数などのラップクラスを自作してしまった。
##pthread_sigmask は未実装となっております。 < Posix Threads for Win32
#windowsではそもそもPOSIXシグナルがほとんど意味をなさないのでそれはいいんじゃないかな。
#あれ、でもそうするとBoehm GCでstop worldするシグナルはどうやってハンドルされてるんだろう。
#あと、スタティックリンクするときは使う側でちょっとコードを変えなきゃならなかったはず。
##GC_stop_world -> GC_suspend -> SuspendThread(win32) という流れみたいですね。＞ stop world 。シグナルのところを見てみよう。
#そこだけwin32 thread apiを呼んでるのかな (pthread-win32を使う場合にstop_worldがどうなるか、ってことが気になってます)
#(boehm gc的にはpthreadプラットフォームに見えてるはずなので)
#なるほど。
#折角 thread が動いたのでもうちょっと本格的なアプリが動くかどうか試してみようと思って Mephisto を動かしたらちゃんと動いた。
#齊藤さんのビルドでGauchebox作るかなあ。ビルドを再現できないのは困るけど
#SF.netに齊藤さんbranchを作るのはどうか
##の Function: port-seek port offset &optional whence のとこ：
#You can only query the current byte offset of output string ports.
#を読んで「出力文字列ポートでしか現在のバイトオフセットは取得できない」と勘違いしてそんなバカな、と慌てた僕はとても恥ずかしい...
#エイゴムツカシイネ
#onlyはqueryにかかってる、ということですな
#わかりづらいかな。For output string ports, you can only query the current byte offset, but can not set it. とかの方がいいかも。
#lseek(2)を知ってればそんな理不尽な制限を設けるわけがないので誤読することないと思うんですけどね。「onlyはqueryにかかってる」と気付く前にREPLで動作を確かめちゃいましたよｗ
Gauche > Archives > 2009/07/17