Re: [sage-devel] Re: Optional and experimental packages

2019-10-29 Thread Samuel Lelièvre
Tue 2019-10-29 11:57 UTC, kcrisman: > >> Perhaps should we simply remove the pseudo-packages whose type is "pip" >> (since there is the "sage -pip install" command), that is: >> >> beautifulsoup >> biopython >> brian >> guppy >> mercurial >> mpi4py >> nibabel >> pybtex >> pyflakes >> sqlalchemy >>

[sage-devel] Re: Switch to Python 3 by default

2019-10-29 Thread Travis Scrimshaw
+1 On Sunday, October 27, 2019 at 9:58:23 AM UTC+10, Volker Braun wrote: > > Maybe I missed it, but I didn't find a ticket for that. I think now would > be a good time to flip the switch, though. Any thoughts? > -- You received this message because you are subscribed to the Google Groups

Re: [sage-devel] Re: OSX Catalina works

2019-10-29 Thread Andrew
Thanks everyone for their comments. > try explicitly adding "-stdlib=libc++" to CXXLAGS and LDFLAGS. Adding these flags to the Makefile didn't change anything: the build again failed with givaro-4.1.1 > After installing Xcode, did you run Xcode? Yes, of course! Xcode and the command line

[sage-devel] Re: [sage-support] optional packages and binder

2019-10-29 Thread Vincent Delecroix
Dear Enrique, It would be helpful to have the complete error message and the log of the failed build. And if you know how to do that, you can open a trac ticket. Also, it would be nice to have docker images for Sage with most (if not all) optional packages installed. Vincent Le 29/10/2019 à

Re: [sage-devel] Re: OSX Catalina works

2019-10-29 Thread Samuel Lelièvre
Tue 2019-10-29 11:46 UTC, Andrew: > > Thanks Dima > > On Tuesday, 29 October 2019 17:51:02 UTC+11, Dima Pasechnik wrote: >> >> Did you run >> >> xcode-select --install >> >> after Xcode upgrade? > > > Yes, the command line tools are correctly installed but, as far as I can see, > xcode-select

[sage-devel] Re: Symbolic Variables for Internal Use

2019-10-29 Thread Nils Bruin
Short answer: no. Workaround: conceive some prefix to make a really unlikely name; something like _my_internal_symbol_t_ or so. Ameliorating circumstance: for the most part, symbolic variables are just immutable place-holders, so it shouldn't matter who uses them. Probably the most serious

[sage-devel] Symbolic Variables for Internal Use

2019-10-29 Thread Michael Jung
I'd like to use symbolic expressions in the source code to compute taylor expansions of predefined functions. But this affects the use of variables named the same way on the level of the user. Is there a safe way to use the framework of symbolic calculus without affecting the variables

Re: [sage-devel] Re: sage.plot.graphics.GraphicsArray no longer available?

2019-10-29 Thread Eric Gourgoulhon
Le mardi 29 octobre 2019 23:49:41 UTC+1, William a écrit : > > On Tue, Oct 29, 2019 at 1:37 PM Eric Gourgoulhon > wrote: > > > > Do you think it's necessary to add a redirect import for GraphicsArray > from sage.plot.graphics? We can easily make a new ticket to fix this for > Sage 9.0. > >

Re: [sage-devel] Re: sage.plot.graphics.GraphicsArray no longer available?

2019-10-29 Thread William Stein
On Tue, Oct 29, 2019 at 1:37 PM Eric Gourgoulhon wrote: > > Le mardi 29 octobre 2019 21:17:02 UTC+1, Eric Gourgoulhon a écrit : >> >> Le mardi 29 octobre 2019 19:19:51 UTC+1, William a écrit : >>> >>> >>> It's (obviously) likely that at least one person did that. This is part >>> of the public

[sage-devel] Re: sage.plot.graphics.GraphicsArray no longer available?

2019-10-29 Thread Eric Gourgoulhon
Le mardi 29 octobre 2019 21:17:02 UTC+1, Eric Gourgoulhon a écrit : > > Le mardi 29 octobre 2019 19:19:51 UTC+1, William a écrit : >> >> >> It's (obviously) likely that at least one person did that. This is part >> of the public API of Sage, so it would be good if it were deprecated before >>

[sage-devel] Re: sage.plot.graphics.GraphicsArray no longer available?

2019-10-29 Thread Eric Gourgoulhon
Le mardi 29 octobre 2019 19:19:51 UTC+1, William a écrit : > > > It's (obviously) likely that at least one person did that. This is part > of the public API of Sage, so it would be good if it were deprecated before > removal (or just left in via a one-liner redirect import). > Sorry about

[sage-devel] Re: sage.plot.graphics.GraphicsArray no longer available?

2019-10-29 Thread William
On Friday, October 25, 2019 at 4:32:49 AM UTC-7, kcrisman wrote: > > I didn't think that this would break any code - is it a very likely thing > that people would have been importing this class explicitly instead of > using the wrapper? > It's (obviously) likely that at least one person did

Re: [sage-devel] Re: OSX Catalina works

2019-10-29 Thread John H Palmieri
On Tuesday, October 29, 2019 at 4:45:53 AM UTC-7, Andrew wrote: > > Thanks Dima > > On Tuesday, 29 October 2019 17:51:02 UTC+11, Dima Pasechnik wrote: >> >> Did you run >> >> xcode-select --install >> >> after Xcode upgrade? >> > > Yes, the command line tools are correctly installed but, as

Re: [sage-devel] Re: OSX Catalina works

2019-10-29 Thread Dima Pasechnik
try explicitly adding "-stdlib=libc++" to CXXLAGS and LDFLAGS. On Tue, 29 Oct 2019, 13:45 Andrew, wrote: > Thanks Dima > > On Tuesday, 29 October 2019 17:51:02 UTC+11, Dima Pasechnik wrote: >> >> Did you run >> >> xcode-select --install >> >> after Xcode upgrade? >> > > Yes, the command line

Re: [sage-devel] Re: Optional and experimental packages

2019-10-29 Thread kcrisman
> > > > Sage-wise, I believe Mercurial is a remnant of the time > > before we switched to Git. I think we should remove it. > > I'm surprised it hadn't been long before. Even I would approve that. > > Perhaps should we simply remove the pseudo-packages whose type is "pip" > (since there

Re: [sage-devel] Re: OSX Catalina works

2019-10-29 Thread Andrew
Thanks Dima On Tuesday, 29 October 2019 17:51:02 UTC+11, Dima Pasechnik wrote: > > Did you run > > xcode-select --install > > after Xcode upgrade? > Yes, the command line tools are correctly installed but, as far as I can see, xcode-select --install is no longer the correct way to check

Re: [sage-devel] Optional and experimental packages

2019-10-29 Thread Nico Van Cleemput
OK, the answer is below: The file splay.c is actually taken from Nauty, so that issue should be resolved there. The most obvious solution is to not compile this as C99, but as C89 since that is what buckygen was written in. So, I can mail this to Brendan McKay to ask to solve this, but since

Re: [sage-devel] Optional and experimental packages

2019-10-29 Thread Nico Van Cleemput
Well, upstream sits at another desk in my office, so I will ask when he gets in. Nico Op di 29 okt. 2019 09:29 schreef Dima Pasechnik : > clang is unhappy about C standards violations. E.g. this is what I get > with clang 7: > > cc -O4 buckygen.c -o buckygen > cc: warning: -O4 is equivalent to

Re: [sage-devel] Optional and experimental packages

2019-10-29 Thread Dima Pasechnik
clang is unhappy about C standards violations. E.g. this is what I get with clang 7: cc -O4 buckygen.c -o buckygen cc: warning: -O4 is equivalent to -O3 [-Wdeprecated] In file included from buckygen.c:272: ./splay.c:139:6: warning: implicit declaration of function 'outputnode' is invalid in C99

Re: [sage-devel] Re: OSX Catalina works

2019-10-29 Thread Dima Pasechnik
Did you run xcode-select --install after Xcode upgrade? By the way, why don't you use NTL from brew? https://formulae.brew.sh/formula/ntl#default you can also make things easier by installing Flint and Arb into homebrew, by using formulas from https://github.com/dimpase/homebrew-science Run

Re: [sage-devel] Optional and experimental packages

2019-10-29 Thread Nico Van Cleemput
buckygen is a pure C package, so I doubt that this has anything to do with the switch to Python 3. Do you have any more information about the fail build, because here it built fine. Nico Op ma 28 okt. 2019 om 23:02 schreef John H Palmieri : > With a Python 3 build of Sage on OS X 10.14.6, I