Same for ruby_2_0_0 branch

https://.com/funny-falcon/ruby/compare/ruby_2_0_0...features_index/ruby_2_0_0.diff
https://.com/funny-falcon/ruby/compare/ruby_2_0_0...features_index/ruby_2_0_0

I've changed implementation a bit:
Because https://bugs.ruby-lang.org/issues/12142 likely to be accepted,
I've used st_table with numtable instead of separate datastructure.

So now is shorter.
https://bugs.ruby-lang.org/attachments/download/6182/0001-load.c-reduce-memory-usage-of-loaded_features_index.

[email protected] wrote:

So now is shorter.
https://bugs.ruby-lang.org/attachments/download/6182/0001-load.c-reduce-memory-usage-of-loaded_features_index.

Thanks; this got broken by trivial whitespace change in r57032

I'm not sure about the portability of initializing structs
with non-const values for some compilers. Maybe usa or
somebody with more portability experience can comment.

Also, in C Ruby; initial indent is 4 spaces, second indent is
hard tab. Not my rule and I hate it; but not much we can do...

Hi,

In message "[ruby-core:78595] Re: [Ruby trunk Feature#8158] lightweight structure for loaded features index"
on Mon, 12 Dec 2016 06:06:13 +0000, [email protected] wrote:

I'm not sure about the portability of initializing structs
with non-const values for some compilers. Maybe usa or
somebody with more portability experience can comment.

It's OK, at least for VC++.

Regards,¶

U.Nakamaura [email protected]

Usaku NAKAMURA wrote:

In message "[ruby-core:78595] Re: [Ruby trunk Feature#8158] lightweight structure for loaded features index"
on Mon, 12 Dec 2016 06:06:13 +0000, [email protected] wrote:

I'm not sure about the portability of initializing structs
with non-const values for some compilers. Maybe usa or
somebody with more portability experience can comment.

It's OK, at least for VC++.

Other compilers fail, IIRC, Solaris, AIX, HP-UX, or something.

I'll fix today.

I've uploaded fixed :
https://bugs.ruby-lang.org/attachments/download/6293/0001-load.c-reduce-memory-usage-of-loaded_features_index.

branch and diff:
https://.com/funny-falcon/ruby/tree/loaded_features_strings
https://.com/ruby/ruby/compare/trunk...funny-falcon:loaded_features_strings.

I've tried to simplify : remove struct feature_str and use just pointer with len.

https://bugs.ruby-lang.org/attachments/download/6295/load.c-loaded_features_numindex.

https://.com/ruby/ruby/compare/trunk...funny-falcon:loaded_features_index.
https://.com/funny-falcon/ruby/tree/loaded_features_index

We looked at this issue at today's developer meeting and had positive opinions. Maybe introduced in 2.5.

The seems OK now. @funny_falcon (Yura Sokolov) do you want to check in by yourself?

Matz.

Matz,

I don't know English enough to clearly understand your suggestion.

Is it suggestion of commit rights?
If it is, it will be a great honor for me.
But I'm not even-tempered person, and I fear I will put a mess into repository if I will have commit rights.

If your suggestion means some-thing else, then may you formulate it in some other words so I can understand?

With regards,
Yura.

Hi Yura,

I think the commit rights here reduce the amount of work for the rest of the Ruby team.

This change is approved and reviewed, so you can commit it directly once you have the rights, no need to make other people do the committing.

Very keen to have this change included in Ruby.

Sam

Year after I think I am more stable person, so I'm going to accept commit rights with gratitude, honor and great responsibility.

But until I passed procedure, I'd be thankful if @tenderlovemaking (Aaron Patterson) will commit this one.

With regards,
Yura.

https://bugs.ruby-lang.org/issues/8158

I am curious, what is the significance of the 0xfea7009e
initializer passed to st_hash?

Would it be appropriate to use for the `st_hash' call in
hash.c::hash_i as well?

Thanks.

@funny_falcon (Yura Sokolov)? Will you be a committer?

Matz.

@matz (Yukihiro Matsumoto) , yes I will.
Excuse me for the delay. I'll try to proceed with steps from CommitterHowto this week.

With regards,
Yura.

normalperson (Eric Wong) wrote:

https://bugs.ruby-lang.org/issues/8158

I am curious, what is the significance of the 0xfea7009e
initializer passed to st_hash?

0xfea7009e - is a "feature" hex-spelled :-) Nothing special.
It could be ommitted, given features are strings without zero bytes.
I put it here just for fun.

Would it be appropriate to use for the `st_hash' call in
hash.c::hash_i as well?

I believe, there's no real needs.

Thanks.

With regards,
Yura.

Hi all.

I did create an account of funny_falcon on svn.ruby-lang.org.