dyne2meter's profile - activity

When I tried to build Sage 9.2 on MacOS 10.11 using the (old, old) Xcode tools, numpy built, but building sagelib failed with errors pointing to problems with numpy.

I've succeeded in building 9.2 from the source tarball on OS X 10.11 using a 'minimal' Homebrew installation including gcc, mpfr, mpfi, gsl, libmpc, boost, gmp, and openblas. Homebrew no longer supports Apple systems running OS older than 10.12, but this worked well enough for me to build Sage.

Am I correct in concluding that the only way to duplicate this on a second (bootable) disk or on another computer running the same system is to duplicate this Homebrew setup and then build Sage from source again? The build time using an 8-core MacPro ca. 2008 only took about 90 minutes, but my other system only has a dual-core CPU.

I've read around a little and it seems that including scripts to relocate Sage are no longer viable with Python3. I also realize that I can just wait a few more days and pre-built binaries will be available. Here, I am just trying to understand the build process a little better. I've read about SAGE_ROOT and SAGE_LOCAL environment variables, but have not been able to figure out how to use them to relocate; I'm guessing this strategy is not possible.

The central question, then, is whether I need to install Homebrew everywhere I want to build Sage 9.2. I think so, because that is how the Sage build system finds those tools.

Note on packages in Homebrew: no need to add gsl, or openblas; Sage builds these anyway.

Thanks for this. I am still low on the learning curve with how all the front-end pieces work together. I have run across some info about how to run Sage within a Python session started the same way, but didn't connect it to the same idea in ipython. Truth be told, I don't use ipython (or sage --python) much, so far, and have been concentrating on the Jupyter notebook interface. Getting a handle on the line magics is going to help me at some point in the near future.

So far, I am using the default python and ipython that I get with the built 9.1 system that I download. Another item on my list is upgrading these components using the package manager or whatever it is called, but I will probably just wait for 9.2 and see what I get.

I responded to your more recent post about this. I needed to start the ipython interface to use ipython symbols like this one. I'm using 9.1. I don't know whether %lsmagic was routinely accessible without starting ipython within sage in versions pre-9.1. This could have to do with switching over to Python3, but that's a wild guess on my part.

Yes, I get that response when I issue the command at the standard Sage command line interface.

However if I start Sage with "sage --ipython", I get the ipython interface, and from there, %lsmagic works fine.

I found this answer before finding

https://ask.sagemath.org/question/412...

The answer given at this link notes the updated method name "find_local_minimum/maximum"

See also: Sage Reference Manual on numerical optimization.

I also discovered this name change after following examples in Craig Finch's "Sage Beginner's Guide"

Thanks for your replies! I see that in the binary downloads there is an 8.6 release that is listed for my system, Mac OS X 10.11. That would give me the benefit of subsequent bug fixes.

I must agree that sage-7.6 is an old release, but my hardware is much, much older! I will give it a try on the 8.6 build after I begin to learn something substantive about using Sage -- intro linear algebra is my current study. I will certainly report back, here, if I experience problems beyond doc testing.

I'm inclined immediately to accept your answer, given below. Am I the only one who can do that?

I have just built Sage 7.6 on an Apple iMac 8,1 running OS X version 10.11.6. I started with a download of a compressed source distribution from the Sage github repository (without cloning the repository itself, since I don't plan to contribute any development ideas or comments for awhile). Doctesting went very well, with only two failed tests out of the entire suite:

sage -t src/sage/doctest/test.py  # 1 doctest failed
sage -t src/sage/modules/vector_rational_dense.pyx  # 1 doctest failed

I also downloaded the equivalent binary distribution and doctested that, obtaining these results:

sage -t src/sage/calculus/calculus.py  # 1 doctest failed
sage -t src/sage/doctest/test.py  # 1 doctest failed
sage -t src/sage/graphs/digraph_generators.py  # 3 doctests failed
sage -t src/sage/graphs/graph_generators.py  # 5 doctests failed
sage -t src/sage/graphs/hypergraph_generators.py  # 7 doctests failed
sage -t src/sage/modules/vector_rational_dense.pyx  # 1 doctest failed
sage -t src/sage/tests/cmdline.py  # Timed out after testing finished

I did expect my own build to do better, but the installation I ended up with is fully 2 GB larger than what came in the binary distribution. Much (more than 1/3) of the overage is in a directory

../sage-7.6/local/share/doc/sage/doctrees

which is not present in the binary distribution, and I assume it is only of interest to developers. Is that correct? I will trim my build by also removing two large files

../sage-7.6/src/build/temp.macosx.10.9...
../sage-7.6/src/build/lib.macosx.10.9...

but keep my log and upstream files in case I want to review the build or look at the sources. All this is pending any further advice I get in the next few days about files that are generally only of interest to developers.

Thanks for the encouragement! I ended up (not surprisingly) with lots and lots (maybe 100+) of failed doctests, but much usable python code and a pretty high version of maxima (for the 10.5 platform) and many of the other goodies. I'm going to assume that builders on legacy systems should expect the doctesting problems.

This isn't a question, yet, depending on replies. It's more of a good-news story (for me, anyway). I'm a hobbyist with legacy mac systems and pretty much a newbie with Sage commands per se, and wanted to use the experience to get a better handle on the structure and behavior of the build system. I just hope this adds to the mac build knowledge base for Sage.

I've just successfully built sage-6.10 (downloaded from the git repository) on a mac book 4,1 system with a Core2Duo processor that does not upgrade MacOS beyond Snow Leopard. The total build time was about 8 hours starting with Xcode 3.2. I had difficulties getting started because all my more modern tools are in my macports installation, and I haven't installed upgrades anywhere else --- or so I thought at first. I hit upon including the path to a previous Sage installation which I did some years ago with a binary download of sage-5.13, adding the path to Sage's local/bin. And it worked!

I had one glitch with the installation of flint-2.5.2, when its makefile died with a request to cp -a which happened after:

mkdir -p "./sage-6.10/local/lib"
mkdir -p "./sage-6.10/local/include/flint"

In my os x shell, there is no cp -a and I substituted cp -pPR by using the debug shell for the build system. Everything else went off without a hitch. What a marvelously robust build system this is, given a finicky set of standard mac build tools! Perhaps I should not find it remarkable that I can still do a build like this with a ten-or-more-year-old computer running a 12-year-old OS.

My question is this: I am having trouble locating solid information about which versions of Sage I should try to build for some particular version of the OS. It it just going to be a matter of dedicated experimentation? If so, my experience here tells me I am ready for that.