[#114348] [Ruby master Feature#19832] Method#destructive?, UnboundMethod#destructive? — "sawa (Tsuyoshi Sawada) via ruby-core" <ruby-core@...>

Issue #19832 has been reported by sawa (Tsuyoshi Sawada).

15 messages 2023/08/06

[#114365] [Ruby master Bug#19834] Segmentation fault while running in docker — "ramachandran@... (Ramachandran A) via ruby-core" <ruby-core@...>

Issue #19834 has been reported by ramachandran@mallow-tech.com (Ramachandran A).

7 messages 2023/08/09

[#114380] [Ruby master Bug#19837] Concurrent calls to Process.waitpid2 misbehave on Ruby 3.1 & 3.2 — "kjtsanaktsidis (KJ Tsanaktsidis) via ruby-core" <ruby-core@...>

Issue #19837 has been reported by kjtsanaktsidis (KJ Tsanaktsidis).

7 messages 2023/08/11

[#114399] [Ruby master Feature#19839] Need a method to check if two ranges overlap — "shouichi (Shouichi KAMIYA) via ruby-core" <ruby-core@...>

Issue #19839 has been reported by shouichi (Shouichi KAMIYA).

27 messages 2023/08/18

[#114410] [Ruby master Bug#19841] Marshal.dump stack overflow with recursive Time — "segiddins (Samuel Giddins) via ruby-core" <ruby-core@...>

Issue #19841 has been reported by segiddins (Samuel Giddins).

9 messages 2023/08/18

[#114422] [Ruby master Feature#19842] Intorduce M:N threads — "ko1 (Koichi Sasada) via ruby-core" <ruby-core@...>

Issue #19842 has been reported by ko1 (Koichi Sasada).

30 messages 2023/08/21

[#114590] [Ruby master Bug#19857] Eval coverage is reset after each `eval`. — "ioquatix (Samuel Williams) via ruby-core" <ruby-core@...>

Issue #19857 has been reported by ioquatix (Samuel Williams).

21 messages 2023/08/30

[ruby-core:114531] [Ruby master Misc#19772] API naming for YARP compiler

From: "kddnewton (Kevin Newton) via ruby-core" <ruby-core@...>
Date: 2023-08-25 12:37:29 UTC
List: ruby-core #114531
Issue #19772 has been updated by kddnewton (Kevin Newton).


Thank you @k0kubun, I didn't fully understand that requirement until you wrote it out here.

I would like to suggest we go with a combination of #2 and #4. I don't think we need to duplicate all of the constants. I think we could use the same parse function that the current runtime uses (like matz's idea) but use the same code we use in YARP to build the Ruby objects. However that function is invisible to the YARP C extension, so it would need to be implemented by the runtime (which we can do since all of the runtimes have integrated it).

I would like to do this because it makes it so that we can solve your requirement (that the code is parsed exactly as the current runtime is parsing it) but it also allows us to provide upgrades and bugfixes to the Ruby API of YARP.

I think it's fine that the C and Ruby code would be provided by different YARP versions. We wouldn't want to introduce any breaking changes outside of a major version of Ruby anyway because we would want tool authors to get a consistent experience. (I have been calling everything that calls `Parser.parse` a tool, maybe I need a better term...) There are a couple of technical hurdles we will need to overcome if we introduce additional fields between versions, but I believe these will be easily overcome.

----------------------------------------
Misc #19772: API naming for YARP compiler
https://bugs.ruby-lang.org/issues/19772#change-104332

* Author: jemmai (Jemma Issroff)
* Status: Open
* Priority: Normal
----------------------------------------
We are working on the YARP compiler, and have [the first PR ready](https://github.com/ruby/ruby/pull/8042) which introduces the YARP compile method. Our only outstanding question before merging it is about naming. How should we expose the public API for YARP's compile method?

Potential suggestions:

1. YARP.compile
2. RubyVM::InstructionSequence.compile(yarp: true)
3. RubyVM::InstructionSequence.compile_yarp
4. Any of the above options, with a name other than yarp (please suggest an alternative)

Regarding option 1, which would mirror `YARP.parse`, is the top level constant `YARP` acceptable?

cc @matz @ko1 



-- 
https://bugs.ruby-lang.org/
 ______________________________________________
 ruby-core mailing list -- ruby-core@ml.ruby-lang.org
 To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org
 ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-core.ml.ruby-lang.org/

In This Thread