[#59462] [ruby-trunk - Bug #9342][Open] [PATCH] SizedQueue#clear does not notify waiting threads in Ruby 1.9.3 — "jsc (Justin Collins)" <redmine@...>

9 messages 2014/01/02

[#59466] [ruby-trunk - Bug #9343][Open] [PATCH] SizedQueue#max= wakes up waiters properly — "normalperson (Eric Wong)" <normalperson@...>

11 messages 2014/01/02

[#59498] [ruby-trunk - Bug #9352][Open] [BUG] rb_sys_fail_str(connect(2) for [fe80::1%lo0]:3000) - errno == 0 — "kain (Claudio Poli)" <claudio@...>

10 messages 2014/01/03

[#59516] [ruby-trunk - Bug #9356][Open] TCPSocket.new does not seem to handle INTR — "charliesome (Charlie Somerville)" <charliesome@...>

48 messages 2014/01/03

[#59538] [ruby-trunk - Feature #9362][Assigned] Minimize cache misshit to gain optimal speed — "shyouhei (Shyouhei Urabe)" <shyouhei@...>

33 messages 2014/01/03
[#59582] Re: [ruby-trunk - Feature #9362][Assigned] Minimize cache misshit to gain optimal speed — SASADA Koichi <ko1@...> 2014/01/06

Intersting challenge.

[#59541] Re: [ruby-trunk - Feature #9362][Assigned] Minimize cache misshit to gain optimal speed — Eric Wong <normalperson@...> 2014/01/04

Hi, I noticed a trivial typo in array.c, and it fails building struct.c

[#59583] [ruby-trunk - Bug #9367][Open] REXML::XmlDecl doesn't use user specified quotes — "bearmini (Takashi Oguma)" <bear.mini@...>

12 messages 2014/01/06

[#59642] [ruby-trunk - Bug #9384][Open] Segfault in ruby 2.1.0p0 — "cbliard (Christophe Bliard)" <christophe.bliard@...>

11 messages 2014/01/08

[#59791] About unmarshallable DRb objects life-time — Rodrigo Rosenfeld Rosas <rr.rosas@...>

A while ago I created a proof-of-concept that I intended to use in my

16 messages 2014/01/15
[#59794] Re: About unmarshallable DRb objects life-time — Eric Hodel <drbrain@...7.net> 2014/01/15

On 15 Jan 2014, at 11:58, Rodrigo Rosenfeld Rosas <rr.rosas@gmail.com> wrote:

[#59808] Re: About unmarshallable DRb objects life-time — Rodrigo Rosenfeld Rosas <rr.rosas@...> 2014/01/16

Em 15-01-2014 19:42, Eric Hodel escreveu:

[#59810] Re: About unmarshallable DRb objects life-time — Eric Hodel <drbrain@...7.net> 2014/01/16

On 16 Jan 2014, at 02:15, Rodrigo Rosenfeld Rosas <rr.rosas@gmail.com> wrote:

[#59826] Re: About unmarshallable DRb objects life-time — Rodrigo Rosenfeld Rosas <rr.rosas@...> 2014/01/17

Em 16-01-2014 19:43, Eric Hodel escreveu:

[#59832] Re: About unmarshallable DRb objects life-time — Eric Hodel <drbrain@...7.net> 2014/01/17

On 17 Jan 2014, at 04:22, Rodrigo Rosenfeld Rosas <rr.rosas@gmail.com> wrote:

[ruby-core:59655] [ruby-trunk - Bug #7742] System encoding (Windows-1258) is not recognized by Ruby to convert back to UTF-8

From: duerst (Martin Dürst) <duerst@...>
Date: 2014-01-09 07:26:39 UTC
List: ruby-core #59655
Issue #7742 has been updated by duerst (Martin D端rst).


thegcat (Felix Sch辰fer) wrote:
> =begin
> We (((<Planio|URL:https://plan.io>))) are also in need of Windows-1258 to UTF-8 conversion, is there anything we can do to help?
> =end

As explained above, the problem is with normalization. If you are okay with a version that just does one-to-one conversion, then that can be produced rather quickly (maybe even over the weekend). But most Vietnamese content, e.g. on the Web, is normalized (NFC), and I guess you'd want to have that, too. But then you also have to be careful with respect to round-tripping, because windows-1258->UTF-8 will be .encode('UTF-8', 'windows-1258').to_nfc or so, but backwards conversion would need special code because neither NFC nor NFD can directly be converted to windows-1258.

A slightly more elaborate version would do one-to-one conversion from windows-1258 to UTF-8, but would convert that kind of data as well as data in NFC back to windows-1258 (but not arbitrarily non-normalized data) back to windows-1258. Such a converter might be relatively easy to produce, or it might be more difficult; I can't say which off the top of my head.

So if you use a normalization library after conversion, that might work out, but it would be somewhat of a special case. Also, when we later introduce a different (more normalizing) converter, that may be seen as a non-backwards-compatible change.

One solution to backwards-compatibility would be to use different encoding labels to differentiate versions of conversion. But this has the problem that in the current state of affairs, it introduces additional "encodings" that are not really different, but just variants produced by different conversions. That's the problem e.g. with the current UTF8-MAC, and I don't want to create more of these.

A more long-term solution would be to introduce a difference between encodings and conversions, where e.g. one could use .encode('windows-1258--non-normalized', 'utf-8') or so to indicate a non-normalized version of conversion. But that would need some more general discussion among the Ruby experts in this field.

So Felix, if you tell me what you need, and we can make sure that it doesn't affect later backwards-compatibility, I might be able to work on something.
----------------------------------------
Bug #7742: System encoding (Windows-1258) is not recognized by Ruby to  convert back to UTF-8 
https://bugs.ruby-lang.org/issues/7742#change-44183

Author: Mars (Hong Ha Dang )
Status: Open
Priority: Normal
Assignee: duerst (Martin D端rst)
Category: 
Target version: next minor
ruby -v: 1.9.3
Backport: 


I installed Railsinstaller in win8. After intall complete the screen set to 
> configuration Railsinstaller on cmd (step 2). I give user name: DHH Mars and 
> email: dhhma...@gmail.com. It ran and have following massage: 
> 
> C:/RailsInstaller/scripts/config_check.rb:64:in 'exist?': code converter not 
> found <Windows-1258 to UTF-8> <Encoding::ConverterNotFoundError> from 
> C:/RailsInstaller/scripts/config_check.rb:64:in 'main' 
> 
> C:\Sites> 


-- 
http://bugs.ruby-lang.org/

In This Thread