[#46329] [ruby-trunk - Feature #7252][Assigned] version number of 2.0 release — "usa (Usaku NAKAMURA)" <usa@...>

26 messages 2012/11/01

[#46350] RubySpecメンテナ — Yukihiro Matsumoto <matz@...>

まつもと ゆきひろです

15 messages 2012/11/02

[#46414] [ruby-trunk - Bug #7287][Open] please rename atomic.h which conflicts with /usr/include/atomic.h in Solaris10 — "ngoto (Naohisa Goto)" <ngotogenome@...>

10 messages 2012/11/06

[#46434] トラップハンドラで許されない操作はなにか — KOSAKI Motohiro <kosaki.motohiro@...>

小崎です

9 messages 2012/11/06

[#46440] [ruby-trunk - Bug #7300][Open] Hash#[] の挙動が 1.9.3 と異なっている — "hsbt (Hiroshi SHIBATA)" <shibata.hiroshi@...>

12 messages 2012/11/07

[#46477] Fwd: [ruby-changes:25559] shugo:r37616 (trunk): * vm_core.h (rb_call_info_t::refinements), compile.c (new_callinfo): — SASADA Koichi <ko1@...>

refinement を導入するときの性能に対する excuse が「method cache に殆どあ

20 messages 2012/11/11
[#46480] Re: Fwd: [ruby-changes:25559] shugo:r37616 (trunk): * vm_core.h (rb_call_info_t::refinements), compile.c (new_callinfo): — Shugo Maeda <shugo@...> 2012/11/11

前田です。

[#46488] Re: Fwd: [ruby-changes:25559] shugo:r37616 (trunk): * vm_core.h (rb_call_info_t::refinements), compile.c (new_callinfo): — SASADA Koichi <ko1@...> 2012/11/12

 ささだです.

[#46491] Re: Fwd: [ruby-changes:25559] shugo:r37616 (trunk): * vm_core.h (rb_call_info_t::refinements), compile.c (new_callinfo): — Shugo Maeda <shugo@...> 2012/11/12

前田です。

[#46493] Re: Fwd: [ruby-changes:25559] shugo:r37616 (trunk): * vm_core.h (rb_call_info_t::refinements), compile.c (new_callinfo): — SASADA Koichi <ko1@...> 2012/11/12

 ささだです.

[#46495] Re: Fwd: [ruby-changes:25559] shugo:r37616 (trunk): * vm_core.h (rb_call_info_t::refinements), compile.c (new_callinfo): — Shugo Maeda <shugo@...> 2012/11/12

前田です。

[#46497] Re: Fwd: [ruby-changes:25559] shugo:r37616 (trunk): * vm_core.h (rb_call_info_t::refinements), compile.c (new_callinfo): — SASADA Koichi <ko1@...> 2012/11/12

(2012/11/12 18:20), Shugo Maeda wrote:

[#46501] Re: Fwd: [ruby-changes:25559] shugo:r37616 (trunk): * vm_core.h (rb_call_info_t::refinements), compile.c (new_callinfo): — Shugo Maeda <shugo@...> 2012/11/12

前田です。

[#46513] Re: Fwd: [ruby-changes:25559] shugo:r37616 (trunk): * vm_core.h (rb_call_info_t::refinements), compile.c (new_callinfo): — Nobuyoshi Nakada <nobu@...> 2012/11/14

なかだです。

[#46509] [ruby-trunk - Bug #7344][Open] gem pristine bigdecimal が失敗してしまう — "hsbt (Hiroshi SHIBATA)" <shibata.hiroshi@...>

31 messages 2012/11/13

[#46520] [ruby-trunk - Bug #7356][Open] ruby-2.0.0-preview1 で adlint-2.6.10 が性能劣化 — "yanoh (Yutaka Yanoh)" <yutaka@...>

11 messages 2012/11/15

[#46647] [ruby-trunk - Bug #7452][Assigned] Main thread is stopped after running finalizers if the main thread has a finalizer — "mrkn (Kenta Murata)" <muraken@...>

8 messages 2012/11/28

[ruby-dev:46396] Re: [ruby-trunk - Bug #2154][Assigned] filesystem encoding of UNIX

From: "U.Nakamura" <usa@...>
Date: 2012-11-05 06:13:12 UTC
List: ruby-dev #46396
こんにちは、なかむら(う)です。

In message "[ruby-dev:46375] Re: [ruby-trunk - Bug #2154][Assigned] filesystem encoding of UNIX"
    on Nov.03,2012 04:56:59, <kosaki.motohiro@gmail.com> wrote:
> 1)
> ロケールは UTF-8
> ファイルシステムはFAT(よってファイルシステムのファイル名はShiftJIS or another country specific codepage)
> ファイルの中身は EUC
> 
> ※これはSDカードなどで実際に発生しうる

これ、私も気になってるんですが、苦情を見かけないのが不思議で
す。
みなさんどうしてるんでしょう?

ただ、よくわかんないんですが、最近はSDカードとかFATつっても
FAT32じゃないんすかね。
であればUnicodeなファイルエントリもあるはずなのでファイルシス
テムドライバが真面目に作ってあればUTF-8でファイル名アクセスが
できて問題ないようにも思います。
この辺はそういうシステムを使ってる人に聞きたいところ。


> 2)  ロケールはUTF-8だけどファイルシステムエンコーディングはUTF8MACな某OS
> 
> というパターンだと思うので、これをケアする必要があるならAPIが必要そうに思えます。要望を上がってこない所をみるとあんまり困ってないのかな

困ってる話は卜部さんも紹介されたようにけっこうな頻度で見かけ
るように思います。
ここは成瀬さんが深く考えていたはずなので説明お願いします。


> まとまってないので思いついたことを箇条書きで書くと
> 
> ・Linuxではlocale(UTF-8)、MacではUTF8MAC、WindowsではUTF-16(だっけ?)がデフォルトのファイルシステムエンコーディングであって欲しい

Windowsではいわゆる「W」は内部的にUTF-8に変換して扱うことにし
たので、next majorあたりでファイルシステムエンコーディングは
UTF-8にします。
# スクリプトはUTF-16を返されてもASCII compatibleじゃないので
# 制限がきつくて使えないし、ruby内部でもASCII compatibleじゃ
# ない文字列をパス名として扱えるようにはほとんどなってない。


> ・SDカード対策のために違うエンコーディングを指定できて欲しい。これはdefault_externalをかえるよりかは引数で与えれたほうが便利そうな気がする。
> default_externalを変えちゃうと別のスレッドがぎゃっといいそうだから
> ・default_filesystem_encondingみたいなのがあれば、昔のLinuxのイメージに残っているEUC-JPなデータをサルベージするときに便利そうである

これは先に書いたとおり私も同意します。


> ・2.0ではデフォルトはlocaleにしておいたほうが、あとから自然に拡張できるような気がする

default_externalじゃなくて、ということでしょうか?


実はbackportの都合で今時点の1.9.3 HEADも現状のtrunkの実装を引
き継いでいるので、個人的には、まずさっさと2.0.0でどうするか、
を決めてしまいたい気分です。1.9.3はそれに合わせるので。


ところで、しろさきさんってこっち見てます?
見てたらいろいろ教えて欲しいところ。


それでは。
-- 
U.Nakamura <usa@garbagecollect.jp>


In This Thread