[#78949] [Ruby trunk Feature#13095] [PATCH] io.c (rb_f_syscall): remove deprecation notice — kosaki.motohiro@...
Issue #13095 has been updated by Motohiro KOSAKI.
3 messages
2017/01/03
[#78997] [Ruby trunk Bug#13110] Byte-based operations for String — shugo@...
Issue #13110 has been updated by Shugo Maeda.
3 messages
2017/01/06
[#79228] Re: [ruby-cvs:64576] naruse:r57410 (trunk): Prevent GC by volatile [Bug #13150] — Eric Wong <normalperson@...>
naruse@ruby-lang.org wrote:
5 messages
2017/01/23
[#79511] Re: [ruby-cvs:64576] naruse:r57410 (trunk): Prevent GC by volatile [Bug #13150]
— Eric Wong <normalperson@...>
2017/02/13
Eric Wong <normalperson@yhbt.net> wrote:
[#79518] Re: [ruby-cvs:64576] naruse:r57410 (trunk): Prevent GC by volatile [Bug #13150]
— Nobuyoshi Nakada <nobu@...>
2017/02/13
On 2017/02/13 10:04, Eric Wong wrote:
[#79298] [Ruby trunk Bug#13085][Assigned] io.c io_fwrite creates garbage — nobu@...
Issue #13085 has been updated by Nobuyoshi Nakada.
3 messages
2017/01/29
[#79337] Re: [ruby-changes:45397] normal:r57469 (trunk): io.c: recycle garbage on write — SASADA Koichi <ko1@...>
Eric:
4 messages
2017/01/31
[#79352] Re: [ruby-changes:45397] normal:r57469 (trunk): io.c: recycle garbage on write
— Eric Wong <normalperson@...>
2017/01/31
SASADA Koichi <ko1@atdot.net> wrote:
[ruby-core:79230] [Ruby trunk Bug#13152][Feedback] Numeric parsing differences between ruby <-> crystal
From:
duerst@...
Date:
2017-01-23 23:49:06 UTC
List:
ruby-core #79230
Issue #13152 has been updated by Martin D端rst. Status changed from Open to Feedback A few questions: - What is the result if this expression is written as a formula (i.e. with the exponent as a superscript)? Wouldn't this be the more 'intuitive' behavior? - What would the backwards compatibility issues be for Ruby when changing this? (I guess there might be quite a few subtle bugs.) - What do other languages (in particular languages more well known that Cristal) do? - Wouldn't it be quite easy to automate this part of the conversion? - Why do I think that the sentence "However, on the heels of the discussion/decision to not change the default rounding behavior of numerics in 2.4.0 would it also be worth it to change this parsing behavior to make this more natural and intuitive, as in crystal?" doesn't make sense? On the heels of not making a backwards incompatible change, would it really be worth to make another backwards incompatible change? ---------------------------------------- Bug #13152: Numeric parsing differences between ruby <-> crystal https://bugs.ruby-lang.org/issues/13152#change-62648 * Author: Jabari Zakiya * Status: Feedback * Priority: Normal * Assignee: * Target version: * ruby -v: * Backport: 2.2: UNKNOWN, 2.3: UNKNOWN, 2.4: UNKNOWN ---------------------------------------- I noticed this difference between ruby and crystal when converting a gem. puts -2**4 -> -16 (ruby) || 16 (crystal) puts (-2)**4 -> 16 (both) ruby parses -2**4 as -(2**4), while crystal does (-2)**4, which is more intuitive. This creates need to be careful converting negative number usage from ruby <-> crystal. (I haven't investigated differences with other languages.) Using parentheses to explicitly create intended outcomes can overcome this. However, on the heels of the discussion/decision to not change the default rounding behavior of numerics in 2.4.0 would it also be worth it to change this parsing behavior to make this more natural and intuitive, as in crystal? -- 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>