ruby.git/include/ruby/internal/core, branch ruby_3_0 The Ruby Programming Language Removed rb_cData entity 2020-12-21T17:51:49+00:00 Nobuyoshi Nakada nobu@ruby-lang.org 2020-12-21T16:00:43+00:00 8918a9cf6c65409ae1ffcdea324a1b97c6e5bb70 * Use the wrapper of rb_cObject instead of data access * Replaced rest of extentions * Updated the version guard for Data * Added the version guard of rb_cData 
* Use the wrapper of rb_cObject instead of data access
* Replaced rest of extentions
* Updated the version guard for Data
* Added the version guard of rb_cData
Added parentheses to silence sizeof-array-div warnings [Bug #17385] 2020-12-12T05:25:30+00:00 Nobuyoshi Nakada nobu@ruby-lang.org 2020-12-12T05:22:59+00:00 68af5235292f82145c599038b4bff7d9225e62d7 As well as 2366c681166a1dab95de6b9ca8ffcaae18aadd39. 
As well as 2366c681166a1dab95de6b9ca8ffcaae18aadd39.
Ractor.make_shareable(obj) 2020-10-20T22:59:24+00:00 Koichi Sasada ko1@atdot.net 2020-10-20T15:54:03+00:00 2f50936cb913b7458cbaa03dc4652f1127a7631a Introduce new method Ractor.make_shareable(obj) which tries to make obj shareable object. Protocol is here. (1) If obj is shareable, it is shareable. (2) If obj is not a shareable object and if obj can be shareable object if it is frozen, then freeze obj. If obj has reachable objects (rs), do rs.each{|o| Ractor.make_shareable(o)} recursively (recursion is not Ruby-level, but C-level). (3) Otherwise, raise Ractor::Error. Now T_DATA is not a shareable object even if the object is frozen. If the method finished without error, given obj is marked as a sharable object. To allow makng a shareable frozen T_DATA object, then set `RUBY_TYPED_FROZEN_SHAREABLE` as type->flags. On default, this flag is not set. It means user defined T_DATA objects are not allowed to become shareable objects when it is frozen. You can make any object shareable by setting FL_SHAREABLE flag, so if you know that the T_DATA object is shareable (== thread-safe), set this flag, at creation time for example. `Ractor` object is one example, which is not a frozen, but a shareable object. 
Introduce new method Ractor.make_shareable(obj) which tries to make
obj shareable object. Protocol is here.

(1) If obj is shareable, it is shareable.
(2) If obj is not a shareable object and if obj can be shareable
    object if it is frozen, then freeze obj. If obj has reachable
    objects (rs), do rs.each{|o| Ractor.make_shareable(o)}
    recursively (recursion is not Ruby-level, but C-level).
(3) Otherwise, raise Ractor::Error. Now T_DATA is not a shareable
    object even if the object is frozen.

If the method finished without error, given obj is marked as
a sharable object.

To allow makng a shareable frozen T_DATA object, then set
`RUBY_TYPED_FROZEN_SHAREABLE` as type->flags. On default,
this flag is not set. It means user defined T_DATA objects are
not allowed to become shareable objects when it is frozen.

You can make any object  shareable by setting FL_SHAREABLE flag,
so if you know that the T_DATA object is shareable (== thread-safe),
set this flag, at creation time for example. `Ractor` object is one
example, which is not a frozen, but a shareable object.
remove rb_obj_iv_index_tbl 2020-10-16T23:18:04+00:00 Koichi Sasada ko1@atdot.net 2020-10-14T07:59:31+00:00 91ec5f9e39cf54dd7a157addb778293853571f13 (1) nobody uses it (gem-codesearch) (2) the data strucuture will be changed. 
(1) nobody uses it (gem-codesearch)
(2) the data strucuture will be changed.
ROBJECT_IV_INDEX_TBL: convert into an inline function 2020-08-19T05:30:57+00:00 卜部昌平 shyouhei@ruby-lang.org 2020-08-17T04:51:23+00:00 6649677eb93a101a5411a942ca1b84b541262537 Former ROBJECT_IV_INDEX_TBL macro included RCLASS_IV_INDEX_TBL, which is not disclosed to extension libraies. The macro was kind of broken. Why not just deprecate it, and convert the internal use into an inline function. 
Former ROBJECT_IV_INDEX_TBL macro included RCLASS_IV_INDEX_TBL, which is
not disclosed to extension libraies.  The macro was kind of broken.  Why
not just deprecate it, and convert the internal use into an inline
function.
RARRAY_AREF: convert into an inline function 2020-08-15T03:09:26+00:00 卜部昌平 shyouhei@ruby-lang.org 2020-08-14T05:45:23+00:00 ff30358d13d24d8202f2717c43700be70bdd49d3 RARRAY_AREF has been a macro for reasons. We might not be able to change that for public APIs, but why not relax the situation internally to make it an inline function. 
RARRAY_AREF has been a macro for reasons.  We might not be able to
change that for public APIs, but why not relax the situation internally
to make it an inline function.
Use RUBY_DEBUG instead of NDEBUG 2020-05-25T18:21:14+00:00 Koichi Sasada ko1@atdot.net 2020-05-20T02:38:44+00:00 21991e6ca59274e41a472b5256bd3245f6596c90 Assertions in header files slows down an interpreter, so they should be turned off by default (simple `make`). To enable them, define a macro `RUBY_DEBUG=1` (e.g. `make cppflags=-DRUBY_DEBUG` or use `#define` at the very beggining of the file. Note that even if `NDEBUG=1` is defined, `RUBY_DEBUG=1` enables all assertions. [Feature #16837] related: https://github.com/ruby/ruby/pull/3120 `assert()` lines in MRI *.c is not disabled even if `RUBY_DEBUG=0` and it can be disabled with `NDEBUG=1`. So please consider to use `RUBY_ASSERT()` if you want to disable them when `RUBY_DEBUG=0`. 
Assertions in header files slows down an interpreter, so they should be
turned off by default (simple `make`). To enable them, define a macro
`RUBY_DEBUG=1` (e.g. `make cppflags=-DRUBY_DEBUG` or use `#define` at
the very beggining of the file. Note that even if `NDEBUG=1` is defined,
`RUBY_DEBUG=1` enables all assertions.
[Feature #16837]
related: https://github.com/ruby/ruby/pull/3120

`assert()` lines in MRI *.c is not disabled even if `RUBY_DEBUG=0` and
it can be disabled with `NDEBUG=1`. So please consider to use
`RUBY_ASSERT()` if you want to disable them when `RUBY_DEBUG=0`.
sed -i 's|ruby/impl|ruby/internal|' 2020-05-11T00:24:08+00:00 卜部昌平 shyouhei@ruby-lang.org 2020-05-08T09:31:09+00:00 9e41a75255d15765648279629fd3134cae076398 To fix build failures. 
To fix build failures.
mv include/ruby/{impl,internal} 2020-05-11T00:24:08+00:00 卜部昌平 shyouhei@ruby-lang.org 2020-05-08T09:10:13+00:00 b85fd1d690b65efaa126cf9c24da73f31eee7a4e Devs do not love "impl". 
Devs do not love "impl".