Rubyのバージョンについて
前提
Ruby 開発陣がブランチのメンテナンスに割けるリソースは限界がある。具体的には2本 (+trunk) が限界。
現状
1.9.3 と 2.0.0 がメンテナンスされている。年末に 2.1.0 が増える。
利用者のニーズ
- セキュリティ修正のみのブランチが欲しい (debian や heroku など)
- バグ修正のみのブランチが欲しい (普通の開発者)
- バグ修正と軽微な機能追加のみのブランチが欲しい (ちょっと進んだ開発者)
- そこそこ互換性を保ったブランチが欲しい (先進的な開発者)
- 互換性なんてどうでもいいぜﾋｬｯﾊｰ (Rubyコミッタ)
現在は、安定版ブランチが 2.、trunk が 5. である。
よくある要望
1. や 3. なブランチが欲しい
想定される返答
金を出すか自分でやってくれ（ただし、一度始めたら数年程度は継続して頂きたい）
はてぶへの返信
gfx: 2 (バグ修正のみのブランチ) をやめて 1（セキュリティ修正のみのブランチ）にするというのはありな気がする
https://www.ruby-lang.org/ja/news/2013/06/27/ruby-2-0-0-p247-is-released/ あたりを参照しつつ考えていただきたいのですが、経験上直らないと一部の人が生きるのがつらいレベルのバグはちらほらあるような記憶があるんですよねぇ。なので、1.+5.はいろいろとつらいんじゃないかなぁ。
アイディアレベルでは1.+3.+5.にしつつ、LTS導入みたいな話もあるんですが、このレベルの議論は皆様もにもお知恵を出していただいて、じっくり考えたいところですね。
Ruby開発者会議20130727
というわけで、Ruby 2.1 に向けて DevelopersMeeting20130727Japan をしたのです。
開発者会議で何をするかというと、RubyKaigi での見世物の通り、みんなが集まって色んなトピックに対してああでもないこうでもないと言い合うわけです。するとあら不思議、チケットで議論していた時はなかなか進まなかった話が、あっという間に reject されます。
また、三人寄れば文殊の知恵とはよく言ったもので、集まって議論していると保留間違いなしな雰囲気漂うラディカルな提案が、ブレイクスルー的な発想によって合意を得られることがたまにあります。今回で言えば分数リテラルがそうで、1/2r という表記の発想と虚数リテラルへのコンボは会議のハイライトでした。
次回は DevelopersMeeting20130831Japan なので、また大きな進展があるといいなぁ。
まとめ: Ruby 2.1 は電卓がはかどる
追記
ko1: 個人的にはキーワード引数の別名を蹴って binding.local_variable_get(:if) でいける、としたことがハイライト
議事録にも片鱗がありますが、コレに至るまでに色々な案が出ては却下されていき、収束していくスピード感がよかったですね。
観察日記 2013-02-20
2月も20日になるともう Ruby 2.0 出しちゃった気分なので、2.1 の妄想など考えるわけです…が、以下のログは実は1年半前のもの。
そういえばうささんいるからきくんですが、
殺気...
Time#to_sとかそのへんって、今はnon ASCIIこない?
こなくなったような
{unak} "2011-08-25 20:48:08 +0900"
こうなったから。
ただし、Time#zoneは
{unak} "東京 (標準時)"
でつ。
1.9.0の頃にWindowsだと(火)とか来るんでdefault_internalにしたつもり（だったがASCII-8BIT) だったが
なるほろ
%Zですよね
曜日はなんだっけ
曜日はstrftimeが自分で持ってる
wdayかな
4だった。
%A %a %B %bあたりで
strftimeだけかな曜日文字列は
で、曜日文字列は自力で持ってるから問題ないと思われる
Time#wednesday? とかいう下らないものがあった
東京（標準時）はなんとかならんのかな
なんともならんだろう。
つか、何になってほしいの?
ASCIIでかえしてほしいです
Japanese Standard Time (Tokyo)
あんまうれしくないな
これをアルファベットで取る方法は存在するのかなあ。
つかどうやって取得してるんだ。
tzname?
http://msdn.microsoft.com/ja-jp/library/bb384272.aspx ばってんばっかじゃねぇか
{hermit} ローカル システムで定義されているタイム ゾーンの検索 (text/html; charset=utf-8, 93092 bytes)
っとおもったらチェックかこれは
まぎらわしいやつらだ
tznameぽいなあ
システム内部に入りたくないな
WindowsはもうちょっとハイレベルなAPIを使いたい
ハイかローか微妙なところだが
てゆか.NETじゃなくて、と
GetTimeZoneInformation() をじっと眺める
http://msdn.microsoft.com/ja-jp/library/4ssfs1ya.aspx ふぅん?
{hermit} _get_tzname (text/html; charset=utf-8, 338597 bytes)
ふうん?
ほんとうに"PST"とか"PDT"が返ると思う?
おもわない
まあ、試すか
VC6とVC10でtzname周りは違うように聞こえるな
おお
PSTが返った。
すげーｗｗｗｗ>PSTが返った
ここ、日本なんですけど...
まあ、なんというか、まったく使い物にならなさそうですがｗ
{unak} 実行時に明示的に変更しない限り、この値の既定値は、それぞれ "PST" と "PDT" になります。
文字通りの意味過ぎてワラタ
どうしろっていうんだ。
単にtzname返してるだけだわ
意味ない
てゆか、C runtimeに頼るのは常に間違いである
というのが我々の知見である。
そういえばcygwinだと" "だな
まさかのMSVCRTフリー
やる気がまるでない
さすがのcygwinクォリティ
さて
Windowsはタイムゾーン名をどうやって持っているかというと
HKLM\Software\Microsoft\Windows NT\CurrentVersion\Time Zones
でした。
そこに例えば Tokyo Standard Time とかいうキーがあって、その中に表示名として「東京(標準時)」とか「東京(夏時間)」とかいうデータを持っている。
逆に言うと、英語名はレジストリ上のキー名としてしか存在しなくて、
ふむ、すくなくね?
しかも夏時間の英語名はそれすらない
ということになるね。
あぁ、これXPだから違うのかな
ほう、なんか違う?
どう伝えればいいんだろう
えくすぽーとか
paste> (略)
はった
とてもみづらい
あ、きーがあるのか
だいぶちがうかん
どうでもいいけど、exportするときはreg形式で
それが一番人間に見やすいという
なるほろ
paste> (略)
スクリーンショットが一番見やすいな
これがWin7
ご覧の通りさ
結構違いますね
XPまではキーじゃなかったってことだよね
ん、いやキーでもあるぞ
なんだとー
reg形式おながいします...
はりなおした
なるほど、キーはキーで似たようなもんがあるね。
スリジャヤワルダナプラコッテ に吹いた
いつもながらスリランカたんはｗ
Time Zones直下の値群の意味がさぱーりわかりませんな
いずれにせよ英語名を手に入れることは難しそう
というか、JSTとか欲しいだけなのになぜ持たない...
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation ふむ
ふむ?
そういえばtzsetの引数にはPDTとか取るんだよね
ふむ
その変換表はどこにあるんだ
さあ
JSTでレジストリ検索か
レジストリじゃないのかもしれないが
JSTで検索してもヒットしないぜ
しないね
どっかのDLLか
どっかの、というか、tzres.dllに決まってるけど。
と思ったのだが
tzres.dllは中身空っぽ...
謎は深まるばかりだ
英語で取れないとアレかな
Windows以外ではUS-ASCII, WindowsではEncoding.find("locale")かしら
きんもー
きんもー
mingwとかだとどうなんだろう
cygwinはtzcodeを入れてexport TZ=Asia/Tokyoしろってことらしい
一緒じゃないかな
msvcrtから取ってきてるなら同じ
まぁ、cygwinはそうなるのか
SetTimeZoneInformation()でタイムゾーン名としてPDTとか
とか指定できるムードはあるんだが
なにがどうなってるのかはさっぱりわからない
というかSetしたくないｗ
ローカル言語以外の文字列が欲しければtzres.dllのリソース番号ほにゃららをひけ
ていうか、そのセットする文字列を知りたいんだが・・・っていう
と書いてある気はするのだが
空だっつーの
逆か、ローカル言語で文字列が欲しければ以下略、なのか。
そして日本語Windowsの場合レジストリにいきなりローカル言語でぶちこんであるのでtzres.dllは空だという。
結論としてはギブアップ気味
ふーむ
タイムゾーンDB添付とかやめたいしなぁ
したくないっすねえ。
Windowsだけlocaleかねぇ
#to_sは常にUS-ASCIIでstrftimeはとかはできるが
+0900とか-0800でよくね? 気分ではある。
<- Windowsにおける%Z
http://blogs.msdn.com/b/bclteam/archive/2007/06/07/exploring-windows-time-zones-with-system-timezoneinfo-josh-free.aspx ふむ
{hermit} Exploring Windows Time Zones with System.TimeZoneInfo [Josh Free] - BCL Team Blog - Site Home - MSDN Blogs (text/html; charset=utf-8, 107682 bytes)
gettimezoneinformationをとって、そのバイナリの内容をTZIとし,
これでレジストリを検索して、キーの名前を取る、でいけそうだ
標準時は。
夏時間は?
で、http://unicode.org/repos/cldr-tmp/trunk/diff/supplemental/zone_tzid.htmlをひく
{hermit} Zone → Tzid (text/html, 51403 bytes)
むぎゅ
これを持つ?
つか、なぜunicode.org
TZIDが欲しいわけじゃないので、その先が問題ではないか
ここからolsonひいて、そっから夏時間の名前を取る
http://www.ailight.jp/Blog/sha256/archive/2011/1/30/%E3%82%BF%E3%82%A4%E3%83%A0%E3%82%BE%E3%83%BC%E3%83%B3
tzutilなんてものが
paste> (略)
こんなん出ました
レジストリキー列挙ぽいな
まぁ、問題は夏だな
また非公開APIを見つけてしまった。
IsTimeZoneRedirectionEnabled()
はてさて。
そういえば、現在の日本語Windowsの%ZはCP932?
UTF-8 or CP932という話
たぶんそう。
UTF-8ではないな。
%ZはTimezone IDだとすれば、夏時間だからと言って変える必要ないんじゃなかろうか
でも変わるでしょ?
{unak} Replaced by the timezone name or abbreviation, or by no bytes if no timezone information exists.
どこを参照している?
{unak} The Open Group Base Specifications Issue 7
{unak} IEEE Std 1003.1-2008
http://pubs.opengroup.org/onlinepubs/9699919799/
{hermit} The Open Group Base Specifications Issue 7 (text/html, 787 bytes)
で、strftimeの%Zのところを見た。
それはPOSIXじゃん
うん。
で、他の何を頼るの?
で、ここのtimezone nameはどういうものかというと、
%ZはTimezone IDだと言っている例は他に存在しなくて、
おそらく唯一規格化している例であるPOSIXはこう言ってますよ。
で、実際のPOSIXな実装たちでは夏時間とそれ以外では別の文字列返してますよ。
というのが僕の観測結果。
俺定義実装を別途用意してもあまり嬉しくないと思うので、既存の規格/実装は尊重するのがいいのではないでしょうか。
そのtimezone nameってhttp://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08 にあるstdと関係ないのかなぁ
{hermit} Environment Variables (text/html, 34729 bytes)
つまりalphanumeric characters from the portable character setじゃないかなーと思うんだけど
それはそうなんじゃないかしら。
もっとも
なので、どっちみちPOSIXからは外れているので、
どこを犠牲にするかという話ではある
現状が外れてるのはわかりきってるのでまあいいのですが
外れてるから同じく外れてそうななんか全然独自のをつくろう
というのはさすがに。
全然独自かなぁ
しかし、期待しているのと違うのはまぁ変わらんのだよな
うん。
他に事例がないものを独自と呼ぶ(キリッ
俺が事例だどどん
なんか筋が通ってたら独自でもいいんだけど
別に筋が通ってる気もしない。
Javaみたいに自前で頑張る
がんばりたくないでござる
まだ+0900の方がマシ感
それも独自じゃないすかに
独自だけどがんばらなくていいじゃん
まぁね
独自方向にがんばるのは気が乗らぬ。
いかにも「適当にごまかしましたので」という感じにしとくのは、ま、繋ぎとしてはいいんじゃね。
とりあえずstrftimevの戻り値はlocaleかなぁ
かなあ
なんか.NETあたりにいいのないかな
いずれにせよ、POSIXでも、aAbBprxXあたりはlocaleで変わるぜぐへへへ、とか書いてあるので、
気をつけたほうがいいのかもしれない。よくわからんが。
aAbBpはシステム使ってないので問題ない
しょぼん
{unak} * However this method is locale independent since Ruby 1.9.
rdocに明記してあってびびる
rxXもだな
正確には1.9.1からですね
まぁ、1.9.0は黒歴史だからいいけど
1.9.0とか存在しないから＾＾
やっぱなんとかせんとだめか。
というか、そう明記するなら、システム側のstrftimeへのフォールバック処理(%Zだけのような気がするけど)を殺す必要がある気がする。
なもんで、zoneだけなんすよ
%Zはstrftimeじゃなくてtzname
両方あるよ
Windowsの場合はtznameだと思うけど
あ、ほんとだ
tm_zoneがあればそれを使い、tm_zoneがなくてtznameがあればそれを使い、どっちもなけりゃstrftimeに聞く
というコードのはず。
で、tm_zoneは俺知らないんだけどtznameやstrftime("%Z")にlocale依存がないってのは幻想だよね。
"timezone name or abbreviation"が何者かという話で
std and dstのとこにあるやつだろJKと思うんですがどうなんでしょうね
っていうさっきの話に戻る
ふつーそれだろ、と思いつつも
あえて直接の関連性を提示しないで別解釈を許しているような気もします。
なんだよね
悩ましい
が、JSTとかPSTとかPDTとか出るのが万人にハッピーではあろう。
カスタムタイムゾーンとかだと手も足も出ないな
というわけで、_get_tzname()を呼んで
PSTと出るようにはなるという(ぉ
ひどい
あまりにひどいな。
実際にはtzset()を呼べば変わるので
環境変数TZを設定していればきっとJSTも出る＾＾
(よわよわ
わーい、でたー
うれしくねえなあ
てゆか、今のRubyでもTZ設定してればそれが出るから同じか。
TZ設定してないときに頑張ってみるんだけどその結果がアレでソレ
ということなんだよねえ。
故に、やはりシステムに頼らないで+0900を返しちゃうのが事故も起こらず安全なのではないか。