問題はGoogleがMozillaの息の根を止めるかどうかではない。いつ止めるかだ。 わたしは理念としてのオープンソースを愛している。だが金は商売の潤滑油だ。そしてMozillaとFirefoxの開発を永らえさせているのはGoogleの金だ。eWEEKの同僚クリント・ボールトンは、MozillaがどれほどGoogleに依存しているかについていい記事を書いた。「Mozillaの資金の88%はGoogleから出ている。GoogleはMozillaに金を払ってFirefoxブラウザでデフォルトの検索エンジンになっている」 Firefox 1.0がリリースされた2004年11月は、Googleが検索大手になるべく台頭してきた時期と一致する。検索関連の提携は、GoogleとMozillaの双方にとって幾つもの点で好都合だった。MicrosoftのInternet Explorer(IE)はMSNがデ
Windows Vistaが2回目の誕生日を迎えた。だが、誰も気にも留めなかった。 確かに世の中には、お父さんやお母さんが自分の大切な誕生日を忘れてはいないかと不安に思いながら眠る子供もいるだろう。2年前の11月30日、米Microsoftは企業向けにWindows Vistaをリリースした。だが今年の11月30日には、ファンファーレもなければ、2周年を祝う義務的なコメントも発表されず、Microsoftの従業員ブロガーによるコメントすら一切なかった。なんてことだ。Vistaはどうなってしまったのだろう? 第2のWindows Meだ。 Microsoftは既にVistaの後継版に目を向けているが、この後継版はまだリリースもされていない。悲しいことに、誰もWindows Vistaの誕生日を祝いたいとは思っておらず、その存在を忘れてしまっている。そして、多くの企業は依然としてWindows
「スーパーコンピューティングの歴史に残る日。5年前に夢見ていたことが実現した」──米NVIDIAのジェン・スン・フアン社長兼CEOは12月2日、東京工業大学のスーパーコンピュータ「TSUBAME」がGPUコンピューティングの導入で強化されたことを喜んだ。 TSUBAMEは多数のOpteronサーバなどをグリッド化したスーパーコンピュータ。このほど、NVIDAの「Tesla GPU」を導入して処理能力を強化。理論ピーク性能を約160TFLOPSに高め、Linpackベンチマークで77.48TFLOPSをマーク。スーパーコンピュータの世界ランキング「Top500」で29位に入った。 NVIDIAは、グラフィックスに使われてきたGPUの高い処理能力を科学技術計算などにも活用するGPUコンピューティングの普及を推進している。来日したジェン・スン・フアン社長兼CEOは、TSUBAMEが稼働している東
スクウェア・エニックスは12月10日、ニンテンドーDS向けRPG「ドラゴンクエストIX 星空の守り人」を2009年3月28日に発売すると発表した。価格は5980円。都内で開かれた発表会では、ドラクエシリーズの生みの親・堀井雄二さんが登場し、10作目となる「X」(テン)をWii向けに開発する方針を明らかに。任天堂の岩田聡社長も登場し、ドラクエの海外展開をサポートしていく考えを明らかにした。 →ゲーム画面とムービーのスクリーンショットはこちら ドラクエのナンバリングタイトルとしては初めてのニンテンドーDSタイトル。シナリオは堀井雄二さん、キャラクターデザインは鳥山明さん、音楽はすぎやまこういちさん、開発はレベルファイブと、累計488万本を出荷した前作「ドラゴンクエストVIII 空と海と大地と呪われし姫君」(PS2)と同じスタッフで制作する。 DSならではのワイヤレス通信機能を生かし、友達などと
ref:2007-12-02 - プログラミング日記 なるほど。同値関係を定義できるのに、同一オブジェクトじゃないと同一ハッシュにならないという状況はいろいろまずそうだから、それを回避するわけだ。 しかし、新スタイルクラスではobjectに__hash__が定義されているので必ず__hash__を持つので、Cのソース中のTypeErrorは起こらないと思う。その代わり、list自体は__hash__でTypeErrorを投げるように実装されているのではないだろうか。 Objects/listobject.c を見てみた。 static long list_nohash(PyObject *self) { PyErr_SetString(PyExc_TypeError, "list objects are unhashable"); return -1; } PyTypeObject PyL
PEP 289 – Generator Expressions Author: Raymond Hettinger <python at rcn.com> Status: Final Type: Standards Track Created: 30-Jan-2002 Python-Version: 2.4 Post-History: 22-Oct-2003 Table of Contents Abstract Rationale BDFL Pronouncements The Details Early Binding versus Late Binding Reduction Functions Acknowledgements References Copyright Abstract This PEP introduces generator expressions as a hi
Peter Norvig 氏の Solving Every Sudoku Puzzle というエッセイで、数独の解き方が Python を使って示されています。 ちょうど SRFI-42 (eager comprehension) というライブラリを使ってみたいなと思っていたところに見つけたので、ジェネレータ式というものが多用されているこの Python コードは恰好の題材でした。 ということで、原文の流れに沿いながら Scheme に訳していきたいと思います。 まず用語を紹介しておきます。 9x9マスの縦の列を column、横の列(行)を row と言うのは自明と思いますが、3x3 のまとまりは block、そして各マスを square と呼んでいます。 さらに、row、column、block それぞれ9マスずつのまとまりを unit、1つの square が所属する unit 内の
1. 配列の要素を集計をするときに感じた違和感 配列の要素を集計をすることを考える。 例えば、1 ~ 5 までの整数に対して、 1 + 2 + 3 + 4 + 5 の答えを求める場合、次のような手順を踏む。 Ruby で書くなら、 ary = [1, 2, 3, 4, 5] total = 0 for elem in ary total += elem end puts total もちろん、慣れているので、この計算の方法に抵抗は感じない。 しかし、この手順を初めて見たとき、 「わかりにくい」 と感じた。極めてシンプルなコードなんだけれど、どこか頭が混乱するような、そんな感覚に陥ったことを覚えている。 では、その原因はどこにあったのだろうか? 2. わかりにくい理由は、「要素の走査」「計算」「変数の再代入」を行なっているから 頭が混乱する印象を受けたのは、以下の箇所。 total += e
西尾泰和のはてなダイアリー: __hash__ (http://d.hatena.ne.jp/nishiohirokazu/20071130/1196442062) なるほど。__hash__も__cmp__、__eq__も定義されていなければid(obj)が使われるのか。 なんで「tp->tp_compare == NULL && RICHCOMPARE(tp) == NULL」って条件が必要なのかがわからない。tp_hashを持っているならそれでハッシュ値を計算して、持ってないならポインタの値から計算する、でいいのに。 これは、 Effective Python: 2 __hash__ (http://morchin.sakura.ne.jp/effective_python/dict_user_def.html) に書いたことで、 >>> class Foo(object): ...
http://d.hatena.ne.jp/morchin/20071130/p1 を読んで。 object.cから転載 long PyObject_Hash(PyObject *v) { PyTypeObject *tp = v->ob_type; if (tp->tp_hash != NULL) return (*tp->tp_hash)(v); if (tp->tp_compare == NULL && RICHCOMPARE(tp) == NULL) { return _Py_HashPointer(v); /* Use address as hash value */ } /* If there's a cmp but no hash defined, the object can't be hashed */ PyErr_Format(PyExc_TypeError, "unh
Python2.5のときは、新スタイルクラスのインスタンスは辞書のキーとして必ず使用できたけど、Python 2.6ではそういうわけじゃなくなってるぽい。という話。 class TestClass(object): def __init__(self, i_name): self._name = i_name def __eq__(self, i_other): if not isinstance(i_other, TestClass): return False return self._name == i_other._name print 'object.__hash__ = ' + str(object.__hash__) print 'TestClass.__hash__ = ' +str(TestClass.__hash__) 上記のようなコードを実行したら、Python 2.
id:amachangに「PerlではMRO(Method Resolution Order, メソッドの解決順序)は幅優先探索とかC3ってのとかが外付けのライブラリで選べるような仕組みになっているけども、Pythonはどうなの?と聞かれてわからなかったので調べました。 新しいクラスでは >>> class A(object): pass >>> class B(object): pass >>> class AB(A, B): pass >>> class BA(B, A): pass >>> class ABBA(AB, BA): pass Traceback (most recent call last): File "<pyshell#14>", line 1, in <module> class ABBA(AB, BA): TypeError: Error when callin
西尾泰和のはてなダイアリー: 多重継承時のメソッドの解決順序について (http://d.hatena.ne.jp/nishiohirokazu/20071129/1196334522) そうそう、「すべての親クラスを探索し終わってから祖父クラスを探す」という理解をしている人が多い(僕も含めて)ようだけど、それは間違い。 ほほう。単純に旧スタイルクラスは深さ優先検索、新スタイルクラスは幅優先検索ではないのか…。間違えて理解していたなあ。て言うか、『Pythonクイックリファレンス』ではダイヤモンド継承の例しか載ってなかったと思うので勘違いしやすいかも。 『Java Puzzlers』から引用したクイズは反響が大きかった気がするのでPythonクイズをたまには書こうかな。最近気になっていたのは『Pythonチュートリアル』の用語集の中で、オブジェクトに__hash__が定義されていればそのオ
odz buffer: list の hash (http://d.hatena.ne.jp/odz/20071202/1196602935) list の __hash__ が TypeError を投げるで間違いなさげ。 やはり挙動から推測した通り。しかし一般には、実装==仕様ではないが、公式サイトにある「Python Reference Manual」が仕様と考えて良いのかな。 以下は、「Pythonリファレンスマニュアル」からの抜粋。 __hash__( self) 辞書演算 の際にキーとなるオブジェクトに対して呼び出されたり、組み込み関数 hash() から呼び出されたりします。 辞書演算におけるハッシュ値として利用できる、32 ビットの整数を返さなければなりません。このメソッドに必要な性質は、比較結果が等価であるオブジェクトは同じハッシュ値をもつということです; オブジェクト間
目次 dis/inspect モジュールと ceval.c を使った Python のハッキング dis モジュールと python interpreter 関数に属する func_code オブジェクトとco_varnames, co_names, co_consts 属性 python interpreter ceval.c:Python Virtual Machine の C ソース・コード inspect モジュール dis, inspect を使った一行コード python コードの hack x,y = y,x, x,z,y = z,y,x Python オブジェクト 関数 STORE_GLOBAL/STORE_NAME inspect 経由による クラスの disassemble LOAD_ATTRI リスト hash generator thread decorator 構
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く