it seems to be related to Apple removing support for libstdc++.
Could it be that you have something related to "deployment target"
(MACOSX_DEPLOYMENT_TARGET ?) in your default environment variables, or
similar settings in Xcode?
Or perhaps CPLUS_INCLUDE_PATH is set somewhere?
Perhaps your "XcodeD
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
>>
+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
"sage
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 too
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 à 05
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 --in
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 cas
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 globally?
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.
> >
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
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
>> r
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 t
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 th
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 f
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 t
> >
> > 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
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 thi
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 Naut
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 -
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 [-
20 matches
Mail list logo
