CommonLisp Scheme Part11

1 名前：デフォルトの名無しさん mailto:sage [04/08/02 23:13] 過去スレ Part1: piza2.2ch.net/tech/kako/987/987169286.html Part2: pc.2ch.net/tech/kako/1002/10025/1002584344.html Part3: pc.2ch.net/tech/kako/1008/10082/1008220265.html Part4: pc.2ch.net/tech/kako/1016/10162/1016211619.html Part5: pc3.2ch.net/tech/kako/1023/10230/1023091882.html Part6: pc3.2ch.net/tech/kako/1031/10315/1031560687.html Part7: ruku.qp.tc/dat2ch/0311/20/1042167213.html Part8: pc2.2ch.net/tech/kako/1058/10582/1058263391.html Part9: pc2.2ch.net/test/read.cgi/tech/1069594582/ Part10: pc5.2ch.net/test/read.cgi/tech/1075630259/ 関連リンクは>>2-10あたり 369 名前：デフォルトの名無しさん mailto:sage [04/09/19 12:34:50] >>366 > であれば、Windows 専用の Scheme 実装の上に > Windows 専用のライブラリを構築するほうが > ずっといいと思う。 そういうことは、既存Scheme処理系をWindowsに移植しようとして 挫折してからいうべきなのではないか。先人の知恵は偉大だよ。 ;;; 挫折というのは移植者の能力不足のことではないよ。 あ、もしかして、scheracy？ 370 名前：& ◆TACpYgPjX6 [04/09/19 12:37:25] >>369 >あ、もしかして、scheracy？ え？ Scheme ヤラシイ？ なんですかそれは。 371 名前：デフォルトの名無しさん mailto:sage [04/09/19 12:40:07] >>367 だよね。他にもあるかも知れないけど、 .NETFramework をサポートする Scheme を開発するプロジェクト ttp://radio.weblogs.com/0101156/stories/2002/03/19/tachy.html ttp://www.cs.indiana.edu/~jgrinbla/index.htm 372 名前：デフォルトの名無しさん mailto:sage [04/09/19 12:45:12] チョット前に出てたハンディスキームじゃダメなのか? 373 名前：ミミ [04/09/19 12:49:18] >>371 情報ありがとうございます。一度よく調べてみます。 うーん、私は .NET 勉強してからしばらくたつので、 いろいろ忘れていますが、.NET ってそんなにいいものですかね？ どうも GUI が重ったるいし、C# も VB.Net もなんかシンプルじゃないし、 .NET ライブラリってあんまり洗練されていないような気がするし (MS的ゴテゴテ)、 いじってたらバグがごろごろ出てきたし (もう直ってるだろうけど) "as a hacking tool" というコンセプトと馴染むでしょうか。 "as a hacking tool" ===> "cool and cute" ですよ？ 374 名前：& ◆TACpYgPjX6 [04/09/19 12:55:32] >>372 > チョット前に出てたハンディスキームじゃダメなのか? むむ！ これ、なんだかよさげですね。 こんなのがあったんですね。 ちょっと今日の宿題にしてみます。 ありがとうございます！ 375 名前：デフォルトの名無しさん mailto:sage [04/09/19 13:13:42] おぇ 376 名前：デフォルトの名無しさん mailto:sage [04/09/19 13:17:42] "as a hacking tool" ===> "as a hacking tool" 377 名前：デフォルトの名無しさん mailto:sage [04/09/19 14:24:34] なんでハンドル二つ使って常時ageなんだ？ 378 名前：デフォルトの名無しさん mailto:sage [04/09/19 14:34:01] Cからのscheme呼出しの中で補足された継続のエクステントが無制限な処理系ってあるの？ GaucheでもCからのコールバックで補足されたもののエクステントはコールバック内に限定されるし 379 名前：デフォルトの名無しさん mailto:sage [04/09/19 15:02:33] >>363 クロージャが難しいというよりはガーベジコレクションが難しそう． Schemeで書かれた関数をWin32APIに渡して，コールバック関数として登録したとして， その関数がいつまで使われるかはSchemeインタプリタ側では判別できないと思う． 380 名前：デフォルトの名無しさん mailto:sage [04/09/19 16:06:22] >>377 1. 2ch が Netscape や Mozilla に対応していない。 2. よって、cookie に書き込まれた全角のハンドル名が化ける。 3. あわててハンドル名を入れなおすと、そのときは正しい名前で掲示板に 　　書き込まれる。 4. 次に書き込むと、またハンドルが化ける。 5. 以下繰り返し。 Netscape, Mozilla ではハンドルは半角英数にするのが吉。 常時 age については分からない。 381 名前：デフォルトの名無しさん mailto:sage [04/09/19 16:13:53] >>380 > >>377 > 常時 age については分からない。 sage を知らない、だろうな。 382 名前：デフォルトの名無しさん mailto:sage [04/09/19 17:31:16] > Windows みたいな素敵なシステムに、 ここんとこに賛同できないのは漏れだけなのか。s/Windows/MacOSX/だったら同意なんだが。 383 名前：デフォルトの名無しさん mailto:sage [04/09/19 17:42:53] その部分は罠と判断した。 384 名前：デフォルトの名無しさん mailto:sage [04/09/19 17:53:10] >>366 > 一番大きなのは、コンソール (標準入出力) を前提としていること。 なにか大きな誤解をしているような。 Schemeって必ずしもトップレベル環境のreader/writerと標準入出力が結びついている 必要はないでしょ。Dr.Schemeとか触ってみれば？ ttp://www.drscheme.org/ あとDLLの動的呼び出しそのものはそれほど難しくないと思われ ttp://www.kt.rim.or.jp/~qfwfq/rhiz-pi/ > 共有オブジェクト(Win32ではDLL)を動的にロードし、 > 中の関数をscheme コードから呼び出すことができる。 > さらにコールバック関数をscheme コードで記述できる。 385 名前：デフォルトの名無しさん mailto:sage [04/09/19 22:06:34] DrSchemeって、一応他のエディタで編集してロードすれば、日本語表示できるみたいだな。 例えば、「あ」と言う文字のように二文字目が\と同じコードの場合には「あ\」と、\を余分にくっつけて \\を\と認識させるという技を使わなくちゃいけないのが面倒だけど。 ランタイムDLLが必要になるがEXEも作れるようだし、俺の中ではDrScheme最強になりつつある。 386 名前：デフォルトの名無しさん mailto:sage [04/09/20 01:04:59] gaucheでhtml解析するときって皆さんどうやってます? saaxとかつかってます? それとも自分で解析モジュールを書いちゃいます? 387 名前：デフォルトの名無しさん mailto:sage [04/09/23 02:10:26] やっと cygwin + slib のインスコ完了したよ・・・ なんでこんなに疲れるんだろう 388 名前：デフォルトの名無しさん mailto:sage [04/09/23 11:27:01] >>386 これは? 使ったことないけど。 www.neilvandyke.org/htmlprag/ 389 名前：デフォルトの名無しさん [04/09/23 18:33:55] gosh のload-path は add-load-path 以外に方法がないのですか？ 毎回指定するの面度印ですけど・・・ 390 名前：デフォルトの名無しさん mailto:sage [04/09/23 18:40:08] >>389 command line optionの-I 391 名前：デフォルトの名無しさん mailto:sage [04/09/23 19:04:22] >>368 継続はコールバックに跨らなければ問題ない。 ハンドラからtoplevelに直接行ったりきたりする様な継続の呼び出しは 不可能ではないけど、コールバックを叩くWindows側で何をしているのかわからんから、 こっちはやらない方が良いとは思う。 ちゃんとコールバックに制御を返却する当てがあるなら、たぶん問題なし。 これに関しては結局セオリーみたいのは見つからなかった。 (deine user32 (loadlib "user32.dll" )) (define DefWindowProc (getproc user32 "DefWindowProcA" __stdcall '(h m w l))) (define handler (make-callback __stdcall (lambda (hwnd msg wparam lparam) (DefWindowProc hwnd msg wparam lparam)))) (define (single-window handler) (make-window handler)) 自作の処理系ではこういう感じで窓を作成する。 make-callbackでクロージャとC関数をブリッジする以外に特別な物はない。 schemeの様に内部定義を許す言語のメリットはここから。 handlerはclosureそのものなので、関数外の局所変数をあえて引数渡しする必要がなく、 C言語だとグローバル変数に移したり関数で分離していた箇所を一つにまとめることができる。 (define (test foo) (make-window (make-callback __stdcall (lambda (hwnd msg wparam lparam) (display foo) ;; ハンドラ外の変数の参照 (DefWindowProc hwnd msg wparam lparam)) この辺の自由度はC言語と比べると比較にならない。（gccはExtensionで関数内関数が 使えるんだけど制限が多く、schemeの様に内関数同士の再帰やコールバック関数にできない。） ただね、いまんとここれ使って何がしたいって訳でもないので、そのまま放置状態。 とにかく機構そのものより、ラッパとか書くのが面倒すぎて、型変換も適当。 392 名前：& ◆TACpYgPjX6 [04/09/23 19:48:16] >>391 > 継続はコールバックに跨らなければ問題ない。 > ちゃんとコールバックに制御を返却する当てがあるなら、たぶん問題なし。 > これに関しては結局セオリーみたいのは見つからなかった。 OS から コールバック A が呼ばれ、そこで継続 ContA を作成して、 トップレベルに束縛したとします。 次に、OS から別のコールバック B が呼ばれ、そこから ContA を呼び出すとします。 ContA を呼び出した直後は別に問題は発生しませんよね。 問題は、ContA を呼び出し後に、コールバック A から呼び出し側に戻って しまうことが問題なのですよね。 であれば、コールバック A から OS 側に戻ろうとする直前に、 あたかも、コールバック B から戻ったように見せかけることができれば、 いい感じがしませんか？ 393 名前：ミミ [04/09/23 19:48:51] 具体的な実装方法は、コールバック クロージャ B の サンクとなる C 関数において、 コールバック開始時の継続をキャプチャしておきます。 また、「コールバック B のコンテキストである」という記録を g_callbackContext グローバル変数に保持しておきます。 ここで、コールバック クロージャ A のサンクとなる C 関数から OS 側に戻ろうとするとき、g_callbackContext を確認し、 それがコールバック A のコンテキストであれば、 そのまま OS 側に戻ります。 コールバック A のコンテキストでなければ、 そのコンテキストに対応する継続 (コールバック B 開始時にキャプチャしたもの) を呼び出すことで、コールバック B のコンテキストを回復した上で OS 側に戻ります。 少し問題なのは、コールバックの戻り値をどのように決定するかですが。。。 394 名前：デフォルトの名無しさん mailto:sage [04/09/23 20:27:26] >>393 >問題は、ContA を呼び出し後に、コールバック A から呼び出し側に戻って >しまうことが問題なのですよね。 Scheme の継続って、OS 側のコンテキストすら 捕獲できるほど強力だったか？ 根源的に何か勘違いしていないか？ 395 名前：& ◆TACpYgPjX6 [04/09/23 20:40:39] >>394 実装によってはできますよ。 スタックをすべて記憶する類の実装の場合です。 396 名前：デフォルトの名無しさん mailto:sage [04/09/23 20:48:45] なんでそんなに継続にこだわってるんだ？ コールバックの中で補足した継続にそこまで意味があるとは思えないんだが。 具体的にどういう使いかたを想定しているの？ 397 名前：ミミ [04/09/23 21:06:20] いやー、コールバック ベースではない普通の Scheme コードの場合 (C でいう main() プログラム)、継続はどこで作成されたものであっても 自由に使えますよね。 でも、コールバック ベースの Scheme コードの場合 (C でいう WinMain() プログラム)、その継続がどのコールバック内 (「どの」というのは空間および時間で区別しなければならない) で呼び出されたかを覚えていないとだめですよね。 継続を１つのコールバック内に閉じ込めて使用しなければならないという この窮屈さを解消したいだけなのですけど。。。 398 名前：ミミ [04/09/23 21:07:40] すいません、間違い。 × で呼び出されたかを覚えていないとだめですよね。 ○ で作成されたかを覚えていないとだめですよね。 399 名前：デフォルトの名無しさん mailto:sage [04/09/23 21:10:25] いいかげんsageてくんないかなあ・・・ 400 名前：デフォルトの名無しさん mailto:sage [04/09/23 21:22:30] こんなことでぐだぐだ言ってないで、さっさと処理系書いてみれ。 コールバックをまたぐ継続が動かないことくらいすぐ分かるよ。 401 名前：ミミ [04/09/23 21:37:21] >> 400 いや、私がいいたかったのは、そうじゃないんですよぉ。。。 おこんないでくださいよぉ。。 402 名前：デフォルトの名無しさん mailto:sage [04/09/23 21:41:42] 具体的に 「こういう使い方すると非常に便利だから絶対使いたい」 というわけでもないのに、 処理系云々の前段階げグダグダいっても意味無いだろ。 実装するにはいろいろ難しい問題があり、汎用的なものにすることは不可能なんだから、 要求が出る前から考えたって良い解法が出るわけがない。 あと、いいかげんsageろ知障。 403 名前：デフォルトの名無しさん mailto:sage [04/09/23 21:43:55] くれぐれもshiroさんとこ行ったりして迷惑かけるなよ 404 名前：デフォルトの名無しさん mailto:sage [04/09/23 21:52:20] 汎用的に実装するのはまず無理だろうし，できたとしても OS側の継続(変な言い方だけど)が戻らないんじゃ意味無し． が，絶対に無理かと問われると断言できないのが歯痒いというか何というか． 405 名前：ミミ mailto:sage [04/09/23 22:02:04] > 汎用的に実装するのはまず無理だろうし， うーんと、私はコールバックを超えて継続したいと言っているんではないのですよ。 > OS側の継続(変な言い方だけど)が戻らないんじゃ意味無し いや、ですから、OS 側の継続を行うのは可能なんですって。。。 > くれぐれもshiroさんとこ行ったりして迷惑かけるなよ あのう、shiroさんて、誰でしょうか。。。 > あと、いいかげんsageろ知障。 すいません、やっと意味が分かりました。m(_ _)m 406 名前：デフォルトの名無しさん mailto:sage [04/09/23 22:22:17] > コールバック A から OS 側に戻ろうとする直前に、 > あたかも、コールバック B から戻ったように見せかけることができれば、 この時点でOS側の継続は戻ってないと思うんだが そもそもOSがコールバック関数を呼ぶってのは言わば見せかけであって， 実際にはプロセス間通信なんかが絡んでるの判ってる? 407 名前：デフォルトの名無しさん mailto:sage [04/09/23 22:26:21] >>406 Windows素人は黙ってて欲しいなあ・・・ 408 名前：ミミ mailto:sage [04/09/23 22:31:33] >>406 たぶん、私の意図を誤解されています。 実際に OS 側の継続を戻す Scheme 実装系はありますよ。 409 名前：デフォルトの名無しさん mailto:sage [04/09/23 22:33:06] OS のコールバックを跨ぐ事を前提にしているのに、 Scheme 側で生のスタックを使おうとしているのが、 根本的な設計ミスだろ？ 普通の Scheme コンパイラで生のスタックを使っていたりするのは、 それが "たまたま" 使えたから。 それを理解せずにスタックに拘る奴は愚かと言う他はない。 410 名前：デフォルトの名無しさん mailto:sage [04/09/23 22:35:34] >>408 > 実際に OS 側の継続を戻す Scheme 実装系はありますよ。 それはどの OS 上のどの実装系？ OS 側のサポートが無い限り setjmp/longjmp 以上のことができるとは思えないんだが。 411 名前：ミミ mailto:sage [04/09/23 22:45:10] > 409 > OS のコールバックを跨ぐ事を前提にしているのに、 ですから、私はコールバックをまたぎたいんではないんですって。 コールバックをまたぐことはできないことは、最初っから分かっているんですよ。 私がやりたいのは、いかに継続をコールバックというしがらみから解放させたように 見せかけるか、という手法なんですよ。 > 普通の Scheme コンパイラで生のスタックを使っていたりするのは、 > それが "たまたま" 使えたから。 > それを理解せずにスタックに拘る奴は愚かと言う他はない。 スタックを記録するタイプの実装を行っている SCM は、 Mac, Win, Linux, BSD, Solaris, AIX, HP-UX, OS/2, DOS, Amiga, Atari など多くの OS に移植されています。 これほど汎用的に使える手法を"たまたま"と表現することはできないでしょう。 412 名前：デフォルトの名無しさん mailto:sage [04/09/23 22:54:28] >私がやりたいのは、いかに継続をコールバックというしがらみから解放させたように >見せかけるか、という手法なんですよ。 で、そう見せかけるためには、実際にはコールバックをまたぐ必要があるんだろ？ >これほど汎用的に使える手法を"たまたま"と表現することはできないでしょう。 "たまたま" の意味を取り違えているな。 レジスタに 0 をセットのには、たまたま XOR が使えるけど、 123 をセットする為には、どんなにビットをいじくりまわしても 無理。素直にロード命令を使っとけって事。 413 名前：デフォルトの名無しさん mailto:sage [04/09/23 22:55:51] > ですから、私はコールバックをまたぎたいんではないんですって。 まず，「コールバックを跨がなければ問題なく継続を扱える」のは >>391さんの言う通り問題ない． >>392の発言はどう読んでも「コールバックを跨ぎたい」という風にしか 読み取れないんだが． > いかに継続をコールバックというしがらみから解放させたように > 見せかけるか、 もう少し具体的に書いてくれ．これでは全く意味不明． 414 名前：デフォルトの名無しさん mailto:sage [04/09/23 23:00:38] なんか変なやつが増えた？ 具体的には412だけどさ・・・ おねがいだからこれ以上変なスレにしないでね（苦笑 恐らくミミが言ってるのはschemeで擬似的な継続を作ってやりすごそうって事だよな？ その偽の継続と、OS側の本物の継続はかならずしも一致しなくていい。 415 名前：デフォルトの名無しさん mailto:sage [04/09/23 23:03:01] つまりschemeコード上で破綻してなければどんな手段の継続であるうとかまわない、 最終的にプログラムを終了させたときにＯＳ側の継続と一致していれば良い、 って事だと思う。 416 名前：デフォルトの名無しさん mailto:sage [04/09/23 23:05:21] だからコールバックに突入してそのままルートの継続呼び出して戻ってきても、 ＯＳ側の本物の継続はまだコールバックの中、ってこともありえる。 417 名前：デフォルトの名無しさん mailto:sage [04/09/23 23:11:02] >>416 言ってることは分からなくもないが，別に疑似的な継続なんて持ち出さなくても 「コールバックを跨がなければ問題なく継続を扱える」 方法はあるわけで． 418 名前：デフォルトの名無しさん mailto:sage [04/09/23 23:17:24] で，コールバックを跨ぐために疑似的な継続を持ち出してみたものの， どのみちOS側の継続は戻せないので意味ないじゃん…という感じ． 419 名前：デフォルトの名無しさん mailto:sage [04/09/23 23:19:33] 別にOS側の継続戻す必要ないよ 420 名前：デフォルトの名無しさん mailto:sage [04/09/23 23:23:51] おまいらちょっと用語の整理が居るんじゃないか？ おれは理解が追いついていないから何もできんですまんが 421 名前：デフォルトの名無しさん mailto:sage [04/09/23 23:26:00] >>419 WM_* のコールバック中に継続を保存し、それを再開できるとでも？ 422 名前：デフォルトの名無しさん mailto:sage [04/09/23 23:29:22] コールバックをまたがないのなら、それは継続ではないし、継続である必要も無い。 全く無意味で非実用的な事態を想定し、無駄に思考時間を消費しているだけ。 423 名前：デフォルトの名無しさん mailto:sage [04/09/23 23:31:10] >>420 ついでにカキコしてる人の整理もな… どれとどれが同じ人の書き込みなのかさっぱり 424 名前：デフォルトの名無しさん mailto:sage [04/09/23 23:32:44] >>423 「ミミ」以外は区別する必要無い気が 425 名前：デフォルトの名無しさん mailto:sage [04/09/23 23:54:40] >>392 を図示してみた。間違っていたら指摘してくれ。 注)[Sn]:Scheme で使うスタック要素, [On]:OS で使うスタック要素 1. >OS から コールバック A が呼ばれ、 スタック:[S1][S2][O1][O2][A] 2. >そこで継続 ContA を作成して、 >トップレベルに束縛したとします。 スタック:[S1][S2][O1][O2][A] ContA:[S1][S2][O1][O2][A] 3. >次に、OS から別のコールバック B が呼ばれ、 スタック:[S3][S4][S5][S6][O3][O4][O5][O6][B] ContA:[S1][S2][O1][O2][A] 426 名前：デフォルトの名無しさん mailto:sage [04/09/23 23:55:07] 4. >そこから ContA を呼び出すとします。 >ContA を呼び出した直後は別に問題は発生しませんよね。 スタック:[S1][S2][O1][O2][A] 5. >問題は、ContA を呼び出し後に、コールバック A から呼び出し側に戻って >しまうことが問題なのですよね。 スタック:[S1][S2][O1][O2] <-これが問題。本来なら[O6]に戻るべき。 6. >であれば、コールバック A から OS 側に戻ろうとする直前に、 >あたかも、コールバック B から戻ったように見せかけることができれば、 >いい感じがしませんか？ 3.から4.に遷移する時に スタック:[S3][S4][S5][S6][O3][O4][O5][O6][A] となればいい、って事か？ 427 名前：ミミ mailto:sage [04/09/24 00:07:07] >>415 >>416 私の意図を汲み取ってくれています。 ありがとうございます。 >>425 >>426 最後の 6 だけ私の意図とは違います。 > 3.から4.に遷移する時に > スタック:[S3][S4][S5][S6][O3][O4][O5][O6][A] > となればいい、って事か？ のではなくって、 継続 A へ飛んだあと、 コールバックを終了して OS 側に戻る直前に、 スタック:[S3][S4][S5][S6][O3][O4][O5][O6] となるということです。 したがって、これを行うのは、 コールバック A の C サンクの中です。 428 名前：デフォルトの名無しさん mailto:sage [04/09/24 00:07:16] コールバックの用途が概ね副作用であり、大域的状態変化が伴う事を無視して スタックだけを取り上げるのはいかがなものかと 429 名前：デフォルトの名無しさん mailto:sage [04/09/24 00:10:13] >>410は無視ですかそうですか 430 名前：デフォルトの名無しさん mailto:sage [04/09/24 00:17:24] 410に限らず、都合の悪いレスは無視みたいね オナニーは一人でやってほしいもんだ 431 名前：デフォルトの名無しさん mailto:sage [04/09/24 00:17:45] >>429 素人さんは、すっこんでろ 432 名前：デフォルトの名無しさん mailto:sage [04/09/24 00:20:10] 410は何が知りたいんだろう・・・ 433 名前：デフォルトの名無しさん mailto:sage [04/09/24 00:25:59] >>410=429=430 setjmp/longjmpは、別に「OSの機能」で実現されてるわけじゃないぞ？ ほぼレジスタやスタックの操作だけ。 アセンブラというものが使える状況なら基本的にどのOSでも作れる。 434 名前：デフォルトの名無しさん mailto:sage [04/09/24 00:29:04] >>433 だからこそOSを含めて継続の保存/復帰を実現するには、OS側のサポートも必要だろってことだよ。 で、そういう実装があるのなら参考のために是非知りたいということ。 435 名前：デフォルトの名無しさん mailto:sage [04/09/24 00:30:55] >>434 おまえさ、わざと勘違いしてんのか？ つまんねえよ。 話の腰を折るだけのつもりなら消えてくれ。 436 名前：デフォルトの名無しさん mailto:sage [04/09/24 00:35:35] なんか、OSを含めて継続保存とか意味不明なこと言ってるアフォがいるけど、 いつからOS含めた話になったの？ 437 名前：デフォルトの名無しさん mailto:sage [04/09/24 00:37:55] >>436 >>408に、「実際に OS 側の継続を戻す Scheme 実装系はありますよ。」とあり、 >>410は、その実装系はなんなのかを知りたいという。 ただそれだけの話なんだが、そんなに分かりづらいか？ 438 名前：デフォルトの名無しさん mailto:sage [04/09/24 00:38:21] WindowsプログラマとUNIX BAKA (BAd Knowhow Association)の 間で文化摩擦が発生しています 439 名前：デフォルトの名無しさん mailto:sage [04/09/24 00:42:16] 「ＯＳ側の継続」の定義がそれぞれ違うんだろうね。 なんかプロセス間通信とか言ってる馬鹿(=410)が混じってるので これ以上続けても無駄な気がする。 それでも続けるなら、 ここからは「Windows限定」でどぞ↓ 440 名前：デフォルトの名無しさん mailto:sage [04/09/24 00:42:35] なんでそーなるの? Windows でも X でも、Scheme 的継続はコールバック跨げないよ。 441 名前：デフォルトの名無しさん mailto:sage [04/09/24 00:44:31] >>440 だから話をシンプルにするための処置だよ。 おまえた単にWindows嫌いなだけだろ。 以降「Windows限定」でどぞ↓ 442 名前：デフォルトの名無しさん mailto:sage [04/09/24 00:46:44] ('A`) 443 名前：デフォルトの名無しさん mailto:sage [04/09/24 00:48:36] そもそもXなんて誰も使わないしUNIX系は無視してもいいと思う。 「ミミ」自体Windowsって言ってるんだし。 444 名前：デフォルトの名無しさん mailto:sage [04/09/24 00:49:15] いや〜、やっぱり Scheme は面白いですね。 445 名前：デフォルトの名無しさん mailto:sage [04/09/24 00:50:30] (gc) 446 名前：デフォルトの名無しさん mailto:sage [04/09/24 00:50:58] (exit) 447 名前：デフォルトの名無しさん mailto:sage [04/09/24 00:59:15] UNIX馬鹿の粘着のおかげで横道逸れすぎて話が全然進まなかったな。 448 名前：デフォルトの名無しさん mailto:sage [04/09/24 01:00:04] なんでもいいからさー、実装出してよ。 449 名前：デフォルトの名無しさん mailto:sage [04/09/24 01:10:55] 程よく荒れてきたようなので、一つ質問。 例えば、 ContA:[S1][S2][O1][O2][A] で、[A] から抜けて（[O2][O1]の事は脇に置いておいて） [S2]に戻るから、これを「継続」って呼んでいるんだよね？ なのに 6.のように [A] から抜けた後、[S6]に戻る（？）ものを 「継続」って呼んでも良いとでも思っているの？ それは Scheme でいう「継続」とは全く別のものじゃないの？ 450 名前：デフォルトの名無しさん mailto:sage [04/09/24 01:30:40] ミミﾀﾝの作る処理系は独自実装なので そんなコトはどうでもいいのです。 451 名前：デフォルトの名無しさん mailto:sage [04/09/24 01:32:18] 別に問題ない。 スタックのどこであろうとschemeコードに制御が移ったのなら、それは立派な継続。 コールバック内外へ飛んだ事を「継続を使うユーザー」が知っていればいい。 452 名前：デフォルトの名無しさん mailto:sage [04/09/24 01:32:59] とりあえず Scheme にやさしい OS をつくろうよ。 453 名前：デフォルトの名無しさん mailto:sage [04/09/24 01:45:21] 頭固い人多いね ま、一人が粘着してるだけかもしらんけど・・ >>449 ＞「継続」って呼んでも良いとでも思っているの？ ＞「継続」って呼んでも良いとでも思っているの？ ＞「継続」って呼んでも良いとでも思っているの？ もうね、君に理解は無理だよ 454 名前：デフォルトの名無しさん mailto:sage [04/09/24 01:55:24] >>453 >もうね、君に理解は無理だよ いや、それはすなわち規格で規定された動作が 出来なくなってしまうという事を意味すると思ったのだが・・・ ま、確かに俺には理解不能だな。 455 名前：デフォルトの名無しさん mailto:sage [04/09/24 02:26:12] >>454 ミミが定義した偽継続だからそれでいいんだろ。scheme的継続だと思ってはいけない。 456 名前：デフォルトの名無しさん mailto:sage [04/09/24 02:37:43] 規格に通らなくなるってわけでもなさそうだけど。 規定された動作って、どの辺の事？>454 457 名前：デフォルトの名無しさん mailto:sage [04/09/24 02:59:31] 実装の話もいいけど、 使う側の話もしようぜ？ 458 名前：デフォルトの名無しさん mailto:sage [04/09/24 04:27:16] ヒント。partial continuaionについて調べよ。 459 名前：デフォルトの名無しさん mailto:sage [04/09/24 08:17:03] 事の発端となった香具師の要件が明確でないのに本人はうやむやにしたまま消えちゃうし、 まるでそれと入れ替わるかのようにいつもは議論になっても出てこないような類のレベルの低い煽りのみを繰り返す香具師が出てくるし、 そんな状態で外野が言い合ってたって全く意味が無く、時間の無駄以外の何者でもないと思う。 460 名前：デフォルトの名無しさん mailto:sage [04/09/24 09:25:41] ミミは夜行性だから夜まで待て 461 名前：デフォルトの名無しさん mailto:sage [04/09/24 13:45:00] 話を蒸し返すようで悪いが，「プロセス間通信云々」→「Windows素人は黙ってろ」 の流れの意味が分からない．誰か説明キボン． 例えば，Windowsのウィンドウプロシージャが呼び出される過程は， ・OSからウィンドウの属しているスレッドのメッセージキューに 　メッセージが送られる．(ここでプロセス間通信) ・ウィンドウの属しているスレッドにて，キューからメッセージ取り出し． ・取り出したメッセージを引数にコールバックプロシージャを呼び出す． こんな感じじゃないの? 明らかにプロセス間通信は絡んでると思うんだけど． 462 名前：デフォルトの名無しさん mailto:sage [04/09/24 15:50:49] www.double.co.nz/scheme/partial-continuations/partial-continuations.html 463 名前：デフォルトの名無しさん mailto:sage [04/09/24 16:23:22] >>461 必死に慣れない参考書読んで調べたんだろうけどさ、基本的なことを まるで理解してないな。 おまえが調べた内容は、ＯＳ側でブラックボックス化してる部分を ただほじくりかえしただけ。つまり大ハズレもいいとこ。 これはね、まず恥ずかしいことなんだと認識してくれよ？ 悦に浸るどころじゃないよ？（ｗ なんのためにスレッド毎にメッセージキューがあるのかをまずよく考えてね？ Windowsの開発者はメッセージキューの知識だけでプログラミングできるだろ。 あえて「プロセス間通信」を意識して扱う必要なんてないんだよ。 別にＯＳを作るわけじゃないんだから。 つーかプログラム書いた事もなさそうだし、どっか他行って勉強してきて。 もうね、ここで続けられると邪魔だから消えろ。 464 名前：デフォルトの名無しさん mailto:sage [04/09/24 17:38:49] 全然素人なんだけど、WindowsってOSの使用するスタック領域と アプリケーションプロセスの使用するスタック領域は連続しているの？ 連続しているからスタックを保存すれば継続が補足できると言う前提で 議論しているみたいだけど、OS側に制御が渡った瞬間、別のプロセス空間の スタック領域にスイッチする場合、どう考えてもOS側の継続を制御するのは 無理のように思えるけど。。 465 名前：デフォルトの名無しさん [04/09/24 17:59:39] >>464=461 全部間違ってる もう引退時じゃね？ LISPには柔軟な頭が必要なのよ 466 名前：デフォルトの名無しさん mailto:sage [04/09/24 18:06:09] > ・OSからウィンドウの属しているスレッドのメッセージキューに > 　メッセージが送られる．(ここでプロセス間通信) PostMessage,SendMessageは ・他プロセスの場合は最初に該当するスレッドの保有するメッセージキュー領域を メモリマップドファイルを使って共有し、データ書き込み。 ・同一プロセス、他スレッドの場合は受信スレッドのメッセージキューに直接書き込み。 ・同一スレッドなら、コールバックの直接呼出し。 こんな感じか？ 467 名前：464 mailto:sage [04/09/24 18:11:17] 一応いっておくけど、461とは別人です。 >>425みてもわかるように、OS側の継続がアプリケーションと 同じスタックに乗っている前提で話してるよね？ 違うのかな？ 468 名前：デフォルトの名無しさん mailto:sage [04/09/24 18:11:50] >>463 反応するのも馬鹿らしいが， メッセージキューってのは立派なプロセス/スレッド間通信の一種． あと，この部分は別にブラックボックスにはなってない．むしろ基礎の基礎． >>464 > OS側の継続を制御するのは無理 これは正しい． > スタックを保存すれば継続が補足できると言う前提で議論している こっちは×．最終的にスタックを元の状態に戻してやれば Schemeインタプリタ側では好き勝手にいじってもいいよねー，って話． たぶん． 469 名前：464 mailto:sage [04/09/24 18:15:44] >>468 コールバックは常に同一プロセス内から直接呼び出されるのなら、 スタックコピーで制御は戻りそうなんだけど、私が疑問に思ったのは、 コールバックを渡すOS側は同じプロセス空間で動いてないような気が するんだけど。あてずっぽうですが。

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef