トップ «前月 最新 翌月» 追記

はじめてのにき

ここの位置付け

2004|11|
2005|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|04|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|04|05|06|07|08|09|10|11|12|
2012|01|02|03|04|05|06|07|08|09|10|11|12|
2013|01|02|03|04|05|06|07|08|09|10|11|12|
2014|01|02|03|04|05|06|07|08|09|10|11|12|
2015|01|02|03|04|05|06|07|08|09|10|11|12|
2016|01|02|03|04|05|06|07|08|09|10|11|12|
2017|01|02|03|04|05|06|07|08|09|10|11|12|
2018|01|02|03|04|05|06|07|08|09|10|11|12|
2019|01|02|03|04|05|06|07|08|09|10|11|12|
2020|01|02|03|04|05|06|07|08|09|10|11|12|
2021|01|02|03|04|05|06|07|08|09|10|11|12|
2022|01|02|03|04|05|06|07|08|09|10|11|12|
2023|01|02|03|04|05|06|07|08|09|10|11|12|
2024|01|02|03|04|05|06|07|08|09|10|11|

ToDo:


2009-10-01

_ Hello 14B

http://d.hatena.ne.jp/kurimura/20090929/1254257912

なるほどなー

(02:00)

_ テキストプロトコル

http://d.hatena.ne.jp/kazuhooku/20090928/1254113043

基本的には正しいと思うけど、 http みたいに細かいヘッダがいくつかあって 後はどんとペイロードが入ってるようなプロトコルを前提にしてる感じなのかなぁ。 バックエンドとミドルエンド的な中継サーバとのやりとりとかで、 細々としたフィールドがあるようなプロトコルだと なかなかテキストではやりたくないような。

たとえば twitter の検索だったら、

[{ uid: 1234, timestamp: 1254330459, text: "なんとかなう", client_id: 3 },
 { uid: 2345, timestamp: 1254330451, text: "ほげほげなう", client_id: 2 },
 ...
]

とか、こういうのはあんまりテキストで送りたくはないような。

弊社はまぁなんでもかんでも protocol buffer に つめこむ習性があると思うんだけど、 まぁバイナリプロトコルも解析ツールとか 手軽にテキストで送信できるツールとかが そろってればそんなに使い勝手は悪くはない気がする。

一方ゴルフ場はどう考えてもテキストプロトコルであるべきであった…

(02:11)

_ あと

http://d.hatena.ne.jp/kazuhooku/20090924/1253766558

こっちもそうだよねえと思いつつ読んだのを思い出した。

もうなんか全てのプロセスはたまに止めたいんだよな。 ブラウザとか1日に一回くらい夜中に再起動してて欲しい。 お手軽 Copying GC とか冗談で言ってるんだけど、 まぁ冗談じゃなく普通にアリなんじゃないかなぁ。

(03:05)

本日のツッコミ(全2件) [ツッコミを入れる]

_ naruse [そーいえば、もう伝わってるかも知れませんが ゴルフ 12B http://d.hatena.ne.jp/nurse/..]

_ shinh [あーはい。ファイルだろうなぁとは思ってたのですが、まぁこのへんはなんとかします…]


2009-10-02

_ Arc

http://golf.shinh.org/

足した

(01:40)

_ ちょっと

downtime

(01:43)

本日のツッコミ(全1件) [ツッコミを入れる]

_ Twuvurfc [この間も俊太郎の詩をお http://www.stlouisbusinesslist.com/business/5..]


2009-10-03

_ リリースマネージャ

http://jibun.atmarkit.co.jp/ljibun01/rensai/leader/33/01.html

かっこいいなぁ。

Chrome もこっち系の仕事をやってる人が何人かいるんだけど、 まぁ彼らはすごいなぁと思う。ありがたい。

Yugui さんて同年代くらいなのか。 別に上という印象も下という印象もなかったのだけど。

(18:06)

_ CSS地獄

CSS1 にテキストを capitalize させる text-transform:capitalize という、 python の str#title() 並にどうしようもなく存在価値が なさそうな物体があるのだけど、 そのブラウザごとの挙動が驚くほど違って面白かった。

http://spreadsheets.google.com/pub?key=tGCsFWV1bwyYanB9y4Ri9IQ&output=html

Firefox が一番まともそうな雰囲気に見えるかなぁ。 シングルクォートへの対応が大変興味深い。 個人的には Opera の挙動がわかりやすいので一番好みで、 これが唯一 CSS の test suite を通るはずで、 かつこんな機能どうせ誰も真剣に欲しがってないと思うので、 test suite 通せるという一点で Opera のでいいと思うんだけどね。

あとこのへんのあきらかに実現不可能な Correct output sample も面白かった。 One-to-One とか無理だろ! とか クリンゴン語 (tlh) とか入れるなよ! とか。

https://bug-3406-attachments.webkit.org/attachment.cgi?id=2381

どうでもいいけど Python の title() は

>>> "foo's".title()
"Foo'S"

とかになるので最もどうでもいい。

(21:25)

_ blokus

やる気は一応あるけど過去のコード、 つまり2年前のコードが読めない。 よって CPU ロジックは一から作ろうと思うのだけど、 そうは言っても再利用したい部分はあるので…

if (ev.key.keysym.sym == SDLK_z) {
    current_state -= (current_state & 1) * 4 - 2;
}
if (ev.key.keysym.sym == SDLK_x) {
    current_state += (current_state & 1) * 4 - 2;
}
if (ev.key.keysym.sym == SDLK_c) {
    current_state ^= 1;
}

この int の意味はなんだろう! c はどうもひっくり返してくれるようなので、 下位 1bit は parity というのかそういうもののようだ。

ああなるほど回転はその parity のせいで 方向が変わりうるのね… つまり 0-7 までぶんまわせば全状態が取れるようだ

(21:57)


2009-10-04

_ ふうせんおじさん

http://darwinawards.com/darwin/darwin2008-16.html

ブラジルにもいたらしい。 GPS持って出発したけどGPSの使い方がわからなかったらしい。

(18:50)


2009-10-05

_ std.format

import std.format;
import std.stdio;
import std.string;

void main() {
    stdout.writeln(format("%c", 'a'));
}

ぎぎぎ %c が無いぞ… よくわからんけど今度パッチをほる

(01:41)

本日のツッコミ(全2件) [ツッコミを入れる]

_ yshl [よくわかりませんが、%s を使えばいいのではないでしょうか?]

_ shinh [あーそうかそういえばそれでいいんですね。ありがとうございます!]


2009-10-08

_ base85

というものがあるようだ。

http://tools.ietf.org/rfc/rfc1924.txt

Git がこれ使って binary diff を作ってるみたいなんだよね。 自分で書きたくないから素直に base64 使って欲しいなぁ…

(02:50)


2009-10-10

_ バグ報告とか

なにやら大変面白い話が。

http://d.hatena.ne.jp/IwamotoTakashi/20091006/p1

http://d.hatena.ne.jp/ku-ma-me/20091010/p1

http://akimoto.jp/blog/2009/10/08/bug-report-in-foreign-language/

個人的な感覚では、オリジナルの報告者の方も 最初に close した PHP の人も、 その後のいやこれは dup じゃないんだという主張も、 その後の直してくれるまでのやりとりもごく問題ないように見えるかなぁ。

なんか気になるとしても本当に細かい点で。

指摘されてる通り、 オリジナルの報告者が謙譲しすぎっていう点については、 これ要するにパッチには自信無いけどたぶんこんな感じでいいよね、 って言いたいってことなんだと思うんだけど、 まぁそいうのはよくあるからきちんとそう書いた方が 良かったかなぁというかんじはする。 これだとレポート自体に不穏な空気を出してしまうのはそうだし。 でも本当にこんなのは細かい点で。

あとは最初の php.net の人の応対だけど、 まぁどれと dup してるかくらいは言ってよ、 って感じではあるけど、 これもこの対応見るだけで判断すると、 そんなにひどい応対とは思えないなぁ。 仮にこのバグを reopen して、もう一度理由を示されず close されてたとしたら それはひどい人だと思うけど、 この程度だったらまぁ忙しいプロジェクトの バグ管理とか多少雑になっちゃうのはしょうがないと思う。

バグの数が50000とかになってるプロジェクトなんだから (10年やってるわけだけど単純計算で1日10個とかだよねえ…)、 多少ミスがあるかもしれないけど適当に バグの dup 判定とかをざっとやって、 それでお前それ違うヨ! って言われたら もうちょっとちゃんと判断する、みたいな 雑なスキームになっちゃうのはしょうがないように思う。

だからこの応対だけではこれはひどいとは思えないかなぁ。 懇切丁寧な方がそりゃいいんだけど。

でまぁ、エスパーじゃあるまいし実際そいう事情があるかは知らんので、 報告者の方がそのへんを察するべきだった! とかいう主張をする気も全くなくて、 絶望した! とか思っちゃうのもしょうがないと思う。 それでもちゃんといやこれ dup じゃない気がするんだ と言ってるのもすごくいいと思う。

そんなこんなで僕的にはごく普通の bug repot → fix の流れのひとつに見えたようにおもう。

ちょっと改善できたらいいかなぁと思ったのは はてぶとかしてる人で実際に PHP のそのバグを 困るものとわかってる人は、 バグに対して賛意を示してあげたりすると目立つからいいと思うんだよな。 できれば補足説明とかしてあげられるといいけど、 "+1 for this bug" とかだけでもいいように思う。

あと個人的には秋元さんの意見には 一般論としてはあまり同調できないなぁ。 そういう(すごく丁寧に説明する)やりかたも アリっちゃアリだとは思うんだけど、 個人個人のリソースは限られてるんだし、 適当に短いバグレポートをほってみて、 それだけで直してくれたらラッキーだし、 反応が無いようなら重要度に応じてあきらめてみたり ping してみたり、 伝わってない部分があればそこを細かく説明してみたり、 という感じで適当にやればいいんじゃないかなぁ。 伝えるのが難しそうなら日本語でブログ書いて応援求めるとかも すごくいいように思う。

例えば英語とか書きたくなければ、 there is a bug: <再現するコード>, expected: <hoge>, actual: <bug!>、 とかだけでもたぶん良いわけで。 実際 WebKit のバグとか見てる感じでは、 最悪再現する URL だけでも良くて、 できれば再現する最小の html なりなんなりにしてくれると良くて、 さらにそのまま test として使える程度にわかりやすい html だと (緑になるべきだけど赤くなるとかそういうやつ) なおよい感じかな。

直す側に回る時はそのバグの深刻度とかは 正直どうでもいい情報でしかなくて、 開発者側の priority 見積りは信用できないから 急いでなおして欲しい! と思うなら書く、 くらいでもまぁいいんじゃないかなぁ

そいう意味で秋元さんご自身のバグレポートの例それ自体は、 これはこれでこの事情ならこのくらいきちんと説明しないと ドコモのほげほげの事情とか知らんだろうし、 丁寧に説明しておられたのはそれはそれで適切な気がした。 普通に考えるとそんなよくわからんバグに priority あげられないからねえ。

(17:59)

本日のツッコミ(全7件) [ツッコミを入れる]

Before...

_ naruse [わたしもほっとくよりはrejectって感じかなぁ。 ruby でも仕様変更のパッチは高確率で放置じゃないかな。 後..]

_ shinh [あーなんかその手の contributor が知ってるとトクなプロジェクトごとの文化みたいなのはお互い難しいですよね..]

_ ku-ma-me [3 日くらい、とは最初ぼくも思いましたが、よく見てみると、報告があって 30 分で「重複すんな」といい、さらに 30..]

_ shinh [http://bugs.php.net/report.php に太字で If you feel this bug..]

_ ku-ma-me [おお。http://www.php.net/mailing-lists.php と http://bugs.php...]


2009-10-11

_ ふりー

http://www.tees.ne.jp/~sin-x/200910a.html#0901

どうでもいいけどこの free_LIST は 要素数多いとスタック喰い潰して死ぬのが初学者には厳しそうな… とか思った。

(05:20)

_ ばぐれぽ

http://www.kt.rim.or.jp/%7ekbk/zakkicho/09/zakkicho0910a.html#D20091010-2

glibc といえば Ulrich とかなのですかね…

(13:10)

_ XSS

そういえば XSS で今までに発生した一番深刻な被害ってなんなんだろう と思ってちょっとぐぐってみた。

たぶん cookie 盗まれてログイン情報乗っ取られて、ぼくのお金が… みたいなヤツかと思ってたんだけど、実際あるんだろうか。

と思ったらなんか cookie 盗まれるだけではすまないらしい。

http://itpro.nikkeibp.co.jp/article/NEWS/20061113/253479/

ああ単にユーザ情報収集に使われちゃうよって話か。 これもまぁクレジットカード番号とか入れてたらヤバいわけだけど、 自前でサイト作るのに対して 他人のサイトの XSS 使うメリットは URL に信用されてるドメインが使えるとかなのかな。

(13:35)

本日のツッコミ(全1件) [ツッコミを入れる]

_ きむら(K) [>Ulrich とかなのですかね… その通りで。 何人か応援(別の修正方法を検討というのも含め)してくれる人もいたん..]


2009-10-12

_ stack_ni_yasasii_free_tree

http://www.tees.ne.jp/~sin-x/200910b.html#1201

を見て結構 tree で空間を定数しか使わずに、 かつ計算量 O(N) で free するのって たぶん結構難しいよねーと思って書いてみた。 実際結構難しかった。

http://github.com/shinh/test/blob/183dec99c9f05642488820587bf9e1aa48de94ea/free_tree.c

もちょい綺麗に書けたりするのかなぁ。 あとそもそも間違ってたりすると恥ずいけど、 たぶんあってるよね…

あと free_LIST は

void free_LIST(LIST *list) {
    if(list){
        free(list->name);
        LIST* next = list->next;
        free(list);
        free_LIST(next);
    }
}

としてやれば gcc なら再帰の形のままで stack ni yasasiku なるという話もありますね。

(08:44)

_ まーじゃん

やった。 一晩やってとんとんだったから成績としてはよかったんだけど、 切り間違えとかおかしいリーチとか多かったのはいまいちだった。

あと三色同刻ができたのがうれしかった。

赤入りはただでさえクソゲーの麻雀がさらにクソゲーになると思ってるんだけど、 手作りの楽しみは減るけど、押し引きが際立つ感じはあるかなぁとか思った。 麻雀ってどうせ一点読みとかはそうそうできないので、 上がりに行くか降りるかの判断が一番重要かなぁと思ってるんだけど、 赤入りだと要はドラが2個あればクイタンでもいいから上がりにいって、 1個もなければすぐ降りる、みたいな感じで適当にやってもよくて、 まぁ結局相手が高そうかどうか考えるとかする必要がなくてアレなんだけど、 すぐに降りちゃうヘタレとしては頻繁に降りておいて たまにドラあると攻めていくみたいなのがやりやすいなぁとか。

(18:43)

_ なるほどなー

http://d.hatena.ne.jp/kurimura/20091012/1255340288

紙に書いてしばし考えないとわからなかった。

要は tree を単なる list に変換しつつ 単方向 list になった時点で削除してる、 っていう感じだなぁと僕なりに理解した。

(19:14)

_ ゴルフ場

とりあえず tmpfs 使ってみる実装にしてみた。 基本的なチェックはしたけど、まぁそれなりに動いてそう。

やってて思ったんだけど、 dmesg とかに情報残すのは依然として可能だよなー。 まぁ 5B hello とかはできんくなるからいいけど…

あとは process group 一掃するようにするとか setpgid や setpgrp の禁止ってのがあったなぁ。

(23:06)

本日のツッコミ(全2件) [ツッコミを入れる]

_ bero [>としてやれば gcc なら再帰の形のままで stack ni yasasiku なるという話もありますね。 でもこ..]

_ shinh [ええ全くですね。まぁ OCaml とか Haskell とかそのへんのせいか、 list を見ると再帰で処理したくな..]


2009-10-13

_ require 'yaml'

YAML モジュールむずかしいぞ…

http://d.hatena.ne.jp/shinichiro_h/20090826#c1255355058

をなんとかしようとしてる。

まず parser か emitter にバグがあるのは確実。

require 'yaml'
o = "-\n \n-"
p o == YAML::load(YAML.dump(o))

が false を返すのだから。

  • parser は literal や fold 形式の中に空白だけの行があると空白を落とす。
  • emitter は空白だけの行がある文字列を literal として出力する可能性がある。

のいずれかがバグ。調べてないけどたぶん普通に考えて前者。

とりあえず parser のバグ直すか…と ruby の中に入ってる syck のコード読んだんだけど… えっとこれ yacc で生成されてるんだよね なんでオリジナルの gram.y とか token.re とか入ってないの…

そして _why 失踪につきオリジナルのコードとかどこにあるかよくわからず。

というわけでそっちはとりあえず諦めた。

まぁなんにせよ修正は emitter 側でやった方がいい。 Ruby の修正が入るの待つより サーバだけ修正した方がいいからね。

で、まぁ…

class String
  def to_yaml_style
    :quote1
  end
end

とかしたら良いように思うのだけど、 全然 quote1 にしてくれません! なんかコードが複雑怪奇なんだけど、 複数行に渡ってると literal にするってのが優先されてる感じかなぁ。

あと YAML::Syck::Scalar#style= というメソッドもあるみたいだけど、 これをどう使うかとかはさっぱりわからない。

あとこの rdoc で何がわかるのだろう。

http://doc.okkez.net/191/view/method/Object/i/to_yaml_style

で、なんか syck を見つけた。

http://github.com/indeyets/syck

token.re 読んでたらなんとなくわかってきた… よしなおった!

diff --git a/lib/token.re b/lib/token.re
index 9d9c855..4d16363 100644
--- a/lib/token.re
+++ b/lib/token.re
@@ -308,6 +308,7 @@ TAB = "\t" ;
 SPCTAB = ( SPC | TAB ) ;
 ENDSPC = ( SPC+ | LF ) ;
 YINDENT = LF TAB* ( SPC | LF )* ;
+YINDENT2 = LF TAB* SPC* ;
 NULL = [\000] ;
 ANY = [\001-\377] ;
 ISEQO = "[" ;
@@ -966,7 +967,7 @@ ScalarBlock2:

 /*!re2c

-YINDENT             {   char *pacer;
+YINDENT2            {   char *pacer;
                         char *tok = YYTOKEN;
                         int indt_len = 0, nl_count = 0, fold_nl = 0, nl_begin =
 0;
                         GOBBLE_UP_YAML_INDENT( indt_len, tok );

でも parser 直しても意味ねー。

うーんどうやったら quote 文字列とかで出力してくれるかって話ですね…

(08:42)

_ とりあえず

パッチはちょっと修正して今のメンテナっぽい人にメールしておいた。

んなことより emitter ですね… 別の yaml ライブラリ使うかねえインストールするの面倒だけど…

(09:26)


2009-10-14

_ 検索がうまくないという話

なにか僕は絶望的にヘタな検索をするという話をよくする。 けど具体的にどんなヘタ検索だったか覚えてなかったので、 適当にログをあさってヘタそうな検索失敗例を探してきた。 たいてい単語が足りてなくて増やすのだけど、 増やす前の検索キーワードで目的のものが見つかるはずがない。

  • DS => カルドセプト DS
  • MT => MT mersenne
  • 永田 => 永田 赤軍
  • span => span style => span style height
  • NTT => NTT goo

あとは何が知りたかったのか見当もつかないようなクエリが たまにあるはず…と思ったのだけど、意外となかった。 不意に「はらへった」とかで検索してた気がするんだけどなぁ。 本気で意図がわからなかったのは、 「財布」「店主」などがあった。 「雪歩shinh」というのもあったが俺は一体何を期待していたのか。

あとはどんなの出てくるかなー的に検索してみたのがあるな。 「学会 エロゲ」「彼女ほしい」「エロ動画」など。 そうそう「プロフ 姫 闇」も。

(00:48)

_ YAML問題は

結局 JSON module が入ってれば JSON 使って落とすことによって解決することに。

http://github.com/shinh/caddy

rm ~/.golf/ag/Count\ diamonds\ level\ *.db

とかしてから caddy update すればたぶんうまくいきます。

しかしまぁ今回で YAML はやっぱ ムダに機能多すぎだよなーという思いを強くした。 まぁ手で書きやすいのはいいんだけど、 お手軽シリアライザとしては JSON の方がいいのかもねえ。

本当は inspect => eval でもいいんだろうけど、 まぁ eval はちょっと恐い気もしたので。

さてここで問題です。以下のコードがあって、

eval(s.inspect)
  • s を自由な文字列から選べる時、任意コード実行可能な抜け道はあるか
  • s を自由な ruby オブジェクトから選べる時、任意コード実行可能な抜け道はあるか

できなさそうな気がするけど、 できるとしたら kurimura さんとかが すぐに発見してくれそうな。

(01:16)

本日のツッコミ(全13件) [ツッコミを入れる]

Before...

_ ku-ma-me [「Marshal.dump か JSON 使ってくださいというのが Ruby の見解」ってそうなんですか? 「Num..]

_ shinh [説得力があるかはわかりませんが、僕が便利だと思うのは、何かを集計するツールを二段階で作ってる場合なんかかなぁと思いま..]

_ naruse [> 「Marshal.dump か JSON 使ってくださいというのが Ruby の見解」ってそうなんですか? 前..]

_ ku-ma-me [そうか、グラフ構造は確かに手間ですね。考えると面白そうなネタです。]

_ なひ [たいていの道はakrさんが通過済みであります: http://raa.ruby-lang.org/project/a..]


2009-10-18

_ ワンライナー自体が quine

今のところ普通に

perl -e'$_=q(printf"perl -e%c\$_=q($_);eval%1\$c$/",39);eval'
ruby -e'eval Q="puts %(ruby -e%ceval Q=%p%c)%[39,Q,39]"'

あたりが短いんだけど、 なんかまだまだ気の効いた方法はありそうだなぁ。

お、これとかちょっと気が効いてるね。

ruby -e"eval Q=%(puts %(ruby -e%p)%%(eval Q=%%(%s))%Q)"

(02:03)

_ なにかおかしい…

と思ったら一箇所 single qoute にできるんだね。

ruby -e"eval Q=%(puts'ruby -e%p'%%(eval Q=%%(%s))%Q)"

(02:04)

_ Jeff Dean's talk

http://www.cs.cornell.edu/projects/ladis2009/talks/dean-keynote-ladis2009.pdf

ぱっと読んだかんじ

  • a web search touches 50+ separate services, 1000s machines
  • BigTable Coprocessors
  • Spanner

あたりが喋っていいんだなぁリストに足された。

Spanner は何かとんでもないものが作られようとしているというイメージ。

最初の数字は google 入って結構びっくりしたことの一つだった。 あんだけ速く検索できるんだから すごくチューニングされた少数のマシンが返事してるのかなぁと 漠然と入る前は思っていたのだけど、 実際にはえらいたくさんのマシンがかかわってたのであった。 まぁ冷静に考えるとネットワーク速いわけだし、 あたりまえという感もあるのかもだけど…

(02:35)

_ ファイル書き込み

tmpfs を使う実装に変えた。 これでたぶんファイル残すのはかなり大変になったと思うので、 ファイル書いたと思われる投稿は消した。 具体的には hello.rb 12B * 3 だけなんだけど、 他にもあったかなぁ。

(03:17)

_ SELinux

本題の SELinux のお勉強は相変わらずわけわからんなーと思ったので、 SELinux 知ってる人いますかーと聞いたら みんな無効化したことはあるということだった。

Google suggest とかも SELinux に対して、 「無効」「停止」「無効化」などの 愛があふれる単語を suggest してくれると教えてもらった。

それでそういえば hamajis に対して 「浜地慎一郎 google」とか出してきやがるのは どうなんだとかいう話をした。

でまぁ TTEdit という ttf を手軽にいじれそうな ソフトを教えてもらって、 それは CSV からの import とかができるのが なかなかいい感じだったのだけど、 どうも小回りがきかない感じはあるのであった。 例えば UnitsPerEm をキリのいい数字にしたいのだけど、 できないぽかった。

まぁそんなこんなで 5x5 font を ベースにして TTF を作ってみたりした。 chrome で見るとどうにも文字の左右に色が見えるなぁ。 それは Ahem でも同じことだから、 Layout tests 走らせてる時はそのへん無くなるようにとかしてあるのかなぁ。

なんにせよ TTEdit 使って CSV から import するのは結構めんどくさいから、 Ahem ベースで fontforge-dev で作れたりするといいのかな。

つか Ahem 作った時のスクリプトとかがあれば手っ取りばやいのだけど。

http://hixie.ch/resources/fonts/iw-generator.py

はなぜ 500 なんだ

(04:05)

_ fetchmail

英語風設定ファイルを自慢げに書いていたのは伽藍とバザールだったか…

http://www.tlug.jp/docs/cathedral-bazaar/cathedral-paper-jp-8.html

(04:38)

_ signal

http://d.hatena.ne.jp/w_o/20091018

signal はみんなだいすき。 とりあえず練習として書いてみる。

#include <signal.h>
void (*signal(int signum, void (*handler)(int)))(int);
void static (*(* const signalp)(int, void (*)(int)))(int) = &signal;

あまりすらすらとは書けなかった… const の位置の尋常じゃない違和感といったら!

typedef は storage-sepecifier で、ヘンな位置に書けるとかいう話。

int typedef i;

とかは中置演算と考えれば読みやすいかもとかいう話だったんだけど、

int* typedef ip;

とは書けないので、まぁダメダメなのであった。

int const typedef * const i;
struct {
    int x;
    int y;
} typedef pos;

もげもげ

(05:42)

_ SSE一覧

http://krypton1.at.infoseek.co.jp/x86/x86ext.htm

ちょうべんり

(14:37)

_ Core 2 Duo

と単純にいっても色々あるわけだ。

http://ja.wikipedia.org/wiki/Intel_Core_2

今のメインマシンの R61 は…

Intel(R) Core(TM)2 Duo CPU     T7250  @ 2.00GHz (FSB=800MHz, L2=2MB)

次期ゴルフ場にしようとしてる X60 は…

Intel(R) Core(TM)2 CPU         T5600  @ 1.83GHz (FSB=667MHz, L2=2MB)

会社の X61 は…

Intel(R) Core(TM)2 CPU         T7300  @ 2.00GHz (FSB=800MHz, L2=4MB)

まくぶくはスペックからの推定だけど、

T7200  @ 2.00GHz (FSB=667MHz, L2=4MB)

このへんは全部 Merom とかいうヤツで、 全部まぁ実に似たようなものなのであった。 Core 2 Duo マシン 4 台とか持ってるという事実にも、 それらのスペックが似たようなもんという事実にも、 悲しくなるのであった。

ああでも会社の Mac Pro はたぶん SSE4 とかある感じかな。

(17:22)


2009-10-19

_ SELinux

なーんとなくおぼろげにつかめてきた。 カンで書く。

  • SELinux とは。 linux kernel でなんかプロセスのやることにセキュリティコンテキストベースで制限とかがかけられる。
  • ls -Z とか ps Z でどいうセキュリティコンテキストのファイル/プロセスかがわかる。
  • ポリシーを手動でセットしていくのは大変なので hoge.te, hoge.fc を書くことによって make で作れたりするようになってる。
  • さらに reference 設定として配布されてるものがあって、かつそれは distribution が改造して適当に配布している。
  • strict mode では基本全てのプロセスが何もできないのがデフォルトだけど、それは結構真剣に不便なので targeted mode とかいうヤツが普通のディストリビューションでは使われていて、それだと特定のプロセス(要はサーバ)だけできることを減らす、というような感じでできる。
  • targeted で特に何も指定してないプロセスは unconfined_t とかいうのがついて、何でもできる。
  • あとたぶん MLS とかいうのもある、がなんか軍とかで機密データは大佐以上がアクセス可、とかそいうヤツぽい。
  • プロセスのやることを制限する書式は基本的に whitelist 方式。

さて、やりたいことは unconfined_t からほんの少しだけ権限を奪った、 つまり blacklist な感じの policy を作りたいんだけど、 あんま簡単ではなさそうなんだよな。 unconfined_domain_noaudit ってマクロが /usr/share/selinux/default/include/system/unconfined.if にあるから、 これをコピってから必要な制約だけつけないようにする、って感じかなぁ。

なんか allow kern_unconfined ~{ setpgid } とかそいうのかも

(05:19)

_ ゴルフ場 sandbox

前回までのあらすじ: SELinux はたいへん難しかった

メンテ性考えても kernel module の方が はるかにマシなんじゃないかという結論に至り、 その方向でやってみたい。 方針としてはややこしいのを書くと 大変なことになりそうなので、 間違えようのないくらい簡単なものにする。

  • setuid, setgid, setsid, setpgid は root 以外は EPERM 。
  • accept, bind, listen, socket あたりは…禁止したいけど、 execution server 自身の通信ができなくなるんだよな。とりあえず保留かな。
  • exec の実行回数を記録しておく。
  • getpriority(1764, __NR_execve) で exec の実行回数が帰るようにしておく。
  • setpriority(1764, __NR_setuid, 0) とかで EPERM な system call が実行されたかをリセットして getpriority で取得。
  • setpriority(1764, __NR_getpid, pid) で setpid 。
  • setpriority(1764, __NR_setpriority, 0) だけは禁止。これのカウントで exec 回数の記録が捏造されてないかをチェック。

こんな感じでどうかなぁ。 やってみよう

(22:46)


2009-10-20

_ kernel module sandbox

http://github.com/shinh/ags/blob/master/be/modules/sandbox.c

うーんこんな感じでそれなりに良さそう。 簡単なことしかしてないので、 一度しか kernel が大変なことにはならなかった。

うーん最初からこうすればよかったなぁ…

(00:23)

_ setpid

http://github.com/shinh/ags/commit/4264152293a449bd7ec4c43496716c2981829050

実装した。 うーん簡単だなぁ。 本当に最初からこうしていればよかったんだ…

(00:45)


2009-10-21

_ 対関数

sin-x さんに教えてもらう。

http://ja.wikipedia.org/wiki/対関数

よく整数2つの点とかの hash 値をどう計算するか悩むわけなんだけど、 本質的にこの関数はちょっと遅そうだけど、悪くないかも、ね。

ちょっとやってみた。 適当な値域の乱数のペアを大量に作って適当に突っ込む。

http://github.com/shinh/test/blob/da1e28b9fd201ca2d203d3e187cc280e9a8b9f9a/bijection_hash.cc

ハッシュ関数としては単なるかけ算、 よくある x + y * prime みたいなヤツ、 それとこの対関数、をそれぞれ使ってみた。

bijection_hash.gif

最初の立ち上がり部分は値域がほぼ埋まってるのであんまり関係ない。

  • 単なるかけ算は明らかに悪い。
  • 対関数は密度がある程度あるうちは衝突が少ないおかげかちょっと早そう。
  • 密度が薄くなると普通のやつに比べてたぶん hash の計算自体が遅いのでキツい。

て感じですかね。

(00:10)

_ smjs のクソ仕様

http://shinh.skr.jp/m/?date=20070219#p01

の時書いてたやつはいつのまにかなおってるぽいかな。

(03:16)

_ SVNSearch

http://svnsearch.org/svnsearch/repos/WEBKIT/search?start-index=20&logMessage=hamaji

これをみるとパッチ数がわかるうえに なんかかっこいいグラフとかがついてていいみたいだ。

Chromium の方はコミッタになる前のが入らんのが微妙ね。 9月ゼロってすごいな

http://tinyurl.com/yj2la4v

(04:33)

_ failwithf

http://d.hatena.ne.jp/camlspotter/20091020/1256049332

via http://twitter.com/chunjp/status/5021818819

これ全然動かないのはなぜなんだろう…

let failwithf fmt = Printf.kprintf (fun s -> failwith s) fmt;;

に変えたらうごいた。 ああ第一引数が (string -> 'a) だから (fun s () -> failwith s) でも unit を取る関数が帰ってるってことなのか。

てことはこう使うの?

let failwithf fmt = Printf.kprintf (fun s () -> failwith s) fmt;;
(failwithf "hoge: %s" "hii") ();;

うーんこれ何が嬉しいんだろう。

あと fmt が両辺にある理由もよくわからん。 単に

let failwithf = Printf.kprintf (fun s -> failwith s);;

じゃだめななにかがあるんかなぁ。

(10:54)

本日のツッコミ(全5件) [ツッコミを入れる]

_ kinaba [let failwithf = Printf.kprintf (fun s -> failwith s);; だと ..]

_ shinh [ううむありがとうございます。インタプリタだと通ったので通るんじゃね? と思ってしまってました。たしかにコンパイラだと..]

_ jijixi ['a と '_a は違うものです。 それぞれの関数を一回使った後に型がどうなってるか確かめてみるとわかるかと]

_ mame [value restriction とか言われます。 http://ftp.yl.is.s.u-tokyo.ac.j..]

_ Waecnhro [この間も俊太郎の詩をお http://www.stlouisbusinesslist.com/business/5..]


2009-10-22

_ ゴルフ場再建

出張から帰ったら動かせる程度になってると良いのう。

実装はだいたい終わった気がするので、 あとは70言語とかいうフザけた数の復元か… 酒でも呑みながらやれば割とすぐ終わるとは思うけど

(01:32)

_ あと

18言語か…

それと basic と erlang がそれぞれヘンなことしてて setpgid とか setsid 呼んでて warning が出るのがキモいなぁ。 はてさて。

結構テストだけ書いたら通ってた系のが多いのはありがたいけど。

うーん現ゴルフ場の maxima の exec count 間違ってそうな気がするんだけどいいのかな。

(02:10)


2009-10-23

_ literacy

http://d.hatena.ne.jp/Hamachiya2/20091022/literacy

昨日はこれを一通り見て色々思ったのだった。 なんというか、表現が難しいんだけど。

まぁこれを見た時のインターネットパワーユーザ的な人とか、 良いサービスは課金されて当然と思ってるような 世代の人とかの反応はまぁ、 ゆとり乙という感じだと思うんだけど、 まぁそれはそれでいいと思う。

ただなんか、色んな意味でサービス提供側というか 彼らが客になりうる、プログラム書く系の人が これはひどい的なことを言うのは、 まぁ気持ちはわかるけどあぶなっかしい面もあるかなぁという。

全員をひとくくりにはできないけど、たぶん彼らの多くは 良質なサービスがインターネット上で無料であることに慣れていて、 かつそのサービス提供側の中に無料でサービス提供しつつも 金儲けに成功してる会社が結構な量あること、 その多くが広告収入であることを知ってるんじゃないかなと思う。

でまぁそいう良質でかつ無料で使えるサービスなんてのは 今後も別に減りゃしない気がするので、 そいった人々は今後も同じような考えを持ち続けるんじゃないかなーと思う。 あっちは広告で金稼いでて無料なのに なんでこっちは金取ろうとしてるの? 広告でもうけられるはずじゃないの? 的な。

でまぁ今が過渡期で「リテラシ」と呼んでるものが浸透して そういう人々の人口が減るって前提ならまぁいいんだけど、 僕はあんま減らなくてむしろ増えるんじゃないかなぁとか思っていて。 その前提ではこの人達がネット慣れしてないんじゃなくて、 僕たちが古いネットにだけ慣れしていて 最近のネットの感覚に慣れてないって話なんじゃないかなぁと思う。

でまぁ普通は別に感覚のズレがあってもあんまり問題ないんだけど、 少なくとも自身よりコンピュータとかネットとかに詳しくないであろう 彼らを客とする身分である以上、 単にコイツらリテラシ足りねえプギャーとかで片付けるのは まぁなんか違うんじゃないかなぁと。

サービス提供側は今のユーザはこいう感じだからどうもうけようか、 って考えるとか、 プログラマは今のユーザはバグとかあんま牧歌的に許してくれないから ちゃんと作ろうって考えるとか、 まぁそっち系の考え方をする方が安全な気がした。

そういうことを思った。

(11:13)

本日のツッコミ(全3件) [ツッコミを入れる]

_ naruse [ぐーぐる「ゆとりはてめーらだよプギャー」ということですね。 いや、まぁ、全くもって同意する所なんですが、彼らがそう..]

_ shinh [ここに書いてあることは全て私的な意見であり会社を代弁するものではありません、とかバカなこと書きたくないので勘弁してく..]

_ shinh [あ、会社うんぬんは naruse さんがどうこうというより、うっかり引用とかされちゃった時のための安全弁程度のアレな..]


2009-10-25

_ 修行

http://risky-safety.org/~zinnia/d/2009/10/#20091021-t0-h1-p3

個人的には topcoder とかならまだゴルフの方を真剣にオススメするのですが。 問題がまだ現実世界に近いという意味で。

id:sumim さんがやっておられるように、 ブログとかで話題になってる問題を解いてみるってのは結構いいなぁと感じます。 あとたまに wikipedia とかにのってるアルゴリズムを 実際に書いてみるとかするんですが、そいうのもいい気がしています。 こないだ mutex 書いてたのはまさにそんな感じ。

http://d.hatena.ne.jp/shinichiro_h/20091018#1255797222

(01:27)

_ 海外に持っていくべきものリスト

  • 財布
  • パスポート
  • ノートPC
  • ACアダプタ
  • USBケーブル * 2
  • LANケーブル
  • HHK
  • エネループ
  • (必要な国なら)コンセントコンバータ
  • 高価なカメラ
  • アンドロイド
  • ひげそり
  • 目薬
  • リップクリーム
  • アトピーのくすり
  • 壊れていない折り畳み傘
  • 祝福されたナイロン袋 * 3
  • 大きいゴミ袋
  • めんぼう
  • 重くない魔法書
  • ペン
  • 栓抜き
  • イアホン

本当は瞬間移動の指輪と瞬間移動制御の指輪も欲しいね。

(01:35)


2009-10-27

_ dame_rev

http://d.hatena.ne.jp/camlspotter/20091026/1256567062

http://twitter.com/shinh/status/5194338611

http://twitter.com/shinh/status/5194346481

さて読もう!

08049860 <camlDame_rev__dame_rev_58>:
 8049860:       83 ec 04                sub    $0x4,%esp
 8049863:       89 c1                   mov    %eax,%ecx    # なんか知らんが第一引数は eax なのかね…
 8049865:       83 f9 01                cmp    $0x1,%ecx    # なんか知らんが nil の内部表現は 1 なのかね…
 8049868:       74 46                   je     80498b0 <camlDame_rev__dame_rev_58+0x50>
 804986a:       a1 40 b5 05 08          mov    0x805b540,%eax    # 0805b540 B caml_young_ptr なんだこれは! とりあえず GC 関係ぽい。 young って世代別とかそいうやつかいな
 804986f:       83 e8 0c                sub    $0xc,%eax    # なんか知らんが値減らして保存しなおしてるみたいだ!
 8049872:       a3 40 b5 05 08          mov    %eax,0x805b540
 8049877:       3b 05 44 b5 05 08       cmp    0x805b544,%eax    # 0805b544 B caml_young_limit
 804987d:       72 3a                   jb     80498b9 <camlDame_rev__dame_rev_58+0x59>    # これの行き先が GC なので、まぁ GC 関係
 804987f:       8d 58 04                lea    0x4(%eax),%ebx    # ここから本番。なんかたぶんリストの確保が終わってて ebx に入るのですよ、たぶん
 8049882:       89 1c 24                mov    %ebx,(%esp)   # たぶんこれがいま ebx=[]
 8049885:       c7 43 fc 00 08 00 00    movl   $0x800,-0x4(%ebx)    # (%eax) じゃないのか悩むが謎の定数を元の eax のところに入れてて、うーんこれはなんだろう
 804988c:       8b 01                   mov    (%ecx),%eax    # x を eax に入れた
 804988e:       89 03                   mov    %eax,(%ebx)    # ebx=[] の car を [x] にした
 8049890:       c7 43 04 01 00 00 00    movl   $0x1,0x4(%ebx)    # ebx=[] の cdr に 1 (やっぱ nil やね) をつっこむ
 8049897:       8b 41 04                mov    0x4(%ecx),%eax    # xs を eax に入れて
 804989a:       e8 c1 ff ff ff          call   8049860 <camlDame_rev__dame_rev_58>    # 再帰呼び出し
 804989f:       8b 1c 24                mov    (%esp),%ebx    # スタックに置いておいた [x] を持ってきた
 80498a2:       83 c4 04                add    $0x4,%esp
 80498a5:       e9 16 08 00 00          jmp    804a0c0 <camlPervasives__$40_167>    # 0x40 は '@' なのでまぁそういうことだろう
 80498aa:       8d b6 00 00 00 00       lea    0x0(%esi),%esi    # 何これここ来ることあるんか!!! → とりあえず gdb で break しかけても止まらない。
 80498b0:       b8 01 00 00 00          mov    $0x1,%eax
 80498b5:       83 c4 04                add    $0x4,%esp
 80498b8:       c3                      ret    
 80498b9:       e8 3a d7 00 00          call   8056ff8 <caml_call_gc>
 80498be:       eb aa                   jmp    804986a <camlDame_rev__dame_rev_58+0xa>

わかったことは引数は eax, ebx と入れて渡す呼び出し規約だということだった。 あと GC まわりのコードはこれだけではよくわからん。 てか [x] のために allocate ぽいことしちゃうのはちょっといけてないなー

さて次は @ を読もう!

0804a0c0 <camlPervasives__$40_167>:
 804a0c0:       83 ec 04                sub    $0x4,%esp
 804a0c3:       83 f8 01                cmp    $0x1,%eax    # 第一引数がカラだったらさっさと終わろうね☆
 804a0c6:       74 48                   je     804a110 <camlPervasives__$40_167+0x50>
 804a0c8:       8b 50 04                mov    0x4(%eax),%edx    # 第一引数の cdr
 804a0cb:       8b 08                   mov    (%eax),%ecx    # 第一引数の car
 804a0cd:       89 0c 24                mov    %ecx,(%esp)   # car の方は保存しておいて
 804a0d0:       89 d0                   mov    %edx,%eax    # cdr の方を次の関数 call の第一引数にして
 804a0d2:       e8 e9 ff ff ff          call   804a0c0 <camlPervasives__$40_167>   # 再帰! (ebx=第二引数は触ってないのでそのまま)
 804a0d7:       89 c1                   mov    %eax,%ecx    # 帰ってきたリストを ecx に。この時点で第二引数はくっついてるはず
 804a0d9:       a1 40 b5 05 08          mov    0x805b540,%eax    # また GC ゾ〜ン
 804a0de:       83 e8 0c                sub    $0xc,%eax
 804a0e1:       a3 40 b5 05 08          mov    %eax,0x805b540
 804a0e6:       3b 05 44 b5 05 08       cmp    0x805b544,%eax
 804a0ec:       72 28                   jb     804a116 <camlPervasives__$40_167+0x56>
 804a0ee:       8d 40 04                lea    0x4(%eax),%eax    # まぁこれで eax にカラリストが入ったんだろう
 804a0f1:       c7 40 fc 00 08 00 00    movl   $0x800,-0x4(%eax)
 804a0f8:       8b 1c 24                mov    (%esp),%ebx    # 保存しておいた car の方を
 804a0fb:       89 18                   mov    %ebx,(%eax)    # 確保したカラリストの car に入れるよ
 804a0fd:       89 48 04                mov    %ecx,0x4(%eax)    # cdr は帰ってきた値ね
 804a100:       83 c4 04                add    $0x4,%esp
 804a103:       c3                      ret    
 804a104:       8d b6 00 00 00 00       lea    0x0(%esi),%esi   # また使われてなさそうなコードがあるね…
 804a10a:       8d bf 00 00 00 00       lea    0x0(%edi),%edi   # また使われてなさそうなコードがあるね…
 804a110:       89 d8                   mov    %ebx,%eax    # ここは第一引数がカラリストだった場合なので、単に第二引数をかえせば良い!
 804a112:       83 c4 04                add    $0x4,%esp
 804a115:       c3                      ret    
 804a116:       e8 dd ce 00 00          call   8056ff8 <caml_call_gc>
 804a11b:       eb bc                   jmp    804a0d9 <camlPervasives__$40_167+0x19>
 804a11d:       8d 76 00                lea    0x0(%esi),%esi

ええとこれは… 正直どうしてこうなった…と思ってしまうな… これが関数型かー

何が言いたいかというとなんで list を append するのに allocation が大量発生してるんだよ! っていう

でまぁどう見ても O(n^2) でしかないので、 まぁ GC でこんだけ遅くなるのかなぁ。

(15:31)

本日のツッコミ(全6件) [ツッコミを入れる]

Before...

_ shinh [とりあえずこれかなーと読んでみました。 http://citeseerx.ist.psu.edu/viewdoc/..]

_ shinh [ところで OCaml くわしくないはつっこんだ方が良かったでしょうか :-))))]

_ kik [x86はよく知りませんがleaは6バイトnopのインテル推奨の書き方らしいですよ。]

_ shinh [ああ使ってるレジスタ違うから気付いてなかったんですがこれ nop なんですね。やまぁ padding なんだろうなぁ..]

_ shinh [ところで x86 くわし略 :-))))))))))))))))))]


2009-10-30

_ なんだろうね

仕事が楽しいとかは本気で本当によくないと思っているので、 本当に本気でこれはいけないと思う。

しかしそろそろ本気で英語なんとかならんもんかなぁとか 思うようになってきた。 もちろん努力をする気とか自分のお金を使う気とかは 依然として全くないのだけど、 こう、ラクしてというか何もせずに、 ある日突然うまくなっているべきだと思う。

このままではいけない。 こんな本質的でない問題はいつのまにか勝手に 乗り越えられているべき問題なのである。 例えばアメリカで日本語全面採用とか。 そういう問題意識ばかりがつのっていく。

(16:50)

_ rdtsc

x86 では "A" とかで受けてやればそれだけでいいわけなんだけど、 x86-64 では色々大変みたいだ。

http://d.hatena.ne.jp/rero/20071208/p1

よくわからんけどポータブルな rdtsc としては こんなかんじでいいのかね。

http://github.com/shinh/test/blob/2a7a2bf7dbffae14851725154e187a636bb269ff/rdtsc.c

(17:05)

本日のツッコミ(全3件) [ツッコミを入れる]

_ naruse [shinhさんがすーぱーくりえーたーになれば、 ぐーぐるさんが通訳さんを用意してくださるんじゃないでしょうか]

_ n [ぐーぐるさんも英語が苦手 http://d.hatena.ne.jp/Ozy/20080916 何とかならんでしょう..]

_ shinh [まぁいくらかマシになったようではありますけどね… http://translate.google.com/tran..]


2009-10-31

_ w3m で history 共有

共有っていうか今のセッションの ヒストリは別に持ってて欲しいんだけど、 保存は常に見た順でしておいて欲しいよね。

クッキーは w3mcooksrv で処理してる今となっては 一番 w3m のうざい部分の一つになってたんだけど、 まぁ別に各プロセスで同期とかして欲しくもないので、 こっちは特にサーバ化とかするまでもないのであった。

http://github.com/shinh/w3m/commit/53a5adaecee42d46efb5b458defe0f1f03ccbeaf

ていうかクッキーも必要なタイミングで毎回読むっていうのも まぁありっちゃありなんだよなぁ。

(15:15)

_ w3m -ppl 14

screen で画像ずれるのってどうするのがいいのかなーと 考えた結果、書いた通りにフラグセットするのがとりあえずよさそう。

(16:24)

_ セレン

i@uco ~> grep '^se ' /usr/share/skk/SKK-JISYO.L
se /セレン/Selenium/┌;罫線/┏;太い罫線/

これなんだろう

(16:25)

_ すのーれぱーど

i@um ~/wrk/sevil> ./dump
Sat Oct 31 17:00:08 um dump[13353] <Error>: kCGErrorInvalidOperation: _CGSFindSharedWindow: WID 40
Sat Oct 31 17:00:08 um dump[13353] <Error>: kCGErrorFailure: Set a breakpoint @ CGErrorBreakpoint() to catch errors as they are logged.
Screen size: (1280, 800)

CGSValue で string 受けるのが CFString になったのかなぁ という感じだったので変えてみたらそれでもなんかエラーが。

(17:01)

本日のツッコミ(全2件) [ツッコミを入れる]

_ ょゎ [> ┌;罫線/┏;太い罫線 罫線が南(s)と東(e)に伸びてるってことかも。]

_ shinh [なるほど! たしかに正解のようです。 i@uco ~> grep '^se ' /usr/share/skk/SK..]


2009年
10月
1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31
1.shinh(2014-05-24 01:31) 2.ょゎ(2014-05-24 01:31) 3.shinh(2014-05-24 01:31)
search / home / index

全てリンクフリーです。 コード片は自由に使用していただいて構いません。 その他のものはGPL扱いであればあらゆる使用に関して文句は言いません。 なにかあれば下記メールアドレスへ。

shinichiro.hamaji _at_ gmail.com / shinichiro.h