#・mmap は VirtualAlloc に置き換え
・Windows では存在しないヘッダファイルはコメントアウト
・call-with-process-io は新しい API を使用 (文字列でなくリストで渡す)
・(close-output-port out) の前に (display "\x1A" out)
・gauche-package compile は使わない
#これくらいかな。
#なるほど、ありがとうございます。
#こっちでも試してみます。
#時々、タイトルに未読の数字が出ているのに、iframeの中身が更新されていないことがあるみたい
#あれ、と思ってリロードするとちゃんと新しい発言が表示される
#む? スクロールに失敗してるとかでもなくて?
#違うみたいです
#スクロールバーは一番下の状態で、それをさらに下にドラッグしても表示は変わらない
#Safari4
#debian系(ubuntu)であるファイルがどのパッケージに属してるか調べるのってどうするんだったっけ
#rpmだとrpm -qf fileだったかな。
#どうもパッケージ管理はいまだにrpmの癖が抜けない。
#debian系はよくわからない。
#dpkg -S だったかなぁ
#完全に忘却の彼方
#ああ、man dpkg-queryで出てくるんですね > dpkg -S
#パッケージ管理のいくつかのコマンドの役割分担がまだ把握できてない
#apt-file とか。
#apt-file search mysql.h みたいに使います。
#Gaucheの(schemeno
#schemeのコードから
#mmapを使う方法って今ありませんよね
#c-wrapperで行けます？
#理屈はよくわかんないけど、参考になりそうなページを見付けた。
##一応、(c-load "sys/mman.h") で mmap が呼び出せました。
#適当なパラメータを与えると、それっぽいポインタが返ってきましたが、きちんと振る舞いは確認してないです。
#ありがとうございます。
#ProjectEulerやる時に、１億までの素数をさっとロードしたいとか
#取り急ぎはその程度の用途です
##簡単に言えば、Schemeの言語仕様に2レベル設けようって話です。
#r6rsは実用を目指しましたが、そうすると必然的に仕様は肥大化します。
#仕様が大きくなると便利にはなりますが、検証はしずらくなります。ある処理系を作ったとき、それが本当にrnrsに準拠しているのかどうか、を判断しづらくなるということです。
#多くの言語はそういう罠にはまっていて、エッジケースで処理系の振る舞いが怪しくなることが多いですよね。
#そこで、検証も実装も容易であるというかつてのSchemeの特徴を引き継ぐ"small scheme"と、実用的なライブラリを備える基礎となる"large scheme"の2レベルにわけたらどうか、という話になったわけです。
#r6rsでも、「コア」と「ライブラリ」を分離することである程度そういう方向を目指していたんですが、
#r6rs「コア」が本当に必要にして十分な「コア」かどうかという検討は不十分でした。
#今回の方針の理想的な帰結としては、small schemeが「これ以上弱点を取り除くことができない仕様」としてのコアを目指し、large schemeはsmall schemeによって参照実装される(従って、small schemeの仕様からすべて説明がつく)ってあたりでしょうね。
#ただし、本当にそんなに綺麗に分離できるのか、というのはこれからやってみないとわかりません。
#とりあえず、small schemeとlarge schemeそれぞれにワーキンググループが設けられ、必要な仕様を検討したらどうかね、という話が出てきたって段階です。
#ちょっと訂正。それぞれにワーキンググループを作ったらどうか、って段階ですね。
#なるほど。やはり言語コアという考え方は魅力的なのですかね。
Gauche > Archives > 2009/08/25