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,
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
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 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
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 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
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
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 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 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
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, 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
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
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
>
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
>
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.
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
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
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
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
20 matches
Mail list logo
