ml.ruby-lang.org
Sign In Sign Up
Manage this list Sign In Sign Up

Keyboard Shortcuts

Thread View

  • j: Next unread message
  • k: Previous unread message
  • j a: Jump to all threads
  • j l: Jump to MailingList overview

ruby-dev

Thread Start a new thread
Download
Threads by month
  • ----- 2025 -----
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2024 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2023 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2022 -----
  • December
  • November
ruby-dev@ml.ruby-lang.org

August 2023

  • 1 participants
  • 5 discussions
[ruby-dev:52034] [Ruby master Bug#19792] arm の alpine 上でネストしたハッシュに長い文字列を入れると segmentation fault が発生する
by koke2y 30 Sep '23

30 Sep '23
Issue #19792 has been reported by koke2y (優樹 纐纈). ---------------------------------------- Bug #19792: arm の alpine 上でネストしたハッシュに長い文字列を入れると segmentation fault が発生する https://bugs.ruby-lang.org/issues/19792 * Author: koke2y (優樹 纐纈) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.2 (2023-03-30 revision e51014f9c0) +YJIT [aarch64-linux-musl] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ## 実行環境 Docker version: Docker version 24.0.2, build cb74dfc Docker image: ruby:3.2.2-alpine3.18 ホスト環境 - chip: Apple M2 Max - OS version: Version 13.4 ## 発生した事象 上記の環境で下記のスクリプトを実行すると、segmentation faultが発生しました。 ``` str = 'a' * 100_000_000 hash = { x: { y: { z: str } } } p hash ``` ``` 81a3dc0d38e8:/api# ruby test.rb test.rb:11: [BUG] Segmentation fault at 0x0000ffff84e454a0 ruby 3.2.2 (2023-03-30 revision e51014f9c0) +YJIT [aarch64-linux-musl] -- Control frame information ----------------------------------------------- c:0006 p:---- s:0022 e:000021 CFUNC :inspect c:0005 p:---- s:0019 e:000018 CFUNC :inspect c:0004 p:---- s:0016 e:000015 CFUNC :inspect c:0003 p:---- s:0013 e:000012 CFUNC :p c:0002 p:0029 s:0008 E:001cc0 EVAL test.rb:11 [FINISH] c:0001 p:0000 s:0003 E:000da0 DUMMY [FINISH] ``` -- https://bugs.ruby-lang.org/
5 5
0 0
[ruby-dev:52042] [Ruby master Bug#17925] Pattern matching syntax using semicolon one-line
by kddnewton (Kevin Newton) 25 Aug '23

25 Aug '23
Issue #17925 has been updated by kddnewton (Kevin Newton). This is interesting. It surfaces and incompatibility we have. I didn't realize Ruby didn't allow this, so YARP allows `case expression in 42; end` to parse as expected by the OP here. If `parse.y` can't support this, I will need to explicitly disallow this in YARP. ---------------------------------------- Bug #17925: Pattern matching syntax using semicolon one-line https://bugs.ruby-lang.org/issues/17925#change-104372 * Author: koic (Koichi ITO) * Status: Open * Priority: Normal * ruby -v: ruby 3.1.0dev (2021-05-28T16:34:27Z master e56ba6231f) [x86_64-darwin19] * Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN ---------------------------------------- ## Summary There are the following differences between `case ... when` and` case ... in`. Is this an expected behavior? ```console % ruby -v ruby 3.1.0dev (2021-05-28T16:34:27Z master e56ba6231f) [x86_64-darwin19] % ruby -ce 'case expression when 42; end' Syntax OK % ruby -ce 'case expression in 42; end' -e:1: warning: One-line pattern matching is experimental, and the behavior may change in future versions of Ruby! -e:1: syntax error, unexpected `end', expecting `when' case expression in 42; end ``` So, I have two concerns. - Since the pattern matching syntax is different from `case ... when`, can't user write semicolon one-line `case ... in` in the same semicolon one-line as `case ... when`? - Does `case expression in 42; end` display an experimental warning of one-line pattern matching. Right? This is reproduced in Ruby 3.1.0-dev and Ruby 3.0.1. ## Additional Information NOTE 1: I understand that only syntax that doesn't use `case` and `end` is experimental one-line pattern matching syntax. ``` % ruby -ce 'expression in 42' -e:1: warning: One-line pattern matching is experimental, and the behavior may change in future versions of Ruby! Syntax OK ``` NOTE 2: The syntax is OK if a semicolon is used between `expression` and `in`. But `case ... when` is a valid syntax to omit. ``` % ruby -e ruby -ce 'case expression; in 42; end' Syntax OK ``` -- https://bugs.ruby-lang.org/
1 0
0 0
[ruby-dev:52041] [Ruby master Bug#17925] Pattern matching syntax using semicolon one-line
by nobu (Nobuyoshi Nakada) 25 Aug '23

25 Aug '23
Issue #17925 has been updated by nobu (Nobuyoshi Nakada). I thought it a trade-off. To allow the statement, one-line pattern matching is not allowed there. But it returns `true`/`false` only and may be useless for `case`. ---------------------------------------- Bug #17925: Pattern matching syntax using semicolon one-line https://bugs.ruby-lang.org/issues/17925#change-104322 * Author: koic (Koichi ITO) * Status: Open * Priority: Normal * ruby -v: ruby 3.1.0dev (2021-05-28T16:34:27Z master e56ba6231f) [x86_64-darwin19] * Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN ---------------------------------------- ## Summary There are the following differences between `case ... when` and` case ... in`. Is this an expected behavior? ```console % ruby -v ruby 3.1.0dev (2021-05-28T16:34:27Z master e56ba6231f) [x86_64-darwin19] % ruby -ce 'case expression when 42; end' Syntax OK % ruby -ce 'case expression in 42; end' -e:1: warning: One-line pattern matching is experimental, and the behavior may change in future versions of Ruby! -e:1: syntax error, unexpected `end', expecting `when' case expression in 42; end ``` So, I have two concerns. - Since the pattern matching syntax is different from `case ... when`, can't user write semicolon one-line `case ... in` in the same semicolon one-line as `case ... when`? - Does `case expression in 42; end` display an experimental warning of one-line pattern matching. Right? This is reproduced in Ruby 3.1.0-dev and Ruby 3.0.1. ## Additional Information NOTE 1: I understand that only syntax that doesn't use `case` and `end` is experimental one-line pattern matching syntax. ``` % ruby -ce 'expression in 42' -e:1: warning: One-line pattern matching is experimental, and the behavior may change in future versions of Ruby! Syntax OK ``` NOTE 2: The syntax is OK if a semicolon is used between `expression` and `in`. But `case ... when` is a valid syntax to omit. ``` % ruby -e ruby -ce 'case expression; in 42; end' Syntax OK ``` -- https://bugs.ruby-lang.org/
1 0
0 0
[ruby-dev:52040] [Ruby master Bug#17925] Pattern matching syntax using semicolon one-line
by jeremyevans0 (Jeremy Evans) 24 Aug '23

24 Aug '23
Issue #17925 has been updated by jeremyevans0 (Jeremy Evans). @kddnewton Is this possible to fix in YARP? @yui-knk Is this possible to fix in parse.y/lrama? ---------------------------------------- Bug #17925: Pattern matching syntax using semicolon one-line https://bugs.ruby-lang.org/issues/17925#change-104311 * Author: koic (Koichi ITO) * Status: Open * Priority: Normal * ruby -v: ruby 3.1.0dev (2021-05-28T16:34:27Z master e56ba6231f) [x86_64-darwin19] * Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN ---------------------------------------- ## Summary There are the following differences between `case ... when` and` case ... in`. Is this an expected behavior? ```console % ruby -v ruby 3.1.0dev (2021-05-28T16:34:27Z master e56ba6231f) [x86_64-darwin19] % ruby -ce 'case expression when 42; end' Syntax OK % ruby -ce 'case expression in 42; end' -e:1: warning: One-line pattern matching is experimental, and the behavior may change in future versions of Ruby! -e:1: syntax error, unexpected `end', expecting `when' case expression in 42; end ``` So, I have two concerns. - Since the pattern matching syntax is different from `case ... when`, can't user write semicolon one-line `case ... in` in the same semicolon one-line as `case ... when`? - Does `case expression in 42; end` display an experimental warning of one-line pattern matching. Right? This is reproduced in Ruby 3.1.0-dev and Ruby 3.0.1. ## Additional Information NOTE 1: I understand that only syntax that doesn't use `case` and `end` is experimental one-line pattern matching syntax. ``` % ruby -ce 'expression in 42' -e:1: warning: One-line pattern matching is experimental, and the behavior may change in future versions of Ruby! Syntax OK ``` NOTE 2: The syntax is OK if a semicolon is used between `expression` and `in`. But `case ... when` is a valid syntax to omit. ``` % ruby -e ruby -ce 'case expression; in 42; end' Syntax OK ``` -- https://bugs.ruby-lang.org/
1 0
0 0
[ruby-dev:52038] [Ruby master Bug#8782] Don't set rl_getc_function on editline
by jeremyevans0 (Jeremy Evans) 22 Aug '23

22 Aug '23
Issue #8782 has been updated by jeremyevans0 (Jeremy Evans). Status changed from Assigned to Closed Backport deleted (1.9.3: UNKNOWN, 2.0.0: UNKNOWN) Readline support was removed in commit:59fd67fc3d405e529e038172e769ff20a8fb5535. If this is still an issue, please file it upstream https://github.com/ruby/readline-ext ---------------------------------------- Bug #8782: Don't set rl_getc_function on editline https://bugs.ruby-lang.org/issues/8782#change-104205 * Author: naruse (Yui NARUSE) * Status: Closed * Priority: Normal * Assignee: kouji (Kouji Takao) * ruby -v: ruby 2.1.0dev (2013-08-12 trunk 42528) [x86_64-darwin12.4.0] ---------------------------------------- r42402 以来 OS X 等の editline 環境では #define rl_getc(f) EOF が使われるようになってしまって残念なことになっていたわけですが、 そもそも editline の readline wrapper は non ASCII に対応していません。 (editline 自体には UTF-8 のみの対応が入ったが、readline wrapper は src/readline.c の _getc_function を経由するので non ASCII は化ける) ので、いっそ rl_getc_function を使わないようにしてはどうでしょう。 以下のようなパッチを当てると、readline なしの OS X の irb で日本語が使えるようになります。 diff --git a/ext/readline/extconf.rb b/ext/readline/extconf.rb index 0b121c1..bc0ee77 100644 --- a/ext/readline/extconf.rb +++ b/ext/readline/extconf.rb @@ -94,4 +94,5 @@ readline.have_func("clear_history") readline.have_func("rl_redisplay") readline.have_func("rl_insert_text") readline.have_func("rl_delete_text") +readline.have_func("el_init") create_makefile("readline") diff --git a/ext/readline/readline.c b/ext/readline/readline.c index 0f76d1a..85109f0 100644 --- a/ext/readline/readline.c +++ b/ext/readline/readline.c @@ -130,12 +130,7 @@ static VALUE readline_instream; static VALUE readline_outstream; #if defined HAVE_RL_GETC_FUNCTION - -#ifndef HAVE_RL_GETC -#define rl_getc(f) EOF -#endif - -static int readline_getc(FILE *); +# ifndef HAVE_EL_INIT static int readline_getc(FILE *input) { @@ -187,6 +182,7 @@ readline_getc(FILE *input) #endif return FIX2INT(c); } +# endif #elif defined HAVE_RL_EVENT_HOOK #define BUSY_WAIT 0 @@ -1771,7 +1767,9 @@ Init_readline() /* libedit check rl_getc_function only when rl_initialize() is called, */ /* and using_history() call rl_initialize(). */ /* This assignment should be placed before using_history() */ +# ifndef HAVE_EL_INIT rl_getc_function = readline_getc; +# endif #elif defined HAVE_RL_EVENT_HOOK rl_event_hook = readline_event; #endif -- https://bugs.ruby-lang.org/
1 0
0 0

HyperKitty Powered by HyperKitty version 1.3.12.