言語のコアに関わりそうな所だけでいいのですが。見た所MSWIN32というifdefフラグはあるのですが、VC++のビルドに関するドキュメントが見つけられませんでした。今のところVC++で試したことはありません。誰かがトライしてくれることを期待して別ページを立ててみました。システム関数関係がPOSIXべったりなんでそこを分離させないと難しそうではあります。GCのコードを持って来ていて、その中ではMSWIN32とかMSWINCEとかのフラグは使われていますが、Gaucheのメイン部分(src以下)にはそういうフラグはないはずです。一度も試みたことがないので。MSWINが定義されてたらconfig.hじゃなくてconfig_win32.hを読むとかしておけば良いのかなあ。gcの中だけだったのですか。CEでの前例があるのかとふんでいたのですが。それでは自分で勝手にやってみる事にします。動かすだけならどうにかなりそうですが、ちゃんと移植するのは面倒そうです。thread回りがちょっと骨ですねぇ。variableに関しては一応マクロにしてあります(src/gauche/pthread.hとsrc/gauche/uthread.h)。路線とりあえずコンパイルを通して実行してみる。必要な機能は後から足す。総量見積もる程度のつもりで適当にifdefを足していく。かわらない気もするけど、こちらは実験とか雑感とか。PSTScm_SetMasterSigmaskでは、まずは何も考えずにreturnしてみる事にする。それだとまずそうな部分が結構あるので、後でもっとまともなダミーに差し替える予定そろそろシグナルに関するポリシーを決めなきゃダメかなぁ...LoadFileでgauche-init.scmがロードできない、だそうで。そりゃパスとかいいかげんに設定しているからあたりまえなのだが...シグナル回りはどうすべきか。適当に存在する奴だけ対応、でもちろん移植は完成なのだが、、、パス名区切り文字どうも内部でも/区切りでgaucheはファイル名を持ちたがっているように見える。/等は何かの背後に隠す、というのが正しいのかもしれないけど、綺麗になるだけで面倒さは増す気もするファイルに触る回りだけでなんかフィルタかまして¥に変換してもいいんだけど、ちとカコワルイLoadFile全面書き換えで内部的にも¥区切りで持たせておくのが好みな気がする普通に考えるとWinなのだからレジストリにロードパス等は入れるべきだろう。それが嫌なら.exeのあるフォルダと同じ所に初期化ファイルを置く、とか。特定パスを環境変数で設定させて、それを変更するとでどこでもおっけー、というのはWinっぽく無い気がするでも複数のインタプリタを同居させるならslibのパス等は環境変数で設定したいかもしれない。pathnameに関しては当初抽象化すべきかどうか迷ったのですが、CommonLispのpathnameオブジェクト(えらく立派な仕様で大抵のOSに対応できるようになっている)が、面倒だという印象しかなかったので、思い切って単純にしました。内部ではスラッシュ区切りで統一、システムに渡すところで変換、というのが良いように思います。入力に関してはstring->pathnameみたいなバックスラッシュ区切りが入って来たらスラッシュ区切りに変換するという手続きを用意しておくとか。うーん、やっぱりそっちの方がいいですかねぇ。するとネットワークドライブとかドライブの変更とかそういう事が少し面倒になりそうなのがいまいち乗り気にならない所ですが。個人的にはこういう所はWindowsべったりの方が好みですが、そうするとスクリプト側も変更しなきゃいけなかったり、変更箇所も多くなったりで悩ましい所です。実験ならシステムに渡す所で変換、が一番楽そうなのでそれでいきます。走っているプラットフォームによって区切り文字を切替えてる処理系もあるんですが、そうするとスクリプトの互換性が問題になります。スクリプト内に書かれるリテラルのパス名は統一しとくに越したことはないと思うのです。環境で設定された変数を設定ファイルに書いてあるもので上書きする(さらにコマンドラインからの入力でまた上書きする)というスタイルでやっています。パス文字、ドラッグアンドドロップでファイル名を取るとC:¥から始まってしまうのですが、どうするのがいいですかね?Windowsファイルパスも内部的に扱えるようにするドライブ指定は無条件で取る適当にエンコーディングしてUnixのファイルシステムのように見せるそもそも_openってロングファイルネーム対応だったか知らないのですが。男らしくCreateFileHandleにするべきかなぁ。受け取ったパス名をScm_Loadに渡すところなんかにかませてやるのがいいかなあ。実用上それで困るケースというのはどんなものがあるでしょうか。名前が重なる時位な物だと思いますけどね。実用上、という観点からすれば大して困らないかもしれません。Schemeプログラマにとっては自然かもしれませんが、WindowsのVBプログラマとかからすると奇異に見えるかもしれません。本質的で無い事に手間がかかる恐れがあるかもしれない、と少し危惧してます(具体的に何か思いついている訳ではありませんが)。/gauche_drive/c/とかならC:とかでとりあえずは実装してみるかなぁ。あのー盛り上がってるとこわるいんですがWindowsは/区切りも認識しますよ。変換自体はたいした手間じゃないだろうけど、#ifdefやら変換漏れやらが面倒そう。コンソールWindow作ってメッセージ送信をWindow宛てに行う、とかの方がまだWindowsアプリっぽい気がする。イベントドリブンに直さなきゃいけないけど。コンソールアプリってかっこ悪いから嫌いなんだよなぁ...Windows的に考えるならIActiveScriptを実装してCScriptで実行する、という方が正しい気がする。loopは本来Gaucheのオプショナルな機能ですんで、こだわらなくても良いです(そもそもgoshは「サンプルアプリケーション」なのです)。goshはWindowsではスクリプト実行用と割り切って、インタラクティブなやつは別にWinネイティブなアプリケーションを作っちゃったほうが良いかもしれません。goshをごちゃごちゃにしたくないので。一応、イベントドリブンなアプリでのインタラクティブセッションを作成するベースとして、gauche.listenerというモジュールがあります(lib/gauche/listener.scm)。それがよさそうですね。goshはサンプル、というのを見て考えが変わりました。なんかそれっぽいアプリケーションを作ってみます。PSTarch.hがなぜか良く解らないけど出来てないので適当にdefine。文字列は"undefined_arch_dir"とか適当な名前をつけておく大量の存在しないシグナル系を適当にifdefgetoptやらgetgrgidやらひっかかるので適当によきにはからう。いくつかシグナル系で面倒な物は関数自体をダミーにさしかえてしまう。unwindではまり中。sigsetjmpなんか無いしなぁ。PSTいろいろ適当に定義してsyslib.cとsystem.cを外して他のから参照されているのだけ入れる、という感じで進めるリンクは通ったけど、Scm_SetMasterSigmaskでパニック。PSTstat等やopenを呼んでる所でパス名を変換するarch.hの中身をgauch-ini.scm等がある場所にちゃんとあわせるWinMainから従来のmainを引数適当で呼んでやるmainの中でオプションとか見はじめる前の所でScm_Loadでファイル名直指定してやるここまでで一応動くようになります。これだと途中のデバッグが不可能なので、途中でScm_ErrorやPutzやらいろいろな所でstderrに出力しているのをOutputDebugStringに変更というのが必要だと思います。PSTmain.cは使わない事にしてWinMainでウィンドウを作って、ドラッグアンドドロップがあったらそのファイルをScm_Loadするようにしました以上で動く事は動きます。DllのロードとかThreadとか残っている物はいろいろありますが、Win32APIでゴリゴリ書くのがもうたくさんなので今後は小さい変更をちょろちょろしたら、たぶんATLに進みます。レジストリ使いまくりで皆様お嫌いでしょうから、ここらでこのバージョンは終了、という感じにする予定。問題はどこで公開するか、だけど...パッチでいいかなぁ。パッチにして頂ければこちらに取り込みます。(うちにはビルド環境が無いので確認できないのですが)。直したらどっかに置きます。http://members.tripod.co.jp/k_arino/patch.txtそのうち消すかもしれません。「ヒューメイン・インターフェース」のアイデアに基づいて、エディタ上で動くものとしてインターフェースを改良していくという方向もあるわけで、私はその方向を追及していきたいので。エディタ、というのがWindowsのエディタであるなら、コンソールよりこのバージョンの方が使いやすいと思いますが。curses等を使って何かやるならまずいですが、それならcygwin版の方がメリットがあるはず(シグナルが使えるので)。そもそも最初はemacsもどき(というかxyzzyもどき)を作ろう、としてこの作業が始まったので、エディタに組み込むならここらへんからやるのが良いと私は思ってます(今は違う方向に進んでますが)。コンソールバージョンは今の所私はあんまり作る気はありません。今回のコンセプトはなるべくWindowsべったり、なので。main.cをちょろちょろ書き換えればすぐに動かす事は出来ます。初期の頃はそれでテストしていたので確かです。コードは捨ててしまいましたが。インタラクティブな開発の根っ子はread-eval-printloopにあるわけですが、それがstdioにつながっているというところはあまり本質的ではないと思います。unixではたまたまstdioでコンポーネントを組み合わせるのが楽だったというだけで。stdioがベストとは限らないわけですしね。私はWindowsにあまり触らないのですが、(例えば)COMがWindowsのコンポーネントの組み方のベースにあるならそれを基礎にして、コンソールが欲しければその上に作る、という方向が何かと便利なように思います。抜きでコンソールアプリを利用できればいいかなと考えたその程度です。相互に呼び出して使えるようにした方がいいかも、とだけ言っておきます。IDEか否かによらず、stdioはpoorなProgram間Interfaceなのは確かですね。Object(OOP風に言えば)同士の参照し合いやMethod呼び合いに比べれば貧弱貧弱ぅ。手続きプログラムは、外界との「接点」が1つしかないのが問題です。起動という接点だけ(藁)。unixなstdioモデルはまさにこの問題を抱えてる。filter的プログラムを作る理由はむしろそれのInterfaceが低機能過ぎるから(そのぶん作るのも楽だから)でしかないなぁ俺。コンポモデルの個人的嗜好。)もオプショナルでいいや。いうノリでDelphiのコンポーネントとして実装されてるScript言語エンジンも幾つか有ります。最高だと思うわけですけど。......この話長くなりますね。何をやりたいのかはさっぱり理解してませんが、コンソール版の欲しい理由がcygwinよりも多くの人に試してもらえる、なのなら、自分で作ってしまうのが一番早いと思います。私は多くの人に試してもらいたい、とはあまり思っていないし、main.cをVC++でコンパイルするのに必要な変更なんてたかだか20行位ですし、私がやるよりも何をやるのか理解している人がやる方がよっぽどいい予感。その程度の理由に過ぎないので、絶対に用意してもらいたいというわけではない、ということを書き損ねてましたね。話をぐちゃぐちゃにしてしまってすみません。系のifdefはconfigureに入れるのが正しい?DebugTerm等は実質まだ使われていないevalした結果の表示手段が今の所message-boxしか無いいくつかいいかげんにifdef入れた所があるGC関係は一切テストしていないこの変更を加えた結果、他の環境でコンパイルできなくなってるかもそのほかいろいろ今後の標準的な路線こんな事を書くのは有野は違う方向に進むつもりだからですが。なんらかのターミナル(DebugTerminalでもいいか?)を作るevalした結果はターミナルに出力するようにするウィンドウのメニューからライブラリのパスを指定出来るようにして、結果はiniファイルに吐くその他メニューはもっと充実させるLoadLibraryやCreateThreadにちゃんと対応するターミナルやDebugTerminalをちゃんとSchemeのオブジェクトに対応させるパス名やドライブ名等、そこらへんをきっちり扱うようなユーティリティをそろえる(これはSchemeのレイヤーでいいと思う)という感じでしょうか。どれもそんなに大変では無いと思いますし、そこそこ需要もあるとは思います。ATL版のインターフェースとりあえず実装前に考えておく。Scm_LoadScm_EvalScm_ApplyScm_Compile(?)Scm_ReadFromCString徐々に足していく予定。ここまで来て、Scm_Applyを使いやすくするには、なんかまともに機能するwrite可能なポートが欲しい事に気づく。それを設定してやれば、Scm_Writeでちまちま書いていく、という作戦が取れるので。Scm_MakeSubrのような類の物は含めるべきだろうか?Scm_MakePortWithFdのようなあたりをうまく扱わないと、VMをnewしてもいろいろ使いにくいんだよなぁ。戻り値をVARIANTにしようとしたら、C的に基本型じゃない型の場合を綺麗に扱う方法が思いつかなかったので、ATL路線は中止する事に。一応動く所までいった残骸があるのでIDLだけ置いておきます。最低でもIDispatchを実装しないと使い道は無いと思う。本気でやるならどちらにしろVARIANTへの変換をまじめにやらないとダメでしょうけど。