On Tuesday, April 23, 2024 at 8:58:58 PM UTC-5 Dima Pasechnik wrot
It's not quite correct to say that a C, or other, compiler is not required
to run Sage. Sage allows you to define, build, load, and run Cython
extensions without leaving Sage, thus, it needs to call a compiler after
That was it!
Thank you Gonzalo; indeed, it helps a lot. And your workaround is fine,
since we don't support the -i option, Even if we did, the default names
for as, ld and ar are correct whenever the command line tools are
installed. So that block of code is completely irrelevant for the
https://github.com/sagemath/sage/blob/develop/src/bin/sage-env#L482 and L494
See: https://github.com/sagemath/sage/issues/14296 and
https://github.com/sagemath/sage/commit/69213d74ead4e93687cf61f214b0d96dd3f9885a
Maybe you can workaround this by setting AS=as and LD=ld in sage-env-config.
HTH,
On 23 April 2024 19:48:18 BST, Marc Culler wrote:
>I discovered, by installing the Sage_macOS app on a pristine macOS system,
>that somehow, somewhere, in Sage's startup sequence there is a call to
>gcc. This is true whether Sage is being started from a command line or a
>notebook.
>
>On
On 23 April 2024 19:13:44 BST, Matthias Koeppe wrote:
>On Tuesday, April 23, 2024 at 11:06:12 AM UTC-7 Dima Pasechnik wrote:
>
>
>
>On 23 April 2024 18:41:34 BST, Matthias Koeppe
>wrote:
>>*$ git blame src/sage/combinat//designs/block_design.py*
>>
>>fdbe7f7e3348 (Matthias Koeppe
On Tuesday, April 23, 2024 at 11:06:12 AM UTC-7 Dima Pasechnik wrote:
On 23 April 2024 18:41:34 BST, Matthias Koeppe
wrote:
>*$ git blame src/sage/combinat//designs/block_design.py*
>
>fdbe7f7e3348 (Matthias Koeppe 2023-07-12 10:53:08 -0700 65)
>lazy_import('sage.libs.gap.libgap',
I discovered, by installing the Sage_macOS app on a pristine macOS system,
that somehow, somewhere, in Sage's startup sequence there is a call to
gcc. This is true whether Sage is being started from a command line or a
notebook.
On such a macOS system /usr/bin/gcc exists, but calling it
On 23 April 2024 18:41:34 BST, Matthias Koeppe wrote:
>On Tuesday, April 23, 2024 at 10:32:22 AM UTC-7 Dima Pasechnik wrote:
>
>in
>src/sage/combinat//designs/block_design.py
>
>you can see
>
>lazy_import('sage.libs.gap.libgap', 'libgap')
On Tuesday, April 23, 2024 at 10:32:22 AM UTC-7 Dima Pasechnik wrote:
in
src/sage/combinat//designs/block_design.py
you can see
lazy_import('sage.libs.gap.libgap', 'libgap')
lazy_import('sage.rings.finite_rings.finite_field_constructor',
'FiniteField')
*$ git blame
On Tuesday, April 23, 2024 at 8:38:13 AM UTC-7 Martin R wrote:
If I understand correctly, the current proposal does not mind if some
things don't work or could be replaced without too much effort. For
example, Dima might have referred to the fact that
OrderedPartitions.cardinality uses gap,
On Monday, April 22, 2024 at 2:22:36 AM UTC-7 Martin R wrote:
I still don't see why you would name these distributions as you do, and why
you collect them as you do.
Above I explained, "I introduce these packages to create *discoverability* for
potential consumers of portions of the Sage
On Tue, Apr 23, 2024 at 3:31 PM Matthias Koeppe
wrote:
>
> On Tuesday, April 23, 2024 at 6:14:05 AM UTC-7 Dima Pasechnik wrote:
>
> On Sun, Apr 21, 2024 at 10:42 PM Matthias Koeppe wrote:
>
> Let's just go through the list of distribution packages and their
> dependencies for concreteness. (All
On Tuesday, April 23, 2024 at 5:35:10 AM UTC-7 Kwankyu Lee wrote:
I meant the sage library as a collection of mathematical modules. If a
certain module did not but somehow would develop to rely on the
mathematical functionality of another module, then the design of the
modularization should
> *Just go with how github works, which is positive review = ready to merge
and "files changed" shows the actual changes that this PR implements.*
The problem with this is: if there are commits on a branch that are
reviewed in more than one PR, the question is: does *positive review* mean
If I understand correctly, the current proposal does not mind if some
things don't work or could be replaced without too much effort. For
example, Dima might have referred to the fact that
OrderedPartitions.cardinality uses gap, even though it is in
sagemath-combinat.
The gap dependency in
On Tuesday, April 23, 2024 at 6:14:05 AM UTC-7 Dima Pasechnik wrote:
On Sun, Apr 21, 2024 at 10:42 PM Matthias Koeppe
wrote:
Let's just go through the list of distribution packages and their
dependencies for concreteness. (All depend on *sagemath-categories* and
thus on the basic arithmetic
On Tuesday, April 23, 2024 at 4:07:37 AM UTC-5 Tobias wrote:
In reply to the comment (
https://github.com/sagemath/sage/pull/36676#issuecomment-2067371677)
once the modularization is in place, it will impose wide-ranging
constraints on what functions from other modules you are able to use.
The vote was 8-4. I'm setting the PR back to positive review.
David
On Sat, Apr 20, 2024 at 5:04 AM Volker Braun wrote:
> It was merged because it was positively reviewed.
>
> Neither I nor the merge script reads every ticket description and looks
> through the text whether any dependency is
On Sun, Apr 21, 2024 at 10:42 PM Matthias Koeppe
wrote:
> On Sunday, April 21, 2024 at 2:30:15 AM UTC-7 Martin R wrote:
>
> Why would you separate mathematics into packages that have no more
> external dependencies from others, which at the same time may grow internal
> dependencies over time?
>
>> My fear would be that at some point there is a request not to use
symbolics in some module, because Lisp is hard to install on some system.
>That should not happen. Modularization is downstream to the sage library.
Yes, we are restructuring some parts of the sage library to fit with
In reply to the comment
(https://github.com/sagemath/sage/pull/36676#issuecomment-2067371677)
>> My fear would be that at some point there is a request not to use
symbolics in some module, because Lisp is hard to install on some system.
>That should not happen. Modularization is downstream to
21 matches
Mail list logo
