CommonLisp Scheme Part11 - 暇つぶし2ch

CommonLisp Scheme Pa ..

353:デフォルトの名無しさん
04/09/19 11:07:15
不可能な理由がなかったら可能だよ。

354:& ◆TACpYgPjX6
04/09/19 11:17:07
それがよくわからないんですよ。
だって、OS 側でどんな処理をしているか分からないじゃないですか。

たとえば WM_KEYDOWN ハンドラ内で継続を作成して、
一度そのハンドラを終了して OS に制御を返すでしょ。
そのあと WM_LBUTTONDOWN ハンドラ内で
先ほどの継続を呼び出すと、WM_KEYDOWN メッセージの処理が
再開されるわけですよね。

OS 側でスタック上のデータではない
グローバル変数をいじっていたとすると、
コンテキストがめちゃくちゃになって、
よくない気がするんです。

355:デフォルトの名無しさん
04/09/19 11:26:55
> OS 側でどんな処理をしているか分からない

分からない以上、可能だという確認ができないんじゃないか？

356:ミミ
04/09/19 11:31:53
いえいえ、今の私の知識ではわからないということなんです。
どなたか深い知識をご存知の方はいらっしゃらないかなと思いまして。

357:デフォルトの名無しさん
04/09/19 11:33:02
354の話で使いたい場面と、問題意識が少しわかったので
もう少し整理してから、その問題意識を中心に調べものしたらわかるのではないかな。
イベントハンドラまわりなんだよね。
;;; Windowsのことはよく知らないけど...

358:& ◆TACpYgPjX6
04/09/19 11:36:15
実は Windows 専用 Scheme を作りたいと思っているんです。
特にシステムハックをするためのツールを
Scheme でガンガン作りたいんですよねぇ。

コンセプトは
"Scheme as a better C."
"Scheme as a hacking tool."

359:デフォルトの名無しさん
04/09/19 11:50:34
で？

360:ミミ
04/09/19 11:51:32
協力してくれたらうれしい。
できたら使わせてあげるから。

361:デフォルトの名無しさん
04/09/19 11:54:40
面白そうではあるが，コールバックまで正常動作させようとすると
継続はおろかクロージャさえ厳しいだろうな…

362:& ◆TACpYgPjX6
04/09/19 11:56:17
だいたいですね、Lisp 系の言語って、
どれもこれも Unix っぽいのがよくないと思うんですよ。
Perl や Python も同じなんですけど、
Java はちょっと違う感じ。

Windows みたいな素敵なシステムに、
Scheme みたいな素敵な言語があれば、
みんな幸せだろうなぁ、と思ってさ。

363:ミミ
04/09/19 11:59:09
すいません、どうしてクロージャが難しいのでしょうか。
何も OS が直接クロージャを呼び出すことは期待していないです。
間に C 関数をかませば問題ないですよね？

> 面白そうではあるが，
ありがとう。

364:デフォルトの名無しさん
04/09/19 12:00:52
PythonはMac出身じゃなかったっけ.
まぁ、それはともかく、Unixっぽいってどういうこと？

365:デフォルトの名無しさん
04/09/19 12:13:05
>>363
話の流れからすると，Win32APIを丸々wrapするんじゃなくて，
Cの関数を直接呼び出したりできる機構を用意しようってことだよね?

366:& ◆TACpYgPjX6
04/09/19 12:18:32
一番大きなのは、コンソール (標準入出力) を前提としていること。

あと、いろんな Scheme 処理系をみてみても、
最初にサポートされるライブラリが POSIX ライブラリを移植したものとか、
GNU の readline たら curses たら、
/etc/network の存在を仮定したソケットライブラリとか (Winsock にしてくれ)、
Windows で使うにはほとんどいらないものばっかりあって、
肝心の Windows 用のライブラリがないんですよ。

レジストリアクセスや COM バインディングは必須でしょう。
もちろんウィンドウプログラミングができないとだめ。
(Unix では X がオプションだから困る)

あと、リソースのアクセスとか、シェルサービスへのアクセスとか、
さまざまな Win32 API をオブジェクト指向的にパックしたものとか
Win32 のセキュリティ機構は Unix と大きく異なっているから、
それを無理やり Unix 的に狭めても、使う気になれない。

Scheme だけで DLL を書くとか、サービス書くとか、
スクリーンセーバー書くとか、Scheme だけでデバドラ書くとか。
そんなのができない。

しようとすると、既存の Scheme に拡張機能を実装しないとだめで、
その Scheme 実装系の内部動作から把握しないとだめってことになる。
しかも Scheme 実装系自体が Unix を基盤としているので、
Windows 用に最適化されているわけでもない。

であれば、Windows 専用の Scheme 実装の上に
Windows 専用のライブラリを構築するほうが
ずっといいと思う。

367:デフォルトの名無しさん
04/09/19 12:27:13
うーん、Scheme.NETか？

368:ミミ
04/09/19 12:28:34
>>365
> 話の流れからすると，Win32APIを丸々wrapするんじゃなくて，
> Cの関数を直接呼び出したりできる機構を用意しようってことだよね?

構想としては WIn32 API (というか任意の DLL 関数)
をすべて生で呼び出し可能にしたいとは
思っています (間に多少のサンクは入ってもよし)。

VB の Declare 文みたいに、Scheme ソース上で
宣言するだけで、外部の API を呼び出したいです。

たとえば、
(dll-import MessageBox
((DWORD hwnd)
(WSTR text)
(WSTR caption)
(UINT type))
(alias "MessageBoxW"
stdcall)
)
という感じで宣言して、
呼び出すときは
(MessageBox 'hwnd hwnd
'text "テキスト"
'caption "キャプション"
'type (| MB_OK MB_ICONINFORMATION) )

コールバックの話は、ウィンドウを使いたいために出てきた話です。
ウィンドウを使うには OS からのコールバックとして実装しなくてはならず、
その場合、継続と相性悪くないのかなぁ、とふと思ったのです。

369:デフォルトの名無しさん
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:デフォルトの名無しさん
04/09/19 12:40:07
>>367
だよね。他にもあるかも知れないけど、
.NETFramework をサポートする Scheme を開発するプロジェクト

URLﾘﾝｸ(radio.weblogs.com)
URLﾘﾝｸ(www.cs.indiana.edu)

372:デフォルトの名無しさん
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:デフォルトの名無しさん
04/09/19 13:13:42
おぇ

376:デフォルトの名無しさん
04/09/19 13:17:42
"as a hacking tool"
===> "as a hacking tool"

377:デフォルトの名無しさん
04/09/19 14:24:34
なんでハンドル二つ使って常時ageなんだ？

378:デフォルトの名無しさん
04/09/19 14:34:01
Cからのscheme呼出しの中で補足された継続のエクステントが無制限な処理系ってあるの？
GaucheでもCからのコールバックで補足されたもののエクステントはコールバック内に限定されるし

379:デフォルトの名無しさん
04/09/19 15:02:33
>>363
クロージャが難しいというよりはガーベジコレクションが難しそう．
Schemeで書かれた関数をWin32APIに渡して，コールバック関数として登録したとして，
その関数がいつまで使われるかはSchemeインタプリタ側では判別できないと思う．

380:デフォルトの名無しさん
04/09/19 16:06:22
>>377
1. 2ch が Netscape や Mozilla に対応していない。
2. よって、cookie に書き込まれた全角のハンドル名が化ける。
3. あわててハンドル名を入れなおすと、そのときは正しい名前で掲示板に
　　書き込まれる。
4. 次に書き込むと、またハンドルが化ける。
5. 以下繰り返し。

Netscape, Mozilla ではハンドルは半角英数にするのが吉。

常時 age については分からない。

381:デフォルトの名無しさん
04/09/19 16:13:53
>>380
> >>377
> 常時 age については分からない。
sage を知らない、だろうな。

382:デフォルトの名無しさん
04/09/19 17:31:16
> Windows みたいな素敵なシステムに、
ここんとこに賛同できないのは漏れだけなのか。s/Windows/MacOSX/だったら同意なんだが。

383:デフォルトの名無しさん
04/09/19 17:42:53
その部分は罠と判断した。

384:デフォルトの名無しさん
04/09/19 17:53:10
>>366
> 一番大きなのは、コンソール (標準入出力) を前提としていること。

なにか大きな誤解をしているような。
Schemeって必ずしもトップレベル環境のreader/writerと標準入出力が結びついている
必要はないでしょ。Dr.Schemeとか触ってみれば？ URLﾘﾝｸ(www.drscheme.org)

あとDLLの動的呼び出しそのものはそれほど難しくないと思われ

URLﾘﾝｸ(www.kt.rim.or.jp)
> 共有オブジェクト(Win32ではDLL)を動的にロードし、
> 中の関数をscheme コードから呼び出すことができる。
> さらにコールバック関数をscheme コードで記述できる。

385:デフォルトの名無しさん
04/09/19 22:06:34
DrSchemeって、一応他のエディタで編集してロードすれば、日本語表示できるみたいだな。
例えば、「あ」と言う文字のように二文字目が\と同じコードの場合には「あ\」と、\を余分にくっつけて
\\を\と認識させるという技を使わなくちゃいけないのが面倒だけど。

ランタイムDLLが必要になるがEXEも作れるようだし、俺の中ではDrScheme最強になりつつある。

386:デフォルトの名無しさん
04/09/20 01:04:59
gaucheでhtml解析するときって皆さんどうやってます?
saaxとかつかってます?
それとも自分で解析モジュールを書いちゃいます?

387:デフォルトの名無しさん
04/09/23 02:10:26
やっと cygwin + slib のインスコ完了したよ・・・
なんでこんなに疲れるんだろう

388:デフォルトの名無しさん
04/09/23 11:27:01
>>386 これは? 使ったことないけど。
URLﾘﾝｸ(www.neilvandyke.org)

389:デフォルトの名無しさん
04/09/23 18:33:55
gosh のload-path は add-load-path 以外に方法がないのですか？
毎回指定するの面度印ですけど・・・

390:デフォルトの名無しさん
04/09/23 18:40:08
>>389
command line optionの-I

391:デフォルトの名無しさん
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:デフォルトの名無しさん
04/09/23 20:27:26
>>393
>問題は、ContA を呼び出し後に、コールバック A から呼び出し側に戻って
>しまうことが問題なのですよね。

Scheme の継続って、OS 側のコンテキストすら
捕獲できるほど強力だったか？

根源的に何か勘違いしていないか？

395:& ◆TACpYgPjX6
04/09/23 20:40:39
>>394
実装によってはできますよ。
スタックをすべて記憶する類の実装の場合です。

396:デフォルトの名無しさん
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:デフォルトの名無しさん
04/09/23 21:10:25
いいかげんsageてくんないかなあ・・・

400:デフォルトの名無しさん
04/09/23 21:22:30
こんなことでぐだぐだ言ってないで、さっさと処理系書いてみれ。
コールバックをまたぐ継続が動かないことくらいすぐ分かるよ。

401:ミミ
04/09/23 21:37:21
>> 400
いや、私がいいたかったのは、そうじゃないんですよぉ。。。
おこんないでくださいよぉ。。

402:デフォルトの名無しさん
04/09/23 21:41:42
具体的に「こういう使い方すると非常に便利だから絶対使いたい」というわけでもないのに、
処理系云々の前段階げグダグダいっても意味無いだろ。
実装するにはいろいろ難しい問題があり、汎用的なものにすることは不可能なんだから、
要求が出る前から考えたって良い解法が出るわけがない。
あと、いいかげんsageろ知障。

403:デフォルトの名無しさん
04/09/23 21:43:55
くれぐれもshiroさんとこ行ったりして迷惑かけるなよ

404:デフォルトの名無しさん
04/09/23 21:52:20
汎用的に実装するのはまず無理だろうし，できたとしても
OS側の継続(変な言い方だけど)が戻らないんじゃ意味無し．
が，絶対に無理かと問われると断言できないのが歯痒いというか何というか．

405:ミミ
04/09/23 22:02:04

> 汎用的に実装するのはまず無理だろうし，
うーんと、私はコールバックを超えて継続したいと言っているんではないのですよ。

> OS側の継続(変な言い方だけど)が戻らないんじゃ意味無し
いや、ですから、OS 側の継続を行うのは可能なんですって。。。

> くれぐれもshiroさんとこ行ったりして迷惑かけるなよ
あのう、shiroさんて、誰でしょうか。。。

> あと、いいかげんsageろ知障。
すいません、やっと意味が分かりました。m(_ _)m

406:デフォルトの名無しさん
04/09/23 22:22:17
> コールバック A から OS 側に戻ろうとする直前に、
> あたかも、コールバック B から戻ったように見せかけることができれば、
この時点でOS側の継続は戻ってないと思うんだが

そもそもOSがコールバック関数を呼ぶってのは言わば見せかけであって，
実際にはプロセス間通信なんかが絡んでるの判ってる?

407:デフォルトの名無しさん
04/09/23 22:26:21
>>406
Windows素人は黙ってて欲しいなあ・・・

408:ミミ
04/09/23 22:31:33
>>406
たぶん、私の意図を誤解されています。
実際に OS 側の継続を戻す Scheme 実装系はありますよ。

409:デフォルトの名無しさん
04/09/23 22:33:06
OS のコールバックを跨ぐ事を前提にしているのに、
Scheme 側で生のスタックを使おうとしているのが、
根本的な設計ミスだろ？

普通の Scheme コンパイラで生のスタックを使っていたりするのは、
それが "たまたま" 使えたから。

それを理解せずにスタックに拘る奴は愚かと言う他はない。

410:デフォルトの名無しさん
04/09/23 22:35:34
>>408
> 実際に OS 側の継続を戻す Scheme 実装系はありますよ。

それはどの OS 上のどの実装系？
OS 側のサポートが無い限り setjmp/longjmp 以上のことができるとは思えないんだが。

411:ミミ
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:デフォルトの名無しさん
04/09/23 22:54:28
>私がやりたいのは、いかに継続をコールバックというしがらみから解放させたように
>見せかけるか、という手法なんですよ。
で、そう見せかけるためには、実際にはコールバックをまたぐ必要があるんだろ？

>これほど汎用的に使える手法を"たまたま"と表現することはできないでしょう。
"たまたま" の意味を取り違えているな。
レジスタに 0 をセットのには、たまたま XOR が使えるけど、
123 をセットする為には、どんなにビットをいじくりまわしても
無理。素直にロード命令を使っとけって事。

413:デフォルトの名無しさん
04/09/23 22:55:51
> ですから、私はコールバックをまたぎたいんではないんですって。
まず，「コールバックを跨がなければ問題なく継続を扱える」のは
>>391さんの言う通り問題ない．
>>392の発言はどう読んでも「コールバックを跨ぎたい」という風にしか
読み取れないんだが．
> いかに継続をコールバックというしがらみから解放させたように
> 見せかけるか、
もう少し具体的に書いてくれ．これでは全く意味不明．

414:デフォルトの名無しさん
04/09/23 23:00:38
なんか変なやつが増えた？
具体的には412だけどさ・・・
おねがいだからこれ以上変なスレにしないでね（苦笑

恐らくミミが言ってるのはschemeで擬似的な継続を作ってやりすごそうって事だよな？
その偽の継続と、OS側の本物の継続はかならずしも一致しなくていい。

415:デフォルトの名無しさん
04/09/23 23:03:01
つまりschemeコード上で破綻してなければどんな手段の継続であるうとかまわない、
最終的にプログラムを終了させたときにＯＳ側の継続と一致していれば良い、
って事だと思う。

416:デフォルトの名無しさん
04/09/23 23:05:21
だからコールバックに突入してそのままルートの継続呼び出して戻ってきても、
ＯＳ側の本物の継続はまだコールバックの中、ってこともありえる。

417:デフォルトの名無しさん
04/09/23 23:11:02
>>416
言ってることは分からなくもないが，別に疑似的な継続なんて持ち出さなくても
「コールバックを跨がなければ問題なく継続を扱える」
方法はあるわけで．

418:デフォルトの名無しさん
04/09/23 23:17:24
で，コールバックを跨ぐために疑似的な継続を持ち出してみたものの，
どのみちOS側の継続は戻せないので意味ないじゃん…という感じ．

419:デフォルトの名無しさん
04/09/23 23:19:33
別にOS側の継続戻す必要ないよ

420:デフォルトの名無しさん
04/09/23 23:23:51
おまいらちょっと用語の整理が居るんじゃないか？
おれは理解が追いついていないから何もできんですまんが

421:デフォルトの名無しさん
04/09/23 23:26:00
>>419
WM_* のコールバック中に継続を保存し、それを再開できるとでも？

422:デフォルトの名無しさん
04/09/23 23:29:22
コールバックをまたがないのなら、それは継続ではないし、継続である必要も無い。
全く無意味で非実用的な事態を想定し、無駄に思考時間を消費しているだけ。

423:デフォルトの名無しさん
04/09/23 23:31:10
>>420
ついでにカキコしてる人の整理もな…
どれとどれが同じ人の書き込みなのかさっぱり

424:デフォルトの名無しさん
04/09/23 23:32:44
>>423
「ミミ」以外は区別する必要無い気が

425:デフォルトの名無しさん
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:デフォルトの名無しさん
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:ミミ
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:デフォルトの名無しさん
04/09/24 00:07:16
コールバックの用途が概ね副作用であり、大域的状態変化が伴う事を無視して
スタックだけを取り上げるのはいかがなものかと

429:デフォルトの名無しさん
04/09/24 00:10:13
>>410は無視ですかそうですか

430:デフォルトの名無しさん
04/09/24 00:17:24
410に限らず、都合の悪いレスは無視みたいね
オナニーは一人でやってほしいもんだ

431:デフォルトの名無しさん
04/09/24 00:17:45
>>429
素人さんは、すっこんでろ

432:デフォルトの名無しさん
04/09/24 00:20:10
410は何が知りたいんだろう・・・

433:デフォルトの名無しさん
04/09/24 00:25:59
>>410=429=430
setjmp/longjmpは、別に「OSの機能」で実現されてるわけじゃないぞ？
ほぼレジスタやスタックの操作だけ。
アセンブラというものが使える状況なら基本的にどのOSでも作れる。

434:デフォルトの名無しさん
04/09/24 00:29:04
>>433
だからこそOSを含めて継続の保存/復帰を実現するには、OS側のサポートも必要だろってことだよ。
で、そういう実装があるのなら参考のために是非知りたいということ。

435:デフォルトの名無しさん
04/09/24 00:30:55
>>434
おまえさ、わざと勘違いしてんのか？
つまんねえよ。
話の腰を折るだけのつもりなら消えてくれ。

436:デフォルトの名無しさん
04/09/24 00:35:35
なんか、OSを含めて継続保存とか意味不明なこと言ってるアフォがいるけど、
いつからOS含めた話になったの？

437:デフォルトの名無しさん
04/09/24 00:37:55
>>436
>>408に、「実際に OS 側の継続を戻す Scheme 実装系はありますよ。」とあり、
>>410は、その実装系はなんなのかを知りたいという。
ただそれだけの話なんだが、そんなに分かりづらいか？

438:デフォルトの名無しさん
04/09/24 00:38:21
WindowsプログラマとUNIX BAKA (BAd Knowhow Association)の
間で文化摩擦が発生しています

439:デフォルトの名無しさん
04/09/24 00:42:16
「ＯＳ側の継続」の定義がそれぞれ違うんだろうね。
なんかプロセス間通信とか言ってる馬鹿(=410)が混じってるので
これ以上続けても無駄な気がする。

それでも続けるなら、
ここからは「Windows限定」でどぞ↓

440:デフォルトの名無しさん
04/09/24 00:42:35
なんでそーなるの?
Windows でも X でも、Scheme 的継続はコールバック跨げないよ。

441:デフォルトの名無しさん
04/09/24 00:44:31
>>440
だから話をシンプルにするための処置だよ。
おまえた単にWindows嫌いなだけだろ。
以降「Windows限定」でどぞ↓

442:デフォルトの名無しさん
04/09/24 00:46:44
('A`)

443:デフォルトの名無しさん
04/09/24 00:48:36
そもそもXなんて誰も使わないしUNIX系は無視してもいいと思う。
「ミミ」自体Windowsって言ってるんだし。

444:デフォルトの名無しさん
04/09/24 00:49:15
いや～、やっぱり Scheme は面白いですね。

445:デフォルトの名無しさん
04/09/24 00:50:30
(gc)

446:デフォルトの名無しさん
04/09/24 00:50:58
(exit)

447:デフォルトの名無しさん
04/09/24 00:59:15
UNIX馬鹿の粘着のおかげで横道逸れすぎて話が全然進まなかったな。

448:デフォルトの名無しさん
04/09/24 01:00:04
なんでもいいからさー、実装出してよ。

449:デフォルトの名無しさん
04/09/24 01:10:55
程よく荒れてきたようなので、一つ質問。

例えば、
ContA:[S1][S2][O1][O2][A]

で、[A] から抜けて（[O2][O1]の事は脇に置いておいて）
[S2]に戻るから、これを「継続」って呼んでいるんだよね？

なのに 6.のように
[A] から抜けた後、[S6]に戻る（？）ものを
「継続」って呼んでも良いとでも思っているの？
それは Scheme でいう「継続」とは全く別のものじゃないの？

450:デフォルトの名無しさん
04/09/24 01:30:40
ミミﾀﾝの作る処理系は独自実装なので
そんなコトはどうでもいいのです。

451:デフォルトの名無しさん
04/09/24 01:32:18
別に問題ない。
スタックのどこであろうとschemeコードに制御が移ったのなら、それは立派な継続。
コールバック内外へ飛んだ事を「継続を使うユーザー」が知っていればいい。

452:デフォルトの名無しさん
04/09/24 01:32:59
とりあえず Scheme にやさしい OS をつくろうよ。

453:デフォルトの名無しさん
04/09/24 01:45:21
頭固い人多いね
ま、一人が粘着してるだけかもしらんけど・・

>>449
＞「継続」って呼んでも良いとでも思っているの？
＞「継続」って呼んでも良いとでも思っているの？
＞「継続」って呼んでも良いとでも思っているの？

もうね、君に理解は無理だよ

454:デフォルトの名無しさん
04/09/24 01:55:24
>>453
>もうね、君に理解は無理だよ
いや、それはすなわち規格で規定された動作が
出来なくなってしまうという事を意味すると思ったのだが・・・

ま、確かに俺には理解不能だな。

455:デフォルトの名無しさん
04/09/24 02:26:12
>>454
ミミが定義した偽継続だからそれでいいんだろ。scheme的継続だと思ってはいけない。

456:デフォルトの名無しさん
04/09/24 02:37:43
規格に通らなくなるってわけでもなさそうだけど。
規定された動作って、どの辺の事？>454

457:デフォルトの名無しさん
04/09/24 02:59:31
実装の話もいいけど、
使う側の話もしようぜ？

458:デフォルトの名無しさん
04/09/24 04:27:16
ヒント。partial continuaionについて調べよ。

459:デフォルトの名無しさん
04/09/24 08:17:03
事の発端となった香具師の要件が明確でないのに本人はうやむやにしたまま消えちゃうし、
まるでそれと入れ替わるかのようにいつもは議論になっても出てこないような類のレベルの低い煽りのみを繰り返す香具師が出てくるし、
そんな状態で外野が言い合ってたって全く意味が無く、時間の無駄以外の何者でもないと思う。

460:デフォルトの名無しさん
04/09/24 09:25:41
ミミは夜行性だから夜まで待て

461:デフォルトの名無しさん
04/09/24 13:45:00
話を蒸し返すようで悪いが，「プロセス間通信云々」→「Windows素人は黙ってろ」
の流れの意味が分からない．誰か説明キボン．
例えば，Windowsのウィンドウプロシージャが呼び出される過程は，
・OSからウィンドウの属しているスレッドのメッセージキューに
　メッセージが送られる．(ここでプロセス間通信)
・ウィンドウの属しているスレッドにて，キューからメッセージ取り出し．
・取り出したメッセージを引数にコールバックプロシージャを呼び出す．
こんな感じじゃないの?
明らかにプロセス間通信は絡んでると思うんだけど．

462:デフォルトの名無しさん
04/09/24 15:50:49
URLﾘﾝｸ(www.double.co.nz)

463:デフォルトの名無しさん
04/09/24 16:23:22
>>461
必死に慣れない参考書読んで調べたんだろうけどさ、基本的なことを
まるで理解してないな。
おまえが調べた内容は、ＯＳ側でブラックボックス化してる部分を
ただほじくりかえしただけ。つまり大ハズレもいいとこ。
これはね、まず恥ずかしいことなんだと認識してくれよ？
悦に浸るどころじゃないよ？（ｗ
なんのためにスレッド毎にメッセージキューがあるのかをまずよく考えてね？
Windowsの開発者はメッセージキューの知識だけでプログラミングできるだろ。
あえて「プロセス間通信」を意識して扱う必要なんてないんだよ。
別にＯＳを作るわけじゃないんだから。
つーかプログラム書いた事もなさそうだし、どっか他行って勉強してきて。
もうね、ここで続けられると邪魔だから消えろ。

464:デフォルトの名無しさん
04/09/24 17:38:49
全然素人なんだけど、WindowsってOSの使用するスタック領域と
アプリケーションプロセスの使用するスタック領域は連続しているの？
連続しているからスタックを保存すれば継続が補足できると言う前提で
議論しているみたいだけど、OS側に制御が渡った瞬間、別のプロセス空間の
スタック領域にスイッチする場合、どう考えてもOS側の継続を制御するのは
無理のように思えるけど。。

465:デフォルトの名無しさん
04/09/24 17:59:39
>>464=461
全部間違ってる
もう引退時じゃね？
LISPには柔軟な頭が必要なのよ

466:デフォルトの名無しさん
04/09/24 18:06:09
> ・OSからウィンドウの属しているスレッドのメッセージキューに
> 　メッセージが送られる．(ここでプロセス間通信)

PostMessage,SendMessageは
・他プロセスの場合は最初に該当するスレッドの保有するメッセージキュー領域を
メモリマップドファイルを使って共有し、データ書き込み。
・同一プロセス、他スレッドの場合は受信スレッドのメッセージキューに直接書き込み。
・同一スレッドなら、コールバックの直接呼出し。
こんな感じか？

467:464
04/09/24 18:11:17
一応いっておくけど、461とは別人です。
>>425みてもわかるように、OS側の継続がアプリケーションと
同じスタックに乗っている前提で話してるよね？
違うのかな？

468:デフォルトの名無しさん
04/09/24 18:11:50
>>463
反応するのも馬鹿らしいが，
メッセージキューってのは立派なプロセス/スレッド間通信の一種．
あと，この部分は別にブラックボックスにはなってない．むしろ基礎の基礎．

>>464
> OS側の継続を制御するのは無理
これは正しい．
> スタックを保存すれば継続が補足できると言う前提で議論している
こっちは×．最終的にスタックを元の状態に戻してやれば
Schemeインタプリタ側では好き勝手にいじってもいいよねー，って話．
たぶん．

469:464
04/09/24 18:15:44
>>468
コールバックは常に同一プロセス内から直接呼び出されるのなら、
スタックコピーで制御は戻りそうなんだけど、私が疑問に思ったのは、
コールバックを渡すOS側は同じプロセス空間で動いてないような気が
するんだけど。あてずっぽうですが。

470:デフォルトの名無しさん
04/09/24 18:16:57
>>458
URLﾘﾝｸ(www.google.co.jp)
R5RS partial continuaionに該当するページが見つかりませんでした。
URLﾘﾝｸ(www.google.co.jp)
scheme partial continuaionに該当するページが見つかりませんでした。

>>462
規格とは関係ないみたいよ？
もちろん部分継続も問題ないし。
いったい何を危惧してるのかね。
ちゃんと継続を理解してる人って少ないの？

471:デフォルトの名無しさん
04/09/24 18:19:46
>>464
スレ違いな質問繰り返してんじゃねーよ
デバッガ使って自分で確かめろ
ミミよりｳｻﾞｲ

472:464
04/09/24 18:20:40
Schemeインタプリタ自体は同一プロセス内で動いてるから、
スタックコピーで継続が戻るのは当たり前だと思うけど、
Schemeインタプリタとは異なるプロセスの継続も補足できるの？

473:デフォルトの名無しさん
04/09/24 18:21:27
>>469
メッセージキューにメッセージを置くのはOS側(もちろん違うプロセス空間で動いてる)だけど，
メッセージを取り出すのは自分なので問題ない．というか，別に違うプロセス空間から
呼び出されても問題ないと思うけど．

>>470
ミミがやりたいのは部分継続じゃないの? ってことだと思う．

474:464
04/09/24 18:24:37
>>473
ああ、ここでコールバックって言ってるのは、あくまでも
イベントキューから自分で読み出して関数を呼ぶイベント駆動
プログラミングのことなんだね。
違うものを想像してたよ。

475:デフォルトの名無しさん
04/09/24 18:25:26
＞Schemeインタプリタとは異なるプロセスの継続も補足できるの？
で　き　ま　せ　ん

なあ、その電波な質問はどっからやってくるんだ？

476:464
04/09/24 18:26:20
>>475
言葉のすれ違いと思ってくんなまし。

477:デフォルトの名無しさん
04/09/24 18:26:43
つーか試しもしないで質問ばかりする464は不要な人材

478:ミミ
04/09/24 18:46:38
こんにちは。
昨日は遅くまでありがとうございます。
細かい議論はあるかもしれませんが、
おおまかなアイデアは理解していただけたようですね。

私は部分継続を行いたいのではなくて、
コールバックの検問所を作りたいということです。
図にまとめてみました。

479:ミミ
04/09/24 18:47:08
■従来のコールバックの実装

┌─┐
│ │ ┌──┐
│ │ ┌┘ │
│ CbA├─┘ │
OS │ ├─┐ ContA │
側 │ │ └┐ │
│ │ └──┘
│ │ ┌──┐
│ │ ┌┘ │
│ CbB├─┘ │
│ ├─┐ o--───ここから ContA を呼ぶと
│ │ └┐ │ CbA から出て行ってしまう。
└─┘ └──┘ これは破綻する。

480:ミミ
04/09/24 18:47:28
■検問所式コールバックの実装

┌─┐
│ │
│ │ CbA ┌───┐
│ │ ┌─┘ │
│ ├─┼─┐ ContA │
OS │ │ │ └───┘
側 │ ⇔ │
│ │ │ ┌───┐
│ ├─┼─┘ │
│ │ └─┐ o--─── ここから ContA を呼んでも
│ │ CbB └───┘ OS 側に正しく戻ってくれる。
│ │
└─┘

コールバックは必ず検問所(⇔)を通して呼び出されるし、
検問所を通して戻る。検問所を通して戻るときは、
必要があればスタックの回復を行ってくれる。
したがって、Scheme 側では継続とコールバックの関係を
気にしなくてよい。

481:ミミ
04/09/24 18:49:37
■従来のコールバックの実装

┌─┐
│ │ ┌──┐
│ │ ┌┘ │
│ CbA├─┘ │
OS │ ├─┐ ContA │
側 │ │ └┐ │
│ │ └──┘
│ │ ┌──┐
│ │ ┌┘ │
│ CbB├─┘ │
│ ├─┐ o--───ここから ContA を呼ぶと
│ │ └┐ │ CbA から出て行ってしまう。
└─┘ └──┘ これは破綻する。

482:ミミ
04/09/24 18:50:32
あれれ、うまく表示されませんねぇ。。。

483:ミミ
04/09/24 18:54:26
■従来のコールバックの実装

┌─┐
│ │ ┌──┐
│ │ ┌┘ │
│ CbA├─┘ │
OS │ ├─┐ ContA │
側 │ │ └┐ │
│ │ └──┘
│ │ ┌──┐
│ │ ┌┘ │
│ CbB├─┘ │
│ ├─┐ o--───ここから ContA を呼ぶと
│ │ └┐ │ CbA から出て行ってしまう。
└─┘ └──┘ これは破綻する。

484:デフォルトの名無しさん
04/09/24 18:55:39
もういいよ・・・
なんとなくわかったから

書き込みの練習は専用板があるからそっちでやってくれ
URLﾘﾝｸ(aa5.2ch.net)

485:デフォルトの名無しさん
04/09/24 19:18:16
だから、具体的にどういう場面で使いたいのよ？
それは継続でなければならないのか？

486:デフォルトの名無しさん
04/09/24 19:20:13
UNIXっぽくない用途だって。

487:ミミ
04/09/24 19:31:23
>>485
> だから、具体的にどういう場面で使いたいのよ？

今のところ、特に使い道というものは考えていないです。

コールバックベースの Scheme コードを書く場合、
Gauche のように継続に何らかを制限をつけるという方法もありますが、
検問所方式で常に安全を確保するという方法もあるのでは、
というだけです。

もう少しアイデアを膨らませたら、何か面白いことができるかもしれません。
Scheme 実装を書きながら、おいおい考えたいと思っています。

488:デフォルトの名無しさん
04/09/24 19:35:08
案の定何も考えてないのに非現実的なものを想定して時間を無駄にしてただけかよ
アホくさ

489:ミミ
04/09/24 19:37:58
>>448
そんなことはありませんよ。
どんな小さなアイデアも、大きな発明に結びつく可能性があるって、
どこかの発明家が言っていましたよ。

Windows 専用 Scheme で実現したい機能とかありましたら、
みなさんのご意見もお聞きしたいです。
面白そうだったら実装したいと思います。

490:デフォルトの名無しさん
04/09/24 19:52:13
ＲＳ２３２Ｃに継続ベースで送受信

491:ミミ
04/09/24 19:57:05
> ＲＳ２３２Ｃに継続ベースで送受信

ええ？これはどういうことですか？

492:デフォルトの名無しさん
04/09/24 19:58:21
なぜかここって学習能力のないUNIX知障が常駐してるね。
何故？
ここには何もありませんよ～？

493:デフォルトの名無しさん
04/09/24 20:03:36
「知障」だの「全部間違ってる」だの言うだけで具体的なことを
何一つ言えない威勢のいいやつが一人居るなw

おれ? まあ、おれもそうかな・・・

494:デフォルトの名無しさん
04/09/24 20:09:03
>>489
そういうのは、まずできることをやってから言うもんだよ。
技術的知識やノウハウがなきゃ、せっかくのアイデアもその価値を正しく見極めることができず、
多大な時間とコストをかけて実装したのに実はもっと簡単でいい解法があった、なんてことになりかねない。
そうでなくても、モノが無いのに口先だけの人が好かれやすいとは思えないし。

495:デフォルトの名無しさん
04/09/24 21:00:54
>>494 いいじゃん。いずれ実装が出れば白黒はっきりつくんだしさ。
実装がなきゃ評価できないってんなら黙ってればいい。
漏れは、>>480 で言っているのが部分継続とどう違うのか
よくわからないんで、これ以上はコードで説明してもらいたい
(仮想OSを使ったSchemeコードで構わない) と思うけど。

コールバックで捕まえる継続は、検問所までの部分継続だと
するだけでちゃんと動くんじゃないの、ってことね。

496:デフォルトの名無しさん
04/09/24 21:18:25
>>480
URLﾘﾝｸ(www.ipsj.or.jp)
これがズバリかな?
個人的には，
> Scheme 側では継続とコールバックの関係を気にしなくてよい
とは思えない．
完全な継続とコールバックまでの部分継続が暗黙のうちに
すり替えられるのはこわい…というか，常に意識していなければ危険だと思う．
call/ccとは別の名前で実装するんなら問題ないかな?

>>495
コールバック時に暗黙に行うって所がポイントなんじゃない?
俺は上述のようにデメリットが大きいと思うけどね．

497:デフォルトの名無しさん
04/09/24 22:44:16
キャッチコピーとしては魅力を感じます

498:デフォルトの名無しさん
04/09/24 22:53:39
cygwin で gauche-gl のインストールに成功した人
いませんか？
glut

499:デフォルトの名無しさん
04/09/24 22:56:29
glut 関連の関数が解決できずにmake が失敗します

500:デフォルトの名無しさん
04/09/24 23:09:41
そういや昔glutのインターフェースが無茶苦茶いいかげんな事に
気付いて使う気なくしたんだった。

501:デフォルトの名無しさん
04/09/24 23:20:57
ここを見る限りだと成功している人がいるみたいなんだけど・・・
やり方がわからん
URLﾘﾝｸ(www.kauda.jp)

502:デフォルトの名無しさん
04/09/25 05:41:27
>>499
うちでも普通に入ったけど。
glutはインストールしてある?
標準以外の場所に入ってたら、configureに--with-glut
オプションが必要かも。

503:デフォルトの名無しさん
04/09/25 09:13:43
>>498
成功してます
$ ln -s /usr/include/GL /usr/include/GLUT
$ ./confiugre --without-x
でいけるはず．

504:498
04/09/25 11:28:34
最近のcygwinはGLUTが最初から入っていると
いうことなのでGLUT.hを検索すると色々なディレクトリに
入っていてどこがどこやら・・・
見つかったディレクトリは

c:/cygwin/usr/include/FL
c:/cygwin/usr/include/mingw/GL
c:/cygwin/usr/X11R6/include/GL

GLUTはcygwinのsetup.exeからダウンロードした時点では
まだインストールされていない？のでしょうか

505:デフォルトの名無しさん
04/09/25 12:43:57
>>504
OpenGLパッケージをインストールすれば入ってくるが。

506:デフォルトの名無しさん
04/09/25 18:22:47
こういう話はうまくいったバージョン書いてくれないとダメなんじゃない？
まあcygwinて適当なftpから適当なバージョンのアーカイブ引っ張ってくるから
うまくいく組み合わせの特定ってかなり難しいとは思うけどね。
つまりcygwinで同一環境にするにはインストールログが必要なわけ。
こんなシステムだからcygwinは不安定って言われるのさ。

507:デフォルトの名無しさん
04/09/25 18:53:06
＼　　　∩─ｰ､　　　====
　＼／　●　､_ ｀ヽ　　======
　　/ ＼(　●　 ● |つ
　　|　　 X_入__ノ　ミ　　　そんなエサで俺様がクマ―！！
　　､　(＿／　　　ノ　/⌒l
　　 /＼＿＿＿ノﾞ＿/　 /　　=====
　　〈　　　　　　　　＿_ノ　　====
　　　＼　＼＿　　　　＼
　　　　　＼＿__）　　　　　＼　　　======　　　(´⌒
　　　　　　　　＼　　＿＿_ ＼＿＿　　(´⌒;;(´⌒;;
　　　　　　　　　＼＿＿＿）＿＿＿）(´;;⌒　 (´⌒;;　　ズザザザ
　　　　　　　　　　　　　　　　　　　　　　　(´⌒;　(´⌒;;;

508:498
04/09/25 20:28:31
>>506
色々試行錯誤したんですが、上手くいきませんでした
OpenGLのバージョンを落とさないといけないっぽいことは
わかったのですが・・・
力尽きました

509:デフォルトの名無しさん
04/09/25 23:57:34
なんかcygwinのgaucheって不安定じゃない？
何かすぐにフリーズする

510:デフォルトの名無しさん
04/09/26 00:36:44
coLinuxを使えば?

511:デフォルトの名無しさん
04/09/26 01:14:43
それって解決になってない気が。
それよりVC++やMingwで動かす話があったはずだけど。

512:デフォルトの名無しさん
04/09/26 03:55:19
>>511
gauche-gl の話しでしょ？
もしかして VC++で使えるって話し？

513:デフォルトの名無しさん
04/09/26 04:26:56
511ではないが、cygwinではなくてMingwで動かす話がある。
あまりうまくいっていないようなので、やるなら自分でやった方がよいかも。

514:デフォルトの名無しさん
04/09/26 05:20:39
("root"
("usr" "aaa.txt" "bbb.txt"
("bin" "perl" "ruby" "gosh")
))

ディレクトリ構造をS式で表したいのですが、上のように
「リストの最初にディレクトリ名をおく」というのを考え
ました。もっといい方法ってありますか？

515:デフォルトの名無しさん
04/09/26 05:29:30
carはディレクトリ名、cdrはそのディレクトリの要素、でどう?
cdrは、listだったときはディレクトリ、atomだったらファイル名。

("etc" ; /etc/
　"fstab" ; /etc/fstab
　"passwd" ; /etc/passwd
　("namadb" ; /etc/namedb/
　　"named.conf" ; /etc/namedb/named.conf
　　"named.root")) ; /etc/namedb/named.root

とか

516:515
04/09/26 05:31:02
あ、よくみたら同じことやってる、おれってばか(;´Д`)
もう寝ます…

517:ミミ
04/09/26 06:07:28
>>514
UNIX だけならそれでいいと思う。
Win だとドライブ名がないとだめだね。

("/" "C:" "WinNT" . "Notepad.exe")

絶対パスと相対パスはどう区別するのかな。

次ページ