#とおる。さんて嘉門達夫をリアルタイムに知ってる世代だっけ?
#関西人なのでとてもよく親しんでいます :D
##「そうすると、未だになんとなくメンテナンスしてもらえそうなのはGaucheしかない。で、Gauche用のフレームワークはKahuaしかない。でもKahuaの開発はとまってる」
#うは。
#たった今、Kahuaアプリのコード書いていますよ〜。
#でも納期がつまってるんで本体へうまい形でフィードバックできてないのは確か。
#なんつうか、きちんと書かなくても泥縄的に何とかなってしまうが故に、少々の不自由があっても気合入れて本体を直そうというとこまでモチベーションが上がらないってのはあるかも
#"good enough"のトラップにハマってしまっている感じが。
#アイディアはいくつか持ってるんだけど、この2年くらいモチベーションがあまりプログラミングに向かなくなっちゃってるのが個人的には最大の問題だなぁ
#「○○機能搭載！」みたいなのがなくても、ちょこっとやれば大体のことはできてしまうっていうことですかね。
#Kahuaには愛着があるので(新参者だけど)、もっといいものにしたいとは常々思ってるのだけど
#最終的にはGaucheなんで、何とかできちゃう
#あと、個人的には「薄い」フレームワークが好きなんですよ
#まあ、私は中身をなまじ知ってるために、機能設計段階からkahuaでやりやすいように考えるから、あんまり色々な機能が次々と欲しくならないってのはある
#限りなくツールに近い奴
#あ、そうそう。Kahuaはちょっとモジュール間が縦に依存しまくってて、気軽にいじれなくなっちゃってるとこがあるよね。
#重厚長大なフレームワークが嫌いなので、機能を足したいとか思わない
#はい
#特に、kahua.serverとkahua-serverの絡み具合は何とかしたい
#プラグイン的なものがいいのかな。
#あれはプロトタイプコードがそのまんま肥大化した感じだからなあ
#プラグインというより、全体の設計が、横にブロックを並べる感じでつくられていると
#少なくとも、レンダラ(ページ記述言語インタプリタ)部分は外に出したい
#あと、サンドボックスの考え方を整理したいんですよね
#アプリケーションをプラッガブルにつくると、コミュニティがもりあがる。
#現行のサンドボックスにはメリットが見出せない
#少しの機能しか必要でないアプリは、少しのブロックだけ使って他をみなくて済むので楽
#サンドボックスは廃止でいいと思います
#やっぱり廃止ですかね
#で、サンドボックス廃止すると、プラグインの仕組みもいらなくなるんじゃないかという気が… (普通にGaucheモジュール書けばいいので)
#そうです
#一度そうしちゃうのがいいかもしれない
#Gauche モジュールは、ちょっとおまじないが多いかなぁと個人的には思います。
#ミニマルセットにまで整理しちゃって
#既存のアプリとの互換性を保とうとすると色々面倒が出そうな気がするんですが、幸か不幸かそれほどアプリは多くないので、現行アーキテクチャは完全にメンテモードにして大きく変えるというのはありだと思う。
#@とおる。Gaucheモジュールのおまじないって?
#provide とか。あと、もし○○クラスから導出しなきゃいけないとかあるとすれば、そういうのとか。
#provideは0.9から不要になりました。じゃじゃーん。
#おー。
#クラスのプロトコルは、ちょっとルーズな関係なんでわかりにくいかも。
#自動provide?
#@bi
#@び はい。
#koguroさんが前WiLiKiに書いてた奴ですね
#欲しいって
#gauche.collectionやgauche.sequenceをuseしないと主要な手続きがジェネリックになってなくてはまる、という問題については、最初から全部ジェネリック (gauche.collectionやgauche.seqneuce不要) にしちゃおうかなと思ってます。性能の問題をクリアできれば。
#Blosxom とか Remedie とかのプラグインは、拍子抜けするくらいシンプルにかけるので。
#Remedie のプラグインはこんなかんじ。
##でもプラグインの「約束事」を覚える必要があるんですよね。
#うらで何やってるか知りませんが、プラグインシステムが必要なことはだいたいやってくれる。
#あ、はい。約束事はありますね。これとこれの関数を定義しましょうとか。
#コードが短くても約束事が多いと、3年後に手直しが入るみたいな案件ではやっぱりオーバヘッドが大きい
#最近ちょっと考えてるんですが
#コードの量と約束事(implicitにサポートされる機能)とはトレードオフにあるけど、別の要素もあるからうまくデザインすれば両方を下げることはできるんじゃないかと思います。
#あ、はい。そうなんですよね。あんまり長生きはできない。
#(use module-name 'prefix:)みたいなことってできたら便利かなぁ、と
#複数のモジュールをuseした時、importする関数名がかぶってて悲しい思いをしたことがあるので
#prefixはサポートしたいんだけど、速度を下げずにやるのが面倒で止まってる
#スコープ解決演算子みたいなのですかね。
#逆に C++ とかみたいに、局所的に use namespace できるとかでもいいのかな。
#でもr6rsコンパチ (r6rs準拠ではなく、r6rsのコード「も」走るということ) にしたいので、renameやprefixはサポートしないと。
#どちらかというと、XMLのネームスペースに近い考え方なのだけど
#そういえば、ほかにそういう言語思いつかないですね。
#名前空間に別名がつけられるのって。
#CLってそうじゃない?
#あー。CL はよく知りません。
#CLはパッケージに別名がつけられる
#単純にかたっぱしから (define prefix:xxx ...) みたいなのを羅列するマクロじゃだめかな。
#あるGaucheモジュールがexportしているシンボル一覧を得る方法ってありましたっけ?
#あるモジュールXが別のモジュールYをuseした「後で」Yに定義が追加される可能性があるのです。
#うげ
#それだ
#なるほど。
#@び えーっと、module-exportsだと…明示的にexportしてないやつが出てこないな
#prefix:xxx wo(with-module M xxx)
#あ。まちがえた。
#そしたら、とおる。さんが言ってるようなマクロができそうだな
#だけど、マクロに別名付けるのにはdefineじゃ無理だよね?
#prefix:xxx を (with-module M xxx) に展開するマクロを生成するとか。
#define だとだめなので。
#あ、だめか。
#そもそもそんなマクロかけない。
#マクロはファーストクラスじゃないし
#あと、別名つけても元の名前が消えるわけじゃないからなぁ
#関係ないですが、ぼくは C のコードでも M-( で () を出すので、関数名と括弧の間にスペースが開いちゃうんですが、やっぱり気持ち悪いですか？
#SGI の STL のリファレンスのサンプルとかはスペースが開いてるので親しみがもてるんですけど。
#あれ、改めてみてみたら SGI のサンプルもスペースがつまってる。ここじゃなかったかな。
#GNU coding standard はスペース要求するから、emacsとかgccのソースはあいてます。Kernel Normal Formはスペースなしを要求するので、NetBSDのソースなどはあいてないですね。
#個人的にはそろってないのが一番気持ち悪いかな。
#prefix:xxx -> (with-module M xxx) はリーダマクロがあれば変換できます。実際、M#xxx -> (with-module M xxx) は実験したことがあったんですが、なんか問題があって止めたような…どっか予期しないところでモジュラリティが崩れるとかだったかな
#1.三菱東京UFJに電話して聞いたら、法人の口座開設は直接ユニオンバンクに聞いてくれと言われた
#2.ユニオンバンクに国際電話して日本語で聞いたら、US法人がない会社の口座は税法上作れないと言われた
#ということでUS法人が必要なことまではわかりました。
#ありゃ。
#ハワイのLLCなら、州内に連絡先住所と代理人がいればつくれますが。代行業者もある。
#a,
#LLCだと外国人のownershipが面倒だったかな、と一瞬思ったんだけど、ストックホールダーに制限があるのはS-corportaionの方だったか。
#LLCは外国人でもだいじょぶだったはず。
#法人口座は、LLCの申請書類の受理証 (申請書類に番号が入ったやつが送り返されてくる) とタックスナンバーを持って銀行にいけば作ってくれます。代理人でokなはず。
#$100くらいで設立できたはず。維持費は年一回のannual report filingで$15くらい。あと税金の書類のfiling。どっちも電子的にできる。
#maa
#まあその手間に見合うかどうかですね。
#ありがとうございます。最近弊社にUSスタンフォード在住の役員が加わったそうなので社内で検討してみます。
#カリフォルニアは維持費高いですよ。年間$800だったかな。
#やはりハワイ法人ですかねえ
#Android Developer accountがapprovedになってDev Phone Buy nowとかいうリンクが表示されたけど、クリックするとあいかわらず元のページにリダイレクトされちゃう。ebayで買う鹿
#おお。ハワイ法人。
#日本は、最低でも年間 7 万円かかります。地方税の均等割。ハワイはめちゃくちゃ安いですね。
##> Minimum opening deposit requirement of $100.
#しまった。iPhone OS をアップデートしたら Xcode からつながらなくなってしまいました。新しい iPhone SDK を落とさないと。
#iPhone SDK 2.1.1?
#はい、いまはいってるのは、古いやつ。
#2.1GB。うちは 500kbps くらいしか出ないから、一晩じゃ終わらないかな。
#MacだとAndroid開発もラクチンです
#え、GB
#おお、そうなんですか？
#エミュレータで動画動いた(さすがにフレームレートは低いが)
#public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
//
setContentView(R.layout.main);
video = (VideoView)findViewById(R.id.video);
video.setMediaController(new MediaController(this));
video.setVideoPath("/sdcard/samplevideo.mp4");
video.start();
}#こんな感じ
#お。なんかわかりやすい。
#Clojure も動くんでしたっけ？
#どうでしょう。
#そのへんは(び)さんに任せた
#iPhone SDK は、Objective-C はまだいいとしても、Interface Builder が賢すぎてさっぱり仕組みがわからないです。
#Androidはエミュレータがクソ遅いことを除けば通常のEclipseによるJava開発です
#なんで遅いんでしょうかね。
#ああ、とりあえず、朝までに iPhone SDK がダウンロードできている事を祈って寝ます。
#おやすみなさい。
#何でもArmエミュレータの上にLinuxカーネルをのせてAndroid OSを動かしているとか
#電話できないとか以外は実機とかわらないです。
#おやすみなさい＞とおる。
#おお、CPUのレイヤをまるごとエミュレートしてるわけですか。
#エミュレータ起動時のタイムラグをさけるため、常にエミュレータを起動しながらコーディングする
#iPhone SDK のシミュレータは、普通に i386 バイナリを実行してたりします。だから、シミュレータ用と実機用でバイナリが違う。
#そうなんだ。i-Modeとかのエミュレータと同じだ
#Androidだと実機を接続すろのもエミュレータ使うのも、同じようにアプリをpublishして開発するのであまり変わらない
#qemuじゃなかったっけ
#Android?>qemu
#androidです
#だからWindowsよりLinuxやMac OSの方がAndroidエミュレータが速いのか
##このへんを使えばChaton Radar for Androidが書けるかも
#Gaucheのuseって、
#(1) require
(2) import
を順に実行するけど、
#(1) define-module
(2) select-module
(3) require
(4) 元のモジュールに戻す
(5) import
#といったように define-moduleも合わせて行なうようにすれば、モジュールファイル側に define-module がいらなくなっていいんじゃないかと思うんですがどうでしょう。
#define-moduleとかselect-moduleって少し冗長に感じるので。
#それだと、モジュールファイル側に自分のモジュールを記述する手段が無くはないですか?
#あっ、すみません。ちょっと具体例ありますか?
#イメージがわかなかった。
#同一の内容のソースなのに、呼び方が違うと別のモジュールになっちゃうって困らないかな、とか。useで読んだ時とloadで読んだ時で違ったりしないかな、とか。
#あっ、むしろそれを狙っていました。
#ひとつのファイルのソースを見た時に、その範囲でソースの意味が完結してない、というのが気持ち悪いのかな。
#main関数を描いておけば、単体で読み込んだ時は、コマンドとしても使えますし、モジュールとしても使えるので。
#確かにそういった気持ち悪さはあるかもしれません。
#a.scm と b.scm があって、(use a) (use b) と使ってもらったらいいけど、(begin (load "a") (load "b")) って使われちゃうとaとbが同じ名前空間にくっついちゃいますよね。
#そうなりますが、呼ぶ側が意図してそうしているんなら、それでもいいんじゃないかと。
#ふーむ。
#なんか、モジュールの指定ってファイル名での指定(ファイルの位置)と、ソースコード側での指定の2つがあって、2ヶ所で指定するのが面倒(ってほどでもないけど)かな、と最近思ったのです。
#select-moduleについては確かに冗長で、r6rs風にひとつのdefine-moduleフォーム中にすべて書いてしまうこともできるんですが、そうするとインデントが気持ち悪くなるのと、今のdefine-moduleの運用だとソースをスキャンしてモジュールに関するメタ情報を取りやすいってのがあります。
#ああ、確かに define-module がないと、メタ情報がとれなくなる。
#自分でモジュールのシンボルを調べる EmacsLisp を書いておきながら、define-moduleの利便性を忘れていた。
#ファイル名とソース側の指定はわざとdecoupleさせたんだけれど(単一ファイル内に複数のモジュール、とかたまにやるので)、運用上ほとんど常に一致してるんならデフォルトの動作としてファイル位置に基づくモジュール名が仮定されるってのはありなのかなあ。
#メタ情報については、useフォームとexportフォームを必ず先頭に置くって運用でもなんとかなるかもしれない。
#いつも define-module 〜 select-module までテンプレートにしていたのですが、Lisp使っているのにエディタのテンプレート機能に頼るのはなんか負けた気がして、もやもやっとしていました。
#Common Lispの環境だと、ソースを読んだ時にそのソースのin-packageフォームを認識してくれるんで、どのパッケージにいてもeval-sexpとかが正しく動くっていうのがありますね。
#普通のScheme modeだと、Gaucheのモジュールは知らないから、普通にC-c C-eするとREPLのカレントモジュールで評価されちゃう。
#うーん、いろいろ考えると、現状の姿がいいのかな。
#ちょっと考えてみたんですが、ソース作成者が想定する「正しい呼び方」というのがわからないのはやっぱり困るような気がします。私の場合、useされることを想定してdefine-module使って書く場合と、loadされることを想定してべたに(module指定なして)書く場合があって、前者をuseでなくloadするのはまあいいんですが、後者をloadでなくuseしたら色々困りそうな。何らかの区別がついてくれるとうれしいかも。
#もっとも、CLの場合はまた感覚が違って、だいたいpackage定義は別ファイルにまとめますから、個々のソースには(パッケージにかかわる指定としては)in-packageしか出てこない。それはそれで違和感無いから、メタ情報も単一ソース内に欲しいというのは単なる習慣の問題かもしれない。
#(ただ、defpackageだけの別ファイルを書くのはそれはそれで面倒なんですが)
#ちょっとイメージがわかないんですけど、「正しい呼び方」がloadになる例ってどんなのがあるんでしょう。
#基本的に第3者に公開するものってモジュールとして公開するので、基本 use しかつかわないのかなと思ったので。
#ああ、loadで呼ばせるのは、アドホックな対応であることが多いですね。他の処理系と共同で使う部分だけ別ファイルにくくりだしてあるとか、他のSchemeコードを最小限の手間でportするために外側のdefine-moduleは別ファイルで作ってソースをいくつかload or requireするとか。
#だからまあ、イレギュラーケースと考えていいかも。効率からいえば、レギュラーケースの手間を減らすのが正しい方向ではあります。
#なるほど、他Scheme処理系へのportを考えると、loadを使う局面もありますね。use が微妙に便利すぎるんですが、手間を減らしすぎて、過剰な最適化に陥るのもいやなので、バランスをとるのが難しいですね。
#あ、そうそう。あと、ソース自体に自分のモジュール情報が無い場合、EmacsでC-c C-lしたらどうなるんだろう。
#あれはloadしちゃうよねえ。
#カレントモジュールにloadするしかないですね。
#それはすさまじく不便なような気がする。
#うーむ。やっぱりしかたないのか。
#ただ、ここしばらく長期的な方針として「いかに記述量を減らすか」ということを考えてるので、define-module/select-moduleまわりは改善の余地ありとしておきます。
#select-moduleで知らない名前が与えられたら勝手にモジュール作ってくれるようにしといたら、実はselect-moduleだけでいいのか?もしかして。
#define&select-module
#一緒にしちゃうってか。
#名前はいやだけど。select-moduleにそういった機能を持たせるのはよいような気がする。
#モジュール名のスペルを間違えても、なかなか気がつかなくなるという問題はあるけど。
#そこはテストでカバーできないかな。
#まっさらのところにuseしたら、スペリングが違ってるとimportできないからわかる
#たとえばソースファイルは基本的に
#(in-module foo.bar.baz)
(use xxx)
(use yyy)
(export a b c d e)
#みたいな感じで始まる、みたいに運用するとか。
#ああ、それいいですね。
#define-moduleは、たぶんもともとはCLのdefpackageが頭にあって、いずれはモジュールに関するメタ情報を一ヶ所にまとめるフォームにするようなイメージがあったんじゃないかという気がする。自分的に。
#でも実際はbody部は普通のトップレベルとして評価しているだけなので、現状を見ればdefine-moduleが別フォームになっている意味はあまりない。
#空気読まずに質問です。
馬鹿な質問だったらすみません。
kahua-spvr から特権ポート(80)で開いてroot特権を放棄する(一般ユーザに切り替える)方法って無いのでしょうか。
kahua-spvr.scm の (define (start-httpd... を書き換えたら出来たみたいなんですが、どうも直接書き換えるのは気が引けるので..
#ああ、今はそういう運用はたぶん考えられてないと思います。
#そうですか、了解です。ありがとうございます。
#kahua-httpd自体、httpdとしては最低限の機能しか実装してないんで、どっちかというとローカルでの試験用とか、実運用するにしてもApacheなどをフロントに立ててreverse proxyでやるのが推奨です。
#(って、kahua-httpdの話ですよね? kahua-spvr自体はhttpdを話さないので、80をlistenしても困るような…あれ、記憶違いだったかな?)
#あ、でも今みたらkahua-httpdも結構がんばってるな。最低限の機能ということはないか。
#(define (start-httpd spvr spec)
(let* ((m (#/^\d+$/ spec))
(s (kahua-site-root))
(cmd (script-command spvr "kahua-httpd.scm"
(append (config-options)
`(("-l" ,(kahua-logpath "kahua-httpd.log")))
(if m
`(("-p" ,(m 0)))
`((,spec))))))
(httpd (run-piped-cmd cmd)))
(set! (ref spvr 'httpd) httpd)
(close-input-port (process-output httpd))))#ってなってるんですが、どうなんでしょう。
#なってますね。httpdの機能自体はkahua-httpdが実装してるんですが
#サブプロセスとして起動してhttpリクエストを処理させるのか。
#あれ、setuidする機能を付けた記憶があるが >kahua-httpd
#ほんとだ。
#--runasオプション
#kahua-httpd からは落とせるみたい。
#そうそう --runas です。
#なので、kahua-httpdを80番ポートで立てる時は、kahua-spvrからではなくて、別に起動するんです
#spvrから起動するのってどういうケースだっけ。cgiでしか運用してないから忘れちゃったな
#正直、そこまでの安定性も性能もまだないとおもうのでお薦めはしませんが
#なるほど
#開発中とかはkahua-spvr -H localhost:8080 とかして起動しますね >kahua-httpd
#元々は、kahua-spvrが内部にHTTPd機能を持ってたんですが、1.0に向けて開発を進めた時に分離したんです
#自宅サーバで、嫁のホームページをしばらくkahua-httpdとkahua-webで運用してたことがあります
#アクセスが1日に1000PVもないようなサイトなら一応運用できました
#ある程度の規模になったら、Apache等を介在させるんでしょうか。
#kahua.cgi/kahua.fcgをブリッジにして運用してますね
#後者はFastCGIです
#なるほど、勉強になります。
#フロントに立つHTTPdは、Apacheでもlighttpdでも運用実績はあります
#ブリッジに関しては、ajpやmod_lispというのもアイディアとしては出てるんですが
#サボっててまだやってません
#mod_kahuaなんて話も一時期あった
#ajpは、プロジェクトのメンバーのひとりがプロトタイプを2年くらい前に書いてくれてるんですがね...
#nobsunの説明だと、mod_kahuaは*.kahuaを解釈実行するモジュールだってことだったから、ブリッジとはちょっと違うかと思ってた
#今なら、KahuaプロトコルをしゃべるApacheモジュールを書けばいいかもしれない
#あれ、自分が書きかようとして放置しちゃったやつは、spvrにS式投げるブリッジのつもりだったけど。
#あ、そうなんだ
#それはどこかにソース残ってます?
#いや、ほとんど何も書いてなかったし(apacheのモジュールサンプルに毛が生えた程度)、コミットもしてない。もうどこにも残ってないと思う。
#そうですか
#mod_gaucheって書くとして、Gaucheの持つマルチスレッド機能とApache 2.2以降のスレッドモデルがどうなるのかよくわかってない&調べてなくて、そのままになってるんですよね
#mod_gauche内ではgauche.threadsの使用を避ければ問題ないんだろうか
#うーん、まず、gaucheのマルチスレッドについては、Boehm GCがpthread_createなどをインターセプトする必要があるため、Apache側で作られたスレッドと共存するのはたいへんだと思う.
#ああそうだ、Boehm GCの問題もあるのだった
#gaucheでスレッドを使わなければたぶん動くと思うけれど、ヘヴィに使うならメモリ空間が分かれてた方が何かと安心な気はするなあ。
#単純に、Kahuaプロトコルをmod_kahuaに喋らせる時、それをC/C++でスクラッチから書くのが馬鹿馬鹿しいなということだけなんですけどね
#kahua.protocol.workerをロードして、その関数を実行できればいいんだけど、多重化するなら結局mod_kahua部分がマルチスレッドに動く必要があるし、難しそうですね
#Gaucheはembedded interpreterとしても使えるようにしてるけど、その状態でGauche側にものすごいロードをかけるようなことをしたらスタンドアロンの時ほど効率よくはさばけないだろう。あ、でもブリッジにする程度なら大丈夫かも。
#なるほど
#define&select-module だと、Perl の package とおなじですね。
#Perl の package はスコープの中に限定できるけど。
#あと、Perl の場合は、use するモジュールはファイル名のサフィックスを .pm にすることになってます。
#個人的には define-module とか select-module とか書くのは、自由に対する代償だと思うので、割と抵抗ないですね。
Gauche > Archives > 2009/06/19