ToDo:
かかったらしい。 木曜にしんどくなって 木曜朝の時点で 38 度ちょい。 まぁこのくらいなら熱は慣れててなんてことないけど そうは言ってもしんどいので休む。 バファリン飲んでたけど昼頃とかもどんどんしんどくなっていって 夕方頃には 39 度近くに。
しゃーないので病院に行ったところ、 たぶんインフルエンザだろうと言われつつ検査の結果は陰性。 ただ発熱後24時間以内とかは見つからんもんらしいので それ結局検査の意味あるんかいな…という。 まぁたぶんインフルエンザなのでそう仮定して薬飲むかいということで タミフルとかそのへんをもらう。
夜くらいはまだ熱は増えて深夜の段階で 39.3 。 解熱剤飲んでて 39 度出てるとかやばいなーとか思った。
朝5時くらいには 38.6 とかでだいぶマシに。 そこから飯喰って薬飲んで寝て飯喰って薬飲んで今に至るわけだけど、 37.5 とかでもうすっかり元気。
医者にタミフル飲んでラクになったらインフルエンザだよーと 言われたのでもうほとんど間違いなくそうなんだと思う。 一応病院で検査しなおしてもらって確定させてもいいと思うんだけど、 しかしもう9割方状況証拠あるような状態で病院行って 他の人にうつしたら申し訳ないし まぁラクになっているのでこのまま寝ててもいいかなあ… 他の妙な病気の可能性を消せるってくらいしかメリットないし。
潜伏期間平均2日らしいし新幹線でうつされたんだろうなー。
(21:09)
http://d.hatena.ne.jp/KeisukeNakano/20100109/1231593647
すごいなー
(17:06)
http://slashdot.jp/~taro-nishino/journal/497528
これは OSS とかそいうのでは重要な話なんだろうなぁ。 OSS やってたけどつらくなったと言う人は こっち系の話をすることがあるように思って、 そういうのはこの話的には失敗と言えるのかもしれないなぁ。 しかしまぁこういうコミュニケーションを 最初に試みる役目はあんまりしたくないよなぁ…
特に英語はありえん
(17:12)
だらだら書いてみたわけだけど、 同じようなことを GCC とか Emacs とか Xen とか Qemu とか valgrind とか なんでもいいけどまぁ他のプロジェクトであるといいなぁ。
(05:10)
stat が遅いということがあって、 長い間こんな ls を使っていた。 要は 2回 ls をして、最初の ls で 500 エントリ以上あると判明したら 色つけたりをやめる。 stat が 500 回とか当時のマシンでは相当キツかったから。 LS は vanilla ls ね。
ls () { if [ `LS -B $@ >/dev/stdout >&/dev/null | wc -l ` -le 500 ] ; then LS -F --color -B $@ else LS -B $@ fi }
今時こんなもん意味あるんだろうか… そもそも dirent の d_type 見てくれたりしてくれんの? ということで strace してみる。 すると見事に stat 呼んでない。 coreutils の ls.c も適当に読んだところ、 たぶん DT_UNKNOWN とかじゃなければ基本 stat 呼ばない気がする。 よってこんなハックもういらない。
どうでもいいけど ls.c のこの if 文は力作すぎる
if (command_line_arg || format_needs_stat /* When coloring a directory (we may know the type from direct.d_type), we have to stat it in order to indicate sticky and/or other-writable attributes. */ || (type == directory && print_with_color) /* When dereferencing symlinks, the inode and type must come from stat, but readdir provides the inode and type of lstat. */ || ((print_inode || format_needs_type) && (type == symbolic_link || type == unknown) && (dereference == DEREF_ALWAYS || (command_line_arg && dereference != DEREF_NEVER) || color_symlink_as_referent || check_symlink_color)) /* Command line dereferences are already taken care of by the above assertion that the inode number is not yet known. */ || (print_inode && inode == NOT_AN_INODE_NUMBER) || (format_needs_type && (type == unknown || command_line_arg /* --indicator-style=classify (aka -F) requires that we stat each regular file to see if it's executable. */ || (type == normal && (indicator_style == classify /* This is so that --color ends up highlighting files with these mode bits set even when options like -F are not specified. Note we do a redundant stat in the very unlikely case where C_CAP is set but not the others. */ || (print_with_color && (is_colored (C_EXEC) || is_colored (C_SETUID) || is_colored (C_SETGID) || is_colored (C_CAP))) )))))
{
でまぁ NFS なんだけど、 NFS だと結構 DT_UNKNOWN がかえってくるみたいだ。 一見して一回 stat したら cache されて その情報で d_type 埋めてる、って感じかなぁ。 となると worst case で stat 呼びまくるのはさけがたい感じなのかなぁ…
一番うざいのは zsh & nfs でたまに補完がすごい遅いという話で、 zsh はどうも d_type とか気にせず stat 呼びまくってるっぽいんだよなぁ。 コードちょっと読んだけどイマイチよくわからず。 NFS で最悪状況でのパフォーマンスが良くならんとわかったのもあってやる気失せてきた
(22:38)
LS -B $@ >/dev/stdout >&/dev/null
ってなんだろう。なんで
LS -B $@ 2>/dev/null
じゃないんだろうか。 まぁ書いたの10年くらい前だろうし shell のシの字くらいもわかってなかったのかもしれず
(22:40)
charset セットしてくれてないサイトで WebKit は化けるんだけど、 まぁいいかげん detection ぽいの作ろうと。 どうやればいいのかよくわからんかったのだけど、 とりあえず以下のを Chrome key に読ませたら動いた。 とりあえず牧野先生のところとその他もろもろでそれなりに動くから良しとする。
var CHARSETS = ["Shift_JIS", "EUC-JP", "UTF-8", "ISO-2022-JP"]; var currentCharset = document.charset; var bestText = ''; var bestScore = 20000; var bestCharset = currentCharset; for (var i = 0; CHARSETS[i]; i++) { var charset = CHARSETS[i]; if (charset == currentCharset) continue; var http = new XMLHttpRequest(); http.overrideMimeType("text/html; charset=" + charset); http.open("GET", location.href, false); http.send(); var text = http.responseText; var last = text.length; if (last > 10000) last = 10000; var bakeCount = 0; for (var j = 0; j < last; j++) { if (text.charCodeAt(j) == 65533) bakeCount++; } console.log(charset + ": " + bakeCount); if (bakeCount == 0) { document.body.innerHTML = text; document.charset = charset; return; } else if (bestScore > bakeCount) { bestScore = bakeCount; bestText = text; bestCharset = charset; } } document.body.innerHTML = bestText; document.charset = bestCharset;
(23:31)
最近 64bit とかになって hoge_t* が 8 バイトあるのが 耐えられないとか言ってよくわからないうわごとをよく言っている。 そういううわごとの一つとして最近よく言ってるのが x86-34 で。
まず ELF 。たぶん class は ELF32 でいい。 Machine は EM_X86_34 で。
kernel 。 CPU は 64bit モードで動かすけど kernel が mmap にかえすアドレスは 34bit 空間に。 vdso とかそのへんも 34bit 空間で。
コンパイラ… int* とか string* とかは 32bit で表現。 デリファレンスは全部 4*(%rax) とかで頑張る。 char* とかとにかく 4byte 以下のデータへのポインタと void* はしょうがないので 64bit で表現。 だから sizeof(char*) > sizeof(int*)
char* => int* の cast とかは基本無理で困る。 まぁデータの 3byte 目を int として読むみたいな、 つまり *(int*)(chptr+3) みたいなのは許すとして、 後は基本許さん方向で。
void* => int* の cast は 4byte アラインされてないと不定な動作!
jmp と call は x86-64 と同じでいいや。 ただ関数は 4byte 境界に。
リンカとローダはグローバルにある int* の解決とかはちょっといじらにゃいかん気がする。
デバッガはそれなりに。
要は 4GB のアドレス空間は足りないかもしれないけど 16GB あれば10年くらいは戦えそうじゃないかという。
うわごともいいところだなあ。
(03:41)
#include <stdio.h> int main() { // ここでとある方法で e を定義すると FPE が出る printf("%d\n", e - e); }
というような e があるんだなぁとふと見つけた
(03:46)
http://d.hatena.ne.jp/ku-ma-me/20100112/p1
s=*$< x=y=0 y+=1until x=/S/=~s[y] q=[[a=s,x,y]] (a,x,y=q.shift a=a.map &:dup a[y][x]=?$ 4.times{|k|s[j=-(k^1)/2+1+y][i=-k/2+1+x]!=?*&&(s[j][i]=?*;q<<[a,i,j])} )while/G/=~a*'' puts a
あんまマジメにやってないんだけど 適当に解いてて一応勝ってる (181B) ぽいので。
はじっこに壁があるのを仮定してるのはちょっとずるかったりするんかな。 あと S の位置が 1,1 というのを仮定してよかったらだいぶラクなんだけどなあ。 なんかそれを仮定してそうなコードをどっかで見た気がしたんだ
(00:43)
http://john.freml.in/codegolf-cheating
できそうと教えてもらったけど、 まぁ誰もやらんだろうと思ってたんだけど、やってくれた。
というわけで共有メモリとメッセージキューは殺したんだけど、 semaphore は mono が使うらしい。 アホかーと思ったんだけど、 まぁ数をギリギリの数にしておいた。
でもまぁ気持ち悪いし、 一個でも semaphore 作られたら C# のプログラムが動かなくなるので、 後で semaphore はクリアするようにしておこうと思う。 で、 Ruby は syscall 呼ばんと getsem とか無いかなぁ…とかいう。
(00:48)
s=*$< x=y=0 y+=1until x=/S/=~s[y] q=[a=s,x,y] (a,i,j,*q=q a=a.map &:dup a[j][i]=9*4.times{|k|q+=[a,x,y]if s[y=-~k%3-1+j][x=-k/2+1+i]!=s[y][x]=?*})while/G/=~a*'' puts a
まだまだ縮みそうではある
(01:04)
s=*$< x=y=0 y+=1until x=/S/=~s[y] q=[a=s,x,y] (a,i,j,*q=q a=*a*'' a[j][i]=9*4.times{|k|q+=[a,x,y]if s[y=-~k%3-1+j][x=-k/2+1+i]!=s[y][x]=?*})while/G/=~a*'' puts a
よく考えるとどうせ 1.9 じゃ動かんしなぁ
(01:08)
q=a=gets(p),~/S/ (a,i,*q=q a*=1 a[i]=9*4.times{|x|q+=[a,x]if$_[x=-~x%3*-~~/$/-~/$/+-x/2+i]!=$_[x]=?*})while/G/=~a puts a
golf data structure is always linear は金言だなぁ…
しかしなんかむしろコードが間違ってたらはずかしいな
(01:32)
q=gets(p)*1,~/S/ (a,i,*q=q a[i]<?S&&a[i]=?$ 4.times{|x|q+=[a*1,x]if$_[x=-~x%3*-~~/$/-~/$/+-x/2+i]!=$_[x]=?*})while/G/ puts a
どうしても S を塗らない処理が大変だなぁ。 G を塗らないのはむしろ短くなった気がするんだけど…
(02:31)
http://webkit.org/blog/1012/shinichiro-hamaji-is-now-a-webkit-reviewer/
ぶじなれたみたいだ。
(04:11)
_ naruse [おめでとうございます]
使おうと思ったら色々問題があった。 ありすぎてわけがわからん。 最初の問題は su できないとか adb shell できないとか。
しょうがないから色んなイメージを入れてみたりとかそんなこんな しているうちに突然再起動したりする問題と、 android.prcess.media has stopped unexpectedly とやたら言われる問題が起きた。 あとおうちの SSID を見つけてくれない。
adb の方は別につなげられるよーと言われたので、 色々やってみたところ
http://groups.google.co.jp/group/android-group-japan/msg/8bf1b8894ca31148
を見つけて udev のエントリーを2つにしたら動くようになった。 なんでやねん。
android.process.media の方はネットの情報によると SD card をフォーマットすればなおるらしいということだったのだけど、 format するために unmount したら即再起動するという悲惨な状態だった。
こっちは isshiki さんに SD card をフォーマットしてもらって解決。
しかし今度は USB cable を刺すと再起動するという…
なにがなんだかわからない
(19:29)
version down (1.1) => BIOS の update => version up (1.6) とかしたら 再起動しかしない状態になった。 しょうがないので user data も含めて factory reset かましたらなんとよくなった。
おうちの SSID 拾ってくれないのはホントなんでかなーと思いつつ SSID 一文字とかが駄目なのかなーと思ったけど違って、 いろいろぐぐってたらどうも、
にある通りで、 channel が 12 になってたのが良くなかったようなので 11 にした。
あとはいつも入れてるアプリを入れてみたり。
AndroidSKK も入れてみた。 よく動いてて良い。 ただ Enter 入れると日本語入力になるので、 Google に英単語入れて Enter で submit したりすると 日本語モードになるのがちょっとびっくりするけど、 まぁ実用上は問題ないかも。 いや submit せずに日本語モードにできないのはちょっと困るかも。 まぁしばらく試してみようとおもう
http://d.hatena.ne.jp/minghai/20090502/p1
コード読んだ。 なんか soft keyboard なら / 長押しでいいみたいだな。 あとなんていうか上下左右入れるヤツで 上入れたら例外飛んだぽいので、それも含めて適当にいじってみるかな。
(01:19)
080-4366-8161
らしいんで適当にどうぞお願いします。 メアドは未だによくわからんのだけど、 まぁ gmail でいいんじゃないかな。
いずれにせよ phs ___at___ shinh.skr.jp を gmail に転送しとくようにしておいたし、 まぁ i.softbank.ne.jp とかゲットしたら適当にそっちにも転送すると思われるので、 それでいい気がする
(01:39)
ついにこれのパスワードの調べかたがわかった。 契約したときにもらった紙に書いてあったのだった。 というわけで設定したので phs ___at___ の forward 先に追加したので まぁなんとでもなると思われた
(02:02)
http://mkosaki.blog46.fc2.com/blog-entry-1069.html
これはそのなんというかひどいなとしか言えないなぁ… なんでそこでインターフェース切ったのって感じだろうか。
まぁいつも言ってるんだけど x86-64 持ってる人は以下を実行してみるべき。
int main() { printf("%d %f\n", 1.2, 42); }
(22:47)
http://google-opensource.blogspot.com/2010/01/love-for-luajit.html
知らんかった
(05:59)
http://blog.kmckk.com/archives/cat_107264.html
面白い。 TCG は興味あったのに調べてなかったんだけど、 なんか結構 QEMU 以外で使うのにはイマイチな感じなのかな。
(06:02)
_ calgary search engine optimization [そのような意味&#..]
ちょっと前に婚活サイトにまじめに登録した人の話を聞いて面白かった。
とかだそうだ。
なんか思ってたよりまともというか サバサバしてるというか合理的というかなんだなぁと思った。
(01:56)
今頃になって PRA に second author 的な感じで載るらしい。 一般的にはいいことなんだろうけど、 しょうみのところ何を思えばいいかわからん程度に何も思えないなぁ面白い
(23:17)
パソコンが遅い == メモリが遅いについて、 どんなのがあったっけなあと適当に思いだしてみる。
頻繁に起きていた。今は IRC クライアントとは違うマシン使ってるというか Ruby で書かれた rail から Perl で書かれた tiarra に移行したら大丈夫になった。 Ruby ってより rail が悪い可能性が強い気がしてるけど調べてないのでよくわからない。
これはたぶん二つ問題があって、片方の disk 全力で書いてる最中に完全に動作が止まる、って方は fsync がどうこうなので本質的にあまり関係ないと思う。まぁしかしそれでなくてもメモリ喰いまくって遅かった。クライアント側でメモリ
対策としては色々やったけど Linux Chrome 出てなかった時期は Windows Chrome 立ち上げて rdesktop でアクセスとかやってたくらい辛かった。
これは Windows が悪いってより僕の使ってるマシンで一番非力なマシンが Windows な上に coLinux まで動いてるというハンデがあるので Windows を責めるのはかわいそう。いずれにせよキャッシュに行ってる気配しかしないのでまぁメモリさんが足りないのが悪い。
適当にでっかいデータを処理してる時に、たまたま一個だけ入ってるでっかいレコードを全部メモリに読もうとして死亡→一からやりなおし、ってパターンは悲しい。
例えば ICFP の時の僕の UM とか適度にリークしてたのでひどかった。
あとまぁなんかしら適当にでかいデータ処理するとデータ2倍にしたら終わるまでの速度が20倍とかよくあるよねー的な。
(23:18)
http://slashdot.jp/it/article.pl?sid=10/01/28/0536223
なんか実際に客がいるサービスをやっていないので、 大学でクラスタ〜とかの研究するの大変という話を聞いた後だったので、 こういうの引き受けたりしたらいいのになぁとかちょっと思った。
単に ircd 動かすだけならどうでもいいと思うけど、 認証つきの全文ログの提供&ログ検索などなどやれば結構大変そうな気がする
(23:21)
もう何茶だったか忘れたアレ。
http://d.hatena.ne.jp/shinichiro_h/20060831#1156993501
侘び茶だった。 あれ的な感じで web からも Ajax でアクセスできますよ〜とか XMPP も喋りますよ〜とかそういうのやって欲しい。 まぁ結局俺がやって欲しいだけにすぎないが
というか stateless なプロトコルはともかく、 コネクションはりっぱなしになるようなプロトコルと データセンターのやりとりとかよくわかってないんだよなぁ。 たぶん難しそうだと思うんだけど。 研究とか的にはどうなんかな。
(23:25)
ひさびさに…
(23:52)
_ naruse [せっかくWebSocketsやってる鵜飼さんが近くにいるのに、と思いました。 いや、物理的に近くなのか?でも先日お会..]
前 | 2010年 1月 |
次 | ||||
日 | 月 | 火 | 水 | 木 | 金 | 土 |
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 |
全てリンクフリーです。 コード片は自由に使用していただいて構いません。 その他のものはGPL扱いであればあらゆる使用に関して文句は言いません。 なにかあれば下記メールアドレスへ。
_ reputation management online [そのような意味&#..]