These are chat archives for symengine/symengine

16th
Jun 2015
Isuru Fernando
@isuruf
Jun 16 2015 14:56
@certik, CMake on sage is a big mess. I'm writing wrappers for Sage for symengine right now. How should a user install symengine on sage?
Ondřej Čertík
@certik
Jun 16 2015 14:57
@isuruf is there a problem with CMake on linux in Sage?
Isuru Fernando
@isuruf
Jun 16 2015 14:58
Features that we use are fine. Some of the tests don't succeed.
And it should be fine on OS X systems other than 10.10
Ondřej Čertík
@certik
Jun 16 2015 15:05
Let's make sure SymEngine works 100% on linux in Sage and just make sure SymEngine works 100% on Mac, outside of Sage.
Can you post the failures in Sage on linux?
Can you point to other problems that are "a big mess"?
Isuru Fernando
@isuruf
Jun 16 2015 15:06
OS X 10.10 is the problem. It has a header called dispatch/object.h which gives errors when compiling with gcc
Ondřej Čertík
@certik
Jun 16 2015 15:07
@isuruf that's a known problem. The gcc needs to be patched on OS X and Sage does it.
Are you using Sage's gcc?
Isuru Fernando
@isuruf
Jun 16 2015 15:08
Yes, it is patched on Sage's gcc, but cmake uses a system header (CoreFoundation.h) in OS X and it calls the system header dispatch/object.h
Ondřej Čertík
@certik
Jun 16 2015 15:08
In Hashdist, here is the fix that we have to do to make it work on OS X: https://github.com/hashdist/hashstack/blob/9a590dc60a70012bce39e970fd9fcda3ea3daa16/pkgs/gcc/gcc.yaml#L30, Sage uses a similar fix.
Isuru Fernando
@isuruf
Jun 16 2015 15:09
Yes, both fixes are the same
Ondřej Čertík
@certik
Jun 16 2015 15:10
So in my experiments, the patched gcc seems to prefer its own dispatch/object.h over the system wide.
You are saying that there is a case, when it still prefers the system one?
Isuru Fernando
@isuruf
Jun 16 2015 15:10
Yes
Ondřej Čertík
@certik
Jun 16 2015 15:10
Ok.
So to workaround that, one needs to compile cmake a bit differently. Let me show you how we do it in Hashstack, which works.
Isuru Fernando
@isuruf
Jun 16 2015 15:11
Stacktrace is something like this
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/dispatch/dispatch.h:50:0,
                 from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CFStream.h:15,
                 from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CFPropertyList.h:13,
                 from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h:55,
                 from /usr/local/src/sage/sage/local/var/tmp/sage/build/cmake-3.2.1/src/Source/CPack/OSXScriptLauncher.cxx:17:
Ondřej Čertík
@certik
Jun 16 2015 15:11
Well, that stacktrace doesn't show the actual error.
The trick is to install all the cmake dependencies ourselves, then cmake itself is just a simple C++ code, and it doesn't need the OS X systemwide headers.
Isuru Fernando
@isuruf
Jun 16 2015 15:12
I don't have access to OSX right now, but it was posted here, http://trac.sagemath.org/ticket/18078#comment:10
Ondřej Čertík
@certik
Jun 16 2015 15:13
If I remember well, I think it was the curl dependency that failed. In any case, now the problem is shifted on the dependencies to build on OS X with gcc.
Much easier to tackle and we've tackled it in Hashstack. For example the curl is here: https://github.com/hashdist/hashstack/blob/9a590dc60a70012bce39e970fd9fcda3ea3daa16/pkgs/curl.yaml, it's very straightforward. I think the trick is to use a new version of curl, which fixes all these OS X issues. I think CMake itself ships with an older version which doesn't compile.
So we should do the same in Sage, then there is no problem. Is there any other problem besides this one?
Isuru Fernando
@isuruf
Jun 16 2015 15:15
I tried building curl first, but it doesn't make a difference
Ondřej Čertík
@certik
Jun 16 2015 15:15
Post the full build log for cmake as well as the build script.
Isuru Fernando
@isuruf
Jun 16 2015 15:17
I'm using a friend's Mac, so I'll post the build log tomorrow.
Ondřej Čertík
@certik
Jun 16 2015 15:22
Btw, when you copy a line from github, you can press "y", which will put the last commit hash into the address, that way the link stays forever valid. If you post master, then if somebody pushes to master, it can shift or delete the line that you point to.
The build script looks good.
Sumith Kulal
@Sumith1896
Jun 16 2015 15:28
@certik I have a couple of questions too, once you are done with @isuruf
Isuru Fernando
@isuruf
Jun 16 2015 15:30
@certik, it tries to compile this file, https://github.com/Kitware/CMake/blob/master/Source/CPack/OSXScriptLauncher.cxx
which has CoreFoundation.h which in turn calls dispatch/object.h
Thanks for the tip, I didn't know how to make the link permanent
Ondřej Čertík
@certik
Jun 16 2015 15:34
@Sumith1896 you can ask now.
@isuruf I see. Just patch the cmake source code and comment out the two lines:
  add_executable(OSXScriptLauncher
    CPack/OSXScriptLauncher.cxx)
(and probably a few more related lines)
Sumith Kulal
@Sumith1896
Jun 16 2015 15:35
Regarding the next todos, I read this article you gave here which says about hashtables
Ondřej Čertík
@certik
Jun 16 2015 15:36
@Sumith1896 So I would suggest to first try to use the piranha::hash_set.
That way we should (hopefully) be able to match Piranha's speed.
Only then we can play with other libraries and see if they are even faster.
I would keep the code as it is, i.e. you have std::unordered_map, and then I would convert it to piranha::hash_set, before you benchmark it. Then I would write a new poly_mul routine, which works with piranha::hash_set and only benchmark that.
Sumith Kulal
@Sumith1896
Jun 16 2015 15:40
Why is there a need of new poly_mul routine?
Ondřej Čertík
@certik
Jun 16 2015 15:41
Because your current routine works with std::unordered_map, and we want to try piranha::hash_set. So you need to change the arguments and perhaps change the syntax in the loop a bit.
This is just for your PR, to make it easy to try it out.
Sumith Kulal
@Sumith1896
Jun 16 2015 15:42
So that we can try out both in the same PR?
Ondřej Čertík
@certik
Jun 16 2015 15:43
I just thought it would be easier for you.
Sumith Kulal
@Sumith1896
Jun 16 2015 15:43
Okay, I didn't understand at the first go
Now I get you
Thanks, that'll keep me busy @certik
Ondřej Čertík
@certik
Jun 16 2015 15:44
Because Piranha takes a long time to compile, I thought it would be easier to first write some function that takes our std::unordered_map (i.e. machine ints as keys and the piranha::integer as coefficients), and returns piranha::hash_set.
Then you have to write the new poly_mul routine. Once both compile, then you use the first routine in the benchmark, and the new poly_mul. And that's it.
Sumith Kulal
@Sumith1896
Jun 16 2015 15:45
Cool. Thanks.
Ondřej Čertík
@certik
Jun 16 2015 15:45
That's how I would do it. That way you do not need to modify any header files, which trigger full recompilation, which takes forever with any Piranha header in it.
Sumith Kulal
@Sumith1896
Jun 16 2015 15:49
Agreed