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

From: "Eregon (Benoit Daloze) via ruby-core" <ruby-core@...>
Date: 2023-08-22 13:38:06 UTC
List: ruby-core #114444
Issue #19772 has been updated by Eregon (Benoit Daloze).


I think `YARP` is already too widely used and talked about to be renamed without causing significant confusion and downsides.
In fact the gem already has [multiple releases](https://rubygems.org/gems/yarp).

> I don't think "YA-" names nice in general, unless for development code name.

I don't see the problem with that.
The obvious names which could be better are `parser` and `ruby_parser` but both are already taken.

As a parallel, I think RubyVM should be YARV/CRuby, `RubyVM` confuses everyone, it looks like something general but it's actually YARV/CRuby-specific (at the very least RubyVM::InstructionSequence).

`YARP::CallNode` looks better than `Prism::CallNode` to me.

Many many Rubyists already know this project as YARP, renaming it now would IMO cause confusion and hurt.
The benefits of the rename seem way too small.

(also BTW there is already YJIT/`--yjit`, and it seems nobody minds that name)

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

* 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