GSoC Project: Ruby bindings to the CSymPy C++ symbolic library

[Abinash Meher]

Hello,

I came across this project idea from the thread on the mailing list. The idea of two organisations coming together to realise the project makes me love Open-Source even more! I am very interested in contributing to this project as a part of this year's GSoC. I am very comfortable with C++ and only know the basics of Ruby, for which I am working on it to become more proficient.

I have already setup csympy on my system, with the help of a friend who has contributed to csympy. I have started exploring the code. Since I don't know how to write Ruby extensions or wrappers yet, I am referring to the following links.
1. https://www.amberbit.com/blog/2014/6/12/calling-c-cpp-from-ruby/
2. http://www.rubyinside.com/how-to-create-a-ruby-extension-in-c-in-under-5-minutes-100.html

Regarding the discussion what to use to write Ruby wrappers, the first link has benchmarked results for Ruby Inline, Rice and FFI. Also, Shogun (Machine Learning Toolbox) uses SWIG to interface to many languages, including Ruby. We can consider SWIG too.

I want to get started as early as possible. Please guide me as to how to go about it. Looking forward to your reply.
 

Regards,

Abinash Meher

[Ondřej Čertík]

Hi Abinash,

Thanks for the interest!

I'll be happy to help if you have any questions regarding the csympy
code. As to the wrappers, John, what would you recommend as the best
way forward?

Ondrej

[John Woods]

I think FFI or manual should be used. If you're dealing with a lot of pointers, you're almost certainly going to want to use the manual method — you end up having to do just as much work in Ruby, but the code is clearer in C.

--
You received this message because you are subscribed to the Google Groups "SciRuby Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sciruby-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Abinash Meher]

Hi John,

It would be very helpful if you could please redirect me to some of the wrapper code that you have already written manually, which you mentioned in the earlier thread. I can learn a lot from it.

Regards,

Abinash Meher

[John Woods]

Sure. For sake of comparison, here is some FFI code I wrote:
https://github.com/mariusmuja/flann/tree/master/src/ruby

And here's a bit of pure C code integrated manually:

https://github.com/marcottelab/boolean/tree/master/ext/hypergeometric

For some more complicated C/C++ Ruby integration, check out nmatrix (specifically the ext/nmatrix directory).

John

[Abinash Meher]

Thanks! :) I am on it.

Regards,

Abinash Meher

[Abinash Meher]

Hi John,

Seems like I am not able to access the second link
https://github.com/marcottelab/boolean/tree/master/ext/hypergeometric

It shows a 404 error. Could you please look into it?

Regards,

Abinash Meher

[John Woods]

Oh, rats. I forgot that repo is private.

Here you go, no harm in showing the C parts:

https://gist.github.com/mohawkjohn/c0cd0f57c4bcee78db6d

[Ondřej Čertík]

On Thu, Mar 5, 2015 at 2:46 PM, John Woods <john.o...@gmail.com> wrote:
> Oh, rats. I forgot that repo is private.
>
> Here you go, no harm in showing the C parts:
>
> https://gist.github.com/mohawkjohn/c0cd0f57c4bcee78db6d

Thanks! I think we should use the manual C way for sure. The advantage
is that it is compiled, so we immediately get a compile error on
Travis if we change an interface in CSymPy, so we know we have to fix
it. While with the FFI method, I assume you get a segfault at runtime
while running Ruby tests (those we have to add either way to make sure
it works).

John, last question --- is it better practice to have the wrappers as
a C code (in this case we'll wrap our C wrappers:
https://github.com/sympy/csympy/blob/7585503c149e1e8c766cca3a7a21cce300ea74dd/src/cwrapper.h,
we'll have to extend them to cover all C++ functionality), or can the
C Ruby wrapper actually be a .cpp file, and thus we can call any C++
from it?

Ondrej

[John Woods]

Excellent point about compiler errors. Hadn't thought of that, but it's definitely a reason to prefer the manual approach — yes, FFI will only give you segfaults.

With respect to your last question, Ruby can't interact with mangled C++ function names, so you have to expose them with an extern "C" {} block and some C functions. NMatrix is a good example of this sort of code.

So, yes, you can use a C++ compiler to compile your Ruby extensions — and yes, you can have them in .cpp files. Only in one case in NMatrix did we store code separately in a .c file, and even then I believe it's compiled by the C++ compiler.

John

[Ondřej Čertík]

On Thu, Mar 5, 2015 at 3:11 PM, John Woods <john.o...@gmail.com> wrote:
> Excellent point about compiler errors. Hadn't thought of that, but it's
> definitely a reason to prefer the manual approach — yes, FFI will only give
> you segfaults.
>
> With respect to your last question, Ruby can't interact with mangled C++
> function names, so you have to expose them with an extern "C" {} block and
> some C functions. NMatrix is a good example of this sort of code.
>
> So, yes, you can use a C++ compiler to compile your Ruby extensions — and
> yes, you can have them in .cpp files. Only in one case in NMatrix did we
> store code separately in a .c file, and even then I believe it's compiled by
> the C++ compiler.

Thanks for the tips. Then I think the best way is to use C++ to
compile the Ruby wrappers, with extern "C" of course. Here is the
nmatrix code that you mentioned:

https://github.com/SciRuby/nmatrix/blob/b25f494f6272f01029e45fedbe18da16587f1000/ext/nmatrix/nmatrix.cpp

Here is the C file:

https://github.com/SciRuby/nmatrix/blob/b25f494f6272f01029e45fedbe18da16587f1000/ext/nmatrix/ruby_nmatrix.c

Which indeed is a compiled with a C++ compiler --- I think it has to
be, as it is using C++ templates.

Ondrej

[Abinash Meher]

Hi Ondřej and John,

I came to know that I need to send a patch to be eligible to be considered for a project. If that's the case, where do I need to contribute? CSymPy or SciRuby ? Also for the application, I need to follow the SciRuby's application template, right?

Regards,

Abinash Meher

[John Woods]

Hi Abinash,

This is a good question. As for contributions, we'll honor one to CSymPy, if it is a patch that makes Ondřej happy. =)

Ondřej, what do you think? We don't know slot allocations yet, so I'm not quite sure how to handle it — but probably more appropriate to include in SciRuby than CSymPy's GSoC allocation, yes?

John

--
You received this message because you are subscribed to the Google Groups "SciRuby Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sciruby-dev...@googlegroups.com.

[Ondřej Čertík]

Hi John,

On Sun, Mar 8, 2015 at 11:45 AM, John Woods <john.o...@gmail.com> wrote:
> Hi Abinash,
>
> This is a good question. As for contributions, we'll honor one to CSymPy, if
> it is a patch that makes Ondřej happy. =)
>
> Ondřej, what do you think?

Either is fine with me --- we also have a patch requirement,
essentially just to show that the student knows how to use the tools
and communicate with the community (e.g. respond to reviews etc.) and
manage to get a patch merged.

> We don't know slot allocations yet, so I'm not
> quite sure how to handle it — but probably more appropriate to include in
> SciRuby than CSymPy's GSoC allocation, yes?

SymPy didn't get in as an organization this year, so we are part of
Python Software Foundation this year. Few other organizations also
said they would consider our applications, so if SciRuby couldn't host
it, I could ask them. I was hoping SciRuby could host this, and then
the patch I think should go to SciRuby.

Ondrej

[John Woods]

Sorry to hear you all didn't make it into GSoC. =( Now I understand a little better though — consider this adopted by us. =)

So, yes, patch requirement is for SciRuby, and application should be SciRuby's as well.

Cheers,

John

[Abinash Meher]

Please correct me if I am wrong, the ruby wrappers go to the csympy repository, right? There was this discussion where Ondrej had mentioned how the wrappers being in cpp files can be checked by travis (that csympy currently uses) for build errors. I was thinking that a proper file structure can be a nice start.

--

[John Woods]

Yes. Have a look at FLANN for an example of such a file structure. You'll need an extconf.rb, as well, for which you might make use of the one in NMatrix as a model.

[Abinash Meher]

Hi John,

Here is the link to the PR, that I have sent for the initial file structure of the ruby wrappers.
https://github.com/sympy/csympy/pull/414#issuecomment-80851699

Looking forward to your comments. :)

Regards,

Abinash Meher