I don't understand what you are saying. When you say "works on Windows" do
you mean that the build works? I am certain that sig_on and sig_off do not
work on Windows if you have not added any Windows-specific signal handling.
Yes, the build works on Windows as well as all tests are passing
On 20 November 2024 01:06:39 GMT-06:00, "'tobia...@gmx.de' via sage-devel"
wrote:
>The new version of cysignals, released just a couple of hours ago, now
>builds using Meson and works fine on Windows. Thanks Dima and Frédéric for
>the quick reviews and the new release!
I still need to figur
On Wed, Nov 20, 2024 at 10:34 AM Antonio Rojas wrote:
>
> El miércoles, 20 de noviembre de 2024 a las 15:37:32 UTC+1, dim...@gmail.com
> escribió:
>
>
>
> On 20 November 2024 01:06:39 GMT-06:00, "'tobia...@gmx.de' via sage-devel"
> wrote:
> >The new version of cysignals, released just a couple
Hi Marc,
On Wed, Nov 20, 2024 at 8:55 AM Marc Culler wrote:
>
>
>
> On Wednesday, November 20, 2024 at 1:06:39 AM UTC-6 tobia...@gmx.de wrote:
>
> The new version of cysignals, released just a couple of hours ago, now builds
> using Meson and works fine on Windows.
>
>
>
> @Marc, Nathan & collab
El miércoles, 20 de noviembre de 2024 a las 15:37:32 UTC+1,
dim...@gmail.com escribió:
On 20 November 2024 01:06:39 GMT-06:00, "'tobia...@gmx.de' via sage-devel" <
sage-...@googlegroups.com> wrote:
>The new version of cysignals, released just a couple of hours ago, now
>builds using Meson and
On Wednesday, November 20, 2024 at 1:06:39 AM UTC-6 tobia...@gmx.de wrote:
The new version of cysignals, released just a couple of hours ago, now
builds using Meson and works fine on Windows.
@Marc, Nathan & collaborators: I've seen that CyPari has some
Windows-specific signal handling. Wo
The new version of cysignals, released just a couple of hours ago, now
builds using Meson and works fine on Windows. Thanks Dima and Frédéric for
the quick reviews and the new release! At the moment, we don't provide
wheels for windows but this can be added if it's a hard requirement for you
or
For a timely example of how PyPI size limits can be very real, JupyterLab's
is hitting this right now:
https://github.com/jupyterlab/jupyterlab/issues/16859
ERRORHTTPError: 400 Bad Request from https://upload.pypi.org/legacy/
Project size too large. Limit for project 'jupyterlab' tot
PRs to cysignals are most welcome. It should not be impossible to hook up a
Windows CI and wheel builder in cysignals, too.
On Wednesday, October 9, 2024 at 6:14:58 PM UTC+1 marc@gmail.com wrote:
> On Wednesday, October 9, 2024 at 9:32:27 AM UTC-6 Gonzalo Tornaría wrote:
>
> As far as I know
On Wed, 9 Oct 2024 at 18:15, Marc Culler wrote:
>
> On Wednesday, October 9, 2024 at 9:32:27 AM UTC-6 Gonzalo Tornaría wrote:
>
> > As far as I know, cysignals is another instance of a component originally
> > developed for sagemath, about maybe 20 years ago, then separated into a
> > standalone
On Wednesday, October 9, 2024 at 9:32:27 AM UTC-6 Gonzalo Tornaría wrote:
As far as I know, cysignals is another instance of a component originally
developed for sagemath, about maybe 20 years ago, then separated into a
standalone package. In theory, this separation should make it easier to
sup
On Wednesday, October 9, 2024 at 2:17:34 AM UTC-3 marc@gmail.com wrote:
The problem with Windows is just that cypari2 does not support it.
CyPari works fine on Windows. There is some trickiness required to
get cysignals to work on Windows. This is because sage's
implementation of sig_on cal
specifically, this is PEP 759 – External Wheel Hosting (
https://peps.python.org/pep-0759)
and there
https://peps.python.org/pep-0759/#addressing-pypi-limits
On Wednesday, October 9, 2024 at 1:12:56 AM UTC+1 Dima Pasechnik wrote:
> I read on Python Discource a proposal to allow externally hosted
Currently, when you try to package sage on a new distro, you need to have
all dependencies installed before you can even explore building sage. The
modularization effort could be helpful in this regard, because it enables a
more incremental approach where you first package a smaller subset of th
On Tue, Oct 8, 2024 at 8:52 PM 'Gonzalo Tornaría' via sage-devel
wrote:
> For me cypari2 works really nice and it's not particularly difficult to
> package (except it broke with pari 2.17, but of course having this as a
> standalone package makes it much easier to fix it). What is the problem w
On Monday, October 7, 2024 at 10:26:52 AM UTC-3 marc@gmail.com wrote:
On Monday, October 7, 2024 at 12:05:25 AM UTC-5 Kwankyu Lee wrote:
On the other hand, who would be the users of the distribution packages for
whatever need? I wonder how they overlap with sage developers.
A concrete exam
FWIW, the source distribution of sagemath 10.4 (from pypy) is about 20M,
see https://pypi.org/project/sagemath-standard/#files
We build the sagemath package for void linux from this source alone,
obtaining a binary package of about 55M, see
https://voidlinux.org/packages/?arch=x86_64&q=sagemath
I read on Python Discource a proposal to allow externally hosted
wheels on PyPI. With PyPI only hosting metadata and
checksums. I imagine this will lift the size constraints, if accepted.
Dima
On Tuesday, October 8, 2024 at 11:59:12 PM UTC+1 Nils Bruin wrote:
> On Tuesday 8 October 2024 at 15:40
On Tuesday 8 October 2024 at 15:40:07 UTC-7 oscar.j@gmail.com wrote:
> As you're pointing out, sage still fits within 10GB in source, so it
looks like sagemath could just be one pypi package.
I think that you have misunderstood the limits that Marc was referring
to. The 100MB file limits m
> > On Tuesday 8 October 2024 at 13:20:54 UTC-7 marc@gmail.com wrote:
>
> On Tuesday, October 8, 2024 at 1:23:55 PM UTC-6 Nils Bruin wrote:
>
> > Pypi packages have a default size limit of 100MB per file and 10GB per
> > project.
>
> As you're pointing out, sage still fits within 10GB in sourc
On Tuesday 8 October 2024 at 13:20:54 UTC-7 marc@gmail.com wrote:
On Tuesday, October 8, 2024 at 1:23:55 PM UTC-6 Nils Bruin wrote:
- the examples we have of bits of software developed as part of sage that
ended up as library components of other projects are peripheral,
interfacing parts
On Tuesday, October 8, 2024 at 1:23:55 PM UTC-6 Nils Bruin wrote:
- the examples we have of bits of software developed as part of sage that
ended up as library components of other projects are peripheral,
interfacing parts that were spun off into independent libraries.
- we don't have exampl
Summarizing what I've seen come by here:
- the examples we have of bits of software developed as part of sage that
ended up as library components of other projects are peripheral,
interfacing parts that were spun off into independent libraries.
- we don't have examples of core functionality
On 22:35 Mon 07 Oct 2024, Dima Pasechnik wrote:
Indeed, Flint is dual licensed under GPL and LGPL - so why don't we
re-license sagelib under LGPL then.
...[SNIP]...
I don't know whether it'd need a lot of individual approvals, but
GPL->LGPL is certainly done quite often. E.g. GMP was relicenced u
> Mind you, Mathematica (!) bundles Flint (which is GPL, and depends on
GPLd libraries).
This is wrong. Flint is LGPLv3, which is what enables Mathematica to link
to it.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this
On Mon, Oct 7, 2024 at 8:37 PM Oscar Benjamin
wrote:
>
> On Mon, 7 Oct 2024 at 20:19, Dima Pasechnik wrote:
> >
> > Mind you, Mathematica (!) bundles Flint (which is GPL, and depends on
> > GPLd libraries).
>
> FLINT is LGPL as are its dependencies GMP and MPFR.
>
> I'm no expert on license terms
On Mon, 7 Oct 2024 at 20:19, Dima Pasechnik wrote:
>
> Mind you, Mathematica (!) bundles Flint (which is GPL, and depends on
> GPLd libraries).
FLINT is LGPL as are its dependencies GMP and MPFR.
I'm no expert on license terms but Wikipedia says:
The main difference between the GPL and the LGPL
On Mon, Oct 7, 2024 at 7:56 PM Michael Orlitzky wrote:
>
> On Mon, 2024-10-07 at 11:47 -0700, William Stein wrote:
> >
> > Licensing is a critical part of evaluating this. For example, mpmath is
> > BSD licensed. Even if chopping up the core of Sage produced things that
> > are useful, a lot of
On Mon, Oct 7, 2024 at 7:48 PM William Stein wrote:
>
>
> Dima:
>>
>> If we concentrated on facilitating the latter, rather than on
>> distribution packages, it could have been there now.
>
>
> +1
>
> Nils:
> > I have yet to see a convincing example where chopping up core architecture
> > of sage
On Mon, Oct 7, 2024 at 5:15 PM Michael Orlitzky wrote:
>
> On Mon, 2024-10-07 at 07:55 -0700, William Stein wrote:
> > Hi,
> >
> > There are a number of big chunks of functionality in Sage, like interval
> > arithmetic (I was just going to say this and Marc beat me to it), and the
> > sage prepars
On Mon, 2024-10-07 at 11:47 -0700, William Stein wrote:
>
> Licensing is a critical part of evaluating this. For example, mpmath is
> BSD licensed. Even if chopping up the core of Sage produced things that
> are useful, a lot of projects wouldn't touch them due to the GPLv3
> license. (Networkx
Dima:
> If we concentrated on facilitating the latter, rather than on
> distribution packages, it could have been there now.
>
+1
Nils:
> I have yet to see a convincing example where chopping up core
architecture of sagemath (like the coercion framework, the category
framework, etc) leads to usa
On Mon, 2024-10-07 at 07:55 -0700, William Stein wrote:
> Hi,
>
> There are a number of big chunks of functionality in Sage, like interval
> arithmetic (I was just going to say this and Marc beat me to it), and the
> sage preparser, which could be valuable as separate packages that Sage uses.
>
>
On Monday 7 October 2024 at 06:26:52 UTC-7 marc@gmail.com wrote:
A concrete example of a useful standalone Sage module is CyPari2. By
including CyPari within SnapPy we are able to make it possible to compute
number theoretic invariants of hyperbolic manifolds. We are unable to use
Sage's
Hi,
There are a number of big chunks of functionality in Sage, like interval
arithmetic (I was just going to say this and Marc beat me to it), and the
sage preparser, which could be valuable as separate packages that Sage uses.
License of Sage is GPLv3, whereas the vast majority of the scientific
On Mon, Oct 7, 2024 at 2:26 PM Marc Culler wrote:
>
>
>
> On Monday, October 7, 2024 at 12:05:25 AM UTC-5 Kwankyu Lee wrote:
>
> On the other hand, who would be the users of the distribution packages for
> whatever need? I wonder how they overlap with sage developers.
>
>
> A concrete example of
On Mon, Oct 7, 2024 at 11:47 AM Kwankyu Lee wrote:
>
> On Monday, October 7, 2024 at 6:38:34 PM UTC+9 oscar.j@gmail.com wrote:
>
> ... There would also be a strong incentive to try to carve out
> a meaningful subset of Sage for end-users that was more portable ...
>
>
> "portable" sounds a goo
On Mon, Oct 7, 2024 at 10:38 AM Oscar Benjamin
wrote:
>
> On Mon, 7 Oct 2024 at 06:05, Kwankyu Lee wrote:
> >
> > On Monday, October 7, 2024 at 12:24:04 AM UTC+9 marc@gmail.com wrote:
> >
> > > I would say that the motivation is to make it possible for a developer to
> > > include a self-con
For me, this is another instance of a user point of view versus a developer
point of view.
Coming from someone who tries to make SageMath easily available for
ordinary people, Marc's views are all the more valuable IMHO.
An individual mathematician who only needs some portion of the sage libr
On Monday, October 7, 2024 at 12:05:25 AM UTC-5 Kwankyu Lee wrote:
On the other hand, who would be the users of the distribution packages for
whatever need? I wonder how they overlap with sage developers.
A concrete example of a useful standalone Sage module is CyPari2. By
including CyPari
On Monday, October 7, 2024 at 6:38:34 PM UTC+9 oscar.j@gmail.com wrote:
... There would also be a strong incentive to try to carve out
a meaningful subset of Sage for end-users that was more portable ...
"portable" sounds a good adjective to characterize distribution packages.
Another may
On Mon, 7 Oct 2024 at 06:05, Kwankyu Lee wrote:
>
> On Monday, October 7, 2024 at 12:24:04 AM UTC+9 marc@gmail.com wrote:
>
> > I would say that the motivation is to make it possible for a developer to
> > include a self-contained portion of sage in a separate project without
> > having to m
On Monday, October 7, 2024 at 12:24:04 AM UTC+9 marc@gmail.com wrote:
I would say that the motivation is to make it possible for a developer to
include a self-contained portion of sage in a separate project without
having to make that project as large as a full Sage distribution.
OK. That
el] Re: [debian-science] Modularized sagemath packages:
proof of concept
[EXTERNAL]
I wholly agree with Marc.
For me, this is another instance of a user point of view versus a developer
point of view.
Coming from someone who tries to make SageMath easily available for ordinary
people, Marc'
I wholly agree with Marc.
For me, this is another instance of a user point of view versus a developer
point of view.
Coming from someone who tries to make SageMath easily available for
ordinary people, Marc's views are all the more valuable IMHO.
Guillermo
On Sun, 6 Oct 2024 at 17:24, Marc Cull
On Thursday, October 3, 2024 at 8:05:09 PM UTC-5 Kwankyu Lee wrote:
The motivation of the modularization project is to reduce the burden who
only needs some portion of the sage library,
and wants to use and develop the portion within the python ecosystem.
I would say that the motivation is to
We are observing disadvantage of a long thread.
It is also very useful to have it all in one thread though.
it's more work with the modularised system, not less
On the project level, It takes more work to provide more products
(distribution packages) to users.
I completely agree with
We are observing disadvantage of a long thread.
At some point, other participants forget the context in which a participant
write a comment.
Dima and I were talking about a fictional sagemath-number-theory
distribution package.
I imagined a user/developer who installed sagemath-number-theory, a
On Thu, Oct 3, 2024 at 11:01 PM Matthias Koeppe
wrote:
>
> On Thursday, October 3, 2024 at 1:18:44 PM UTC-7 Dima Pasechnik wrote:
>
> Why is it quicker than running ./sage -t src/sage/lfunctions src/sage/rings/
> (perhaps few other should be added) on a full sagelib install?
>
>
> You are missing
On Thursday, October 3, 2024 at 1:18:44 PM UTC-7 Dima Pasechnik wrote:
Why is it quicker than running ./sage -t src/sage/lfunctions
src/sage/rings/
(perhaps few other should be added) on a full sagelib install?
You are missing the point.
The main point of testing a modularized distribution i
On Thursday, October 3, 2024 at 1:16:12 PM UTC-7 Dima Pasechnik wrote:
what's so special about an updated sagemath-categories distribution so that
you absolutely must base the brial update on them?
Distributions are just wrappers for code, after all.
"Wrappers"? No.
Instead of using -distri
On Thursday, October 3, 2024 at 2:47:20 AM UTC-7 axio...@yahoo.de wrote:
> There's a simple and important principle of Open Source: Trust those who
are doing the work.
I cannot quite pin it down,
I think it's worth to engage in a bit more of reflection.
but this sounds fishy to me. Maybe bec
On Thursday, October 3, 2024 at 5:26:09 AM UTC-7 axio...@yahoo.de wrote:
It seems to me that one of the main innovations of sage (among other CAS)
was to make writing doctests really easy *and* keep them together with the
code *and* make testing them *while developing* very straightforward.
Ye
On Thursday, October 3, 2024 at 6:11:48 AM UTC-7 Kwankyu Lee wrote:
It seems to me that one of the main innovations of sage (among other CAS)
was to make writing doctests really easy *and* keep them together with the
code *and* make testing them *while developing* very straightforward.
True!
On Thu, Oct 3, 2024 at 2:11 PM Kwankyu Lee wrote:
>
> It seems to me that one of the main innovations of sage (among other CAS) was
> to make writing doctests really easy *and* keep them together with the code
> *and* make testing them *while developing* very straightforward.
>
>
> True!
>
>
> T
On 3 October 2024 11:30:38 BST, Kwankyu Lee wrote:
>I can imagine this:
>
>sagemath-number-theory won't have the coding theory portion of the sage
>library. Hence developers for sagemath-number-theory could test their
>favorite distribution package quicker.
However, they'd need to test all p
On Wednesday, October 2, 2024 at 2:48:10 PM UTC-7 oscar.j@gmail.com
wrote:
In my mind it could make sense for there to be a sagemath-minimal
package which from a user perspective represents a "minimal
installation of Sage" in comparison to say a package called
sagemath-full. The implicatio
On Wednesday, October 2, 2024 at 1:08:37 AM UTC-7 axio...@yahoo.de wrote:
the description given by Matthias, reproduced below, makes no sense to me
at all.
> The other contents of *sagemath-categories* are provided in similar
spirit. For example, there are the Function objects from sage.functi
And I have repeatedly explained that no matter how brial and
sagemath-categories are related, one can perfectly either
have a completely independent PR for brial, or
base the brial one on a PR that deals with updates to sagemath-whatever
distribution(s).
If X depends on Y, make a PR for Y, an
It seems to me that one of the main innovations of sage (among other CAS)
was to make writing doctests really easy *and* keep them together with the
code *and* make testing them *while developing* very straightforward.
True!
The final of these three points would be broken *by encouraging d
I think that this would be a major step backwards. Currently, if I make
changes in one part of sage (right now: polynomials), I am sometimes a bit
surprised where I am breaking code (in the case at hand: braid groups). Of
course, this is rarely surprising once I look at the code, but I don't h
I can imagine this:
sagemath-number-theory won't have the coding theory portion of the sage
library. Hence developers for sagemath-number-theory could test their
favorite distribution package quicker.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" gr
> It may provide a "sage" with elementary mathematics that all advanced
mathematics depend
There is no boundary between "elementary" and "advanced" mathematics.
Also, there is no boundary between "discrete mathematics" and "complex
analysis" or "numerics".
> There's a simple and important pri
In my mind it could make sense for there to be a sagemath-minimal
package which from a user perspective represents a "minimal
installation of Sage" in comparison to say a package called
sagemath-full.
sagemath-standard is your sagemath-full.
I think distribution packages in the current des
On Wed, 2 Oct 2024 at 18:16, Matthias Koeppe wrote:
> On Tuesday, October 1, 2024 at 10:54:36 PM UTC-7 axio...@yahoo.de wrote:
>>
>> What do you have in mind people would do with just the stuff in
>> `categories`?
>
> As the dependency diagram shows -- it works as the common dependency of
> va
On Wednesday, October 2, 2024 at 1:08:37 AM UTC-7 axio...@yahoo.de wrote:
... What I tried to say is that the core distribution should have minimal
dependencies, but contain as much of sage as possible.
More code requires more dependencies. The "core distribution" as you
describe is not possi
On Wednesday, October 2, 2024 at 1:57:48 AM UTC-7 Dima Pasechnik wrote:
I don't think it's wise to subject people to more messy misnamed
things than it is absolutely necessary.
Once people are used to bad designs and wrong names (assuming there is
anyone left working with them!),
it's pretty h
On Wednesday, October 2, 2024 at 1:57:48 AM UTC-7 Dima Pasechnik wrote:
They do provide a random subset of concrete implementations - e.g.
polynomials.
It's not "random".
What is included is the result of years of my work on code and tests, to
find a viable subset that can be separately bui
On Wednesday, October 2, 2024 at 1:57:48 AM UTC-7 Dima Pasechnik wrote:
> And for sure doing any such renaming games will be outside of the scope
of the PR in question. https://github.com/sagemath/sage/pull/36380 should
not wait for it.
#36380 is first of all waiting for, requested by more tha
On Tuesday, October 1, 2024 at 10:54:36 PM UTC-7 axio...@yahoo.de wrote:
So, it turns out that
> * a core distribution with absolutely minimal dependencies and only
dependencies which have proved stable on all supported platforms
>
> This is exactly sagemath-categories. It has absolutely minim
On Wed, Oct 2, 2024 at 12:43 AM Matthias Koeppe
wrote:
>
> On Sunday, September 29, 2024 at 12:15:04 AM UTC-7 Dima Pasechnik wrote:
>
> On 29 September 2024 01:50:39 BST, Matthias Koeppe
> wrote:
> >On Saturday, September 28, 2024 at 5:21:56 PM UTC-7 oscar.j@gmail.com
> >wrote:
> >
> >On Sun
On Wed, Oct 2, 2024 at 6:54 AM 'Martin R' via sage-devel
wrote:
>
> So, it turns out that
> > * a core distribution with absolutely minimal dependencies and only
> > dependencies which have proved stable on all supported platforms
> >
> > This is exactly sagemath-categories. It has absolutely min
... What I tried to say is that the core distribution should have minimal
dependencies, but contain as much of sage as possible.
More code requires more dependencies. The "core distribution" as you
describe is not possible.
I don't understand this, and I don't understand why some "function
There are two factors that forms a distribution package: (a) mathematical
contents of the code and (b) dependencies (external software packages) that
supports the code.
Some distribution packages are named after mathematical contents and others
are named after the main dependency.
Distribution
So, it turns out that
> * a core distribution with absolutely minimal dependencies and only
dependencies which have proved stable on all supported platforms
>
> This is exactly sagemath-categories. It has absolutely minimal
dependencies
is not what I tried to say. What I tried to say is that
On Sunday, September 29, 2024 at 1:30:38 AM UTC-7 axio...@yahoo.de wrote:
I think that `sagemath--minimal-dependencies` would be clear, wouldn't it?
Again fails the "minimal for what" test; and fails to distinguish
*sagemath-categories* from *sagemath-objects* (which has the same
dependencies
On Sunday, September 29, 2024 at 12:15:04 AM UTC-7 Dima Pasechnik wrote:
On 29 September 2024 01:50:39 BST, Matthias Koeppe
wrote:
>On Saturday, September 28, 2024 at 5:21:56 PM UTC-7 oscar.j@gmail.com
>wrote:
>
>On Sun, 29 Sept 2024 at 00:22, Matthias Koeppe
>wrote:
>> On Saturday, S
On Sunday, September 29, 2024 at 5:31:15 PM UTC+9 axio...@yahoo.de wrote:
Please don't fragment this discussion. It seems productive to me currently.
According to the recent survey, visitors to sage-devel seem to get tired of
lengthy technical discussions with only a few people involved. This
Please don't fragment this discussion. It seems productive to me currently.
On Sunday 29 September 2024 at 09:09:42 UTC+2 Kwankyu Lee wrote:
> I welcome this discussion on the design of modularized distribution
> packages.
>
> Perhaps Matthias has his design fixed in his plan. But I believe th
> I could also imagine to have three layers:
>
> * a core distribution with absolutely minimal dependencies and only
dependencies which have proved stable on all supported platforms
>
> This is exactly sagemath-categories. It has absolutely minimal
dependencies.
Would it make sense to gi
On 29 September 2024 01:50:39 BST, Matthias Koeppe
wrote:
>On Saturday, September 28, 2024 at 5:21:56 PM UTC-7 oscar.j@gmail.com
>wrote:
>
>On Sun, 29 Sept 2024 at 00:22, Matthias Koeppe
>wrote:
>> On Saturday, September 28, 2024 at 12:28:30 PM UTC-7 axio...@yahoo.de
>wrote:
>>
>> I
I welcome this discussion on the design of modularized distribution
packages.
Perhaps Matthias has his design fixed in his plan. But I believe the
modularization project would succeed only when many sage developers
understand and accept the design.
Hence it is crucial that we have open discus
On Saturday, September 28, 2024 at 5:21:56 PM UTC-7 oscar.j@gmail.com
wrote:
On Sun, 29 Sept 2024 at 00:22, Matthias Koeppe
wrote:
> On Saturday, September 28, 2024 at 12:28:30 PM UTC-7 axio...@yahoo.de
wrote:
>
> I could also imagine to have three layers:
>
> * a core distribution wi
On Sun, 29 Sept 2024 at 00:22, Matthias Koeppe wrote:
>
> On Saturday, September 28, 2024 at 12:28:30 PM UTC-7 axio...@yahoo.de wrote:
>
> I could also imagine to have three layers:
>
> * a core distribution with absolutely minimal dependencies and only
> dependencies which have proved stable on
On Saturday, September 28, 2024 at 12:28:30 PM UTC-7 axio...@yahoo.de wrote:
I could also imagine to have three layers:
* a core distribution with absolutely minimal dependencies and only
dependencies which have proved stable on all supported platforms
This is exactly *sagemath-categories*. I
On Saturday, September 28, 2024 at 11:24:46 AM UTC-7 Dima Pasechnik wrote:
[...] fixing the breakage in distribution A might induce a
breakage in distribution B,
as they overlap in hard to keep in mind, spaghetti-like, ways.
No, the distributions do not overlap. They are disjoint.
--
You rec
A much more meaningful design, and an obvious improvement, would be to
have a (say) sagemath-smallcore, where, say, 70% of
sagelib functionality is, with the remaining parts based off this
sagemath-smallcore.
I agree. This sounds more reasonable to me. I could also imagine to have
three
On Sat, Sep 28, 2024 at 3:02 AM Matthias Koeppe
wrote:
>
> On Friday, September 27, 2024 at 2:25:07 PM UTC-7 axio...@yahoo.de wrote:
>
> The diagram you link to indicates that sagemath-categories is almost at the
> bottom, whereas sagemath-symbolics is almost at the top of the hierarchy that
> y
On Friday, September 27, 2024 at 11:52:51 PM UTC-7 axio...@yahoo.de wrote:
this PR introduces a new kind of file, `all__sagemath_categories.py`,
Not, it's not a new kind of file. These files have been around since Sage
9.6 (https://github.com/sagemath/sage/issues/29865).
The main purpose of t
Yes, I had to care about the `all.py` files whenever I added something that
should be exposed to the user. Eg., Bijectionist, LazyXXXSeriesRing,
GrowthDiagram, whatever.
So, at the very least I would like to know what decides whether something
goes into `all__sagemath_categories` and what does
On Saturday, September 28, 2024 at 3:52:51 PM UTC+9 axio...@yahoo.de wrote:
However, this PR introduces a new kind of file,
`all__sagemath_categories.py`, into (almost?) *every* subdirectory of src.
Thus, it seems to me that this affects almost all developers - after all
these files have to b
I think that "technical discussion" refers to "discussion about a technical
detail".
However, this PR introduces a new kind of file,
`all__sagemath_categories.py`, into (almost?) *every* subdirectory of src.
Thus, it seems to me that this affects almost all developers - after all
these files
I don't see why `simplify` should be in something named
`sagemath_categories`.
How is it decided whether a function should be a function in `Sage
categories, basic rings, polynomials, functions`?
Martin
On Saturday 28 September 2024 at 04:02:26 UTC+2 Matthias Koeppe wrote:
> On Friday, Septemb
On Friday, September 27, 2024 at 7:02:17 PM UTC-7 Dima Pasechnik wrote:
It seems that it puts about 50% or more of Sage into sagemath-categories,
cause it includes SR (with calculus), polynomial rings, etc. One may ask
whether it's worthwhile to have at all in this form.
No, SR is not in *sage
On Friday, September 27, 2024 at 2:41:21 PM UTC-7 Dima Pasechnik wrote:
If this is the case then the brial related PR ought to come after the
sagemath-objects and -categories stuff PR. (Or maybe more than one PR).
No, the PR has a suitable scope, and it has already been reviewed.
--
You recei
On Friday, September 27, 2024 at 2:25:07 PM UTC-7 axio...@yahoo.de wrote:
The diagram you link to indicates that sagemath-categories is almost at the
bottom, whereas sagemath-symbolics is almost at the top of the hierarchy
that you propose.
That's right.
However, the PR includes a file
s
Just to add that the PR as it is now changes over 100 files, and about 2000
lines of code.
And it goes about 4 different topics.
Thanks, Martin, for taking time looking into it. It seems that it puts about
50% or more of Sage into sagemath-categories, cause it includes SR (with
calculus), poly
Everyone here,
According to the recent survey, people complain lengthy technical
discussions happening in sage-devel, that many of them find irrelevant to
their interests.
If a thread in sage-devel involves a technical discussion, how about
opening a new Discussion
in https://github.com/sagem
On Saturday, September 28, 2024 at 6:25:07 AM UTC+9 axio...@yahoo.de wrote:
... All of these are then imported by src/sage/all__sagemath_categories.py
I don't think that I understand the purpose of sagemath_categories.
Do you know the purpose of files like `all__xxx`? The purpose of these
file
If this is the case then the brial related PR ought to come after the
sagemath-objects and -categories stuff PR. (Or maybe more than one PR).
It would be easier for reviewers, and moreover easier to find reviewers.
On 27 September 2024 21:34:09 BST, Matthias Koeppe
wrote:
>On Friday, Septem
1 - 100 of 105 matches
Mail list logo
