##辞書ファイルのファイル名をパラメタで渡せるようにしました。これで複数の辞書を使い分けるとかできるかな。
#parameter を使ってみましたが、あんまりうまく使えてないです。「ある値が定義されているときだけ parameterize する」という動作をもうちょいスマートにかく方法はないですかね。
#>とおる。 それpath traversal対策しないとやばくない? scheme-baton.scm?../../../etc/passwd とかやられたりすると…
#「ある値が定義されてるときだけ」の「定義」ga
#「定義」ga
#あ、やられますけど、S 式じゃないので読めないかなと思って。
#あれ
#「定義」がdefined?の意味ならちょっと厄介だけど、
#あ、えっと、この場合は、CGI のクエリストリングで渡されたかどうか、です。
#cgiパラメータに渡されたかどうかって話なら (parameterize ([parameter-name (cgi-get-parameter "x" params :default (parameter-name)...
#とかかなあ。
#ちょっと不細工だけど。
#ですよねぇ。(parameter-name) をもういちどよぶのが、なんとなく抵抗があったんですが。
#性能の問題で呼びたくないなら (or (cgi-get-parameter ...) (parameter-name)) とする手もあるけど、コード上はごちゃごちゃするね。
#ちなみにcgi-get-parameterのデフォルトは (:list #t を指定しなければ) #f なので、 :default #f はいらない。
#あー、何も考えずにコピペしましたが、せっかくなので直しておきますかね。
#:convert x->string もいらないような気が。
#path-traversalについては、たまたまvalidなS式として読めちゃうケースとかもあり得るし、このスクリプトは書き込みもやるみたいだからちょっと気持ち悪いなあ。
#って、ここで色々言うくらいならワシがバトン引き受ければいいのか?
#つぎ(び)さんがうけとってくれるそうなので、そのつぎでも。
#gauche決め打ちで、細かいところ直すだけならできるかな。
#shiroさんはゴール、らしいですがｗ
#e,
#いや、いつでも参加して頂いて構わないかと
#ちょこっとなおして git push しました。
#どうせならプレインテキストじゃなくて DBM とかのほうが軽くできそう。
#晩遅くに受け取りますので、それまではなんぼ直してもらってもひろえまっす >とおる。
#fdbmならどんな環境でも一応使えるのかな? >DBM
#性能はいいから手軽にポータブルなdbmが欲しい、fsdbmだとファイルがいっぱいできるので面倒、という時のために、単にハッシュテーブルをS式にしてread/writeするようなdbmを考えたこともあるんだけど、需要あるかなあ。
#Kahua的には欲しいかな
#現状のKahuaのfsdbは1.0リリース時に書き直したものですが、今見るとあまりイケてないので
#Gaucheに標準でいいのが入るのであれば、独自のfsdbを捨ててそちらに乗り換えたい
#でも、RDBMSバックエンドと統合する為にsqlite3を同梱しちゃえという乱暴なアイディアも持っているので、なかなか微妙なところです
#いいっていうか、上のアイディアはopen時にファイルをがっと読んでテーブル作って、close時とか適当なタイミングでがっと書き出すってことなので、データ量が増えるにつれopenとcloseのコストがどんどん増えるという欠点があります。利点はポータブルなこととファイル一つで持ち運べること。
#現状でもfsdbmで一応ポータブルなkey-value storeというのは実現されてるわけですが。
#はい
#単純なkey-value store以上のものが必要ならdbmは考えない方がいいでしょうね。
#なるほど
#kahua.efsdbを書いた一番の理由は、インデックスロットを実装したかったからなのです
#fsdbmって、keyがpathでvalueがファイルの中身なわけですが
#そのファイルへのシンボリックリンクをインデックスにしてるんですね
#実体がひとつでkeyがいっぱい、みたいなのが欲しかった/欲しい
#最近のBerkeley DBって、そういうのができたと思う
#はい。でもその時点でkey-value storeのパラダイムからははみ出しているので、ちゃんとしたrdbmに移行するか、あくまでkey-value storeは下請けのブラックボックスとして扱って (例えばgdbmなどにすげかえても動く形で) その上に複数インデックスのdbを作るか、というのがたぶん順当な方向ですね。
#ちなみに、shiroさんの最初に言ってたアイディアって、fsdbmにdump/undump機能を追加するだけじゃだめなのかしら
#dbmにインタフェースとしてそれを用意しとくと、バックエンドを替える時便利かも
#別コマンドを通すならtarでもいいわけで。それさえも面倒だし、どうせエントリ数も大したことないのわかってるし、ってな場合向けです。
#なるほど
#ちょっとしたセッション情報の管理とかには便利そう
#そうそう。あとファイルを直接編集できるしね。オプションファイルとかちょっとしたユーザ管理なんかでいちいち読み書きを書くのも何だなあという気がしてるので。
#でも、たとえば最初にdbm.fsdbmで運用してて、性能が足りなくなったからdbm.gdbmに移行したくなった時なんかに、標準でdump/undump欲しいと思うことがあります
#まぁ、毎回ちょろっと移行ツール書けば済むからいいんですが
#ああ、設定ファイルは確かにあるな
#そっか。wilikiの移行スクリプトは書いたけど、dbm汎用のは書いてないなあ。
#標準のdump形式があると、便利かなぁと思うことはあります
#S式dbmを標準のピボット形式にして相互変換できればいいのか。
#そういえば、<hash-table>がwritableじゃないのは、object-hashメソッドがカスタマイズされてると困るから、という話がありませんでしたっけ?
#確かshiroさんから聞いたようなかすかな記憶が
#そうです。でもeq, eqv, string=については決まってるので読み書き可能でも構わないとは言えます。
#「ハッシュリテラル」がある言語(正確には「マップリテラル」の方がいいか)って、ハッシュ関数と比較関数は決め打ちなんですよね。利便性はいいんだけれど、柔軟性を失うのが怖いのはLisperの臆病さか… Clojureは割り切っちゃってますけど。
#CLはどうしてるんでしたっけ?
#って、CLtL2を見ろ >俺
#cl-user> (make-hash-table)
#<eql hash-table with 0 entries @ #x10009a31d2>
#比較関数とハッシュ関数は自由に与えられます。
#リテラル形式は無し。
#なるほど
#Gaucheの場合はobject-hashとobject-equal?でカスタマイズ、と
#そういうデザインだったんだけど、いまいち使いにくいということがわかってきたので、もっといいデザインを考え中。
#object-hashとobject-equal?によるカスタマイズも残すけど。
#Bignumを大量に放り込むことがよくあるのですが、そういう場合はじゅうらいどori
#キーとしてBignumな値を放り込むことがよくあるのですが、そういう場合は従来通りeqvですかね >hash
#bignumならeqvでいいと思います。eq?比較は保証されませんから。
#有難うございます
#この単語帳ソフトは中で単語のリストを成績順にソートしたりする必要があるみたいなんですが、そういうのに適したストレージってどんなのがあるでしょうか？
#うーん、ディスク上でソートされててほしいの? そしたらインデックスにB treeとか使う真っ当なdbみたいなものになるかなあ。
#単にメモリ上でソートされてて欲しいなら、読んだ辞書をtree-mapに入れてけば順番に取り出せるけど。
#やっぱりディスクにしまっておく場合は、まっとうな DB になっちゃいますかね。
#ケースバイケースでしょう。毎回必ず全部読み、全部書き直すってことがわかってればソートした順で書いとけばいいだろうし。必要なとこだけ読み書きして、挿入があり得るのなら、自分で書いても結局普通のdbがやってるようなことを自前でやるだけになりそうな。
#ですよねぇ。
#当初の想定では単語は登録されても 10^3 のオーダーだから、毎回全読み、全書きでいけるだろうというものでした。あとは human readable/writable であって欲しかったので S 式のままにしてあります。
#えぇ、まぁ、ひとりしか使わないならいいんですけど、ウェブサーバで一般に向けて公開する場合は、パフォーマンス向上のハックもありかなぁと思いました。逆に言うと、サーバサイドでやれる事ってそのくらいしかないような。
#なるほど。自分ならRDBMSに入れてしまいますね。
#サーバーサイドでやるなら、地味ですがファイルの競合も考えないといけないですね。
#あったなぁ、ロックもかけないでカウンタファイルを更新していた某K_h_a(笑)
#えw ＞ 某K_h_a(笑)
#コードバトン。たのしそうだなぁ。
#>higeponさん RDBMS入れるとき、問い合わせはどうされてますか？。直接SQLなどを叩くんですか？
#自分はKahuaの場合、付属の永続化が諸事情でダメで、直接SQL -> S式SQL -> エセORマッパ という遍歴があるのですが、Schemeでの永続化は皆さんどうされてるんでしょうか。
#私はS式を直接ファイルに書き出し、dbm、Kahuaのefsdb、ごくたまにdbiからdbd.mysql、って感じです。dbiが使いたい時っていうのは定型的なデータの出し入れが頻繁な時なんで、SQLのprepared statementで用が足りちゃってる感じです。
#出し入れが頻繁でなければ、write-objectとread-ctorを書けばGaucheのオブジェクトはそのままread/write出来るので、オンメモリで持っといて適当にファイルにS式でダンプする感じ。
#自分は環境に合わせる感じです、Gauche/Mosh なら prepared statement かな。Rails とかなら ActiveRecord ですませてしまiます。
#なるほど。勉強になります。いろいろい作っていて思った理想は、[オンメモリ <-> 外部表現] 且つ、それ自体ほかの機能を持たないプロセスで、ACIDを確保しつつ、どんなgoshからでも違いなく、メモリにアクセスする感覚で使えるものなんですよね。Common Lisp界隈にはそういったものがあるような匂いがするのですが。
#Allegro CLについてるAllegroCacheはそんな感じですね。Kahuaの永続オブジェクトもそっちの方向を目指してはいるんですが、ちゃんと実装するのはかなりパワーが要ります。
##あれ、t-code.orgにアクセスできないなあ。
#さてと
#バトン受け取ります
#次はnobsunかな(笑)
#ちなみに、差し支えなければKahuaの永続化がダメだった諸事情を教えてもらえるとありがたいです >ayato
#多分ハックすれば問題ない事なんでしょうけど(自分の力不足)、単純に外部のスクリプトからアクセスする必要があったんです。自分でOR map書く労力とKahuaをハックする労力を天秤にかけたときに前者を選びました。
#あーなるほどわかります
#あ、文脈的に紛らわしかったので捕捉です。Kahuaの永続化が"ダメ"なのではなくて、自分の使い方が"ダメ"なのです。Kahuaの永続化は素晴らしいと思います。
#ライブラリとしてのKahuaは整備が圧倒的に足りてないですからね
#例えば、efsdbに保存していたものをmysqlに移行する時、毎度アドホックなツールを書かなきゃならない(現に何度か書いた)
#あと、cronから叩くツールを書いたりとか
#あー、やっぱScheme(Gauche)は読みやすい
#というか読み慣れているから、すっと頭に入ってくる
#すいません、そういえばt-code.org放置してドメイン失効させてしまいました。
##Delhi bellyという表現を教わった
#考えてみたら、かなり失礼な表現だな...
#「スペイン風邪」に近いものを感じる
#豚インフルも豚に失礼。
Gauche > Archives > 2010/01/27