トップ «前10日分 最新 次10日分» 追記

はじめてのにき

ここの位置付け

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|12|
2025|01|02|03|04|05|06|07|

ToDo:


2014-02-11

_ 読んだ本

  • 天冥の標1-6: 最初の方は読んでてしんどかったけど、だんだん面白くなってきた。1が長いくせに伏線散らすだけで、SF的面白さもなくてだるかった。2は病気の話。ちょっとだけ面白くなった。3はもうちょっと面白くなった。わかりやすいSF的な。空中戦闘と中二的な呼びかけが良い。レイジチャージパラージ。4はエロ。エロだからとか関係なく、単に面白くない気がした。主人公二人が気に入らないというのもあるし、オチがいつの少女漫画ですか的な感じだし…5は農場経営とか。面白い。こういう前提の世界で、社会はこうなってますよ、って納得できる感じで描写されてると楽しい。一個前は全く納得できなかったんだよな。あ、ノルルスカインとかいう情報生命の話も良い。6は話が動きはじめた感じなのかな、普通に大変面白かった。おおむね面白くなってきてるので、7-10は楽しみ。最初の方とかはもうちょっとなんとかならなかったのかな…
  • 種まきガールズ: 小野ほりでいという人の http://togech.jp/2013/06/18/2012とかが面白かったので買った。普通、っていうかトゥギャッチの方が面白いかな
  • 国語入試問題必勝法: 結局全部読んだんだっけ…
  • 遺跡の声: 地味に面白かった。地味だけど。フェルマーの最終定理が解かれる前に書いたらしく、とんでもない難問としてフェルマーの最終定理が出てきてて味わいぶかかった。
  • フリーランチの時代: 小川一水短編集。まあまあ的な。特に表題作は印象に残った。
  • 老ヴォールの惑星: 小川一水短篇集。こっちの方が好きなのがそろってたかな。ギャルナフカの迷宮てのと漂った男とか。
  • 青い星まで飛んでいけ: 小川一水短篇集。バラマンディのサエってのが良かったかな…
  • 臨機巧緻のディープブルー: 小川一水。なんかまぁ面白いんだけど、短編の方がラクで良いな…ていうか、この人もうちょっと暑苦しいレベルにムダに熱い感じの書いてる人だと思ってたんで、この短編3つと長編でだいぶ印象かわった。で暑苦しい系のが好きなんだなとも認識した。
  • この世でいちばん大事なカネの話: どうもファンらしいので西原本を読んでみた。
  • 国民クイズ: ひさしぶりに読みたくなって買ったけどやっぱ面白いと思う。
  • 僕らはみんな死んでいる10: オチだけ気になったので読んだ。そんなんでいいのかよっていう。
  • 校舎のうらには天使が埋められている1-3: いじめマンガ。だんだん鬱ぽさが減って、最後はひどい
  • 空が灰色だから1-5: 前から買うかなーと思ってたので買った。思ってたより破壊力ある話の密度が低かったけど、たまにすごい話がある
  • 変ゼミ8: 平常運行
  • アジアを喰う: インドじゃなかったよ…
  • マスゴミ: わりとどうでもいいか
  • ピコピコ少年: ハイスコアガールズ同様世代があってるから面白い…
  • MMR復活編: 復活するなよ…
  • 34歳無職さん: ふつう
  • 粋奥: ふつう
  • 式の前日: どんな話だっけ
  • 夕凪の街桜の国: 面白かった
  • 俺はまだ本気出してないだけ4: どうでもいい

他にもゴミみたいなマンガいっぱい読んだけど、まぁめんどくさいというか、書く意味ないのでやめた。最初読むのが苦痛なレベルだった天冥が面白くて困りますね…

(04:15)


2014-02-09

_ emacs は git 使うべきってはなし

http://lists.gnu.org/archive/html/emacs-devel/2014-01/msg00005.html

スラドで ESR が emacs ML に bzr やめろって言った、って話を見て、原文とそれへの反応見たいなーと思ってたのでながめた。

というのは、みんな黙って git 使え、ってのは基本的に大賛成だから。 VCS じゃなくて shell とかなら別に bash 使ってようが tcsh 使ってようが個人の自由でいいんだけど、 VCS とビルド手順だけは大きなプロジェクトはなるべく長いものにまかれて欲しい。

一方で別のやつに愛着ある人からすればふざけんな、って感じではあると思うけど、ある程度大きなプロジェクトは開発者がチェックアウトする回数より多く部外者がチェックアウトするわけで、ある程度我慢して欲しい感じなんだよな…

というわけでながめた結果、おおむね好意的に受けいれられてるっていうか、反対する人はいない感じみたいだった。 ESR 節はスルーされてて、オトナな感じ。これはそこまで意外じゃないっていうか、なんかあちこちで git に移行しようぜーって議論を見たけど、案外強く反発するとこ無いんだよな。

でまあ見てると ESR 以前にも git にしようぜって言った人がいて、こっちもおおむね賛成気味だったんだけど、 RMS が bzr にチャンスをやろうとか言って suspend 、みたいな state のようだ。

http://lists.gnu.org/archive/html/emacs-devel/2013-03/msg00776.html

ところで統一して欲しいものとしては distrubutor のパッケージツールってのもあるな… apt-get とか yum とか。

(08:05)

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

Before...

_ kosaki [いまんとこ、githubのpull requestは簡単なものは代理コミットされてclose、難しい物は bugs...]

_ naruse [公式見解は出ていませんが、Git/GitHub移行派を黙らせるための有力な手段の一つとして認識されてはいます。]

_ kosaki [わたしはnaruseさんのその理屈に説得力があるとは思ってないので賛同できませんが、それはさておき、言ってるパッチっ..]

_ hsbt [nacl の修正全くわからないので取り込んで良いのかよくわからないのですがどうするのがいいんですかねえ。@yugui..]

_ shinh [ああすいません yugui さんに言っておこうと思いつつ忘れてるという state です…]


2014-02-08

_ libarchive

errno 入れてる変数に条件式で

r = (a->fd < 0);

とかしてやがる… 1 は EPERM とかにせずにもっとレアなエラーにしておいて欲しかったな…

(23:30)


2014-02-04

_ C++/Boost

http://atnd.org/events/47238

なんか日本の C++ イベントはことごとく僕がいない時に行なわれるなあ…と思うとともに、いよいよ興味のある話がなくなってる上にていうかあんまりこれは C++ だと思って C++ を書いた記憶がない。

僕にとって C++ とは…

うーんデバッグ用に書いた PrintHoge って関数呼びたいなあ、えいやっ

void PrintHoge();

うーんああ呼び出し元は C++ のコードかめんどくさいなあ、えいやっ

extern "C" void PrintHoge();

うーん C++ では () は引数取らないって意味らしいなあ、えいやっ

extern "C" void PrintHoge(...);

みたいに調整がめんどうなものになっており、いやそんなはずは無いはずなので C++ 自体は悪くないと今でも思っている…

(00:10)


2014-02-02

_

なんか知らんけど、共有オブジェクトと意味不明なつきあいかたをしていて悩まされる感じの夢を見た。同名で内容の違ったのが二つあって、それが両方必要。で、いやこっちのバイナリはあっちのやつを読んでくれないとまずいのに…とか悩んでいる

基本的には意味不明な状況だけど、夢でまでこの手の問題を考えるとのか…と感慨深くなった。

(09:16)

_ 今日の nacl_io

2 drw-rw-rw-  0 1001 1002   0 Feb  2 04:19 foo
2 -rw-rw-rw-  0 1001 1002 129 Feb  2 00:35 hello.c
2 drw-rw-rw-  0 1001 1002   0 Feb  2 00:31 mingn
2 -rw-rw-rw-  0 1001 1002   1 Feb  2 04:20 moe
2 -rw-rw-rw-  0 1001 1002   1 Feb  2 03:48 ok
2 drw-rw-rw-  0 1001 1002   0 Feb  2 02:11 tmp
2 drw-rw-rw-  0 1001 1002   0 Feb  2 03:52 xxx

なんで全部 inode 同じなんだよ! てーか実装見る感じこれ開くたびに変わる気しかしないんだけど…

(16:19)


2014-02-01

_ ロボットレストラン

にチームの人と行った。なんだこれ…って感じですごかった。

チームの人は女の子の乗った鮫が悪いヤツを喰ってるシーンが一番良かったとか言ってて、ロボットレストランって名前からは全く想像できない感想であった。

セグウェイが事故ってたり、あとそもそも見たこと無い乗り物とかがあった。あれはバイク的なものだったのかなぁ。

(12:59)

_ checkpointing と process migration 、あと zygote

http://i-saint.hatenablog.com/entry/2014/01/30/014332

undump (http://d.hatena.ne.jp/shinichiro_h/20060715#1152922272) 書いたあとに、結構既存研究があるぽい、ってことでちょっと勉強したことがあるなぁ。

モジュール、ヒープ、ページメモリ、スタックまでのメモリは、単純にメモリのマップされてる領域を片っ端から保存しておいて、復元するのが簡単なはず。 Unix なら core に program header が入ってるので、どうマップすればいいかもそれ見りゃわかるし、復元も copy-on-write で mmap するだけでいいはずで安いし省メモリ(初期化だけに使った用なメモリはメモリ消費しないんで)、たぶん。 Windows の core 相当が何か知らないけど、まぁ無いわきゃない…のかな

スレッドはスレッド起こしなおして元の PC に飛ぶだけ。 TLS があるならその前に TLS 用のレジスタも復帰するだけ。

で、たぶんそこからが結構地獄で、 fd の復元がまずもってめんどくさい…がこれは技術的には普通に可能で、書いてあるようなやり方で全然いけると思う。このへんくらいまでは、既存のオープンソースのライブラリとかが、 undump 作った直後くらいの段階でほどほどにある感じだったと思う。

IPC とネットワークはたぶん本気でたいへん。なんか論文とかで結構あったと思う。日本の大きなメーカとかが、ルータとかまで手入れて、メンテしたいマシンにいたサーバプロセスの移動とかした話を聞いたことがある気がするけど、まぁ費用対効果がすっごく低い気がする。

クラウド屋さんとかだと、データを serve してるプロセス動かしたい時は単に殺して他で生き返らせても動く構成にしておけばいいじゃん、どうせマシンって壊れるんだしさ…って風潮になってると思う。大量並列計算みたいなやつだと、ソフト側に協力させて、ここで状態保存ですよーみたいなことやる感じにしてると思う、 mapreduce とか。というわけで、僕の感覚ではサーバ用途ではこのへんの研究は流行ってない…気がする。

クライアントアプリだと初期化の高速化っていう限定的な用途で普通に使われてそう…かな。有名所だと emacs って今でも一通りの初期化した後の core を保存しておいて、そこから復帰する感じで起動してる…と思う。このへんだとメモリだけできれば良かったりするのでだいぶラクなんだろうね。

だーいぶ話がそれるけど、 Android やら Chrome がやってる zygote ってのもディスク使わず似たようなことをやってる感じ…だと思う。初期化が終わった状態のプロセス (zygote process) を用意しておいて、そのプロセスをもう一個作りたくなったら、一から初期化しなおすんじゃなくて、 zygote process に IPC 送って fork してもらう。これも初期化用途なんで、 fd から先のめんどくさいことはほとんど考えなくて良い。 Chrome 動かした状態で ps --forest すると chrome が階層構造になってるのがそれ…

と思ったんだけど、なんか僕が思ってたより一段深いなこれ…よくわからんけどぱっと見、 zygote に IPC 送る専用のプロセスがいる感じなのかな。 Chrome むつかしい…

(13:54)

_ びーる

最近は飲み会以外で日本大手のビール/発泡酒/第三種を飲むのを完全にやめた。酒は飲んでて何飲むかっていうと地ビールをなるべく飲んでいる。単にラガーに飽きただけかもしれないけど。

何が好きかというとまあなんでも飲むんだけど、今はペールエールとベルギー流の白ビールが好きな気がする。 IPA とスタウトあたりはちょっと前好きだったけど最近好きでないので、あまり好みは固定されてない気がする。銘柄は最低でも10回くらい飲まないと覚えられない子なので、あんまり覚えない。というかビールってこう適当に飲むもんなので、日常的に手に入らない種類にはイマイチひかれない。好きで覚えてるのは、結局日常で触れられるもので、

  • シエラネバダ: ペールエールだと思う。西海岸でどこでも手軽に飲めるからやたら飲む…ので多少飽きた
  • ファットタイア: ペールエールだと思ってたら amber ale らしい。 amber ale ってなにかなーとぐぐったらまぁ似たようなものらしい。西海岸でまあまあ売ってて、シエラネバダよりこれの方が今は好き。この new belgium とかいう会社のやつは、今まで飲んだ範囲では全部うまかった。日本で手に入れたいんだけど、売ってないぽいんだよな…
  • ブルームーン: ベルギー白だと思ってたけど、サイト見るとなにやら工夫してるらしい。西海岸で飲む。サイト見ると日本でも結構飲めるらしいなぁ。
  • ヒューガルデン: ベルギー白。会社で金曜に出るから飲む。普通に日本で買える。なんか人気なだけあってうまいと思う。
  • ブラン: ベルギー白だと思う。フランスだけど。ヒューガルデンより甘いというかなんか。金曜に飲む。最近好きな気がしてたけど飽きてきた。
  • ピルスナーウルケル: ピルスナーではとりあえずうまい。他にも好きなの結構ある気がするけど、名前覚えられん。これを覚えてる理由はもちろんもやしもんに出てきたからでしかない。

日本のだとよなよな最強だなぁ。よなよなエールと水曜日のネコがうまい。あと昔はそれほどでもなかったけど、銀河高原もうまいような。まぁでも上記の連中の方が好きかな。

会社の外人に日本酒と焼酎飲ませながら、日本は地ビールが最近まで作れなくて、大手が強すぎてさみしい、とかいう話をした。ら、「アメリカも似たような法律が30年前くらいまであって、それまではワインは色々個性があって上流階級の飲むもので、ビールは労働者の酒だった。種類はクアーズバドワイザーハイネケンみたいなラガーが4種類くらいあるだけで」みたいなことを教えてもらって、勉強になった。アメリカでも地ビールが浸透するのは時間がかかったから、そのうち流行るんじゃね、とか言ってた。今の雰囲気ではそんな気がしないけど、まぁそういうもんかもしれぬ。

(19:28)


2014-01-22

_ ld

冬休みに昔作った nacl-gcc を Chrome の NaCl 上で動かすってのを復活させて、 bash の上で動かしてたりしてたのをチマチマ naclports に入れていっている。

その時一番困った問題は、これ

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

もうちょっと詳しく書いてみる。

最新の nacl-gcc/nacl-binutils で最新の nacl-binutils をビルドするとリンクがこけて、少し古い nacl-gcc/nacl-binutils で少し古い nacl-binutils もビルドできず、しかし古いので新しいのを作るか、新しいので古いのを作ると大丈夫という問題があった。

きっと ./configure がなんかヘンなもの detect しちゃって compile/link flag が微妙に違うとかそういうのだろーなーと見てみても、コマンドラインは基本一致している。

はてこれはいよいよおかしいなーと -v とかつけてみると、リンカスクリプトの prefix を指定するオプションが古いやつと最新で違う。古いやつは elf_nacl で新しいのは elf_i386_nacl 。しかしこれが一致してると動くならともかく、一致してると動かないのはヘンだ。

しょうがないから strace とかで様子を見ると、 ld をリンクする時だけ、カレントディレクトリにある ldscripts/elf*_nacl.x* とかを見ている。 ld をリンクする時は ld の出力ディレクトリに cd してからリンクしてるんだけど、この時 ldscripts ってディレクトリが既に置いてある。しかしこれ同じ内容のものがあるなら問題ないはずなんだけどなぁ、と見てみると、どうも static link 用の ldscripts が置いてあると気付く。

で、わかったことは nacl-glibc の shared link 用の ldscript はこっちのディレクトリにあって

https://chromium.googlesource.com/native_client/nacl-glibc/+/master/nacl/dyn-link/ldscripts

かつこれは後から ld の中に置いてある ldscripts と merge されているってこと。 linux 用の nacl-binutils をビルドする時はカレントディレクトリに置いてある NaCl 用の ldscripts は無視されるから問題ないんだけど、 NaCl 用の nacl-binutils をビルドする時は static link 用の設定を読んでしまうってわけ。

まぁ結局対処としてはカレントディレクトリにある ldscripts ディレクトリを ld をリンクする時だけ一時的に rename してやれば良くて、実際はこんな感じ

 ld-new$(EXEEXT): $(ld_new_OBJECTS) $(ld_new_DEPENDENCIES)
 @rm -f ld-new$(EXEEXT)
- $(LINK) $(ld_new_OBJECTS) $(ld_new_LDADD) $(LIBS)
+ # ./ldscripts/* will be read during this link and it messes up the
+ # link result because ./ldscripts contains the linker script for
+ # statically linked binaries. So, we temporary rename it.
+ mv ldscripts ldscripts.tmp && ($(LINK) $(ld_new_OBJECTS) $(ld_new_LDADD) $(LIBS) || (mv bar foo && false)) && mv ldscripts.tmp ldscripts

NaCl で遊んでると、大袈裟にハマってから、「俺だから致命傷で済んだがお前には NaCl は難しい」とか中二的な発言をしたくなるエピソードがたくさんできるわけだけど、これはまさにそういうインスタンスであった。

(01:36)


2014-01-21

_ lld

ちょっと前になんとなくコード書いてるとこ撮ってみたやつだけど、 lld じゃなくて ldd だなぁ…とか思った。

http://www.youtube.com/watch?v=Lw2cW-n4hC8

わかったことは elf.h 見ないと ELF 扱うプログラム書けないぽいってことだった。あと vim 使えてない

(03:18)


2014-01-12

_ ぷよm@s

http://www.nicovideo.jp/watch/sm22653884

やっとトーナメント終わった

(23:20)


2014-01-10

_ ARM

http://www.ced.is.utsunomiya-u.ac.jp/lecture/2013/aca/ARMjp-vH.pdf

ざっくりと ARM モードの命令セットをながめた。なんか結構ヘンなのあるんだなぁ。 short な複素数に便利ですって言われても僕の日常にはあまり影響しないよな…まぁ暗号とか動画エンコーダとかそのへんで便利だったりするんかね。

まだイマイチ GE フラグがよくわかってない…がまぁいいか。

Thumb はだいたいこれのエンコードが違って命令が少ないバージョンって理解でいいのかな…また今度ざっくり眺めよう

(01:18)

_ x86-64 ABI of TinyCC

http://repo.or.cz/w/tinycc.git/commitdiff/55ea6d3fc175b0e01e2e946ca9b319c1fbe8aa67?hp=3f1d9000071eeebe315795079c3adbe4022d6d19

なんか TCC がちゃんと x86-64 ABI 守る呼び出し規約やっててびびった。頑張って実装したなあ…

(01:50)


2025年
7月
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-02-21 00:03) 2.mame(2014-02-20 23:44) 3.shinh(2014-02-17 01:33)
search / home / index

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

shinichiro.hamaji _at_ gmail.com / shinichiro.h