観察日記 2010-03-18
Redmine for Ruby のメンテナ
redmineのメンテ権限はもう手放すぞー!
時間が出来たときまでに誰かが拾わなかったらまた拾うけど。
ruby用redmineの保守は誰かやる気がある人がいたら、もうパッチ無しには口は出さないのでshugoさんと相談して好きにしてくれ、の意。
そういうのこそ跡継ぎを大々的に募集したほうがよいような
そうかも。
redmineの管理人のことか。
redmineにパッチを当てるのかと思った。
ML連携をunportableに実装してしまったからそれが問題なんだよね。
redmine を引き継ぎたい人はいないだろうなあ
yugui さんは偉大
私もリリース管理してほしかったから導入しただけで、redmine弄りたかったわけではないからなぁ。
今ではそれなりに愛着もあるけど
だってバグの管理を卜部さんがほそぼそとやっていたんだから*1、あの状況からは大分いい。
バグトラッカが定着したんだからすばらしい
まー、mameさんのおかげでようやく決心も付いたので、こんな感じでやってきましょう。mameさんに怒られないように粛々と進めたいと思います
ここまで Redmine が定着したのは素晴らしいことだと思います。で、ちょっと弄りたいところがあるので、わたしは微妙に手を上げる予定なんですが、0.9 のマージみたいなでかいところはやりたくないので、どなたかやってくれませんか。http://redmine.ruby-lang.org/projects/show/redmine が Ruby 開発用カスタムプロジェクトの URL です。
signbit
最近のコミットで使われるようになった signbit(3) は C99 の関数で、一部の環境にはないという話。missing/signbit.c を用意することになった。ここでは一度共用体に代入し、取り出している。
tmpdir
r26952 で tmpdir が mswin32 で ext/dl に依存しなくなった。
NaN の作り方と Mac OS X
NaNを作る関数ってなんだっけ
nan()?
そんな関数あったっけ
C99 の関数だった
あるんだ！
man nan したらコンニャク畑を思い出した
さすがに引数とったりはしませんか
{ko1_ndk} (サポートされている場合) マクロ NAN は quiet NaN を表す float 型の定数に展開される。 quiet NaN は計算式の中で使われたときに例外を起こさない NaN ("not-a-number") である。この反対は signalling NaN である。 IEC 60559:1989 を参照すること。
マクロもあるんだなあ
{ko1_ndk} double nan(const char *tagp);
取るじゃん
すげー
Lua はこれを使ってるんだろうか
strtod って "NaN" って受け取るんだ
NANか
凄いなあ
引数は実装依存っぽい
うい
http://www.opengroup.org/onlinepubs/9699919799/functions/strtod.html
OSXのだと0..255までの整数に変換される文字列と明記されている
OSXのというかBSD
Mac OS Xのマニュアルは時々嘘つくんだよな、と疑ってかかる
というかrubyレベルではNaN codeというものを取り出す方法がない
packするしかない
{n0kada} $ ./ruby -e 'p [Float.nan(10),Float.nan(20)].pack("e*")'
{n0kada} "\x00\x00\xC0\x7F\x00\x00\xC0\x7F"
変わりゃしねー
http://www.atdot.net/sp/readonly/okqczk
ちゃんとできてるっぽいが
floatにしてるからか?
{n0kada} $ ./ruby -e 'p [Float.nan(10),Float.nan(20)].pack("G*")'
{n0kada} "\x7F\xF8\x00\x00\x00\x00\x00\n\x7F\xF8\x00\x00\x00\x00\x00\x14"
できてた
{n0kada} $ ./ruby -e 'p [Float.nan(1000)].pack("E").unpack("V")'
{n0kada} [1000]
やっぱり嘘ついてた
clipped to the range 0 to 255, inclusive はしてない
たぶん、float/double/long double でマニュアルの記述を分岐しないといけないのに、サボってる
っと思ったけど、floatでも22bit使えるはずだな
double->floatの変換で捨てられてるような
変換で捨てられるのはしょうがない気もする
nan()でclippingはしてないけど範囲外まで保存される保証もないと思えばいいのかな
Macの挙動に保証もへったくれもない気がする
Appleクォリティだからな
URI.decode_www_form と Encoding.default_internal
こういうときは Encoding.default_internal じゃないのかなあ > URI.decode_www_component
普通はEncoding.default_internalはnilである
もしセットされているとしたらたいていはUTF-8である
そもそも、これって外部フォーマットだから、あんまinternalは関係ないな
変に他の値に影響されるより固定の方が便利なのかなあ。
encoding与えられるし
ていうかえーと
http://www.w3.org/TR/html5/forms.html#url-encoded-form-data
を眺めながらとして、
{hermit_} 4.10 Forms ― HTML 5 [text/html; charset=utf-8]
送られてくるデータの符号化方式の決定権は必ずしもサーバサイドにはない
が、そのformのaccept-charsetだとか、document's character encodingだとか、両方微妙だったらUTF-8とか、サーバサイドで予測可能な部分は大きい
サーバサイドで予測可能な部分ってのは、実際にはコードを書いている人であって、Webアプリ自身が予測可能なわけではなく、それとdefault_internalの関連性は必ずしも高くない(ケータイなど
と、すれば中途半端なことはするべきではなく、8割はUTF-8なんだからデフォルトそれにした上で、明示的に指定できればいいよねというお話に
Encoding.default_internal はあくまで UCS 正規化戦略をとった場合の、しかも内部コードなのです。
