[#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 ”äBC” instead of ”ÄBC”?
[#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, if > you're writing in Turkish, you would expect "i".upcase to return a dotted > uppcase I: http://www.i18nguy.com/unicode/turkish-i18n.html I know. The same goes for ‘i’ in Lithuanian. > Doing this properly is *really* hard and needs to have a lot of flexibility, > especially when it comes to non-Western languages. This is simply not true. Unicode defines how to deal with case conversions. I’m not saying that the Unicode standard is infallible, but we can at least adhere to it. I’m not saying that Unicode is the 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 "äbc".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 “this String is encoded as UTF-8” (or, in this case, “strings in this file are encoded as UTF-8”), I expect Ruby to respond “OK, I’ll use the Unicode rules that govern methods like #upcase for that String”. 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 "äbc".unicodify.upcase, if the UCD can’t be included in standard Ruby runtime. But, come to think of it, doesn’t Oniguruma need most of the UCD information, so isn’t most of it already included in the Ruby runtime? Adding casing information perhaps wouldn’t require much additional space. If this isn’t of interest, then I’m 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.