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

2024-04-25 Thread 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

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

2024-04-25 Thread 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

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

2024-04-24 Thread 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 softw

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

2024-04-24 Thread 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

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

2024-04-21 Thread 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

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

2024-04-10 Thread 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

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

2024-03-04 Thread 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

[sage-devel] Re: VOTE: disputed PRs

2024-03-04 Thread 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

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

2024-02-19 Thread 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

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

2024-02-18 Thread 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

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

2024-02-18 Thread 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

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

2024-02-17 Thread 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

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

2024-02-17 Thread 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

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

2024-02-16 Thread 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

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

2023-06-29 Thread 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.

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

2023-06-12 Thread 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

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

2023-06-12 Thread 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

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

2022-09-21 Thread 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

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

2022-09-10 Thread 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,

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

2022-08-05 Thread 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] Re: Polling for pygments style for our future doc

2022-08-04 Thread 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 --

[sage-devel] Re: arctanh vs. artanh

2022-03-23 Thread 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

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

2022-03-08 Thread 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

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

2021-12-06 Thread 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'.

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

2021-12-05 Thread 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

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

2021-10-12 Thread 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

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

2021-10-01 Thread 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

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

2021-09-26 Thread 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

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

2021-09-24 Thread 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

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

2021-08-14 Thread 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

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

2021-06-26 Thread 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

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

2021-06-14 Thread 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 >

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

2021-05-24 Thread 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

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

2021-04-10 Thread 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

[sage-devel] Comparing RealIntervalField elements with floats

2021-04-10 Thread 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

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

2021-04-10 Thread Nathan Dunfield
: > 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 f

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

2021-04-04 Thread 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:

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

2021-03-10 Thread 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,

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

2021-03-09 Thread Nathan Dunfield
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 "

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

2021-03-09 Thread 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

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

2021-01-05 Thread 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

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

2020-10-20 Thread 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

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

2020-10-20 Thread 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

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

2020-10-19 Thread 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

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

2020-08-21 Thread 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

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

2020-07-24 Thread 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

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

2020-07-24 Thread 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

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

2020-07-24 Thread 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] >

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

2020-04-30 Thread 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

[sage-devel] Re: sage_sample

2020-04-04 Thread 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

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

2020-03-29 Thread 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

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

2020-03-02 Thread 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

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

2020-02-04 Thread 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

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

2020-01-10 Thread 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

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

2019-07-31 Thread 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

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

2019-07-31 Thread 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

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

2019-05-04 Thread 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 UserW

[sage-devel] PolyRings over NumberFields: odd UserWarning

2019-05-04 Thread 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.

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

2019-02-06 Thread 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

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

2019-02-04 Thread 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()

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

2019-02-03 Thread 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-devel] Python 3: gap interface issue

2019-02-03 Thread 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') ---

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

2019-02-03 Thread 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 >

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

2019-02-03 Thread 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 --

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

2019-02-02 Thread 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

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

2019-01-29 Thread 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

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

2019-01-10 Thread 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

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

2019-01-10 Thread 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

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

2019-01-10 Thread 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&qu

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

2019-01-09 Thread 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

[sage-devel] Re: snappy in Sage

2018-10-04 Thread 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 corre

Re: [sage-devel] snappy in Sage

2018-10-02 Thread 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

Re: [sage-devel] snappy in Sage

2018-10-02 Thread 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

Re: [sage-devel] snappy in Sage

2018-10-02 Thread 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

[sage-devel] Re: snappy in Sage

2018-10-02 Thread 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

[sage-devel] Re: talk

2018-07-25 Thread 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

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

2018-05-27 Thread 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

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

2018-05-17 Thread 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.

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

2018-05-16 Thread 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

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

2018-04-30 Thread 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

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

2018-04-29 Thread 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

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

2018-04-28 Thread 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

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

2017-10-23 Thread 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

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

2017-10-16 Thread 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

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

2017-09-01 Thread 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

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

2017-06-16 Thread 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 mi

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

2017-06-15 Thread 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

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

2017-06-14 Thread 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

Re: [sage-devel] pip install on MacOS

2017-05-06 Thread 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

Re: [sage-devel] ComplexField dilog precision bug

2017-02-13 Thread 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

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

2016-10-28 Thread 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

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

2016-06-10 Thread 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

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

2016-06-07 Thread 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

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

2016-06-07 Thread 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

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

2016-06-07 Thread 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

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

2016-06-07 Thread 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

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

2016-06-07 Thread 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

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

2016-06-07 Thread 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

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

2016-06-07 Thread 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,

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

2016-06-07 Thread 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

  1   2   >