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

はじめてのにき

ここの位置付け

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|

ToDo:


2012-03-02

_ ぶっこわれサーバ

http://d.hatena.ne.jp/nn_x/20120219/1329633519

すいませんすいません…という感じで、東証とかと違って単にわかりきってるバグを放置してるだけのことですな…具体的には長い間ほっといてる ruby ってやつはいずれバカみたいにメモリ使い出してフロントエンドが死ぬってのと、 IO error だかなんだかはよくわからんけど実行サーバ側の ruby スクリプトがよくわからない理由で SEGV してる時があって、起動時のスクリプトで 100 回くらいは retry するようになってるんだけど、 100 回くらいを越えると完全に死ぬとかいう。

個人的には長い間動かしてるプログラムってのは遅かれ早かれいずれ死ぬもんだと思っていて、経験上 C++ でやってると自前でリソース管理してる関係で死亡率が低くなるものの、まぁそうは言っても死ぬ時は死ぬんで、死んでも大丈夫にする方がコスト的にはラクだと思っています。

さくら VPS 以降前は health check して、やばそうならやばい子を自動的に立ち上げなおすとかやってたんだけど、それを以降後動かしてないという怠慢がまず第一に悪いとかなんとか。最近は死ぬ頻度が少ないもんだから手動でもいいかなーとか思っちゃって、しかしやったほうがいいに決まってますね…

言語については Haskell だのあのへんはバグ減らすってことをかなりマジメに考えてると思うんですけど、どっちかというと気持ち悪い/不慣れな/熟れてないシンタクスとセマンティクスと、やはり熟れてない実装でイマイチ使う気起きないとかなんとか…

しかし最近の C ゴルフってやつはなにやら色々すごい感じで全然ついていけてませんな…ゴルフ場カンファレンスというか雑談会が必要な気がする

(21:27)

_ race

で個人的には最近は race ってヤツがホットなバグで、チャンネルみたいなやつが解決としては良いなーと思ってるわけですが、チャンネルみたいなやつって深く考えるまでもなく C++ の template で Channel<Foobar*> とか作れる気しかしないんで、誰かがそいうの実装したら案外 race はだいぶ減るんじゃないかな…とかなんとか

(21:30)

_ クライミングメモ

10b: 3回前に核心まで行って行ける気がして、2回前に核心が行けなくて、1回前にどうでもいいとこでミスったものの核心が行けて、しかし今回もまたしても核心ですべった。これ通せると 10b 行けたってことで嬉しいんだけど。 10a: へんなとこで違う足場使った。まぁ行けると思うし過去やったことがある気がする… 9: かぶってて少し前はいけなかったやつ。なんかあっさりいけた。実はうまくなってるのかな…とはじめて思った。でも手を打ったのでいたかった 10a: かぶってる 10a にもチャレンジ。無理。 9: 書いてある難易度よりどう考えても難しいものを作る理不尽な人が作ったコース。しかし教育的らしい。手がいたいけどのぼってみる。最後がいける気しなかった

(21:40)

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

_ Egtra [Channelとは、Go言語とかの類に載っているようなやつですよね?ちょうどそういうものがVisual C++にある..]

_ shinh [あー VC はこいうのがあっていいですね… C++ で実装すると全部 template になっちゃってコンパイル遅そ..]


2012-03-06

_ りんぐのーどべんちまーく

http://risky-safety.org/~zinnia/d/2012/02/#20120227-t0-h1-p0 経由で

http://d.hatena.ne.jp/iasija/20091124/1259060817

を見て、 go の方が遅いってのもへんな話かなーとちょっと動かしてみる。

> erlc ring_bench.erl
> time erl +P 200000 -noshell -eval 'io:format("~w\n", [timer:tc(ring_bench, start, [20000, 100, "hello"])]).' -s init stop
{1435773,ok}
erl +P 200000 -noshell -eval  -s init stop  1.72s user 0.21s system 75% cpu 2.554 total
> ~/src/go/bin/6g ring_bench.go && ~/src/go/bin/6l ring_bench.6
> time ./6.out 20000 100 hello
20000 100 1.417406
./6.out 20000 100 hello  1.38s user 0.04s system 99% cpu 1.429 total

1435773 ってのはたぶん micro seconds だろう、と考えるとまぁだいたい互角か、ちょっと erlang の方が遅い。この2年の間に go の処理系がちょっと速くなったって感じなのかな。なんか Core 2 Duo E8400 3GHz vs Core i7-2630QM 2GHz というあたりも考えるとそのへんの違いかもしれないけど。

go のコードは log.Exit がなくなってたので log.Fatal に変えて、 Printf の最後に改行文字欲しかったので入れておいた。

ついでに、 make(chan Msg, 1) は make(chan Msg) の方が速そうかなあというのと、最後の stop は自分に帰ってきてないというのを修正してみたり。高速化はそれなりに効いて、

> time ./6.out 20000 100 hello
2012/03/06 01:51:00 OK
20000 100 1.053176
./6.out 20000 100 hello  1.02s user 0.04s system 99% cpu 1.067 total

とのこと。

--- ring_bench.go	2012-03-06 01:43:53.020232774 +0900
+++ ring_bench2.go	2012-03-06 01:44:09.200232421 +0900
@@ -16,42 +16,47 @@
 func main() {
 	// コマンドライン引数の処理
 	flag.Parse();
-	if flag.NArg() != 3 { log.Exit("invalid argument.") }
+	if flag.NArg() != 3 { log.Fatal("invalid argument.") }
 	n , err := strconv.Atoi(flag.Arg(0));
-	if err != nil { log.Exit("setconv.Atoi:", err) }
+	if err != nil { log.Fatal("setconv.Atoi:", err) }
 	m , err := strconv.Atoi(flag.Arg(1));
-	if err != nil { log.Exit("setconv.Atoi:", err) }
+	if err != nil { log.Fatal("setconv.Atoi:", err) }
 	str := flag.Arg(2);
 	
 	ts := time.Nanoseconds(); // 時間計測開始
 	start(n, m, str);
 	te := time.Nanoseconds(); // 時間計測終了
 	
-	fmt.Printf("%d %d %f", n, m, float64(te - ts) / 1000000000);  // N M 秒
+	fmt.Printf("%d %d %f\n", n, m, float64(te - ts) / 1000000000);  // N M 秒
 }
 
 // メインの処理
 func start(n int, m int, str string) {
-	nch := make(chan Msg, 1);
-	pch := make(chan Msg, 1);
+	nch := make(chan Msg);
+	pch := make(chan Msg);
 
 	// リング作り
 	makeRing(n, nch, pch);
 		
 	// リングにメッセージを投げる
-	nch <- Msg{command:message, str:str};
+	msg := Msg{command:message, str:str};
 	for i := 0; i < m; i++ {
-		msg := <- pch;
 		nch <- msg;
+		msg = <- pch;
 	}
 	nch <- Msg{command:stop}; // リングを壊す
-	<- pch; // リングが壊れるのを待つ
+	msg = <- pch; // リングが壊れるのを待つ
+	if msg.command == stop {
+		log.Println("OK")
+	} else {
+		log.Println("???")
+	}
 }
 
 func makeRing(n int, nch chan Msg, pch chan Msg) {
-	var prevCh chan Msg = nch;
+	prevCh := nch;
 	for i := 0; i < n-1; i++ {
-		nextCh := make(chan Msg, 1);
+		nextCh := make(chan Msg);
 		go makeNode(nextCh, prevCh);
 		prevCh = nextCh;
 	}

(01:51)


2012-03-13

_ ゴルフ会

http://partake.in/events/ca7e323a-7dff-4f60-86af-d20cd30555bb

適当に御参集おねがいします

(01:39)

_ 最近なんだかなーと思ったバグ

if (foobar) {
  LOG(ERROR) << "foobar";
  return;
}

if (barbaz)
  LOG(ERROR) << "barbaz";
  return;

if (hogefuga) {
  LOG(ERROR) << "hogefuga";
  return;
}

doSomething();

とかやってて、 doSomething 呼ばれねーなでもエラーメッセージも出てないななんでだ…とかしばらく考えてしまった。 Python 使うべきか

(01:41)

_ 最近なんだかなーと思ったバグ2

ひき続きぼんやりとぷよぷよをやってて、オレオレシミュレータが欲しいな…とか思って適当に書いてた。

JS で書いてて、 linux chrome で試してたんだけど、 android chrome の方の動作が遅すぎるなーとか思って、ちょっと描画まわりをいじってみたりすると速くなった気がする。

でもなんかやっぱり遅い気がする。というか動かしてるうちにだんだんと遅くなっている気がする。描画まわりをいじって速くなった気がしたのは、リロードして速い状態に戻っただけな気がする。 linux chrome では遅くならないのにナゼ…という。 FPS カウンタを入れてみると、やはりみるみるうちに FPS が減っていく

となるとどんどんデカくなってる配列があるとかかな、でも linux chrome では遅くならんしなーと思いつつデータ見てみるも、そんなのはない。そのうちに android chrome の方だと動かす前の画面で放置しててもだんだん遅くなっていくということに気付く。

はてなんでだろう…お行儀の描画 API の使いたしてて、 android chrome の WebKit はそれが秘孔をつくとかかなーとか思いつつ #sdl-fan-jp でフッシギーとか言ってみる。したら firefox と mac chrome でも遅くなっていくと報告していただく。 win chrome は大丈夫。 firefox については自分でも確認できた。

となるとむしろ linux chrome だけがお行儀が悪いことを許してると考えた方が自然かなーと思う。 chrome の挙動の違いも、どっちかというと最近の WebKit だと大丈夫、って感じかなぁとか思う。

しかしやってることは、イベントの取得、 FPS カウンタの更新、キー押されたかチェックしてるだけくらいで終了するロジック、画面消して線一本ひいて4つ画像を表示するだけの描画まわり、くらい。

この中では描画が一番秘孔をつきそうかな…と思う。

画像を表示する部分は

   fb.drawImage(images[t+2], x * 16, y * 16);

の一行で、これはさすがに大丈夫だろうと思う。

画面を消す部分は

   fb.fillStyle = 'white';
   fb.fillRect(0, 0, fbW, fbH);

だけで、これも大丈夫だろうと思う。 'white' とかは実装がすごいバカならすごいことになってもおかしくない気がするけど、 WebKit の実装を思い出すに別にバカだった気がしないし、こんなよく使われてるとこがおかしかったらマズい。一応 clearRect に変えてみたりしたけど関係ない。

線一本は

   fb.strokeStyle = 'red';
   fb.moveTo(puyo.offsetX + 16, puyo.offsetY + 16 * 2);
   fb.lineTo(puyo.offsetX + 16 * 7, puyo.offsetY + 16 * 2);
   fb.stroke();

だけ。これもよく使われてる部分だし秘孔つく気もしないな…と思う。でもそういえば closePath ってあったなーと思って、あれって正方形とか書く時に最後の一辺を書くだけぽいから直線にはいらないと思ってたんだけど…と思いつつ入れてみるもなおらない。ひょっとしたら同じ線を書くオペレーションがどんどん積もっていって、 1000 フレーム後には 1000 回同じ線をひいてるとかになってるのかと思ったのだけど。

はてな…と。しかし linux firefox で再現してるのはありがたくて、 android よりはるかに挙動を観測しやすい。 top 動かしてみると、最初は 10% くらいだった firefox の CPU 使用率が徐々に増えていって、 100% になると FPS が減りはじめる。なるほど firefox で大丈夫な時とダメな時があると思ってた理由は、単に待った時間の差か。あとメモリ使用量は増えてない。まあリソース喰い潰してたらもっと大変なことになるよな…と。

となるとやっぱ描画オペレーションが溜まっていってるのかな…と思って、そういえば canvas の getContext('2d') は最初に呼んで取得したコンテキストをずっと使ってるけど、毎フレーム取得しないと良くなかったりするんだっけ…とか思いつついじってみるもなおらない。まああたり前です。

でもとにかくあやしいのは線だよなーと思って、線をかくコードを消してみる。遅くならない。やはりこれかとなる。これをさっさとやれよ…という感じ。遅くなるって現象が起きるのに時間がかかるから、 iteration に時間がかかるんですよね…

で、ちゃんと canvas の API を読みなおそう…と見てみると、 beginPath というのがある。そうか beginPath で前回の描画オペレーションがクリアされるのか俺はアホかーと。 fb.beginPath() を足して解決。

たぶん最近の WebKit には同じ描画が繰り返されたら省略する、みたいな最適化が足されたのかなぁ、というのが今の予想。おせっかいな感じもするけど、機械が生成した canvas のコードとかで重複が結構あるとかはありそうだから、まぁ悪い話ではないのかもしれないなぁ…

というような、なんだかなぁ…としか思えない、くだらないバグだったんだけど、妙に時間を消費した。思ったこととしては、

最近特に自分で使うものなんて、 WebKit 以外どうでもいいべーとか思ってるけど、セカンドオピニオンというか、まぁ他のブラウザで試してみるのもそれなりにした方がいいかな…ということ。 linux chrome で起きなくて android chrome で起きる問題を修正するのに、 firefox が役に立ったんだから…

ゲームぽいことやる時は FPS カウンタって本当に役に立つよね…ということ。

(02:09)

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

_ jiro [-Wunreachable-code が -Wall -Wextra に含まれてるといいんですけどねぇ…]


2012-03-16

_ ミク

なんかライブは前のが最後ということで、おーじゃあ今後見れることないのかな…と、うっかり

http://www.amazon.co.jp/DVD%E3%80%8C%E3%83%9F%E3%82%AF%E3%81%AE%E6%97%A5%E6%84%9F%E8%AC%9D%E7%A5%AD-Giving-DayProject-presents-%E5%88%9D%E9%9F%B3%E3%83%9F%E3%82%AF%E3%83%BB%E3%82%BD%E3%83%AD%E3%82%B3%E3%83%B3%E3%82%B5%E3%83%BC%E3%83%88%E3%80%9C%E3%81%93%E3%82%93%E3%81%B0%E3%82%93%E3%81%AF%E3%80%81%E5%88%9D%E9%9F%B3%E3%83%9F%E3%82%AF%E3%81%A7%E3%81%99%E3%80%82%E3%80%9C%E3%80%8D/dp/B003S9U5BE/ref=sr_1_6?ie=UTF8&qid=1331832992&sr=8-6

を買ってしまった。

ミクってのは現象的にはかなり好きで、好きな曲も結構あって、ただ色んな人が作ってるから、あまり好きじゃない曲もいくつかあって、見てる最中の感想は早く終わらんかなだったという。

いや実物見てみたかった…

そういえば会社で「なにごとも最初のやつが一番いいんですよ。VOCALOIDとかもミク以外どうでもいいでしょ」とか言ってる人として MEIKO KAITO かわいそうだなあとか思ったけど、しかしこの DVD にもいなくてかわいそうだった。他のはいたんだけど。

(02:46)


2012-03-17

_ 偶奇

http://logsoku.com/thread/engawa.2ch.net/poverty/1330078980/

2で既に正しい答えが出てるのに、証明できないのをバカにしつつ間違った答えを乱発するという、なんともいえない感じの…

しかし実際このへんの証明とかむずかしいよな…いきなり道端で聞かれたら結構考えそうだ

(16:41)


2012-03-18

_ あたりまえな気もするけどいいこと言うな的な

ことを最近ときどき思う。 たまたま覚えてるってかメモ取ってたのはこの2つ

http://karino2.livejournal.com/86589.html

http://qiita.com/items/773

前者はバランスだいじだよなあとか。

後者はなんか漠然とした感じの質問になんか正しい感じの答えだなぁとか。できづくと natsutan さんだった。

(17:43)


2012-03-21

_ ゴルフ場メンテナンスマニュアル

ags/fe/masquerade.sh を FE で実行して、 BE 側の gateway を適当にセットするとネットワークがつながる。

(02:07)

_ Piet

をゴルフ場に足して、これの Quine は結構たいへんだなーと思ったら mame さんが既にやってた…

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

なるほどデータはこいう感じに置けるわけか…

(03:15)


2012-03-23

_ ゴルフ場に言語いろいろ足した

適当にリクエストされてたものとかを足した。 それぞれについて適当になんか書いてみよう

  • CLC-INTERCAL: 元祖ジョーク言語。 PLEASE PLEASE 言わないと動いてくれない言語。いろいろ方言があるみたいだけど、 C-INTERCAL と CLC-INTERCAL がだいたい有名で、 CLC-INTERCAL の方が後のものぽかったのでこっちを。必要なら C-INTERCAL の方も入れます。ジョークとしてはまぁまぁ古いけど面白いんだけど、いかんせん言語的な面白さはあんま無いんだよな。
  • Icon: Perl が参考にした言語のひとつ…だった気がしたけどどこにもそう書いてないな。それで気付いたけど、オライリーにもらった言語系譜 (http://oreilly.com/news/graphics/prog_lang_poster.pdf) を引越してから部屋に貼ってないな… Python が参考にしたのか…まぁ詳しくは kinaba さんを参考のこと http://www.kmonos.net/alang/etc/icon.php 僕の印象はここに書いてあった every だけ
  • SNOBOL: Icon と同じ作者…だけど hello は似ても似つかない。よくしらない。
  • REXX: YTさんが触ってた言語だっけ…と思ってたけどそれは REBOL だった。まったくしらん。
  • PARI/GP: さっきはじめて聞いた
  • gnuplot: なんかループ書けるんですよね…
  • Malbolge: あきらかに最狂言語。 INTERCAL と違っていろいろ考えることができてとても面白い言語だと思う。なんか難易度のバランス調整が絶妙な気がするんだよな。基本絶望的な要求をしつつ、 NOP があるとか jmp がループ不変とか、微妙な救いが用意されてるというか…この複雑さをインタプリタ164行が作ってるってのも味わい深い…
  • Euphoria: なんだろうこれ
  • K: APL 系のやつ。欲しいということだったので。
  • Piet: 画像言語。まあ面白いと思う。ゴルフ的には奥が深すぎてしんどい系だと思うな…

TODO としては、

  • TeX: stdin/stdout の処理が適切にできる方法がよくわからない。 \message とかだとゴミがくっつくし。だれか教えてください…
  • Dart: Google 言語。
  • Sawzall: ログ処理 Google 言語。分散構造化 awk
  • Falcon: 名前しか聞いたことがない
  • MUMPS: 知らん
  • Occam: 名前聞いたことあったっけ…

ちょうどこれだけ足すと 99 言語になるな…

(02:43)

_ MOCO'sキッチン

http://wintomorrow.at.webry.info/201202/article_25.html

おもろいな。

なんかイギリスで似たような番組似たなと思った。人気番組という話だったから、フォーマットをマネしたのかも。どんなとこが似てたかっていうと、なんか料理番組ってよりパフォーマンス的なところ。具体的には

  • なんかかっこいい俳優が料理する(イギリスのは女の人だったけど。あと料理用の服じゃなくてスーツだった)
  • 分量の説明とか全くしない
  • 謎の材料がなんか適当にほうりこまれる

とか。

イギリス人はこの番組を見て、料理なんて当然せずにさてととマズい外食を喰いに行くのが日課と、先生が言っていた

(03:37)


2012-03-26

_ 連鎖尾入門

僕がよく作る形にちゃんと連鎖尾を入れたい。雪崩と称して適当に4つずつ置いていって同時消しになったり消えないのはそろそろ卒業しないといけない。いきなりむつかしいのはなかなかできないので、形よくなくてもなるだけわかりやすいやつ。

黄色上L

http://bit.ly/GRG9dF

http://bit.ly/GPj9aE

http://bit.ly/GPzAJ0

本当は青の下に潜り込ませたい。

http://blog.livedoor.jp/tom109/archives/51101707.html

でも今のレベルで複数潜り込ませると混乱するので、現実的に把握できそうかつ第二折りや潰しに使えそうなのはこういうのかなぁ。

http://bit.ly/H2fKZ3

赤の潜り込みさえできれば、残りの赤は割とどこでもいいみたいだ。

http://bit.ly/GZGj4M

http://bit.ly/GZGrB6

http://bit.ly/GPw7Gx

黄色Z

この形は左端しかこういう使い方できないんだな…

http://bit.ly/H2DpuY

雪崩の場合は右端限定かな。君案外使いにくい子だったんだね…

http://bit.ly/H2DQ8A

潜り込みも手に負えそうなのはこれくらいか…

http://bit.ly/H1y7L8

右端の青を乗せない方が雪崩自体は組めるけどこれはあまりやりたくないな…

http://bit.ly/H1yuFe

黄色四角

黄色が四角になるパターンはこれくらいしか組みやすそうなのを思いつかない。

http://bit.ly/GPHfad

黄色凸と黄色下L

これはもうわかりやすいから雪崩でいいよ、って気になるけど、高いところは逆さまに置いた方がいい、ってのを忘れがち

http://bit.ly/GPHXEr

http://bit.ly/GPIbeK

http://bit.ly/GPIvKj


2012-03-29

_ クライミングメモ

  • 黄10b: なんかいきなりいける気がしない感じで落ちた。あれこれやってると少し登れたけどそっからよくわからなくてやめた
  • ピンク10b: ずっと通しでいきたかったやつ。いけた。ただ核心のとこであれーここどうすんだっけ忘れたなーと思ってたら下からアドバイスもらって行けた感じだった。
  • 黄10b: 見本を見てからリベンジ。そこらじゅう落ちまくりつつ途中の部品部品を練習していった。2/3くらい行ったとこでここどうすんだーてとこで腕の力尽きてたので終わり。
  • ピンク10a: 割と余裕で登れた記憶があるけど、疲れてるからキツイかなーと思ったけど余裕だった。

(23:22)


2012-03-30

_ ladder corners problem

http://golf.shinh.org/p.rb?Ladder+corner+problem#dc

dc で対抗してたけど完璧に負けたー。

ぱっと見た感じまぁだいたい思ってた通りループの条件が雑すぎたかなぁ。

しかしそうか kK で整数化できるわけね…これは今まで使ってたテクニックだっけな…

(00:55)


2012年
3月
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.jiro(2012-03-14 23:44) 2.shinh(2012-03-03 00:58) 3.Egtra(2012-03-02 22:39)
search / home / index

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

shinichiro.hamaji _at_ gmail.com / shinichiro.h