#glintへのアノテータとして使えないのかな >コメント
#って、ちゃんと使ったことないのだけどglint
#アノテータ? アノテーション?
#でも私も型をコメントとして書くことあるけど、コーダの意識として書いてるレベルであって本当にその型があるわけじゃないんですよね
#それがまた楽なわけで
#たとえば今の場合だとLayouterというのを意識しているだけであってコード上にはどこにもでてない。
#出てなくてもよいのがまぁ楽というか
#で、実は下層の方で場合によって#fを返すのに上層がそれを考慮してなくてハマる、というのがkahua.elemの問題点だったりしたわけだが(笑)
#ああ、まーね
#今考えると、あれはstate monadをrenderが正しく扱わなかったことが問題だったのかな
#複雑になってくると型を厳密にチェックしてもらわないと人間の目では検出できないとか、管理しきれないとか。
#その正しく扱うってのを人間ができる範囲はいいんですけど、確かに結構でかくなってるし
#私もよくわかってないのにいじってるからなぁ
#実際nobsunもそのつもりで組んだけど今のコードは意味をなしてないって以前言ってたけど
#Lisp文化って「複雑になる前に繰り返し試してバグを潰すから後日大きく複雑になっても大丈夫」ということだからな
#実際には複雑になっちゃってからいじることも多々あるわけなので
#最近思うんだけど複雑さって全体が複雑になるのは問題がそうなんだからしょうがないとして
#それを完全に把握できるレベルまで局所化できるかが重要なのかなと
#複雑になったらリファクタして簡単にしたり抽象構造取りだしたりしますけど
#Functional Programmingってまさにそうでしょ
#その能力に限界がないならどの言語でも同じはずだと思う。
#でも、状態は部分をまたいで受け渡されるから、本質的に局在化とは相反する物だと思う
#その能力とは、リファクタリングによって抽象構造を取り出す能力ということ?
#だとするとstate monadを使ってもやっぱり局所化できてないってなるな
#getとかputとかしたのはどこに対して？とか考えると結局
#うん
#グローバル変数的なものをシミュレートしてるわけだし
#現実問題として「全てを局在化してそのブロックを組み合わせて万事解決」ということはありえないと思う
#もっと正確には「そのやり方は人間の本性に反する」というか
#まだうまく整理できないんだけど
#情報の渡し方はいろいろありえて、
#グローバル変数による方法だとダメで
#引数にして渡すのがOKなのは
#当然だと思ってたけど、どう渡そうが
#管理できてるかどうかという点ではなんか大差ない気もしてくる
#引数で渡したって、参照渡しで書き換え自由だったら、グローバル変数と変わりない
#そこが問題なのかな＞書き換え自由
#そう
#最近Kahuaのリポジトリいじってるのは0.9対応？
#すごくラフに言えば、「思ってたのと違う値が入ってる」というのがまずい
#ん
#Gauche-dbd-mysql?
#0.9対応というより、やりかけのままずっとほっぽってあったから年内に0.3としてリリースしようかと思って
#そればっかりだっけ？他にも変更メールが来てた気がしたけど錯覚かな
#クリスマスリリースだ
#他のは、えんどうさんがpainaをいじった奴じゃない?
#Haskell Night向けにいろいろいじってたっぽいので
#おお、なるほど。
#Gauche-dbd-mysqlはMySQL 5.0以降のみサポートにすることにしたので
#だいぶ楽になった
#4.1サポートするために相当ぐちゃぐちゃしてたから
#ほっぽってるうちに時間が解決してくれたって奴だね(笑)
#一応5.0のAPIはほぼカバーしたので(deprecatedなAPIを除く)、テストをちゃんと書いたらリリースするよ
#すげー＞ほぼカバー
#放置してたら発酵がすすんで酒になってた
#ではなく
#Foreign Pointerのおかげで、カバーするだけならすごく簡単
#放置してたら腐敗がすすんでカビがはえてた
#バインディング書いたことないからなー
#Gauche-firebirdも完全放置状態だしなー
#c-wrapperが出てきて私みたいに動けばいいやなレベルの人間はますます書かなくなった
#ああ、それはあるけど
#今だとsqliteとかのがよく利用されてる？
#幸い(?)、Snow Leopardではc-wrapperがまだビルドできないので、ちょっとだけモチベーションが上がる(笑)
#どうだろうな
#SQlite3はパブリックドメインなので、いろんなプログラムに同梱しやすいから
#特にWebフレームワークだとデフォルトがSQLite3ってことは多いと思うよ
#とりあえず動かせるからね
#障害になるのはいつもライセンスという事実
#そういう意味では、Gauche-dbd-sqlite3(いくつか世の中に存在する)さえちゃんとしてたら、Kahuaのデフォルトをそれにちゃうのはありかもね
#それにしちゃう
#小さいとか軽いとか
#言われているほど遅くはない
#そのイメージもあるんじゃない？
#まぁ
#あれ？遅いって言われるんだ＞sqlite
#言われてたよ
#あと、ごく最近までForeign Keyをサポートしてなかったりとか
#トランザクションがサポートされたのも比較的最近(と言っても数年前)
#トランザクションは確かに重要だな
#トランザクションにしてないと、たいてい後になってから問題でてくる
#まぁSQLite3の一番いいのは、サーバの設定を全くする必要がないことでしょう
#MySQLやPostgreSQLは、サーバの設定を考えちゃうからな
#セキュリティのことを考えると、あんまり気楽に立てる気にならない
#組込でDBを使いたいとか
#汎用目的のDBサーバとして使うってより
#このアプリにDBが必要だから組み込むという感じでしょうか
#> SQLite3の一番いいのは、サーバの設定を全くする必要がないことでしょう
#ホントにこれ一番です。 RailsのデフォルトがMySQLからSQLite3になって教育がすごーく楽になりました。
#なるほどね
#確かにDBのセットアップからやりだすと大変そう
#Kahuaはfsdbがデフォルトだからそれでスルーしてるんだな
#Kahua2からはSQLite3しばりにして、fsdb捨てたいなぁ
#正直、今の(e)fsdbでがんばるのは限界が低過ぎて不毛だ
#将来的に例えばGaucheがmmapをネイティブサポートした暁に、妥当AllegroCacheを標榜してがんばるのならアリだと思うけど
#どんなにがんばっても「間に合わせ」にしかならないのがわかっていると、モチベーションが上がらない
#個人的な要望を言えば
#レベルは低くてよい＞fsdb
#fsdbの存在意義ってインストールしたらするっと動作する
#その意味ではsqliteに置き換えって戦略はありなんだけど
#なんせ別プロジェクトゆえ、いつなくなるか分からないってのが懸念点
#とは言え例のインデックスにしても
#他のDBの機能をフォローするにはパフォーマンス以外に大変な部分があるのは分かるので
#乗り換えてしまって、もしsqliteがプロジェクト終わる状況になったら、その時はまた別の候補がきっとあるから
#そっちに乗り換えるでもいいかもしれない
#gaucheもGCは別プロジェクトを組み込んでるし、あんまり別プロジェクトだからとか神経質になるものではないのかしらん
#SQLiteの場合パブリックドメインなので
#Kahuaにまるっと取り込んじゃえるんだよね
#そこが利点になるか欠点になるかは微妙だけど
#んで、fsdbが手軽なのは確かなんだけど
#fsdbがサポートできないが故にKahuaとしてサポートできない機能(特にトランザクションまわり)というのがあったりするわけ
#あるいは、fsdbの動作がbuggyであるが故にKahuaが安定運用できないとかね
#んで、しばらく前から、dbm系を使ってfsdbを作り直せないか検討してたんだけど
#SQLite3がここまで普及してるんだったら、むしろSQLite3を使った方が他のRDBMSサポートとの整合性を考えても合理的なんじゃないかなぁと
#ただ、Gauche-dbd-sqlite3をどうするかがけっこう微妙なのだけど
#決定版がないので
#じゃあびの仕事だ＞決定版
#うん
#たぶんスクラッチから作っても大した手間じゃないと思うので
#SQLite3そのものとGauche-dbd-sqlite3までKahuaそのものに同梱できるなら、Kahua2のfsdbはSQLite3ベースにしちゃってもよいかな、と
#configureのオプションでインストール済みのGauche-dbd-sqlite3を使えるようにしておけばいいでしょう
#いつやるんだ、という話はあるが(笑)
#code書いてる暇があるならchordを弾いてたい(笑)
#今やるんだ
#いや、仕事あるし(しかも.Net)
#当分、Kahua関連は仕事ではやらない
##しまった
#haskell-jaの方に貼り付けたかったのをこっちに貼っちゃった
#.NETの仕事はびじゃなくてもよい
#Kahuaの仕事はびじゃないと
#エサついばんでくる
#今年はBird Feederを用意してないな、そういえば
#M: ミコアイサ
#誤爆
###これのうまい解答ってかけないですかね？ ひとりが答えているのは、継続を実行するスケジューラのようなものを使う方法で、これはこれで汎用的でいいんですけど。
#(1)3つコルーチンが走るなら常に必ず2つ休んでるはずなので元コードのanother-funはセットになる (2)ラウンドロビンで走らせるならそのセットはFIFO、というとこまでは素直にゆくから、そしたら既に出てる答えは必然的な帰結のような。
#あーでもanother-funの作り方を工夫するとそのへんをクロージャに閉じ込めちゃうことはできたりするかな?
#既出回答と原理的には変わらないものになるような気もするけど。
#というか元の質問はそういうパズル的な話なのかな? proc Cを同じ形で足しても動作するようなanother-funを考えよ、という。
#SQLiteってトランザクションあったっけ?
Gauche > Archives > 2009/12/04