Implement methods of `Set`

[seven1m]

Our main approach is to work on one spec from ruby/spec at a time, implementing as much of the spec as possible, then check it off the list:

• [x] add_spec.rb
• [x] append_spec.rb
• [x] case_compare_spec.rb
• [x] case_equality_spec.rb
• [x] classify_spec.rb
• [x] clear_spec.rb
• [x] collect_spec.rb
• [x] compare_by_identity_spec.rb
• [x] comparison_spec.rb
• [x] constructor_spec.rb
• [x] delete_if_spec.rb
• [x] delete_spec.rb
• [x] difference_spec.rb
• [x] disjoint_spec.rb
• [x] divide_spec.rb
• [x] each_spec.rb
• [x] empty_spec.rb
• [x] eql_spec.rb
• [x] equal_value_spec.rb
• [x] exclusion_spec.rb
• [x] filter_spec.rb
• [x] flatten_merge_spec.rb
• [x] flatten_spec.rb
• [x] hash_spec.rb
• [x] include_spec.rb
• [x] initialize_clone_spec.rb
• [x] initialize_spec.rb
• [x] inspect_spec.rb
• [x] intersect_spec.rb
• [x] intersection_spec.rb
• [x] join_spec.rb
• [x] keep_if_spec.rb
• [x] length_spec.rb
• [x] map_spec.rb
• [x] member_spec.rb
• [x] merge_spec.rb
• [x] minus_spec.rb
• [x] plus_spec.rb
• [ ] pretty_print_cycle_spec.rb
• [x] pretty_print_spec.rb
• [x] proper_subset_spec.rb
• [x] proper_superset_spec.rb
• [x] reject_spec.rb
• [x] replace_spec.rb
• [x] select_spec.rb
• [x] size_spec.rb
• [x] subset_spec.rb
• [x] subtract_spec.rb
• [x] superset_spec.rb
• [x] to_a_spec.rb
• [x] to_s_spec.rb
• [x] union_spec.rb

[nanobowers]

Hi @seven1m
For things in "library" (as opposed to core) that are implemented in ruby for MRI (and JRuby and probably other implementations) it seems like once Natalie "core" was implemented enough then Natalie could also compile those existing libraries as Ruby code (for things like mkmf, set, shellwords, getoptlong, and probably a dozen others). Some Ruby libraries that are part of MRI and JRuby are presumably written in C/Java so obviously those would be eventually natively developed for Natalie to get to full Ruby spec compatibility.

Is part of the goal of Natalie to independently implement all of the non-core ruby library as well?

[seven1m]

Is part of the goal of Natalie to independently implement all of the non-core ruby library as well?

I think the word "goal" implies there is a "plan." 😆

When I started working on this project, my goal was to have fun. That is still my goal. And I hope that is the goal of anyone who has come along to help out with the project. (I've seen your work, and I would venture a guess that you are having fun. 🤗)

I made justforfunnoreally.dev as a sort of counter to what I have seen regularly from certain people who stumble upon Natalie and demand I tell them why it's better/faster/safer and (implied) why I have the right to make such claims (that they demand I make).

My response is still, after a number of years: "I do it for fun!"

Anyway, to get to the point, I don't have a plan or roadmap other than: "Are we still having fun?"

In practical terms, I think it would be fun to implement the Set class, because I want to know how it works. My implementation of Set may be slower, worse in every way, but I still want to do it anyway. 😂

That's not to say we might scrap the whole thing and redo it in a better way a year from now. Or we might import set.rb from MRI. (Though, honestly I didn't even look in MRI's source to see if it's implemented in pure Ruby, as that kinda ruins some of the fun for me. I'd like to first see if we can do it without taking a peak at MRI's source. I admit that could be seen as vain, but I still think it's just plain fun.)

I started working on lib/json.rb because I wanted to know how to make a JSON parser. That was some of the most fun I've had!

As for mkmf, shellwords, etc., I don't feel particularly strong about any of those. If someone thinks working on one of those libraries sounds like fun, I am thrilled for that person to work on it in a way that they see fit. If they want to implement from scratch, cool! If they want to import code from MRI, I don't think I would reject such a contribution (though we just have to be careful about keeping copyright and license info denoted and clear if we do that).

I've babbled enough. I'll just end with... "are we still having fun?" 🤗

[nanobowers]

I'm certainly having fun and like to learn new things - thanks for the weblink to justforfunnoreally.dev. When I started learning Crystal, I worked on porting some Ruby. I started with some things I was familiar with, then did some other gems I had never even used before but wanted to learn how they worked and try re-imagining on a similar but different platform. I doubt anyone has ever used them and maybe never will and that's fine with me. I also have a trail of half-finished and abandoned things too, and I expect most that write code as a hobby do too. Nearly all of those projects have been self-initiated, self-completed projects and so project vision is whatever I wanted it to be. Other things I've contributed to have been more established and the unfortunately the barrier to contributing was pretty high.

Working with this project has been great (for me) because there is so much to work on and everyone has been really helpful and accommodating. Also I was never that great at C++ and am a long time out of practice so it felt like a good place to learn and also hopefully be helpful. At this point in this project there are still so many interesting topics to work on sometimes it's hard to decide what to do next! If the project has specific goals I can help with then I'd prefer to align with those. I'll also admit to being overly interested in the gamification aspect of the "Is Natalie Ruby yet?" graph and the potential of one day having a mostly compatible Ruby that compiles to C++.

Sorry if I ruined any excitement by mentioning Set was implemented in Ruby, let's carry on with the fun.

[seven1m]

No fun was harmed in this process! 😃

[herwinw]

Also, because this is pure Ruby this part is very suitable for a first time committer or people who want to help out but don't know C++

[rubyFeedback]

As for mkmf, shellwords, etc., I don't feel particularly strong about any of those. If someone thinks working on one of those libraries sounds like fun, I am thrilled for that person to work on it in a way that they see fit.

I don't care about shellwords, but mkmf may be important for some ruby-addons. For instance, there is libui-ng and the ruby libui-bindings maintained by kojix2 here:

https://github.com/kojix2/LibUI

It would be great if natalie could support LibUI one day. No idea if mkmf is important for that, probably not. That way we could use the Natalie implementation and also have a GUI.

(The bindings he maintains are not that complicated, see here at: https://github.com/kojix2/LibUI/blob/main/lib/libui/ffi.rb; but fiddle is important. No idea if Natalie supports fiddle, if not then I think it may be useful to add support for fiddle, at the least so that the basic things can work. Fiddle is probably not part of the ruby spec, but it is used in quite a few projects and gives us more options to relate to existing C/C++ libraries as-is.)

[herwinw]

The only spec left is pretty_print_cycle_spec.rb, which seems a bit pointless to implement without a pretty printer. I would say we can close this case