efclのブックマーク - はてなブックマーク

ファイル更新に耐性のあるテキストタグ手法を考える - .mjtの日記復帰計画
コンパイラの警告やシナリオのコメント、クラッシュレポートの処理等、"行の特定位置にタグを振りファイルが更新されても追跡したい"という需要がそれなりにある。...需要自体は有るんだけど、実装がバラバラになってしまっているので、ちゃんとモデル化し、フレームワークとして統一を図りたい。行コンテンツとblame履歴によるアドレッシング今回考えたタグのモデルは、ファイルを行に分割し、各行のコンテンツおよび初出現リビジョンのハッシュをアドレスとする。このアドレッシングにより、ファイルが更新されたとしてもタグを頻繁に書き換える必要は無い。もちろん、行を書き換えた場合はハッシュ値が変わるためタグも"打ち直し"が必要になるが、それでも行番号を使用した場合よりも高い生存率が期待される。これはblameにタグを付けるのと同じと言える。つまり、 VCS上の履歴を伴ったファイルにしかタグ付けできないし、タグ
efcl 2019/02/11
変更耐性がある位置上のタグ付けのモデル化。 blameでの追跡できるモデル

github

バージョン管理
リンク
非同期I/O APIの設計がなかなか難しい - .mjtの日記復帰計画
yuniで実用的なプログラムを書くためには、どうしても非同期I/Oライブラリが必要になる。というわけで黙々と設計しているけれど、これがなかなか難しい。非同期I/Oライブラリの難しさそもそもOS/処理系毎に別物が必要 "非同期I/Oライブラリなんてlibuv一択だろ"という意見も有るかもしれないし、実際、Node.jsはlibuvのデザインの実用性を証明しつづけていると言える(実際には逆で、Node.jsのOS抽象化レイヤとしてlibuvが実装されている)。が、libuvはカーネル機能の抽象化でしかなく、同じデザインがyuniに適用できるとは限らない。yuniは既にKawa(Java上のScheme実装)やIronScheme(.net上のScheme実装)をターゲットしているので、これらでも動作するような配慮が必要になる。もし、yuniの非同期I/Oライブラリを単なるlibuvのバイ
efcl 2018/01/16
非同期I/O APIの設計。 libuvがカバーする範囲、OSやライブラリによって異なる非同期の抽象化について

program
リンク
中間言語としてのJavaScriptはどうなったのか - .mjtの日記復帰計画
prev: http://d.hatena.ne.jp/mjt/20080904/p2 なぜか３年前の記事が急にブックマークされていたのでフォローする記事。 ↑の記事の1年後、InfoQの記事( http://www.infoq.com/news/2009/09/javascript-compilation-target )でいくつかのJavaScriptにコンパイルする言語が紹介された。もちろん、GoogleのGWT(Google Web Toolkit)もJavaScriptを出力するJava環境と言える。先の記事で触れたエミュレータでの活用は、見たところDirect-threadingによるものに限られているように見える。つまり、CPU命令をJavaScript的なfunctionとして実装し、CPU命令と１対１対応させる。Google V8のような、Direct-threadin
efcl 2011/05/02
JavaScriptにコンパイルする言語 Emscripten

JavaScript

program

言語
リンク
1