トップ «前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|

ToDo:


2008-12-10

_ nativeclient

ちょっとだけ遊ぶ。 フツーに SDL が動くのかなぁと思ってたけど違う、のかな。 ぱっと見たかんじ、

  • ブラウザ内 => nacl => NS なんちゃら
  • standalone => nacl => SDL

みたいな感じになってる気がする。 SDL の nacl 用 video driver とかそいうのが無いと、かな。

http://d.hatena.ne.jp/ABA/20081209#p2

の SDL 移植に全く同意なのだけど。

あと ActiveX とかはまぁサンドボックスがほげほげーとかいう違いが

(10:48)

_ あんごう

http://igarashikuniaki.net/tdiary/20081209.html#p01

わかりやすいなあ。 や正直なところもともとわかってたまるか系の話だから わからない人はいそうだけど、 まぁ他の説明よりはわかりやすい気がする。

いやでも干渉うんぬんとかは… うーんでもどう説明したらいいんだろうなぁ。

まぁなんにせよ量子暗号はサンプルとしてはすごくいい気がする。 Shor とかは絶対無理感がただよっている。 Grover はどうかな…微妙か…

(11:15)

  • CASEC
受験日 Sec1(full:250)  Sec2(full:250)  Sec3(full:250)  Sec4(full:250) Total(full:1000) TOEIC(R)(スコア目安) TOEFL(R) (※)(スコア目安)英検級(目安)
2007/11/28 20:12:17 160 176 185 174 695 705 502 2級
2008/06/04 01:55:29 203 174 211 137 725 810 513 2級
2008/12/10 22:16:09 186 194 200 185 765 790 529 2級

普通に良くなってるのかなぁうさんくさい。TOEIC換算だけ減ってるが謎。


2008-12-09

_ relocation できない問題

普段は。

  • malloc した領域 == 自分のコード領域 => 32bit 領域
  • libc => 64bit 領域
  • libc への relocation (32=>64) は届かない
  • でも malloc しといた jmp table からなら届くよ

という感じ。

tcc.c だと、

  • コード領域がデカくなりすぎて 64bit な領域に追い出されている
  • libc への relocation は届く
  • でも追い出されてないシンボル (たぶんデータだけ?) は届かないよ

つーかデータ領域の PLT ってどうなってるの (?-?)

手軽(?)に解決するなら一旦ファイルに書くつもりで メモリに書く、ってアプローチだろうなぁ。 コンパクションしても 2GB 越えてるとかいうコードは… まぁ TCC でコンパイルすることはないだろう。

(08:39)

_ 時砂

http://d.hatena.ne.jp/nagachika/20081130/king_of_timeglass

なんかネットで見るとおかしいとか書いてあって、 どこのことかなぁとか思ってたけど、 言われてみると「ここより前に〜」はアレっと思った気がする。

まぁなんかイーガンとかならともかく こういうチャンバラものというか とりあえず卑弥呼かわいいよみたいなものは 整合性的なものはわりとどうでもいいと感じてるようだ。

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

(08:53)


2008-12-08

_ TODO

  • GC
  • TCC いじり
  • va_list
  • grub いじり
  • n
  • ゴルフ場いじり
  • 通帳を作る
  • クレジットカード解約

つかシティは Amazon 解消とともに 古いのに自動スイッチなのね…

(22:15)


2008-12-06

_ 41!!!!!!!!!!!!!!!

@pascal

(02:44)


2008-12-05

_ suge-

http://d.hatena.ne.jp/w_o/20081204#p1

init を bash にするのはできないのかな。 最後 exec するとか

(07:26)

_ と思ったら

書いてあった!

(07:27)

_ ゴルフ会

なんか明日昼12:30から夜6:30からとかです。

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

codegolf.com に参加してた方は今からでもどうぞ。 夜の方はゴルフやったことあれば適当に6:30からの部にどうぞ。

メールいただけるとかコメントしていただくとかすれば適当に対処します

(20:58)

_ 結局

日曜あたりからしょぼしょぼ縮めて、

  • total triangles (63 => 62): かなりいい感じのコードになった気がするのにあまり減ってないから本気出せばもうちょい行ける気もするけど…
  • 99 bottles or beer (170 => 167): 見た瞬間縮んだ。
  • prime factors (78 => 77): 既に縮んでたけどサブミットしてなかった。

という感じだった。

(21:02)

_ もんだい

  • pascal: 39/42, 9285: ダメージはでかめ。でも思いつかん。
  • total: 59/62, 9516: もうちょい頑張れないのだろうか…
  • prime: 76/77, 9870: こんなもんだと思う。諦めうる。
  • range: 50/54, 9259: ダメージはでかめ。でも思いつかん。
  • switch: 56/59, 9491: 思いつかん。
  • beer: 165/167, 9880: 点数は十分だけど、なんか縮みそうじゃね…
  • cipher: 45/45, 10000: まぁ問題ないか

pascal, range, switch は時間のムダ感が強すぎるので、 total, beer の悔いを無くす方向で。特に total かなぁ。

(21:39)

_ あと

IRC の #mazop あたりに入ってれば当日繋ぐようにしとこうと思うので、 リモートで適当に多少の会話をすることはできるんじゃないかなーとか

(21:59)

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

_ kik [今から寝るので遅刻する可能性大です。]


2008-12-04

_ GC

http://d.hatena.ne.jp/authorNari/20081203/1228267905

ああ Boehm GC はそれやってるんだなぁ。 それで緩和はすると思うっていうか 件のスレッドにそれは書いてあったように思う。 でもたぶん真に問題なのはそこじゃなくて、 スタックの底〜SP の間に valid な VALUE が残っちゃったまんまでイヤーンという話だと思います。

TODO: あの話はかなり感動したのでこんどなんかかく

(00:55)

_ なんというか

SP が激しく上下しててたまに底付近まで 行ってくれたりするようなその対処で問題なくて、 でもデカい Ruby コードだったりすると戻って来んよねーとかいう話かなと

(00:57)

_ String#ord

http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-dev/37266

言ってみるもんだなぁと思た

(00:58)


2008-12-03

_ Enumerator#inspect

http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-dev/37248

の議論を IRC で見てて、最初にぱっと思ったのは

def make_pure_enumrator(e)
  def e.inspect
    "#<Enumerator::#{to_a.inspect}>"
  end
  e
end

class Array
  alias orig_each each
  def each
    make_pure_enumrator(orig_each)
  end
end

p [1,2,3].each

みたいな感じのを、 Array の中身を include 一発でできるんじゃないかなぁ、 と思ったのだけど、やっぱできないような気がして、 書いてみたらやっぱりできなかった。 できるのかもしれんが。 まぁ Ruby むつかしい気味ではある。

あとこれ Ruby 1.8 で動かんね。

(01:02)

_ GC

http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/20149

このスレッドが面白いなぁとか思ってたんだけど誰も反応してないから、 まぁ日頃から GC に慣れ親しんでる人には常識なのかなぁとか思ってたんだけど、 なんか matz さんが反応した。 月曜に色々聞いた感じでは GC フェチには常識的な感じではあるみたいだ

(02:29)

_ ウヒョー

ttp://shinh.skr.jp/t/tree.gif

http://d.hatena.ne.jp/miura1729/20081202/1228227760

を使ってみた。素敵だなあ。

ttp://shinh.skr.jp/t/081202_2358.jpg

まぁでもこっちの方が読みやすいよね!!

(02:47)


2008-12-02

_ 木ぽいののループ検出

http://d.hatena.ne.jp/miura1729/20081130/1228033970

via http://practical-scheme.net/wiliki/wiliki.cgi?Shiro

あまり問題は把握してないしグラフがうんぬんとかはよくわかってないけど、 このウサギ大量作戦だと

こんな感じで木?を作ると

(define (gen-line n c)
  (if (> n 0)
      (cons (gen-line (- n 1) c) c) c))

(print (gen-line 3 1))

(define (gen-tree-aux n m)
  (if (> n 0)
      (let ((c (gen-tree-aux (- n 1) m)))
        (cons (gen-line m c) c))
      (gen-line m 1)))

(define (gen-tree n) (gen-tree-aux n n))

(define (run n)
  (if (> n 0) (let ()
                (run (- n 1))
                (no-cycle? (gen-tree n))
                (print cnt)
                (set! cnt 0))))
(run 25)

N^2 のサイズの木?に対して指数ぽい挙動になるような。

なんか勘違いしてそうだけど…

(00:24)

_ String#[]

ホント改悪ですよね(ゴル略的な観点で)!

でまぁマジメに 1.8 に String#ord 入れて欲しいなぁ… てか String#getbyte とかあるのかそっちも入れて欲しい。

(02:05)

_ 文句言ってる間に

http://redmine.ruby-lang.org/issues/show/809

一念発起してアカウントを作った。

メール投げるよりこっちの方がいいのかな。 メールよりめんどいけど。 なんていうかこう残るものは close したくなる気がするし。 insns.def のコメントもこっちにコピペしたろか。

(22:50)

_ GCC ビルド

stage すっとばすオプションあったよなあ

../configure --prefix=/usr/local/stow/gcc-4.3.0 --disable-nls --enable-languages=c --disable-stage1-languages

とかでいいんだっけか。

たしか直近ではあろはさんとこで見た気がするので、 とか書いとけば教えてもらえるんだきっと…!

(23:38)

_ disable-bootstrap

か。

(23:41)

_ まとめると

configure --prefix=/usr/local/stow/gcc-4.3.0 --disable-nls --enable-languages=c --disable-bootstrap --disable-multilib --enable-checking=all

あたりで。

http://gcc.gnu.org/wiki/MiddleEndLispTranslator

に書いてあった。

(23:42)

_ ななしさん

http://pc11.2ch.net/test/read.cgi/tech/1173057314/229-

一応 _ に変換するようにしといた

(23:50)


2008-11-30

_ rand

まぁ rand は無いってのはそうだと思う。

http://blog.bugyo.tk/lyrical/2008/11/cdiv-1.html

#include <stdio.h>
#include <stdlib.h>
int main(int argc)
{
    int i, j, sum = 0;
    int x = rand()%3+3;
    int y = argc + 10;
    for (i=0; i<10000000; i++) {
    for (j=0; j<10; j++) {
#if 1
        div_t d;
        d = div(x, y);
        sum += d.quot;
        sum += d.rem;
#else
        sum += x / y;
        sum += x % y;
#endif
        x++; y++;
    }
    }
    printf("%d\n", sum);
    return 0;
}

とかでやってみた。

./a.out  0.83s user 0.00s system 97% cpu 0.845 total
./a.out  0.61s user 0.02s system 95% cpu 0.661 total

で div 使わない方の勝ちだった。 アセンブリ見た感じ div は関数呼んじゃってるなぁ 除算はきちんと一回になってるし。

まぁ除算きちんと最適化できるのに div なんてレアなものを builtin にする意味ないって感じかなぁ。

一応 gcc/builtins.c 見ても div ぽいのは無かった。

あとベンチマークの後は妥当ぽいか確認する手段として、 クロック数を概算してみるとかいいと思う。 1秒程度かかってるんならループ1回に数百クロックくらいかかってる感じで、 除算だけでそれはちょっと無いよなぁみたいなそういう。

(00:43)

_ メンバ250

くらいならいじったことあるなあ。 あれは苦痛に満ち満ちていた。

http://www.kt.rim.or.jp/%7ekbk/zakkicho/08/zakkicho0811c.html#D20081127-6

それはそうとまさに構造体のダンプのために こいうもの作った過去があるわけですが

http://d.hatena.ne.jp/shinichiro_h/20051230#1135939355

今も動くかは知らぬー

うむ 64bit linux では動かん。 今度なおすかなあ。

(05:48)


2008-11-29

_ function purity

GCC ML で目に入った

http://gcc.gnu.org/ml/gcc/2008-11/msg00357.html

こいうのはちょっと面白い話かなぁと思う。

(21:48)

_ ばぐ

だんだん潰すべきバグが難しくなってきた

単に引き続き体調悪いせいかもしれんが。

なんというか gdb 使えない領域のデバッグは割と大変だなぁとかそういう。

(22:09)


2024年
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.kosaki(2014-05-24 01:57) 2.shinh(2014-05-24 01:57) 3.kosaki(2014-05-24 01:57)
search / home / index

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

shinichiro.hamaji _at_ gmail.com / shinichiro.h