Re: [sage-devel] Re: MacOS build Sage libcurl error for R

2019-06-03 Thread Samuel Lelièvre
Mon 2019-06-03 22:45 UTC, darwin doppelganger: > > By the way, why are we seeing Mac users compiling Sage > for themselves rather than just downloading an executable? > Is it anything to do with the double-clickable Mac application > problem that appeared on Mac OSX 10.4 (Mojave)? One might want

Re: [sage-devel] Re: MacOS build Sage libcurl error for R

2019-06-03 Thread darwin doppelganger
On Monday, June 3, 2019 at 12:15:28 PM UTC-5, Samuel Lelievre wrote: > > ... > Would it make sense to mitigate this frequent source of problems > for Sage users by detecting the presence of Anaconda and issuing > a helpful message indicating Anaconda was detected and it being > in the PATH is

Re: [sage-devel] Polyhedron -- make constructions respect backend

2019-06-03 Thread Vincent Delecroix
To my mind: * backend and base ring should be preserved by default. Of course it should make sense: a translation by sqrt(2) would break the base ring QQ. * no need to create one ticket for each method if this is mostly the same action to be done for each of them. If some method

[sage-devel] Re: error building sage for Scientific Linux 7.6

2019-06-03 Thread Charles Campbell
Hello: I do have a skylake architecture (10-core, i9-7900X), and the assembler is as: GNU assembler version 2.27-34.base.el7. Unfortunately make -j1 openblas also gave the same error message. I tried ./configure with_blas=atlas, and got: a new error! (that seems like an improvement,

[sage-devel] Polyhedron -- make constructions respect backend

2019-06-03 Thread 'Jonathan Kliem' via sage-devel
At the moment the backend setting is lost, when constructing a pyramid of a Polyhedron. Same holds for all other constructions. I think that all constructions should respect the backend of self. I intend to create tickets (one by one) for each construction in Polyhedron_base (that gives a new

Re: [sage-devel] Re: MacOS build Sage libcurl error for R

2019-06-03 Thread Samuel Lelievre
Mon 2019-06-01 06:20:39 UTC, E. Madison Bray: > > On Sun, Jun 2, 2019 at 11:46 PM darwin doppelganger: > > > > I responded to a similar posting with a link to directions > > for removing anaconda. It seems to have worked just fine, > > but Dima's suggestion sounds easier. > > One thing I've

Re: [sage-devel] Re: compiling error for 8.8.beta6 on Red Hat 6.10

2019-06-03 Thread Christian Stump
It appears that it is not an issue of this particular old system as Matthias pointed out. I would appreciate further help at https://trac.sagemath.org/ticket/27907 to figure out how to provide the correct version of [gcc-7.2.0] /usr/lib/../lib/crti.o: could not read symbols: File in wrong

Re: [sage-devel] Re: error building sage for Scientific Linux 7.6

2019-06-03 Thread Dima Pasechnik
On Mon, 3 Jun 2019 at 08:41, E. Madison Bray wrote: > Well, this would be a problem building OpenBLAS specifically :) > > I see this same problem mentioned here as well. Maybe it will help: > https://github.com/JuliaLang/julia/issues/30696 > > I'm not sure I understand the patch on that issue

Re: [sage-devel] Re: error building sage for Scientific Linux 7.6

2019-06-03 Thread E. Madison Bray
Well, this would be a problem building OpenBLAS specifically :) I see this same problem mentioned here as well. Maybe it will help: https://github.com/JuliaLang/julia/issues/30696 I'm not sure I understand the patch on that issue that mentions cross-compiling to a 32-bit architecture. You're

Re: [sage-devel] Continuous benchmarking

2019-06-03 Thread E. Madison Bray
On Sat, Jun 1, 2019 at 12:28 PM Volker Braun wrote: > > Any kind of shared cpu container solution like openstack is also going to be > unsuitable for benchmarking, I think. There is going to be lots of background > stuff that the test process has no control / visibility of. Yes-and-no. It

Re: [sage-devel] Re: MacOS build Sage libcurl error for R

2019-06-03 Thread E. Madison Bray
On Sun, Jun 2, 2019 at 11:46 PM darwin doppelganger wrote: > > I responded to a similar posting with a link to directions for removing > anaconda. It seems to have worked just fine, but Dima's suggestion sounds > easier. One thing I've noticed a lot of Anaconda users don't realize or