On Monday, June 12, 2023 at 4:54:21 PM UTC-7 Nathan Dunfield wrote:
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.
In the present design
On Fri, 23 Jun 2023, 22:48 Matthias Koeppe,
wrote:
> On Friday, June 23, 2023 at 1:24:42 PM UTC-7 Dima Pasechnik wrote:
>
> a lot of this is caused by Sage the distribution intertwined with Sage the
> library too much.
>
>
> It isn't. That was a problem years ago, but it has been fixed with only
On Friday, June 23, 2023 at 1:02:34 PM UTC-7 Michael Orlitzky wrote:
[...] And instead of focusing on
them we keep getting distracted by squirrels.
Around here, hummingbirds are the bigger problem in this regard
--
You received this message because you are subscribed to the Google Groups
On Friday, June 23, 2023 at 1:24:42 PM UTC-7 Dima Pasechnik wrote:
a lot of this is caused by Sage the distribution intertwined with Sage the
library too much.
It isn't. That was a problem years ago, but it has been fixed with only a
few odd ends (such as sage.misc.package) remaining.
--
On Fri, Jun 23, 2023 at 1:02 PM Michael Orlitzky
wrote:
> The second issue is that WebAssembly doesn't actually solve the
> problems we have,
By "the problem we have" I guess maybe you mean "Sage is a lot of work to
maintain".The fundamental
and massive problem that I think SageMath has is
It's strange that nobody said this already, but a lot of this is caused by
Sage the distribution intertwined with Sage the library too much.
The right way forward is to decouple these two.
I tried to propose something like this years ago, but didn't get far.
In a nutshell, shift the non-Python
On Thu, 2023-06-22 at 14:41 -0700, William Stein wrote:
>
> WebAssembly is not an experimental linux distribution, and it has very
> little overlap with linux distributions. The WebAssembly ecosystem is
> built from the ground up, primarily on the LLVM (and Rust) toolchain, and
> an ecosystem of
I believe that wasm is the future, because you don't have to install
anything and computations are done in the browser client, they do not
require ressources from a server (except for the initial download of the
wasm file). Giac/Xcas does that since many years now, (initially it was a
request
On Thu, Jun 22, 2023 at 2:15 PM Michael Orlitzky
wrote:
> On Thu, 2023-06-22 at 13:56 -0700, William Stein wrote:
> >
> > (5) provide a WebAssembly option
> >
> > WebAssembly is typically about half the speed as native code (at best),
> but
> > it is highly cross platform and self contained.
Well, concerns of software integration and deployment have always been part
of the Sage project. And several leading projects in scientific python have
already invested in WebAssembly deployment, at least for its obvious uses
in providing interactive documentation. I, for one, welcome our new
On Thu, 2023-06-22 at 13:56 -0700, William Stein wrote:
>
> (5) provide a WebAssembly option
>
> WebAssembly is typically about half the speed as native code (at best), but
> it is highly cross platform and self contained. WebAssembly is difficult
> mainly when you have to deal with the OS
On Thu, Jun 22, 2023 at 1:44 PM Matthias Koeppe
wrote:
>
> On Thursday, June 22, 2023 at 12:49:29 PM UTC-7 Francesco Biscani wrote:
>
> On Fri, 9 Jun 2023 at 02:02, Matthias Koeppe wrote:
>
> building binary wheels to be distributed on PyPI (in addition to the
source distributions) will be one
On Thursday, June 22, 2023 at 12:49:29 PM UTC-7 Francesco Biscani wrote:
On Fri, 9 Jun 2023 at 02:02, Matthias Koeppe wrote:
building binary wheels to be distributed on PyPI (in addition to the source
distributions) will be one of the key steps in order to make it very
user-friendly -- i.e.,
On Fri, 9 Jun 2023 at 02:02, Matthias Koeppe
wrote:
> On Thursday, June 8, 2023 at 4:40:06 PM UTC-7 Michael Orlitzky wrote:
>
> Pip [...] can't do anything with the non-python software on which sage
> subsists.
> To make sage-via-pip work, we'll have to maintain a new pseudo-
> distribution on
On Friday, June 16, 2023 at 12:08:29 AM UTC-7 Michael Orlitzky wrote:
[...] without resolving any of the
other ongoing massive complicated projects.
One such project that has been ongoing (or rather started and then
forgotten) since at least 2012
>
On 2023-06-15 18:08:35, 'Travis Scrimshaw' via sage-devel wrote:
>
> That is simply not true right now. The # optional sage.* doctests as a
> user-visible change.
>
These tags aren't essential to the modularization itself. They're an
artifact of bad tests:
* doctests are in general just a
Perhaps one can introduce a tag #needsmodule
Yours is the
latest: https://github.com/sagemath/sage/issues/35750#issuecomment-1594072121
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving
On Fri, 16 Jun 2023, 02:08 'Travis Scrimshaw' via sage-devel, <
sage-devel@googlegroups.com> wrote:
>
> On Monday, June 12, 2023 at 10:53:38 AM UTC+9 Matthias Koeppe wrote:
>
> On Sunday, June 11, 2023 at 6:20:03 PM UTC-7 Travis Scrimshaw wrote:
>
> My understanding of William's goal (please
On Thu, Jun 15, 2023 at 6:49 PM 'Travis Scrimshaw' via sage-devel
wrote:
>
> Hi William,
>That is interesting. Although my take on that is following Matthias's
> proposal, they will just use one (or more) part of Sage as a Python library.
> So if they switch, in effect they will still be
On Thursday, June 15, 2023 at 6:58:36 PM UTC-7 Travis Scrimshaw wrote:
I've been following along with different pieces to see how it's going. You
are right, in part I am bringing this up now because it is is affecting
code I care about (and regularly use to promote Sage)
Well, when you
On Friday, June 16, 2023 at 10:58:36 AM UTC+9 Travis Scrimshaw wrote:
... but it is also starting to come with policy implications due to its
scale that are not easy to revert.
Right. So I welcome all these discussions. We (the developers and even
those focusing on research mathematics) need
On Friday, June 16, 2023 at 10:49:49 AM UTC+9 Kwankyu Lee wrote:
The Sage distribution will continue to exist. There will be no user-visible
change coming from the modularization project for the users of the Sage
distribution.
That is simply not true right now. The # optional sage.*
The Sage distribution will continue to exist. There will be no user-visible
change coming from the modularization project for the users of the Sage
distribution.
That is simply not true right now. The # optional sage.* doctests as a
user-visible change.
Matthias means that all pieces (the
Hi William,
That is interesting. Although my take on that is following Matthias's
proposal, they will just use one (or more) part of Sage as a Python
library. So if they switch, in effect they will still be dropping Sage. I
don't see Sage as having its own custom language other than some
On Thursday, June 15, 2023 at 6:08:36 PM UTC-7 Travis Scrimshaw wrote:
On Monday, June 12, 2023 at 10:53:38 AM UTC+9 Matthias Koeppe wrote:
It works the other way around. B and C (applied to individual Cython/Python
modules) were/are _obstacles_ to making modularized pip-installable
On Monday, June 12, 2023 at 10:53:38 AM UTC+9 Matthias Koeppe wrote:
On Sunday, June 11, 2023 at 6:20:03 PM UTC-7 Travis Scrimshaw wrote:
My understanding of William's goal (please correct me if I am wrong) was to
put everything together so nobody was trying to build a better wheel. To
me, by
Hi Sage Devs,
As further motivation for this discussion of "Modularization project:
I. The goals", here is a quote from a discussion just now (with
permission) from Eric Deeds, who is the vice chair for Life Sciences
Math Courses and Professor of Integrative Biology and Physiology at
UCLA:
"I
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
On Monday, June 12, 2023 at 11:18:05 AM UTC-7 Nathan Dunfield wrote:
[...] 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
Hi Nathan,
What parts of Sage does SnapPy use? (I was starting to look
at
https://github.com/search?q=repo%3A3-manifolds%2FSnapPy+%2F%28import+sage%7Csage.*import%29%2F=code=1
but this would take a while...)
Matthias
On Monday, June 12, 2023 at 11:18:05 AM UTC-7 Nathan Dunfield wrote:
> For
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
On Sun, Jun 11, 2023 at 6:53 PM Matthias Koeppe
wrote:
> On Sunday, June 11, 2023 at 6:20:03 PM UTC-7 Travis Scrimshaw wrote:
>
> My understanding of William's goal (please correct me if I am wrong) was
> to put everything together so nobody was trying to build a better wheel. To
> me, by
On Sunday, June 11, 2023 at 6:20:03 PM UTC-7 Travis Scrimshaw wrote:
My understanding of William's goal (please correct me if I am wrong) was to
put everything together so nobody was trying to build a better wheel. To
me, by splitting everything up into these small pieces, it seems contrary
to
I strongly disagree with your conclusion that this is a bug, much less a
severe one. My understanding of William's goal (please correct me if I am
wrong) was to put everything together so nobody was trying to build a
better wheel. To me, by splitting everything up into these small pieces, it
On Friday, June 9, 2023 at 12:40:52 AM UTC-7 Dima Pasechnik wrote:
some other examples of such pip-installable spin-offs of parts of
Sage, some with binary wheels, some without, are pplpy, cysignals,
primecountpy
(more of this should come)
Yes! Making sure that all of these have
On Fri, Jun 9, 2023 at 1:02 AM Matthias Koeppe wrote:
>
> On Thursday, June 8, 2023 at 4:40:06 PM UTC-7 Michael Orlitzky wrote:
>
> Pip [...] can't do anything with the non-python software on which sage
> subsists.
> To make sage-via-pip work, we'll have to maintain a new pseudo-
> distribution
On Thursday, June 8, 2023 at 4:40:06 PM UTC-7 Michael Orlitzky wrote:
Pip [...] can't do anything with the non-python software on which sage
subsists.
To make sage-via-pip work, we'll have to maintain a new pseudo-
distribution on pypi that either ships people pre-built wheels or wraps
On Thu, 2023-06-08 at 14:09 -0700, Matthias Koeppe wrote:
>
> *D. *As a consequence of B and C, it was *impossible to build or run parts
> of the Sage library.* And it is *impossible to install the whole Sage
> library using Python infrastructure* (pip). (Yes, I know that conda exists.)
>
Of
Dear all,
I proposed the modularization project three years ago, in May 2020, in the
post https://groups.google.com/g/sage-devel/c/M9QTWtln6zU/m/UHwkrmTKBQAJ
The most recent substantial discussions on sage-devel on this topic took
place in Oct/Nov 2021; and I gave a presentation on it in June
39 matches
Mail list logo