`const` removed in `convertElement`

[patleb]

It's not possible anymore to call const methods when using std::variant for example. Wouldn't having an overloaded convertElement be better?

* I'm using the latest commit b66d551

[cfis]

Maybe? The problem I have been trying to solve is supporting RValues, and those can't be const - see 10d9b95.

Let's add a test case that takes a const variant and get it to work.

[patleb]

Understood. Otherwise, may I suggest starting to use ruby tests instead of directly into C++? The reasons being that every suite need to be compiled separately (which is quite long), it doesn't reflect how the library is used in Ruby (first thing coming to mind is that real usage doesn't start a Ruby VM for every test... I may be wrong about this though) and you wouldn't catch GC bugs for longer tests.

[cfis]

Ok, const std::variant should now work. What does not work is std::variant<const xyx>. So at least a step forward hopefully - will close this ticket.

As far as Ruby tests - the Ruby VM is only spun up once per test run. You can definitely catch GC bugs - notice all the GC start calls in the test suite to force the issue. And having a single executable, unittest, makes debugging easier.

There were a few tests that created a shared library, and then ruby loaded that library (so how you would use Rice in the "real" world). But they were very minimal and not maintained so I recently removed them.

[patleb]

Thx, yup, you're right, I should have stuck to the slowness reason and not adding more reasons that I wasn't sure of... after writing the comment, I was wondering if it was true and moved on instead of just correcting my comment.

Not sure about the easier debugging part. In my code base, I have filters to ignore entire parts of the build so that I don't have to compile everything to develop, test and debug a small part. Not sure Rice could benefit since every suite has a #include <rice/rice.hpp>, but something similar could be done to target specific suites and still compile only once.

Otherwise, I can understand why probably most tests would be easier to write directly in C++ since Rice has low level concerns that couldn't or shouldn't be exposed to Ruby. My point was more about the high level tests for the Ruby side of things... like the ones I'm bringing up in the issues I open. Having tests in Ruby gives you an easy way to use either GDB or Ruby debugger depending on which part you try to debug.