Re: [sage-devel] Re: Urgent and important: Please vote on disputed PR #36964 (next step of the modularization project)

[Nathan Dunfield]

On Thursday, April 25, 2024 at 2:17:31 AM UTC-5 Martin R wrote:

I agree that my terminology is not good.  I tried to make a distinction 
between research involving math and the - to me unknown - rest.  I find it 
hard to imagine that any mathematician would bother installing anything 
else but all of sage. 


As mentioned upthread, CyPari is one of the few examples of something 
that's been modularized out of Sage.  While it's small compared to Sage, it 
can still do everything Pari can, which is a lot.   Marc and I broke out 
CyPari so we could use it in SnapPy (https://snappy.computop.org), whose 
users are, at a guess, 90% mathematicians, 9% physicists,  1% other.   The 
most recent version stand-alone (Sage-free) version of SnapPy has been 
downloaded 1,200 times on Windows and macOS.  That's a lot of 
mathematicians who are already installing only part of Sage.

Another example is large-scale pure math computation on clusters.  Because 
of Sage's size and the nature of distributive file systems, the time to 
startup Sage can be 30 seconds or more, which complicates things if you 
want to do 100,000 calculations that are only 10 seconds each.  I was 
recently at a workshop on computational topology, and several researchers 
there regarded using Sage in this context as a non-starter, in one case 
they were completely changing their approach to avoid using Sage. 

Best,

Nathan

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/c429af78-dd69-4ed5-94d4-0c0a45df8114n%40googlegroups.com.

Re: [sage-devel] Re: Urgent and important: Please vote on disputed PR #36964 (next step of the modularization project)

[Nathan Dunfield]

On Wednesday, April 24, 2024 at 10:14:09 PM UTC-5 Matthias Koeppe wrote:

Yes, native Windows would clearly be a very important target.


As a data point, downloads of our stand-alone SnapPy app, which is about as 
high level pure math as it gets, are 60% higher for Windows than macOS.
 

In another direction: I have started a port of Sage to pyodide, the 
distribution of Python for WebAssembly (WASM), which makes Python runnable 
directly in the browser. I can already run and test the modularized 
distributions **sagemath-objects**, **sagemath-categories** there.


It would be amazing if a decent portion of Sage could be run in the browser 
this way, e.g. to have the occasional HW assignment that needs Sage without 
the overhead of using something like CoCalc. 

Best,

Nathan
 

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/db5485fe-3da5-44bf-b063-7fa7274de17dn%40googlegroups.com.

Re: [sage-devel] Re: Urgent and important: Please vote on disputed PR #36964 (next step of the modularization project)

[Nathan Dunfield]

On Wednesday, April 24, 2024 at 4:25:41 PM UTC-5 Dima Pasechnik wrote:

On Wed, Apr 24, 2024 at 9:29 PM Nathan Dunfield wrote:
> On a related note, the reason that CyPari2 and CyPari are still separate 
relates to what Marc mentioned earlier about tension between two models of 
installing software: the "Linux distro way" using a system-level package 
manager (where there is typically only one version of any given library on 
the system) and the "Python pip" way (where all needed libraries are 
statically linked into the wheel). CyPari2 follows the first, CyPari the 
second. (This story is further complicated by the fact that, from a user's 
perspective, conda is like "Python pip" in that it is orthogonal to any 
system libraries, but developing packages for conda is akin to building 
them for a Linux distro.) 

There isn't a big problem to set up a GitHub wheel builder for 
CyPari2, so there is not really a sea of difference here in this 
sense.


Dima,

Good point, I had forgotten that Matthias did exactly that when he released 
the most recent CyPari2:

https://github.com/sagemath/cypari2/blob/master/.github/workflows/dist.yml

and the binary wheels for CyPari2 on PyPI are indeed statically linked and 
self-contained.  So CyPari2 is a good example of a Python package the fully 
supports both modes.  (Unlike CyPari, which only supports "Python pip", 
though unlike CyPari2 it does work on Windows.)
 

Also, probably it should be mentioned that linux distro way/pip way 
can be very nicely combined using a python venv. 
So one can use system packages, but add up more packages, and, if 
needed, override system packages with other versions.


Agreed!

Best,

Nathan


-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/c9c1ac2d-2f04-4e36-97f6-dc43ff12a0b0n%40googlegroups.com.

Re: [sage-devel] Re: Urgent and important: Please vote on disputed PR #36964 (next step of the modularization project)

[Nathan Dunfield]

On Wednesday, April 24, 2024 at 2:26:37 PM UTC-5 Oscar Benjamin wrote:

Thanks Marc. This seems like a good example of a useful part of Sage 
that can be extracted to something much smaller than Sage. 

Presumably though a hypothetical person who wants CyPari2 but not all 
of Sage can already just use CyPari so that person is already well 
served. 


Correct.
 

Is the plan that CyPari2 would effectively replace CyPari? Then the benefit 
is not needing to maintain CyPari separately from 
sagelib's CyPari2 dependency?


No, rather CyPari is an example of the sort of free-standing Python package 
that could be extracted from Sage.  Modularization would create more of 
these, in varying sizes and levels of granularity.

Some level of modularization is necessary to address what William Stein 
described last year as:

*The fundamental and massive problem that I think SageMath has is that it 
is not part of the  Python ecosystem,*
*by which I mean that there is no good way to do "pip install 
sagemath-[foo]", in sufficient generality.*

*PROBLEM: SageMath is not part of the Python ecosystem.*

*DEFINITION: A piece of software is part of the Python ecosystem, if you 
can do "pip install " on*
*basically the same platforms as the intersection of where you can install 
scipy/numpy/matplotlib/pandas,*
*and with somewhat comparable resource usage (i.e., installing Sagemath 
can't use 100x of the time/space of*
*the above, as that would be unfair).*

On a related note, the reason that CyPari2 and CyPari are still separate 
relates to what Marc mentioned earlier about tension between two models of 
installing software: the "Linux distro way" using a system-level package 
manager (where there is typically only one version of any given library on 
the system) and the "Python pip" way (where all needed libraries are 
statically linked into the wheel).  CyPari2 follows the first, CyPari the 
second.  (This story is further complicated by the fact that, from a user's 
perspective, conda is like "Python pip" in that it is orthogonal to any 
system libraries, but developing packages for conda is akin to building 
them for a Linux distro.)

Of course, most projects in the scientific Python community support both 
models, but there is technical overhead in doing so, which I believe is the 
root of some of the current conflict.

Best,

Nathan

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/60a60056-f8e9-417e-b03a-1dcfcbc3c6ebn%40googlegroups.com.

Re: [sage-devel] Re: Urgent and important: Please vote on disputed PR #36964 (next step of the modularization project)

[Nathan Dunfield]

On Saturday, April 20, 2024 at 5:01:04 PM UTC-5 kcrisman wrote:

Can someone who is not Dima or Matthias explain to us how it is possible 
that they both are claiming to represent the normal Python way of doing 
things?  There have been numerous statements by both of them about this, 
which makes it sound like there are two pieces to it (modularization but 
also "de-vendoring"), and I can only assume that it would be possible for 
both to occur simultaneously.  It would be helpful for this to be 
clarified, though, so that one knows precisely what *piece* of their 
proposals represent the "normal Python ecosystem.


For the statements in this thread, I don't see any contradictions about the 
definition of the "normal Python way of doing things".  My understanding of 
that term is to post *self-contained* binary wheels to PyPI for all 
supported platforms that install in a minute or two with no compilation (as 
Dima wrote), as well as a source-code only package that serves as a 
rarely-used backup if no suitable binary is available.  (The self-contained 
bit is important; for example, on Linux here are the only external libraries 
 a binary wheel is 
allowed to link to.)

So far, we only post a source-code only package "sagemath-standard" on 
PyPI, and so "pip install sagemath-standard" is basically equivalent to 
downloading the tarball and running "configure/make".   As Matthias says 
"It takes very long. This alone makes it simply not suitable as a 
dependency of other pip-installable projects."

In particular, no one is arguing that Sage currently follows the "normal 
Python way", though we have made one step in that direction by posting the 
source-only package.

Best,

Nathan

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/680fd044-ffb6-4b86-a830-cc76b7f982afn%40googlegroups.com.

[sage-devel] Re: Proposal (redo): Make python_build (and its dependency pyproject_hooks) a standard package

[Nathan Dunfield]

+1: Using the PyPA standard build tools is a good move.

On Tuesday, April 9, 2024 at 10:44:36 PM UTC-5 Matthias Koeppe wrote:

> We added python_build as an optional "pip" package (see 
> https://deploy-livedoc--sagemath.netlify.app/html/en/developer/packaging#package-types
>  for 
> the terminology),
> - 
> https://deploy-livedoc--sagemath.netlify.app/html/en/reference/spkg/python_build#spkg-python-build
>  (added 
> in 2022).
>
> "python_build" (a.k.a. pypa/build) is the current standard front-end for 
> making source distributions and wheels from a Python source tree. It has 
> replaced the deprecated practices of calling "setup.py sdist" or "setup.py 
> bdist_wheel" directly. We already use it for building the modularized 
> distribution packages. Making it a standard package will allow us to 
> modernize the build infrastructure (front-end) for the Sage library in the 
> Sage distribution.
>
> I'm proposing to make it a standard package according to the procedures in 
> our developer guide. Per our policy, that's a "normal" package, so its 
> dependency pyproject_hooks will also be added. The PR is prepared in 
> https://github.com/sagemath/sage/pull/37300 
>
> This is a re-do of my proposal 
> https://groups.google.com/g/sage-devel/c/MIU-xo9b7pc/m/NsyUa7iXAgAJ whose 
> discussion was stalled by commenters bundling it with political demands. 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/13f7a510-d4e8-4a64-a037-eb0094845a33n%40googlegroups.com.

[sage-devel] Re: VOTE: Use "CI Fix" label for merging into continuous integration runs

[Nathan Dunfield]

+1

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/36943a81-ebb7-4dc8-920a-3e9ada379099n%40googlegroups.com.

[sage-devel] Re: VOTE: disputed PRs

[Nathan Dunfield]

+1

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/08598c62-0ab2-40da-859b-7437a1e4e989n%40googlegroups.com.

Re: [sage-devel] Re: [Proposal] allow standard packages to be pip packages, reduce source tarball size

[Nathan Dunfield]

On Monday, February 19, 2024 at 3:08:54 PM UTC-6 John H Palmieri wrote, 
responding to Dima:

You said: "The difference between wheel packages vs pip packages is that 
the latter don't require pre-fetched wheels, and absence of the need for 
package (micro)management." The implication is that changing the package 
management system is, maybe not part of this proposal, but a next step. In 
other words, I'm getting this impression from your words, not by other 
"certain parties."

You said: "My proposal is in fact aimed at reducing the number of pinned 
Sage dependecies, drastically." (You have made similar comments elsewhere 
in this thread.) How does (1) accomplish this? Either I'm missing something 
or you have not spelled everything out in your proposal.

You said '"Allow" does not mean "Make all of the", it should be obvious.'

"Allow" does not cause any changes to happen drastically. So what exactly 
are you proposing to accomplish these drastic changes? If you have a 
roadmap in mind, it would be helpful if you described it.


My understanding is that allowing standard packages to be pip packages 
could greatly reduce the number of pinned Sage dependencies for two reasons:

1) a build-from-source or wheel package must explicitly pin its version, 
but, more importantly,

2) a pip package is allowed to install additional dependencies of PyPI that 
are not recorded anywhere in the Sage repo.

A simple example is pytest.  Here it is as an optional pip package:

https://github.com/sagemath/sage/tree/develop/build/pkgs/pytest

To be upgraded to a standard package, under the current policy would need 
to be turned into a "wheel package" requires adding its dependencies like 
so:

https://github.com/sagemath/sage/pull/37301

Here, pytest has just a few dependencies, but jupyterlab has more like 50 
when you include dependencies of dependencies. 



Personally, I think the current system of having everything pinned and 
explicitly recorded is the right choice, being more stable in my experience 
with other projects.  In any event, switching to a pip package for e.g. 
jupterlab doesn't affect the final size or complexity of Sage as installed, 
just how many moving pieces there appear to be if you look in 
"sage/build/pkgs".

Best,

Nathan

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/f81b8284-cb48-44fe-a3f7-158be2438335n%40googlegroups.com.

Re: [sage-devel] Re: [Proposal] allow standard packages to be pip packages, reduce source tarball size

[Nathan Dunfield]

On Sunday, February 18, 2024 at 12:14:58 PM UTC-6 Dima Pasechnik wrote:

Reading: 
https://deploy-livedoc--sagemath.netlify.app/html/en/developer/packaging#package-source-types
 

The wheel you talk about is just another packaging of a source package, 
isn't it?


No.


Well, I might have used incorrect terminology, but our wheels are always 
"build from source" wheels.


No, many pure Python wheels are simply downloaded in the their final form 
from PyPI, for example:

https://github.com/sagemath/sage/tree/develop/build/pkgs/webcolors 
https://github.com/sagemath/sage/tree/develop/build/pkgs/jupyterlab

Best,

Nathan

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/9775f89c-4901-4a0f-a0e0-91b38c215f18n%40googlegroups.com.

Re: [sage-devel] Re: [Proposal] allow standard packages to be pip packages, reduce source tarball size

[Nathan Dunfield]

On Sunday, February 18, 2024 at 6:26:28 AM UTC-6 Dima Pasechnik wrote:

I cannot imagine CI breaking down by, say, pytest.


I can definitely see that happening, and indeed it seems to have done so 
for other projects:

https://github.com/pytest-dev/pytest/issues/9765
https://github.com/pytest-dev/pytest/issues/11983
 

Besides, you can pin down or limit the version of a pip package, just as 
well. E.g. pin down the version of Cython. But leave its dependencies out 
of Sage, as much as possible.


Leaving out dependencies doesn't eliminate complexity, it just hides it.  
That doesn't seem like an improvement to me.  Plus, some packages are 
dependencies of multiple other packages, and pip's ability to find a 
version of said dependency that all other packages will tolerate is not the 
greatest in my experience.

Best,

Nathan



-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/73328e5d-6e5a-4245-823f-957a3b2ef230n%40googlegroups.com.

Re: [sage-devel] Re: [Proposal] allow standard packages to be pip packages, reduce source tarball size

[Nathan Dunfield]

On Saturday, February 17, 2024 at 1:13:33 PM UTC-6 Dima Pasechnik wrote:

My proposal is in fact aimed at reducing the number of pinned Sage 
dependecies, drastically. 

Because most of them are either dependencies of Jupyterlab, or of Sphinx, 
or of Python build system, and none of the them should be Sage's concern to 
package, with all their dependencies.


In my experience, it's particularly important to pin build dependencies.  
Most of the "out of the blue" CI failures we've seen with "snappy" have 
been caused by new versions of build dependencies, especially Cython.  (I 
see that Cython was also one of the motivations for the "conda-lock" scheme 
of https://github.com/sagemath/sage/pull/35986 )

If you itch to pack the said dependencies, please do it in a separate 
repo/PyPI package, which can be consumed by sagelib to get the desired 
pinned dependencies (and test all this in the existing CI, why not?) 
But stop tying them up with sagelib - which in effect forces people 
interested in sagelib to slave away on packaging 300 dependencies, most of 
which aren't even tested by CI in any way, besides building.


It seems to me that the "wheel" type Sage packages, each of which is 
primarily just the version number of a file on PyPI and its hash, is like a 
"requirements.txt" file (or "conda-lock" file, for that matter) spread over 
multiple directories.  Personally, I don't view that as packaging a 
dependency, but rather saving some metadata to aid 
reliability/reproducibility.

Best,

Nathan

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/c1d9fe0f-c196-4fe3-b11f-2d8673f782a7n%40googlegroups.com.

Re: [sage-devel] Re: [Proposal] allow standard packages to be pip packages, reduce source tarball size

[Nathan Dunfield]

On Friday, February 16, 2024 at 11:17:37 PM UTC-6 Matthias Koeppe wrote:

If one does not care about the use case without internet access, then it's 
just the following:
- Pinning, as you mentioned (see also 
https://groups.google.com/g/sage-devel/c/5kmxaw105lg/m/9rF77fvFAAAJ above, 
where I discussed some details of this, including risks of leaving packages 
unpinned)
- Dependencies: "pip" packages can pull some of their build-time and 
run-time dependencies directly from PyPI, without us mirroring these 
dependencies in SageMath metadata. That's a mild convenience for 
developers, of importance if one wants to leave the version range wide 
open; but also has risks of instability.


Matthias, thanks for the clarification.  I think pinning the version of a 
"standard" package, including all its dependencies and down to the minor 
release, is likely the best approach.  Based on my experience with snappy 
[1], not pinning things will result in CI runs failing "out of the blue" 
because one of the dependencies got updated.  With a small project like 
snappy, this is pretty occasional and serves as a way to flag issues with 
new upstream releases, but with Sage my guess is that such failures would 
be frequent.   Suppose that each time the CI runs on a new PR, there's a 
10% chance of it failing because some completely unrelated dependency 
shifted; that would be a major annoyance to seasoned Sage developers and 
very discouraging to newcomers.  Now for a smaller package without (many?) 
dependencies, one can probably get away with pinning just down to the major 
release, but the benefit of doing that is pretty marginal.

So I am against allowing standard packages to be "pip" packages --- the 
"wheel" approach seems like the right tradeoff here as (a) the final 
package is sourced straight off PyPI so we don't have to build it (b) the 
result is completely stable.

Best,

Nathan
  
[1] https://snappy.computop.org

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/5b0a8e66-3b2c-48df-8287-258d8252decdn%40googlegroups.com.

Re: [sage-devel] Re: [Proposal] allow standard packages to be pip packages, reduce source tarball size

[Nathan Dunfield]

Dima mentioned "tox" [1] as an example of a "standard" package that would 
benefit from being switched to a "pip" package.  The "tox" package is pure 
python, so could also made a "wheel" package, which are already allowed for 
standard package, for example [2].  I'm having difficultly understanding 
the practical differences between a "wheel" package and a "pip" packages in 
this setting.  With "wheel", the wheel is downloaded from PyPI and put in 
upstream/ by various GH actions and put in the sage tarball and copied over 
to the sage mirrors, whereas with "pip" it is only downloaded by pip itself 
when an end-user builds Sage.  But in terms of developer effort, the only 
difference I see between "wheel" and "pip" is that the former has a few 
extra checksums, compare [2] and [3].  What distinctions am I missing?  Is 
it that a "wheel" must be pinned to a specific release on PyPI whereas 
"pip" can specify a range?

Best,

Nathan

[1] https://github.com/sagemath/sage/tree/develop/build/pkgs/tox
[2] https://github.com/sagemath/sage/tree/develop/build/pkgs/webcolors
[3] https://github.com/sagemath/sage/tree/develop/build/pkgs/snappy

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/30bb7f74-e4f0-4122-84a7-7e7fb3db1f99n%40googlegroups.com.

Re: [sage-devel] Question about reading Sage documentation

[Nathan Dunfield]

On Thursday, June 29, 2023 at 8:50:27 PM UTC-5 Marc Culler wrote:

I was asking a very specific question about SageMath on Ubuntu 22.04: Are 
Ubuntu 22.04 users who install the sagemath-doc package able to read those 
(Sage 9.5) docs with Firefox?


I tested this and the answer thankfully is yes.  The sagemath-doc packages 
installs the docs into /usr/share/doc which is one place that Firefox has 
access to, I believe 
via: https://snapcraft.io/docs/the-system-package-doc-interface

Best,

Nathan

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/5cecaedd-8595-4c5d-a894-398d0f0c07dfn%40googlegroups.com.

Re: [sage-devel] Modularization project: I. The goals

[Nathan Dunfield]

On Monday, June 12, 2023 at 2:58:18 PM UTC-4 Matthias Koeppe wrote:

What parts of Sage does SnapPy use? 


Primarily the various rings/fields, including matrices over them and basic 
linear algebra.  Specifically, interval arithmetic 
(Real/ComplexIntervalField), polynomial rings (in several variables, 
including Laurent polynomials), number fields, and the basic rings ZZ, QQ, 
GF, RealField, ComplexField, etc.  Also, the ptolemy submodule uses Sage 
for groebner_basis calculations.  I suspect most of what we use would be 
part of any initial pip-installable version of the Sage library.  Right 
now, in the stand-alone apps we backstop some of Sage's functionality (e.g. 
arbitrary precision floats) with CyPari, which is itself an example of part 
of Sage being modularized. 

Best,

Nathan

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/4b14371d-b528-4b43-b350-5920259c88e1n%40googlegroups.com.

Re: [sage-devel] Modularization project: I. The goals

[Nathan Dunfield]

For the SnapPy project [1], modularization of Sage would very useful.  
Currently, we provide SnapPy as a stand-alone GUI application on Windows 
and macOS and as a pip-install Python module on those platforms plus 
Linux.  When used in Sage, the SnapPy module gains extra functionality by 
leveraging various parts of sage.all, including features that are of high 
interest to our users.  It would be fantastic if we could include those in 
the stand-alone applications (including on Windows, which accounts for 2/3 
of the downloads of the full application).

Best,

Nathan

[1] https://snappy.computop.org

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/1391e2d0-d8bc-423d-9f7a-ee19a8e2939dn%40googlegroups.com.

Re: [sage-devel] VOTE: move Sage development to Github

[Nathan Dunfield]

+1 for GitHub

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/d639d283-afe5-409c-8eb3-72f5abb92551n%40googlegroups.com.

Re: [sage-devel] Re: incremental migration to github? [prompted by FUNDING issues!!!] + general flakiness of trac

[Nathan Dunfield]

I think moving to GitHub makes total sense.  Every other open-source math 
project I use regularly is on GH, and there are big network-effect benefits 
to being where everyone else is as others have already pointed out: easier 
for others to contribute, easier to get credit for contributions, easier 
cross references to issues up and downstream, etc.  Given the range of 
projects that use GH, including those like numpy and scipy whose issue/PR 
counts are similar to the number Sage trac tickets, I'm sure any technical 
or workflow issues have already been overcome by others and the solutions 
are likely even documented.  Given the open-source community's reliance on 
GH, any serious misbehavior on GH's part would result in a massive pushback 
and, if necessary, a concerted effort by a huge number of people to work 
out an alternative.

Nathan

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/59ec7a86-18c7-4296-84d9-04c250ec27b6n%40googlegroups.com.

[sage-devel] Re: Polling for sphinx background style

[Nathan Dunfield]

detoned > grayish >> original

In grayish, the color for large code blocks is nearly the same as that for 
inline code (which is also used for methods), so some visual information is 
lost compared to detoned.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/feaf0b42-3ac8-4fee-a081-6b0a4a0ef287n%40googlegroups.com.

[sage-devel] Re: Polling for pygments style for our future doc

[Nathan Dunfield]

I prefer sphinx with default as my second choice.

I like the colors in tango, but making all the output in italic is really 
ugly, especially with the larger matrices in

https://2505ea042169d8a179d4b1f28a0c0baeabdd421a--sagemath-tobias.netlify.app/tutorial/tour_linalg.html

Best,

Nathan

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/5ecaa751-6057-4235-9fc4-ecdc37788b4an%40googlegroups.com.

[sage-devel] Re: arctanh vs. artanh

[Nathan Dunfield]

Mathematica, Maple, and numpy all use "arctanh"; MATLAB uses "atanh".  It's 
"arctanh" in the NIST Digital Library of Mathematical Functions as well:

https://dlmf.nist.gov/4.37

It is the case that "ar-" prefix is the current ISO standard, and per the 
Wikipedia talk page the "ar-" prefix is more common in the non-English 
literature, but I'm not aware of any computer algebra system that uses it.  
So I would not support changing away from "arc-" as the default.

Best wishes,

Nathan

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/947becfa-9b63-4973-b046-1e9e20fb8c63n%40googlegroups.com.

[sage-devel] Re: Questions about what directory and files are safe to delete.

[Nathan Dunfield]

On Tuesday, March 8, 2022 at 9:04:22 PM UTC-6 John H Palmieri wrote:

> In theory you should be able to run "make micro_release". 
>

This mostly works, though it fails to strip some binaries which were moved 
in Sage 9.5.  See https://trac.sagemath.org/ticket/33409

Nathan


-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/d2240440-64ad-4dce-a8c4-e9d77307a5b3n%40googlegroups.com.

Re: [sage-devel] Re: Demote SageTeX to an optional package?

[Nathan Dunfield]

On Monday, December 6, 2021 at 8:39:23 AM UTC-6 Michael Orlitzky wrote:

>
> Does "sage -i" not work either? (Is there a ticket for fixing it?)
>

It doesn't with the recommend macOS binaries, nor does it if you install 
SageMath via conda ("make: *** No rule to make target 'all-toolchain'.  
Stop"). I haven't tried the linux "sage-as-distribution" binaries recently.

Nathan

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/2f64dde5-24c9-40ee-9df9-109939d936e0n%40googlegroups.com.

[sage-devel] Re: Demote SageTeX to an optional package?

[Nathan Dunfield]

I'd be extremely hesitant to remove something that's been a standard 
package for over a decade unless it was causing major headaches.  I could 
be wrong, but isn't SageTeX just a couple files totaling under 25K?

The vast majority of SageMath users install it from binaries; tell them to 
run "make sagetex" or mess with "configure" would not help them.

Best,

Nathan





-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/b199a1ca-0f7c-4a3a-8ad1-e206f7f4deafn%40googlegroups.com.

[sage-devel] Re: How to modularize for fun and profit, II: MONOREPO vs. MULTIREPO

[Nathan Dunfield]

On Sunday, October 10, 2021 at 7:17:33 PM UTC-5 Matthias Koeppe wrote:

> *Recommendation:* Keep MONOREPO for all distributions that fill the 
> sage.PAC.KAGE.MODULE namespace (= distribution packages named *sagemath-... 
> *-- according to my recommendation in part I). 
>
> *Recommendation: *For distributions that do not use the 
> sage.PAC.KAGE.MODULE namespace (= distribution packages named something 
> other than sagemath-... -- according to my recommendation in part I), weigh 
> the benefits vs. drawbacks of MONOREPO vs. MULTIREPO. It is also simple 
> enough for a distribution to start out being developed inside of the Sage 
> MONOREPO and to be split out to a separate repository later.
>

I think these are the right choices, at least for now.  Once modularization 
is complete, perhaps MULTIREPO becomes viable, as it is for scipy, but 
until the work is done I don't think it is clear how one would want to 
subdivide it.

Best,

Nathan

 

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/a8470cc0-a3dc-419c-9fd0-c892168bb20cn%40googlegroups.com.

Re: [sage-devel] Re: Sage no longer working in Binder

[Nathan Dunfield]

On Thursday, September 30, 2021 at 10:53:46 AM UTC-5 wrote:

> My understanding is that the Sage-9.3 and Sage-9.4 binaries are broken 
> on a large number of machines due to an issue with how openblas was 
> built. You probably have to use a sage-9.2 docker container, or wait 
> for sage 9.5 to come out.
>

This is moot since Eric has reported OP is using 9.1, but at least on macOS 
both Jupyter and Sage start fine even with the openblas problem --- you 
need to import numpy (or similar) to get a crash.

Nathan

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/d6e11695-2ca8-4807-85be-625da3bc4a7fn%40googlegroups.com.

Re: [sage-devel] Re: #32532 - removing gcc and gfortran spkgs

[Nathan Dunfield]

On Friday, September 24, 2021 at 1:12:38 PM UTC-5 William Stein wrote:

> I assume you are talking about the official binaries that are distributed 
> on Sagemath.org.  Fortunately, the Sage binaries on 
> MacOS that are produced by the conda-forge devs are not total crap.  
>

William,

There are two different Sage binaries for macOS referred to on 
SageMath.org.  The first, which is the recommended one is:

https://github.com/3-manifolds/Sage_macOS/releases

created by Marc Culler over the past year and is very far from total crap.  
While it does not yet support the M1 natively, it does offer a code-signed 
and notarized app that is just as easy to install as Mathematica et al.  
 (Note that the JupyterLab App is *not* notarized so one gets the "macOS 
cannot verify that this app is free from malware" message and have to go 
through System Preferences to run the installer.)

The second is the old:

http://mirrors.mit.edu/sage/osx/intel/index.html

Best,

Nathan



-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/976d7e64-ddb8-438a-b621-187547ccf29an%40googlegroups.com.

Re: [sage-devel] alternative approach to distributing sage -- jupyterlab_app

[Nathan Dunfield]

>
> > Signing is a bit tricky to set up.
>>
>> Is that mainly due to paying the Apple Developer subscription fee?
>>
>
> Yes, and the fact that I don't have a macOS machine with a GUI to try 
> things out.
> I only have access to a macOS machine through SSH.
>

Maybe the conda or JupyterLab community has tools for this, but Marc 
Culler's experience with [1] is that getting the Apple Developer 
subscription solves at most 10% of the problem.  If one is building an 
application with Xcode, then signing is trivial, but for apps built with 
other tools it's a tedious trial-and-error process as Apple's documentation 
on what is allowed in a code-signed bundle is very poor.  You sign the 
code, upload to Apple, have it rejected, study the error message, and 
repeat.

Best,

Nathan

[1] https://github.com/3-manifolds/sage_macOS


-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/e9d3854a-d728-4389-bede-21489efb5fe8n%40googlegroups.com.

[sage-devel] Re: failed in "sage -f python3" on M1 MacBook Pro with macOS Big Sur 11.1

[Nathan Dunfield]

I recommend installing either of 

https://github.com/3-manifolds/Sage_macOS/releases/tag/v1.0

or 

https://github.com/3-manifolds/Sage_macOS/releases/tag/v1.2-rc.0

which despite the description has been reported to run on M1 macs.   (The 
9.3 releases at the same site do not work on M1 processors.)

These both will function under Rosetta.  If you want to run Sage on an M1 
natively, use Conda:  

https://groups.google.com/g/sage-devel/c/l0Kv4InEDiI/m/9JEEJ7KyCwAJ

Best,

Nathan



On Friday, August 13, 2021 at 3:28:03 AM UTC-5 Allison Li wrote:

> Hi,
>
> When I launched Sage, Jupyter server was not started. Following its error 
> log, I installed ssl and then tried to build python3 with "sage -f 
> python3", but it failed in configuring python3-3.8.5.  Could you please 
> help?
>
> My computer: MacBook Pro (13-inch, M1, 2020)
>
> Operating system: macOS Big Sur 11.1
> The build log file is attached.
>
> $PATH:  
> /Applications/SageMath-9.2.app/Contents/Resources/sage/build/bin:/Applications/SageMath-9.2.app/Contents/Resources/sage/src/bin:/Applications/SageMath-9.2.app/Contents/Resources/sage/local/bin:/Applications/SageMath-9.2.app:/Applications/SageMath-9.2.app/Contents/Resources/sage/local/bin/:/opt/homebrew/opt/openssl@1.1/bin:/opt/homebrew/bin:/opt/homebrew/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin
>
> Thanks!
> -AL
>
> PS: brief output:
>
> [python3-3.8.5] configure: error: Unexpected output of 'arch' on OSX
>
> [python3-3.8.5] 
> 
>
> [python3-3.8.5] Error configuring python3-3.8.5 See the file
>
> [python3-3.8.5] 
> /Applications/SageMath-9.2.app/Contents/Resources/sage/local/var/tmp/sage/build/python3-3.8.5/src/config.log
>
> [python3-3.8.5] for details.
>
> [python3-3.8.5] 
> 
>
> [python3-3.8.5] real 0m13.347s
>
> [python3-3.8.5] user 0m6.534s
>
> [python3-3.8.5] sys 0m4.743s
>
> [python3-3.8.5] 
> 
>
> [python3-3.8.5] Error building package python3-3.8.5
>
> [python3-3.8.5] 
> 
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/3c7e4b36-1534-45ae-8529-7ad8e33cb546n%40googlegroups.com.

[sage-devel] Re: proposal - remove gcc, gfortran, python building/spkgs

[Nathan Dunfield]

On Thursday, June 24, 2021 at 1:16:29 PM UTC-5 Matthias Koeppe wrote:

> Strong -1 on this.
> Given the troubles that we have every time that a major gcc version shows 
> up in distributions (we still do not have GCC 11 support -
> https://trac.sagemath.org/ticket/31786), and given the trouble that we 
> had most recently with faulty homebrew packaging of python3, this would 
> dramatically limit our options.
>

I have benefitted a lot from Sage providing the option of compiling its own 
gcc when building Sage for academic computer clusters.  Such clusters often 
run a very old OS with truly ancient compilers.  For example, the main one 
I use until a year ago was on Centos 6 with gcc 4.8 and  6.1; now it runs 
Centos 7 (first released 2014!) and gcc 9.3 is available.  With regards to 
conda, I'm not sure it's a cure-all: when Sage 9.0 came out this cluster's 
gcc was so old that it couldn't compile Sage's preferred gcc, so I tried 
with that gcc provided by conda. I still never managed to get Sage to 
build, IIRC due to competing system libraries and those in $CONDA_ROOT, so 
I just used conda to install all of Sage in binary form.  Which was very 
convenient, though I lost the ability to install optional spkg's as a 
result.

Still, I can see that it might be more robust to have users try to install 
gcc via a package manager rather than build it from source.  But on the 
flip side, having Sage build its own Python is surely increases the 
probability of a successful build.  If the users compiler and tool chain 
can't build Python, it almost certainly will choke on some much less robust 
component of Sage and the extra isolation of Sage having it's own Python 
surely prevents all sorts of headaches...

Best,

Nathan


-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/0d31810f-7775-4da8-80f4-51cc0ff3f874n%40googlegroups.com.

Re: [sage-devel] Safari not showing three.js plots

[Nathan Dunfield]

Ticket created at https://trac.sagemath.org/ticket/31983

On Saturday, June 12, 2021 at 4:08:26 AM UTC-5 dim...@gmail.com wrote:

> On Sat, Jun 12, 2021 at 12:33 AM Nathan Dunfield  
> wrote:
> >
> > With Sage 9.3 on macOS Catalina and default browser set to Safari 
> 14.1.1.1, if I open a Terminal.app window, start sage, and type:
> >
> > sage: var('x, y')
> > sage: plot3d(x^2 + y^2, (x, -1, 1), (y, -1, 1))
> >
> > an essentially blank webpage opens in Safari (there is the little "i in 
> a circle" menu in the lower-right corner but no plot).
>
> same on macOS 11.4
>
>
> >
> > On the same system, the plot appears fine if I switch to Chrome or 
> Firefox. Moreover, if in Safari I turn on the developer menu, it works ok 
> there as well.
> >
> yes, the same with Develop menu here on 11.4, as well.
>
>
> > Based on my testing, I believe that, with the developer menu off, Safari 
> will not pull in script files when they are not located at or below the 
> location of the html file. Specifically, I copied one of the tmp_hash.html 
> files to the attached “bad_sage.html” and played with different locations 
> and values of the “script src” for “three.min.js”. For example, in is 
> current form, if I put a copy of “three.min.js” in $HOME then Safari opens 
> “bad_sage.html” when it in $HOME but not if the html file is in 
> $HOME/Desktop or /tmp.
> >
> > Is this a known problem? I could not find any reference to it on trac.
> >
> > Thanks,
> >
> > Nathan
> >
> >
> >
> >
> > --
> > You received this message because you are subscribed to the Google 
> Groups "sage-devel" group.
> > To unsubscribe from this group and stop receiving emails from it, send 
> an email to sage-devel+...@googlegroups.com.
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-devel/59e8e251-0157-4900-8aeb-654449f29c80n%40googlegroups.com
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/59f4165c-8f08-4e83-84ac-3136e297aceen%40googlegroups.com.

[sage-devel] Re: sage9.3 verification error for python3 on MacOS Big Sur

[Nathan Dunfield]

Try this 
version: https://github.com/3-manifolds/Sage_macOS/releases/tag/v1.1-beta

On Monday, May 24, 2021 at 10:04:06 AM UTC-5 Udo Baumgartner wrote:

> Hi, 
>
> I installed the new sage9.3 which according to release notes supports Mac 
> OS Big Sur on intel machines. However, when I launch I get the the 
> following error message:
>
> *“python3.9” cannot be opened because the developer cannot be verified.*
>
> I did not encounter that problem with the app-versions I usually use, in 
> particular with 9.2 (which however has other problems). When I was forced 
> to install myself to get access with sage9.1 to some data computed with 
> earlier versions I seem to recall there was an analogous error. However, an 
> app-version of sage appears not to be available for version sage9.3. 
>
> How do I fix this? I searched for information on this but was unsuccessful.
>
> Help would be very much appreciated. 
>
> Best, 
>
> Udo 
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/bb0204e6-747d-466d-86fa-e45e4f8419d4n%40googlegroups.com.

Re: [sage-devel] Comparing RealIntervalField elements with floats

[Nathan Dunfield]

On Apr 10, 2021, at 8:59 PM, Matthias Koeppe  wrote:
> Sounds like what is described in 
> https://wiki.sagemath.org/ReleaseTours/sage-9.3#Numerics

Thanks, we will adjust SnapPy to match https://trac.sagemath.org/ticket/15114

Nathan

> 
> On Saturday, April 10, 2021 at 6:45:09 PM UTC-7 Nathan Dunfield wrote:
> In Sage 9.2 and earlier one has:
> 
> sage: RIF(1.0) < 2.0
> True
> sage: RIF(1.0, 3.0) < 2.0
> False
> 
> but in Sage 9.3beta8 (most recent docker image) such comparisons raise the 
> below exception. 
> 
> ---
> TypeError Traceback (most recent call last)
>  in 
> > 1 RIF(RealNumber('1.0')) < RealNumber('2.0')
> 
> ~/sage/local/lib/python3.9/site-packages/sage/structure/element.pyx in 
> sage.structure.element.Element.__richcmp__ 
> (build/cythonized/sage/structure/element.c:10370)()
>1109 return (self)._richcmp_(other, op)
>1110 else:
> ->  return coercion_model.richcmp(self, other, op)
>1112 
>1113 cpdef _richcmp_(left, right, int op):
> 
> ~/sage/local/lib/python3.9/site-packages/sage/structure/coerce.pyx in 
> sage.structure.coerce.CoercionModel.richcmp 
> (build/cythonized/sage/structure/coerce.c:20790)()
>2004 # so we raise an exception.
>2005 if op == Py_LT:
> -> 2006 raise bin_op_exception('<', x, y)
>2007 elif op == Py_LE:
>2008 raise bin_op_exception('<=', x, y)
> 
> TypeError: unsupported operand parent(s) for <: 'Real Interval Field with 53 
> bits of precision' and 'Real Field with 53 bits of precision'
> 
> Is this change intensional or is this a regression?  I noticed because some 
> of SnapPy's doctests fail on 9.3beta8.
> 
> Thanks,
> 
> Nathan
> 
> 
> 
> -- 
> You received this message because you are subscribed to a topic in the Google 
> Groups "sage-devel" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/sage-devel/_Ajyfl4qiSo/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> sage-devel+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-devel/862203f0-5025-41bb-a78a-25fac7165183n%40googlegroups.com.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/6BA352DA-4895-4EF2-8BB5-ECED7CCCB2E3%40gmail.com.

[sage-devel] Comparing RealIntervalField elements with floats

[Nathan Dunfield]

In Sage 9.2 and earlier one has:

sage: RIF(1.0) < 2.0
True
sage: RIF(1.0, 3.0) < 2.0
False

but in Sage 9.3beta8 (most recent docker image) such comparisons raise the 
below exception. 

---
TypeError Traceback (most recent call last)
 in 
> 1 RIF(RealNumber('1.0')) < RealNumber('2.0')

~/sage/local/lib/python3.9/site-packages/sage/structure/element.pyx in 
sage.structure.element.Element.__richcmp__ 
(build/cythonized/sage/structure/element.c:10370)()
   1109 return (self)._richcmp_(other, op)
   1110 else:
->  return coercion_model.richcmp(self, other, op)
   1112 
   1113 cpdef _richcmp_(left, right, int op):

~/sage/local/lib/python3.9/site-packages/sage/structure/coerce.pyx in 
sage.structure.coerce.CoercionModel.richcmp 
(build/cythonized/sage/structure/coerce.c:20790)()
   2004 # so we raise an exception.
   2005 if op == Py_LT:
-> 2006 raise bin_op_exception('<', x, y)
   2007 elif op == Py_LE:
   2008 raise bin_op_exception('<=', x, y)

TypeError: unsupported operand parent(s) for <: 'Real Interval Field with 
53 bits of precision' and 'Real Field with 53 bits of precision'

Is this change intensional or is this a regression?  I noticed because some 
of SnapPy's doctests fail on 9.3beta8.

Thanks,

Nathan


-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/5ac290b2-38b0-40d0-883b-4920cb8a2355n%40googlegroups.com.

[sage-devel] Re: [macOS] New beta app by Marc Culler

[Nathan Dunfield]

The first full release of this app has been posted at:

https://github.com/3-manifolds/Sage_macOS/releases/tag/v1.0

A trac ticket to update the Sage docs to mention it is here:

https://trac.sagemath.org/ticket/31638

Additionally, perhaps it should be linked to at e.g.

http://mirrors.mit.edu/sage/osx/intel/index.html

In my testing, I have found it much superior to the current binaries on 
newer versions of macOS, solving many of the issues that keep coming up on 
macOS on sage-support and sage-devel.

Best,

Nathan

On Friday, April 9, 2021 at 7:24:13 PM UTC-5 enis...@gmail.com wrote:

> I tried it out! It is very slick. It resolves many issues with the current 
> .app.dmg that can easily scare away newcomers.
>
> On Sunday, April 4, 2021 at 3:47:30 PM UTC-7 Nathan Dunfield wrote:
>
>> Dear Sage folks,
>>
>> Marc Culler has been working on a fully signed and notarized version of 
>> the SageMath binary for macOS, with the goal of eliminating the many 
>> problems plaguing Sage on that platform caused by Apple's gatekeeper 
>> antimalware protections.  He now has posted a beta version at:
>>
>> https://github.com/3-manifolds/Sage_macOS/releases/tag/v1.0-beta.2
>>
>> and needs as many people to try it out as possible and report any 
>> problems on the GitHub issue tracker.  
>>
>> The app supports macOS High Sierra, Mojave, Catalina, and Big Sur and can 
>> run Sage either in a terminal window or as a Jupyter notebook.  Please try 
>> it out!
>>
>> I should emphasize that I am just the messenger and the credit for all 
>> the hard work leading to this huge step forward in providing a 
>> user-friendly macOS binary is entirely due to Marc (
>> https://marc-culler.info/).
>>
>> Thanks,
>>
>> Nathan
>>
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/8ae08e21-829e-4d24-b21b-9394b964edd8n%40googlegroups.com.

[sage-devel] [macOS] New beta app by Marc Culler

[Nathan Dunfield]

Dear Sage folks,

Marc Culler has been working on a fully signed and notarized version of the 
SageMath binary for macOS, with the goal of eliminating the many problems 
plaguing Sage on that platform caused by Apple's gatekeeper antimalware 
protections.  He now has posted a beta version at:

https://github.com/3-manifolds/Sage_macOS/releases/tag/v1.0-beta.2

and needs as many people to try it out as possible and report any problems 
on the GitHub issue tracker.  

The app supports macOS High Sierra, Mojave, Catalina, and Big Sur and can 
run Sage either in a terminal window or as a Jupyter notebook.  Please try 
it out!

I should emphasize that I am just the messenger and the credit for all the 
hard work leading to this huge step forward in providing a user-friendly 
macOS binary is entirely due to Marc (https://marc-culler.info/).

Thanks,

Nathan


-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/12a9c764-2412-4733-a3bc-f82eceabebb5n%40googlegroups.com.

Re: [sage-devel] distro packaging, docbuilding and modularisation

[Nathan Dunfield]

On Wednesday, March 10, 2021 at 4:50:41 AM UTC-6 Dima wrote:

> numpy does this:
> https://numpy.org/devdocs/docs/howto_build_docs.html
>
> you can only build numpy docs after numpy is installed.
>

Of course, with numpy "installed" doesn't necessarily mean installed in the 
main site-packages, you can use a virtualenv.  Then you delete the 
virtualenv once the docs are built and install the module and the docs for 
real.  It's hard to avoid something like this if using Sphinx's autodoc 
features that actually import the Python module and build the docs from the 
docstrings it finds.

Sage is likely too complicated for this to work, but you can skip the 
virtualenv step by having Sphinx work off the copy of the in 
"build/lib.macosx-10.9-x86_64-3.9" or similar.  This is the trick we use 
with 
SnapPy:  https://github.com/3-manifolds/SnapPy/blob/master/doc_src/conf.py

Nathan

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/bef870a4-de6d-4f17-a761-227b3902a92dn%40googlegroups.com.

Re: [sage-devel] Re: Downgrade R to optional? See #31409.

[Nathan Dunfield]

An update: I just tried three different binary versions on Linux: The 
Ubuntu 20.04 binary posted at SageMath.org, the sagemath/sagemath:develop 
Docker image, and conda on RHEL 7.  None of them "just worked" with "sage 
-i foo".  The Docker image and conda failed completely with

make: *** No rule to make target 'all-toolchain'.  Stop.

I got farther with the Ubuntu binary.  Choosing "sage -i pyflakes", it 
successfully pip-installed pyflakes and then started rebuilding all of Sage 
from scratch, starting with libpng, pkgconf, etc.  So in some sense this 
worked --- I was able to abort the build and import pyflakes --- but in the 
end was equivalent to building Sage from source if I hadn't stopped it.  

Best,

Nathan




On Tuesday, March 9, 2021 at 9:00:22 AM UTC-6 Nathan Dunfield wrote:

> To what extent does installing optional packages "just work" with the 
> current binary distributions of Sage?  I'm thinking of both those posted on 
> sagemath.org as well as things not directly under our control such as the 
> sage packages for conda, debian, gentoo, etc.  My past experience has been 
> that "sage -i foo" works only if I had built Sage from source, though I 
> haven't tried any of the binaries recently.
>
> I bring this up because the user impact of moving R or any other package 
> to optional depends tremendously on whether "sage -i R" just works.  If 
> switching R to optional is tantamount to requiring users of R to build all 
> of Sage from source, that would be very disruptive for those users of R in 
> Sage.  Building Sage from source  is a huge hurdle for 95% users and a 
> nontrivial hassle for the rest.
>
> Best,
>
> Nathan
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/4c6b267c-b29d-4aae-8bbd-f52f7f9ae820n%40googlegroups.com.

Re: [sage-devel] Re: Downgrade R to optional? See #31409.

[Nathan Dunfield]

To what extent does installing optional packages "just work" with the 
current binary distributions of Sage?  I'm thinking of both those posted on 
sagemath.org as well as things not directly under our control such as the 
sage packages for conda, debian, gentoo, etc.  My past experience has been 
that "sage -i foo" works only if I had built Sage from source, though I 
haven't tried any of the binaries recently.

I bring this up because the user impact of moving R or any other package to 
optional depends tremendously on whether "sage -i R" just works.  If 
switching R to optional is tantamount to requiring users of R to build all 
of Sage from source, that would be very disruptive for those users of R in 
Sage.  Building Sage from source  is a huge hurdle for 95% users and a 
nontrivial hassle for the rest.

Best,

Nathan

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/e2bd0b88-baea-4c7d-94b8-9f519addd2d3n%40googlegroups.com.

[sage-devel] Re: Sage Installation Issues on mac

[Nathan Dunfield]

Masoud,

I suggest you try: https://github.com/3-manifolds/fix_mac_sage

Best,

Nathan

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/ace51625-735a-4ad2-8d7e-76a8af7aac68n%40googlegroups.com.

Re: [sage-devel] Re: "Real Field" -> "Real Floating-point Field"

[Nathan Dunfield]

>
> My perspective is partly coming as someone who has several papers that 
>> rely heavily on Sage computations. I've archived the code and data in a 
>> permanent fashion, but every backwards incompatible change Sage makes 
>> decreases the odds that anyone will be able to easily verify or extend my 
>> work five years from now. 
>>
>
> one needs to maintain the code, one can't just hope it will all magically 
> keep working in newer versions (it won't be true even if it was in plain 
> Python).
>
> And in this case a fix is trivial.  (and you have a chance to check along 
> the way that it is still working)
>

Yes, I am all too well-aware that all code requires some level of 
maintenance.  The question is how often and how much, and I don't think the 
fact that maintenance is inevitable is a good argument for increasing the 
amount required unnecessarily.  Especially in the context of software used 
by mathematical researchers.  Enough trivial changes add up to something 
nontrivial, and my main point is that for a lot of Sage users, something 
like this is not trivial and has the potential to turn mathematicians away 
from Sage to one of the "M" tools that are likely more stable (I'm not sure 
about that, I of course avoid the M's when at all possible ;-).

Nathan

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/d714fefb-8925-4350-9422-0ebe1fb6ceccn%40googlegroups.com.

Re: [sage-devel] Re: "Real Field" -> "Real Floating-point Field"

[Nathan Dunfield]

>
> Well, seriously speaking, such drastic changes are needed sometimes, 
> and they demand a bump in the major version number, e.g. they can 
> happen in Sage 10.0. 
>
It takes a lot of effort for a newcomer to get that RR and CC are 
> basically RDF and CDF on steroids, to get the mysteries of AA, etc 
> etc. 
>

My perspective is partly coming as someone who has several papers that rely 
heavily on Sage computations. I've archived the code and data in a 
permanent fashion, but every backwards incompatible change Sage makes 
decreases the odds that anyone will be able to easily verify or extend my 
work five years from now.  Certainly, changing the meaning of RealField 
will break all of it.  As you say, such changes are sometimes necessary.  
However, if Sage can solve the same technical problem by calling the new 
real number overclass GenuineRealField (or whatever) rather than stealing 
the name of the current RealField, I am arguing that it is not. 

With regards to newcomers, I don't think having "RealField" be some 
abstract base class which is rarely what they need is going to help them, 
and any scheme for working with reals on a computer is going to be a bit 
complicated.  I will also point out that intermediate users hate-hate-hate 
having their old notebooks and code no longer work.  To any of us, fixing 
something like this is a simple search and replace after glancing at the 
traceback to realize what the issue is, but things like this are incredibly 
frustrating to more occasional users who view tracebacks as 
incomprehensible.

Best,

Nathan

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/128f0019-1979-4c17-a902-33528232f060n%40googlegroups.com.

[sage-devel] Re: "Real Field" -> "Real Floating-point Field"

[Nathan Dunfield]

-1: I don't really care what RealField.__repr__ returns, but cast a token 
no vote to object to the logical next move of breaking backwards 
compatibility by changing the meaning of RealField and/or RR.  I see the 
need for a "genuine real field", but it seems a lot simpler just to call it 
something other than "RealField" and so not break a lot of existing users' 
Sage code.

Best,

Nathan

On Wednesday, October 14, 2020 at 1:28:08 AM UTC-5 vdelecroix wrote:

> Dear all,
>
> I would like to discuss the patchbomb at
>
> https://trac.sagemath.org/ticket/24523
>
> The ticket hopes to change the string representation from
> "Real Field with XX bits of precision" to "Real Floating-point
> field with XX bits of precision".
>
> Rationale: it was quite unfortunate from the beginning that
> RealField and ComplexField mean "floating-point arithmetic".
> On the one hand, one would like to be able to work with the
> (abstract) Parent modeling the real numbers (eg for coercions).
> On the other hand, in the setting of computer algebra it is
> very often much better to work with interval arithmetic or
> balls rather than floating-point. The ticket is a small
> step towards getting the genuine "RealField" standing for
> the set of real numbers. See
>
> https://trac.sagemath.org/ticket/17713
>
> I think this deserves an agreement from other developers! Any
> comment very welcome.
>
> Best
> Vincent
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/cb5ad840-0ed1-4383-a806-cc5bbc8f4645n%40googlegroups.com.

[sage-devel] Re: Transition from jupyter notebook to jupyterlab

[Nathan Dunfield]

I use Jupyter with Sage somewhat regularly, and have tried out JupyterLab 
on several occasions.  I use Jupyter notebooks only when making a lot of 
plots as otherwise I prefer an editor+REPL setup.  In particular, I have 
not used it in any of my classes.

As mentioned, JupyterLab is more like an IDE than the classic Jupyter and 
so has a rather different feel.  Possibly as a consequence, my 
understanding is that adoption of JupyterLab over Jupyter classic in the 
general scientific computing community has been quite slow, with many 
people trying Lab and then sticking with Classic [1, 2, 3].  Classic 
Jupyter has a relatively simple interface that's good for beginning 
programers and other non-developers, but the editor in JupyterLab isn't as 
sophisticated as Emacs or VS Code and so it also doesn't appeal to many 
hard-core developers.  I tried Lab fairly early (around the first non-beta 
release) and at the time there were enough rough edges that I went back to 
Classic which had all the features I needed anyway.

I think Sage would be better off sticking with Jupyter Classic until a 
version of JupyterLab is available that can emulate Classic; otherwise, the 
interface switch will be fairly jarring to users, especially the less 
experienced ones for whom notebook interfaces are particularly appealing, 
in addition to all the technical hurdles.

Best,

Nathan

P.S. That said, one thing Lab is really great for is pulling a basic but 
serviceable development environment out of a Docker container.  I know 
people who have had success with this approach for undergraduate 
computational research projects.


[1] https://github.com/jupyterlab/jupyterlab/issues/8450
[2] 
https://discourse.jupyter.org/t/any-recent-usage-polling-on-jupyter-lab-vs-notebook-usage/4344/23
[3] 
https://discourse.jupyter.org/t/benefits-of-the-classic-ui-and-use-cases-for-classic-over-jupyterlab-was-why-is-tim-not-moving-to-lab/2419/3

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/95f6e7d7-4a80-4770-95ad-45b8aaa3269en%40googlegroups.com.

Re: [sage-devel] gsl build failure on Centos 6

[Nathan Dunfield]

On Friday, July 24, 2020 at 10:58:12 AM UTC-5, Isuru Fernando wrote:
>
> This is an issue with the openblas build. You might need 
> https://github.com/conda-forge/openblas-feedstock/blob/master/recipe/0002-Fix-gfortran-detection-for-ctng-based-cross-compilers.patch
>   
> (That patch was not sent upstream because it breaks other gcc builds. Need 
> to figure out a patch that works for all)
>

Thanks, I'll have a look.
 

> Also, I'm curious to hear more about the illegal instructions. We can fix 
> that if you report them. I'm a conda-forge maintainer.
>

Here you go, looks like the problem is in Linbox:

https://github.com/conda-forge/sage-feedstock/issues/57
 

> We also have Normaliz packaged in conda-forge.
>

When I try to install "normaliz", mamba wants to role back my version of 
"sagelib" from 9.1 to 9.0.  I will make a ticket for this too.

Thanks,

Nathan

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/8b253da1-dd9b-44c2-800e-660f758218cco%40googlegroups.com.

Re: [sage-devel] gsl build failure on Centos 6

[Nathan Dunfield]

On Friday, July 24, 2020 at 10:43:40 AM UTC-5, Dima Pasechnik wrote:
>
> Can you use gsl provided by Conda?
>
> If you run can Sage's ./configure with conda active then it will list 
> "system" packages to install.
>

I don't think so because having conda install gsl will cause it to install 
conda's openblas.  Originally, I tried the maximal-conda approach, 
installing as many of Sage's dependencies that way as possible (following 
the sage conda feedstock script), but then giac wouldn't build.  I then 
slowly reduced the number of conda packages installed, but there were 
(sometimes different) build problems for Sage with everything I've tried.  
Hence the "sage-as-distribution" approach I'm trying currently, which has 
worked for me in the past on this system, with many version of  Sage <= 8.4 
(though I never could get Sage 8.9 to build).

Nathan

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/8324c169-0508-4885-9fcb-dad5b711e6f0o%40googlegroups.com.

[sage-devel] Re: gsl build failure on Centos 6

[Nathan Dunfield]

>
> I am trying to build Sage 9.1 from source on Scientific Linux 6.10 
> (=Centos 6) using gcc 7.5 provided by Conda, and am having problems getting 
> gsl to build:
>
> [gsl-2.5] 
> /data/keeling/a/nmd/miniconda3/envs/sage_base_lite4/bin/../lib/gcc/x86_64-conda_cos6-linux-gnu/7.5.0/../../../../x86_64-conda_cos6-linux-gnu/bin/ld:
>  
> /data/keeling/a/nmd/pkgs/sage-9.1/local/lib/libopenblas.so: undefined 
> reference to `_gfortran_concat_string'  
>
> Attached are the logs for gsl, openblas, and config.  The config command 
> was:
>

Sorry, I should also have mentioned that I modified the environment 
variables FFLAGS and DEBUG_FFLAGS to remove "-fopenmp" before running 
"make" in the "sage-9.1" directory as openmp was causing problems with 
other spkgs.

Nathan 

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/4c91ef06-7673-415f-b47f-3a1829acc3a5o%40googlegroups.com.

[sage-devel] Re: -i openssl not working Mac OSX

[Nathan Dunfield]

Assuming you are using one of the recent binary packages for Sage 8.9 or 
9.0, you could also use the prebuilt openssl packages available here:

https://bitbucket.org/t3m/snappy/downloads/

Just download "mac_sage8.tgz" or "mac_sage9.tgz", unpack, and follow the 
instructions.

Nathan

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/b9b944e1-36da-45ec-b255-f7d8054bd477%40googlegroups.com.

[sage-devel] Re: sage_sample

[Nathan Dunfield]

>  * is there any example of a package using Travis CI testing on sage9 and 
> maybe with docker that I could use as an example?
>

Yes, we do that for SnapPy.  The relevant files are here:

https://github.com/3-manifolds/SnapPy/blob/master/.travis.yml
https://github.com/3-manifolds/SnapPy/blob/master/dev/build_and_test_in_sage.bash

Best,

Nathan

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/91cb27bd-696a-4dab-84fe-b2b5f5ca5a19%40googlegroups.com.

[sage-devel] Re: Get Python3 to build its ssl and tkinter modules on macOS

[Nathan Dunfield]

On Sunday, March 29, 2020 at 5:09:26 PM UTC-5, Samuel Lelievre wrote:
>
> Dear sage-devel,
>
> on macOS, is there a recommendation on how to
> get Python3 to build its ssl and tkinter modules
> when building Sage from source?
>
> I'm using macOS 10.14.6 Mojave.
>

This is not quite answering your question, but Marc Culler built a version 
of Tk 8.6.10 (all but very recent versions have issues on 10.14 and 10.15) 
and posted it here 

https://bitbucket.org/t3m/snappy/downloads

together with a small package "mac_sage9.tgz" which installs a version of 
"tkinter" and "openssl".  It targets the binary release, but should work if 
you build from source.

Best,

Nathan

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/cf7e2ea4-9069-4ee8-9d4d-a1314d3aee9e%40googlegroups.com.

[sage-devel] Re: sagemath 9.0 for MacOS is not linked with SSL

[Nathan Dunfield]

Unfortunately, no recent SageMath binary for macOS comes with a working SSL 
lib.  Two fixes:

1) Download "mac_sage9.tgz" from 

https://bitbucket.org/t3m/snappy/downloads/

unpack, and follow the instructions.

2) Assuming you have the XCode command line tools installed, the following 
usually works to enable SSL on SageMath 9.0:

/Applications/SageMath-9.0.app/sage -i openssl
/Applications/SageMath-9.0.app/sage -f python3

Note the second command will take quite some time to run as it will 
recompile much of the Sage library proper.

Best,

Nathan






On Monday, March 2, 2020 at 4:21:05 AM UTC-6, Junwei Wang wrote:
>
> (sage-sh) 
> junwei@jwang-imac:~/git/tool_whitebox-engine/web_service/services/api$ 
> which pip
> /Applications/SageMath-9.0.app/Contents/Resources/sage/local/bin/pip
> (sage-sh) 
> junwei@jwang-imac:~/git/tool_whitebox-engine/web_service/services/api$ pip 
> install tqdm
> pip is configured with locations that require TLS/SSL, however the ssl 
> module in Python is not available.
> Collecting tqdm
>   Retrying (Retry(total=4, connect=None, read=None, redirect=None, 
> status=None)) after connection broken by 'SSLError("Can't connect to HTTPS 
> URL because the SSL module is not available.")': /simple/tqdm/
>   Retrying (Retry(total=3, connect=None, read=None, redirect=None, 
> status=None)) after connection broken by 'SSLError("Can't connect to HTTPS 
> URL because the SSL module is not available.")': /simple/tqdm/
>   Retrying (Retry(total=2, connect=None, read=None, redirect=None, 
> status=None)) after connection broken by 'SSLError("Can't connect to HTTPS 
> URL because the SSL module is not available.")': /simple/tqdm/
>   Retrying (Retry(total=1, connect=None, read=None, redirect=None, 
> status=None)) after connection broken by 'SSLError("Can't connect to HTTPS 
> URL because the SSL module is not available.")': /simple/tqdm/
>   Retrying (Retry(total=0, connect=None, read=None, redirect=None, 
> status=None)) after connection broken by 'SSLError("Can't connect to HTTPS 
> URL because the SSL module is not available.")': /simple/tqdm/
>   Could not fetch URL https://pypi.org/simple/tqdm/: There was a problem 
> confirming the ssl certificate: HTTPSConnectionPool(host='pypi.org', 
> port=443): Max retries exceeded with url: /simple/tqdm/ (Caused by 
> SSLError("Can't connect to HTTPS URL because the SSL module is not 
> available.")) - skipping
>   Could not find a version that satisfies the requirement tqdm (from 
> versions: )
> No matching distribution found for tqdm
> pip is configured with locations that require TLS/SSL, however the ssl 
> module in Python is not available.
> Could not fetch URL https://pypi.org/simple/pip/: There was a problem 
> confirming the ssl certificate: HTTPSConnectionPool(host='pypi.org', 
> port=443): Max retries exceeded with url: /simple/pip/ (Caused by 
> SSLError("Can't connect to HTTPS URL because the SSL module is not 
> available.")) - skipping
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/b596fdb1-850b-4742-9700-555d9d32149c%40googlegroups.com.

[sage-devel] Re: Poll: make giacpy_sage a standard package

[Nathan Dunfield]

On Monday, February 3, 2020 at 4:52:44 PM UTC-6, Samuel Lelievre wrote:
>
> Please vote for making giacpy_sage a standard package.
>

+1

The "giacpy_sage" optional package is one I always install when I build 
Sage and it has been robust in my experience.  As others have said, given 
that giac itself is included, allowing Python direct access to giac at the 
C level rather than going through pexpect is clearly an improvement.

Nathan

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/802f92c6-549c-4ae1-9e50-b487f812e9bb%40googlegroups.com.

Re: [sage-devel] drop python2 compatibility in 9.1 ?

[Nathan Dunfield]

On Friday, January 10, 2020 at 8:11:43 AM UTC-8, William wrote:
>
> The main person that has valid reason to want longer support for python2 
>> is William.
>> As he mentions, he has paying customers.
>>
>
> I am 100% satisfied for my use case with cocalc by just keeping a copy of 
> sage-8.9 available longterm.   Fortunately, I don't need any sage-9.x 
> versions to support python2.
>

I think that for nearly all users, in practice sage < 9.0 will mean Python 
2 and sage >= 9.0 will mean Python 3.  There will be a handful of folks who 
use (sage-9.x + Python 2) for whatever few values of x this will work for, 
but I agree with William and others that in nearly all cases just using 8.9 
would suffice.

Given that the period of official dual Python 2/Python 3 support is going 
to be a few months, not years, I see no harm in removing Python 2 support 
in Sage 9.1.

In terms of helping users with thousands of lines of Python 2 based Sage 
code, trying to keep building Sage 8.9-the-distribution binaries for future 
OS releases as they come out is probably a lot more effective than working 
hard to push back the date that Python 2 support is dropped from Sage 9.x.

Best,

Nathan


-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/45548347-5167-43e1-a50e-6120e98a83d2%40googlegroups.com.

[sage-devel] Re: Possible to use current Sage version in travis-ci?

[Nathan Dunfield]

On Wednesday, July 31, 2019 at 4:33:21 PM UTC-5, Simon King wrote:
>
> Question: Is it (reasonably) possible to use a sage beta version in 
> travis-ci? How? 
>

Docker images with beta versions of Sage are available:

https://hub.docker.com/r/sagemath/sagemath/tags

so just change the requested image in the travis config file to, for 
example, "sagemath/sagemath:8.9.beta4".  I don't know if there's a way to 
simply get the most recently posted image (the tag ":latest" is just a 
name, and currently seems to be equivalent to ":8.7").

Best,

Nathan  

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/d1b60876-adcf-4b37-9d73-5d3949403bc9%40googlegroups.com.

[sage-devel] Re: Possible to use current Sage version in travis-ci?

[Nathan Dunfield]

On Wednesday, July 31, 2019 at 4:33:21 PM UTC-5, Simon King wrote:
>
> Question: Is it (reasonably) possible to use a sage beta version in 
> travis-ci? How? 
>

Docker images with beta versions of Sage are available, so just change the 

https://hub.docker.com/r/sagemath/sagemath/tags

requested image in the travis config file to, for example, 
"sagemath/sagemath:8.9.beta4".  I don't know if there's a way to simply get 
the most recently posted image (the tag ":latest" is just a name, and 
currently not 

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/a9b67f77-a230-46b0-a829-f1b383d3ca3c%40googlegroups.com.

[sage-devel] Re: PolyRings over NumberFields: odd UserWarning

[Nathan Dunfield]

On Saturday, May 4, 2019 at 10:45:56 AM UTC-5, Nathan Dunfield wrote:
>
> Dear Sage folks,
>
> For a number field K whose defining polynomial has a non-integral rational 
> coefficient, factoring a polynomial with coefficients in K sometimes 
> results in the following UserWarning:
>

Created a ticket for this: https://trac.sagemath.org/ticket/27765 

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] PolyRings over NumberFields: odd UserWarning

[Nathan Dunfield]

Dear Sage folks,

For a number field K whose defining polynomial has a non-integral rational 
coefficient, factoring a polynomial with coefficients in K sometimes 
results in the following UserWarning:

SageMath version 8.8.beta1, Release Date: 2019-04-07
sage: K. = NumberField(x^2 - 1/2)
sage: R. = PolynomialRing(K)
sage: p = 11*a*y + 7
sage: p.factor()
/sage/local/lib/python3.7/site-packages/sage/rings/number_field/number_field.py:1682:
 
UserWarning: interpreting PARI polynomial 11 relative to the defining 
polynomial x^2 - 2 of the PARI number field
  % (x, self.pari_polynomial()))
(11*a) * (y + 14/11*a)

Oddly, I'm only seeing this error for linear polynomials in y, not things 
of higher degree:

sage: q = p**2*y + p/3 + (a/5)*y^3
sage: prod(q.factor()) == q
True

The only reference in trac to this error message I could find is:

https://trac.sagemath.org/ticket/22202

Indeed the doctest added in #22202 to show that this ticket is fixed fails 
if the defining polynomial of the number field is made non-integral:

sage: y = QQ['y'].gen()
sage: R = QQ.extension(y^2-1/2,'a')['x']  # was y^2 - 2
sage: R("a*x").factor()
/sage/local/lib/python3.7/site-packages/sage/rings/number_field/number_field.py:1682:
 
UserWarning: interpreting PARI polynomial 0 relative to the defining 
polynomial x^2 - 2 of the PARI number field
  % (x, self.pari_polynomial()))
/sage/local/lib/python3.7/site-packages/sage/rings/number_field/number_field.py:1682:
 
UserWarning: interpreting PARI polynomial 1 relative to the defining 
polynomial x^2 - 2 of the PARI number field
  % (x, self.pari_polynomial()))

In all the instances I've seen, the polynomial being interpreted in the 
warning is a constant, meaning that the warning is harmless.  I assume the 
issues is related to the fact that K.pari_polynomial() is not just 
K.absolute_polynomial():

sage: K.pari_polynomial()
x^2 - 2
sage: K.absolute_polynomial()
x^2 - 1/2

Best,

Nathan

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: Python 3: gap interface issue

[Nathan Dunfield]

On Monday, February 4, 2019 at 8:12:02 AM UTC-6, Nathan Dunfield wrote:
>
> On Sunday, February 3, 2019 at 10:31:21 PM UTC-6, Dima Pasechnik wrote:
>>
>> I don't know what exactly is wrong with that docker container, but 
>> certainly GAP workspace might not be present if you never ran GAP via 
>> pexpect. It is created and rotated on the fly. 
>> Does 
>>
>> sage: gap_console() 
>>
>> work for you, just as a sanity check? 
>>
>
> Yes, that works just fine.
>

I figured out how to fix the issue on my Docker container, but it may be a 
general issue that will need a ticked and a fix.

The Docker container did not have any locale set (this is a common problem, 
apparently): 

sage@20cb4c8077bc:~$ python3 -c 'import locale; 
print(locale.getdefaultlocale())'
(None, None)
sage@20cb4c8077bc:~$ python3 -c 'import locale; 
print(locale.getpreferredencoding())'
ANSI_X3.4-1968

After doing:

export LANG=C.UTF-8

the answers change to ('en_US', 'UTF-8') and UTF-8 and then

sage: gap('0')

works! 

However, if instead I do:

sudo locale-gen en_US
export LANG=en_US

then Python gives ('en_US', 'ISO8859-1') and ISO-8859-1, and then 
"gap('0')" in Sage gives the same error as before.  My guess is that if the 
locale is not UTF-8 then GAP is printing its banner message in a non-UTF-8 
compatible encoding and then the pexpect interface is defaulting to trying 
to decode it as UTF-8 resulting in the error I found.

Should I open a ticket on this?  I tried logging into some random linux 
machines and got a whole range of responses for the locale...

Thanks,

Nathan

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: Python 3: gap interface issue

[Nathan Dunfield]

On Sunday, February 3, 2019 at 10:31:21 PM UTC-6, Dima Pasechnik wrote:
>
> I don't know what exactly is wrong with that docker container, but 
> certainly GAP workspace might not be present if you never ran GAP via 
> pexpect. It is created and rotated on the fly. 
> Does 
>
> sage: gap_console() 
>
> work for you, just as a sanity check? 
>

Yes, that works just fine:

sage@f826cc11a45a:~$ sage
SageMath version 8.7.beta2, Release Date: 2019-02-03
sage: gap_console()
 *   GAP 4.10.0 of 01-Nov-2018
 *  GAP  *   https://www.gap-system.org
 *   Architecture: x86_64-pc-linux-gnu-default64
 Configuration:  gmp 6.0.0, readline
 Loading the library and packages ...
 Packages:   Alnuth 3.1.0, AtlasRep 1.5.1, AutPGrp 1.10, CRISP 1.4.4, 
CTblLib 1.2.2, FactInt 1.6.2, FGA 1.4.0, GAPDoc 1.6.2, 
 IRREDSOL 1.4, LAGUNA 3.9.0, Polycyclic 2.14, PrimGrp 3.3.2, 
SmallGrp 1.3, Sophus 1.24, TomLib 1.2.7, TransGrp 2.0.4
 Try '??help' for help. See also '?copyright', '?cite' and '?authors'
gap> 

By running "gap('0')" in the ordinary python3 interpreter, I get a more 
concise traceback (see below) that makes it a little easier to see what is 
going wrong.  It is trying to reset (in this case, create) the gap 
workspace file, but is hitting a unicode error:

UnicodeDecodeError: 'utf-8' codec can't decode byte 0x80 in position 15: 
invalid start byte

I have posted the docker container as "computop/sage:py3" in case that is 
helpful.

Thanks,

Nathan


sage@f826cc11a45a:~$ python3
Python 3.6.6 (default, Feb  4 2019, 01:44:41) 
[GCC 7.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from sage.all import gap
>>> gap('0')
Traceback (most recent call last):
  File "/sage/local/lib/python3.6/site-packages/sage/interfaces/gap.py", 
line 1240, in _start
if os.path.getmtime(WORKSPACE) < timestamp():
  File "/sage/local/lib/python3.6/genericpath.py", line 55, in getmtime
return os.stat(filename).st_mtime
FileNotFoundError: [Errno 2] No such file or directory: 
'/home/sage/.sage/gap/gap-workspace-0x12758382c9bdb473'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/sage/local/lib/python3.6/site-packages/sage/interfaces/expect.py", 
line 1437, in __init__
self._name = parent._create(value, name=name)
  File 
"/sage/local/lib/python3.6/site-packages/sage/interfaces/interface.py", 
line 484, in _create
self.set(name, value)
  File "/sage/local/lib/python3.6/site-packages/sage/interfaces/gap.py", 
line 1414, in set
self._eval_line(cmd, allow_use_file=True)
  File "/sage/local/lib/python3.6/site-packages/sage/interfaces/gap.py", 
line 743, in _eval_line
self._start()
  File "/sage/local/lib/python3.6/site-packages/sage/interfaces/gap.py", 
line 1247, in _start
gap_reset_workspace(verbose=False)
  File "/sage/local/lib/python3.6/site-packages/sage/interfaces/gap.py", 
line 1579, in gap_reset_workspace
g.eval('SetUserPreference("HistoryMaxLines", 30)')
  File "/sage/local/lib/python3.6/site-packages/sage/interfaces/gap.py", 
line 583, in eval
result = Expect.eval(self, input_line, **kwds)
  File "/sage/local/lib/python3.6/site-packages/sage/interfaces/expect.py", 
line 1351, in eval
for L in code.split('\n') if L != ''])
  File "/sage/local/lib/python3.6/site-packages/sage/interfaces/expect.py", 
line 1351, in 
for L in code.split('\n') if L != ''])
  File "/sage/local/lib/python3.6/site-packages/sage/interfaces/gap.py", 
line 743, in _eval_line
self._start()
  File "/sage/local/lib/python3.6/site-packages/sage/interfaces/gap.py", 
line 1274, in _start
self.set_seed(self._seed)
  File "/sage/local/lib/python3.6/site-packages/sage/interfaces/gap.py", 
line 1179, in set_seed
self.eval("Reset(GlobalMersenneTwister,%d)" % seed)
  File "/sage/local/lib/python3.6/site-packages/sage/interfaces/gap.py", 
line 583, in eval
result = Expect.eval(self, input_line, **kwds)
  File "/sage/local/lib/python3.6/site-packages/sage/interfaces/expect.py", 
line 1351, in eval
for L in code.split('\n') if L != ''])
  File "/sage/local/lib/python3.6/site-packages/sage/interfaces/expect.py", 
line 1351, in 
for L in code.split('\n') if L != ''])
  File "/sage/local/lib/python3.6/site-packages/sage/interfaces/gap.py", 
line 755, in _eval_line
normal, error = bytes_to_str(normal), bytes_to_str(error)
  File "sage/cpython/string.pxd", line 31, in 
sage.cpython.string.bytes_to_str 
(build/cythonized/sage/cpython/string.c:1508)
  File "sage/cpython/string.pxd", line 60, in 
sage.cpython.string.bytes_to_str 
(build/cythonized/sage/cpython/string.c:1392)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0x80 in position 15: 
invalid start byte

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "", line 1, in 
  File 
"/sage/local/lib/python3.6/site-packages/sage/interfaces/interface.py", 
line 288, in __call__

[sage-devel] Re: Python 3: gap interface issue

[Nathan Dunfield]

On Sunday, February 3, 2019 at 7:23:52 PM UTC-6, Simon King wrote:
>
> Hi Nathan, 
>
> On 2019-02-04, Nathan Dunfield > 
> wrote: 
> > On Sage 8.6 with Python 2, the following command produces the expected 
> > result (namely, a sage.interfaces.gap.GapElement): 
> > 
> > sage: gap('0') 
> > 0 
> > 
> > whereas in Sage 8.6 with Python 3 I get the following error: 
>
> Works for me. In Sage 8.7.beta1 with Python 3.6.6, I get 
>   sage: gap(0) 
>   0 
>   sage: gap('0') 
>   0 
>

I just tried the git tip, which is Sage 8.7.beta2, and get the same error 
as before.  The main error seems to be:

FileNotFoundError: [Errno 2] No such file or directory: 
'/home/sage/.sage/gap/gap-workspace-0x1bd17f6665cc701c'

It is the indeed the case that there is no file gap-workspace* in 
$HOME/.sage/gap, in fact, there is no directory $HOME/.sage/gap at all!  If 
I do "libgap(0)", which does work, then a file 
$HOME/.sage/gap/libgap-workspace-* is created.

This is on a complete clean Docker image [1], so possibly the reason it 
works for you but not me is that you have a gap-workspace file left over 
from a previous version?  On the other hand, I tried copying over a 
gap-workspace file from the Python 2 version of Sage and that didn't help. 
So perhaps the error is coming when it tries to create the file or 
something.

Essentially the only difference between [1] and my usual Docker image [2] 
is that I specify the config flag "python3" during the Sage build process.

Best,

Nathan

[1] https://bitbucket.org/t3m/sagedocker/src/default/sage-py3/
[2] https://hub.docker.com/r/computop/sage

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Python 3: gap interface issue

[Nathan Dunfield]

On Sage 8.6 with Python 2, the following command produces the expected 
result (namely, a sage.interfaces.gap.GapElement):

sage: gap('0')
0

whereas in Sage 8.6 with Python 3 I get the following error:

sage: gap('0')
---
FileNotFoundError Traceback (most recent call last)
/sage/local/lib/python3.6/site-packages/sage/interfaces/gap.py in 
_start(self)
   1239 # been upgraded.
-> 1240 if os.path.getmtime(WORKSPACE) < timestamp():
   1241 raise OSError("GAP workspace too old")

/sage/local/lib/python3.6/genericpath.py in getmtime(filename)
 54 """Return the last modification time of a file, reported by 
os.stat()."""
---> 55 return os.stat(filename).st_mtime
 56 

FileNotFoundError: [Errno 2] No such file or directory: 
'/home/sage/.sage/gap/gap-workspace-0x752c50fd99b2032f'

During handling of the above exception, another exception occurred:

UnicodeDecodeErrorTraceback (most recent call last)
/sage/local/lib/python3.6/site-packages/sage/interfaces/expect.py in 
__init__(self, parent, value, is_name, name)
   1436 try:
-> 1437 self._name = parent._create(value, name=name)
   1438 # Convert ValueError and RuntimeError to TypeError for

/sage/local/lib/python3.6/site-packages/sage/interfaces/interface.py in 
_create(self, value, name)
483 name = self._next_var_name() if name is None else name
--> 484 self.set(name, value)
485 return name

/sage/local/lib/python3.6/site-packages/sage/interfaces/gap.py in set(self, 
var, value)
   1413 cmd = ('%s:=%s;;' % (var, value)).replace('\n','')
-> 1414 self._eval_line(cmd, allow_use_file=True)
   1415 

/sage/local/lib/python3.6/site-packages/sage/interfaces/gap.py in 
_eval_line(self, line, allow_use_file, wait_for_prompt, restart_if_needed)
742 if self._expect is None:
--> 743 self._start()
744 E = self._expect

/sage/local/lib/python3.6/site-packages/sage/interfaces/gap.py in 
_start(self)
   1246 except OSError:
-> 1247 gap_reset_workspace(verbose=False)
   1248 

/sage/local/lib/python3.6/site-packages/sage/interfaces/gap.py in 
gap_reset_workspace(max_workspace_size, verbose)
   1578 g = Gap(use_workspace_cache=False, max_workspace_size=None)
-> 1579 g.eval('SetUserPreference("HistoryMaxLines", 30)')
   1580 from sage.tests.gap_packages import all_installed_packages

/sage/local/lib/python3.6/site-packages/sage/interfaces/gap.py in 
eval(self, x, newlines, strip, split_lines, **kwds)
582 input_line += ';'
--> 583 result = Expect.eval(self, input_line, **kwds)
584 if not newlines:

/sage/local/lib/python3.6/site-packages/sage/interfaces/expect.py in 
eval(self, code, strip, synchronize, locals, allow_use_file, split_lines, 
**kwds)
   1350 return '\n'.join([self._eval_line(L, 
allow_use_file=allow_use_file, **kwds)
-> 1351 for L in code.split('\n') 
if L != ''])
   1352 else:

/sage/local/lib/python3.6/site-packages/sage/interfaces/expect.py in 
(.0)
   1350 return '\n'.join([self._eval_line(L, 
allow_use_file=allow_use_file, **kwds)
-> 1351 for L in code.split('\n') 
if L != ''])
   1352 else:

/sage/local/lib/python3.6/site-packages/sage/interfaces/gap.py in 
_eval_line(self, line, allow_use_file, wait_for_prompt, restart_if_needed)
742 if self._expect is None:
--> 743 self._start()
744 E = self._expect

/sage/local/lib/python3.6/site-packages/sage/interfaces/gap.py in 
_start(self)
   1273 # set random seed
-> 1274 self.set_seed(self._seed)
   1275 

/sage/local/lib/python3.6/site-packages/sage/interfaces/gap.py in 
set_seed(self, seed)
   1178 seed = self.rand_seed()
-> 1179 self.eval("Reset(GlobalMersenneTwister,%d)" % seed)
   1180 self.eval("Reset(GlobalRandomSource,%d)" % seed)

/sage/local/lib/python3.6/site-packages/sage/interfaces/gap.py in 
eval(self, x, newlines, strip, split_lines, **kwds)
582 input_line += ';'
--> 583 result = Expect.eval(self, input_line, **kwds)
584 if not newlines:

/sage/local/lib/python3.6/site-packages/sage/interfaces/expect.py in 
eval(self, code, strip, synchronize, locals, allow_use_file, split_lines, 
**kwds)
   1350 return '\n'.join([self._eval_line(L, 
allow_use_file=allow_use_file, **kwds)
-> 1351 for L in code.split('\n') 
if L != ''])
   1352 else:

/sage/local/lib/python3.6/site-packages/sage/interfaces/expect.py in 
(.0)
   1350 return 

[sage-devel] Re: Python 3: adding object to a category

[Nathan Dunfield]

On Sunday, February 3, 2019 at 6:39:42 PM UTC-6, Simon King wrote:
>
> > Thanks for the pointer, following those examples solved my problem! 
>
> Note, however, that it only adresses the question how to use a metaclass 
> in py3. It does not address the question how to use Sage's category 
> framework. 
>

Simon,

Yes, thanks also for pointing out this simplification.

Nathan


-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Python 3: adding object to a category

[Nathan Dunfield]

On Sunday, February 3, 2019 at 2:22:33 AM UTC-6, Frédéric Chapoton wrote:
>
> git grep "@add_metaclass" src/sage
>
> will give you plenty of examples on how to add metaclasses in a py3 
> compatible way
>

 Frédéric,

Thanks for the pointer, following those examples solved my problem!

Nathan

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Python 3: adding object to a category

[Nathan Dunfield]

Taking Frédéric's advice to heart, I have begun porting SnapPy to 
Sage+Python3.  (We have supported Python 3 outside of Sage for a few years 
now.)  Right now, I am having difficulty with how to register something as 
a field.  Below is the minimal (non) working example: if you run it with 
Python 2 it will print "True", but with Python 3 you get "False".  
Suggestions? 

Thanks, Nathan

-

import sage.all
from sage.structure.parent import Parent
from sage.structure.unique_representation import UniqueRepresentation
from sage.categories.fields import Fields
from sage.misc.classcall_metaclass import ClasscallMetaclass

class SnappyNumbersMetaclass(ClasscallMetaclass):
"""
Metaclass for Sage parents of SnapPy Number objects.
"""
def __new__(mcs, name, bases, dict):
dict['category'] = lambda self : Fields()
return ClasscallMetaclass.__new__(mcs, name, bases, dict)

class SnapPyNumbers(UniqueRepresentation, Parent):
"""
Sage parents of SnapPy Number objects.
"""
__metaclass__ = SnappyNumbersMetaclass

def __init__(self, precision):
Parent.__init__(self)
self._precision = precision

SPN = SnapPyNumbers(53)
print(SPN in Fields)

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: documentation of SageMath (Python) packages

[Nathan Dunfield]

 Vincent, 

Imagine I have a Python module, typically hosted on PyPI and depending 
> on SageMath, that provides documentation in some form (e.g. a pdf file, 
> a sphinx repo, etc). 
>
> 1) When a user performs `sage -pip install X`, should the documentation 
> be compiled and installed? 
>

I can tell you what we do with SnapPy, which has both Sphinx-generated docs 
and some PDF files. When building the sdist tarballs and wheels for posting 
on PyPI, we use Sphinx to compile the docs into HTML and then put the 
resulting HTML files as well as a few random PDFs into the Python package 
as "package data".   There are convenience functions such as 
"spherogram.pdf_docs()" which open the docs in a webrowser or pdfviewer as 
appropriate. As we support vanilla Python as well as SageMath, we can't 
assume that Sphinx is installed.

Best,

Nathan

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Import issue for Sage when using the system's Python (e.g. Debian)

[Nathan Dunfield]

On Thursday, January 10, 2019 at 9:58:56 AM UTC-6, E. Madison Bray wrote:
>
> > On archlinux that also uses system Python for Sage the 
> > situation is better: importing sage.all in Python2 does work! Even 
> > though the configuration constants are not in the environment! They 
> > are set up properly in sage_env.py that is part of the SageMath 
> > installation. And more precisely $SAGE_LOCAL fallsback to the default 
> > "/usr" which is what it is intend to be on archlinux. 
> > 
> > I don't understand why on Debian $SAGE_LOCAL is set to None and 
> > managed by environment variables. 
>
> I have mentioned elsewhere (e.g. on 
> https://trac.sagemath.org/ticket/22652) that the sage.env module ought 
> to be fixed upstream (that is, in the main Sage sources) so that it 
> can actually work properly without having to set any special 
> environment variables.  Even if it has to guess in some cases, and has 
> to raise a RuntimeError if it can't reasonably guess the correct 
> values for some variables, in most cases it should be possible to 
> design this in such a way that it *just works* from a normal python 
> interpreter with no additional variables set. 
>

Fixing upstream is always best, but in the meantime is there some reason 
that the Debian package doesn't just patch "sage/env.py" like Arch does?  
Looking at the Arch approach, I checked that the following 3-line patch 
causes 'python -c "import sage.all"' to succeed on Debian Sid with SageMath 
8.4. 

Best,

Nathan

--- env.py.orig 2019-01-03 05:15:59.0 -0600
+++ env.py 2019-01-10 12:28:13.0 -0600
@@ -118,10 +118,10 @@
 _add_variable_or_fallback('LOCAL_IDENTIFIER','$HOSTNAME.%s'%os.getpid())
 
 # bunch of sage directories and files
-_add_variable_or_fallback('SAGE_ROOT',   None)
-_add_variable_or_fallback('SAGE_LOCAL',  None)
+_add_variable_or_fallback('SAGE_ROOT',   '/usr/share/sagemath')
+_add_variable_or_fallback('SAGE_LOCAL',  '/usr')
 _add_variable_or_fallback('SAGE_ETC',opj('$SAGE_LOCAL', 'etc'))
-_add_variable_or_fallback('SAGE_SCRIPTS_DIR',opj('$SAGE_LOCAL', 'bin'))
+_add_variable_or_fallback('SAGE_SCRIPTS_DIR',opj('$SAGE_ROOT', 'bin'))
 _add_variable_or_fallback('SAGE_INC',opj('$SAGE_LOCAL', 'include'))
 _add_variable_or_fallback('SAGE_SHARE',  opj('$SAGE_LOCAL', 'share'))


-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Import issue for Sage when using the system's Python (e.g. Debian)

[Nathan Dunfield]

On Thursday, January 10, 2019 at 9:38:15 AM UTC-6, vdelecroix wrote:
>
> Could you repeat the order in which things are broken. 
>

Any of the following sequences of commands will install both the SnapPy 
Python package and SageMath without producing any errors:

0) install python2 and python-pip 
1) install snappy via pip 
2) install sagemath via apt 

and 

1) install sagemath via apt 
2) install snappy via pip

and 

1) install sagemath via apt 
2) source sage-env and install snappy via pip 

Independent of which route one takes above both of the following commands 
will succeed:

A) sage -python -c "import snappy"
B) source  /usr/share/sagemath/bin/sage-env; python -c "import snappy"

and this will always fail:

C) python -c "import snappy"

Best,

Nathan



-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Import issue for Sage when using the system's Python (e.g. Debian)

[Nathan Dunfield]

On Thursday, January 10, 2019 at 6:47:33 AM UTC-6, vdelecroix wrote:
>
> Le 10/01/2019 à 04:47, Nathan Dunfield a écrit : 
> > 
> > P.S. In the Debian package "sage" does not accept the "-pip" flag, even 
> > though installing the "sagemath" package does pull in "pip" (tested on a 
> > clear Sid Docker container).  Why is this?  I ask because our current 
> > instructions for installing SnapPy into SageMath use "sage -pip". 
>
> The sage script in Debian is indeed a restricted version of the 
> original sage script (to avoid messing up with the system). You 
> can just use the pip from the system. That works fine if you 
> source the environment variables first: 
>
> $ source /usr/share/sagemath/bin/sage-env 
> $ pip install surface_dynamics --user 
>

Yes, snappy installs fine with the system pip (even without sourcing 
sage-env), though as you know from writing the flatsurf docs, this 
distinction rather complicates the installation instructions.

Our issue reports have actually come from people who installed SnapPy in 
their system Python with pip only to have it crash when starting the 
SnapPy app because they had also previously installed Sage via their 
package manager.  In other words, our "installing SnapPy in Linux (no 
Sage)" instructions will fail if user has previously installed Sage in a 
particular way.  

Nathan

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Import issue for Sage when using the system's Python (e.g. Debian)

[Nathan Dunfield]

I am a developer of the Python package "snappy" which acquires extra 
features when imported inside of Sage. Some of our Linux users have 
recently reported difficulties with SnapPy on machines where Sage was 
installed by the standard package manger making use of the system libraries 
and in particular the system python.  I have reproduced the problem on 
Debian Sid but it also manifests itself on Fedora 28 [1].  The root of our 
problem is that in this situation: 

python -c "import sage.all"

results the error: 

Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python2.7/dist-packages/sage/all.py", line 71, in 
from sage.env import SAGE_ROOT, SAGE_SRC, SAGE_DOC_SRC, SAGE_LOCAL, 
DOT_SAGE, SAGE_ENV
  File "/usr/lib/python2.7/dist-packages/sage/env.py", line 123, in 
_add_variable_or_fallback('SAGE_ETC',opj('$SAGE_LOCAL', 'etc'))
  File "/usr/lib/python2.7/dist-packages/sage/env.py", line 103, in 
_add_variable_or_fallback
value = sep.join(components)
TypeError: sequence item 0: expected string, NoneType found

whereas 

sage -python -c "import sage.all"

works as expected.  Currently, our Python package tests for whether it is 
running in SageMath by:

_within_sage = False
try:
import sage.all
_within_sage = True
except ImportError:
pass

One solution for us (I think) would be to simply catch and ignore all types 
of exceptions in the above block, but I was wondering if the current 
behavior of 'python -c "import sage.all"' was expected or is this possibly 
a bug?  Or perhaps there is a work-around of some kind?

Thanks,

Nathan

P.S. In the Debian package "sage" does not accept the "-pip" flag, even 
though installing the "sagemath" package does pull in "pip" (tested on a 
clear Sid Docker container).  Why is this?  I ask because our current 
instructions for installing SnapPy into SageMath use "sage -pip".  


[1] See the second comment, not the original report, on 
https://bitbucket.org/t3m/snappy/issues/14/

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: snappy in Sage

[Nathan Dunfield]

On Tuesday, October 2, 2018 at 10:40:28 AM UTC-5, Nathan Dunfield wrote:
>
> This is a known bug and we are working on it (there's even a ticket).  It 
> should be fixed soon.  It's some issue with our configuration script.  
>

FYI, this issue has now been fixed and the corrected version is on PyPI as 
version 2.6.1.post1.  
 
Nathan

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] snappy in Sage

[Nathan Dunfield]

>
> > The idea is that cython produces fully compliant C code, so that no 
> tuning 
> > of the generated C code is required. Distributing the cythonized c-files 
> > has the advantage that the installing user does not need cython 
> installed. 
> > In sage we have run into trouble with that due to API incompatibilities 
> > between Py2 and Py3, and it doesn't seem possible to specify the right 
> > conditionals in the cython file to produce an appropriate c file with 
> the 
> > right conditional pieces of code in. 
>
> As far as I remember, snappy deals with that by providing file.py2.c and 
> file.py3.c. Nathan could infirm/confirm. 
>

For SnapPy itself, we don't hit this API issue and so there is just a 
single version of each Cython-generated ".c" file.  For CyPari, I believe 
Marc Culler did have to use the scheme Vincent mentions above.

Nathan

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] snappy in Sage

[Nathan Dunfield]

>
> Thanks, Thierry.  Sounds like we need a ticket for this.  In particular, I 
> wasn't even able to get sage -pip install mercurial to work on OS X.
>

I was just helping a colleague install SnapPy into SageMath on OS X and hit 
the above issue.  I just downloaded the source tarball from BitBucket 
directly and all of SnapPy built fine, even though Mercurial didn't.  So 
probably a problem with Mercurial...

Nathan

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] snappy in Sage

[Nathan Dunfield]

>
> It's bad packaging by upstream: it's running Cython but the Cython 
> source files are not in the snappy source tarball. 
>

Yes, we ship the Cython generated C/C++ files rather than Cython code 
itself.  My understanding from the Cython docs is that this is the 
recommended approach for non-Sage packages, and we have always done this.  
But apparently we accidentally introduced a bug in the setup.py script in 
SnapPy 2.6 that is causing it to look for the Cython files anyway...

Nathan

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: snappy in Sage

[Nathan Dunfield]

This is a known bug and we are working on it (there's even a ticket).  It 
should be fixed soon.  It's some issue with our configuration script.  

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: talk

[Nathan Dunfield]

On Tuesday, July 24, 2018 at 4:49:45 PM UTC-5, Timo Kaufmann wrote:
>
> I really like your wishlist! The all-or-nothing nature of sage and the 
> slow startup time (although it's actually more like 1.3 seconds with a warm 
> cache on my machine) are my biggest pain points. 
>

I've encountered incredibly slow Sage startup times on big clusters due to, 
I believe, the very slow nature of their distributed file systems and the 
huge number of files Sage opens at startup.  This was several years ago, 
but at the time Sage took several *minutes* to start on the main campus 
cluster here at UIUC.  I ended up using a smaller cluster for my 
computations where the startup time was "just" 20 seconds.  (I was running 
things from my home directory rather that trying to convince the admins to 
install Sage on each node which presumably would have fixed things.)  

>From the viewpoint of SnapPy, a more modular Sage would be fantastic as it 
would allow us to have more functionality in the stand-alone version and 
reduce development effort at the same time.

Nathan


 

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: SageMath 8.2 Docker image: pip lacks SSL support

[Nathan Dunfield]

On Saturday, May 26, 2018 at 7:43:14 PM UTC-4, Julian Rüth wrote:
>
> Thanks for reporting this and even providing a workaround :)
>
> You are right, Sage was built with libssl-dev but the final container had 
> been missing openssl. I fixed it for the 8.2 build and pushed a new image 
> to the Docker Hub.
>

Great, the fixed version works for me.   Thanks for fixing this!

Nathan

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: SageMath 8.2 Docker image: pip lacks SSL support

[Nathan Dunfield]

>
> In the interim, could you try to install OpenSSL and its development files 
> a,d reinstall Sage's pip ?
>

Actually, I fixed the problem simply by installing the (non-development) 
Ubuntu package "openssl".  In particular, I did not need to reinstall or 
rebuild any part of Sage itself.   I'm guessing that the "openssl" package 
was accidentally removed from the Docker image after Sage was built.

Nathan

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] SageMath 8.2 Docker image: pip lacks SSL support

[Nathan Dunfield]

Just tried out the latest Sage Docker image and, unlike all previous 
versions, I can no longer use pip to fetch packages off PyPI:

docker run -it sagemath/sagemath:8.2 /bin/bash
sage@6bf664a266cd:~/sage$ sage -pip install FXrays
pip is configured with locations that require TLS/SSL, however the ssl 
module in Python is not available.
Collecting FXrays
  Retrying (Retry(total=4, connect=None, read=None, redirect=None, 
status=None)) after connection broken by 'SSLError("Can't connect to HTTPS 
URL because the SSL module is not available.",)': /simple/fxrays/
[...]
  Retrying (Retry(total=0, connect=None, read=None, redirect=None, 
status=None)) after connection broken by 'SSLError("Can't connect to HTTPS 
URL because the SSL module is not available.",)': /simple/fxrays/
  Could not fetch URL https://pypi.python.org/simple/fxrays/: There was a 
problem confirming the ssl certificate: 
HTTPSConnectionPool(host='pypi.python.org', port=443): Max retries exceeded 
with url: /simple/fxrays/ (Caused by SSLError("Can't connect to HTTPS URL 
because the SSL module is not available.",)) - skipping
  Could not find a version that satisfies the requirement FXrays (from 
versions: )
No matching distribution found for FXrays

If I do

sudo apt-get update; sudo apt-get install -y openssl

in the container then pip starts working again.  So it looks like Python 
was compiled with SSL support but somehow the openssl module itself gets 
removed somewhere in the process.

Thanks,

Nathan

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] ecm build fails with 8.2rc1 on Ubuntu 18.04

[Nathan Dunfield]

I tried building Sage from source on the new Ubuntu 18.04 in a clean Docker 
container with just a handful of basic packages installed, principally gcc 
7.   It was unable to build ecm-7.0.4.p1 which is included in 8.2rc1.  Here 
is what seems to be the core of the error message:

mv -f aprtcle/.deps/aprcl-mpz_aprcl.Tpo aprtcle/.deps/aprcl-mpz_aprcl.Po
libtool: link: gcc -g -O3 -fPIC -Wl,-rpath -Wl,/sage/local/lib -o tune 
tune-mpmod.o tune-tune.o tune-mul_lo.o tune-listz.o tune-auxlib.o 
tune-ks-multiply.o tune-schoen_strass.o tune-polyeval.o tune-median.o 
tune-ecm_ntt.o tune-ntt_gfp.o tune-mpzspv.o tune-mpzspm.o tune-sp.o 
tune-spv.o tune-spm.o tune-auxarith.o  -L/sage/local/lib 
./x86_64/.libs/libmulredc.a /sage/local/lib/libgmp.a -lrt -lm
mv -f aprtcle/.deps/libecm_la-mpz_aprcl.Tpo 
aprtcle/.deps/libecm_la-mpz_aprcl.Plo
mv -f .deps/libecm_la-pm1fs2.Tpo .deps/libecm_la-pm1fs2.Plo
/sage/local/lib/libgmp.a(fat_entry.o): In function `__gmpn_mod_34lsub1':
/sage/local/var/tmp/sage/build/mpir-3.0.0-644faf502c56f97d9accd301965fc57d6ec70868/src/mpn/tmp-fat_entry.s:202:
 
multiple definition of `__gmpn_mod_34lsub1'
tune-schoen_strass.o:/sage/local/var/tmp/sage/build/ecm-7.0.4.p1/src/schoen_strass.c:61:
 
first defined here
/usr/bin/x86_64-linux-gnu-ld: /sage/local/lib/libgmp.a(fat_entry.o): 
relocation R_X86_64_32S against symbol `__gmpn_cpuvec' can not be used when 
making a PIE object; recompile with -fPIC
/usr/bin/x86_64-linux-gnu-ld: final link failed: Nonrepresentable section 
on output


You can find the whole log at http://dunfield.info/temp/ecm-7.0.4.p1.log 

The underlying hardware (i.e. the Docker host) is an iMacPro with a Xeon 
W-2150B CPU.  I will try building on an older Mac Pro and see if the 
failure is processor dependent, but I have successfully built 8.2rc1 on the 
same machine in a 16.04 Docker container.  

Best,

Nathan

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Sage 8.2rc1 and Ubuntu 18.04: ecm fails to build

[Nathan Dunfield]

On Sunday, April 29, 2018 at 4:55:35 AM UTC-5, Erik Bray wrote:
>
> Yep, SAGE_FAT_BINARY=yes is what did it.  I'll look into it further. 
>

Erik,

Thanks!  I just confirmed that setting SAGE_FAT_BINARY to "no" fixes the 
problem on my machine as well.

Nathan

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Sage 8.2rc1 and Ubuntu 18.04: ecm fails to build

[Nathan Dunfield]

On Saturday, April 28, 2018 at 7:41:49 PM UTC-5, Erik Bray wrote:
>
> I just finished a full build from scratch on Ubuntu 18.04 and it went 
> fine. This was of 8.2.rc4. 
>
> I don't recall off the top of my head whether anything changed between 
> rc1 and rc4 that might have effected this, but you might try bumping a 
> rc4 just in case. 
>

Erik,

First, thanks for looking into this.  I erred when I wrote rc1, I too was 
working with the very latest rc4.  I was using my own variant of your 
original Dockerfiles, but I just did another run where I cloned 
"sagemath/docker-images", edited the first line of 
"sagemath-base/Dockerfile" and then did:

docker build --tag="sagemath/sagemath-base" sagemath-base
docker build --tag="sagemath/sagemath-develop" sagemath-develop


The error log looks pretty much the same as before except this time the 
package was "ecm-7.0.4.p0" rather than "ecm-7.0.4.p1". 

Best,

Nathan

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Nathan Dunfield]

On Monday, October 23, 2017 at 7:32:03 AM UTC-5, Erik Bray wrote:
>
> > I also balk at the idea of shipping a crippled pip. 
>
> It's not crippled if you don't need it to install from HTTPS which not 
> everyone does.
>

I agree with Emmanuel that providing "pip" without HTTPS is shipping a 
broken product.  While there are other uses for "pip", by far the most 
common is to install Python packages off PyPI, which requires HTTPS.  

For the same reasons Emmanuel lists for R, installing Python packages via 
manual download and then pip breaks down fast for all but the simplest 
packages.  I once installed "snappy" [1] into a copy of SageMath on macOS 
where Sage's pip lacked OpenSSL support via such manual downloads.  I 
succeed but it was quite painful and in any event I'm a maintainer of said 
package...

Best,

Nathan

[1] https://pypi.python.org/pypi/snappy/

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: VOTE: inclusion of OpenSSL in Sage

[Nathan Dunfield]

|X| Yes, we should fully support OpenSSL now, and clarify the licensing 
issue.  


-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: RFC: Draft blog post on Sage for Windows

[Nathan Dunfield]

I would suggest adding a link or instructions for how to download your new 
SageMath installer for Windows. 

Nathan

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: Conda package for Sage

[Nathan Dunfield]

On Thursday, June 15, 2017 at 12:38:40 PM UTC-5, Volker Braun wrote:
>
> On Thursday, June 15, 2017 at 3:10:22 PM UTC+2, Nathan Dunfield wrote:
>>
>> but of course the Mac Mini has only 2 cores.
>>
>
> For the record, our OSX buildbot is a quad-core mac mini (i7-3720QM CPU @ 
> 2.60GHz).
>

Inexplicably, the option of a quad-core processor was dropped with the 
current Mac mini revision that came out in late 2014.

Nathan

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: Conda package for Sage

[Nathan Dunfield]

>
> Plus licenses for a range of OSX versions (at least those that are 
>> still supported by Apple...) 
>>
>
> these are peanuts, e.g. £20 for 10.7
>

I don't know if this is still the case, but as of a year ago if you become 
a registered Apple Developer then you got access to all the old versions of 
OS X and XCode as well as the pre-releases.  That costs US$100/year, but 
once you have the complete set you could drop the subscription since it's 
easy to keep current: just copy the VM for version n when n+1 comes out and 
the let the system update itself. 

With regards to hardware, the single-core performance of the Mac Pro isn't 
that much better than the Mac Mini, see:

https://browser.primatelabs.com/mac-benchmarks

but of course the Mac Mini has only 2 cores.  If space is not an issue, you 
might think about the iMac with the i7-7700K, or, if it is, the top of the 
line Mac Book Pro is quite a bit more powerful than the Mini at this point.

Nathan

 

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: Conda package for Sage

[Nathan Dunfield]

>
>  How do people get VMs for testing different OSX / XCode versions? 
>

Both VirtualBox and VMWare (Fusion) fully support OS X VMs with the 
important caveat you have to use actual Apple hardware for the host.

I've used both without major problems on a Mac Pro.  Currently I mostly use 
VMWare since it's a little more polished (my university has a 
site-license).  You can configure VMWare so you that you can both ssh into 
the VM from the host as well as interact with the full GUI, the latter even 
remotely using VMWare's VNC capability.   With fairly minimal installs and 
only the occasional snapshot, I find you need about 40-50Gb of disk space 
for each VM.  

I believe Travis-CI offers OS X nodes, though building Sage might well time 
out on their free tier.  

Best,

Nathan

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] pip install on MacOS

[Nathan Dunfield]

On a good day, assuming the user has the Xcode command-line tools 
installed, the following suffices to get pip working with the current 
binary version of SageMath on macOS 10.12:

sage -i openssl
sage -f python2

It would be great if the next release of SageMath had a working version of 
pip on macOS as the current situation causes no end of trouble for a lot of 
people. 

Best, Nathan

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] ComplexField dilog precision bug

[Nathan Dunfield]

FYI, I found a very similar issue with "exp" and "log" for purely imaginary 
numbers:

http://pari.math.u-bordeaux.fr/cgi-bin/bugreport.cgi?bug=1896

Nathan

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

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

[Nathan Dunfield]

>
> It's ridiculous that we spend no effort on pandas/statsmodels, and all 
> this 
> effort on R.  


+1
 

> For example, I recall that there are some issues involving pandas + 
> statsmodels + the sage preparser.  
>

I use Pandas in the default Sage Interpreter on a daily basis and have only 
encountered a few quirks, all I think related to the Sage Integer vs. 
Python Integer distinction.  I don't use statsmodel though.  

Nathan

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Abandon Python 2.6 support?

[Nathan Dunfield]

>
> Which operating systems / distros would be affected by this (i.e., only 
> ship with 2.6.x [and probably some older 3.x])? 
>

What I'd seriously worry about here is RHEL 6 and derivatives (CentOS, 
SciLinux).  It only comes with Python 2.6 by default, and while old (came 
out in 2010), it is frequently seen on university high-performance 
computing clusters (for example the main cluster here at UIUC).  

OS X is not a issue as has been Python 2.7 is included since 10.7, and in 
any event it is easy to install Python there. 

Best,

Nathan

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: Build failure Sage 7.3.beta3 on Mac OS 10.9 with binary-pkg

[Nathan Dunfield]

>
> I'm wondering, if we should delete the beta3 and beta0 variants to avoid 
> confusion?
>

That definitely seems like the right move to me.

Nathan

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: SageMath 7.3.beta3 build failure on OS X versions 10.8 and 10.9.

[Nathan Dunfield]

>
> Is there a ticket for this? 
>

I just created one --- trac was down when I posted originally:

http://trac.sagemath.org/ticket/20779#ticket

Nathan

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Re: Developing sage-based code out of tree

[Nathan Dunfield]

>
> That made me think that sage fails to set everything required to let 
> "--user" work properly (I noticed installation path names containing 
> ".../.sage/..." so at least it was trying something distinct from what 
> python would do in a standard config.)
>

Hmmm, I install Python packages into Sage with the "--user" flag all the 
time, so my initial guess is this is specific to this particular package or 
Sage build. 

As of 7.1 or 7.2, Sage's Python has the user base directory set to 
"~/.sage/local" rather than the usual (for Unix) of "~/.local". In 
particular, the user site packages should be 
"~/.sage/local/lib/python2.7/site-packages".  This was done to avoid 
conflicts with other versions of Python the user might have installed 
(which, for example, might not be binary compatible with Sage's). 

Nathan



-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Developing sage-based code out of tree

[Nathan Dunfield]

>
> While this might work for simple projects, this won't work when you need 
> the metadata that cythonize() adds. For example, anything using 
> cysignals really must use cythonize(), it won't work otherwise. 
>

Jeroen,

As of Cython 0.22, it looks like the metadata you refer to is cached in the 
Cython-generated C files:

http://grokbase.com/t/python/cython-devel/152c310vvz/cython-cython-0-22-released

Specifically, if you look at the top of a Cython-generated C file, there is 
what looks to be a JSON string encoding the metadata.   

Of course, as Erik says one shouldn't have to mess with this all "by hand". 
 For example, setuptools could provide a "stub" version of cythonize that 
(a) does nothing but load this metadata if the C files are up to date and 
otherwise (b) attempts to import Cython and run the real cythonize... 

Best,

Nathan

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Developing sage-based code out of tree

[Nathan Dunfield]

>
> > Agreed, it's certainly what the Cython docs recommend: 
> > 
> > 
> http://docs.cython.org/src/reference/compilation.html#distributing-cython-modules
>  
>
> Ah, okay.  I didn't see that before.  At least it's the recommended 
> best practice.  It should be easier to do automatically though (where 
> desired). 
>

Definite +1 for this being done automatically...

Nathan

 

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Developing sage-based code out of tree

[Nathan Dunfield]

>
> > Interesting, I didn't realize that build-time (as opposed to run-time) 
> > dependencies were even *possible* with setuptools, even if it does 
> require a 
> > hack.  With SnapPy, we just ship the Cython-generated C/C++-files in the 
> > tarball that we post on PyPI. 
>
> I was going to post that my understanding is that shipping 
> Cython-generated files is the current standard way of shipping Cython 
> code (for better or worse). 
>

Agreed, it's certainly what the Cython docs recommend:

http://docs.cython.org/src/reference/compilation.html#distributing-cython-modules

Nathan

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

Re: [sage-devel] Developing sage-based code out of tree

[Nathan Dunfield]

Erik,

Interesting, I didn't realize that build-time (as opposed to run-time) 
dependencies were even *possible* with setuptools, even if it does require 
a hack.  With SnapPy, we just ship the Cython-generated C/C++-files in the 
tarball that we post on PyPI.  It adds a bit to the tarball's size, but is 
more robust than requiring Cython. For example, there are sometimes 
incompatibilities between different versions of Cython, and it's a bit rude 
to force the end-user to upgrade or downgrade their version of Cython just 
so they can install some other package.  

In our setup.py we use code like:

# If have Cython, check that .c files are up to date:

try:

from Cython.Build import cythonize

if 'clean' not in sys.argv:

targets = ['planarity_src/planarity.pyx', pmap_dir + 
'planarmap.pyx']

cythonize(targets)

except ImportError:

pass


Even if the user has the "wrong" Cython, the PyPI tarball will still build 
since the Cythonized files are up-to-date.  

Best,

Nathan

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

[sage-devel] Re: proposal: possibly remove Watkins Sympow from Sage

[Nathan Dunfield]

Also works in Sage 7.2 for me on OS X version 10.9 and a hoary RHEL 6 
derivative.  In both cases, Sage was compiled straight from the source 
tarball.

Nathan

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.