These are chat archives for symengine/symengine

11th
Aug 2015
Ondřej Čertík
@certik
Aug 11 2015 15:34
@isuruf I think we should eventually split the Python and Ruby wrappers into separate repositories.
Isuru Fernando
@isuruf
Aug 11 2015 15:36
It'll be hard to keep track of them.
I was thinking of the best way to distribute the python wrappers and I think the best would be to have libsymengine as a dependency and package the python wrappers with the compiled symengine_wrapper.cpp
Ondřej Čertík
@certik
Aug 11 2015 15:36
It will simplify testing a lot I think. SymEngine would be just the C++ library, so we just need to thoroughly test that and not worry about any other language. Then the Python wrappers need to test the various Python versions. One will probably install symengine from source, though one can just as well install a binary on Travis. The only issue is that symengine can be built with debugging or not (that changes the size of RCP), and so one needs to recompile the wrappers.
One can distribute the Python wrappers as binary, but as I said, one needs to be careful to compile the symengine_wrapper.cpp with the same debugging options as the libsymengine.so library.
The point is to figure out a workflow of distributing the SymEngine C++ library properly, so that one can easily use it from Julia wrappers (which are already separate), as well as Python and Ruby wrappers.
Ondřej Čertík
@certik
Aug 11 2015 15:42
I know one can emit some kind of CMake file with the proper configuration that was used for SymEngine, and then one can use it for the wrappers. Or one can just read the symengine/symengine_config.h which is installed among the include files.
Isuru Fernando
@isuruf
Aug 11 2015 15:43
Yeah, a ProjectConfig.cmake would be good
Ondřej Čertík
@certik
Aug 11 2015 15:43
So I guess this config file already has the proper debug options (i.e. if we use Teuchos::RCP or our RCP) and so all that is needed is just to compile the wrappers, and it will do the right thing. The only way it can break is if we install the wrappers, and then recompile the SymEngine library. Then it won't work.
Ultimately, we just want to distribute the Release version as the main thing. It's just that if there is a segfault, we need to be able to recompile with debugging options, so that we can get an exception.
And also for testing, it's good to make sure the Python wrappers tests pass with debugging options on.
Ondřej Čertík
@certik
Aug 11 2015 16:07
@isuruf I agree it sounds like more painful. But even if we keep Python and Ruby inside the symengine git repo, we still need to figure out the workflow for Julia wrappers.
(and any other wrappers that we might write, like Haskell wrappers --- I found a person interested in those)
Isuru Fernando
@isuruf
Aug 11 2015 16:08
For julia, we can have symengine/julia as a submodule
Ondřej Čertík
@certik
Aug 11 2015 16:08
So you would move Julia inside the symengine repository?
Isuru Fernando
@isuruf
Aug 11 2015 16:09
No, keep the Julia repository separate, but have it as a git submodule inside main repo
Like we did with symengine.spkg, where src/ is a git submodule
Ondřej Čertík
@certik
Aug 11 2015 16:45
So you propose to have symengine as a submodule in the Julia wrappers repo, or do you propose to have the Julia wrappers repo as a submodule in the symengine repo?
Isuru Fernando
@isuruf
Aug 11 2015 16:45
second one
Ondřej Čertík
@certik
Aug 11 2015 16:46
What would be the advantage? I see lots of disadvantages, as submodules kind of suck.
Isuru Fernando
@isuruf
Aug 11 2015 16:49
In symengine main repo, we could have a test for it in one or multiple configurations. Since one version of Julia, Python and Ruby are in each of workers, we could test it on symengine main repo so that we know if we have done some breaking changes to the wrappers
In the julia repo, we could test multiple versions of the language
Ondřej Čertík
@certik
Aug 11 2015 16:51
So you can do this check on the main repo even without having the Julia as a submodule. You simply check it out on Travis and install it.
Isuru Fernando
@isuruf
Aug 11 2015 16:52
Yeah, you are right
Ondřej Čertík
@certik
Aug 11 2015 16:52
I think that's a good idea to check every commit with the Python wrappers, just one version, to make sure we didn't break anything.
Isuru Fernando
@isuruf
Aug 11 2015 16:53
One more problem though, when we make such a breaking change, we have to update main repo first, which will be indicated as failed and then update the wrappers
Ondřej Čertík
@certik
Aug 11 2015 16:56
Exactly, I just thought about that as well. I don't know a good solution.
Ondřej Čertík
@certik
Aug 11 2015 17:02
(Guideline 8 and 9)
Isuru Fernando
@isuruf
Aug 11 2015 18:04
@certik, I'm almost done with the PyNumber. What kind of numeric types in SymPy do we not support yet so I can test this
Ondřej Čertík
@certik
Aug 11 2015 18:07
What's a PyNumber?
The numeric types in sympy are mpmath types and then just the Python types, as well as Integer and Rational classes, which we already support.
Isuru Fernando
@isuruf
Aug 11 2015 18:09
The one in my proposal, to support any Python type, something like the FunctionWrapper
Ondřej Čertík
@certik
Aug 11 2015 18:11
So that you can implement a numeric type in Python?
Post a PR, we can discuss the details.
Isuru Fernando
@isuruf
Aug 11 2015 18:12
Ok
Ondřej Čertík
@certik
Aug 11 2015 18:12
I would test it with a custom Python type, a wrapper around an integer for example.
In the tests.
Depending on how you implemented it, if the C++ code doesn't know anything about Python, then we also need a similar custom type in C++, in the tests.
Ondřej Čertík
@certik
Aug 11 2015 23:07
@isuruf we should test the Python wrappers from a separate repository with each commit of the C++ library, but the tests should be in the "can fail" section on Travis. If they fail but our C++ tests don't, it's a sign that our C++ testsuite is not complete, and we need to improve it. The goal is to have a thorough C++ test suite, so that we do not need to test Python wrappers at all. But since life is not perfect, it's good to run the tests, but in the can fail category. That way, if we make a breaking change, we do not need to worry that the tests temporarily break.