[#90865] [Ruby trunk Bug#15499] Breaking behavior on ruby 2.6: rb_thread_call_without_gvl doesn't invoke unblock_function when used on the main thread — apolcyn@...
Issue #15499 has been reported by apolcyn (alex polcyn).
3 messages
2019/01/03
[#90877] [Ruby trunk Bug#15499] Breaking behavior on ruby 2.6: rb_thread_call_without_gvl doesn't invoke unblock_function when used on the main thread — apolcyn@...
Issue #15499 has been updated by apolcyn (alex polcyn).
3 messages
2019/01/03
[#90895] Re: [ruby-alerts:11680] failure alert on trunk-mjit@silicon-docker (NG (r66707)) — Eric Wong <normalperson@...>
ko1c-failure@atdot.net wrote:
4 messages
2019/01/05
[#90896] Re: [ruby-alerts:11680] failure alert on trunk-mjit@silicon-docker (NG (r66707))
— Takashi Kokubun <takashikkbn@...>
2019/01/05
Thanks to explain that.
[#91200] [Ruby trunk Feature#15553] Addrinfo.getaddrinfo supports timeout — glass.saga@...
Issue #15553 has been reported by Glass_saga (Masaki Matsushita).
4 messages
2019/01/21
[#91289] Re: [Ruby trunk Feature#15553] Addrinfo.getaddrinfo supports timeout
— Eric Wong <normalperson@...>
2019/01/26
glass.saga@gmail.com wrote:
[ruby-core:91212] [Ruby trunk Bug#11116] The spec of String#dump
From:
mame@...
Date:
2019-01-21 13:20:59 UTC
List:
ruby-core #91212
Issue #11116 has been updated by mame (Yusuke Endoh).
Eregon (Benoit Daloze) wrote:
> Does that preserve the encoding of the String though?
The short answer: yes.
If the encoding is ASCII-compatible, it is preserved via its encoding of the resulting string.
```
s = "Hello こんにちは".encode("Windows-31J")
s = s.dump
puts s #=> "Hello \x82\xB1\x82\xF1\x82\xC9\x82\xBF\x82\xCD"
p s.encoding #=> #<Encoding:Windows-31J>
s = eval(s)
p s.encoding #=> #<Encoding:Windows-31J>
puts s.encode("UTF-8") #=> Hello こんにちは
```
If the encoding is not ASCII-compatible, the dumped string has an explicit `force_encoding`.
```
s = "Hello こんにちは".encode("UTF-16LE")
s = s.dump
puts s #=> "H\x00e\x00l\x00l\x00o\x00 \x00S0\x930k0a0o0".dup.force_encoding("UTF-16LE")
s = eval(s)
puts s.encode("UTF-8") #=> Hello こんにちは
```
I guess that there might be other subtle edge cases that I don't know. It is difficult for me to write the detailed document.
> What about String#inspect, does it also eval() to itself?
No, it is not guaranteed. `String#inspect` is just for human, so there is no annoying hack like the above non-ASCII-compatible encoding. (I have encountered another subtle case, but I cannot remember...)
----------------------------------------
Bug #11116: The spec of String#dump
https://bugs.ruby-lang.org/issues/11116#change-76450
* Author: mame (Yusuke Endoh)
* Status: Closed
* Priority: Normal
* Assignee: mame (Yusuke Endoh)
* Target version:
* ruby -v: ruby 2.2.1p85 (2015-02-26 revision 49769) [x86_64-linux]
* Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN, 2.2: UNKNOWN
----------------------------------------
The current spec says:
call-seq:
str.dump -> new_str
Produces a version of +str+ with all non-printing characters replaced by
<code>\nnn</code> notation and all special characters escaped.
"hello \n ''".dump #=> "\"hello \\n ''\"
`\nnn` must be `\xnn` now.
In addition, I've expected String#dump to return a string that evaluates to an original string (except singleton methods, object id, etc.) when `eval`ed. Is this a right expectation? If so, it would be good to officially include the mention in the spec. What do you think?
--
Yusuke Endoh <mame@ruby-lang.org>
--
https://bugs.ruby-lang.org/
Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>