[#35400] Fwd: [ruby-cvs:38176] Ruby:r30994 (trunk): * string.c (rb_str_byteslice): the resulted encoding should keep — "Martin J. Dst" <duerst@...>
I'm really surprised that the encoding is kept for an arbitrary byteslice.
[#35403] Why are hash keys sometimes duped? — Aaron Patterson <aaron@...>
Why are some objects duped when they are used as hash keys and other
Aaron Patterson <aaron@tenderlovemaking.com> wrote:
[#35417] [Ruby 1.9 - Bug #4463][Open] [PATCH] release GVL for fcntl() for operations that may block — Eric Wong <normalperson@...>
> Issue #4463 has been reported by Eric Wong.
Hi
KOSAKI Motohiro <kosaki.motohiro@gmail.com> wrote:
Hi
[#35426] [Ruby 1.8 - Bug #4467][Open] Process.maxgroups= should only accept numeric values — Daniel Berger <djberg96@...>
[#35440] [Ruby 1.9 - Feature #1047] request: getters, setters for the GC — Narihiro Nakamura <authorNari@...>
[#35446] [Ruby 1.9 - Bug #4477][Open] Kernel:exec and backtick (`) don't work for certain system commands — Joachim Wuttke <j.wuttke@...>
[#35462] Source for 1.8 syck gram.y and token.re? — Kurt Stephens <ks@...>
I found bug in 1.8 ext/syck. The problem is in gram.c and/or token.c.
This is obviously dead and gone: http://whytheluckystiff.net/syck/
Syck is dead. 1.9 should make Psych/libyaml default. The fact that
I know syck is dead.
Maybe it's possible to bribe Aaron into releasing a Psych gem for 1.8?
[#35483] /proc/$PID/environ in Linux — Eric Wong <normalperson@...>
I wanted to inspect the environment of a long-running process[1] and I
[#35494] Re: can someone explain this? — Michael Edgar <adgar@...>
[+ruby-core]
[#35509] Why has defined? been changed for autoloaded constants in 1.9? — Nikolai Weibull <now@...>
Hi!
[#35513] String#upcase and UTF-8/Unicode not working — Nikolai Weibull <now@...>
Why does the following print =E2=80=9D=C3=A4BC=E2=80=9D instead of =E2=80=
[#35519] NoMethodError#message may take very long to execute — Adiel Mittmann <adiel@...>
Hello,
[#35528] [Ruby 1.9 - Feature #4512][Open] [PATCH] ext/fcntl/fcntl.c: add F_DUPFD_CLOEXEC constant — Eric Wong <normalperson@...>
[#35536] File.write take 4 — Roger Pack <rogerdpack2@...>
Hello all.
Could I get any feedback on my latest patch for File.write?
[#35552] [Ruby 1.9 - Feature #4523][Open] Kernel#require to return the path of the loaded file — Alex Young <alex@...>
On 18/03/12 10:22, nobu wrote:
On Mon, Mar 19, 2012 at 8:06 AM, Alex Young <alex@blackkettle.org> wrote:
On 19/03/12 11:58, Luis Lavena wrote:
[#35555] [Ruby 1.9 - Bug #4527][Open] [PATCH] IO#close releases GVL if possible — Eric Wong <normalperson@...>
[#35565] [Ruby 1.9 - Feature #4531][Open] [PATCH 0/7] use poll() instead of select() in certain cases — Eric Wong <normalperson@...>
> ref: [ruby-core:35527]
KOSAKI Motohiro <kosaki.motohiro@gmail.com> wrote:
2011/3/29 Eric Wong <normalperson@yhbt.net>:
Comment for patch 2.
Motohiro KOSAKI <kosaki.motohiro@gmail.com> wrote:
diff --git a/ext/-test-/wait_for_single_fd/wait_for_single_fd.c
[#35566] [Ruby 1.9 - Feature #4532][Open] [PATCH] add IO#pread and IO#pwrite methods — Eric Wong <normalperson@...>
2011/3/28 Eric Wong <normalperson@yhbt.net>:
KOSAKI Motohiro <kosaki.motohiro@gmail.com> wrote:
[#35567] [Ruby 1.9 - Bug #4534][Open] ri does not open $PAGER with program name only — Robert Klemme <shortcutter@...>
[#35586] [Ruby 1.9 - Feature #4538][Open] [PATCH (cleanup)] avoid unnecessary select() calls before doing I/O — Eric Wong <normalperson@...>
Charles Nutter <headius@headius.com> wrote:
[ruby-core:35525] Re: [Feature #2350](Rejected) Unicode specific functionality on String in 1.9
On Fri, Mar 18, 2011 at 11:53, Magnus Holm <judofyr@gmail.com> wrote: > The problem is that the definition of #upcase doesn't only depend on the > encoding used, but also the language of the encoded text. For instance, i= f > you're writing in Turkish, you would expect "i".upcase to return a dotted > uppcase I:=C2=A0http://www.i18nguy.com/unicode/turkish-i18n.html I know. The same goes for =E2=80=98i=E2=80=99 in Lithuanian. > Doing this properly is *really* hard and needs to have a lot of=C2=A0flex= ibility, > especially when it comes to non-Western languages. This is simply not true. Unicode defines how to deal with case conversions. I=E2=80=99m not saying that the Unicode standard is infallibl= e, but we can at least adhere to it. I=E2=80=99m not saying that Unicode is t= he only encoding that we should care about, but if we support the Unicode transfer formats, why not support other interesting parts of the standard? > It's far easier for everyone that the built-in #upcase is > simple and fast and you'll have to be explicit about any > other I18n stuff IMO. Easy, perhaps, but hardly useful. My point is that the current #upcase (and similar methods) is basically useless for anything other than ASCII. I was looking for an actual solution to this problem. I have a library (character-encodings) that does support these conversions, based on locale and the Unicode character database (UCD). How do we make it easy for the user to deal with m18n? I mean, if I say # -*- coding: utf-8 -*- puts "=C3=A4bc".upcase I expect this to do the right thing for Unicode under the current locale. As Unicode defines how to deal with case conversions, if I tell Ruby that =E2=80=9Cthis String is encoded as UTF-8=E2=80=9D (or, in this case, = =E2=80=9Cstrings in this file are encoded as UTF-8=E2=80=9D), I expect Ruby to respond =E2=80= =9COK, I=E2=80=99ll use the Unicode rules that govern methods like #upcase for that String=E2=80=9D. The UCD requires a lot of memory, so I suggested that a library, such as character-encodings, should be able to seamlessly add this kind of behavior without requiring the user to write "=C3=A4bc".unicodify.upcase, if the UCD can=E2=80=99t be included in standard Ruby runtime. But, come to think of it, doesn=E2=80=99t Oniguruma need most of the UCD information, so isn=E2=80=99t most of it already included in the Ruby runti= me? Adding casing information perhaps wouldn=E2=80=99t require much additional space. If this isn=E2=80=99t of interest, then I=E2=80=99m still looking for a way= to override #upcase for Strings that use the UTF-8 encoding without resorting to alias_method or extend (as shown earlier in this discussion). This seems impossible to do at the moment, as Encoding is a completely opaque object.