BugStories
Shiro(2011/09/16 02:28:53 PDT):ハードなバグに関する話って読んでてとてもおもしろいのだけれど、 いざ事例を探そうとすると思うように探せないので、何となくまとめておこう。 好きなように足してください。自分で書いてリンクするのも歓迎。 (2017/05/06 17:40:34 UTC: 新しい記事を前に足してゆくように変更) How we found and fixed a rare race condition in our session handlingFinding a CPU Design Bug in the Xbox 360オーバーフローが引き起こした面白いバグの話The Horror in the Standard LibraryA tale of an impossible bug: big.LITTLE and cachingThis is s
Lisp:Geometry
(Shiro: 私はNichimen Geometryになってから、 プラグイン書き等で少々いじったにすぎないので、 Symbolics時代のこととか、周辺事情にもあまり詳しくないっす。 識者の方、がんがん修正してください)。 (khashi) 情報追加しといたんですが、まとまりがなくなってしまったんで、適当に整理しといてください。 Geometryとは Lispで書かれたモデリングツール。 もともとSymbolicsのグラフィックス・パッケージS-Products のモデリング・モジュール。 1981年公開の映画「トロン」のモデリングを担当してたLarry Maloneによって開発された。 このツールが最初に日本でデモされたのは1985年の筑波博覧会アメリカ館。 市販されてから20年の歴史を持っている。 尚且つ20年間1人のプログラマによってメンテナンスされている。 開発当初は、Zeta
Gauche:デバッガ
GaucheにデバッグAPIを組み込むに当たり、よりよいインターフェースや実装などを議論するためのページです。 こんな機能が必要 この実装だとXXXの問題が避けられる などのアイデアがあればどんどん書き込んでください。 (以前の内容はデバッガに移されました) 議論にあたっての制約と目的について Shiro(2008/11/19 02:47:17 PST): エンジニアリングはトレードオフです。 重要なのは色々な方法を考えることではなく、 考えた方法のうちから与えられた制約と目的にベストフィットするものを 選択することです。つまり制約と目的が明らかでない段階での議論は無意味です。 デバッガ一般の話ではなく、Gaucheについて考える場合は、 Gaucheの制約と目的を踏まえて議論をお願いします。 実行時性能重視。デバッガの存在が実行時にペナルティにならないこと。 プロダクション投入可能な実行
Y Combinatorを始めた理由 ---Why YC---
Y Combinatorを始めた理由 ---Why YC--- Paul Graham, March 2006 (Rev. August 2009).[訳註1] Copyright 2009 by Paul Graham. これは、Paul Graham：Why YC を、原著者の許可を得て翻訳・公開するものです。 <版権表示> 本和訳テキストの複製、変更、再配布は、この版権表示を残す限り、自由に行って結構です。 (「この版権表示」には上の文も含まれます。すなわち、再配布を禁止してはいけません)。 Copyright 2009 by Paul Graham 原文: http://www.paulgraham.com/whyyc.html 日本語訳：Shiro Kawai (shiro ＠ acm.org) <版権表示終り> Paul Graham氏のエッセイをまとめた『ハッカーと画家』の
naoya_t:MacOSX:Gauche.frameworkを作ろう
いまのGaucheだと % ./configure --enable-framework % make framework で Gauche.framework が出来ます。 framework.sh にあるとおり、こうして出来る Gauche.framework はアプリケーションバンドル（OS Xのアプリケーション形式、ほげほげ.app みたいなやつ）内にただコピーするだけで、プライベートフレームワークとして利用できます。Gaucheがインストールされていないマシンにもアプリケーションバンドルを単純にコピーできるのが利点です。（共有フレームワークは Gauche ではサポートの予定がないようです） 但し、こうして出来るのはビルドした環境用のライブラリのみです。 以下、OSX 10.4以降 Intel/PowerPC 両環境で動くフレームワークを作ってみるメモ。もっと簡単かつ確実な方法が
Scheme:Lisp プログラマのためのPerl入門
Lisp プログラマが Perl を学ぶときの要点 Perl は Lisp ほど関数的でない。map, grep などの便利な構文、無名関数はある。 Perl のオブジェクトは「リファレンス変数を bless したもの」。 bless とはパッケージ名をリファレンス変数に結びつけるもの。 Perl には構文上はクラスがない代わりに、 bless された package（名前空間）を使ってメソッドディスパッチをする。 便宜上、パッケージ名をクラスということは多い。 Perl のオブジェクトはデータ型についての情報は持たない。（メソッドだけ。） Perl のクロージャーは sub で作る。Perl 6 ではより簡潔に作れる。 # 加算関数 #!/usr/bin/perl use strict; use warnings; sub make_adder { my $n = shift; retu
Scheme:マクロ:CommonLispとの比較
安全なマクロ束縛変数の衝突自由変数の衝突S式≠プログラム?議論、コメント 関連: Scheme:マクロ:anaphoric ifの代替, Scheme:マクロの効用, Scheme:マクロの危険 2007/05/15 00:08:13 PDT追記: 黒田さんの再反論と、それに対するコメント:Scheme:マクロ:CommonLispとの比較:意味論。 安全なマクロ MSIの黒田さんの About Schemeより: first class symbol がないということは様々な弊害を引き起こしますが、なかでも深刻なのは、名前の衝突に関して無力な点です。 そうすると、実質 macro が書けない… 例えば以下の arithmetic-if は、いかなる名前とも衝突しない uninterned な名前を var に割当てることで、 どういうコンテクストにおいても動作保証のできるマクロ展開結果を
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Gauche:循環リストの読み書き
Release:arc0
[