オフィシャルなArcをもとに、ユーザーがいろんなことをして遊んでいる感じのArcリポジトリだ。バグフィックスや有益なライブラリなどが追加されていて、実用的である。オフィシャルなArcには、公開されているリポジトリなどない。最新のものがつかいたい場合、Anarkiは選択肢のひとつとなるだろう。名前のとおり、wikiスタイルのリポジトリということなので(なにそれ?)、みんなが好き勝手にpushしたりする。フリーダムさがたまらない。壊れていることもあるので注意したい。最近はガイドラインっぽいものがつくられたり、更新する人も減ってきているため、安定しているかもしれない。なんとか言語でArcを実装してみました系ここにまとまっている。Forumに出入りしている人は、当たり前のように処理系を実装しちゃうひとたちばっかでこわい。基本的にArcのサブセットだったり、独自の機能を盛り込んでいたり、そもそも、すでに別言語になってたりする。純粋にArcを楽しみたいなら避けるべきかもしれない。おもしろいと思うが、ぼくもあまり追いかけてはいないため、これ以上の言及はやめておく。arc-mgarc-mgは、ぼくがメンテナンスしているArc処理系だ。処理系を自作したい欲求は日増しに高まるが、あくまで、オフィシャルのArcをベースとしている。Forumであがったパッチやライブラリを取り込んだり、独自の拡張、ライブラリの追加などをやっている。ぼくが必要だと思った機能、ライブラリを優先的に実装しているので、万人には向かないかもしれない。少なくとも、ぼくがつかっている範囲では、十分実用的だ。mgはmgikenの略であり、ガンプラでいうところの、マスターグレードだ。スタンダードアイテム的な位置づけを目指したい。Graham)にしかつくれない。これから、Arcをはじめる場合は、まずこれを試してみたらいいのではないかと思う。現状、サポートはあまり期待できないが(自分で言うな)、フィードバックは歓迎する。arc-mgすればok。Racketもまとめてインストールされるので楽ちん。自作のライブラリについても、ebuildを用意してある。自分用につくっているということもあり、Gentooでつかうことを前提としている。Linuxでなら問題なく動くと思う。cloneしてmakeすれば大丈夫だと思う。依存関係などは、がんばって解消してほしい。まとめざっくりとArc処理系の紹介をしてみた。別にArcを普及させようとは思っていない。Gentooを激しくオススメしておく。これを機会に、GentooとArcをはじめよう。2012の8日目の記事です。今日は、みなさんお待ちかねのArc。Arcでリーダーマクロとは?はい、そんなのない。Grahamが公開しているオリジナルのArcには、リーダーマクロはまだない。ここで話を終わらせてもいいのだが、とりあえず、Arcのread関数の定義でも見てみることにする。read関数は、arc.arcで定義されているので、該当部分を抜き出す。portかの判定をしている。おっと、実際の処理はsread関数みたいだね。それでは、sread関数の定義を見てみる。ac.scmの該当部分。うーむ、これはSchemeか。ご存知のとおり、ArcはRacketで実装されている。expr))))xdefはRacketからArcのネームスペースにバインドするためのマクロ。ああ、結局、Racketのread関数に丸投げしてる。Racketのread関数は終端まで行ったらeof-objectが返るので、それをArcのためにラップしているだけだ。readの略のようなので、そのままだね。以上、Arcのread関数の定義を見てみた。要するにRacketのread関数に丸投げなので、Racketのリードテーブルを変更してやれば、Arcでもリーダーマクロっぽいことがやれそうだ。いうわけで、Racketのリードテーブルのドキュメントを読んでみる。Racketも英語も苦手。しようもないので、ArcからRacketのリードテーブルを変更するライブラリを公開している人がいるので、それをつかうことにしよう。いうときに、ユーザーの多い言語は便利ですね(遠い目)。ちなみに、このライブラリを少し修正したものを、arc-mgにも取り込んでいる。}で書けるようにしてみよう。scheme-t)簡単だね。"foo"))ばっちり。普段コードを書いていても、通常のマクロで十分なことが多く、リーダーマクロの最適な使い所に出会うことは少ないかもしれない。自分の道具箱の中に忍ばせておくと、いざというときに表現の幅が広がっていいのではないだろうか。flagをいじってみてもXに依存してしまい、ビルドが通らない。MASKされている状況なので、バグかなにかだろうと思い、そのうち修正されるのを期待して放置していた。修正される気配はないし、やっぱり最新版つかいたいので調べてみた。v5.2くらいから、X依存前提みたい。Textualという、別パッケージになっているらしい。いうことなら、ebuild書くだけ。無事インストールできた。https://github.com/mgiken/portage-overlay/tree/master/dev-scheme/racket-textual正直、ArcのためにRacketをインストールしているだけなので、最近の動向とか、さっぱりわからない。面白そうな変更とかいろいろ加えられてるみたいだけど。19:03:15一応、hachioji.pmメンバーなので、2日間ずっとLT-THON会場にいた。最終日の撤収作業を少し手伝っただけなので申し訳ない。事前準備とか大変だったと思う。すばらしいイベントだった。本編はまったく聴講してないので、みんなのレポートや動画をまったりと。普段あまり外に出ないので、人の多さに疲れた。アイコンしか知らないような、ハッカーと呼ばれる人たちを見てきた。ぼくが憧れてるのは、80年代のMITハッカーなので、ちょっと物足りない気もした(ルックス的に)。いうわけで、LT-THONしてきた。mgiken技評さんのレポートにピックアップされたみたいでうれしい。準備不足だったし、疲労もピークでグダグダだったと思うが、伝えたいことは伝わったみたいでホッとした。Arcというそれなりに破壊力の強いコンテンツを持ちながら、生かしきれてないなと反省。反響を求めるなら、もっとネタに走るべきなのかもしれない。あまりに、クソまじめにArcやり過ぎてるせいか、ネタに走るという発想がなかった。自虐ネタなら大量にあるのに。ちなみに、Arc-users.jpの編集者の応募は未だにゼロです。このイベントを通じて、楽しむことの大切さを実感した。いえば、某言語コミュニティとか、いまいち方向性がわからない。普及させるとかいう前に、まずは、自分たちが楽しむことを優先すればいいと思った。これから百年かけて、Arcのコミュニティを育てていきたい。16:14:17YAPCの準備中、ふと、*-users.jpブームのきっかけは、YAPCだったなーなんて思い出した。2008年といえば、Arcの最初のバージョンがリリースされた年でもある。なんだか感慨深いものがある。Arcやってるんだもんな。そんな思い出に浸りながら、重い腰を上げた。wikiっぽいなにかをでっちあげた。箱だけ用意しただけで、まったくのノープランだ。編集してくれる人を募集中なので、Arc-users.jpを見てください。ちなみに、4年間で、Sinatraでつくろうかと思う規模のアプリなら、Arcで書きたいと思えるレベルには育ててきた。人知れずだが、Arcは前進しているのだ。ぼくは歩みを止めない。ブームが去った後ってのはヒドいものだ。サーバ落ちてたり、ドメイン失効してたり、スパムサイトみたいになってたり。ruby-users.jpとか、python-users.jpとか、それはヒドいものだ。19:41:05YAPC初参加だが、LT-THONという楽しそうなサブイベントが企画されているらしい。以前から、ちょくちょく遊びに行っていた、Hachioji.pm主催ということで応募した。当選したみたいなので、ArcネタでLTやります。29日午後2の回です。詳しくはタイムテーブルを確認してください。会場で、こんなこと叫んでるとヌッコロされそうだが、正直、そんなにPerlに興味がない。本編よりLT-THONのほうが面白そうだと思ってしまうから怖い。当日は、LT-THONの会場でうだうだしてると思うので、気が向いたら声かけてください。いうか、本編のタイムテーブルとかノーチェックなので、これは聞いとけみたいなトークがあれば、誘ってください。23:53:28適当だけど、とりあえず書いてみた。https://github.com/mgiken/portage-overlay/tree/master/dev-db/ArangoDBGitHubで管理されてるプロジェクトの、ebuildを書くベストプラクティスが知りたい。12:51:28『リーダブルコード』を読んだ。評判通りいい本だった。ぼくは、普段からできるだけ読みやすいコードを書くように心がけているつもりだ。無意識に俺色なコードを書く癖がある。定期的にこういう本を読むとハッとさせられる。ところで、明日の自分は他人だとか、自分の書いたコードも1日経てば忘れてしまうなんて、よく言われているが、ぼくはそういう経験が少ない。他人のコードを読むことに慣れすぎているからかもしれない。俺かー!」なんて憤慨することも多い。忘れていても見たら、だいたいすぐに思い出せる。未来の自分が憤慨しないで済むためにも、読みやすいコードを書くことは大切だ。あと、当たり前すぎるからなのか、あまりはっきりと語られることが少ないような気がする、ひとつの原則がある。「理解できないコードは書かない」ぼくは昔からこの原則を心がけている。この原則さえ守っていれば、そんなに酷いコードにはならないんじゃないかと思う。この本には、読みやすくて美しいコードを書くためのテクニックがつまっている。自分が理解できないコードでは意味がない。カタチから真似をするのも有益だ。それに加えて、ちゃんとプログラミングスキルも伸ばしていきたい。Feedに対応しました。http://mgiken.com/blog/feedあと、おもしろそうなので、Zenback設置してみた。17:17:57簡単に言うと、こういうことがやりたい。以前から、いろいろ試行錯誤してみたものの、結果的に、これ無理だろってあきらめかけていた。–enable-gui=noと–without-xのvimでは残念ながらclientserverが有効にならないのである。簡単につかえるのであれば、誰か教えてください。そんな日々を悶々と過ごしていたのだが、今日、なんとなくvim-slimeのソース読んでたら、なんだかtmux使ってごにょごにょ面白いことやってるわけ。そこで、ピコーンと閃いた。はい、tmuxで今開いてるwindowの最初のpaneにvimを固定するスクリプトできた。https://github.com/ryuji/vis/blob/master/visぼくはvimのタブ機能はつかっていないので、バッファを開くようにしてるけど、タブで開くオプションとかもあればいいのかもしれない。tmux経由でなんでもコマンド流せそうなので、今はファイルを開くことしかやってないが、いろいろほかにも応用できそうな気がする。あと、tmuxの1セッションにつきvimをひとつにするっていう実装でもよかったのだが、windowが違ったら、そこは別世界だという認識でつかっている。tmuxをあまりつかいこなせてるとは言えないので、今後変更するかもしれない。18:45:19これまで、フリーランスとして活動してきましたが、2012年4月17日に合同会社を設立しました。フリーランス時代からの仕事を引き続き行いますが、ゆるやかに、自社製品・サービスにも力を入れていきます。これから多くの困難が待ち受けているかと思いますが、今なら空だって飛べそうな気がします。