[#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:114533] [Ruby master Misc#19772] API naming for YARP compiler

From: "Eregon (Benoit Daloze) via ruby-core" <ruby-core@...>
Date: 2023-08-25 13:31:48 UTC
List: ruby-core #114533
Issue #19772 has been updated by Eregon (Benoit Daloze).


@kddnewton
> 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.

How? That seems near impossible to me, without having 2 versions of the C code (*.h and *.c and `api_node.c`) & Ruby code too.
If there is a single `api_node.c` it would use the struct definitions in the gem for the result of `yp_parse` in interpreter, which would break as soon as there is any field change in any of the node structs.
E.g. if there is a new field in the yarp gem then it would read out of bounds.

And if we think about serialization I think it's more obvious it cannot work without duplicating all files related to serialization & deserialization and their dependencies (so basically every file of YARP), since it would be different YARP::VERSION and the check when deserializing would (correctly) fail.

---

Here is how I see those 5 solutions:

1. not really a solution because the Ripper API is very inconvenient to use and longer-term Ripper might use YARP, and/or be deprecated.
2. this requires quite a lot of work and magic to adapt the namespace. It feels rather messy, but probably feasible. Obviously there is the overhead of defining every Ruby node class twice, etc.
3. this is the simplest solution. It might be the best because of that.
4. I think this cannot work. It would need to duplicate every file but also if you install an older YARP gem how would it find the {.c,.h,.rb} files for current Ruby? It seems impossible.
5. this is the most generic solution and would allow to fully replace the `parser` gem, and make adoption much easier for any tool using the `parser` gem currently. It means more `if` in the codebase but OTOH a single branch to maintain.

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

* 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