[#101981] [Ruby master Bug#17519] set_visibility fails when a prepended module and a refinement both exist — dbfeldman@...

Issue #17519 has been reported by fledman (David Feldman).

12 messages 2021/01/08

[#102003] [Ruby master Bug#17527] rb_io_wait_readable/writable with scheduler don't check errno — julien@...

Issue #17527 has been reported by ysbaddaden (Julien Portalier).

13 messages 2021/01/11

[#102065] [Ruby master Bug#17536] Segfault in `CFUNC :define_method` — v.ondruch@...

Issue #17536 has been reported by vo.x (Vit Ondruch).

13 messages 2021/01/13

[#102083] [Ruby master Bug#17540] A segfault due to Clang/LLVM optimization on 32-bit ARM Linux — xtkoba+ruby@...

Issue #17540 has been reported by xtkoba (Tee KOBAYASHI).

12 messages 2021/01/14

[#102102] [Ruby master Bug#17543] Ractor isolation broken by `self` in shareable proc — marcandre-ruby-core@...

Issue #17543 has been reported by marcandre (Marc-Andre Lafortune).

14 messages 2021/01/15

[#102118] [Ruby master Feature#17548] Need simple way to include symlink directories in Dir.glob — keithrbennett@...

Issue #17548 has been reported by keithrbennett (Keith Bennett).

8 messages 2021/01/17

[#102158] [Ruby master Bug#17560] Does `Module#ruby2_keywords` return `nil` or `self`? — nobu@...

Issue #17560 has been reported by nobu (Nobuyoshi Nakada).

9 messages 2021/01/19

[#102163] [Ruby master Bug#17561] The timeout option for Addrinfo.getaddrinfo is not reliable on Ruby 2.7.2 — sean@...

Issue #17561 has been reported by smcgivern (Sean McGivern).

8 messages 2021/01/19

[#102249] [Ruby master Bug#17583] Segfault on large stack(RUBY_THREAD_VM_STACK_SIZE) — yoshiokatsuneo@...

Issue #17583 has been reported by yoshiokatsuneo (Tsuneo Yoshioka).

12 messages 2021/01/26

[#102256] [Ruby master Bug#17585] DWAR5 support? — v.ondruch@...

Issue #17585 has been reported by vo.x (Vit Ondruch).

19 messages 2021/01/26

[#102301] [Ruby master Bug#17591] Test frameworks and REPLs do not show deprecation warnings by default — eregontp@...

Issue #17591 has been reported by Eregon (Benoit Daloze).

14 messages 2021/01/29

[#102305] [Ruby master Feature#17592] Ractor should allowing reading shareable class instance variables — marcandre-ruby-core@...

Issue #17592 has been reported by marcandre (Marc-Andre Lafortune).

25 messages 2021/01/29

[ruby-core:101879] [Ruby master Feature#17490] Rename RubyVM::MJIT to RubyVM::JIT

From: eregontp@...
Date: 2021-01-02 12:50:50 UTC
List: ruby-core #101879
Issue #17490 has been updated by Eregon (Benoit Daloze).


> ## Release notes
> > Actually I think MJIT is a lot clearer than JIT in e.g. https://www.ruby-lang.org/en/news/2020/12/25/ruby-3-0-0-released/
> MJIT is not the only "Ruby Just-in-Time compiler", so being precise seems helpful to me when mentioning it by name.
> 
> Are you saying, if we write "JIT" in an MRI release note, readers might get confused about whether it's MRI's JIT or TruffleRuby's Graal?

Not really, I'm saying the "JIT" is just unclear, "which JIT is it?".
The 3.0.0 release notes are hard to read for me because they mix MJIT and JIT.
If we use MJIT everywhere in that note, then I think it is very clear.
If we use JIT everywhere in that note, then I think it is very unclear.
I show examples below.

> Once we have another tier of JIT in MRI, I'd agree it's useful to mention the name "MJIT" at least in a NEWS like:

Yes, I was also thinking about that, if there is another JIT in MRI then `RubyVM::JIT` would become ambiguous.

> but a release note is something which is read by many non-Rubyist people who often don't know there has been a JIT since Ruby 2.6 in the first place.

That means they didn't read previous release notes then?
So probably they read the 3.0 notes because of the new major version.

I think a single sentence, or a link for MJIT would be best, e.g.,
"MJIT is a method JIT for CRuby available since Ruby 2.6."

> Many people thought Ruby 3 newly introduced a JIT, reading the latest release note.

I think that's partly caused by using the term JIT and not MJIT in some places.

"Many improvements were implemented in MJIT." is very clear.

"As of Ruby 3.0, JIT is supposed to give performance improvements in limited workloads" is unclear, does it mean a JIT appeared in 3.0? (no)
Same with JIT->MJIT is clear:
"As of Ruby 3.0, MJIT is supposed to give performance improvements in limited workloads"


----------------------------------------
Feature #17490: Rename RubyVM::MJIT to RubyVM::JIT
https://bugs.ruby-lang.org/issues/17490#change-89720

* Author: k0kubun (Takashi Kokubun)
* Status: Open
* Priority: Normal
----------------------------------------
## Background
In my understanding, MJIT is a codename like YARV which many people outside Ruby community are not familiar with, so I've used JIT in NEWS or release notes to avoid explaining the "M" part whenever we release a new version. However, because we have the name "MJIT" in one of our constants, we've had some naming inconsistency. For instance, --jit is not --mjit and it's not consistent.

## Proposal
Have the same constant as `RubyVM::JIT`, deprecate `RubyVM::MJIT` from Ruby 3.1, and remove the old one in Ruby 3.2.

## Impact
This impacts only [Feature #14830] `RubyVM::MJIT.pause` / `RubyVM::MJIT.resume`, which is basically for k0kubun's own testing.



-- 
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>

In This Thread