Re: [sage-devel] Unable to build sage

On Saturday, July 4, 2020 at 3:12:36 PM UTC-7, Dima Pasechnik wrote: > > I guess this is due to gfortran 10. > We still do not support gcc 10, I think. > Can you downgrade it to gfortran 9? > I had gfortran10 which came with gcc. In installed gfortran (with Homebrew) which gave me gfortran 8.2.

Re: [sage-devel] Unable to build sage

scipy update to 1.5.1 is now at https://trac.sagemath.org/ticket/29766 For gcc 10 support of the whole sage distribution we need at least one more package upgrade: sympow https://trac.sagemath.org/ticket/3360 Meta-ticket on gcc 10 at https://trac.sagemat

Re: [sage-devel] Unable to build sage

Seems to be related to https://github.com/scipy/scipy/issues/11611 and as was pointed out above was fixed in version 1.5. I'd like to propose two workarounds for people who can no longer build sage and stumble into this thread (either should allow scipy 1.2.3 to build) 1). Use fortran 9: brew

Re: [sage-devel] Unable to build sage

On Jul 04, Dima Pasechnik wrote: I guess this is due to gfortran 10. We still do not support gcc 10, I think. Can you downgrade it to gfortran 9? For what its worth, here running arch, 1) removing line 153 from build/pkgs/gcc/spkg-configure.m4 2) adding a newer scipy: upstream/scipy-1.5.0.ta

Re: [sage-devel] Re: Transpiling from Mathematica syntax to sage backends

There are at least two rather complete parsers for the "Wolfram Language" which render stuff like foo[x_]:= Sin[x]+Log[x] into trees / intermediate forms/ Lisp s-expressions. (compare to Wolfram's "FullForm" which is essentially lisp with [] instead of (), and moving parens... x+y becomes

Re: [sage-devel] Unable to build sage

I guess this is due to gfortran 10. We still do not support gcc 10, I think. Can you downgrade it to gfortran 9? On Sat, 4 Jul 2020, 23:06 Daniel Bump, wrote: > > > On Saturday, July 4, 2020 at 2:52:06 PM UTC-7, Dima Pasechnik wrote: >> >> Please post top config.log and also the full logs/pkgs/

Re: [sage-devel] Unable to build sage

Please post top config.log and also the full logs/pkgs/scipy-...log On Sat, 4 Jul 2020, 21:01 Daniel Bump, wrote: > I'm unable to build Sage since yesterday on an iMac running mojave. > > I have tried (repeatedly) to build the develop branch and others including > fusion_central_charge-29615. >

[sage-devel] Unable to build sage

I'm unable to build Sage since yesterday on an iMac running mojave. I have tried (repeatedly) to build the develop branch and others including fusion_central_charge-29615. I mention the last one since there has been no activity on that branch since July 1 and I was able to build it on this mac

Re: [sage-devel] Re: Transpiling from Mathematica syntax to sage backends

On Saturday, July 4, 2020 at 9:10:33 AM UTC-7, Rocky Bernstein wrote: > > > So one goal as briefly mentioned was to be able to write/use a common > language for expressing CAS. > This goal (or perhaps a little more broadly, a common language for expressing mathematical objects) has been around

Re: [sage-devel] Re: Transpiling from Mathematica syntax to sage backends

I am sorry that what I posted originally somehow didn't go through. It took me a while to write and touches on a number of things mentioned in the discussion. So let me try again. I have a limited simple-minded brain for all of the various syntaxes and dialects. So one goal as briefly mentioned w

[sage-devel] Re: Transpiling from Mathematica syntax to sage backends

> I'm curious of any consideration has been giving for transpiling from one > CAS syntax to another instead of or right before sage.repl.preparse(). > I think that long ago some of that was suggested, but the problem is that there are very nontrivial differences - it's not just a matter of c