Re: [sage-devel] Re: Question: why does /usr/bin/gcc get called during Sage startup?

[Marc Culler]

This looks pretty complicated.

I used XCode 15.0.1 to build the macOS SageMath-10-3 app for Arm and XCode 
13.4 for Intel.  I got "duplicate rpaths" and "duplicate libraries" 
warnings with 15.0.1 but not with 13.4. I pasted typical gcc commands (from 
cvxopt) below.  You can see that:
(1) Both commands contain duplicate rpath specifications but XCode 13.4 
does not warn about them
(2) duplicate libraries and invalid library search paths only occur with 
XCode 15.01.
(3) With 15.0.1 the gcc command does not include the linker option 
-ld_classic, so the code in sage-env is not actually succeeding in using 
the  old linker.  (But the build works anyway.)

It is not clear to me that Sage is responsible for the duplicates, since it 
seems to depend on the XCode version, and it is not clear to me that the 
code in sage-env that aims to use the old linker has any effect, on spkgs 
anyway.
 
- Marc

XCode 15.0.1 on Arm:
---
gcc -bundle -undefined dynamic_lookup 
-L/private/var/tmp/sage-10.3-current/local/lib 
-Wl,-rpath,/private/var/tmp/sage-10.3-current/local/lib 
-L/private/var/tmp/sage-10.3-current/local/lib 
-Wl,-rpath,/private/var/tmp/sage-10.3-current/local/lib 
-Wl,-platform_version,macos,11.0,11.1 
-L/Library/Developer/CommandLineTools/SDKs/macOSX.sdk/usr/lib 
-Wl,-rpath,/private/var/tmp/sage-10.3-current/local/var/lib/sage/venv-python3.11.1/lib
 
-L. -Wl,-rpath,. -L/private/var/tmp/sage-10.3-current/local/lib 
-L/private/var/tmp/sage-10.3-current/local/lib 
-Wl,-rpath,/private/var/tmp/sage-10.3-current/local/lib 
-L/private/var/tmp/sage-10.3-current/local/lib 
-Wl,-rpath,/private/var/tmp/sage-10.3-current/local/lib 
-Wl,-platform_version,macos,11.0,11.1 
-L/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib 
-L/private/var/tmp/sage-10.3-current/local/lib 
-Wl,-rpath,/private/var/tmp/sage-10.3-current/local/lib 
-L/private/var/tmp/sage-10.3-current/local/lib 
-Wl,-rpath,/private/var/tmp/sage-10.3-current/local/lib 
-Wl,-platform_version,macos,11.0,11.1 
-L/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib -O2 
-mmacosx-version-min=11.0 
build/temp.macosx-11.0-arm64-cpython-311/src/C/base.o 
build/temp.macosx-11.0-arm64-cpython-311/src/C/dense.o 
build/temp.macosx-11.0-arm64-cpython-311/src/C/sparse.o 
-L/private/var/tmp/sage-10.3-current/local/lib 
-L/private/var/tmp/sage-10.3-current/local/var/lib/sage/venv-python3.11.1/lib 
-lm -lopenblas -lopenblas -o 
build/lib.macosx-11.0-arm64-cpython-311/cvxopt/base.cpython-311-darwin.so
  ld: warning: duplicate -rpath 
'/private/var/tmp/sage-10.3-current/local/lib' ignored
  ld: warning: duplicate -rpath 
'/private/var/tmp/sage-10.3-current/local/lib' ignored
  ld: warning: duplicate -rpath 
'/private/var/tmp/sage-10.3-current/local/lib' ignored
  ld: warning: duplicate -rpath 
'/private/var/tmp/sage-10.3-current/local/lib' ignored
  ld: warning: duplicate -rpath 
'/private/var/tmp/sage-10.3-current/local/lib' ignored
  ld: warning: ignoring duplicate libraries: '-lopenblas'
  ld: warning: search path 
'/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib' not found
  ld: warning: search path 
'/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib' not found
  ld: warning: search path 
'/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib' not found
  ld: warning: duplicate LC_RPATH are deprecated 
('/private/var/tmp/sage-10.3-current/local/lib')

XCode 13.4 on Intel:

gcc -bundle -undefined dynamic_lookup 
-L/private/var/tmp/sage-10.3-current/local/lib 
-Wl,-rpath,/private/var/tmp/sage-10.3-current/local/lib 
-L/private/var/tmp/sage-10.3-current/local/lib 
-Wl,-rpath,/private/var/tmp/sage-10.3-current/local/lib 
-Wl,-platform_version,macos,10.9,11.3 
-Wl,-rpath,/private/var/tmp/sage-10.3-current/local/var/lib/sage/venv-python3.11.1/lib
 
-L. -Wl,-rpath,. -L/private/var/tmp/sage-10.3-current/local/lib 
-L/private/var/tmp/sage-10.3-current/local/lib 
-Wl,-rpath,/private/var/tmp/sage-10.3-current/local/lib 
-L/private/var/tmp/sage-10.3-current/local/lib 
-Wl,-rpath,/private/var/tmp/sage-10.3-current/local/lib 
-Wl,-platform_version,macos,10.9,11.3 
-L/private/var/tmp/sage-10.3-current/local/lib 
-Wl,-rpath,/private/var/tmp/sage-10.3-current/local/lib 
-L/private/var/tmp/sage-10.3-current/local/lib 
-Wl,-rpath,/private/var/tmp/sage-10.3-current/local/lib 
-Wl,-platform_version,macos,10.9,11.3 -O2 -mmacosx-version-min=10.9 
-mno-avx -mno-avx2 -mno-bmi2 
build/temp.macosx-10.9-x86_64-cpython-311/src/C/base.o 
build/temp.macosx-10.9-x86_64-cpython-311/src/C/dense.o 
build/temp.macosx-10.9-x86_64-cpython-311/src/C/sparse.o 
-L/private/var/tmp/sage-10.3-current/local/lib 
-L/private/var/tmp/sage-10.3-current/local/var/lib/sage/venv-python3.11.1/lib 
-lm -lopenblas -lopenblas -o 
build/lib.macosx-10.9-x86_64-cpython-311/cvxopt/base.cpython-311-darwin.so
  ld: warning: passed two min versions (10.9, 10.9) for platform macOS. 
Using 10.9.
  ld: warning: passed two min 

Re: [sage-devel] Re: Urgent and important: Please vote on disputed PR #36964 (next step of the modularization project)

[TB]

  
  
On 25/04/2024 15:28, Nathan Dunfield
  wrote:


  
  
  

  In another direction: I have started a port of Sage to
pyodide, the distribution of Python for WebAssembly (WASM),
which makes Python runnable directly in the browser. I can
already run and test the modularized distributions
**sagemath-objects**, **sagemath-categories** there.



It would be amazing if a decent portion of Sage could be
  run in the browser this way, e.g. to have the occasional HW
  assignment that needs Sage without the overhead of using
  something like CoCalc. 
  

Although SageMathCell
  does not run locally, it does run in the browser. There are
  examples of Sage exercises in this book and
  more on the about
page of SageMathCell. Having a completely offline version of
  parts of Sage that can run in the browser with WASM will be
  wonderful indeed.



Regards,
TB

  




-- 
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/c1ec2bb3-67fb-4e4a-978d-61531acce0d9%40gmail.com.

Re: [sage-devel] VOTE: Revert merged PR with unreviewed dependencies

[Volker Braun]

On Tuesday, April 23, 2024 at 6:24:51 PM UTC+2 seb@gmail.com wrote:

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 
*all* or *some* PR's?


The review is for a single PR, not for individual commits.

The positively reviewed PR gets merged, and then you may or may not want to 
rebase other PRs on the new develop branch. If you do, then the changes 
that were merged disappear from the "files changed" tab of that other PR on 
github. Either way, the commits from the positively reviewed PR are added 
to the sage codebase.

-- 
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/e5dd55d8-b716-483a-9414-546cdcc530fdn%40googlegroups.com.

Re: [sage-devel] Re: Question: why does /usr/bin/gcc get called during Sage startup?

[Marc Culler]

Thanks.

The xcode-select command always exists.
What works is to run the command with stderr redirected to /dev/null and 
then check $?.
I will open a PR.

- Marc
On Thursday, April 25, 2024 at 4:05:34 PM UTC-5 John H Palmieri wrote:

> I also don't know when the linker was fixed and whether we need to support 
> systems on which it is still broken. Anyway, if you want to open up a PR to 
> avoid the call to xcode-select, I'd be happy to take a look. We could also 
> revive some version of the branch at #36337 to filter out the warnings when 
> doctesting.
>
> -- 
> John
>
> On Thursday, April 25, 2024 at 1:19:50 PM UTC-7 John H Palmieri wrote:
>
>> Take a look at the discussion at 
>> https://github.com/sagemath/sage/pull/36337, in particular 
>> https://github.com/sagemath/sage/pull/36337#issuecomment-1741293729. I 
>> saw both "duplicate rpath" warnings and "duplicate library" warnings. Some 
>> (maybe all, at least at that point) of the duplicate rpaths were removed by 
>> https://github.com/sagemath/sage/pull/36364, but I don't know how to 
>> prevent the duplicate libary warnings.
>>
>> -- 
>> John
>>
>>
>> On Thursday, April 25, 2024 at 1:07:17 PM UTC-7 marc@gmail.com wrote:
>>
>>> Hi John,
>>>
>>> I have noticed that .dylib files generated by Sage often have as many as 
>>> 3 identical rpaths.  (When building the macOS app I remove all rpaths and 
>>> replace them with a single rpath which is relative, meaning it starts with 
>>> @loader_path.  Apple will not notarize app bundles with absolute rpaths.)
>>>
>>> I wonder if the "duplicate libraries" warnings are caused by duplicate 
>>> rpath entries in the mach files.  I will try to test that hypothesis.
>>>
>>> Do you have any idea what could cause those duplicate rpaths?  Are there 
>>> multiple -rpath options being passed to the compiler?
>>>
>>> - Marc
>>>
>>> On Thu, Apr 25, 2024 at 2:50 PM John H Palmieri  
>>> wrote:
>>>
 Hi Marc,

 I just tried building Sage without `-ld-classic`. It builds, but I get 
 warnings about "ignoring duplicate libraries", and those cause doctest 
 failures. The lines could be modified to test whether xcode-select is 
 present and executable first, or since Sage now does indeed build without 
 `-ld-classic`, we could filter out the warnings when doctesting.

 -- 
 John


 On Wednesday, April 24, 2024 at 3:20:54 PM UTC-7 marc@gmail.com 
 wrote:

> 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 whether to install the 
> command line tools.  Calling xcode-select on such a system prints the 
> same 
> error message but does not open the dialog. The error message appears in 
> the terminal when running sage in a command line, which is annoying 
> and/or 
> alarming to someone with no plans to do anything involving compilation of 
> C 
> code.
>
> The calls to xcode-select were added in PR#36599 
>  in order to force XCode 
> to use Apple's ld-classic linker instead of ld when their new version of 
> ld 
> was totally broken.  This is done by adding -ld_classic to LDFLAGS.
>
> *Note to people who worked on PR #36599* (@jhpalmieri and @mkoeppe): 
> I think Apple's new linker is working now, so it is probably no longer 
> necessary and not a good idea to force use of ld_classic.
>
> - Marc
>
> On Tuesday, April 23, 2024 at 10:45:54 PM UTC-5 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,  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 macOS 
> platform.  This solves the problem.
>
> - Marc
>
>
>
> On Tuesday, April 23, 2024 at 8:59:12 PM UTC-5 Gonzalo Tornaría wrote:
>
> 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,
> Gonzalo
>
>
> On Tuesday, April 23, 2024 at 3:48:18 PM UTC-3 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 

Re: [sage-devel] Re: Question: why does /usr/bin/gcc get called during Sage startup?

[John H Palmieri]

I also don't know when the linker was fixed and whether we need to support 
systems on which it is still broken. Anyway, if you want to open up a PR to 
avoid the call to xcode-select, I'd be happy to take a look. We could also 
revive some version of the branch at #36337 to filter out the warnings when 
doctesting.

-- 
John

On Thursday, April 25, 2024 at 1:19:50 PM UTC-7 John H Palmieri wrote:

> Take a look at the discussion at 
> https://github.com/sagemath/sage/pull/36337, in particular 
> https://github.com/sagemath/sage/pull/36337#issuecomment-1741293729. I 
> saw both "duplicate rpath" warnings and "duplicate library" warnings. Some 
> (maybe all, at least at that point) of the duplicate rpaths were removed by 
> https://github.com/sagemath/sage/pull/36364, but I don't know how to 
> prevent the duplicate libary warnings.
>
> -- 
> John
>
>
> On Thursday, April 25, 2024 at 1:07:17 PM UTC-7 marc@gmail.com wrote:
>
>> Hi John,
>>
>> I have noticed that .dylib files generated by Sage often have as many as 
>> 3 identical rpaths.  (When building the macOS app I remove all rpaths and 
>> replace them with a single rpath which is relative, meaning it starts with 
>> @loader_path.  Apple will not notarize app bundles with absolute rpaths.)
>>
>> I wonder if the "duplicate libraries" warnings are caused by duplicate 
>> rpath entries in the mach files.  I will try to test that hypothesis.
>>
>> Do you have any idea what could cause those duplicate rpaths?  Are there 
>> multiple -rpath options being passed to the compiler?
>>
>> - Marc
>>
>> On Thu, Apr 25, 2024 at 2:50 PM John H Palmieri  
>> wrote:
>>
>>> Hi Marc,
>>>
>>> I just tried building Sage without `-ld-classic`. It builds, but I get 
>>> warnings about "ignoring duplicate libraries", and those cause doctest 
>>> failures. The lines could be modified to test whether xcode-select is 
>>> present and executable first, or since Sage now does indeed build without 
>>> `-ld-classic`, we could filter out the warnings when doctesting.
>>>
>>> -- 
>>> John
>>>
>>>
>>> On Wednesday, April 24, 2024 at 3:20:54 PM UTC-7 marc@gmail.com 
>>> wrote:
>>>
 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 whether to install the 
 command line tools.  Calling xcode-select on such a system prints the same 
 error message but does not open the dialog. The error message appears in 
 the terminal when running sage in a command line, which is annoying and/or 
 alarming to someone with no plans to do anything involving compilation of 
 C 
 code.

 The calls to xcode-select were added in PR#36599 
  in order to force XCode 
 to use Apple's ld-classic linker instead of ld when their new version of 
 ld 
 was totally broken.  This is done by adding -ld_classic to LDFLAGS.

 *Note to people who worked on PR #36599* (@jhpalmieri and @mkoeppe): I 
 think Apple's new linker is working now, so it is probably no longer 
 necessary and not a good idea to force use of ld_classic.

 - Marc

 On Tuesday, April 23, 2024 at 10:45:54 PM UTC-5 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,  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 macOS 
 platform.  This solves the problem.

 - Marc



 On Tuesday, April 23, 2024 at 8:59:12 PM UTC-5 Gonzalo Tornaría wrote:

 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,
 Gonzalo


 On Tuesday, April 23, 2024 at 3:48:18 PM UTC-3 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 such a macOS system /usr/bin/gcc exists, but calling it causes a 
 dialog to be posted which asks whether to download and install the Xcode 
 "command line tools".

 There is no need for a user to install, or be prompted to install, a C 
 compiler in order to run Sage.  If we want to verify whether a C compiler 
 

Re: [sage-devel] Re: Question: why does /usr/bin/gcc get called during Sage startup?

[John H Palmieri]

Take a look at the discussion at 
https://github.com/sagemath/sage/pull/36337, in particular 
https://github.com/sagemath/sage/pull/36337#issuecomment-1741293729. I saw 
both "duplicate rpath" warnings and "duplicate library" warnings. Some 
(maybe all, at least at that point) of the duplicate rpaths were removed by 
https://github.com/sagemath/sage/pull/36364, but I don't know how to 
prevent the duplicate libary warnings.

-- 
John


On Thursday, April 25, 2024 at 1:07:17 PM UTC-7 marc@gmail.com wrote:

> Hi John,
>
> I have noticed that .dylib files generated by Sage often have as many as 3 
> identical rpaths.  (When building the macOS app I remove all rpaths and 
> replace them with a single rpath which is relative, meaning it starts with 
> @loader_path.  Apple will not notarize app bundles with absolute rpaths.)
>
> I wonder if the "duplicate libraries" warnings are caused by duplicate 
> rpath entries in the mach files.  I will try to test that hypothesis.
>
> Do you have any idea what could cause those duplicate rpaths?  Are there 
> multiple -rpath options being passed to the compiler?
>
> - Marc
>
> On Thu, Apr 25, 2024 at 2:50 PM John H Palmieri  
> wrote:
>
>> Hi Marc,
>>
>> I just tried building Sage without `-ld-classic`. It builds, but I get 
>> warnings about "ignoring duplicate libraries", and those cause doctest 
>> failures. The lines could be modified to test whether xcode-select is 
>> present and executable first, or since Sage now does indeed build without 
>> `-ld-classic`, we could filter out the warnings when doctesting.
>>
>> -- 
>> John
>>
>>
>> On Wednesday, April 24, 2024 at 3:20:54 PM UTC-7 marc@gmail.com 
>> wrote:
>>
>>> 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 whether to install the 
>>> command line tools.  Calling xcode-select on such a system prints the same 
>>> error message but does not open the dialog. The error message appears in 
>>> the terminal when running sage in a command line, which is annoying and/or 
>>> alarming to someone with no plans to do anything involving compilation of C 
>>> code.
>>>
>>> The calls to xcode-select were added in PR#36599 
>>>  in order to force XCode 
>>> to use Apple's ld-classic linker instead of ld when their new version of ld 
>>> was totally broken.  This is done by adding -ld_classic to LDFLAGS.
>>>
>>> *Note to people who worked on PR #36599* (@jhpalmieri and @mkoeppe): I 
>>> think Apple's new linker is working now, so it is probably no longer 
>>> necessary and not a good idea to force use of ld_classic.
>>>
>>> - Marc
>>>
>>> On Tuesday, April 23, 2024 at 10:45:54 PM UTC-5 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,  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 macOS 
>>> platform.  This solves the problem.
>>>
>>> - Marc
>>>
>>>
>>>
>>> On Tuesday, April 23, 2024 at 8:59:12 PM UTC-5 Gonzalo Tornaría wrote:
>>>
>>> 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,
>>> Gonzalo
>>>
>>>
>>> On Tuesday, April 23, 2024 at 3:48:18 PM UTC-3 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 such a macOS system /usr/bin/gcc exists, but calling it causes a 
>>> dialog to be posted which asks whether to download and install the Xcode 
>>> "command line tools".
>>>
>>> There is no need for a user to install, or be prompted to install, a C 
>>> compiler in order to run Sage.  If we want to verify whether a C compiler 
>>> is installed on the host system then we should check the return value of 
>>> xcode-select 
>>> -p rather than calling /usr/bin/gcc.
>>>
>>> I am unable to find where this call occurs.  Do any of the Sage 
>>> developers know which component of Sage could be calling /usr/bin/gcc on 
>>> start up?
>>>
>>> - Marc
>>>
>>> -- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "sage-devel" group.
>> To unsubscribe from this topic, visit 
>> 

Re: [sage-devel] Re: Question: why does /usr/bin/gcc get called during Sage startup?

[Marc Culler]

Hi John,

I have noticed that .dylib files generated by Sage often have as many as 3
identical rpaths.  (When building the macOS app I remove all rpaths and
replace them with a single rpath which is relative, meaning it starts with
@loader_path.  Apple will not notarize app bundles with absolute rpaths.)

I wonder if the "duplicate libraries" warnings are caused by duplicate
rpath entries in the mach files.  I will try to test that hypothesis.

Do you have any idea what could cause those duplicate rpaths?  Are there
multiple -rpath options being passed to the compiler?

- Marc

On Thu, Apr 25, 2024 at 2:50 PM John H Palmieri 
wrote:

> Hi Marc,
>
> I just tried building Sage without `-ld-classic`. It builds, but I get
> warnings about "ignoring duplicate libraries", and those cause doctest
> failures. The lines could be modified to test whether xcode-select is
> present and executable first, or since Sage now does indeed build without
> `-ld-classic`, we could filter out the warnings when doctesting.
>
> --
> John
>
>
> On Wednesday, April 24, 2024 at 3:20:54 PM UTC-7 marc@gmail.com wrote:
>
>> 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 whether to install the
>> command line tools.  Calling xcode-select on such a system prints the same
>> error message but does not open the dialog. The error message appears in
>> the terminal when running sage in a command line, which is annoying and/or
>> alarming to someone with no plans to do anything involving compilation of C
>> code.
>>
>> The calls to xcode-select were added in PR#36599
>>  in order to force XCode to
>> use Apple's ld-classic linker instead of ld when their new version of ld
>> was totally broken.  This is done by adding -ld_classic to LDFLAGS.
>>
>> *Note to people who worked on PR #36599* (@jhpalmieri and @mkoeppe): I
>> think Apple's new linker is working now, so it is probably no longer
>> necessary and not a good idea to force use of ld_classic.
>>
>> - Marc
>>
>> On Tuesday, April 23, 2024 at 10:45:54 PM UTC-5 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,  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 macOS
>> platform.  This solves the problem.
>>
>> - Marc
>>
>>
>>
>> On Tuesday, April 23, 2024 at 8:59:12 PM UTC-5 Gonzalo Tornaría wrote:
>>
>> 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,
>> Gonzalo
>>
>>
>> On Tuesday, April 23, 2024 at 3:48:18 PM UTC-3 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 such a macOS system /usr/bin/gcc exists, but calling it causes a
>> dialog to be posted which asks whether to download and install the Xcode
>> "command line tools".
>>
>> There is no need for a user to install, or be prompted to install, a C
>> compiler in order to run Sage.  If we want to verify whether a C compiler
>> is installed on the host system then we should check the return value of 
>> xcode-select
>> -p rather than calling /usr/bin/gcc.
>>
>> I am unable to find where this call occurs.  Do any of the Sage
>> developers know which component of Sage could be calling /usr/bin/gcc on
>> start up?
>>
>> - Marc
>>
>> --
> You received this message because you are subscribed to a topic in the
> Google Groups "sage-devel" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/sage-devel/4s_5HmznHZM/unsubscribe.
> To unsubscribe from this group and all its topics, 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/c81c9434-3b0c-4730-b3e8-6e36802f5224n%40googlegroups.com
> 
> .
>

-- 
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 

[sage-devel] Re: Question: why does /usr/bin/gcc get called during Sage startup?

[John H Palmieri]

Hi Marc,

I just tried building Sage without `-ld-classic`. It builds, but I get 
warnings about "ignoring duplicate libraries", and those cause doctest 
failures. The lines could be modified to test whether xcode-select is 
present and executable first, or since Sage now does indeed build without 
`-ld-classic`, we could filter out the warnings when doctesting.

-- 
John


On Wednesday, April 24, 2024 at 3:20:54 PM UTC-7 marc@gmail.com wrote:

> 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 whether to install the 
> command line tools.  Calling xcode-select on such a system prints the same 
> error message but does not open the dialog. The error message appears in 
> the terminal when running sage in a command line, which is annoying and/or 
> alarming to someone with no plans to do anything involving compilation of C 
> code.
>
> The calls to xcode-select were added in PR#36599 
>  in order to force XCode to 
> use Apple's ld-classic linker instead of ld when their new version of ld 
> was totally broken.  This is done by adding -ld_classic to LDFLAGS.
>
> *Note to people who worked on PR #36599* (@jhpalmieri and @mkoeppe): I 
> think Apple's new linker is working now, so it is probably no longer 
> necessary and not a good idea to force use of ld_classic.
>
> - Marc
>
> On Tuesday, April 23, 2024 at 10:45:54 PM UTC-5 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,  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 macOS 
> platform.  This solves the problem.
>
> - Marc
>
>
>
> On Tuesday, April 23, 2024 at 8:59:12 PM UTC-5 Gonzalo Tornaría wrote:
>
> 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,
> Gonzalo
>
>
> On Tuesday, April 23, 2024 at 3:48:18 PM UTC-3 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 such a macOS system /usr/bin/gcc exists, but calling it causes a dialog 
> to be posted which asks whether to download and install the Xcode "command 
> line tools".
>
> There is no need for a user to install, or be prompted to install, a C 
> compiler in order to run Sage.  If we want to verify whether a C compiler 
> is installed on the host system then we should check the return value of 
> xcode-select 
> -p rather than calling /usr/bin/gcc.
>
> I am unable to find where this call occurs.  Do any of the Sage developers 
> know which component of Sage could be calling /usr/bin/gcc on start up?
>
> - Marc
>
>

-- 
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/c81c9434-3b0c-4730-b3e8-6e36802f5224n%40googlegroups.com.

Re: [sage-devel] Re: Urgent and important: Please vote on disputed PR #36964 (next step of the modularization project)

[dimpase]

On Thu, Apr 25, 2024 at 07:03:29AM -0700, Marc Culler wrote:
> On Thursday, April 25, 2024 at 8:28:48 AM UTC-5 Dima Pasechnik wrote:
> 
> Essential components of sagelib such as GAP, Singular, don't run on 
> native Windows 
> 
> 
> I was amused to find the following statement on the GAP forum 
>  from 2005:
> 
>   >  While porting GAP to use native Win32 calls is doable, basically 
> src/system.c is the only place
>> that needs lots of changes, it is certainly a nontrivial and 
> time-consuming task. (and one needs
>> to be a bit of an expert in programming to do this, IMHO)
> 
> The author was someone from the Netherlands by the name of *Dima 
> Pasechnik.  :^)*

It was me, yes. And I used to know from what end
you have to approach a Windows machine. :-)
But not to the point of knowing exactly how to change fork() and sbrk(),
(and mmap()) into whatever functions with 15 arguments you have to use
on Win32 as their replacements (they already have about 10 versions of
spawn to use in place of fork).

Note that since 2005 GAP has changed quite a bit, too.
They made a go at making it multithreaded (HPC GAP), and that made code
harder to deal with (HPC GAP is still beta).
Instead of GAP's native GC (with its sbrk/mmap), HPC GAP uses Boehm GC, which 
does run on native 
Windows. But it's a beta...

Oh, and someone died porting GAP to Windows, some years ago.

Dima


> 
> - Marc  
> 
> -- 
> 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/b0784b4b-ab38-4ff7-b5f7-d9cc47472b95n%40googlegroups.com.

-- 
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/Zip4cTYul-rCamCq%40hilbert.


signature.asc
Description: PGP signature

Re: [sage-devel] Re: Urgent and important: Please vote on disputed PR #36964 (next step of the modularization project)

[dimpase]

On Thu, Apr 25, 2024 at 08:09:48AM -0700, Marc Culler wrote:
> The GAP project provides a native Windows installer 
> .
>   
> So, evidently, it is possible to build GAP for Windows.  They do not seem 
> to provide build instructions for Windows, however.

it uses Cygwin, packaged in.

Dima

-- 
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/Zipz_z7DNoumVAiR%40hilbert.


signature.asc
Description: PGP signature

Re: [sage-devel] Re: Urgent and important: Please vote on disputed PR #36964 (next step of the modularization project)

[Marc Culler]

The GAP project provides a native Windows installer 
.
  
So, evidently, it is possible to build GAP for Windows.  They do not seem 
to provide build instructions for Windows, however.

- Marc
 
On Thursday, April 25, 2024 at 9:17:35 AM UTC-5 Marc Culler wrote:

> Another amusing quote, this time from the sbrk man page on macOS:
>
> > The brk and sbrk functions are historical curiosities left over from
>  > earlier days before the advent of virtual memory management.
>
> That seems to be a paraphrase of the FreeBSD man page, which says:
>
> > The brk() and sbrk() functions are legacy interfaces from before the 
> advent of modern virtual
> > memory management. They are deprecated and not present on the arm64 or 
> riscv architectures.
> > The mmap(2) interface should be used to allocate pages instead.
>
> Given that GAP runs on arm64, I suspect that it doesn't use sbrk in an 
> essential way anymore.  Of course fork is a different story.  But there are 
> surely lots of examples of programs that use fork which have been ported to 
> Windows.  I would guess that emacs is among them.  (It has been ported to 
> Windows - I assume it uses fork on posix systems).
>
> - Marc
> On Thursday, April 25, 2024 at 9:03:30 AM UTC-5 Marc Culler wrote:
>
>> On Thursday, April 25, 2024 at 8:28:48 AM UTC-5 Dima Pasechnik wrote:
>>
>> Essential components of sagelib such as GAP, Singular, don't run on 
>> native Windows 
>>
>>
>> I was amused to find the following statement on the GAP forum 
>>  from 2005:
>>
>>   >  While porting GAP to use native Win32 calls is doable, basically 
>> src/system.c is the only place
>>> that needs lots of changes, it is certainly a nontrivial and 
>> time-consuming task. (and one needs
>>> to be a bit of an expert in programming to do this, IMHO)
>>
>> The author was someone from the Netherlands by the name of *Dima 
>> Pasechnik.  :^)*
>>
>> - Marc  
>>
>

-- 
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/7e83fead-ed81-4536-9a64-0f7b1f391d72n%40googlegroups.com.

Re: [sage-devel] Re: Urgent and important: Please vote on disputed PR #36964 (next step of the modularization project)

[Marc Culler]

Another amusing quote, this time from the sbrk man page on macOS:

> The brk and sbrk functions are historical curiosities left over from
 > earlier days before the advent of virtual memory management.

That seems to be a paraphrase of the FreeBSD man page, which says:

> The brk() and sbrk() functions are legacy interfaces from before the 
advent of modern virtual
> memory management. They are deprecated and not present on the arm64 or 
riscv architectures.
> The mmap(2) interface should be used to allocate pages instead.

Given that GAP runs on arm64, I suspect that it doesn't use sbrk in an 
essential way anymore.  Of course fork is a different story.  But there are 
surely lots of examples of programs that use fork which have been ported to 
Windows.  I would guess that emacs is among them.  (It has been ported to 
Windows - I assume it uses fork on posix systems).

- Marc
On Thursday, April 25, 2024 at 9:03:30 AM UTC-5 Marc Culler wrote:

> On Thursday, April 25, 2024 at 8:28:48 AM UTC-5 Dima Pasechnik wrote:
>
> Essential components of sagelib such as GAP, Singular, don't run on 
> native Windows 
>
>
> I was amused to find the following statement on the GAP forum 
>  from 2005:
>
>   >  While porting GAP to use native Win32 calls is doable, basically 
> src/system.c is the only place
>> that needs lots of changes, it is certainly a nontrivial and 
> time-consuming task. (and one needs
>> to be a bit of an expert in programming to do this, IMHO)
>
> The author was someone from the Netherlands by the name of *Dima 
> Pasechnik.  :^)*
>
> - Marc  
>

-- 
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/0fad0dee-9a92-40f3-854a-412acca934e1n%40googlegroups.com.

Re: [sage-devel] Re: Urgent and important: Please vote on disputed PR #36964 (next step of the modularization project)

[Marc Culler]

On Thursday, April 25, 2024 at 8:28:48 AM UTC-5 Dima Pasechnik wrote:

Essential components of sagelib such as GAP, Singular, don't run on 
native Windows 


I was amused to find the following statement on the GAP forum 
 from 2005:

  >  While porting GAP to use native Win32 calls is doable, basically 
src/system.c is the only place
   > that needs lots of changes, it is certainly a nontrivial and 
time-consuming task. (and one needs
   > to be a bit of an expert in programming to do this, IMHO)

The author was someone from the Netherlands by the name of *Dima 
Pasechnik.  :^)*

- Marc  

-- 
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/b0784b4b-ab38-4ff7-b5f7-d9cc47472b95n%40googlegroups.com.

Re: [sage-devel] Re: Urgent and important: Please vote on disputed PR #36964 (next step of the modularization project)

[Dima Pasechnik]

On 25 April 2024 14:47:35 BST, Marc Culler  wrote:
>On Thu, Apr 25, 2024 at 8:28 AM Dima Pasechnik  wrote:
>
>> On Thu, Apr 25, 2024 at 1:28 PM Nathan Dunfield 
>> wrote:
>> >
>> > On Wednesday, April 24, 2024 at 10:14:09 PM UTC-5 Matthias Koeppe wrote:
>> >
>> > Yes, native Windows would clearly be a very important target.
>> >
>> >
>> > As a data point, downloads of our stand-alone SnapPy app, which is about
>> as high level pure math as it gets, are 60% higher for Windows than macOS.
>>
>> That's not for native Windows, that's for WSL, right?
>>
>
>Wrong!  SnapPy runs as a native Windows app.
>
>We build Pari with msys2 and mingw on a CI runner.
>
>Essential components of sagelib such as GAP, Singular, don't run on
>> native Windows (on Cygwin, yes, but
>> we know by now, Cygwin is too flaky for Sage to work) and I don't
>> think anyone is keen on
>> doing the hard work to port it.
>>
>
>Msys2 and mingw are not so flaky, and use more or less the same toolchain
>as Cygwin.  There are many ports of gnu libraries to msys2 which can be
>installed with their package manage (pacman).  I am not convinced that GAP,
>Singuler, etc. could not be built with mingw.

E.g. GAP uses sbrk, fork (which are not in msys2/mingw), you'll need to port 
their GC too.
Doable, but very, very far from easy.



>
>- Marc
>

-- 
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/E442AC03-90B9-4167-81F4-AB0E9E3C20AE%40gmail.com.

Re: [sage-devel] Re: Urgent and important: Please vote on disputed PR #36964 (next step of the modularization project)

[Marc Culler]

On Thu, Apr 25, 2024 at 8:28 AM Dima Pasechnik  wrote:

> On Thu, Apr 25, 2024 at 1:28 PM Nathan Dunfield 
> wrote:
> >
> > On Wednesday, April 24, 2024 at 10:14:09 PM UTC-5 Matthias Koeppe wrote:
> >
> > Yes, native Windows would clearly be a very important target.
> >
> >
> > As a data point, downloads of our stand-alone SnapPy app, which is about
> as high level pure math as it gets, are 60% higher for Windows than macOS.
>
> That's not for native Windows, that's for WSL, right?
>

Wrong!  SnapPy runs as a native Windows app.

We build Pari with msys2 and mingw on a CI runner.

Essential components of sagelib such as GAP, Singular, don't run on
> native Windows (on Cygwin, yes, but
> we know by now, Cygwin is too flaky for Sage to work) and I don't
> think anyone is keen on
> doing the hard work to port it.
>

Msys2 and mingw are not so flaky, and use more or less the same toolchain
as Cygwin.  There are many ports of gnu libraries to msys2 which can be
installed with their package manage (pacman).  I am not convinced that GAP,
Singuler, etc. could not be built with mingw.

- Marc

-- 
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/CALcZXRFLMGZN4Sd6A_VwXzPRnSg%3DRtsT5Am1gEsJtELS5ez9Vg%40mail.gmail.com.

Re: [sage-devel] Re: Urgent and important: Please vote on disputed PR #36964 (next step of the modularization project)

['Martin R' via sage-devel]

Another example is large-scale pure math computation on clusters.  Because 
of Sage's size and the nature of distributive file systems, the time to 
startup Sage can be 30 seconds or more, which complicates things if you 
want to do 100,000 calculations that are only 10 seconds each.


I agree that this an extremely important point.

Martin

-- 
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/f89899dc-db4b-4d24-b479-df375b12cba0n%40googlegroups.com.

Re: [sage-devel] Re: Urgent and important: Please vote on disputed PR #36964 (next step of the modularization project)

[Dima Pasechnik]

On Thu, Apr 25, 2024 at 1:28 PM Nathan Dunfield  wrote:
>
> On Wednesday, April 24, 2024 at 10:14:09 PM UTC-5 Matthias Koeppe wrote:
>
> Yes, native Windows would clearly be a very important target.
>
>
> As a data point, downloads of our stand-alone SnapPy app, which is about as 
> high level pure math as it gets, are 60% higher for Windows than macOS.

That's not for native Windows, that's for WSL, right?

Essential components of sagelib such as GAP, Singular, don't run on
native Windows (on Cygwin, yes, but
we know by now, Cygwin is too flaky for Sage to work) and I don't
think anyone is keen on
doing the hard work to port it.

This puts native  Windows  support into the area of wishful thinking.

 Dima

-- 
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/CAAWYfq3P-zGuoT%2B2x96oFBNeDCh%3DEzqmn9WgTGhPmH2akPp%3DcA%40mail.gmail.com.

Re: [sage-devel] Re: Urgent and important: Please vote on disputed PR #36964 (next step of the modularization project)

[Nathan Dunfield]

On Thursday, April 25, 2024 at 2:17:31 AM UTC-5 Martin R wrote:

I agree that my terminology is not good.  I tried to make a distinction 
between research involving math and the - to me unknown - rest.  I find it 
hard to imagine that any mathematician would bother installing anything 
else but all of sage. 


As mentioned upthread, CyPari is one of the few examples of something 
that's been modularized out of Sage.  While it's small compared to Sage, it 
can still do everything Pari can, which is a lot.   Marc and I broke out 
CyPari so we could use it in SnapPy (https://snappy.computop.org), whose 
users are, at a guess, 90% mathematicians, 9% physicists,  1% other.   The 
most recent version stand-alone (Sage-free) version of SnapPy has been 
downloaded 1,200 times on Windows and macOS.  That's a lot of 
mathematicians who are already installing only part of Sage.

Another example is large-scale pure math computation on clusters.  Because 
of Sage's size and the nature of distributive file systems, the time to 
startup Sage can be 30 seconds or more, which complicates things if you 
want to do 100,000 calculations that are only 10 seconds each.  I was 
recently at a workshop on computational topology, and several researchers 
there regarded using Sage in this context as a non-starter, in one case 
they were completely changing their approach to avoid using Sage. 

Best,

Nathan

-- 
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/c429af78-dd69-4ed5-94d4-0c0a45df8114n%40googlegroups.com.

Re: [sage-devel] Re: Urgent and important: Please vote on disputed PR #36964 (next step of the modularization project)

[Nathan Dunfield]

On Wednesday, April 24, 2024 at 10:14:09 PM UTC-5 Matthias Koeppe wrote:

Yes, native Windows would clearly be a very important target.


As a data point, downloads of our stand-alone SnapPy app, which is about as 
high level pure math as it gets, are 60% higher for Windows than macOS.
 

In another direction: I have started a port of Sage to pyodide, the 
distribution of Python for WebAssembly (WASM), which makes Python runnable 
directly in the browser. I can already run and test the modularized 
distributions **sagemath-objects**, **sagemath-categories** there.


It would be amazing if a decent portion of Sage could be run in the browser 
this way, e.g. to have the occasional HW assignment that needs Sage without 
the overhead of using something like CoCalc. 

Best,

Nathan
 

-- 
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/db5485fe-3da5-44bf-b063-7fa7274de17dn%40googlegroups.com.

Re: [sage-devel] Re: Urgent and important: Please vote on disputed PR #36964 (next step of the modularization project)

['Martin R' via sage-devel]

On Thursday 25 April 2024 at 05:13:37 UTC+2 Matthias Koeppe wrote:

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.


Sorry that my question was not clear enough.  Do you have evidence, that 
this naming enhances discoverability, and that this enhanced 
discoverability would be worthwhile, since it comes with a cost (as 
outlined above)?
 

Wouldn't people in the python world who need a serious amount of math know 
of sage anyway,


What is a "serious" amount of math?


You know it when you see it.  What I mean is, roughly, that it certainly 
does not make sense to use sage as a package if you need a few graph 
algorithms (like shortest paths or some such), because then you'd be better 
served with using a specialised library or perhaps copy the code and adapt 
it. You might want to use sage as a package, if you want to do serious 
enumeration of arbitrary combinatorial objects.  But then you will need 
gap, symmetrica, nauty and maxima or fricas 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?


What do you mean by, "whether they can do without some dependencies"?

 

That's exactly the point of the modularization: 
- To enable people to use parts of Sage without some [actually, most!] of 
the dependencies. 


The only point I am critical of is the splitting of the math library into 
arbitrary pseudo-mathematical parts (i.e., sage-combinat ... 
sage-symbolics, as listed above), which has nothing to do with dependencies.
 

[...] I admit, however, that I cannot really think of any serious use of 
any of the functionality of sage outside of math, where people would know 
that what they need is, say combinatorics or graph theory.


What do you mean by "outside of math"?


I agree that my terminology is not good.  I tried to make a distinction 
between research involving math and the - to me unknown - rest.  I find it 
hard to imagine that any mathematician would bother installing anything 
else but all of sage.  So, maybe I should have written: "I cannot think of 
 sage in an environment, where dependencies are show-stopper, ...".


  I guess it would be quite insane to install sage or parts of sage to get 
an implementation of a particular algorithm in a non-math environment.


Yes, "quite insane" would be a good description of doing this (reusing what 
is implemented in Sage) with the status quo, the monolithic Sage.

That's exactly the point. 
- From the viewpoint of users: It just makes no sense to use a small part 
of Sage: Because of space and time and friction (and limited portability).


However, it *does* make sense to copy small parts of sage.  If I need an 
implementation of some combinatorial algorithm, chances are extremely good 
that I can simply use ?? to go to the code, and copy the relevant part.
 

- From the viewpoint of contributors of new code that could be reused: It 
just makes no sense to trap it in Sage, where it cannot be reused sanely.

 
I doubt this.  Do you have any evidence for that?

Modularization makes it at least "less insane", or perhaps "kind of 
acceptable", or sometimes even "reasonable".
Any of these degrees of improvement of "sanity" would already be a win.


I disagree. "less insane" or "kind of acceptable" would be a loss, not a 
win, since the kind of modularization discussed in this message comes with 
a big cost.

Martin

-- 
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/9ac29423-78cd-40ca-9d33-6fc52c404b19n%40googlegroups.com.