[sage-devel] Re: Master plan of sage modularization
> Let me sketch my strategy to get closer to the design of other > distributions. https://trac.sagemath.org/ticket/29865 (waiting for > review) introduces the two lowest levels - *sagemath-objects*, > *sagemath-categories.* As soon as we have namespace packages working, the > latter will depend on the former. The current issue with both of these > distributions is that they are not really separately testable because the > doctests for these modules depend on a lot of other functionality from > higher-level parts of the library. In contrast, in > https://trac.sagemath.org/ticket/32432, we are working on a medium-sized > distribution *sagemath-polyhedra*, which be the first modularized > distribution that is useful for end users. It will also be sufficiently > self-contained for running most doctests (but some doctests that depend on > other parts of the library are marked # optional). Between > *sagemath-categories > *and *sagemath-polyhedra *(which depends on *sagemath-categories*) there > is room for designing intermediate distributions. For example, there could > be a distribution that contains the linear algebra needed by > *sagemath-polyhedra* (i.e., parts of the sage.modules and sage.matrix). > > At the coarsest level, *sagemath-symbolics (* > https://trac.sagemath.org/ticket/31695) and *sagemath-standard-no-symbolics > *(https://trac.sagemath.org/ticket/32601) are intended to form a > partition of all Sage standard library modules that are not already in > *sagemath-categories > *(or its dependencies). Below these two distributions, again there is > room for designing various intermediate distributions. The design will be > best if done by (or in ollaboration with) developers who are knowledgable > about specific parts of the Sage library corresponding to the various areas > of mathematics. > Thank you. This would be a start. For example, if there would be a distribution sagemath-coding that contains sage/coding, then would we have this hierarchy sagemath-objects < sagemath-categories < sagemath-standard-no-symbolics < ... < sagemath-coding where ... might be filled with other intermediate distributions like, I imagine, sagemath-rings, sagemath-schemes? In general, would this hierarchy have a tree structure? -- 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/079c0635-7611-42a3-a230-d6f258f4145en%40googlegroups.com.
[sage-devel] Re: Master plan of sage modularization
On Wednesday, November 17, 2021 at 10:01:47 PM UTC-8 Kwankyu Lee wrote: > On Thursday, November 18, 2021 at 11:47:37 AM UTC+9 Matthias Koeppe wrote: > >> That would be https://trac.sagemath.org/ticket/29705 > > > Yes, all the information could be found in the ticket description and the > descriptions of the subtickets. But the master plan is buried in the > details. I want to see how the whole sage library would be split into what > distributions at the end of the modularization effort, and how the > distributions depend on another if any. > The design of the distributions is not completely settled. I am hoping that Interested developers will join the effort in completing the design. Hard constraints on the distributions come from compile-time dependencies of Cython modules on C/C++ libraries. We can define some meaningful small distributions that just consist of a single or a few Cython modules. For example, *sagemath-tdlib* (https://trac.sagemath.org/ticket/29864) would just package the single Cython module that must be linked with tdlib, sage.graphs.graph_decompositions.tdlib. In the Sage 9.6 cycle, as soon as namespace packages are activated (by dropping __init__.py files), we can start to create these distributions. This is quite a mechanical task -- for each distribution it's just a new directory in pkgs/ with some metadata files. Let me sketch my strategy to get closer to the design of other distributions. https://trac.sagemath.org/ticket/29865 (waiting for review) introduces the two lowest levels - *sagemath-objects*, *sagemath-categories.* As soon as we have namespace packages working, the latter will depend on the former. The current issue with both of these distributions is that they are not really separately testable because the doctests for these modules depend on a lot of other functionality from higher-level parts of the library. In contrast, in https://trac.sagemath.org/ticket/32432, we are working on a medium-sized distribution *sagemath-polyhedra*, which be the first modularized distribution that is useful for end users. It will also be sufficiently self-contained for running most doctests (but some doctests that depend on other parts of the library are marked # optional). Between *sagemath-categories *and *sagemath-polyhedra *(which depends on *sagemath-categories*) there is room for designing intermediate distributions. For example, there could be a distribution that contains the linear algebra needed by *sagemath-polyhedra* (i.e., parts of the sage.modules and sage.matrix). At the coarsest level, *sagemath-symbolics (*https://trac.sagemath.org/ticket/31695) and *sagemath-standard-no-symbolics *(https://trac.sagemath.org/ticket/32601) are intended to form a partition of all Sage standard library modules that are not already in *sagemath-categories *(or its dependencies). Below these two distributions, again there is room for designing various intermediate distributions. The design will be best if done by (or in ollaboration with) developers who are knowledgable about specific parts of the Sage library corresponding to the various areas of mathematics. -- 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/99a02ddf-5f6a-4973-a15d-7ca927bfd12en%40googlegroups.com.
[sage-devel] Re: Master plan of sage modularization
On Thursday, November 18, 2021 at 11:47:37 AM UTC+9 Matthias Koeppe wrote: > That would be https://trac.sagemath.org/ticket/29705 Yes, all the information could be found in the ticket description and the descriptions of the subtickets. But the master plan is buried in the details. I want to see how the whole sage library would be split into what distributions at the end of the modularization effort, and how the distributions depend on another if any. Help with documenting the principles and goals of modularization in the > developer's guide is definitely very welcome! > I think no one can do this but the conductor orchestrating the modularization process. -- 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/84122d13-92a8-41e9-abeb-76ab6e209ec5n%40googlegroups.com.
[sage-devel] Re: Master plan of sage modularization
That would be https://trac.sagemath.org/ticket/29705 Help with documenting the principles and goals of modularization in the developer's guide is definitely very welcome! On Wednesday, November 17, 2021 at 6:27:56 PM UTC-8 Kwankyu Lee wrote: > Hi, > > Sage modularization is going on, and I see in trac many tickets toward the > goal. But I wonder what is the master plan. I mean the plan how sage > library would be split. Here and there I read that some packages in the > sage library will be namespace packages, and others won't be. It would be > nice to have the master plan at one place. Perhaps this information needs > to be included in the developer manual. If there is a plan laid out, where > is it? > > Thanks for attention. > > -- 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/0c8d550f-bb5a-4ae5-aa24-37944548738an%40googlegroups.com.
[sage-devel] Master plan of sage modularization
Hi, Sage modularization is going on, and I see in trac many tickets toward the goal. But I wonder what is the master plan. I mean the plan how sage library would be split. Here and there I read that some packages in the sage library will be namespace packages, and others won't be. It would be nice to have the master plan at one place. Perhaps this information needs to be included in the developer manual. If there is a plan laid out, where is it? Thanks for attention. -- 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/0490d0f9-4d23-4eb5-af0c-95129e30175bn%40googlegroups.com.
[sage-devel] Flint 2.8.4 Released
Hi all, I just tagged Flint-2.8.4. This is a critical bug fix release and so we strongly recommend upgrading. * Fix a serious bug in fmpz_mod_poly_xgcd for polynomials of large length * Fix an assertion failure in fmpz_mat_solve_fflu (only relevant if asserts enabled) * Fix some bugs on 32 bit machines * Work around a compiler bug on Apple M1 * Fix bug in nmod_mpoly_factor (returned 0 for some factorisations) * Fix some documentation build errors and some doc formatting issues Please note that the C++ wrapper is now considered unmaintained. We will keep it compiling in its current state, but will not be wrapping additional flint functions. If any C++ developers would like to take over maintenance, we estimate it would be about 3-4 months of effort full time to wrap the remaining flint functions in C++ for a VERY experienced C++ developer. Replacing the old metaprogramming wrapper with a new one using more modern C++ features would be about 4-6 months full time work for an experienced C++ developer. If you would like to volunteer, but not be paid for your effort, please let us know [1]. Bill. [1] Application forms are available at Flint Headquarters, Abandoned House, Pfälzerwald. -- 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/CAB0xFnuZxOvO5EYwF03MeK4q-gTs91rb-VPEKxqwjpeUc%2BAknw%40mail.gmail.com.
