#スクリプト言語処理系って、その言語に興味のない人からしたらただのめんどくさいものでしかないんですよねぇ。プロトタイプ段階を終えたら、configure みたいなポータブルなシェルスクリプトを生成するか C で書き直すかしかなさそう。
#その点 Windows だと標準で JScript が使えるので結構便利です。
#デプロイメントの問題は大きいね。確かに。サーバサイドで自分の面倒を減らすのに使うならともかく、作ったものを配るとなると。
#かといって
#デフォルトで入っているように持ってゆこうとしても、そうするだけで大変だけど、それが出来たとして、上でリンクをあげたMongrel2みたいなバージョンの問題が生じるし。
#ニッチな処理系としてはやっぱりランタイム全部まとめて1ファイルで気軽に配れるような簡単な仕組みがあるってのが重要かなあ。
#Gaucheのランタイムは今15Mくらいか。このくらいなら今時、アプリ毎に同梱しちゃっても気にならない量ではあるな。ひとつのマシンにいくつもコピーが入るのは気持ち悪いけど。
#ああ、そういえば、もうすぐ Ypsilon 内臓のピンボールがでるかな？
#あ、内蔵。
#zipかtarのフォーマットをファイルシステムとして見えるようにしておければ、少なくともライブラリの*.scmファイル群については簡単にひとつにまとめられるな。
#同人ゲームとか作って CD-ROM で配布するときとかもアクセスが速くなっていいかも。
#CryEngineのpakファイルって、dllも一緒にしてるんだっけ?
#いえ、DLL はぜんぶばらばらです。
#だよね、OSから読めないとならないもんな。
#「1ファイルで配れる」というのではないですが、Gauche自身をコンパイルするときに、mylibとかmyextとかのサブディレクトリを作っておくと、それらのコンパイルやコピーも同時に行ってくれる、といった仕組みがあると単体のアプリが作りやすいかなと思いました。あと、インストールするときに gauche 以外の名前が簡単に指定できる必要があるか。
#ふむ、アプリの階層の下にgaucheを置くのではなく、gaucheの階層の下にアプリを含めてしまう、という考え方ですか。それもありか。
#本格的にするなら、自アプリのconfigureを書くのでしょうが、configure作るの面倒なので。
#eof-objectのリテラル、というのはwrite-read invarianceの観点から厄介なので(読みもどした時に#<eof>が帰ってきたらそれがデータなのかほんとのファイルの終わりなのかわからない)作ってなかったんだけど、
#全部のSchemeファイルを間にeofリテラルを挟んでつなげて、先頭部分へのインデックスを持たせたら、そこへseekして普通に読んでけば元のファイルの末尾でeofリテラルを読んでおしまい、とすることができるな、とふと思った。
#eofリテラルのもうひとつの応用例は、スクリプトファイル中に書いとけばそっから先は読まれないから、その先にドキュメントとかを置いておける。
#2つ応用例があるということは実装しても良さげな気もするけど、なんとなく間違ってるような気もする。もともとeofって情報はメタ情報なので、それをコンテントの同じレベルに書けてしまうのはやばげ、という感覚。
#Schemeファイルをつなげるのに関しては、インデックスに先頭と終端を入れといて、その範囲だけ読めるvirtual portを作る、というのでも解決できるしなあ。
#＞CryEngineのpakファイルって、dllも一緒にしてるんだっけ?
#CryEngineのpakファイルは実は単なるzipファイルです
#それは知ってるのですが、そのzipの中にdllも入れられたかどうか覚えてなかったので。
#＞shiro @theoria Gaucheがどうなったら「使える」ようになりますか?
#Hadoopのジョブが書けたらです
#今のプロジェクトではJVMで動いてまあまあ有名だからClojureを採用することになったのです
#さいしょはHadoop Streamingというインターフェースを使ってGaucheで書いていたのですが、色々制約が多いので結局JVMな言語になっちゃった。
#ああいいな >ClojureでHadoop
#やー、でもClojureよりGaucheの方が好き
#今の仕事で、しばらく前までHadoopのJobをいろいろ書いてたんですが、Javaだとやはり書きづらい。木に竹を接ぐという風情がぷんぷん。
#うん、それはわたしもそうですがね
#JavaはS式になってマクロとクロージャが入ればよい言語
#というのが、自分の求めるラインなのにClojureはいろいろやりすぎ。過剰。
#というか、今となってはGaucheは疑問の余地なくFirst Callなので。なーんも考えないでGaucheでアイディアを練るという意味ではGaucheがネイティブ言語になりつつある。
#うーん。JVM上に実装された動的言語の中ではClojureが一番シンプルで筋がいいと思うのだよねぇ。Javaは正直、Eclipseの助力なしに書ける気がしない(笑)
#むしろ、EclipseがJavaコードを書く助けを自分がしているような気になります。
#ひょえー
#Eclipseってそんなになんというか、偉いのか
#そういやJavaやpom.xmlをEmacsで書いてたら同僚にびっくりされたっけ……
#僕もいちばんネイティブなのはGaucheなんですけど、Common Lispでもいいかなとも思う。この二つはSTMのようにイライラする組み込み要素がない。
#そっかー。JVMとネイティブのマルチバックエンドな処理系としてはBiglooとかあるけど、バックエンドを複数持つのは開発パワー的にきついかなあ。
#バックエンド言語での実装を最低限にしてほとんどSchemeで書いちゃえば楽なんだろうけど、たぶん(特にJVMで)性能が出ない予感。
#JVMって、動的言語のインフラとしてはどうなんすかね?
#どうなんすかね? ってのもずいぶんな質問の仕方だけど
#そもそもが、動的な言語を効率よく動かそうと設計されたものじゃない気がするので
#TCOがネイティブでサポートされてないのが関数型にはきつい感じ。スタックフレームを自前のクラスで管理しないとならなくなる。
#まあそれをやると継続がシリアライズ可能になるっておまけもついてくるけどね。
#そのあたりが、Clojureが自動的なTail Call Optimizationをサポートしなかった理由だと読みました
#うーん
#あ、Bigloo使ってもよかったのか。フェーズ2では使ってみます。
#でもGaucheの場合既に自前のVMを持ってるから、JVMの上に自前のVMを載っけたら性能的にはどんなもんだろう。
#自前のVM部分を差し替えるのは難しい? 難しそうだな...
#JITとの相性次第って気がする。VMのコードの実行パターンって結構偏ってる気がするから、それを認識してくれたらわりと性能が出るかもしれない.
#ああ、Gauche VMをJVMに差し替えるのは難しいでしょうね。主にTCOと継続絡みで。
#ですよね。うーむ。
#BiglooのJava backendの性能には興味あります。もし使うことがあったらどんなもんか教えてください > theoria
#なんつうか、自分の時間でJava backendに手を出したくないのは、JVMの制約との泥沼的戦いになりそうだから。他からの予算がついたらやらないでもないけれど、先行実装がいくつもある現状では望み薄だなあ。
#Biglooって名前を聞いたことしかないな...
#そうですね。それに、そもそものGaucheの目指した、「軽量なスクリプトエンジン」とも相容れない感じですよね >JVM
#ClojureがJVM言語として強そうなのは、Richは少なくともJVMを嫌ってはいないだろうってとこ。好きとまで言えるのか、単に割りきってるだけかはわからないけど。
#結局、UNIXな文化とJVMベースの言語実装って相性悪くて仕方ない気がする。そして、わたしがGaucheを愛用するのは、UNIXな文化との相性の良さが大きな理由のひとつなので。
#JVMって、なんていうか独立したユートピアですよね……。世の中に
#正直、シグナルハンドリングもまともにできないんじゃ、怖くてUNIXな世界では使えない。他と連携できないもの。
#JVMしか環境がなければ諦められるんだけども。
#了解＞shiro
#連携してはいけないのかもしれない！
#そうそう。そもそもが Java OS なんて夢があったように、Stand aloneなものなんだと思う。そういうところは、ちょっとLisp Machineぽい
#そのうちDalvik VMが数で圧倒するので問題ありません＞JVM
#JVM言語としてClojure以上に使い勝手を良くするには、多分Rich以上にJVMを好きにならないとだめだけど、それは難しい気がする。好きにならなくても職人に徹するという道もあるが…
#ましてや今後OracleがどうJVMを発展させていくか、全然読めない状況だと、モチベーション維持するのが難しそうだなぁ
#むー、でもこんだけインフラとして拡散した今、Oracleの舵取りだけでJVMが滅びちゃうことってあるかな? ライセンス絡みで変なこと言い出したらまずい? JVMの仕様自体が完全にオープンならクリーンルーム実装は生き残れるよね。
#OracleがJVMを捨てるってことはないだろうと思うけど、技術のことを何も分かっていない人が意思決定し始めると変な方向に行くと思う。少なくとも2010年代前半はDalvik VMの勝利だと思う。だから奴らはAndroidと敵対したのです。
#んー、Dalvikについては大した知識はないけど、そもそも立ってる土俵が違うというか、本来はJVMが欲しくて仕方なかったパイをかっさらっただけで、元々JVMが抑えていたパイを奪い取りそうな気はしないのだけど
#で、JVMが滅ぶってことはないと思うのだけど、Oracleがおかしな動きをし続けるようだと(訴訟乱発とか)、JVMから逃げ出す動きはありそうな気がする。クリーンルーム実装の生き残りは可能だけど、現状だとSun由来のJVMに匹肩できそうな完成度のものってあるかなぁ。Googleあたりが人と金をつぎ込めば可能なのかな?
#Dalvikは組み込み向けに特化したレジスタマシンで、JVMバイトコードからコード変換してDalvik VM用のバイトコードを生成する。 http://bit.ly/dg3Dfv インストールベースではJVMを圧倒することになる予定。 #ふむ
#クラウドのプラットフォームとして何らかの仮想化アーキテクチャは必要とされると思うんだけど、GoogleならもしかするとJVMがダメになったら独自
#VMでも作ってくるかも? そしてgoが滅茶苦茶速く走る。
#App Engineってそういう方向なのかしら
#そういえば、App EngineではPythonとJavaが開発言語なのだけど、Goってサポートされないのかな
#Javaというか、JVM言語か。Clojureでも開発できるしデプロイできるようだし(まだ試していない)
#今はJavaバイトコードからDalvik VMのバイトコードに変換してるけど、直接Dalvik VMのバイトコードを吐けるコンパイラぐらいはすぐ作りそう＞Google
#Goってネイティブコンパイラだよね? RT : (び): そういえば、App EngineではPythonとJavaが開発言語なのだけど、Goってサポートされないのかな
#そうだっけ。よく知らないけど。別にGoという言語がネイティブコードをはかにゃならんてわけでもないでしょうし。あるいはApp Engine向けのネイティブコード(そんなものがあるのかは知らないが)を吐いて、そいつをサンドボックス内で実行するとか、そういうのはないんかなぁ、と思ったまで。
#最近、自分の演奏のボトルネックは手より頭の方にあるような気がしている RT: @bizenn: Communication Breakdownのリフを弾いていると、一種の筋トレの様相を呈して来る。まぁ、高速メタルのダウンストローク合戦に比べればぬるいもんですがね。あのダウンストロークの連続からすっと力を抜いて上の方ほ弾くのは、案外アスリートっぽい動き。
#ひたすら繰り返し練習してると手癖として筋肉が覚えるんだけど、それは形で覚えてるだけなので、手だけで弾くことになって正確さが担保できない。まあ完全に形を覚えちゃえば別なのかもしれないけど。
#頭の中で正確に音をイメージしてそれを手に伝えるところが詰まってる感じがする。
#一応そういうプランはあるんですが… examples/minimum-viewer.scm
#おっと
#一応そういうプランはあるんですが… examples/minimum-viewer.scm とかとっかかり RT: @VoQn: OpenGL → Gauche-gl → XXXX な感じでもう一段階LLな感じのライブラリがあるとProcessingより気持ちいいグラフィックプログラミングができそうなんじゃないかと思っている自分はSchemeが好きすぎる
#@VoQn: parameterは遅いです(今のところ)。リアルタイムグラフィックアプリで多用するのはあまりおすすめしません。
#ヒャッ びっくりした
#ここのチャットルームでの内容が @chaton_gauche に流れているのですね
#minimum-viewer.scmというか、gl.simple.viewerですね。minimum-viewerはそのサンプル。
#ほんとはこの調子で便利なラッパー関数をどんどん追加したいのだけれど、忙しさに紛れて止まってます。
#そうですね。わたしはもともと手が速く動く方ではないのですが、速いフレーズをモノにした時って、ちょっと時間感覚が妙な感じになります。フレーズの先を見渡していると同時に、ピッキングのひとつひとつを都度微調整しているような。
#私の場合は楽譜じゃなくて耳で憶えたフレーズか、コードに合わせて適当に出てくるフレーズなのでちょっと違うかもしれませんが。
#トレイルランニングで下りを走っている時にも同じようなことを感じることがある。限界に近いスピードで走っているのに、妙に先が見えていると同時に、着地の一瞬一瞬を微妙に修正している自分が意識できることがある。
#まぁ疲れて来るとだめなんですが(笑)
#うまく弾ける時って頭と手がつながってる感じがしますね。ただ繰り返しによって筋肉に覚えさせて手癖で弾いている時って、手が勝手に弾いててつながってない感じがする。調整が出来ないし、ちょっとでもポジションがずれると間違えまくるし。
#でも手が覚える方が頭が覚えるより早くて、だらだら練習してるとつい手癖だけで流すようになっちゃうんですよね。最近自覚するようになりました (やっと)。今やってる曲は手癖ではまず弾けなさそうなので脳みそ絞る感じで練習してます。
#お、0.9かな。嬉しい。RT: @tana_ash: Ubuntu 10.10のGaucheは新しくなってるのか やっと対応してくれたのか...
Gauche > Archives > 2010/09/23