-
-
Notifications
You must be signed in to change notification settings - Fork 490
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add M4RIE to Sage #9562
Comments
This comment has been minimized.
This comment has been minimized.
comment:2
The SPKG is here: http://sage.math.washington.edu/home/malb/spkgs/libm4ri-20100730.spkg |
comment:3
The attached patch depends on #9475 |
comment:4
The package compiles on t2. sage-check fails because libstdc++ cannot be found (I believe this is due to a problem in the old Sage I have on t2). I cannot apply my patch against this old version of Sage either. |
comment:5
This builds a static library only on Cygwin, but segfaults on both of the tests. |
comment:6
Mike, is there a Sage I can copy on winxp1? |
comment:7
|
comment:8
Replying to @malb:
There's a Sage 4.5.1 package in /usr/local. |
comment:9
After unpacking that I get
Any ideas? |
comment:10
The updated patch fixes all doctest failures. PS: CCing Minh since I'm touching his code in a potentially non-trivial way/ |
comment:11
It's not passing the tests properly on 64-bit OpenSolaris, and I doubt anywhere where SAGE64 needs to be set to yes. The -m64 flag is not getting passed when running the tests, so whilst it builds a 64-bit library, it looks like it tries to create 32-bit objects and link to that 64-bit library. I have not investigated this in any detail, but they were my initial observations. I would try building on 't2' with SAGE64 set to yes. Not all of Sage will build 64-bit without some hacks, but it should be fairly easy to get enough of Sage built to build this library.
|
comment:12
I updated the SPKG linked above
|
comment:13
Everything works on my Cygwin install. |
comment:14
It passed all self-tests on 64-bit OpenSolaris (x64) and 64-bit Solaris 10 (SPARC). Since neither platform has a stable version of Sage yet, running the doctests is pointless. A few questions:
|
comment:15
Replying to @sagetrac-drkirkby:
No decision on [sage-devel] has happened yet. However, the Sage developers here at Sage Days 24 seem to be in favour of adding it.
It makes maintaining the thing easier for all sides: I'm the maintainer of both libraries for both upstream and the SPKGs. It isn't even decided yet whether the two libraries might get merged in the future. Finally, William asked me to not add a new SPKG but to add the M4RIe extension to the M4RI package.
Yes.
Yes.
Note my point above about not being able to use it.
No clue.
Yes.
Yes. |
comment:16
Replying to @malb:
If the packages does get positive review, there should be a note to the release manager(s) not to merge it until there has been an agreement. Though in this case, it looks like getting a vote seems a formality.
One obvious disadvantage of that approach is that since one library relies on the other, the first could be built in parallel with some other packages. That could potentially slow parallel builds.
Your point above says that's probably because you have an old version. But I said above, there is the latest version on there - (
See point above. Dave |
comment:17
Dave, the testuite fails:
Any idea why it wouldn't find libstdc++ on t2? |
comment:19
These lines:
make me think it's the Sage binary that is broken? Why is there be a libstdc++ in the Sage tarball ? |
comment:20
Replying to @malb:
The reason it is there is that the version of gcc shipped with Solaris is 3.4.3, so there are no recent gcc libraries. The compiler is not built with Fortran support, so there is no libgfortran at all. One needs recent run-time libraries, with fortran support, so I added them to the Sage binary. It may be that deleting (making a copy first) of those .la files will solve the problem. Otherwise, editing them to point at the location of the libraries in $SAGE_LOCAL/lib will almost certainly solve it. If that does not work, just build Sage from source. It does not take too long if you build packages in parallel. Dave |
comment:21
After finally building Sage t2 I can confirm that doctests pass there too |
comment:125
Replying to @malb:
Thank you! The new patch applies cleanly. |
Changed work issues from Rebase wrt #4260 to none |
comment:126
It seems to me that all previous complaints are addressed in the new spkg and patches. In particular, if one has opened the spkg, starts a sage shell and does ./spkg-install, then ./spkg-check works, with all tests. passing. hg status in the spkg is fine, and SPKG.txt looks fine as well (except a typo in the last line, should be "split from", not "split form" - but please leave that error, since the Gods don't like perfection among the mortals :) Moreover, All doc tests pass as well, and I think the original problems with t2 had been dealt with. Thus, I hope all participants agree that it is a positive review! |
comment:127
Replying to @simon-king-jena:
Sollte ich dein Urteil infrage stellen weil du uns für sterblich hältst? |
Merged: sage-4.8.alpha2 |
Changed merged from sage-4.8.alpha2 to none |
comment:131
Reopened because of issues with #4260. |
Merged: sage-4.8.alpha3 |
M4RIE is a library for linear algebra over small extension of GF(2). It is still in an early stage but already offers performance comparable to Magma for many inputs and is more than 1000 times faster than what we have in Sage right now.
Upstream: http://bitbucket.org/malb/m4rie/
Sage Days 24 coding sprint: http://wiki.sagemath.org/days24/projects/gf2e
There was a vote on sage-devel, recommending to add this as a standard spkg.
Depends on #11757
Depends on #4260
CC: @sagetrac-mvngu @simon-king-jena
Component: packages: standard
Keywords: m4ri, sd32
Author: Martin Albrecht
Reviewer: Paul Zimmermann, Simon King
Merged: sage-4.8.alpha3
Issue created by migration from https://trac.sagemath.org/ticket/9562
The text was updated successfully, but these errors were encountered: