[sage-support] Re: Doctested all of Sage, four doctests timed out—anything to be concerned about?
On Saturday, July 15, 2017 at 2:00:20 AM UTC+1, Christopher Phoenix wrote: > > Thanks for the answer! :) I'll try re-running the timed-out tests > separately later (tonight, maybe). Right now I'm busy working through the > tuts. > I'm not sure if the tests were running in parallel or not (I just ran > ./sage --testall in the sage directory), but it was pretty busy for quite > some hours. I'll see what happens when I run the tests separately. > you can use a command like "top" in a separate shell to see what's going on on the machine, how many CPUs are occupied and with what. > > On Friday, July 14, 2017 at 4:40:35 PM UTC-7, Dima Pasechnik wrote: >> >> Indeed, only failed tests are listed in this summary at the end. You can >> see the full tests logs in logs/ subdirectory. >> You might re-run these (timed out) tests separately. However, it's not >> uncommon to see these, in particular if you run tests in parallel on a >> loaded machine. >> >> On Friday, July 14, 2017 at 8:52:30 PM UTC+1, Christopher Phoenix wrote: >>> >>> I just ran ./sage --testall to test my new build of Sage like the >>> installation guide recommended. It took over six hours on my hardware >>> (Lenovo Thinkpad 11e, Intel Celeron N2940, 4 gb ram, 500 gb hdd). When the >>> tests finished, four doctests were listed as having timed out. >>> >>> sage -t local/lib/python2.7/site-packages/sagenb/testing/tests/ >>> test_worksheet_list.py >>> [0 tests, 0.19 s] >>> -- >>> sage -t src/sage/manifolds/differentiable/tensorfield.py # Timed out >>> sage -t src/sage/manifolds/differentiable/metric.py # Timed out >>> sage -t src/sage/manifolds/differentiable/affine_connection.py # Timed >>> out >>> sage -t src/sage/misc/temporary_file.py # Timed out after testing >>> finished >>> -- >>> Total time for all tests: 22027.6 seconds >>> cpu time: 17542.6 seconds >>> cumulative wall time: 20277.6 seconds >>> >>> I guess that's not to many considering the size of the Sage library, but >>> is it anything to be concerned about? Should I run the tests again on them? >>> Also, I'm assuming Sage only lists tests that failed or timed out. The >>> output doesn't say anything about the tests that succeeded, but it ran >>> through the rest of them without complaint. Is this the case? Since Sage >>> lists these as having "timed out", I'm guessing that testing timed out on >>> them after they took too long, but didn't get to run through to a failure. >>> >>> Partway through testing, Ubuntu reported that my system's gdb had >>> unexpectedly quit, so perhaps that had something to do with one or some of >>> these time-outs. >>> >> -- You received this message because you are subscribed to the Google Groups "sage-support" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-support+unsubscr...@googlegroups.com. To post to this group, send email to sage-support@googlegroups.com. Visit this group at https://groups.google.com/group/sage-support. For more options, visit https://groups.google.com/d/optout.
[sage-support] How solve simple log equation?
This does not solve...
var("y C")
solve( log(y) == C + log(x) + log(y-1),y)
It returns
[log(y) == C + log(x) + log(y - 1)]
Any ideas?
Thanks!
Chris
--
You received this message because you are subscribed to the Google Groups
"sage-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-support+unsubscr...@googlegroups.com.
To post to this group, send email to sage-support@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-support.
For more options, visit https://groups.google.com/d/optout.
[sage-support] Re: Error building Sage on Ubuntu Mate 16.04 LTS
Thanks for the reply. I actually double-posted this, thinking that my first post was eaten (not having read that the posts from new members are held for moderation). Someone linked a discussion on sage-devel touching on the CPU detection issue. I think the OpenBLAS build issue is an up-stream issue regarding CPU detection. I indeed set OPENBLAS_CONFIGURE="TARGET=ATOM" on my second attempt at building Sage, and it worked just fine. Just finished testing the installation yesterday. Three doctests timed-out but all the rest run a-ok, so I consider that a win. :-) I wanted to try building a package from source, so I'm happy that I took this route. But having done it, I'd definitely recommend the pre-built binaries to anyone who isn't fairly familiar with the terminal. And it can take a long time. On my fairly modest hardware, it took over 4 hours to build Sage. Running all the doctests took several hours more. I'd definitely do it again, though! On Thursday, July 13, 2017 at 4:51:23 PM UTC-7, David Lowry-Duda wrote: > > Hello! > > Firstly, if you are just trying to try Sagemath, you might consider > installing a pre-built binary. See for instance: > http://doc.sagemath.org/html/en/installation/binary.html > The first time I tried sage, I used a prebuilt binary on Ubuntu, and that > worked very well for me. > > Concerning OpenBLAS, you might try to enter the following command in the > same terminal in which you are building sage. > > export OPENBLAS_CONFIGURE="TARGET=ATOM" > > This resolved the problem as reported in this other thread: > https://groups.google.com/forum/#!topic/sage-devel/zQsZsivts0I > > Good luck! > > > On Wednesday, July 12, 2017 at 9:12:18 PM UTC-4, Christopher Phoenix wrote: >> >> I got an error building Sage due to a package failing to be built. I have >> a Lenovo Thinkpad 11e running Ubuntu Mate 16.04 LTS. Before beginning the >> build, I checked that I had all the dependencies and suggested packages >> installed beforehand. Then I pulled the code in through git and ran `make`. >> I set `MAKE='make -j5 -l4` to make the process a bit faster, since my cpu >> has 4 physical cores. Make ran for about 45 minutes or so before it stopped >> and reported this error: >> >> Error building Sage. >> >> The following package(s) may have failed to build (not necessarily >> during this run of 'make all'): >> >> * package: openblas-0.2.19.p0 >> log file: /home/christopher/sagemath/sage/logs/pkgs/openblas-0.2. >> 19.p0.log >> build directory: /home/christopher/sagemath/sage/local/var/tmp/sage/ >> build/openblas-0.2.19.p0 >> >> So I checked the log file and found a list of errors. The log reports >> that detecting the CPU failed and instructs me to set my cpu target >> explicitly. >> >> make[3]: *** [getarch_2nd] Error 1 >> Makefile:123: *** OpenBLAS: Detecting CPU failed. Please set TARGET >> explicitly, >> e.g. make TARGET=your_cpu_target. Please read README for the detail.. >> Stop. >> make[3]: Leaving directory >> '/home/christopher/sagemath/sage/local/var/tmp/sage/build/openblas-0.2.19.p0/src' >> Error building OpenBLAS >> >> Above this I found a bunch of errors prefaced by `getarch_2nd.c`. To >> inexperienced me this looks consistent with what the log report said. It >> looks fixable, but this is my first time installing anything from source >> and I'm not entirely sure how to proceed. I'm guessing I have to set the >> TARGET env variable to my CPU manually for OpenBLAS, but still a bit hazy >> on how to do that! >> >> My cpu is an Intel Celeron N2940 with 4 cores and a base clock of 1.83 >> Ghz, inxi reports this: >> >> me@thinkpad11e:~$ inxi -C >> CPU: Quad core Intel Celeron N2940 (-MCP-) cache: 1024 KB >>clock speeds: max: 2249 MHz 1: 1140 MHz 2: 1569 MHz 3: 2245 >> MHz 4: 2247 MHz >> >> Hope we can get this figured out soon! I'm eager to try Sagemath. >> > -- You received this message because you are subscribed to the Google Groups "sage-support" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-support+unsubscr...@googlegroups.com. To post to this group, send email to sage-support@googlegroups.com. Visit this group at https://groups.google.com/group/sage-support. For more options, visit https://groups.google.com/d/optout.
