Gauche:Windows/VC++:log:old_2003

Gauche:Windows/VC++:log:old_2003

GaucheってVC++でコンパイルできますか? 言語のコアに関わりそうな所だけでいいのですが。ちらっと見た所MSWIN32というifdefフラグはあるのですが、 VC++のビルドに関するドキュメントが見つけられませんでした。--有野

Shiro (2003/03/02 18:59:28 PST): 今のところVC++で試したことはありません。 環境も無いので… 誰かがトライしてくれることを期待して別ページを立ててみました。 とりあえず、システム関数関係がPOSIXべったりなんでそこを分離させないと 難しそうではあります。

軽く挑戦してみた所config.hが無い、だそうで(<あたりまえ)
さて、configureの部分はどうするのがこういう場合は正しいんでしょうかね? WinCEのフラグがある、という事はconfigureの動かない環境での前例があるんでしょうか?--有野

gcはBoehm GCのコードを持って来ていて、その中ではMSWIN32とかMSWINCEとかのフラグは 使われていますが、Gaucheのメイン部分(src以下)にはそういうフラグはないはずです。 一度も試みたことがないので。 MSWINが定義されてたらconfig.hじゃなくてconfig_win32.hを読むとかしておけば 良いのかなあ。--Shiro (2003/03/04 02:23:14 PST)

あれま。gcの中だけだったのですか。 CEでの前例があるのかとふんでいたのですが。
それでは自分で勝手にやってみる事にします。 ただ動かすだけならどうにかなりそうですが、 ちゃんと移植するのは面倒そうです。
thread回りがちょっと骨ですねぇ。 ちなみにこのWiki、日付はどういれるのでしょうか?--有野

日付は$dateというマクロで入ります (cf. WiLiKi:リファレンスマニュアル:マクロ)

thread回り: Windowsのthreadセマンティクスを良く知らないんですが、 mutexとconditional variableに関しては一応マクロにしてあります (src/gauche/pthread.hとsrc/gauche/uthread.h)。

路線

とりあえずコンパイルを通して実行してみる。 必要な機能は後から足す。 あまりコードの変更量を減らすように、という努力はせずに、 総量見積もる程度のつもりで適当にifdefを足していく。

なお、LoadLibraryやらCreateThreadやらはやればそんなに大変でも無さそうですが、後回しという事でoffで行きます。

途中経過、雑感

作業記録とあんましかわらない気もするけど、 こちらは実験とか雑感とか。

2003/03/06 10:28:29 PST

シグナル回りはどうすべきか。 適当に存在する奴だけ対応、でもちろん移植は完成なのだが、、、

パス名区切り文字

どうも内部でも/区切りでgaucheはファイル名を持ちたがっているように見える。/等は何かの背後に隠す、というのが正しいのかもしれないけど、綺麗になるだけで面倒さは増す気もする

ファイルに触る回りだけでなんかフィルタかまして¥に変換してもいいんだけど、ちとカコワルイ

LoadFile全面書き換えで内部的にも¥区切りで持たせておくのが好みな気がする

普通に考えるとWinなのだからレジストリにロードパス等は入れるべきだろう。それが嫌なら.exeのあるフォルダと同じ所に初期化ファイルを置く、とか。あんまし特定パスを環境変数で設定させて、それを変更するとでどこでもおっけー、というのはWinっぽく無い気がする

でも複数のインタプリタを同居させるならslibのパス等は環境変数で設定したいかもしれない。うーん。

有野 2003/03/06 14:07:09 PST うーん、やっぱりそっちの方がいいですかねぇ。そうするとネットワークドライブとかドライブの変更とかそういう事が少し面倒になりそうなのがいまいち乗り気にならない所ですが。
個人的にはこういう所はWindowsべったりの方が好みですが、そうするとスクリプト側も変更しなきゃいけなかったり、変更箇所も多くなったりで悩ましい所です。
ただ、とりあえずの実験ならシステムに渡す所で変換、が一番楽そうなのでそれでいきます。

有野 2003/03/08 11:14:01 PST パス文字、ドラッグアンドドロップでファイル名を取るとC:¥から始まってしまうのですが、どうするのがいいですかね?

そもそも_openってロングファイルネーム対応だったか知らないのですが。 やっぱり男らしくCreateFileHandleにするべきかなぁ。

コンソール

Window作ってメッセージ送信をWindow宛てに行う、とかの方がまだWindowsアプリっぽい気がする。 イベントドリブンに直さなきゃいけないけど。

コンソールアプリってかっこ悪いから嫌いなんだよなぁ…

Windows的に考えるならIActiveScriptを実装してCScriptで実行する、 という方が正しい気がする。

でも面倒だからまずはUnix臭くてもいいかな(ぉ

シグナル

作業記録

2003/03/05 07:35:54 PST

getoptやらgetgrgidやらひっかかるので適当によきにはからう。 いくつかシグナル系で面倒な物は関数自体をダミーにさしかえてしまう。

2003/03/05 12:11:29 PST

2003/03/07 00:03:43 PST

ここまでで一応動くようになります。 ただ、これだと途中のデバッグが不可能なので、途中で

というのが必要だと思います。

2003/03/08 21:21:27 PST

以上で動く事は動きます。 DllのロードとかThreadとか残っている物はいろいろありますが、 Win32APIでゴリゴリ書くのがもうたくさんなので今後は小さい変更をちょろちょろしたら、たぶんATLに進みます。 レジストリ使いまくりで皆様お嫌いでしょうから、ここらでこのバージョンは終了、 という感じにする予定。

2003/03/09 09:05:31 PST

成果物

問題はどこで公開するか、だけど…パッチでいいかなぁ。

作ってみました。

http://members.tripod.co.jp/k_arino/patch.txt

そのうち消すかもしれません。

問題点

今後の標準的な路線

こんな事を書くのは有野は違う方向に進むつもりだからですが。

という感じでしょうか。 たぶんどれもそんなに大変では無いと思いますし、 そこそこ需要もあるとは思います。


ATL版のインターフェース

とりあえず実装前に考えておく。

徐々に足していく予定。

ここまで来て、Scm_Applyを使いやすくするには、 なんかまともに機能するwrite可能なポートが欲しい事に気づく。 それを設定してやれば、Scm_Writeでちまちま書いていく、 という作戦が取れるので。

また、Scm_MakeSubrのような類の物は含めるべきだろうか?

Scm_MakePortWithFdのようなあたりをうまく扱わないと、 VMをnewしてもいろいろ使いにくいんだよなぁ。

ここらへんを考えると、むしろScm_VM関係をちゃんとそろえる方がいいのかな?

2003/03/16 18:31:05 PST 戻り値をVARIANTにしようとしたら、C的に基本型じゃない型の場合を綺麗に扱う方法が思いつかなかったので、 ATL路線は中止する事に。

2003/03/17 21:35:21 PST 一応動く所までいった残骸があるのでIDLだけ置いておきます。欲しい人がいれば公開方法は考えますが、 最低でもIDispatchを実装しないと使い道は無いと思う。 本気でやるならどちらにしろVARIANTへの変換をまじめにやらないとダメでしょうけど。IDL

More ...