Edit History:Diff
Changes of hira since 2004/03/08 02:44:36 UTC
- + added lines
- - deleted lines
Return to the edit history
平内です。
Java屋でした。Javaの言語以外の部分が好きだった。いい夢見させてもらったなぁ。
+ - [http://sourceforge.jp/projects/kisp/ Kisp]: (こっそりと公開。まだなんも動いてないです。メーリングリストに参加していただけると嬉しいです)
+ -- s/ツール郡/ツール群/
+ --- hira: 報告ありがとうございます。直しておきました。
+ -- 20040528-proposal/Kisp-Detail.txtの(年齢 * 10万 = 26万)はちょっとサバ読みすぎのような…
+ --- hira: ばぶー。やっぱり見つけちゃいましたか(笑)。それ気付いてたんですけど、タイムスタンプを変えるのが名残惜しくてそのままにしちゃったんですよね(2004/05/28/15:56)。でもCVSからとってくるとタイムスタンプが壊れちゃうから、意味無いし。やっぱり直しておきます。
+ -- バブー(ども)。またまたつまんないことで申し訳ないですが、s/simgle/single/gですよね？test/の_rule-compiler.scmと040726-test-kisp.rule-compiler.scm。てっきり知らない単語かと思って辞書引いちゃいました。(2004/08/26 10:33:35 PDT)
+ --- hira: ご指摘ありがとうございます。直しておきました。04726-*の方はスナップショットなので放って置くことにします。(2004/08/26 14:03:22 PDT)
+ --- hira: そうか。「simple + single = simgle」だったのか(違
+
+ - はてなダイアリー http://d.hatena.ne.jp/hirau
+
+ [[$$toc]]
+
+ * 作ったモノ
+ [[hira:作ったモノ]]へ引越しました
+
+ * 質問箱
+ [[hira:質問箱]]へ引越しました
+
+ * その他
+ [[Scheme:ある日のプログラミング風景]]
+
* hogeとワタシ
- Schemeとワタシ
-- 2000年頃、Scheme本を読んで「こいつぁ一生つきあえる言語だ！」と確信する。
-- 実用に足る処理系を探しつつ、Scheme(Lisp)本を買いあさる。
-- Gaucheを見て「こいつは一生つきあえる処理系かも？」と思う。
-- ヒマが手に入ったので、一気にSchemeをモノにしようと修行に励んでいる。
- Javaとワタシ
-- ２番目に読んだ技術書が「Java言語入門 ローラ・リメイ著」（初めて読んだ技術書？は「コの業界のオキテ」）
-- 初めてプログラマーとして入った会社が、組込JavaOSを作ってるアツい所だった。
-- Javaには色々文句あるけど、他人にJavaの悪口を言われると、つい凹でしまう。
- プログラミングとワタシ
-- ゲーム作りたいなー。じゃあ、プログラマーになるか。という訳でなったらしい。
-- ゲーム製作は人工知能を組むところで挫折。Schemeをモノにしたら再開しよう。
- * portapi実験場
- 今日はportapi.cの宿題を片付けようと、一日中Makefileをイジクリまわしていた。
- 結局./libgauche_*.dllを最適化戦略の数だけ作り、./gosh -ftest io_bench.scmする前に./libgauche.dllにmvすることにした。
- {{{
- text data bss dec hex filename
- 463508 62132 37584 563224 89818 libgauche_0.dll
- 464052 62132 37584 563768 89a38 libgauche_0i.dll
- 474132 62132 37584 573848 8c198 libgauche_org.dll
- -------------------------------------------------------------------------------
- arc i686-pc-cygwin
- thread-type none
+ ----
- strategy real user system process
- 0 35.01 12.99 19.46 32.46 #全体をSAFE_CALLで囲む
- 0i 41.37 12.54 25.73 38.27 #全体をSAFE_CALLで囲む(インライン展開)
- org 34.20 11.84 19.61 31.45 #オリジナル
- }}}
- インライン展開がこんなに遅いとは。。。なんでやろ？(2004/03/05 07:24:27 PST)
+ * hira:log
- - [[Shiro]]: CVS版はポートロックの度にsigprocmaskを呼ばないように
- なっています。結構差が出るみたいなんで、それを加味して試してみて
- 下さい。src/gauche/vm.hだけ直しても差が出るかも。
- - [[hira]]: やってみました。体感速度が上がりましたね。適用前のと比べると、userがちょい増えて、systemが激減。0iの遅さはsystemの機嫌次第で、0と互角だったり激重だったりと不安定だったけど、これで安定したっぽい。
- {{{
- #sigprocmaskを呼ばない版
- text data bss dec hex filename
- 463188 62196 37584 562968 89718 libgauche_0.dll
- 464084 62196 37584 563864 89a98 libgauche_0i.dll
- 473972 62196 37584 573752 8c138 libgauche_org.dll
- -------------------------------------------------------------------------------
- arc i686-pc-cygwin
- thread-type none
+ ** [http://d.hatena.ne.jp/hirau/ Hatena]に引越しました。(2004/03/17 22:30:06 PST)
- strategy real user system process
- 0 29.28 13.93 13.71 27.65 #全体をSAFE_CALLで囲む
- 0i 29.85 14.73 13.09 27.82 #全体をSAFE_CALLで囲む(インライン展開)
- org 27.30 13.04 12.24 25.29 #オリジナル
- }}}
- - [[hira]]: やっぱりsigprocmaskは必要っぽいです。
- make testしたときに、systemのテストから返ってこなくなっちゃいました。
- {{{
- Testing system ...
- }}}
- Cygwinの場合、下のようなエラーが出るはずなんですが。
- {{{
- Testing system ... failed.
- discrepancies found. Errors are:
- test normalize: expects "/cygdrive/d/home/abc" => got "/cygdrive/d/home/win/abc"
+ たまにツッコミ入れてやってください。
- test sigalrm1: expects 14 => got 0
- }}}
- - [[Shiro]]: どこで止まったかわかります? (test.logの最後を見てください)。(2004/03/06 18:26:41 PST)
- - [[hira]]: ココで止まってました。
- {{{
- test fork & sigint, expects #t ==>
- }}}
- そうそう。固まってからは、Ctrl-Cを連発してもビクともしないんです。無敵状態なのでコンソールを落とすしかない。
+ ** fio
- [[hira]]:「1. SAFE_CALLの前にportタイプで分岐する(Scm_<port-type>_Putbを呼ぶ)」が完成。早速ベンチをとってみました。
- {{{
- #sigprocmaskを呼ぶ版
- text data bss dec hex filename
- 462804 62196 37584 562584 89598 libgauche_0.dll
- 463668 62196 37584 563448 898f8 libgauche_0i.dll
- 468308 62196 37584 568088 8ab18 libgauche_1.dll
- 473908 62196 37584 573688 8c0f8 libgauche_1i.dll
- 474292 62196 37584 574072 8c278 libgauche_org.dll
- -------------------------------------------------------------------------------
- arc i686-pc-cygwin
- thread-type none
+ filter云々の前に、現状のGaucheで何が出来るかイロイロ試している。
+ でもI/O周りの関数名やオプション名はめちゃくちゃ長いし、thunkだわprocだわlambdaだらけで、もうイヤ、て感じ。
+ 試しに、名前を短くしてthunk,procをマクロ化してみた。
- strategy real user system process
- 0 21.95 11.17 9.532 20.70 #全体をSAFE_CALLで囲む
- 0i 22.87 11.92 9.498 21.42 #全体をSAFE_CALLで囲む(インライン展開)
- 1 21.75 10.67 9.222 19.89 #SAFE_CALLの前にportタイプで分岐する
- 1i 21.50 10.21 9.5 19.71 #SAFE_CALLの前にportタイプで分岐する(インライン展開)
- org 20.59 9.972 9.562 19.53 #オリジナル
- }}}
- スピードは0 < 1 < orgですね。あと、インライン展開無しのほうが速い傾向にあります。
- 全体的に、かなり速度が上がってますが、原因不明です。テストはちゃんと通ってるのですが。4日ぶりにOSをリブートしたのが効いたのかしら。
+ gosh> (use hira.fio) => (#<module hira.fio> #<module gauche.interactive>)
+ gosh> (fo "t1" (ds :< :hello 1 :> )) => #<undef>
+ gosh> (fo "t2" (wr :< :hello 2 :> )) => #<undef>
+ gosh> (fo "t3" (fm "<[~10a][~10a] ~d>" (so (fi "t1")) (so (fi "t2")) 3 )) => #<undef>
+ gosh> (fo "t4" (pr "<" (so (fi "t1") (fi "t2") (fi "t3") (si "world")) " " 4 "> ")) => #<undef>
+ gosh> (fio "t4" "t5") => 58
+ gosh> (define t5 (so (fi "t5"))) => t5
+ gosh> t5 => "<<hello1>:<:hello2:><[<hello1> ][:<:hello2:>] 3>world 4>\n"
- [[hira]]:「2. 全面的にScm_MakeVirtualPortを採用してみる」を作ろうとしたけど、設計してみたら、結構大変なことになった。
- portapiに依存しているソースも修正しないといかん。
- gauche.hのマクロも修正だし。
+ 非常に快適だ。デフォルトのexprをcopy-portにしてから面白くなってきた。(2004/03/17 09:25:11 PST)
- ※FdはFile, Socket, Stdin/out/errの親クラスという位置づけ。
- {{{
- struct ScmPortRec {
- /* 省略 */
- union {
- /* 省略 */
- //これは廃止して以下に展開する
- //ScmPortVTable vt; /* virtual port */
- } src;
+ ** マクロ固め
- /* portapi interface. */
- /* safe */
- int (*Getb)(ScmPort *p);
- int (*Getc)(ScmPort *p);
- int (*Getz)(char *buf, int buflen, ScmPort *p);
- //ScmObj (*Getline)(ScmPort *p);
- int (*ByteReady)(ScmPort *p);
- int (*CharReady)(ScmPort *p);
- int (*Putb)(ScmByte b, ScmPort *p);
- int (*Putc)(ScmChar c, ScmPort *p);
- int (*Putz)(const char *buf, int len, ScmPort *p);
- int (*Puts)(ScmString *s, ScmPort *p);
- int (*Flush)(ScmPort *p);
- int (*Close)(ScmPort *p);
- off_t (*Seek)(ScmPort *p, off_t off, int whence);
- /* unsafe */
- int (*GetbUnsafe)(ScmPort *p);
- int (*GetcUnsafe)(ScmPort *p);
- int (*GetzUnsafe)(char *buf, int buflen, ScmPort *p);
- //ScmObj (*GetlineUnsafe)(ScmPort *p);
- int (*ByteReadyUnsafe)(ScmPort *p);
- int (*CharReadyUnsafe)(ScmPort *p);
- int (*PutbUnsafe)(ScmByte b, ScmPort *p);
- int (*PutcUnsafe)(ScmChar c, ScmPort *p);
- int (*PutzUnsafe)(const char *buf, int len, ScmPort *p);
- int (*PutsUnsafe)(ScmString *s, ScmPort *p);
- int (*FlushUnsafe)(ScmPort *p);
- int (*CloseUnsafe)(ScmPort *p);
- off_t (*SeekUnsafe)(ScmPort *p, off_t off, int whence);
- };
+ 昨日はthunkを撲滅しようと思ったのだが、ちと浅はかだった気がしてきた。
+ gauche.testのtest*なんかは一気に書き下すとき便利だけど、thunkを変数として扱えるtestのほうが柔軟性はある。
+ test*だけではつらいかも。昨日つくったfi,fo,fio,si,so,sioにはそれぞれ*付き版を用意すべきか。。。
+ ・・・いや違う。そのときはオリジナルを使えばいいのだ。書き捨て・即効性重視のマクロだ。柔軟性は捨てよう。(2004/03/16 07:52:25 PST)
- /* portapi implements */
- /*Scm_<TYPE><METHOD><ENCODE><UNSAFE>*/
- /*Getb*/ Scm_FdGetb Scm_IStrGetb
- /*Getc*/ Scm_FdGetcEUC Scm_FdGetcSJIS Scm_FdGetcUTF8
- Scm_IStrGetcEUC Scm_IStrGetcSJIS Scm_IStrGetcUTF8
- /*Getz*/ Scm_FdGetz Scm_IStrGetz
- /*Getline*/ //エンコードの扱いが難しい。フィルタにて提供か? エンコード毎に提供するか?
- /*CharReady*/ Scm_FdCharReady Scm_IStrCharReady
- /*ByteReady*/ Scm_FdByteReady Scm_IStrByteReady
- /*Putb*/ Scm_FdPutb Scm_OStrPutb
- /*Putc*/ Scm_FdPutcEUC Scm_FdPutcSJIS Scm_FdPutcUTF8
- Scm_OStrPutcEUC Scm_OStrPutcSJIS Scm_OStrPutcUTF8
- /*Putz*/ Scm_FdPutz Scm_OStrPutz
- /*Flush*/ Scm_FdFlush
- /*Close*/ Scm_FdClose
- /*Seek*/ Scm_FileSeek Scm_IStrSeek Scm_OStrSeek
+ ** ノーサンクス
+
+ 今日はthunkでハマった。
+
+ (with-input-from-file "1.tsv"
+ (port-for-each (lambda (l) (print ">" l)) read))
+
+ これだとウンともスンとも言わずに固まってしまう。
+ 標準入力が1.tsvに切り替わっておらず、コンソール入力でブロックしているのが原因。
+ こうするのが正しい。
+
+ (with-input-from-file "1.tsv"
+ (lambda ()
+ (port-for-each (lambda (l) (print ">" l)) read)))
+
+ with系ioでlambdaを忘れる、の巻でした。
+ 悔しいのでこんな風に書けるマクロを作った。
+
+ ;;上の例と同じ
+ (fi "1.tsv" (port-for-each (lambda (l) (print ">" l)) read))
+ ;;1.tsvから読み込んで2.tsv(:if-exists :append :buffer :line :if-does-not-exist :error)に書き込む
+ (fio "1.tsv" ("2.tsv" :xablne) (port-for-each (lambda (l) (print ">" l)) read))
+
+ こういうのが「言語以上・ライブラリ未満」ていう領域なんだろうな。
+ fi,fo,fio,si,so,sioと作りながら「Schemeの名前、長すぎだよー」と改めて思う。
+ 名前を短く、thunkを撲滅したくなった一日だった。
+ (2004/03/15 07:12:03 PST)
+
+ ** Schemeを256倍使うための本
+
+ そんな本が読みたいなぁ。あと、イディオムを沢山紹介してくれる本かな。Schemeは言語以上ライブラリ未満な領域が広いし、
+ 「やり方は何通りもある」の権化だから、似たような表現をイロイロ比較検討できるのがいいな。
+ ちなみに[http://mitpress.mit.edu/sicp/ 「Schemeを16777216倍使うための本」]は凄過ぎなので却下。65536倍薄めてくれないと読めません。(←そもそもScheme本じゃないか、これは)。(2004/03/14 11:38:27 PST)
+
+ -- あぁ欲しいですね。
+ でもイディオムってよりやっぱマクロ中心希望！~%
+ そうすれば''「schemeを256倍拡張する本」''でなんとなくうれしい。~%
+ いや、（define 本 (lambda () (拡張する schemeを 256倍)))かな。[[cut-sea]]:2004/03/23 00:10:35 PST
+
+ ** 好きなもの
+
+ - 星新一
+ - RAMONES
+ - vi
+ - Unixのツール
+ - Scheme
+
+ シンプルで、速くて、楽しいものが好きなのだ。
+ どれもクローンされまくりだってのがミソ。(2004/03/13 08:43:15 PST)
+
+
+ ** 続・夕日のプログラマー
+
+ [http://www.namazu.org/%7Esatoru/misc/bad-knowhow.html バッドノウハウと「奥が深い症候群」]が面白い。
+ [http://www.hyuki.com/techinfo/knowhow.html バッドノウハウからグッドラッパーへ]なんてのもあるし。
+
+ 良いものに対するノウハウはグッドノウハウ。
+ 悪いものに対するノウハウはバッドノウハウ。
+ 良いものに対するラッパーはグッドラッパー。 (バッドラッパー?)
+ 悪いものに対するラッパーはバッドラッパー。 (グッドラッパー?)
+
+ なんて言い方したら議論にならんな。ラッパーはラッピーを否定する意味で使うべきなのか？
+
+ 醜いものに対するノウハウはアグリーノウハウ。
+ 醜いものに対するラッパーはアグリーラッパー。 (ビューティフルラッパー?)
+
+ いかんな、これじゃ。だから何よって感じがする。
+
+ バッド = ダメな仕様に対するワークアラウンド => ノウハウ
+ グッド = ダメな仕様に対するワークアラウンドに対するワークアラウンド => ラッパー
+
+ てこと？じゃあ
+
+ アグリー = ダメな仕様 => プログラム
+
+ だな。'''「The Wrapper, The Knowhow, And The Program」'''でどうでしょ？いや、タイトルの話（←なんのタイトルじゃ！）。(2004/03/12 08:34:10 PST)
+
+ ** ((癒し系))
+
+ 最近Cをいじってるけど、どうも落ち着かない。心許無い感じがする。丸裸で肌寒い感じ。~%
+ ・・・たぶん、(温もり)が恋しいんだろう。(2004/03/11 06:51:51 PST)
+
+ ** 時間合わせ
+
+ WiLiKiはPSTだし、ShiroさんからのメールはHSTだ。
+ それがどうもピンとこない。
+ {{{
+ JST 日本 : 0 : 24 - 5 = 19 : 24 - 7 = 17
+ HST ハワイ : -24 + 5 = -19 : 0 : 0 - 2 = -2
+ PST 太平洋 : -24 + 7 = -17 : 0 + 2 = 2 : 0
- /*あとFdのUnsafe系とnull系(すでにある)*/
}}}
+ よし。これなら理解できる。GMT-8よりJST-24+5の方が実感わくなぁ。(2004/03/10 08:03:04 PST)
+ ** マクロデビュー
- interfaceとimplementsのバインドはポート生成時に行う。
+ 今までlambdaで実現できるようなマクロばかりを書いていた。
+ でも、こいつぁマクロでなきゃいかん。
+ {{{
+ (define-syntax inc! (syntax-rules () ((_ slot) (set! slot (+ slot 1)))))
+ (define-syntax dec! (syntax-rules () ((_ slot) (set! slot (- slot 1)))))
+ }}}
+ これでやっとマクロの必要性を実感する事ができた。
+ なーんだ、ただのマクロじゃん(←だからそうだって)ていう感じ。(2004/03/09 07:02:06 PST)
+ - hira:これ、Gaucheにもっとすごいのがついてた。[[GaucheRefj:代入]](2004/03/15 15:12:26 PST)
- これが上手くいくと次の2つが手に入る。
- - ポートの動的エンコーディング(encodingはポート作成時に決定する):
- せっかく関数ポインタなんだからと、欲張ってみた。
- でもstring,regexp,symbolのエンコーディングは静的のまま。
- string,regexpもエンコードの数だけ用意するか、マクロではなく関数呼び出しでよしとするか。
- -- [[Shiro]]: 「動的エンコーディング」というのは何を指していますか。
- 外部リソースがネイティブエンコーディングと違うなら、どっちにせよ
- エンコーディングのためだけに一段バッファが必要(読み書きするバッファは
- 別に必要)なので、メカニズム的には現在のgauche.charconvと大差ないと
- 思うのですが。
- -- [[hira]]: うん。これは変なこと考えてたと思います。
- - (たぶん)保守しやすいソース
- -- [[Shiro]]: あ、それと、portは外部への入出力だけでなく、
- 文字列ポートとして内部での処理に多用されることに注意して下さい。
- Gaucheは文字列ポートにかなり依存しています。従って、文字列ポートの
- 作成と読み書きは軽くなければなりません。
- -- [[hira]]: 了解です。オリジナルより速くするのはかなり大変だと思いますが、速度5%落ちだけど、その他のおまけが色々付いてくる、という線を狙ってます。
+ ** セロ弾きのゴーシュ
- 以下の問題を解決するものではない。
- - soft-portのgetb, getc,getzのどれかひとつを提供すれば、他はGaucheが提供してあげる:
- これは単純に体力勝負か。
- 個人的には、ポートを新しく作らせるより、フィルタを作らせたいのだけど。
- -- [[Shiro]]: 性能的にペナルティが無ければ、そっちの方がいいです。
- - 「バッファになりえるもの」の抽象化:
- これ、実はよく分かってないんですよね。
- srcに対するアクセスを抽象化したい、ということでしょうか?
- Fd内の問題としてOKなのかなぁ。mmapもfdが無いと始まらないし。
- I/OStrも「バッファになりえるもの」としてくくろうとしてます?
- エンコーディング問題をココで一挙に解決しようとか?
- -- [[Shiro]]: fdは関係なくて、現在のread-blockとread-block!のように、
- calleeでバッファをアロケートする場合とcallerでバッファを与える場合を
- どう綺麗にハンドリングするかという話です。read-block!はuvectorを
- バッファとして渡してますが、これを「バッファになり得るもの」という
- 抽象クラスで括れないかと思って。uvectorを使うとdlopenするuvector.so
- に依存してしまうので、コアのlibgauche.so内に書きにくいんです。
- -- [[hira]]: ああ、どうもです。ようやく理解できました。
+ {{{
+ 「森で生きている間、私は黙っていた。
+ 命を失った今、澄んだ声で歌う。」
+ 古いチェロにかかれていた言葉
+ }}}
+ Gaucheの名前の由来は絶対これだと予想している私。
+ 上の引用は[http://www.cello.jp/cellist ココ]で発見。
+ そういやλもlambdaになってからの方が、活き活きしてるような。(2004/03/08 10:57:47 PST)
+ - それもありそうですが、私はむしろ
+ Gauche->左->ぎっちょ->*ぶきっちょ->AWKward
+ な流れのほうが濃いのではないかと踏んでいます(まあ詰めてしまえばどっちでも同じようなものですが)。
+ なお、*のあたりは私の見解を反映したものではありません。:) --fuyuki
+ - うへー。[http://www2.alc.co.jp/ejr/index.php?word_in=gauche&word_in2=%82%A0%82%A2%82%A4%82%A6%82%A8&word_in3=PVawEWi72JXCKoa0Je Gauche]って形容詞だったんすね。JohnnyとかJoeyとか、人名にしか使われない単語だと思ってました。「セロ弾きのぶきっちょ」か。おお、なるほど。[[hira]](2004/03/09 20:07:04 PST)
- ----
- * ビックリ事件
+ ** ビックリ事件
+
2,3日前、sort!の「破壊的に再利用」の意味を誤解してハマったことがあった。
MLを読み返していたら[http://lists.sourceforge.jp/mailman/archives/gauche-devel-jp/2003-January/000077.html 似たような話]が出てきたのでsort!だけじゃ無いのかとビックリした。
しかし、どうにも分かりにくい。なんでだろ。
{{{
1. 元の値も戻り値も使用したい。(副作用なし)
2. 元の値を使用したい。(set!しなおす手間を省きたい。メモリを節約したい)
3. 戻り値を使用したい。(メモリを節約したい)
}}}
1と2の感覚しか持ち合わせていなかった、ということか。
2は束縛への副作用を目的としているのだけど、3では束縛への副作用は効率化のための手段に過ぎない。
副作用の有無だけでなく、2と3の違いが見た目で分かるようにならないかなぁ。3は「!!」にするとか。
sort, sort!!, remove, remove!!となっていればこんなハマり方しなくて済むのだけれど。。。(2004/03/07 06:32:50 PST)
- [[hira]]:これはリストならではの問題か。vectorに「!!」はありえないんだよなぁ。コレクションとしてlistとvectorを同一視出来ないってのは、やっぱりビックリだ。と思ったら、gauche.collection には「!」系が無かった。・・・この辺はあとで整理しておこう。R5RS,SRFI,gauche.collectionとRuby,Javaなどのコレクションとの比較だな。(2004/03/07 17:40:28 PST)
- [[Shiro]]: まとめましょう→[[Scheme:!と?]]
+ ** 思い込んだら、試練の道
- * 思い込んだら、試練の道
久しぶりに「switch文のbreak忘れバグ」にハマった。これとtypoは私の天敵だ。簡単に半日は持っていかれる。
自分は正しい、と思い込んでるため、疑惑があさっての方向に向かってしまうからだ。
困難なバグの場合、それに喰らいついて解決したら「俺ってすごいぜ!」と満足感が味わえるものだが、
typoを半日かけて解決した日にゃ「俺ってアホだぜ。。。」とがっかりするしかない。
ま、年に一度のイベントだと思えばいいか。今年はもう無いだろう。(2004/03/06 17:30:21 PST)
+ ** 論よりRun
- * 論よりRun
今日はportapi.cの宿題を片付けようと、一日中Makefileをイジクリまわしていた。
結局./libgauche_*.dllを最適化戦略の数だけ作り、./gosh -ftest io_bench.scmする前に./libgauche.dllにmvすることにした。
{{{
text data bss dec hex filename
463508 62132 37584 563224 89818 libgauche_0.dll
+
464052 62132 37584 563768 89a38 libgauche_0i.dll
474132 62132 37584 573848 8c198 libgauche_org.dll
-------------------------------------------------------------------------------
arc i686-pc-cygwin
thread-type none
strategy real user system process
0 35.01 12.99 19.46 32.46 #全体をSAFE_CALLで囲む
0i 41.37 12.54 25.73 38.27 #全体をSAFE_CALLで囲む(インライン展開)
org 34.20 11.84 19.61 31.45 #オリジナル
}}}
インライン展開がこんなに遅いとは。。。なんでやろ？(2004/03/05 07:24:27 PST)
+ ** 何も出力しないマクロが欲しい
- * 何も出力しないマクロが欲しい
気兼ねなくデバッグログを埋め込みたいので、何も出力しないマクロが欲しい。
{{{
(define-syntax p (syntax-rules () ((_ msg ...) (print "***p***>" msg ... ))))
(define-syntax p (syntax-rules () ((_ msg ...) ))) ;コレがやりたいんだけどsyntax errorになる
(define-syntax p (syntax-rules () ((_ msg ...) () ))) ;仕方ないからコレでガマン
(begin (p 'a)(p 'a)(p 'a)(p 'a)) ;(1)
(begin) ;(2)
}}}
(1)と(2)が同じ意味になるようなマクロって定義できないのだろうか。(2004/03/04 06:17:31 PST)
- [[Shiro]] (2004/03/04 07:04:42 PST): R5RS的には(begin)は未定義で、
Gaucheの現在のふるまいも「たまたまそう動いている」というものにすぎません。
ただ、もし余分な () がシーケンスの途中に入ることによる性能低下を
気にしているのでしたら心配御無用、値が使われないリテラルは
コンパイル時に消えます。(tail positionにあったら消えませんが、
その場合はデバッグマクロの有り無しで戻り値が違ってしまいますね)。
- [[hira]] (2004/03/04 14:01:57 PST): おお、それなら性能低下を気にせずにすみますね。
ちなみにtail positionではこんなの使ってます。
{{{
(define-syntax pp
(syntax-rules ()
((_ val msg ...)
(let1 result val
(print "***pp**>" msg ... " :val<" result ">")
result))))
}}}
性能が低下するなら、ppしか使えないなぁと心配してたんですが、取り越し苦労でした。
- [[Shiro]]: valが多値になる場合に御注意。
+ ** coroutine = subroutineだと思ってたあの頃
- * coroutine = subroutineだと思ってたあの頃
-
coroutineて書き言葉を見るまで、自分の勘違いに気付かなかった。
Kahuaセミナー聞いてた時もこんなだったし↓
{{{
「コルーチン」などはcall/ccの例として、ほげほげふがふがどうのこうの・・・
↓
「子ルーチン」
↓
「サブルーチン」
↓
(ﾟДﾟ)ﾊｧ? oO(call/ccって謎だなー)
}}}
過去にどれだけ「コルーチン」という言葉を見聞きしたか、記憶をたぐるのが恐ろしい。
(2004/03/03 07:37:21 PST)
+ ** クラスの中に入りたい
- * クラスの中に入りたい
-
slotにprivateなアクセッサを定義しようとして、あれ？っと思いました。
generic functionでディスパッチということは、自他の区別なんて無いのかと。
moduleのimport/exportが近いけど、staticな変数の可視／不可視の制御なので、ちょっと違う。
slotにpublic/privateの概念を持ち込むにはどうすればいいのだろう？
クラスの中に入る仕組みがあれば良いのだろうけど。
そうすれば、slot-refにイライラしなくても済むっていうオマケも付くのだが。
(2004/03/02 07:42:32 PST)
{{{
(slot-ref self 'hoge) ;;21文字 CLOS:フツーの書き方
this.getHoge() //14文字 Java:thisマニアが自己カプセル化したときの書き方
hoge ;; 4文字 CLOS/Java:私が望む書き方
}}}
- [[Shiro]]: これは興味深いテーマなので、移動しましょう→ [[Gauche:スロットアクセス]]
+
+ * portapi実験場
+
+ ML:[http://lists.sourceforge.jp/mailman/archives/gauche-devel-jp/2004-February/000648.html 予定とベンチ]
+ Rev.30:[http://practical-scheme.net/wiliki/wiliki.cgi?p=hira&c=hv&t=1078713876 まとめる前のportapi実験場]
+
+ ** 「2. 全面的にScm_MakeVirtualPortを採用してみる」版の設計
+
+ - hira: p->Getbのような直呼び出しを狙ったのだけれど、ポート生成のタイミングや参照のされかたが思ったよりも複雑そうでリファクタリングパスが定まらず、挫折。(2004/03/13 17:37:27 PST)
+
+ ※FdはFile, Socket, Stdin/out/errの親クラスという位置づけ。
+ {{{
+ struct ScmPortRec {
+ /* 省略 */
+ union {
+ /* 省略 */
+ //これは廃止して以下に展開する
+ //ScmPortVTable vt; /* virtual port */
+ } src;
+
+ /* portapi interface. */
+ /* safe */
+ int (*Getb)(ScmPort *p);
+ int (*Getc)(ScmPort *p);
+ int (*Getz)(char *buf, int buflen, ScmPort *p);
+ ScmObj (*Getline)(ScmPort *p);
+ int (*ByteReady)(ScmPort *p);
+ int (*CharReady)(ScmPort *p);
+ void (*Putb)(ScmByte b, ScmPort *p);
+ void (*Putc)(ScmChar c, ScmPort *p);
+ void (*Putz)(const char *buf, int len, ScmPort *p);
+ void (*Puts)(ScmString *s, ScmPort *p);
+ void (*Flush)(ScmPort *p);
+ ScmObj (*Close)(ScmPort *p);
+ ScmObj (*Seek)(ScmPort *p, ScmObj off, int whence);
+ /* unsafe */
+ int (*GetbUnsafe)(ScmPort *p);
+ int (*GetcUnsafe)(ScmPort *p);
+ int (*GetzUnsafe)(char *buf, int buflen, ScmPort *p);
+ ScmObj (*GetlineUnsafe)(ScmPort *p);
+ int (*ByteReadyUnsafe)(ScmPort *p);
+ int (*CharReadyUnsafe)(ScmPort *p);
+ void (*PutbUnsafe)(ScmByte b, ScmPort *p);
+ void (*PutcUnsafe)(ScmChar c, ScmPort *p);
+ void (*PutzUnsafe)(const char *buf, int len, ScmPort *p);
+ void (*PutsUnsafe)(ScmString *s, ScmPort *p);
+ void (*FlushUnsafe)(ScmPort *p);
+ ScmObj (*CloseUnsafe)(ScmPort *p);
+ ScmObj (*SeekUnsafe)(ScmPort *p, ScmObj off, int whence);
+ };
+
+ /* portapi implements */
+ /*Scm_<TYPE><METHOD><UNSAFE>*/
+ /*Getb*/ Scm_FdGetb Scm_IStrGetb
+ /*Getc*/ Scm_FdGetc Scm_IStrGetc
+ /*Getz*/ Scm_FdGetz Scm_IStrGetz
+ /*Getline*/ Scm_FdGetline Scm_IStrGetline
+ /*CharReady*/ Scm_FdCharReady Scm_IStrCharReady
+ /*ByteReady*/ Scm_FdByteReady Scm_IStrByteReady
+ /*Putb*/ Scm_FdPutb Scm_OStrPutb
+ /*Putc*/ Scm_FdPutc Scm_OStrPutc
+ /*Putz*/ Scm_FdPutz Scm_OStrPutz
+ /*Flush*/ Scm_FdFlush
+ /*Close*/ Scm_FdClose
+ /*Seek*/ Scm_FileSeek Scm_IStrSeek Scm_OStrSeek
+
+ /*あとFdのUnsafe系とnull系(すでにある)*/
+ }}}
+
+ interfaceとimplementsのバインドはポート生成時に行う。
+
+ 狙いは保守・拡張しやすいソース
+ - Gaucheは文字列ポートにかなり依存しているので、文字列ポートの
+ 作成と読み書きは軽くなければならない。
+ - Fd系に関しては速度5%落ちだけど、その他のおまけが色々付いてくる、という線。
+ 文字列ポートは現状維持を目指す。
+
+ ** 最新ベンチ結果
+
+ {{{
+ #sigprocmaskを呼ぶ版
+ text data bss dec hex filename
+ 462804 62196 37584 562584 89598 libgauche_0.dll
+ 463668 62196 37584 563448 898f8 libgauche_0i.dll
+ 468308 62196 37584 568088 8ab18 libgauche_1.dll
+ 473908 62196 37584 573688 8c0f8 libgauche_1i.dll
+ 474292 62196 37584 574072 8c278 libgauche_org.dll
+ -------------------------------------------------------------------------------
+ arc i686-pc-cygwin
+ thread-type none
+
+ strategy real user system process
+ 0 21.95 11.17 9.532 20.70 #全体をSAFE_CALLで囲む
+ 0i 22.87 11.92 9.498 21.42 #全体をSAFE_CALLで囲む(インライン展開)
+ 1 21.75 10.67 9.222 19.89 #SAFE_CALLの前にportタイプで分岐する
+ 1i 21.50 10.21 9.5 19.71 #SAFE_CALLの前にportタイプで分岐する(インライン展開)
+ org 20.59 9.972 9.562 19.53 #オリジナル
+ }}}
+
+ ** sigprocmaskを呼ばないようにしてみる
+
+ ML:[http://lists.sourceforge.jp/mailman/archives/gauche-devel-jp/2004-March/000670.html sigsetjmp on port locking]
+
+ - [[Shiro]]: CVS版はポートロックの度にsigprocmaskを呼ばないように
+ なっています。結構差が出るみたいなんで、それを加味して試してみて
+ 下さい。src/gauche/vm.hだけ直しても差が出るかも。
+ - [[hira]]: やっぱりsigprocmaskは必要っぽいです。
+ make testしたときに、systemのテストから返ってこなくなっちゃいました。
+ {{{
+ Testing system ...
+ }}}
+ Cygwinの場合、下のようなエラーが出るはずなんですが。
+ {{{
+ Testing system ... failed.
+ discrepancies found. Errors are:
+ test normalize: expects "/cygdrive/d/home/abc" => got "/cygdrive/d/home/win/abc"
+
+ test sigalrm1: expects 14 => got 0
+ }}}
+ - [[Shiro]]: どこで止まったかわかります? (test.logの最後を見てください)。(2004/03/06 18:26:41 PST)
+ - [[hira]]: ココで止まってました。
+ {{{
+ test fork & sigint, expects #t ==>
+ }}}
+