観察日記 2010-06-29 - なるせにっき

結構ログに差をつけられているので追いつくのに時間がかかりそう。

CHANGE MAKER

まつもとさんが CHANGE MAKER とかいうやつに選ばれたらしい。
「Changemaker チェンジメーカー決定｜CHANGEMAKERS OF THE YEAR 2010 新しいビジネスリーダーを求めて｜WEB DIGNIO」

make change

http://www.atdot.net/sp/readonly/fsnw2l
split(/\n/).eachはeach_lineでいいんじゃない？
1.8の古いのにはないから
これから入れるんなら古いのは関係ないでしょ
make changeすらできないし
BASERUBYが最新とは限らないし
え、失敗する?
BASERUBYは同じバージョンを使うんじゃなかったっけ？
それはクロスか
BASERUBYは(クロス以外は)1.8
で、make changeって何?
さきのsp
ああ、まだないのか。
spってタイトルも入れられるといいな
make helpして「ないよな? よな? とか思ってしまった」
make up help
1行目をtitleにする機能があったような気がしたんだが
気のせいだっけか
気のせい
そういう要望はいったことがある
あ
Windowsでmake installできない問題って直ってないんじゃね
手元のcommon.mkに差分があることをchange makerが教えてくれた
はつみみで(ry
さすがchange maker

change.logに吐くよりstdoutに吐くほうがよかったんじゃねとかいうことはない?
リダイレクトせずに?
うん
change.logだとchangelog-modeになるようなのでそうしてみたんだけど
そういう理由があるのか
いや理由があるならまあ仕方ない。
なんか不都合が?
いや、特に不都合というほどのことがあるわけではない。
stdoutにも吐けばいいんじゃない？
リダイレクト結果をエディタに読み込むコマンドを持ってるので、
いちいちchange.logを開くよりそっちの方が俺の手元では早いというそれだけの話
つっても大した差じゃないから、ま、どうでもいい。
nmakeだと一緒にゴミが入らん?
別にゴミが入ってもどうせ部分コピペだから害はないような
make changeを作ってみたかっただけでchange.logにしたのはついでだから
どっちでも構わない
ま、説明を聞いたから、わざわざ変えなくていいっすよ。
changeとlogに分けるとか

tal さん

そういえば tal さんのコミッタの話はどうなったのかな
どうもなってないかも。
特にここのメンテナとしますというの無いしなぁ。。しいて言えばwindows全般ですが。
む
tal__ = unak2
でしたか
うさんの2番目に位置づけられるとは恐れ多い。
windows全般の面倒をみますよ、って ruby だと案外いないような。
今は、うちでコンパイルしたmsvcrt.dll版でtest-allしてると何かの拍子でgetenvでsegvしたりするのだけれど、何が原因かわからん。。。
（とりあえず環境が悪い気がする。 VC6じゃなくて eVC+PSDK+DDKだからなぁ
http://pc12.2ch.net/test/read.cgi/tech/1155031689/709-710 見て構築してみました。
{util_mput} 【ActiveScript】RubyをWindowsで使うスレ【GUI】 http://tinyurl.com/24nu6y6
VCでビルドしてくれるひとが居るだけでも嬉しい。
unak32
64と32?
tal__ == unak64
しかしVC++2008(ランタイムがmsvcr90)でビルドしてBug投げてるけど、世間はmsvcrtばかりでmsvcr90でビルドしてるのは私だけで需要はさっぱり無いのではないかと心配に。
8bitとか6bitとか4bitとかで。。（それでコンパイルしろとか言われても困りますが＾＾
つまり tal__さんは unak さんの 64版
明らかに順序がおかしいです。
分かりやすい
tal2008
まだ公開鍵送ってないの?
コミッタしますか？と言われてないので。
するひまない?
多分ある
bugを潰すだけならredmineに登録しとけばそのうち誰かがコミットしてくれるので、実務上はコミッタ権いらないのだよな。。。
コミッタ権ってなんだｗコミット権
コミッタになる権利。
rubyの裏世界で売買されている
という噂
ただ、コミット権あげるのでもっと貢献してといってもらえるのは大変な名誉だと思うので、そうならありがたく頂きたいけど。
ｗ
「なるなら早くしろ。でなければ(ry」

WindowsでのUnicodeパスがうんたらかんたら

WindowsでのUnicodeパスがうんたらかんたらは、もう本質的には対応終わった。
プロセス起動部以外は、後は個別メソッドの仕様決めの話なので私にはお答えできません的な
で、Dir.pwdで戻りエンコーディングを指定したいときはどうすりゃいいでしょうね
というネタがとりあえずcoreに転がってるよ
そういえば聞いた記憶がある
Windowsもdefault_external見るようにするかー
default_internalが筋なんじゃね、と答えてしまった俺の立つ瀬がないという。
いやまあ、なくてもいいんだけど。
filesystemは?
internalが設定されている場合には最終的にはinternalになる
互換性問題がなければfilesystem encodingをUTF-8にして終わりなんだけどな。
うむ
filesystemはlocaleかUTF-8になるのが正解なんかのぅ
とりあえず、1.8のスクリプトがそのまま動くことを想定してて、
すると素ではやはり取ってきたパスがsjisでないと困る
うむ
しかし、default_internal=UTF-8のときはUTF-8でいい気がする
それはたぶん間違いない。
中間をどうするかだな
default_externalで変わるのはどうなんだろうなあ。
-Ksの場合はオッケーなわけだけど
Unixの動きを演繹すれば変わることになるが
-Kuでどう動いて欲しいかね
ACPとOEMCPが違う環境が哀れ、という話もある。
UTF-8で来てほしいかな
それはもうどうしようもないな
何がどうしようもないって、何が起きてるのか良く解らんから手のうちようがない
-Kuの時でも、従来はsjisで来てたわけで、既存スクリプトでは内部でsjis->utf変換してるコードが埋めてあるんじゃないかなあ。
というわけで、default_externalによってバイト表現自体が変わるのはやはりまずいんじゃないか説
それ変換するのはなんか元から邪悪な気もするが
いや、しかし、1.8ではそうとしか書けないじゃん。
SJISのまま処理するのが正解
... でも、取ってきたパス名を変換する必要は普通ないか。
かぶた
じゃあやっぱりないか?
いやlsを書いてる人かもしれないし!(そういう人は-Kuにしません)
こうしてみると意外といけそう?
いやACPとOEMCPの違いの考察が抜けてる
意外と行ける気もするんだよな
よくわからない世界からとりあえずUTF-8に移る分すっきりする、とかいう強引な主張
さて、手元にはWindows上で実行してる、-KeでDir#eachを活用してるスクリプトがあるのだが...
しねばいいよ
地雷除けスキルを装備してる俺はそもそも多バイト文字をファイル名に使うという発想がないので問題ないのであった。
そもそも、ファイル名に日本語を使うのが行けない・・・ってかぶった
ユースケースにならねえ
Windows-31Jなパス名を収集してその中にあるEUC-JPなテキストを読み込んで加工した上でUTF-8で出力する
というスクリプト。
いやマジで。
どうしてこうなった
めんどくさいことしてますね
レガシーが積み重なってる
最初のバージョンが1995年(ただしPerlで書いてあった)
歴史的スクリプト
つか15年もデータ溜めてるのか。ひでえな。
IT関連に携わってると、歴史的→とっとと捨てちまえ、という感覚が植え付けられるので
歴史的建造物とか歴史的町並みとかもさっさと壊しちまえと思うようになって良くない
歴史大好き
歴史的ゴミ