Re: [sage-devel] No responde to account request.

Usually not that long :( We are not especially well organised I am sorry to say. You will get an account shortly. François > On 9/08/2017, at 19:15, Hilder Vitor Lima Pereira > wrote: > > Hi, > > > I have sent an e-mail to sage-trac-acco...@googlegroups.com asking

Re: [sage-devel] Sage Python 3 proposal

> On 3/06/2017, at 18:04, Ralf Stephan wrote: > > On Friday, June 2, 2017 at 10:48:19 PM UTC+2, François wrote: > Only used by sage. Those are the components linked to it > > Naive questions (maybe irrelevant): Shouldn't it be only libs/pynac > that is linked to libpynac?

Re: [sage-devel] Sage Python 3 proposal

> On 3/06/2017, at 05:28, Nils Bruin wrote: > > On Friday, June 2, 2017 at 2:54:22 AM UTC-6, Ralf Stephan wrote: > No. See > https://stackoverflow.com/questions/44322187/binary-using-both-python-c-api-version-2-and-3 > > But then we need to either build libraries libpynac2 and

Re: [sage-devel] Sage Python 3 proposal

> On 1/06/2017, at 23:27, Kwankyu Lee wrote: > > I also thought about building both py2+3 at the same time, it would be a > great debugging help during the transition if you can easily run both. Then > in 3 years we'll just cut out the py2 part and be done with it... > >

Re: [sage-devel] Sage Python 3 proposal

> On 2/06/2017, at 20:54, Ralf Stephan wrote: > > No. See > https://stackoverflow.com/questions/44322187/binary-using-both-python-c-api-version-2-and-3 So much for that then. This email may be confidential and subject to legal privilege, it may not reflect the views of the

Re: [sage-devel] Sage Python 3 proposal

> On 2/06/2017, at 17:57, Ralf Stephan wrote: > > On Thursday, June 1, 2017 at 12:29:23 PM UTC+2, François wrote: > .. Installing pynac for both python at the same time > means rethinking its packaging. > > As a possible alternative, would avoiding those calls that differ

Re: [sage-devel] Sage Python 3 proposal

I am currently doing a python2+python3 build in sage-on-gentoo. I need none of the hack currently studied for the script, they may end up being counter productive for sage-on-distro, we’ll have to see. Doing a python2+python3 at the same time in the same prefix is challenging because of brial

Re: [sage-devel] python3 : help needed

> On 26/05/2017, at 15:28, Nils Bruin wrote: > > On Thursday, May 25, 2017 at 6:40:18 PM UTC-7, François wrote: > I am a bit surprised you can do that. I have just sent a PR to pynac > a couple of days ago to have it build with python3. > https://github.com/pynac/pynac/pull/248

Re: [sage-devel] python3 : help needed

I am a bit surprised you can do that. I have just sent a PR to pynac a couple of days ago to have it build with python3. https://github.com/pynac/pynac/pull/248 I have a feeling you still a python2 pynac. François > On 25/05/2017, at 20:49, Frédéric Chapoton wrote: > >

Re: [sage-devel] splitting BRiAl

> On 18/05/2017, at 21:37, Jeroen Demeyer <jdeme...@cage.ugent.be> wrote: > > On 2017-05-18 11:25, Francois Bissey wrote: >> Puzzled me for a while too. It doesn’t. > > So you are saying that BRiAl consists of two *independent* parts which don't > interact at all?

Re: [sage-devel] splitting BRiAl

On 18/05/2017, at 21:24, Jeroen Demeyer wrote: > > On 2017-05-18 01:09, François Bissey wrote: >> And I have a pure >> python pybrial that install with a minimal setup.py. > > If it's pure Python, then how does it access the libBRiAl library? > Puzzled me for a while

Re: [sage-devel] cryptominisat 2 -> 5 jump (+ test cmake)

I am confident cmake can now be moved to optional. I took care of all of the problems I could see on OS X and helped with the ones on other platforms. Do we need some kind of vote for moving from experimental to optional? > On 15/05/2017, at 07:19, Dima Pasechnik wrote: > >

Re: [sage-devel] sage on raspberry pi 3 fails to build gcc

Building an old gcc with a newer gcc is not recommended. Can you give us more details (logs) of the failure with ppl instead? François > On 11/05/2017, at 13:44, Brent Thomas wrote: > > I have been trying to install sage on a raspberry pi 3. I didn't find a > binary

Re: [sage-devel] building pdf docs fails

> On 29/04/2017, at 22:14, Francois Bissey <francois.bis...@canterbury.ac.nz> > wrote: > > We could check whether its use has been re-introduced somewhere else after > that A scan on a sphinx 1.5.3 install says that iftex is not used by sphinx. I’d say you are somehow

Re: [sage-devel] building pdf docs fails

Well it looks like in 1.4.4 they shipped iftex but then in https://github.com/sphinx-doc/sphinx/commit/ead753eaad7e0f73f106c4bda918f916b6d3638c they removed it again. Because they stopped using it. We could check whether its use has been re-introduced somewhere else after that, I guess.

Re: [sage-devel] building pdf docs fails

> On 29/04/2017, at 21:30, Daniel Krenn wrote: > > On 2017-04-29 11:27, Daniel Krenn wrote: >> Building the pdf version of the documentation e.g. for >> reference/asymptotic fails in the current beta (8.0.beta4). It also >> fails in 8.0.beta2, but works in 7.6. >> >> What can

Re: [sage-devel] openblas error while building Sage on Mac OSX 10.9

Can you post the “log file” quoted in the error message please? It is hard to figure out what went wrong without it. François > On 20/04/2017, at 07:30, Anna Haensch wrote: > > I'm trying to build sage from source code on a MacBookPro running OSX 10.9 > and Xcode 6.2

Re: [sage-devel] Re: Make OpenBLAS Error

OK 7.5.1 and 7.6 have the same version of openblas, so something else changed to cause the build failure. So, yes try to build 7.5.1 again. If it fails now, the cause is likely a change in the host system. If it succeeds that’s probably something else in sage that changed. > On 11/04/2017, at

Re: [sage-devel] OSX Xcode 8.3 breaks openblas

My build says halswell perl ./gensymbol osx x86_64 _ 1 0 0 0 0 0 "" "" 1 > osx.def gcc -O2 -DMAX_STACK_ALLOC=2048 -DEXPRECISION -m128bit-long-double -Wall -m64 -DF_INTERFACE_GFORT -fPIC -DNO_WARMUP -DMAX_CPU_NUMBER=4 -DASMNAME=_ -DASMFNAME=__ -DNAME=_ -DCNAME= -DCHAR_NAME=\"_\"

Re: [sage-devel] OSX Xcode 8.3 breaks openblas

issey$ xcode-select -v > xcode-select version 2347. > > Are you at the same level? > > François > > > On 11/04/2017, at 08:03, Francois Bissey <francoi...@canterbury.ac.nz> > > wrote: > > > > It makes shifting to clang a bit more urgent.

Re: [sage-devel] OSX Xcode 8.3 breaks openblas

I don’t seem to be able to reproduce the problem. I have Xcode 8.3.1 and Mirage:~ fbissey$ xcode-select -v xcode-select version 2347. Are you at the same level? François > On 11/04/2017, at 08:03, Francois Bissey <francois.bis...@canterbury.ac.nz> > wrote: > > It makes

Re: [sage-devel] Re: Make OpenBLAS Error

Did it start happening with openblas 0.2.19 or did it suddenly happen one release build openblas 0.2.19 successfully and the next didn’t? I suspect it is a CPU detection problem, we have seen similar logs before on atom chips. François > On 11/04/2017, at 07:45, Ackbach

Re: [sage-devel] OSX Xcode 8.3 breaks openblas

It makes shifting to clang a bit more urgent. I will look into that particular fault ASAP. François > On 11/04/2017, at 07:58, Volker Braun wrote: > > The most recent Xcode update seems to have broken openblas on the OSX > buildbot. Build log errors start at: > > >

Re: [sage-devel] Proposal: remove SAGE_LOCAL/lib/python

> On 6/04/2017, at 10:10, John H Palmieri wrote: > > Did that subject line get your attention? > > I propose that we remove the symbolic link SAGE_LOCAL/lib/python, keeping the > two directories SAGE_LOCAL/lib/python2.7 and SAGE_LOCAL/lib/python3.5. The > link points

Re: [sage-devel] sage.misc.package considered harmful

> On 5/04/2017, at 11:25, Nils Bruin wrote: > > On Tuesday, April 4, 2017 at 4:01:50 PM UTC-7, François wrote: > > With the current system you could install and then remove > some essential files manually and the doctesting framework > would still try to use it. It is

Re: [sage-devel] sage.misc.package considered harmful

> On 5/04/2017, at 10:41, Nils Bruin wrote: > > On Tuesday, April 4, 2017 at 2:24:52 PM UTC-7, François wrote: > Let’s be clear, I could ship a list of possible > optional packages supported in sage-on-gentoo > but any checking of package availability would > have to go

Re: [sage-devel] sage.misc.package considered harmful

> On 5/04/2017, at 08:42, Nils Bruin wrote: > > On Tuesday, April 4, 2017 at 1:00:31 PM UTC-7, François wrote: > (2) while being just one use, is probably not replaceable. > Not in this form at the very least. > > How can one get the appropriate information in sage-on-gentoo?

Re: [sage-devel] sage.misc.package considered harmful

> On 5/04/2017, at 01:12, kcrisman wrote: > > > I am starting this debate because of discussion I had earlier > in #22670. It was pointed out to me that there was no policy > of avoiding `sage.misc.package` and I would very much want one. > > > This seems very

Re: [sage-devel] linker options for C code in ext/interpreters and other stuff in sagelib

> On 28/03/2017, at 21:07, Francois Bissey <francois.bis...@canterbury.ac.nz> > wrote: > >> Does such "#distutils: libraries = blah " automatically imply that libblah >> from $SAGE_LOCAL/lib/ will be linked? >> > > Unless you a

Re: [sage-devel] linker options for C code in ext/interpreters and other stuff in sagelib

> On 28/03/2017, at 21:04, Dima Pasechnik wrote: > > > > On Tuesday, March 28, 2017 at 8:32:53 AM UTC+1, Jeroen Demeyer wrote: > On 2017-03-27 23:15, François Bissey wrote: > > The generated sage/ext/interpreters/wrapper_cdf.pxd has the following > > statement: > >

Re: [sage-devel] Deactivate sage-env for conda

Sounds like what “module”/lmod are supposed to do automatically for you. Sourcing sage-env effectively give you a sage shell as you would if you run “sage -sh”. Again there is not really a deactivation. It starts a new shell and once you type exit you are out. But you could try to work out

Re: [sage-devel] "replacement" optional packages

> On 13/03/2017, at 07:34, Justin C. Walker wrote: > > > On Mar 12, 2017, at 00:27 , Dima Pasechnik wrote: > >> there is no "issue" with pandoc. Most linux distros allow you to install it >> using package manager, and it is easy to install it on OSX or Windows. >> >> On the

Re: [sage-devel] "replacement" optional packages

> On 12/03/2017, at 21:38, Jeroen Demeyer wrote: > > On 2017-03-12 09:35, Dima Pasechnik wrote: >> X11? > > That can be disabled with --disable-gui Indeed X absence is not fatal in configure unlike libjpeg. I guess my point is that before saying it needs porting it

Re: [sage-devel] "replacement" optional packages

Apart from dependencies like jpeg what’s the problem with surf? François > On 12/03/2017, at 21:27, Dima Pasechnik wrote: > > there is no "issue" with pandoc. Most linux distros allow you to install it > using package manager, and it is easy to install it on OSX or Windows.

Re: [sage-devel] ipython-5.0.0 crash

A band aid may be to set LD_LIBRARY_PATH to /opt/sage/local/lib but that’s a band aid only. Would have to check that sage-env doesn’t destroy it. François > On 10/03/2017, at 09:44, Gere Mia wrote: > > Yes, I built it in /tmp, moved it to /opt/sage (so SAGE_ROOT is

Re: [sage-devel] tachyon-0.98.9.p5 build error in Linux

doctesting will fail but building is OK, if dangerous if you are not sandboxed one way or another. François > On 8/03/2017, at 18:59, John H Palmieri wrote: > > Although it's not a good idea to build Sage as root. I think it is likely to > fail -- someone please

Re: [sage-devel] tachyon-0.98.9.p5 build error in Linux

Not at all. It has to do with sage’s python including this patch https://github.com/sagemath/sage/blob/master/build/pkgs/python2/patches/sys_path_security-issue_16202.patch it is something that Dima mentioned earlier in the thread. François > On 8/03/2017, at 15:24, Gere Mia

Re: [sage-devel] tachyon-0.98.9.p5 build error in Linux

Apart from a possible unusual version of make could you try MAKE=“make -d” ./sage -p tachyon That will generate a lot of output but there could be a clue as to why it tries to go in a folder - which is totally abnormal. François > On 7/03/2017, at 06:35, Gere Mia wrote:

Re: [sage-devel] State of sage built with clang/clang++ on OS X - update

uru Fernando <isu...@gmail.com> wrote: > > Thanks. This is using conda's python, so will have to patch that as well. > > > Regards, > > Isuru Fernando > > On Sun, Feb 26, 2017 at 1:09 PM, Francois Bissey > <francois.bis...@canterbury.ac.nz> wrote: >

Re: [sage-devel] State of sage built with clang/clang++ on OS X - update

; > Anybody know why some python extensions with C++ as the language are compiled > with -std=c99? I'm using sage-7.5.1 > > Log is below > > https://travis-ci.org/isuruf/staged-recipes/builds/205439821#L6669 > > Regards, > > Isuru Fernando > >

Re: [sage-devel] cc1 killed in iMac

Output of cat /proc/cpuinfo please. > On 7/02/2017, at 19:58, Jori Mäntysalo wrote: > > Just for fun I tried to compile SageMath on an old iMac with 1 GB RAM and 2 x > T7400 Intel Core 2. > > It stops when compiling m4rie, see >

Re: [sage-devel] Did anyone test latest Sage versions inculding giac on non-x86_64 64 bit systems?

I can have a look. François > On 1/02/2017, at 03:43, Jean-Pierre Flori wrote: > > On a POWER7 (ppc64), giac looks very broken in the spirit of: > * http://xcas.e.ujf-grenoble.fr/XCAS/viewtopic.php?f=19=1723 > I've opened: > * https://trac.sagemath.org/ticket/22280 > > --

Re: [sage-devel] Problem building GSL in cygwin64

That was my suspicion. Now does sage-on-cygwin use openblas? If not that means the corresponding `.pc` files have to be filled with something appropriate before installing any blas/lapack dependencies. The present hack I introduced in gsl and causes this error is to force the linking of libgsl to

Re: [sage-devel] Problem building GSL in cygwin64

Need to see /home/Owner/sage/local/var/tmp/sage/build/gsl-2.1.p1/src/config.log but I suspect I am responsible. François > On 24/01/2017, at 14:51, Frank Garvan wrote: > > > Have attached log file. > > Can this be fixed? > > Thanks > > PS: Running cygwin64 on windows10 >

Re: [sage-devel] Where is implemented the logic deciding whether to install git or not ?

line 292 to 297 of configure.ac. François > On 16/01/2017, at 20:58, Emmanuel Charpentier > wrote: > > Dear list, > > The git standard package is not installed when the system on whic Sage is > built has a systemwide version of git. > > I have been unable to

Re: [sage-devel] trouble compiling on debian sid

:51 AM, Francois Bissey <francois.bis...@canterbury.ac.nz<mailto:francois.bis...@canterbury.ac.nz>> wrote: Would you happen to have polymake installed system wide? Francois On 13/01/2017, at 12:29 AM, moritz <mor...@math.fu-berlin.de<mailto:mor...@math.fu-berlin.de>> wrot

Re: [sage-devel] trouble compiling on debian sid

Would you happen to have polymake installed system wide? Francois On 13/01/2017, at 12:29 AM, moritz > wrote: When trying to build sage from source on my debian box with a current sid install, I get the following error:

Re: [sage-devel] can't compile: make hangs at mpir

Don't think so. Look at the logs at the messages about Sed during configure. Sed is used to preprocess that file. Gentoo report https://bugs.gentoo.org/show_bug.cgi?id=604764 I think Bill will have to look at it upstream. Francois On 11/01/2017, at 9:23 AM, Dima Pasechnik

Re: [sage-devel] can't compile: make hangs at mpir

I have seen a report for this in Gentoo Against 2.6.0. I think it is because of the behaviour of the latest version of Sed. Francois On 10/01/2017, at 1:53 AM, moritz > wrote: Dear list, I am trying to build sage from source on a

Re: [sage-devel] Fail to compile under Mac OS Sierra

Very relevant. Which version of (lib)sodium do you have installed through anaconda? You probably have a version of zeromq installed as well. sodium is an optional dependency of zeromq, an automatic one, so your install of sodium from anaconda has been detected but somehow the path is not set for

Re: [sage-devel] Python 2.7.13rc1 breaks UnknownClass

> On 7/12/2016, at 21:15, Jeroen Demeyer <jdeme...@cage.ugent.be> wrote: > > On 2016-12-07 04:17, Francois Bissey wrote: >> But I am not sure how to do the >> __new__ = object.__new__ in cython. > > You certainly cannot do that since Cython's __new__ does

Re: [sage-devel] Python 2.7.13rc1 breaks UnknownClass

I am guessing we should something more fundamental in sage/structure/sage_object.pyx since we are dealing with SageObject classes. But I am not sure how to do the __new__ = object.__new__ in cython. François > On 7/12/2016, at 15:25, than...@debian.org wrote: > > When setting __new__ =

Re: [sage-devel] SAGE_ATLAS_LIB vs openblas

> On 3/12/2016, at 22:00, Jeroen Demeyer wrote: > > On 2016-12-02 09:21, Thierry wrote: >> Would it be >> preferable to have this possibility dealt at configure time > > Absolutely. Whatever you do, do *NOT* introduce a new environment variable. > Use a configure

Re: [sage-devel] SAGE_ATLAS_LIB vs openblas

> On 2/12/2016, at 21:30, Jean-Pierre Flori wrote: > > > > On Friday, December 2, 2016 at 9:24:16 AM UTC+1, François wrote: > > > On 2/12/2016, at 21:21, Thierry wrote: > > > > Hi, > > > > the SAGE_ATLAS_LIB stuff, which allowed to use

Re: [sage-devel] SAGE_ATLAS_LIB vs openblas

> On 2/12/2016, at 21:21, Thierry wrote: > > Hi, > > the SAGE_ATLAS_LIB stuff, which allowed to use system blas belongs to > SAGE_ROOT/build/pkgs/atlas/spkg-install Is it possible to have such option > (perhaps renamed SAGE_BLAS_LIB) available even if openblas

Re: [sage-devel] Re: OpenSSL as a new systemwide Sage dependency ?

I notice anaconda ship its own openssl, on OS X at least. Are they purposefully avoid GPL in all their packages? François > On 2/12/2016, at 11:47, Volker Braun wrote: > > On OSX, you can do either > > a) nothing => no https support, > > a) supply the (missing) openssl

Re: [sage-devel] Current Maxima version

see https://trac.sagemath.org/ticket/18920 > On 29/11/2016, at 10:26, Paul Masson wrote: > > The version of Maxima that ships with Sage is 5.35.1 from December 2014, > while the most recent version is 5.38.1 from May 2016. > > Is there a compelling reason not to upgrade

Re: [sage-devel] Update CDDLIB source package? (was: What is the correct way to patch packages that use autotools?)

configure.in are certainly a bad indicator. Anything with one of these instead of configure.ac triggers a warning in gentoo that support for it will be dropped sooner than later. In any case what kind of changes do you want to apply, I may have better luck with my packaging machinery. François

Re: [sage-devel] Error building flint-2.5.2.p0

This is https://trac.sagemath.org/ticket/21782 I believe it is in the latest beta for upcoming sage 7.5. François > On 22/11/2016, at 20:36, Eric Culver wrote: > > I downloaded the Sage source from > http://www.sagemath.org/download-source.html . > When attempting to

Re: [sage-devel] Building Sage 7.4 final release on OS X El Capitan

It is probably not limited to El Capitan it would have been useful to get some more details. Francois On 3/11/2016, at 2:07 PM, Paul Masson > wrote: I had difficulty over the last couple days getting Sage 7.4 to build. Something like ten

Re: [sage-devel] sage 7.4 does not build on Ubuntu 16.10

There is currently an issue with brial and gcc 6.2.0 that remains to be fixed. I don’t remember if someone blacklisted that gcc as a consequence. I should do something about that, even if it is a bit radical. François > On 1/11/2016, at 09:55, William Stein wrote: > > On

Re: [sage-devel] Trac error on push

Add trac.sagemath.org,104.197.143.230 ecdsa-sha2-nistp256 E2VjZHNhLXNoYTItbmlzdHAyNTYIbmlzdHAyNTYAAABBBG+/AO490umZWuczUgClP4BgFm5XR9I43z4kf9f+pu8Uj6UvH/7Pz1oBkJ71xET+xTmecBHB2c9OwlgPjB70AB8= as a single line at the end of .ssh/know_hosts François > On 31/10/2016, at 20:52, Marco

Re: [sage-devel] Trac error on push

Then, it may have been the wrong host. You should remove the line starting with trac.sagemath.org Once removed, the next time you connect to the trac server, you will be asked about adding it to the list of know_hosts. François > On 31/10/2016, at 20:27, Marco Cognetta

Re: [sage-devel] Trac error on push

Removing the 4th line in your file ~/.ssh/known_hosts looks like it would do the trick. I think it would be the 4th line but it could be another one. It will almost certainly be another one for other people. François > On 31/10/2016, at 20:10, Marco Cognetta wrote: >

Re: [sage-devel] R 3.3.1 depends on a SSL/TLS implementation

It is a most interesting point because it explain why the R binary installed from epel for RH7.1 and family isn’t linked to openssl. If they don’t have a rock solid argument, and even if they have, there may not be anymore official R packages from big league binary distros. Unless they patch R,

Re: [sage-devel] R 3.3.1 depends on a SSL/TLS implementation

While not configurable by the user in R-3.2.x it would build if libcurl wasn’t found or missing https support. The change to bail out if you don’t fulfil all the condition appear deliberate to me. And I see the point from a support point of view. My conclusion is that R developers would fill it

Re: [sage-devel] R 3.3.1 depends on a SSL/TLS implementation

at 11:41:20 AM UTC+2, Jeroen Demeyer wrote: > On 2016-10-27 11:29, Francois Bissey wrote: > > R package system include downloading facility from repositories. > > That's fine but it should be possible to just run R without it's > packaging system. > Then I suggest a n

Re: [sage-devel] R 3.3.1 depends on a SSL/TLS implementation

R package system include downloading facility from repositories. That’s why you need curl. At least in theory. I’ll have to check for 3.3.x but there was alternatives in 3.2.x. François > On 27/10/2016, at 22:26, Jeroen Demeyer wrote: > > This is the obvious answer: >

Re: [sage-devel] Can we depend on system's utilities and libraries ?

Yup. It is all system packages. In fact R and its dependencies are not part of the sage-on-gentoo “repo”. Also in Gentoo we don’t usually split things in $package and $package-devel you get the nice libraries for linking and headers. The headers and stuff in $package-devel is the sticky point

Re: [sage-devel] LAPACK from sage (i. e. usable in sage -sh) ?

et should be resolved as "Invalid/won't fix"... > > -- > Emmanuel Charpentier > > > Le 21 oct. 2016 10:22, "Francois Bissey" <francois.bis...@canterbury.ac.nz> a > écrit : > Doesn’t have to use .pc - directly. But it has to be able to accept a u

Re: [sage-devel] LAPACK from sage (i. e. usable in sage -sh) ?

Doesn’t have to use .pc - directly. But it has to be able to accept a user configuration one way or another. Using .pc to provide said configuration in a script is OK. You might want to explore the way I did set up numpy in sage for example. I looked at JAGS it takes --with-blas and

Re: [sage-devel] LAPACK from sage (i. e. usable in sage -sh) ?

I agree it would be best. Unfortunately it may not always be possible to do that without heavy hacking. Adding the liblapack link has trade-off, it would make some stuff work out of the box but it could also hide problems on the long term. Really upstream of any project using blas/lapack needs to

Re: [sage-devel] LAPACK from sage (i. e. usable in sage -sh) ?

libopenblas.so to liblapack.so? Yes it should and I think we even should do it in spkg-install. Feel free to open a ticket. François > On 21/10/2016, at 10:23, Emmanuel Charpentier > wrote: > > Would it be sufficient to link libosympenblas.so to liblapack.so in

Re: [sage-devel] LAPACK from sage (i. e. usable in sage -sh) ?

This is because automatic blas/lapack detection is a hopeless task. You should pass your lapack libraries to the configuration script. If you can’t, hack it. And now that we have switched to openblas, -lopenblas provides lapack. François > On 21/10/2016, at 10:04, Emmanuel Charpentier

Re: [sage-devel] 7.4 release: please don't have fpylll build-depend on Sage

Very much appreciated Martin! Since this ticket doesn’t touch sagelib Gentoo, Debian and other distributions will be able to use fpylll-0.23 directly in sage-7.4. I’ll issue a revision of the sage-7.4 ebuild tomorrow and review the ticket if no one has done it by then. François > On 19/10/2016,

Re: [sage-devel] NTL 1v0.1.0

And posted to libsingular-devel: https://groups.google.com/d/msg/libsingular-devel/u8-aHNMqf44/GNVvSYGEAQAJ > On 18/10/2016, at 21:39, Jean-Pierre Flori wrote: > > > > On Tuesday, October 18, 2016 at 8:52:23 AM UTC+2, François wrote: > > > On 18/10/2016, at 19:42,

Re: [sage-devel] NTL 1v0.1.0

I probably assumed too much. But it felt wrong to say “there is a problem building ntl but ntl upstream is happy to talk to you about your needs” (and doing that anonymously feels like a prank call). I prefer the mailing list option and I am actually subscribed. Still have to get to it. François

Re: [sage-devel] NTL 1v0.1.0

> On 18/10/2016, at 19:42, Jean-Pierre Flori wrote: > > > > On Tuesday, October 18, 2016 at 6:37:49 AM UTC+2, Victor Shoup wrote: > Good! But it should be determined if there is an interface that ntl could > provide so that this problem goes away > > I think that what you

Re: [sage-devel] NTL 1v0.1.0

> On 18/10/2016, at 17:18, Victor Shoup wrote: > > I see. I don't do it on purpose... > I looked at some singular source files, but I don't know if I have the most > recent. But it looks like they are trying to look inside ntl's ZZ > representation. That's a big no no.

Re: [sage-devel] NTL 1v0.1.0

> On 18/10/2016, at 16:49, Victor Shoup wrote: > > Interesting. Looks like the singular code is using internal, undocumented NTL > interfaces. I work very hard to keep the documented interfaces stable and > reliable, but I can't guarantee anything for undocumented

Re: [sage-devel] Milestones

> On 17/10/2016, at 22:42, Erik Bray <erik.m.b...@gmail.com> wrote: > > On Mon, Oct 17, 2016 at 11:39 AM, Francois Bissey > <francois.bis...@canterbury.ac.nz> wrote: >> >>> On 17/10/2016, at 22:33, Erik Bray <erik.m.b...@gmail.com> wrote: >>

Re: [sage-devel] Milestones

> On 17/10/2016, at 22:33, Erik Bray wrote: > > My point is, as it is I see no way to divine when or why a Sage > release is coming out. Release early, release often. In my experience in the last 8 years, especially release often - it has slowed down a bit, but it is

Re: [sage-devel] Re: Make OpenBLAS Error

Not spending the time compiling gcc to get gfortran? François > On 13/10/2016, at 22:01, Sébastien Labbé wrote: > > > > On Wednesday, October 12, 2016 at 9:07:24 PM UTC+2, Eric Gourgoulhon wrote: > > with Ubuntu 16.04, if you install the Ubuntu package gfortran-5, your Sage

Re: [sage-devel] trouble compiling latest sage development version

You mean like https://trac.sagemath.org/ticket/12426 ? François > On 12/10/2016, at 22:48, Dima Pasechnik wrote: > > I see, thanks. I should have been cc'ng myself on #21567 long ago. > > Anyway, is it the time we open a meta-ticket on enabling full build of Sage > with

Re: [sage-devel] trouble compiling latest sage development version

Ok the initial problem was with avx instructions. Either givaro gets misconfigured in thinking you have avx or someone you get a broken assembler. Can you try CXXFLAGS=“-Wa,-q” ./sage -i givaro > On 12/10/2016, at 16:41, Anne Schilling wrote: > > Wait, isn't this the

Re: [sage-devel] trouble compiling latest sage development version

I am surprised you got that far with Xcode 8.0! see https://trac.sagemath.org/ticket/21567 François > On 12/10/2016, at 07:35, Anne Schilling wrote: > > Hi Volker, > > Thanks for the suggestion. I upgraded to OSX 10.12 and installed the latest > version command

Re: [sage-devel] NTL v10

> On 12/10/2016, at 06:54, Victor Shoup wrote: > > While I'm not ready to go all autotools, I've started reading about it. > I read about the DESTDIR trick that some package managers use, > so I added support for that in the makefile. Although I suppose > that may not be so

Re: [sage-devel] NTL v10

And actually I said some stuff without revisiting what is done in Gentoo and in sage and I am not sure which one is overkill anymore. I inherit cruft from someone else (possibly me in the past). I need to sort it out. To go back to: Second, in the patch, you write $(LINK) $(LIBTOOL_FLAGS)

Re: [sage-devel] NTL v10

Autotools is nicer for a lot of things. sage does patch to use libtools and I stayed away from that in Gentoo. The main advantage as far as I am concerned is that it makes it easier to produce shared libraries, correctly on a variety of platforms. Just for linux, and OS X, you don’t strictly need

Re: [sage-devel] NTL v10

> On 9/10/2016, at 09:21, Victor Shoup wrote: > > • I've renamed all the ".c" files to ".cpp" files in the Unix > distribution. This seems to be more in line with common practice, and should > make it easier to work with compilers and other software development tools.

Re: [sage-devel] multithreading performance issues

openmp is disabled in linbox/ffpack-fflas so it must come from somewhere else. Only R seems to be linked to libgomp (openmp) on my vanilla install. Curiosity: do you observe the same behaviour in 7.3? François > On 5/10/2016, at 07:26, Jonathan Bober wrote: > > See the

Re: [sage-devel] State of sage built with clang/clang++ on OS X - update

> On 4/10/2016, at 20:39, Ralf Stephan wrote: > > Ah that would be a wrong libffi-devel version on OpenSuSE, shouldn't > this be tested by Sage configure? > That would explain. Note that I only tested the odd package on linux and most of what I have done has been on OS X.

Re: [sage-devel] State of sage built with clang/clang++ on OS X - update

You need https://trac.sagemath.org/ticket/12473 for ratpoints. coming in the next beta. François > On 4/10/2016, at 19:07, Ralf Stephan wrote: > > On Sunday, October 2, 2016 at 10:33:38 PM UTC+2, François wrote: > this is the status after about two weeks > > ratpoints

Re: [sage-devel] State of sage built with clang/clang++ on OS X - update

I haven’t tried SAGE_INSTALL_GCC=no on linux or using clang for a full build on linux. Just one packages here and there. And yes you cannot build gfortran without gcc a t this time. François > On 3/10/2016, at 22:48, Dima Pasechnik wrote: > > And how about Linux with

Re: [sage-devel] State of sage built with clang/clang++ on OS X - update

In the current state of sage starting from scratch with clang/clang++ via CC=clang CXX=clang++ make will trigger the building of sage’s gcc (which is OK on OS X since you still need gfortran). The problem is that once you build sage’s gcc, there is a clause in src/bin/sage-env to use sage’s

Re: [sage-devel] State of sage built with clang/clang++ on OS X - update

> On 3/10/2016, at 09:33, François Bissey > wrote: > >> linbox > > No news from upstream at > https://github.com/linbox-team/linbox/issues/39 > contributions welome. Well as it turns out the problem is only in the interface with fplll which we are going to

Re: [sage-devel] Re: trouble compiling latest sage development version

Does the ntl failure look like anything reported at https://trac.sagemath.org/ticket/20779 ? François > On 1/10/2016, at 14:52, Travis Scrimshaw wrote: > > Perhaps this is from the same error as stack overflow post? I remember we had > to have something with

Re: [sage-devel] How find out which plot causes docbuild error

A fair question. I cannot remember the folder from the top of my head but I have debugged that problem several time. First counting 35 blocks may not get you the right one, unless you are building serially. You should try to locate it under

Re: [sage-devel] State of sage built with clang/clang++ on OS X

I don’t know about debian based distro specifically but installing clang shouldn’t remove gcc, they are orthogonal to each other. When you try building a specific package try CC=clang CXX=clang++ ./sage -f symmetrica for example. Yes there is a possibility of your sage install breaking after

Re: [sage-devel] State of sage built with clang/clang++ on OS X

Reanimating https://trac.sagemath.org/ticket/12426 There is a ticket for symmetrica, if you still want to do it, I’d rather you fix the code with a patch than with a compilation flags as is suggested in #12439. François > On 17/09/2016, at 15:53, Francois Bissey <franco

  1   2   3   4   5   6   >