kiyoka:log:2007
最新: kiyoka
Gauche-0.8.11のVMでエラーが出た。 (2007/10/13 05:06:27 PDT)
- srl:sxml->html関数にでっかいSXMLデータを渡したら次のようなエラーが出た。
$ ./oldtype_to html t.ot > log #?=expanded-sxml #?- ((hr (|@| (id 1) (class "new5"))) (div (h2 (a (|@| (href "./k ... #?=input-file #?- "t.ot" #?="././oldtype_to":45:(pretty-print sxml) #?- 36 #?="././oldtype_to":47:(srl:sxml->html sxml) *** ERROR: too many arguments (10267) to apply Stack Trace: _______________________________________ 0 (srl:sxml->html sxml) At line 47 of "././oldtype_to" 1 (oldtype:sxml->html (debug-print expanded-sxml) (debug-print input ... At line 194 of "././oldtype_to" 2 (display (oldtype:sxml->html (debug-print expanded-sxml) (debug-pr ... At line 193 of "././oldtype_to" make: *** [all] Error 70
- ソースをgrepすると、このVMのスタックが上限に達している様だった。
/* Size of stack per VM (in words). */ #define SCM_VM_STACK_SIZE 10000
- しょうがないので、定義値を10倍して運用中。
- これって、どうなんでしょうか。srl:sxml->htmlの書きかたが富豪な書きかたになっているのが問題なのかVMのスタックサイズが有限なのが問題なのか...
- ソースをgrepすると、このVMのスタックが上限に達している様だった。
- Shiro(2007/10/13 10:48:40 PDT): ああ、引数の数に関してはコンパイルを行う処理系だと 制限があるのが普通です (Common Lispでは最悪50個と規格で定められています)。 srfi-1のconcatenateなどの関数も、(apply apppend ...) では引数の個数制限に ひっかかる場合があることを考慮して導入されたはず。 いずれこの制限は取っぱらいたいですが (10000個も引数を取れる関数ならたぶんその ほとんどはrest引数でリストにして受けてるはずなので、一度引数を全部スタックに 展開するのではなくリストのまま渡せるはず)、当面はapplyしているところを 探して、長い引数のapplyを避けてください。
- kiyoka(2007/10/22 08:27:17 PDT): 了解です。長い引数のapplyにならないようにコードを書いてみます。オープンソースソフトウェアとしてリリースしたいので標準のGaucheで動かないと困りますもんね。
OldType(Wikiエンジン)開発 (2007/09/20 07:30:11 PDT)
- とりあえずWikiフォーマットで保存した .ot ファイルから html ファイルに変換するパーサが何となく形になってきました。
- 設計メモなどのコンテンツをこちらのリンクOldTypeで見える様にしました。まだまだ設計途中でも有るのでツッコミなどありましたらお願いします。
- kiyoka(2007/09/26 08:04:33 PDT)emacs-w3m+oldtype-modeでWiLiKiのコンテンツを編集する方法をこちらoldtype-mode:応用にまとめました。
OldType(Wikiエンジン)開発 (2007/07/10 07:03:15 PDT)
- 性懲りもなく、また新たなWikiエンジンを作ろうとしています。
- 特徴はWiki記法が行指向でWebブラウザからの編集も行指向のものを考えています。
- Subversionでコンテンツを管理して、GaucheとKahuaの組み合わせでバックエンド処理をさせる事を考えています。
- 他にもアイデアが沢山湧き出て来るんですが、バランスを取るのが、すんごくムズカシーのでじっくり取り組んでいます。
- 例えば...
- バックエンド処理はcronで定時実行にして、Imagemagikバリバリな豪勢な処理もOKとか。
- プラグインはUNIX的なフィルタコマンドを追加するだけとか。
- ある程度blog的な使いかたもできるようにとか。
- Emacsからの編集はhowmライクに運用できるとか。
- バランス重要。
び(2007/07/10 18:23:40 PDT): おお。期待しておりまする ;-)
kiyoka(2007/07/11 05:29:42 PDT): また、LingrでKahuaの質問させてもらうかも知れません。まだまだ先ですが、その時はヨロシクです。
bashでWikiのプラグインコマンドを作れる仕組みについて。デザインするのは難しい。 (2007/07/17 08:17:59 PDT)
- Webアプリとの結合密度が限りなく低いので、細かい拡張はプラグインではできなさそう。
- 但し、その結合度の低さがプラグインの作りやすさの源泉だと思う。
- うーん。この方向で使えるものになるんだろうか...
- この場合のプラグインの適用範囲としては、RSSリーダーとか、メールでのリマインダとか、Wikiページのレイアウト後のサムネイル作成とかをイメージしてる。
WiLiKiのパーサを流用してパーサを試作中 (2007/08/23 08:20:35 PDT)
- fmt-lines()関数から始まる、closureを渡していくパーサのスタイルは何と言うのでしょうか。オモシロイです。
- 次の >> 関数に元来た道であるBlock-levelパーサのclosureを渡す様になっています。インラインレベルのパーサは一連の処理が終わったら contを呼びだすという寸法です。(実際にソースを読んでもらわないとこの説明では分からないと思いますが...)
(define (>> cont ctx seed) (lambda (tok ctx r) (cont tok ctx (cons r seed))))
- Shiro(2007/08/23 13:57:20 PDT): パーザの書き方として特有なスタイルではなく、 普通の継続渡し形式です。継続渡しは探索とかパージングには相性が良いです。
- kiyoka(2007/08/23 16:54:40 PDT): なんでも継続で読んだのと似ているので継続かもと思いましたが、クロージャは必ずリターンするので引数付きのJUMPとは違うのかなと思った次第です。Kahuaの継続渡しは内部で同じような動作になっているのでしょうか。とにかくパーサには合うスタイルですね。
- kiyoka(2007/08/27 05:38:39 PDT): ふと、継続渡しはSchemeだと簡潔に書けるけど、Common Lispだと #,とか funcallとかが大量に出てきて読みにくくなりそうだなと思いました。やっぱりSchemeの方がシンプルでいいですね。
On Lispの読書継続
- まだ100ページあたりを彷徨っています。マクロって凄いですね。
マクロのないSchemeでも十分強力なのにマクロが使えれば、より圧縮したコードが書けそうですね。(2007/02/02 05:51:20 PST)
- やっと、全部読んだ。けど、何度も読まないとモノにならなさそうです。( 2007/07/10 07:03:15 PDT )
明けましておめでとうございます。
- 2007年もLisperでいる予定です。もっとエレガントなコードが書けるように精進していきます。(2007/01/04 02:11:05 PST)