On Wednesday, 30 October 2019 23:27:45 UTC+11, Dima Pasechnik wrote:
>
> I meant cmath files without extensions. These are C++ header files.
> It appears there are two such files on the list. Are they different?
>
> In the interim have have installed homebrew's gcc to see if this helps,
but it
I tried building several version of gfortran by hand on 10.15, but I
couldn't succeed, whereas I could with 10.14. I didn't try just upgrading
Sage's gfortran/gcc package to 9.x.
On Wednesday, October 30, 2019 at 3:21:58 PM UTC-7, François Bissey wrote:
>
> I suspect gcc/gfortran shipped with
I suspect gcc/gfortran shipped with sage is too old to build on 10.15.
Upgrading to 9.x may help.
> On 31/10/2019, at 11:04 AM, Dima Pasechnik wrote:
>
> I think at the moment most people who tried cannot build Sage on MacOS
> 10.15 with Xcode 11.1 (the latest one).
> Regarding gfortran,
Ok, thanks again. Using the construction parameters is definitely an option
and I will change it soon.
Am Mittwoch, 30. Oktober 2019 22:59:34 UTC+1 schrieb Nils Bruin:
>
> On Wednesday, October 30, 2019 at 2:31:37 PM UTC-7, Jonathan Kliem wrote:
>>
>> Basically, I can just do it like this. Now,
I think at the moment most people who tried cannot build Sage on MacOS
10.15 with Xcode 11.1 (the latest one).
Regarding gfortran, perhaps one can try installing Homebrew and use
gfortram from there.
If you just need a working Sage, your best bet on MacOS 10.15 might be
the one from conda-forge.
On Wednesday, October 30, 2019 at 2:31:37 PM UTC-7, Jonathan Kliem wrote:
>
> Basically, I can just do it like this. Now, if I understand it correctly:
>
> Face lattice as it is, should not be cached. Instead its probably fine to
> store the version with indices and convert on each call. Or the
I also had problems with Sage's gfortran package with OS X Catalina. I
instead installed homebrew (https://brew.sh), and used homebrew to install
their gcc package. This should install gfortran, which Sage will find as
part of its configure process, thereby bypassing Sage's gfortran package.
Thanks. I think I have it figured out now.
The current construction passes to the face lattice the ID of self as a
key. This is why F1 and F2 are not identical.
Basically, I can just do it like this. Now, if I understand it correctly:
Face lattice as it is, should not be cached. Instead its
I haven't dug very deep into this, but the following looks suspicious:
sage: o1 = lattice_polytope.cross_polytope(3)
sage: o2 = lattice_polytope.cross_polytope(3)
sage: o1==o2
True
sage: o1 is o2
False
This in itself isn't a problem, but o1.face_lattice() is a
UniqueRepresentation object. That
Can anyone help me explain this
sage: o = lattice_polytope.cross_polytope(3)
sage: F = o.face_lattice()
sage: G = F.relabel(F._elements)
sage: G[0].ambient() is o
True
sage: o = lattice_polytope.cross_polytope(3)
sage: F = o.face_lattice()
sage: G = F.relabel(F._elements)
sage: G[0].ambient() is
William, thanks for chiming in on this - I did not review the ticket but
did look at it some, and the possibility that import would no longer work
(but was an API) did not occur to me, as for Eric. Glad there should be an
easy fix.
--
You received this message because you are subscribed to
In fact, sage/misc/log.py uses very old ipython features, which seem
to be long gone.
A modern way to say e.g. the whole command history to /tmp/xxx.log
would be to run
sage: %history -f /tmp/xxx.log
See
https://stackoverflow.com/questions/16858724/how-to-log-ipython-history-to-text-file/39413200
This is a bug
See https://trac.sagemath.org/ticket/28677
Thanks for reporting it - it's a good example of code bitrot due to no
tests... :-)
On Wed, Oct 30, 2019 at 4:21 PM Max Alekseyev wrote:
>
> Please advise on the following error.
> Thanks,
> Max
>
>
Please advise on the following error.
Thanks,
Max
┌┐
│ SageMath version 8.9, Release Date: 2019-09-29 │
│ Using Python 2.7.15. Type "help()" for help. │
I meant cmath files without extensions. These are C++ header files.
It appears there are two such files on the list. Are they different?
On Wed, 30 Oct 2019, 14:14 Andrew, wrote:
> I don't have anything like MACOSX_DEPLOYMENT_TARGET or CPLUS_INCLUDE_PATH
> set and I'll paste the list of
I don't have anything like MACOSX_DEPLOYMENT_TARGET or CPLUS_INCLUDE_PATH
set and I'll paste the list of filenames contain cmath below.
I wonder if this is part of the problem. According to gcc--version:
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr
Please feel free to edit and enhance the wiki page about the switch :
https://wiki.sagemath.org/Python3-Switch
Le dimanche 27 octobre 2019 01:58:23 UTC+2, Volker Braun a écrit :
>
> 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,
On Wed, Oct 30, 2019 at 02:59:43AM -0700, Michael Jung wrote:
> The issue is more subtle than that. My variable must be defined on the
> complex domain. But
> sage: x = SR.var('x', domain='complex')
> changes the domain of x permanently.
OK, i did not understood your question. This is because
The issue is more subtle than that. My variable must be defined on the
complex domain. But
sage: x = SR.var('x', domain='complex')
changes the domain of x permanently.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this
Hi,
On Tue, Oct 29, 2019 at 04:49:03PM -0700, Michael Jung wrote:
> 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
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
21 matches
Mail list logo
