Dear Matthias!
You mentioned several times, that discoverability is an important aspect.
Do you have any evidence to support that?
Wouldn't people in the python world who need a serious amount of math know
of sage anyway, and then, if they cannot rely on all of sage because that
is too large,
On Tuesday, April 23, 2024 at 11:17:49 PM UTC-5 Marc Culler wrote:
I wonder if the Sage community would be willing to reconsider the idea of
having one entry point for every function provided by SageMath,
I won't speak for the community, but I reconsidered this and I decided that
it would be
On Wed, Apr 24, 2024 at 4:45 AM Marc Culler wrote:
>
> That was it!
>
> Thank you Gonzalo; indeed, it helps a lot. And your workaround is fine,
> since we don't support the -i option,
running Cython in sage prompt or in Sage Jupyter notebook has nothing
to do with -i option. One can call cython
Wouldn't people in the python world who need a serious amount of math know
of sage anyway, and then, if they cannot rely on all of sage because that
is too large, use, for example, `citation.get_systems` to see whether they
can do without some dependencies?
I think they would do `pip instal
On Wednesday, April 24, 2024 at 8:05:15 AM UTC-5 Dima Pasechnik wrote:
running Cython in sage prompt or in Sage Jupyter notebook has nothing
to do with -i option.
I realize that. But it looked to me like those variables are being set in
the sage-env script *primarily* to support sage -i. Per
On Tue, 23 Apr 2024 at 15:27, Marc Culler wrote:
>
> The projects that will really benefit from modularization will be those that
> provide their own limited mathematical context. Developers of such projects
> will be able to choose which parts of Sage are relevant to their specific
> context.
On Wed, Apr 24, 2024 at 2:08 PM Kwankyu Lee wrote:
>
> Wouldn't people in the python world who need a serious amount of math know of
> sage anyway, and then, if they cannot rely on all of sage because that is too
> large, use, for example, `citation.get_systems` to see whether they can do
> wit
I think that CyPari ;and CyPari2 provide a relevant example.
Some background ... CyPari is a PyPi package with binary wheels which
predates and was the starting point for Sage's cypari2 (hence the 2 in the
name). The basis for CyPari was Sage's pari module. That module was
modified to make it i
On Wed, Apr 24, 2024 at 3:37 PM Marc Culler wrote:
>
> I think that CyPari ;and CyPari2 provide a relevant example.
>
> Some background ... CyPari is a PyPi package with binary wheels which
> predates and was the starting point for Sage's cypari2 (hence the 2 in the
> name). The basis for CyPa
On Wed, Apr 24, 2024 at 2:11 PM Marc Culler wrote:
>
> On Wednesday, April 24, 2024 at 8:05:15 AM UTC-5 Dima Pasechnik wrote:
>
> running Cython in sage prompt or in Sage Jupyter notebook has nothing
> to do with -i option.
>
>
> I realize that. But it looked to me like those variables are being
On Wed, 24 Apr 2024 at 15:37, Marc Culler wrote:
>
> I think that CyPari ;and CyPari2 provide a relevant example.
>
> Some background ... CyPari is a PyPi package with binary wheels which
> predates and was the starting point for Sage's cypari2 (hence the 2 in the
> name). The basis for CyPari
On Wed, Apr 24, 2024 at 2:26 PM Oscar Benjamin
wrote:
> 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.
>
That hypothetical person could also use CyPari2 if they didn't care about
memory leaks and
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
On Wed, Apr 24, 2024 at 9:29 PM Nathan Dunfield wrote:
>
> 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 hypothetic
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:
Well, it almost solved the problem.
It turns out that calling /usr/bin/gcc was not the only issue in sage-env.
That script also calls xcode-select. On a system with no XCode app and no
command line tools, calling gcc causes an error message to be printed to
stderr and a dialog to open asking
On Wednesday, April 24, 2024 at 1:07:44 AM UTC-7 Martin R wrote:
You mentioned several times, that discoverability is an important aspect.
Do you have any evidence to support that?
I mentioned "discoverability" in the context of how I have *named* the
distributions.
Wouldn't people in the
On Wednesday, April 24, 2024 at 6:48:30 AM UTC-7 Oscar Benjamin wrote:
Is the benefit in this case mainly about reduced disk/network usage?
I could imagine other theoretical benefits like maybe some parts could
be installed natively on Windows or some parts might be easier to
provide binaries
On Wednesday, April 24, 2024 at 6:11:23 AM UTC-7 Marc Culler wrote:
But it looked to me like those variables are being set in the sage-env
script *primarily* to support sage -i. Perhaps you are right that it is
*primarily* to support compiling cython, but it doesn't look like it to
me. In an
On Wednesday, April 24, 2024 at 8:19:03 AM UTC-7 Dima Pasechnik wrote:
sage -i actually calls make,
This part is true.
on a makefile where everything is already
set up. So no, it's not for sage -i.
This part is false.
Our makefiles (https://github.com/sagemath/sage/blame/develop/Makefile,
20 matches
Mail list logo
