[sage-release] Re: Sage 10.4.beta5 released

[John H Palmieri]

After running `make configure`, the git repository is not clean:

% git status 
On branch develop
Your branch is up to date with 'upstream/develop'.

Untracked files:
  (use "git add ..." to include in what will be committed)
pkgs/sagemath-categories/requirements-editable.txt
pkgs/sagemath-environment/requirements-editable.txt
pkgs/sagemath-objects/requirements-editable.txt
pkgs/sagemath-repl/requirements-editable.txt


On Thursday, May 2, 2024 at 4:08:14 PM UTC-7 Volker Braun wrote:

> As always, you can get the latest beta version from the "develop" git 
> branch. Alternatively, the self-contained source tarball is at 
> http://www.sagemath.org/download-latest.html
>
>
> 744939e037a (github/develop, tag: 10.4.beta5) Updated SageMath version to 
> 10.4.beta5
> e77b3df44ad gh-37915: Replace doctests from jacobian_khuri_makdisi.py 
> taking too long time
> 422c59e95ce gh-37911: Fix overflow in hypergeometric trace
> 67f26757bcb gh-37904: Change `SetSystem` representation
> a1354a74b91 gh-37883: gap: don't use deprecated LaTeX() and LaTeXObj()
> 53566be0ca2 gh-37882: eclib: fix doctests after 20240408 update
> 31cf6d3b0fa gh-37872: sage.{topology,homology}: Remove deprecated chomp 
> interface
> 75c86c8f28c gh-37870: `sage.ext`: Remove deprecated code
> c46302c3a6d gh-37868: `sage.misc.misc`: Remove deprecated code
> b14d3ec8dc3 gh-37856: `sage.misc.dist`: Remove; deprecated in #30207 (2022)
> 6753fbdecdc gh-37855: `sage.misc.package`: Remove deprecated code
> 9ce51d09089 gh-37853: Work around inconsistent iteration in 
> `multi_polynomial_sequence.py`
> 969b687c5f6 gh-37851: Fix issue 37587 regarding the Link class plot method
> 620babd49fb gh-37841: `.ci/write-dockerfile.sh`: Move here from build/bin/
> af6c2085804 gh-37836: fricas/do not get inputform twice
> ac9c1b07203 gh-37835: Optimize `DisjointSet`
> 6e58d87dcc1 gh-37833: `build/pkgs/{python3,setuptools}`: Update fedora 
> distro info
> 5ab5dc3c3fe gh-37829: src/sage/manifolds/differentiable: Docstring/doctest 
> edits
> db630cdf2d9 gh-37827: `sage.tensor`: Tiny doc fixes
> 7d0a347f99b gh-37826: FreeModuleAutomorphism: Add more invariants
> 698774f5289 gh-37825: `FiniteRankFreeModuleMorphism.display`: Show matrix 
> decorated with basis element names
> 3041aac4a21 gh-37823: Fix LaTeX output of FreeModuleTensor.display_comp
> 8296cec240f gh-37822: Fix bug in TensorField.apply_map
> 71d2a96e0d7 gh-37810: build/pkgs/gambit: Remove
> f87f3e3581e gh-37808: Removed non-working and utterly old @rename_keyword 
> in farey_symbol.pyx
> d64f1a8accb gh-37807: Added some documentation in the developer's guide 
> regarding deprecation
> 68e657c09c3 gh-37802: Add the downward monotonic cone to the cone catalogue
> abad24ff15f gh-37800: some cython-lint suggestions fixed in real rings
> 106c0d76be6 gh-37799: little details in quadratic_forms (pep8, ruff, etc)
> 2406c159c81 gh-37798: some ruff C4 fixes in combinat
> ac8792fc3d2 gh-37797: fix the category of quasi-modular form rings
> 1b5a3450555 gh-37793: add links to standard errors in various places
> ca3d59a8f09 gh-37792: remove a stray leftover in in sa2si_ZZmod()
> e9e3a3db928 gh-37750: CI Build: Fix "test modularized distributions" 
> after #37022
> 9097fa25d4b gh-37738: CI Build: Show segfaults using GitHub 
> annotations
> 46b7ec223c3 gh-37722: Remove `CombinatorialClass`
> 19b06ac7387 gh-37715: `sage.{calculus,functions,numerical,symbolic}`: 
> Docstring/doctest cosmetics, `# needs`
> e4e33257ab6 gh-37693: Implement the hypercenter and upper central series 
> for finite dimensional Lie algebras
> f0a28504d47 gh-37692: `matrix`, `Graph.incidence_matrix`, 
> `LinearMatroid.representation`: Support constructing 
> `Hom(CombinatorialFreeModule)` elements
> 9783f965806 gh-37681: Quaternion Ideal Pushforwards and Pullbacks
> 0a75254c9ea gh-37650: src/sage/features/sagemath.py: Add feature SAGE_SRC
> 721fc792a23 gh-37492: make sagelib work with singular>=4.3.2.p15 (future 
> 4.4)
> 2d77ac5ea3c gh-37277: pip 24, setuptools 69.5.1, hatchling 1.22.5, 
> hatch_fancy_pypi_readme 24.1.0, platformdirs 4.2.0, packaging 24.0, 
> trove_classifiers 2024.4.10, wheel 0.43.0
> 248fde327ef gh-37099: GH Actions: Build platform-independent wheels of 
> sagemath-environment, sage-setup, sage-sws2rst for PyPI
> 90e08c88c60 gh-37057: deprecated functions is_Cone, is_Polyhedron, 
> is_LatticePolytope
> ca1b5e6ea0d gh-37041: update FriCAS to 1.3.10, allow building with sbcl
> f19f431d095 gh-36982: Make pyproject.toml the source for build dependencies
> 23ba3d8f174 gh-36768: Retrieve more information of fundamental groups of 
> plane curves
> f633de0146a gh-36498: CI build, doc-build: Run containers explicitly, 
> separate jobs for pyright, build, modularized tests, long tests
> f3847837395 gh-35618: Use `pypa/build` instead of `pip wheel`
> c4363fc97eb (tag: 10.4.beta4) Updated SageMath version to 10.4.beta4
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-release" group.
To unsubscribe from this 

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 
>>>> <https://github.com/sagemath/sage/pull/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://g

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 
>>> <https://github.com/sagemath/sage/pull/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

[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: Proposal (redo): Make python_build (and its dependency pyproject_hooks) a standard package

[John H Palmieri]

+1 to the inclusion of the package, in case anyone views the voting as 
still open.

François, thank you for letting us know about how the ongoing disputes are 
affecting you. I feel your pain.

Regards,
  John


On Monday, April 15, 2024 at 2:01:43 PM UTC-7 François Bissey wrote:

>
>
> On 16/04/24 04:41, kcrisman wrote:
> > SageMath has several other long-term contributors who also package
> > software. We're all roughly on the same page about what it would take
> > to fix the sage installation for end users.
> > 
> > 
> > And some of these people (perhaps kiwifb?) have not been as directly 
> > involved in some of the recent disputes.   Maybe there is a path forward 
> > (I also presume the CoCC is thinking about this).
>
> I would say I have involved myself too much already. I am regularly 
> asked to review some of those tickets that are disputed or become disputed.
>
> It floods my inbox and makes my heart sink.
>
> François
>

-- 
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/94636127-868a-415a-9033-8159582292c6n%40googlegroups.com.

Re: [sage-devel] Mysterious .sage behavior

[John H Palmieri]

I searched for "ipython-5.0.0" in the source and found this:

if [ -z "$IPYTHONDIR" ]; then
# We hardcode a version number in the directory name. The idea is
# that we keep using the same version number as long as that is
# possible. Only when some future IPython version really requires
# a new structure for the $IPYTHONDIR should this version number be
# changed to the new IPython version.
export IPYTHONDIR="$DOT_SAGE/ipython-5.0.0"
fi

So it should be viewed as "IPython, version 5.0.0 or later, as long as 
things remain compatible". Maybe it would be better to have a directory 
"ipython-config" (for example) with subdirectories that somehow convey the 
version information. We could also, or in addition, create a README file 
the existing directory with some sort of explanation.

-- 
John


On Monday, April 1, 2024 at 2:38:09 PM UTC-7 Marc Culler wrote:

> The problem that it *causes* is that people think that Sage has somehow 
> managed to install an ancient ipython-5.0.0 in their ~/.sage directory.  
> The user that reported this was indeed having problems because of an out of 
> date ipython thet they had installed with %pip.  The python package was 
> installed as a --user package  in  ~/.sage.   That is where the macOS app 
> installs all pip packages, being disallowed from putting them into the app 
> bundle itself because that would break the signature and macOS would then 
> refuse to run the app..
>
> The old version of ipython caused the new app to crash with the rather 
> amazing error message "object of type List is not iterable".  When the user 
> removed their ~/.sage directory everything worked as expected.  But then, 
> after starting Sage,  they checked to see what was actually in the 
> directory, and were alarmed to ",find" that Sage had re-installed 
> ipython-5.0.0.
>
> As I said, this idea confuses users, and understandably so.  It was not a 
> great idea. There were so many other, better, ways of naming the directory.
>
> Maybe for the next Sage release I will move the pip packages to 
> ~/Library/SageMath-X.Y.  That won't stop Sage from creating 
> ~/.sage/ipython-5.0.0 but it will remove the motivation for users to look 
> in the .sage directory and get confused.
>
> - Marc
>
> On Monday, April 1, 2024 at 3:31:06 PM UTC-5 Nils Bruin wrote:
>
>> One scenario where I could see this being beneficial:
>> These configurations are written into `$HOME/.sage` (normally), so that 
>> is not a location that is predicated by a venv or a localized subdir. If a 
>> user is using two different sagemath installs (e.g., one system, the other 
>> for development) that have incompatible ipython configs, they need to live 
>> in places that allow peaceful co-existence. This would do it. I agree the 
>> version number can look confusing, It seems like a historic artifact that 
>> we didn't need to change our ipython configs since version 5.0.0, probably. 
>> It looks to me like a fairly arbitrary choice how to mark that directory 
>> name. Not changing it would be the easiest solution, but if someone wants 
>> to make an argument that another naming convention has benefits (following 
>> common practices that have since evolved?) it could be changed, at the 
>> expense of everyone with an install needing to change locations of files 
>> they already customized. So based on that, I think the best time to change 
>> it (if at all) would be when an incompatible change in config is happening 
>> anyway.
>>
>>
>> On Monday 1 April 2024 at 12:20:16 UTC-7 Dima Pasechnik wrote:
>>
>>
>> I must say I don't know what kind of problems these versioned names are 
>> meant to solve. 
>>
>>  
>>
>> >On 31 March 2024 15:23:24 CEST, Marc Culler > > wrote :  
>>
>> >if [ -z "$IPYTHONDIR" ]; then 
>> > # We hardcode a version number in the directory name. The idea is 
>> > # that we keep using the same version number as long as that is 
>> > # possible. Only when some future IPython version really requires 
>> > # a new structure for the $IPYTHONDIR should this version number be 
>> > # changed to the new IPython version. 
>> > export IPYTHONDIR="$DOT_SAGE/ipython-5.0.0" 
>> >fi 
>>
>>

-- 
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/3de2c4d8-f592-4088-bb61-c063d38ec110n%40googlegroups.com.

[sage-release] Re: Sage 10.4.beta0 released

[John H Palmieri]

And on two OS X Apple Silicon machines running Sonoma 14.4.1, new Xcode 
command line tools, sagelib fails to build, as reported here: 
https://groups.google.com/g/sage-support/c/05DARjR8PFI/m/ZqCuYjhIAAAJ


On Tuesday, March 26, 2024 at 5:20:02 PM UTC-7 John H Palmieri wrote:

> OS X Intel machine, documentation fails to build with errors like
>
> OSError: [Errno 24] Too many open files: 
> '/var/folders/z6/yjw_7s357yx3_mhh81__lplcgn/T/tmpu490zz15'
>
> I just built 10.3.rc4 on the same machine and it succeeded.
>
>
> On Monday, March 25, 2024 at 5:13:42 PM UTC-7 Volker Braun wrote:
>
>> As always, you can get the latest beta version from the "develop" git 
>> branch. Alternatively, the self-contained source tarball is at 
>> http://www.sagemath.org/download-latest.html
>>
>>
>> b693ea936fa (origin/develop, tag: 10.4.beta0) Updated SageMath version to 
>> 10.4.beta0
>> b0343d194ea gh-37346: `sage.schemes.generic`: fix docs
>> 8daac35614a gh-37345: implemented function for acyclic orientations
>> 99917591610 gh-37343: Add simple methods to convert to and from bytes for 
>> `ZZ` and finite fields
>> 80e3e609c41 gh-37335: some details in modules (ruff and pep)
>> 217a01968d7 gh-37331: Fixed the doc `sets/recursively_enumerated_set.py`
>> 1f87f98fac2 gh-37322: `sage --package create`: Attempt to bring SPKG.rst 
>> title to a common style
>> c8f5fa4d5db gh-37315: Reference manual: Show package list by category 
>> (math/front-end/other)
>> 6fa97ea57e0 gh-37309: README.md: Move all mentions of release tarballs to 
>> the installation guide
>> 31a08e0366e gh-37288: Directly convert PermutationGroup element into 
>> sized Permutation
>> bab9e4c77ed gh-37264: PDF docbuild: Reduce verbosity
>> 58fbf26925b gh-37257: `sage.groups.generic`: Fix incorrect identity 
>> testing
>> 322860f867f gh-37251: ntl 11.5.1
>> 61066b10409 gh-37198: Translate "A Tour of Sage" into Greek
>> b3d639b6789 gh-37184: Improve Windows installation instructions
>> ba8393ec23f gh-37127: Rerun `configure` less often
>> 397fd3fe34d gh-37118: Fix random polynomial bias
>> 9d73e3cc91c gh-37100: Quaternion Algebra Fractional Ideal improvements - 
>> equivalence and reduced bases
>> f81e21fe963 gh-37083: HTML documentation: Show preparsed doctests using 
>> inline tabs
>> 767c7e8f42e gh-37054: `CODE_OF_CONDUCT.md`: Do not send people to 
>> sage-flame
>> 1ce793911bc gh-37013: Implement the center of a universal enveloping 
>> algebra in the PBW basis
>> 330c35daa82 gh-37011: allowing external ECM to be called gmp-ecm or ecm
>> 3ea5fa9ead4 gh-36971: add helper method to concatenate vectors
>> 3abc045fbeb gh-36970: CI: Upload test stats as artifacts, improve output 
>> of "List Docker images"
>> 93066dbd158 gh-36907: Implementation of the quantum oscillator algebra
>> 80a2744f046 gh-36777: spkg-configure.m4 for most external Python pkgs
>> 78bdda47d1a gh-36748: Implement Specht modules in the tabloid basis
>> 821d8dab96e gh-36741:  Doctest hide option: Better detection of hidden 
>> packages
>> ad7ee31da57 gh-36581: `sage/stats/distributions`: Implement non-spherical 
>> Gaussian sampling over lattices
>> b575734f3c4 gh-36329: Implement call method for elements in CDGA's
>> 4ec03a8daa1 gh-35517: implement the depth of a quasimodular form
>> 0c873c6fd91 gh-35029: Implement basis_of_weight for rings of quasimodular 
>> forms
>> ccc11b6285c (tag: 10.3, github/master) Updated SageMath version to 10.3
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-release" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-release+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-release/8f525412-0ae3-4f99-9da5-1e7d87a34cdan%40googlegroups.com.

Re: [sage-support] Errors building Sage 10.3 in Sonoma 14.3.1

[John H Palmieri]

I'm having the same problem (I think) with Sage 10.4.beta0 on two different 
Apple Silicon machines.

On Wednesday, March 27, 2024 at 9:58:10 AM UTC-7 Dima Pasechnik wrote:

> I've cut out the interesting part of the log.
> It's a linker error (IMHO the linking should be done with C++, not
> with C compiler, but that's probably OK on macOS).
> Related to GiNaC (not a surprise)
>
> Anyway, I haven't seen this sort of errors before. Something for Apple 
> fans...
>
>
> On Wed, Mar 27, 2024 at 3:54 PM Jon Higa  
> wrote:
> >
> > Switched to this, continuing in the same directory:
> >
> > git clean -xdf
> > source .homebrew-build-env
> > make configure
> > ./configure --prefix=/usr/local/sage/10.3 --enable-database_odlyzko_zeta 
> --disable-editable 
> --with-python=/opt/homebrew/opt/pyt...@3.11/bin/python3.11
> > make
> >
> > New logs attached.
> >
> > Thanks.
> >
> > On Wednesday, March 27, 2024 at 6:24:37 AM UTC-4 Dima Pasechnik wrote:
> >
> > sagemath doesn't officially support Python 3.12.
> > Can you try with 3.11 instead?
> >
> >
> >
> > --
> > You received this message because you are subscribed to the Google 
> Groups "sage-support" group.
> > To unsubscribe from this group and stop receiving emails from it, send 
> an email to sage-support...@googlegroups.com.
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-support/9bfc9093-a640-4c75-9b62-0fd21ab3474en%40googlegroups.com
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-support+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-support/2682d574-73c4-4ff7-8c5b-477563f61cf5n%40googlegroups.com.

[sage-release] Re: Sage 10.4.beta0 released

[John H Palmieri]

OS X Intel machine, documentation fails to build with errors like

OSError: [Errno 24] Too many open files: 
'/var/folders/z6/yjw_7s357yx3_mhh81__lplcgn/T/tmpu490zz15'

I just built 10.3.rc4 on the same machine and it succeeded.


On Monday, March 25, 2024 at 5:13:42 PM UTC-7 Volker Braun wrote:

> As always, you can get the latest beta version from the "develop" git 
> branch. Alternatively, the self-contained source tarball is at 
> http://www.sagemath.org/download-latest.html
>
>
> b693ea936fa (origin/develop, tag: 10.4.beta0) Updated SageMath version to 
> 10.4.beta0
> b0343d194ea gh-37346: `sage.schemes.generic`: fix docs
> 8daac35614a gh-37345: implemented function for acyclic orientations
> 99917591610 gh-37343: Add simple methods to convert to and from bytes for 
> `ZZ` and finite fields
> 80e3e609c41 gh-37335: some details in modules (ruff and pep)
> 217a01968d7 gh-37331: Fixed the doc `sets/recursively_enumerated_set.py`
> 1f87f98fac2 gh-37322: `sage --package create`: Attempt to bring SPKG.rst 
> title to a common style
> c8f5fa4d5db gh-37315: Reference manual: Show package list by category 
> (math/front-end/other)
> 6fa97ea57e0 gh-37309: README.md: Move all mentions of release tarballs to 
> the installation guide
> 31a08e0366e gh-37288: Directly convert PermutationGroup element into sized 
> Permutation
> bab9e4c77ed gh-37264: PDF docbuild: Reduce verbosity
> 58fbf26925b gh-37257: `sage.groups.generic`: Fix incorrect identity testing
> 322860f867f gh-37251: ntl 11.5.1
> 61066b10409 gh-37198: Translate "A Tour of Sage" into Greek
> b3d639b6789 gh-37184: Improve Windows installation instructions
> ba8393ec23f gh-37127: Rerun `configure` less often
> 397fd3fe34d gh-37118: Fix random polynomial bias
> 9d73e3cc91c gh-37100: Quaternion Algebra Fractional Ideal improvements - 
> equivalence and reduced bases
> f81e21fe963 gh-37083: HTML documentation: Show preparsed doctests using 
> inline tabs
> 767c7e8f42e gh-37054: `CODE_OF_CONDUCT.md`: Do not send people to 
> sage-flame
> 1ce793911bc gh-37013: Implement the center of a universal enveloping 
> algebra in the PBW basis
> 330c35daa82 gh-37011: allowing external ECM to be called gmp-ecm or ecm
> 3ea5fa9ead4 gh-36971: add helper method to concatenate vectors
> 3abc045fbeb gh-36970: CI: Upload test stats as artifacts, improve output 
> of "List Docker images"
> 93066dbd158 gh-36907: Implementation of the quantum oscillator algebra
> 80a2744f046 gh-36777: spkg-configure.m4 for most external Python pkgs
> 78bdda47d1a gh-36748: Implement Specht modules in the tabloid basis
> 821d8dab96e gh-36741:  Doctest hide option: Better detection of hidden 
> packages
> ad7ee31da57 gh-36581: `sage/stats/distributions`: Implement non-spherical 
> Gaussian sampling over lattices
> b575734f3c4 gh-36329: Implement call method for elements in CDGA's
> 4ec03a8daa1 gh-35517: implement the depth of a quasimodular form
> 0c873c6fd91 gh-35029: Implement basis_of_weight for rings of quasimodular 
> forms
> ccc11b6285c (tag: 10.3, github/master) Updated SageMath version to 10.3
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-release" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-release+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-release/30a67dc7-2f1c-4cba-963d-006a7f1d780dn%40googlegroups.com.

[sage-devel] Vote: changes to Sage's Code of Conduct

[John H Palmieri]

Dear Sage community,

As announced at 
https://groups.google.com/g/sage-devel/c/Xf6dbPLmKPY/m/p88auKlBAwAJ, I 
propose some changes to the Code of Conduct. Those changes have been 
discussed and modified based on feedback from several developers: visit 
https://github.com/sagemath/sage/pull/37501 for details. Those changes are 
now ready for a vote here on sage-devel. 

Please vote: do you approve the changes to the Code of Conduct proposed at 
https://github.com/sagemath/sage/pull/37501? Please vote on or before March 
31.

In case you want a summary: the old code of conduct was pretty short, so 
some details were added, and whole new sections were added. The proposed 
changes were greatly inspired by similar documents from the SciPy and 
NumFOCUS projects, and the proposed code now includes sections on 
diversity, how to report potential violations,  names of the committee 
members, and what is necessary to amend the document. There is also a new 
document, a manual for the Code of Conduct Committee, which describes what 
that committee does and what actions it might take to respond to reports. 
That document is a modified version of SciPy's corresponding document.

-- 
John

-- 
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/97bcddfd-5a48-4feb-ae61-f8c2e50f7cc3n%40googlegroups.com.

[sage-devel] Re: Vote: Sage Code of Conduct

[John H Palmieri]

Dear all,

First, in response to Dima's post: yes, it should definitely be Nils Bruin 
on the ballot. My sincere apologies to Nils that we got his name wrong! If 
anyone would like to adjust their ballot in light of this, please let us 
know and we will make any corrections you request.

Second, voting closes tomorrow. Please vote!

Regards,
  John



On Wednesday, March 13, 2024 at 8:05:32 AM UTC-7 Dima Pasechnik wrote:

> On Thursday, March 7, 2024 at 6:13:42 PM UTC David Roe wrote:
>
> Dear Sage developers,
> Thank you for those you nominated people for the committee following my 
> request 
> , 
> and thank you for those of you willing to serve.  The nominees are
>
> Nils Braun (nbr...@sfu.ca)
>
>
> Braun? Or Bruin ?
>
> I didn't notice when I voted (noticed only last night), as I blindly 
> assumed it's Bruin,
> and just went and searched for Nils Braun at SFU, (nobody found)
> but that's too big a typo to let this unnoticed.
>
> It can very well be that someone looked at Nils Braun ()
> and was unable to figure out who this is - and just skipped.
>
> Note that Nils Bruin has a github handle: https://github.com/nbruin
> but it was not listed.
>
> I think the vote shoud be re-done - if it's indeed not a mystical Nils 
> Braun
> on the ballot, and not Nils Bruin
>
> Cheers,
> Dima
>
>
>
>
>
>  
>
> J-P Labbé (jeanphil...@gmail.com, jplab on github)
> John Palmieri (jhpalm...@gmail.com, jhpalmieri on github)
> Viviane Pons (vivia...@gmail.com, VivianePons on github)
> David Roe (roed...@gmail.com, roed314 on github)
> Julian Rüth (julian...@fsfe.org, saraedum on github)
> William Stein (wst...@gmail.com, williamstein on github)
> Yuan Zhou (xiaoy...@gmail.com, yuan-zhou on github)
>
> Please send votes to sage-c...@googlegroups.com* by Thursday, March 14.  
> We are using approval voting 
> , so you can vote 
> for as many candidates as you like.  The committee will include at least 
> the top 5 candidates, and will be enlarged to include all tied candidates 
> if there is a tie for 5th place.  Note that you can choose to vote for more 
> or less than 5 candidates if you like.
>
> Discussion of candidates is allowed (feel free to continue this thread), 
> but please be respectful.  If you want to see the participation of these 
> candidates in the Sage community, you can search by name on sage-devel 
>  and on github 
> .
>
> Thanks for voting,
> David
> for the Sage Code of Conduct Committee
>
> * We are replacing sage-...@googlegroups.com with 
> sage-c...@googlegroups.com; they currently have the same membership.
>
>

-- 
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/fd4b3d24-51a6-49fc-a59c-6167e7c05654n%40googlegroups.com.

[cctalk] Re: Did something happen to comp.os.vms ?

[John H. Reinhardt via cctalk]

On 3/9/2024 1:50 PM, Zane Healy via cctalk wrote:

Did something happen to comp.os.vms and/or usenet?  All the DEC newsgroups 
appear to be missing from Eternal September.

Zane


Eternal September and Thunderbird (I'm on a Mac) have been weird for me for a while.  For 
example I have had no new messages there in comp.os.vms since 3/9 until today (3/12) and 
then I got 23 messages dated 3/10 - 3/12.  I even did a "Get Messages" several 
time and nothing.  I don't know if it's Thunderbird or E-S.

--
John H. Reinhardt

Re: [sage-devel] Google Season of Docs – org application deadline April 2

[John H Palmieri]

Dima's suggestion is appealing, and somewhat along those lines, I like the 
idea changing Sage to use some standard documentation style 
(https://github.com/sagemath/sage/issues/31044). If the program provides a 
technical writer, though, those may not be suitable goals. A quick glance 
at least year's awards suggests a focus more on the writing and the 
content, not how it is technically presented or generated.

I don't know the whole history of our documentation, but at least some 
versions of it were written by people with no knowledge of how to write 
good software documentation — speaking only for myself and the parts that 
I've worked on. I'm guessing that a technical writer's eyes might spot 
things and see ways to improve them. We have lots of documentation, and I 
think that some of it is very good, probably explains lots of things 
clearly, but it may not always be written with the right audience in mind. 
I think we could use more organization surrounding the tutorial, the 
thematic tutorials, the PREP tutorials, constructions in Sage, a tour of 
Sage, and the FAQ; this could very well make the documentation more 
accessible and allow users to find documentation at the right level and 
with the right content for what they're trying to do. All of that is the 
documentation that we hope new users look at, and in my opinion that's 
where we should focus.



On Sunday, March 10, 2024 at 8:00:03 PM UTC-7 David Roe wrote:

> I think the main question is who is willing to take the lead on writing 
> and submitting applications (before April 2).  I don't have enough time in 
> the next three weeks to do any writing, but I am willing to help brainstorm 
> what form the proposal(s) should take and help edit proposals if someone 
> else volunteers to write them.
> David
>
> On Sun, Mar 10, 2024 at 6:18 PM Matthias Koeppe  
> wrote:
>
>> Yes, we could prepare several proposals for separate projects. 
>> One can see in the lists of past funded projects that some organizations 
>> have received funding for two simultaneous projects.
>>
>> On Sunday, March 10, 2024 at 8:38:13 AM UTC-7 John Cremona wrote:
>>
>>> Should there not be separate projects for documenting (1) building and 
>>> installing Sage; (2) using Sage (perhaps with some subject-specific 
>>> tutorials, some of which exist but might be worth updating) and (3) 
>>> documenting individual Sage functions and methods.
>>>
>>> These require different expertise, for example I recently found a badly 
>>> misleading docstring in the elliptic curves section, but only someone with 
>>> the right expertise would be able to rewrite it properly (yes, I will 
>>> create an issue for this soon!)
>>>
>>> John
>>>
>>> On Sun, 10 Mar 2024 at 15:03, David Roe  wrote:
>>>
 I think this would be good for Sage.  I think there are several 
 decisions to be made:
 * What are our most pressing documentation needs?  Personally, I think 
 we have a gap between the reference manual (which is extensive but has no 
 flow) and the thematic tutorials (which are written to tell a story but 
 are 
 just introductions).  I also poked around online for criticisms of Sage's 
 documentation and found complaints about not having separate pages for 
 each function  
 (compared to Mathematica's), some suggestions here 
 
  
 about focusing on aspects of Sage commonly used by beginners (like 
 plotting).
 * Who will be involved in applying and supervising the project?  This 
 could be a group or a single person.  I can help a bit, but I can't take 
 the lead.
 David

 On Sat, Mar 9, 2024 at 5:13 PM Matthias Koeppe  
 wrote:

> SageMath could benefit from hiring a technical writer for a project to 
> improve the Sage documentation. Google Season of Docs is a program 
> that supports such projects. Some key facts:
> - total project budget $5,000 - $15,000 USD (via OpenCollective) - 
> https://developers.google.com/season-of-docs/docs/org-payments
> - starts April 10 (or May 22 the latest), ends November 22, 2024 - 
> https://developers.google.com/season-of-docs/docs/timeline
>
> Several of our peer projects (NumPy, Matplotlib, SymPy, R, Geomstats) 
> are among the orgs that appear to have made successful use of this 
> program 
> in the past few years, see 
> https://developers.google.com/season-of-docs/docs/2023/participants 
> etc.
>
> Thoughts?
>
> -- 
> 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+...@googlegroups.com.
> To view this discussion on the web visit 
> 

[sage-devel] Re: Vote: Sage Code of Conduct

[John H Palmieri]

Dear all,

Voting continues until Thursday. We have been acknowledging each vote as it 
comes in, so if you think you voted but have not received an 
acknowledgment, please email sage-conduct at googlegroups.com.

Regards,
  John



On Thursday, March 7, 2024 at 10:46:03 AM UTC-8 John H Palmieri wrote:

> Right, please email your vote to that group. Only members of the committee 
> can actually see the postings.
>
> On Thursday, March 7, 2024 at 10:44:03 AM UTC-8 Martin R wrote:
>
>> Thank you - apparently, I do not have permission to see that group.  I'll 
>> try to send my vote by email.
>>
>> On Thursday 7 March 2024 at 19:39:14 UTC+1 John H Palmieri wrote:
>>
>>> Martin: it's "sage-conduct" at googlegroups.com.
>>>
>>> On Thursday, March 7, 2024 at 10:29:58 AM UTC-8 Martin R wrote:
>>>
>>>> For some reason, I cannot see the name of the newsgroup I should be 
>>>> sending my vote to.  (I am using the google groups webinterface)
>>>>
>>>> Martin
>>>> On Thursday 7 March 2024 at 19:13:42 UTC+1 David Roe wrote:
>>>>
>>>>> Dear Sage developers,
>>>>> Thank you for those you nominated people for the committee following my 
>>>>> request 
>>>>> <https://groups.google.com/g/sage-devel/c/u-jUo098jQg/m/Hdiqzn0GAwAJ>, 
>>>>> and thank you for those of you willing to serve.  The nominees are
>>>>>
>>>>> Nils Braun (nbr...@sfu.ca)
>>>>> J-P Labbé (jeanphil...@gmail.com, jplab on github)
>>>>> John Palmieri (jhpalm...@gmail.com, jhpalmieri on github)
>>>>> Viviane Pons (vivia...@gmail.com, VivianePons on github)
>>>>> David Roe (roed...@gmail.com, roed314 on github)
>>>>> Julian Rüth (julian...@fsfe.org, saraedum on github)
>>>>> William Stein (wst...@gmail.com, williamstein on github)
>>>>> Yuan Zhou (xiaoy...@gmail.com, yuan-zhou on github)
>>>>>
>>>>> Please send votes to sage-c...@googlegroups.com* by Thursday, March 
>>>>> 14.  We are using approval voting 
>>>>> <https://electionscience.org/library/approval-voting/>, so you can 
>>>>> vote for as many candidates as you like.  The committee will include 
>>>>> at least the top 5 candidates, and will be enlarged to include all tied 
>>>>> candidates if there is a tie for 5th place.  Note that you can choose to 
>>>>> vote for more or less than 5 candidates if you like.
>>>>>
>>>>> Discussion of candidates is allowed (feel free to continue this 
>>>>> thread), but please be respectful.  If you want to see the participation 
>>>>> of 
>>>>> these candidates in the Sage community, you can search by name on 
>>>>> sage-devel <https://groups.google.com/g/sage-devel> and on github 
>>>>> <https://github.com/sagemath/sage>.
>>>>>
>>>>> Thanks for voting,
>>>>> David
>>>>> for the Sage Code of Conduct Committee
>>>>>
>>>>> * We are replacing sage-...@googlegroups.com with 
>>>>> sage-c...@googlegroups.com; they currently have the same membership.
>>>>>
>>>>

-- 
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/93b73d16-8b1f-40d8-ada0-f5d48bd520cen%40googlegroups.com.

[sage-devel] Re: Vote: Sage Code of Conduct

[John H Palmieri]

Right, please email your vote to that group. Only members of the committee 
can actually see the postings.

On Thursday, March 7, 2024 at 10:44:03 AM UTC-8 Martin R wrote:

> Thank you - apparently, I do not have permission to see that group.  I'll 
> try to send my vote by email.
>
> On Thursday 7 March 2024 at 19:39:14 UTC+1 John H Palmieri wrote:
>
>> Martin: it's "sage-conduct" at googlegroups.com.
>>
>> On Thursday, March 7, 2024 at 10:29:58 AM UTC-8 Martin R wrote:
>>
>>> For some reason, I cannot see the name of the newsgroup I should be 
>>> sending my vote to.  (I am using the google groups webinterface)
>>>
>>> Martin
>>> On Thursday 7 March 2024 at 19:13:42 UTC+1 David Roe wrote:
>>>
>>>> Dear Sage developers,
>>>> Thank you for those you nominated people for the committee following my 
>>>> request 
>>>> <https://groups.google.com/g/sage-devel/c/u-jUo098jQg/m/Hdiqzn0GAwAJ>, 
>>>> and thank you for those of you willing to serve.  The nominees are
>>>>
>>>> Nils Braun (nbr...@sfu.ca)
>>>> J-P Labbé (jeanphil...@gmail.com, jplab on github)
>>>> John Palmieri (jhpalm...@gmail.com, jhpalmieri on github)
>>>> Viviane Pons (vivia...@gmail.com, VivianePons on github)
>>>> David Roe (roed...@gmail.com, roed314 on github)
>>>> Julian Rüth (julian...@fsfe.org, saraedum on github)
>>>> William Stein (wst...@gmail.com, williamstein on github)
>>>> Yuan Zhou (xiaoy...@gmail.com, yuan-zhou on github)
>>>>
>>>> Please send votes to sage-c...@googlegroups.com* by Thursday, March 
>>>> 14.  We are using approval voting 
>>>> <https://electionscience.org/library/approval-voting/>, so you can vote 
>>>> for as many candidates as you like.  The committee will include at least 
>>>> the top 5 candidates, and will be enlarged to include all tied candidates 
>>>> if there is a tie for 5th place.  Note that you can choose to vote for 
>>>> more 
>>>> or less than 5 candidates if you like.
>>>>
>>>> Discussion of candidates is allowed (feel free to continue this 
>>>> thread), but please be respectful.  If you want to see the participation 
>>>> of 
>>>> these candidates in the Sage community, you can search by name on 
>>>> sage-devel <https://groups.google.com/g/sage-devel> and on github 
>>>> <https://github.com/sagemath/sage>.
>>>>
>>>> Thanks for voting,
>>>> David
>>>> for the Sage Code of Conduct Committee
>>>>
>>>> * We are replacing sage-...@googlegroups.com with 
>>>> sage-c...@googlegroups.com; they currently have the same membership.
>>>>
>>>

-- 
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/bcc53760-2338-47ef-8a6c-0482c4a48bd7n%40googlegroups.com.

[sage-devel] Re: Vote: Sage Code of Conduct

[John H Palmieri]

Martin: it's "sage-conduct" at googlegroups.com.

On Thursday, March 7, 2024 at 10:29:58 AM UTC-8 Martin R wrote:

> For some reason, I cannot see the name of the newsgroup I should be 
> sending my vote to.  (I am using the google groups webinterface)
>
> Martin
> On Thursday 7 March 2024 at 19:13:42 UTC+1 David Roe wrote:
>
>> Dear Sage developers,
>> Thank you for those you nominated people for the committee following my 
>> request 
>> , 
>> and thank you for those of you willing to serve.  The nominees are
>>
>> Nils Braun (nbr...@sfu.ca)
>> J-P Labbé (jeanphil...@gmail.com, jplab on github)
>> John Palmieri (jhpalm...@gmail.com, jhpalmieri on github)
>> Viviane Pons (vivia...@gmail.com, VivianePons on github)
>> David Roe (roed...@gmail.com, roed314 on github)
>> Julian Rüth (julian...@fsfe.org, saraedum on github)
>> William Stein (wst...@gmail.com, williamstein on github)
>> Yuan Zhou (xiaoy...@gmail.com, yuan-zhou on github)
>>
>> Please send votes to sage-c...@googlegroups.com* by Thursday, March 14.  
>> We are using approval voting 
>> , so you can vote 
>> for as many candidates as you like.  The committee will include at least 
>> the top 5 candidates, and will be enlarged to include all tied candidates 
>> if there is a tie for 5th place.  Note that you can choose to vote for more 
>> or less than 5 candidates if you like.
>>
>> Discussion of candidates is allowed (feel free to continue this thread), 
>> but please be respectful.  If you want to see the participation of these 
>> candidates in the Sage community, you can search by name on sage-devel 
>>  and on github 
>> .
>>
>> Thanks for voting,
>> David
>> for the Sage Code of Conduct Committee
>>
>> * We are replacing sage-...@googlegroups.com with 
>> sage-c...@googlegroups.com; they currently have the same membership.
>>
>

-- 
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/59ca7e2b-bf7c-4820-9861-008de9b009cfn%40googlegroups.com.

[sage-devel] Re: VOTE: Use "CI Fix" label for merging into continuous integration runs

[John H Palmieri]

+1

-- 
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/db4939fa-dda7-4c53-b4f0-5bb229d3826bn%40googlegroups.com.

[sage-devel] Re: VOTE: disputed PRs

[John H Palmieri]

+1

On Monday, March 4, 2024 at 12:23:39 AM UTC-8 David Roe wrote:

> With no further discussion on this thread 
> , I'm calling a 
> vote on a new process for resolving disagreements on a PR.
>
> *Proposal*
> It is now allowed to vote on disputed PRs directly on Github rather than 
> bringing them to sage-devel.  Working things out amicably is preferable, 
> and anyone is welcome to ask on sage-devel for more eyes on a PR.  If you 
> notice a serious issue with a PR, it is acceptable to change it to Needs 
> Work (and make a comment!) as an initial step, but if the author or 
> reviewer do not agree then process below should be followed instead. This 
> process is intended as a lower-intensity method for resolving 
> disagreements, and full votes on sage-devel override the process described 
> below.
> a. When there is disagreement about whether a PR should be merged, anyone 
> may mark a PR as disputed.
> b. There is no scheduled vote, but rather an ongoing poll based on 
> opinions expressed by developers on the PR (these opinions can be expressed 
> via previous positive reviews or explicit comments giving approval).  The 
> PR author is presumed to vote in favor; if they give up or no longer favor 
> the PR they have the right to close the PR overall without any further 
> voting.
> c. If the total number of positive votes is at least twice the number of 
> negative votes, anyone involved may set the status to *positive review*; 
> if the total number of positive votes is less than twice the number of 
> negative votes, anyone involved may set the status to *needs review*.  
> When either of these actions is taken, the person changing the status must 
> list the people they are counting as positive and negative votes in a 
> comment using @ mentions.
> d. The final decision on merging a disputed PR remains with the release 
> manager, and we encourage the release manager to give enough time for 
> everyone to express an opinion.
>
> Voting will be open until Wednesday, March 13.
> David
>
>

-- 
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/c5314119-140d-41ee-b9e9-37e2a3303487n%40googlegroups.com.

Re: [sage-devel] VOTE: disputed PRs

[John H Palmieri]

Dima, I think that if anyone is incapable of posting to a particular PR, 
they should send email to someone who can post and ask them to record the 
person's vote, resulting in a comment like "I am posting to record 1 
negative vote from X, 2 positive votes from Y and Z".


On Monday, March 4, 2024 at 5:27:21 AM UTC-8 Dima Pasechnik wrote:

> David, 
> how about team members who are blocked on GitHub.
> For GitHub voting to work, this has to be sorted out first.
>
> Dima
>
> On Mon, Mar 4, 2024 at 8:23 AM David Roe  wrote:
>
>> With no further discussion on this thread 
>> , I'm calling a 
>> vote on a new process for resolving disagreements on a PR.
>>
>> *Proposal*
>> It is now allowed to vote on disputed PRs directly on Github rather than 
>> bringing them to sage-devel.  Working things out amicably is preferable, 
>> and anyone is welcome to ask on sage-devel for more eyes on a PR.  If you 
>> notice a serious issue with a PR, it is acceptable to change it to Needs 
>> Work (and make a comment!) as an initial step, but if the author or 
>> reviewer do not agree then process below should be followed instead. This 
>> process is intended as a lower-intensity method for resolving 
>> disagreements, and full votes on sage-devel override the process described 
>> below.
>> a. When there is disagreement about whether a PR should be merged, anyone 
>> may mark a PR as disputed.
>> b. There is no scheduled vote, but rather an ongoing poll based on 
>> opinions expressed by developers on the PR (these opinions can be expressed 
>> via previous positive reviews or explicit comments giving approval).  The 
>> PR author is presumed to vote in favor; if they give up or no longer favor 
>> the PR they have the right to close the PR overall without any further 
>> voting.
>> c. If the total number of positive votes is at least twice the number of 
>> negative votes, anyone involved may set the status to *positive review*; 
>> if the total number of positive votes is less than twice the number of 
>> negative votes, anyone involved may set the status to *needs review*.  
>> When either of these actions is taken, the person changing the status must 
>> list the people they are counting as positive and negative votes in a 
>> comment using @ mentions.
>> d. The final decision on merging a disputed PR remains with the release 
>> manager, and we encourage the release manager to give enough time for 
>> everyone to express an opinion.
>>
>> Voting will be open until Wednesday, March 13.
>> David
>>
>> -- 
>> 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+...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/sage-devel/CAChs6_n4az3_s16E%3DANOv_o%2B0SvavHwnpqKWYuOznGWTJoXqEg%40mail.gmail.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/f5e76b29-0011-428e-bf97-43fc16c2f6e9n%40googlegroups.com.

Re: [sage-devel] Re: Sage's Code of Conduct: proposed changes

[John H Palmieri]

There are suggestions along maybe similar lines at 
https://github.com/sagemath/sage/pull/36844, and I am trying to think of 
how we might incorporate your suggestions and the other ones. I've had the 
thought before about other documents (like our department's by-laws) that 
there should be two separate documents: the main one and then, separately, 
commentary (like the Talmud). These suggestions currently feel more like 
commentary to me, but one option would be to add a "commentary" section to 
the code of conduct.

-- 
John

On Friday, March 1, 2024 at 9:41:31 AM UTC-8 Martin R wrote:

> Thank you for the thoughtful reply!  You gave me a lot to think about, and 
> I'll do so over the weekend, rather than rushing.
>
> Best,
>
> Martin
> On Friday 1 March 2024 at 18:21:59 UTC+1 David Roe wrote:
>
>> Thank you for starting the conversation Martin.  I certainly think that 
>> all of these suggestions are appropriate to discuss, and that sage-devel is 
>> probably a better venue for discussion like this than the PR.
>>
>> On Fri, Mar 1, 2024 at 5:49 AM 'Martin R' via sage-devel <
>> sage-...@googlegroups.com> wrote:
>>
>>> I would like to ask whether we might want to add some of the following 
>>> to the code of conduct, I could not find it covered there.
>>>
>>> I admit that it is unclear to me whether the discussion should be on 
>>> pull requests only.  I don't want to add the following to John's pull 
>>> request, because it definitely doesn't belong there.  Opening another one 
>>> makes things even harder to follow, so I'm trying to be brave.
>>>
>>> I imagine that the issues below may be cultural things, so I would 
>>> perfectly understand that all or some of it is perfectly OK in some 
>>> communities, and therefore should not be part of the sage code of conduct.
>>>
>>> I also admit that some of the issues below are attitudes that make it 
>>> hard for me to work on sage.  There were some situations in which I would 
>>> possibly have stopped contributing to sage, if sage wasn't a professional 
>>> necessity for me.
>>>
>>
>> I'm sorry to hear that there were situations like this.  If you think it 
>> would be helpful to describe them in more detail privately (even if you're 
>> not seeking any kind of action), feel free to write to the Code of Conduct 
>> committee.
>>  
>> Here are my thoughts on your suggestions.  I think that some of them 
>> should definitely be included, though it's not completely clear to me where 
>> (it feels awkward to add yet another enumerated list).
>>  
>>
>>> 0. sage is a community effort, and not the project of a single or even a 
>>> few persons.  Try to not identify yourself with the code in sage.
>>>
>>  
>> The community aspect of Sage is currently discussed in the introduction, 
>> and perhaps we can tweak that to incorporate this suggestion.  As for the 
>> second half, I don't understand how it fits into a code of conduct, since 
>> it seems aimed at internal processes (like how to cope if your code is 
>> removed from Sage), rather than behavior.
>>
>> Currently our introduction is "The Sage community is comprised of an 
>> international mixture of mathematicians, computer scientists, engineers, 
>> researchers, teachers, amateurs, and others with varied backgrounds. This 
>> diversity is one of our strengths, but it can also lead to communication 
>> problems and unhappiness. People who love working on Sage can more 
>> effectively collaborate with others if they follow this code."  What do you 
>> feel is missing from this that you're trying to include?
>>  
>>
>>> 1. It is not OK to judge somebody else's attempts to improve sage other 
>>> than critisising it technically or casting a negative vote.  By contrast, 
>>> emphasising the positive aspects and appreciating the effort is welcome.
>>>
>>
>> I like the idea of including more about positivity, and this fits in with 
>> Guideline 2: "Be welcoming. We strive to be a community that welcomes and 
>> supports people of all backgrounds and identities."  Maybe we can append a 
>> sentence here like "When discussing contributions, endeavor to encourage 
>> positive aspects and avoid overly harsh criticism."
>>
>> I do think there are cultural differences here, and personally I think 
>> restricting negative feedback to just voting and "technical" criticism goes 
>> too far, partly because I don't think technical is very clearly defined.  
>> There are judgement calls to be made about what should be included into 
>> Sage, which are not always a matter of what method is technically 
>> superior.  I don't think we want to restrict developer's ability to offer 
>> negative feedback, but instead to encourage people to be positive and 
>> welcoming.  I'd like to hear other perspectives on this.
>>  
>>
>>> 2. It is not OK to emphasise oneselves contributions or stressing that 
>>> one has been right.  By contrast, it is fine to express that one is happy 
>>> or perhaps even proud to have solved a particular 

[sage-release] Re: Sage 10.3.rc0 released

[John H Palmieri]

The failing command:

gcc -fno-strict-overflow -Wsign-compare -Wunreachable-code -fno-common 
-dynamic -DNDEBUG -g -O3 -Wall -isysroot 
/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk -g -O2 -g 
-DHAVE_LIBTIFF -DHAVE_LIBJPEG -DHAVE_OPENJPEG -DHAVE_LIBZ -DHAVE_XCB 
-DPILLOW_VERSION=\"10.1.0\" 
-I/opt/homebrew/Cellar/openjpeg/2.5.1/include/openjpeg-2.5 
-I/opt/homebrew/Cellar/jpeg-turbo/3.0.1/include 
-I/opt/homebrew/Cellar/libtiff/4.6.0/include 
-I/opt/homebrew/Cellar/zstd/1.5.5/include 
-I/opt/homebrew/Cellar/xz/5.4.6/include 
-I/opt/homebrew/Cellar/freetype/2.13.2/include/freetype2 
-I/opt/homebrew/Cellar/libpng/1.6.42/include/libpng16 
-I/opt/homebrew/Cellar/harfbuzz/8.3.0_1/include/harfbuzz 
-I/opt/homebrew/Cellar/glib/2.78.4/include/glib-2.0 
-I/opt/homebrew/Cellar/glib/2.78.4/lib/glib-2.0/include 
-I/opt/homebrew/Cellar/gettext/0.22.5/include 
-I/opt/homebrew/Cellar/pcre2/10.42/include 
-I/opt/homebrew/Cellar/graphite2/1.3.14/include 
-I/opt/homebrew/Cellar/fribidi/1.0.13/include/fribidi 
-I/opt/homebrew/Cellar/little-cms2/2.16/include 
-I/Users/jpalmier/Sage/TESTING/sage-10.3.rc0/local/include 
-I/opt/homebrew/Cellar/primesieve/12.0/include 
-I/opt/homebrew/Cellar/bdw-gc/8.2.6/include 
-I/opt/homebrew/Cellar/libpng/1.6.42/include 
-I/opt/homebrew/Cellar/ntl/11.5.1/include 
-I/opt/homebrew/Cellar/readline/8.2.10/include -I/opt/homebrew/include 
-I/Users/jpalmier/Sage/TESTING/sage-10.3.rc0/local/var/lib/sage/venv-python3.12/include
 
-I/opt/homebrew/Cellar/freetype/2.13.2/include 
-I/Library/Developer/CommandLineTools/SDKs/MacOSX14.2.sdk/usr/include 
-I/Users/jpalmier/Sage/TESTING/sage-10.3.rc0/local/var/lib/sage/venv-python3.12/include
 
-I/opt/homebrew/opt/python@3.12/Frameworks/Python.framework/Versions/3.12/include/python3.12
 
-c src/libImaging/Jpeg2KDecode.c -o 
build/temp.macosx-14.0-arm64-cpython-312/src/libImaging/Jpeg2KDecode.o

Compared to the previous version (from January): the differences are

- the new version includes -fno-strict-overflow
- the old version includes -fwrapv
- various version numbers have changed, of course


On Wednesday, February 28, 2024 at 2:16:42 PM UTC-8 John H Palmieri wrote:

> OS X, Apple Silicon, with many homebrew packages, including a recently 
> upgraded openjpeg (from 2.5.0 to 2.5.1): pillow is failing to build, with 
> the error message
>
>   src/libImaging/Jpeg2KDecode.c:673:43: error: too few arguments to 
> function call, expected 3, have 2
>   opj_stream_set_user_data(stream, state);
>     ^
>   
> /opt/homebrew/Cellar/openjpeg/2.5.1/include/openjpeg-2.5/openjpeg.h:1235:27: 
> note: 'opj_stream_set_user_data' declared here
>   OPJ_API void OPJ_CALLCONV opj_stream_set_user_data(opj_stream_t* 
> p_stream,
> ^
>   1 error generated.
>   error: command '/usr/bin/gcc' failed with exit code 1
>   error: subprocess-exited-with-error
>   
>   × Building wheel for Pillow (pyproject.toml) did not run successfully.
>   │ exit code: 1
>   ╰─> See above for output.
>   
> I'm a little confused about jpeg, though: although this is using 
> openjpeg-2.5.1, Sage's top-level config.log file says
>
> pkg_cv_libjpeg_CFLAGS=-I/opt/homebrew/Cellar/jpeg-turbo/3.0.1/include
> pkg_cv_libjpeg_LIBS='-L/opt/homebrew/Cellar/jpeg-turbo/3.0.1/lib 
> -ljpeg'
>
> pillow's log file says
>
> Looking for `libjpeg` using pkg-config.
> Appending path /opt/homebrew/Cellar/jpeg-turbo/3.0.1/lib
> Appending path /opt/homebrew/Cellar/jpeg-turbo/3.0.1/include
> Looking for `libopenjp2` using pkg-config.
> Appending path /opt/homebrew/Cellar/openjpeg/2.5.1/lib
> Appending path /opt/homebrew/Cellar/openjpeg/2.5.1/include/openjpeg-2.5
>
> This is similar to a log file from a successful build, though.  (I don't 
> know how to attach files from the browser interface to Google groups.)
>
> Suggestions?
>
>
>
>
> On Sunday, February 25, 2024 at 10:44:20 AM UTC-8 Volker Braun wrote:
>
> As always, you can get the latest beta version from the "develop" git 
> branch. Alternatively, the self-contained source tarball is at 
> http://www.sagemath.org/download-latest.html
>
> acbe15dcd87 (HEAD -> develop, tag: 10.3.rc0, github/develop) Updated 
> SageMath version to 10.3.rc0
> 0fb793fa91a gh-37410: minor fixes in sandpiles
> 57d4e09af50 gh-37405: links for errors in doc of groups
> 6030e58afa0 gh-37398: fix `relabel` for permutation groups
> 5bda2e23eb2 gh-37397: fix some ruff suggestions in cluster_algebra_quiver
> ccd3f8b852e gh-37385: Remove some last traces of Trac
> 64b991ab0df gh-37376: src/sage/rings/polynomial: Link to spkg page by label
> e01a4380176 gh-37375: Speed up square matrix times vector over GF(2)
> 193e49d6742 gh-37367: improve random sampling of quotient-ring elem

[sage-release] Re: Sage 10.3.rc0 released

[John H Palmieri]

OS X, Apple Silicon, with many homebrew packages, including a recently 
upgraded openjpeg (from 2.5.0 to 2.5.1): pillow is failing to build, with 
the error message

  src/libImaging/Jpeg2KDecode.c:673:43: error: too few arguments to 
function call, expected 3, have 2
  opj_stream_set_user_data(stream, state);
    ^
  
/opt/homebrew/Cellar/openjpeg/2.5.1/include/openjpeg-2.5/openjpeg.h:1235:27: 
note: 'opj_stream_set_user_data' declared here
  OPJ_API void OPJ_CALLCONV opj_stream_set_user_data(opj_stream_t* p_stream,
^
  1 error generated.
  error: command '/usr/bin/gcc' failed with exit code 1
  error: subprocess-exited-with-error
  
  × Building wheel for Pillow (pyproject.toml) did not run successfully.
  │ exit code: 1
  ╰─> See above for output.
  
I'm a little confused about jpeg, though: although this is using 
openjpeg-2.5.1, Sage's top-level config.log file says

pkg_cv_libjpeg_CFLAGS=-I/opt/homebrew/Cellar/jpeg-turbo/3.0.1/include
pkg_cv_libjpeg_LIBS='-L/opt/homebrew/Cellar/jpeg-turbo/3.0.1/lib -ljpeg'

pillow's log file says

Looking for `libjpeg` using pkg-config.
Appending path /opt/homebrew/Cellar/jpeg-turbo/3.0.1/lib
Appending path /opt/homebrew/Cellar/jpeg-turbo/3.0.1/include
Looking for `libopenjp2` using pkg-config.
Appending path /opt/homebrew/Cellar/openjpeg/2.5.1/lib
Appending path /opt/homebrew/Cellar/openjpeg/2.5.1/include/openjpeg-2.5

This is similar to a log file from a successful build, though.  (I don't 
know how to attach files from the browser interface to Google groups.)

Suggestions?




On Sunday, February 25, 2024 at 10:44:20 AM UTC-8 Volker Braun wrote:

As always, you can get the latest beta version from the "develop" git 
branch. Alternatively, the self-contained source tarball is at 
http://www.sagemath.org/download-latest.html

acbe15dcd87 (HEAD -> develop, tag: 10.3.rc0, github/develop) Updated 
SageMath version to 10.3.rc0
0fb793fa91a gh-37410: minor fixes in sandpiles
57d4e09af50 gh-37405: links for errors in doc of groups
6030e58afa0 gh-37398: fix `relabel` for permutation groups
5bda2e23eb2 gh-37397: fix some ruff suggestions in cluster_algebra_quiver
ccd3f8b852e gh-37385: Remove some last traces of Trac
64b991ab0df gh-37376: src/sage/rings/polynomial: Link to spkg page by label
e01a4380176 gh-37375: Speed up square matrix times vector over GF(2)
193e49d6742 gh-37367: improve random sampling of quotient-ring elements
702e32f43f9 gh-37366: use Parent in skew polynomials
3ffb70a0d5a gh-37360: Fix doctest for `multiplication_by_m`
f5983a3c510 gh-37355: less usage of method .is_commutative
218012299eb gh-37354: Allow submodule construction of a free module over a 
ring
686f7e9a362 gh-37352: `sage --package create`: When re-creating with a 
different source type, clean up
0df697a0a2d gh-37350: `sage -package dependencies`
fba0587aa94 gh-37343: Add simple methods to convert to and from bytes for 
`ZZ` and finite fields
805c1522b87 gh-37342: remove some old deprecations in functional.py
a451b65a356 gh-37341: Avoid algebra in polynomials
57a404ca7ae gh-37339: Removed whitespaces in `ncsym.py`
ec7b486614b gh-37338: Speedup database_matroids.py tests
0f35a6911dc gh-37334: Preparation for Sphinx 7
e2c3fe9998e gh-37333: fixing ruff UP037 (about type annotation)
34de9761f25 gh-37329: add optional order= argument to .log() method for 
PARI finite-field elements
7f85dca6971 gh-37328: remove "known bug" marker for #6413 from doctest
721030b1b1d gh-37324: Basis completion for matrices over univariate 
polynomials
0b38b3eac89 gh-37318: Allowing HeckeAlgebraSymmetricGroupT to accept 
elements of SymmetricGroup(n) as input
f016b015301 gh-37316: use CommutativeRing in ring_extension
e54f7eb5e14 gh-37313: Fix package install instructions in "Numerical Sage" 
tutorial
0e819af60b8 gh-37311: Add tips for choosing an exception in developer guide
c3e76e125c1 gh-37306: Fix random test failures in 
`number_field_element_quadratic`
c1f56258170 gh-37303: use Parent in Weyl algebra
2416d61a12f gh-37302: use Parent instead of Algebra in finite_gca
2e9c5754bd6 gh-37299: use parent in quaternions
49881576723 gh-37286: sagemath-standard: fix manifest
99fd4f42794 gh-37283: Fix RegularSequence.subsequence for zero sequence
9a1a9649f33 gh-37281: details in Zariski-Van-Kampen
c02dfc43a6c gh-37273: large pep8 cleanup in interfaces
044b3aa1638 gh-37268: Allow custom degree in `random_element` of polynomial 
quotient ring
ffa87518e0f gh-37260: extend `all_paths_iterator` and `all_simple_paths` to 
Graph
d4075f1979c gh-37242: Improved algorithm choice for isogeny computation
54307752f5a gh-37231: Use matroid-database package
71f2ef44c96 gh-37227: build/pkgs/ipython/dependencies: Add matplotlib_inline
3eac6ea28db gh-37221: Added the alt nu-tamari lattices
abc70998ef1 gh-37206: Various edits of developer guide
726052b07ab gh-37186: Update debian.txt for various Python packages
bdf8f978a3c gh-37129: Sphinx 

[sage-devel] Sage's Code of Conduct: proposed changes

[John H Palmieri]

Dear colleagues,

I am working on some changes to Sage's Code of Conduct, and I am asking for 
comments. Once the draft has stabilized, then we will hold a vote on 
sage-devel to approve (or not) the changes. Please visit 
https://github.com/sagemath/sage/pull/37501 to see the proposal.

The current Code of Conduct was approved by a vote in sage-devel almost 10 
years ago. My intention is not to alter the core principles in the Code of 
Conduct, but instead to add more details: for example, how should you 
report a possible violation, what are possible consequences if the Sage 
Code of Conduct Committee (what has until now been called the Sage Abuse 
Committee) finds that a violation occurred, how to amend the document, etc. 
The changes are based in large part on similar documents from SciPy and 
NumFOCUS: we are not reinventing the wheel.

As such, I hope that the proposed changes are (a) not controversial, and 
(b) a clear improvement. I could certainly be wrong about either of these, 
but I will make this suggestion: if you agree with me about (a) and (b) and 
you also want to propose changes that are potentially more controversial, 
then I would ask that you make that proposal separately so that the Sage 
community can vote on it separately, and the changes can be merged 
independently of each other.

Please take a look and leave comments on the PR.

-- 
John

-- 
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/aa75eee6-a2b6-4f0d-8992-4995ed9f4310n%40googlegroups.com.

Re: [sage-devel] Re: [Proposal] allow standard packages to be pip packages, reduce source tarball size

[John H Palmieri]

That's called "whataboutism". Invoking what you consider inappropriate 
behavior by others is not relevant. Please stay on topic, and please follow 
Sage's code of conduct in your posts.

On Tuesday, February 27, 2024 at 1:01:25 PM UTC-8 Dima Pasechnik wrote:

>
>
> On 27 February 2024 20:44:50 GMT, John H Palmieri  
> wrote:
> >Sentences like "At the moment you are actively breaking down the precious 
> >project fabric, all in the name of you having your way" are personal 
> >attacks. Please stop.
>
> Blocking on GitHub members of the project is not a personal attack? 
> Of course it is.
>
>
> >
> >On Tuesday, February 27, 2024 at 12:36:44 PM UTC-8 Dima Pasechnik wrote:
> >
> >>
> >>
> >> On 27 February 2024 19:37:31 GMT, Matthias Koeppe  
>
> >> wrote:
> >> >On Tuesday, February 27, 2024 at 10:50:55 AM UTC-8 John H Palmieri 
> wrote:
> >> >
> >> >A pretty safe second choice would be to have "make download" also 
> >> download 
> >> >the relevant files for pip installation and tell pip where to find 
> them. 
> >> If 
> >> >we implemented this second choice [...]
> >> >
> >> >
> >> >The problem is that such tooling, even if "trivial", would need to be 
> >> >implemented, tested, and maintained as well. And typically this just 
> does 
> >> >not work when there is no developer who is actually interested in 
> using 
> >> it.
> >>
> >> It is a largely artificially invented, by you, problem, to shoot my 
> >> proposal down. Besides, these tools are trivial to build and maintain, 
> much 
> >> easier than your ever growing and breaking maze of packages we don't 
> even 
> >> need to vendor.
> >>
> >> At the moment you are actively breaking down the precious project 
> fabric, 
> >> all in the name of you having your way: 
> >>
> >> you blocked me (without bothering yo even tell me) and perhaps other 
> >> developers on GitHub, meaning that you effectively want to shut me up.
> >> (Well, I had no other choice but to block you too, as a countermeasure; 
> I 
> >> installed this block about 12:00 GMT, today.)
> >>
> >> Of course it's easy to skip this message. But tomorrow it might be you 
> who 
> >> Matthias might block, for disagreements with him.
> >> Why is this tolerated? This is a naked attempt to shut down the 
> opposition.
> >>
> >>
> >> >
> >> >We are better off with improving the tooling that we already know 
> *will* 
> >> >continue to be used: Namely the tooling for creating and maintaining 
> our 
> >> >metadata in build/pkgs.
> >>
> >> Or it will be discarded as useless, because doing things the way 
> projects 
> >> like scipy do is better.
> >>
> >> Your package tooling is makework, repeating with worse tools what 
> already 
> >> is done by Conda, Homebrew, Linux distros, etc. We are mainly a maths 
> >> project, not a distro project. Let us stay this way, and actually do 
> more 
> >> maths and less distro-like stuff.
> >>
> >> Dima
> >>
> >>
> >> > Issues such as:
> >> >- https://github.com/sagemath/sage/issues/36356, 
> >> >- https://github.com/sagemath/sage/pull/37322, 
> >> >- https://github.com/sagemath/sage/issues/37323, 
> >> >- https://github.com/sagemath/sage/issues/37314
> >> >
> >>
> >
>

-- 
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/3f85faf4-840a-4965-bd81-797f2733843fn%40googlegroups.com.

Re: [sage-devel] Re: [Proposal] allow standard packages to be pip packages, reduce source tarball size

[John H Palmieri]

Sentences like "At the moment you are actively breaking down the precious 
project fabric, all in the name of you having your way" are personal 
attacks. Please stop.

On Tuesday, February 27, 2024 at 12:36:44 PM UTC-8 Dima Pasechnik wrote:

>
>
> On 27 February 2024 19:37:31 GMT, Matthias Koeppe  
> wrote:
> >On Tuesday, February 27, 2024 at 10:50:55 AM UTC-8 John H Palmieri wrote:
> >
> >A pretty safe second choice would be to have "make download" also 
> download 
> >the relevant files for pip installation and tell pip where to find them. 
> If 
> >we implemented this second choice [...]
> >
> >
> >The problem is that such tooling, even if "trivial", would need to be 
> >implemented, tested, and maintained as well. And typically this just does 
> >not work when there is no developer who is actually interested in using 
> it.
>
> It is a largely artificially invented, by you, problem, to shoot my 
> proposal down. Besides, these tools are trivial to build and maintain, much 
> easier than your ever growing and breaking maze of packages we don't even 
> need to vendor.
>
> At the moment you are actively breaking down the precious project fabric, 
> all in the name of you having your way: 
>
> you blocked me (without bothering yo even tell me) and perhaps other 
> developers on GitHub, meaning that you effectively want to shut me up.
> (Well, I had no other choice but to block you too, as a countermeasure; I 
> installed this block about 12:00 GMT, today.)
>
> Of course it's easy to skip this message. But tomorrow it might be you who 
> Matthias might block, for disagreements with him.
> Why is this tolerated? This is a naked attempt to shut down the opposition.
>
>
> >
> >We are better off with improving the tooling that we already know *will* 
> >continue to be used: Namely the tooling for creating and maintaining our 
> >metadata in build/pkgs.
>
> Or it will be discarded as useless, because doing things the way projects 
> like scipy do is better.
>
> Your package tooling is makework, repeating with worse tools what already 
> is done by Conda, Homebrew, Linux distros, etc. We are mainly a maths 
> project, not a distro project. Let us stay this way, and actually do more 
> maths and less distro-like stuff.
>
> Dima
>
>
> > Issues such as:
> >- https://github.com/sagemath/sage/issues/36356, 
> >- https://github.com/sagemath/sage/pull/37322, 
> >- https://github.com/sagemath/sage/issues/37323, 
> >- https://github.com/sagemath/sage/issues/37314
> >
>

-- 
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/15220b4c-09f8-4408-9152-816ef45b4261n%40googlegroups.com.

[sage-devel] Re: [Proposal] allow standard packages to be pip packages, reduce source tarball size

[John H Palmieri]

Regarding the proposal to allow standard packages to be pip packages, no 
one really knows how much people rely on the all-in-one tarball that we 
currently distribute. No one really knows how often the "make download" 
option is used for people who just clone the git repo and want to do all of 
their downloads at once. Since we don't know, the absolute safest course of 
action is to not change anything, but maybe that's too conservative. A 
pretty safe second choice would be to have "make download" also download 
the relevant files for pip installation and tell pip where to find them. If 
we implemented this second choice, I would support this aspect of Dima's 
proposal.

My impression from Dima's posts is that he would like us to frequently not 
provide version information for pip packages. Here are some of my thoughts:

As Nathan points out, this will likely lead to instability. Someone will 
upgrade some component, and most of the time that will be fine, but 
occasionally it will break something on some platform, and it could be 
annoying to track down the cause. If this leads to Sage failing to build, 
that's not great, but it would be *far worse* if Sage built and ran but 
produced some mathematically incorrect answers. Being able to control all 
of the versions means that our doctests are pretty robust. If we really 
want to go down the road of unpinning version requirements, I propose that 
we *always* pin version requirements for the mathematical components of 
Sage. If Jupyter or Sphinx doesn't work right, it doesn't affect the 
mathematics, but if linbox or pari don't work right (or ore_algebra, if you 
want a pip package), people could be getting different answers on different 
platforms and we might not know about it for a while. To maintain the 
mathematical integrity of the project, we should keep very careful control 
of the mathematical components of Sage.


On Saturday, February 24, 2024 at 3:40:02 PM UTC-8 Matthias Koeppe wrote:

> On Monday, February 12, 2024 at 6:42:07 PM UTC-8 Matthias Koeppe wrote:
>
> On Monday, February 12, 2024 at 3:52:29 PM UTC-8 Matthias Koeppe wrote:
>
>
> *Proposed action items: *
> *A.* Change https://github.com/sagemath/sage/blob/develop/README.md so 
> that "git clone" is described as the primary way to obtain the Sage 
> sources. That the big release tarball is available can be a footnote in the 
> Installation Guide (
> https://deploy-livedoc--sagemath.netlify.app/html/en/installation/source#installation-steps)
>  
> for the limited no-internet connectivity use case.
>
>
> That's now https://github.com/sagemath/sage/pull/37309 (needs review)
>
>
> Thanks for all comments on the PR. Ready for final review. 
>  
>
>  *B. *Likewise, get rid of all of these "Download Sage source code" pages 
> (https://www.sagemath.org/download-source.html, 
> https://www.sagemath.org/download-latest.html), mirror selection, etc. 
> from the Sage website. 
>
> That's now https://github.com/sagemath/website/pull/466
>
>
> This one has already been merged, thanks, Harald! 
> The "Download" menu no longer sends people to the tarball download pages. 
> The pages are, of course, still there, and links from the installation 
> guide point to them.
>
> [image: Screenshot 2024-02-24 at 3.34.47 PM.png]
>
> On Tuesday, February 20, 2024 at 6:44:32 PM UTC-8 Matthias Koeppe wrote:
>
> On Monday, February 19, 2024 at 12:09:54 PM UTC-8 Matthias Koeppe wrote:
>
> Prompted by the discussion of space use on the *local machines* of users 
> and developers, I propose another item in addition to A and B:
>
> *C. Advertise use of "git worktree" and recommend symlinking the 
> "upstream" directory.* For testing a new release when you have an 
> existing clone of the repository, using "git clone" another time is 
> overkill as it creates another copy of the .git directory. And there is no 
> point in having multiple copies of the "upstream" directory, as the 
> filenames of the tarballs change whenever the contents change.
>
>
> That's now https://github.com/sagemath/sage/pull/37411 (needs review)
>
>
> This one has been positively reviewed. Thanks, Lorenz! 
>
>

-- 
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/b448c1da-eb22-4402-aea7-09bec2ab88e9n%40googlegroups.com.

Re: [sage-devel] Re: Unload "blocker" label

[John H Palmieri]

(and Tobias also proposed in https://github.com/sagemath/sage/issues/37428)

On Monday, February 26, 2024 at 5:05:56 PM UTC-8 John H Palmieri wrote:

> I think that usage (1) is the correct use of "blocker," and usage (3) is 
> not. Usage (2) should have a new name, as Vincent proposes. Failing that, 
> this new use of "blocker" must be documented in 
> https://doc.sagemath.org/html/en/developer/review.html.
>
> On Monday, February 26, 2024 at 4:21:58 PM UTC-8 Kwankyu Lee wrote:
>
>> On Tuesday, February 27, 2024 at 2:43:18 AM UTC+9 Vincent Delecroix wrote:
>>
>> In that case, let me do a proposal. 
>>
>> Introduce a new label distinct from "blocker" for
>>
>> usage 2: PRs that should be merged temporarily before CI tests run
>>
>>
>> I meant by "merged temporarily" the "CI fixes" in Matthias' explanation:  
>>
>>- *Within the release candidate stage,* developers who mark a PR as a 
>>"blocker" so that it be merged in the upcoming stable release need to 
>> know 
>>whether their blocker PR will be conflicting with other blockers (= 
>>candidates for merging in the next rc). Having the "blocker" label double 
>>as the "CI fixes" trigger takes care of this.
>>
>> So blocker PRs get the chance to be tested together before the release by 
>> the "CI fixes" mechanism. Thus "usage 1" and "usage 2" are connected. 
>> Having distinct labels for them does not reflect the connection.
>>
>> I propose (as this discussion is a place to give proposals :-) to give 
>> "the chance to be tested together" only to blocker PRs with "positive 
>> review". This slightly separates "usage 1" and "usage 2". This proposal was 
>> suggested when the "CI fixes" mechanism was introduced, and can be 
>> activated easily.
>>
>>  
>>  
>>  
>>
>

-- 
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/667ef622-5c51-4591-b041-1782061dca8bn%40googlegroups.com.

Re: [sage-devel] Re: Unload "blocker" label

[John H Palmieri]

I think that usage (1) is the correct use of "blocker," and usage (3) is 
not. Usage (2) should have a new name, as Vincent proposes. Failing that, 
this new use of "blocker" must be documented in 
https://doc.sagemath.org/html/en/developer/review.html.

On Monday, February 26, 2024 at 4:21:58 PM UTC-8 Kwankyu Lee wrote:

> On Tuesday, February 27, 2024 at 2:43:18 AM UTC+9 Vincent Delecroix wrote:
>
> In that case, let me do a proposal. 
>
> Introduce a new label distinct from "blocker" for
>
> usage 2: PRs that should be merged temporarily before CI tests run
>
>
> I meant by "merged temporarily" the "CI fixes" in Matthias' explanation:  
>
>- *Within the release candidate stage,* developers who mark a PR as a 
>"blocker" so that it be merged in the upcoming stable release need to know 
>whether their blocker PR will be conflicting with other blockers (= 
>candidates for merging in the next rc). Having the "blocker" label double 
>as the "CI fixes" trigger takes care of this.
>
> So blocker PRs get the chance to be tested together before the release by 
> the "CI fixes" mechanism. Thus "usage 1" and "usage 2" are connected. 
> Having distinct labels for them does not reflect the connection.
>
> I propose (as this discussion is a place to give proposals :-) to give 
> "the chance to be tested together" only to blocker PRs with "positive 
> review". This slightly separates "usage 1" and "usage 2". This proposal was 
> suggested when the "CI fixes" mechanism was introduced, and can be 
> activated easily.
>
>  
>  
>  
>

-- 
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/001204a7-53fe-43ec-8be6-d2dbdd15b69dn%40googlegroups.com.

Re: [sage-devel] Re: [Proposal] allow standard packages to be pip packages, reduce source tarball size

[John H Palmieri]

You're right, plus I was confusing "./bootstrap -d" (which is run by "make 
configure") with "./bootstrap -D" which forces the download.

On Monday, February 19, 2024 at 3:17:11 PM UTC-8 Matthias Koeppe wrote:

> On Monday, February 19, 2024 at 3:09:55 PM UTC-8 John H Palmieri wrote:
>
> By the way, I just cloned the Sage repo and ran "make configure", which 
> runs `./bootstrap`. The upstream directory is empty after that.
>
>
> You probably have autoconf/automake/... installed. In this case, it just 
> uses them to build the configure script. Downloading is a fallback that is 
> used when these "bootstrapping prerequisites" are not installed.
>
>
>

-- 
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/ed16aa03-8b75-4dd1-bf74-567882d16646n%40googlegroups.com.

Re: [sage-devel] Re: [Proposal] allow standard packages to be pip packages, reduce source tarball size

[John H Palmieri]

If we keep a "configure" tarball in each separate Sage installation but 
they share the rest of "upstream", then we save a lot of space and a lot of 
downloading. A workflow like

% make configure
% configure --with-lots-of-options
% make

would be familiar and unchanged from the status quo when working with the 
git clone. Currently users don't have to run `./bootstrap` manually just to 
build Sage, and it would be nice to keep it this way.

By the way, I just cloned the Sage repo and ran "make configure", which 
runs `./bootstrap`. The upstream directory is empty after that. If it's 
getting used for temporary storage for this tarball, that can be done 
elsewhere (.upstream.d? config? some temporary directory?).

Another option for the location of a shared "upstream" would be Yet Another 
Environment Variable.

On Monday, February 19, 2024 at 2:41:11 PM UTC-8 Dima Pasechnik wrote:

> On Mon, Feb 19, 2024 at 10:29 PM Matthias Koeppe  
> wrote:
>
>> An option to "./configure" could work too, except that the "bootstrap" 
>> phase already downloads the "configure" tarball into that directory.
>
>
> an option to ./bootstrap then would be logical
>  
>
>>
>> Another possible direction: I've been thinking about creating a "./sage 
>> worktree" command, see https://github.com/sagemath/sage/issues/34744
>>
>>
>> On Monday, February 19, 2024 at 2:24:40 PM UTC-8 John H Palmieri wrote:
>>
>>> Regarding symlinking the upstream directory: instead or in addition, 
>>> what about an option to `./configure` for the location of that directory?
>>>
>>>
>>> On Monday, February 19, 2024 at 12:09:54 PM UTC-8 Matthias Koeppe wrote:
>>>
>>>> Prompted by the discussion of space use on the *local machines* of 
>>>> users and developers, I propose another item in addition to A and B:
>>>>
>>>> *C. Advertise use of "git worktree" and recommend symlinking the 
>>>> "upstream" directory.* For testing a new release when you have an 
>>>> existing clone of the repository, using "git clone" another time is 
>>>> overkill as it creates another copy of the .git directory. And there is no 
>>>> point in having multiple copies of the "upstream" directory, as the 
>>>> filenames of the tarballs change whenever the contents change.
>>>>
>>>> On Monday, February 19, 2024 at 11:42:01 AM UTC-8 John H Palmieri wrote:
>>>>
>>>> This (A and B below) has the advantage of being quite explicit. The 
>>>> original proposal
>>>>
>>>> 1) allow standard packages to be pip packages 
>>>>
>>>> 2) drop the contents of upstream/ from the Sage source tarballs. 
>>>>
>>>> sounds explicit, but the more the discussion goes on, the more I feel 
>>>> that there are hidden pieces. Does the proposal also mean removing version 
>>>> restrictions and all of the other claimed maintenance burden for various 
>>>> components of Sage? 
>>>>
>>>> Regarding item (2): if I clone the github repository, there is no 
>>>> upstream directory at the start, but after building Sage, it ends up being 
>>>> almost as large as in the current tarballs. (This is on OS X with a lot of 
>>>> homebrew packages installed.) So how much savings are we actually talking 
>>>> about? (Maybe it's not savings for the end user that are important, so 
>>>> *what* are we saving? Disk space on the mirrors?) Dima, can you please 
>>>> provide data? If we convert (according to (1)) to pip packages, those 
>>>> still 
>>>> need to be downloaded, and while they may not end up in "upstream" — I 
>>>> don't actually know how they work — don't they still take up disk space? 
>>>> So 
>>>> again, how much savings are we talking about? Please provide data.
>>>>
>>>> By the way, the git clone yields a package that is 616M on my machine. 
>>>> A good chunk of that is the .git directory. Are you proposing that we do 
>>>> not distribute this? (A recent beta tarball is 1.4G, unpacked 1.6G.)
>>>>
>>>> Regarding item (1): can you provide a list of packages that would 
>>>> become pip packages? Or describe how you would come up with a list?
>>>>
>>>>
>>>> On Monday, February 12, 2024 at 3:52:29 PM UTC-8 Matthias Koeppe wrote:
>>>>
>>>> I'll now offer:
>>>>
>>>> *

[sage-devel] Re: [Proposal] allow standard packages to be pip packages, reduce source tarball size

[John H Palmieri]

Regarding symlinking the upstream directory: instead or in addition, what 
about an option to `./configure` for the location of that directory?


On Monday, February 19, 2024 at 12:09:54 PM UTC-8 Matthias Koeppe wrote:

> Prompted by the discussion of space use on the *local machines* of users 
> and developers, I propose another item in addition to A and B:
>
> *C. Advertise use of "git worktree" and recommend symlinking the 
> "upstream" directory.* For testing a new release when you have an 
> existing clone of the repository, using "git clone" another time is 
> overkill as it creates another copy of the .git directory. And there is no 
> point in having multiple copies of the "upstream" directory, as the 
> filenames of the tarballs change whenever the contents change.
>
> On Monday, February 19, 2024 at 11:42:01 AM UTC-8 John H Palmieri wrote:
>
> This (A and B below) has the advantage of being quite explicit. The 
> original proposal
>
> 1) allow standard packages to be pip packages 
>
> 2) drop the contents of upstream/ from the Sage source tarballs. 
>
> sounds explicit, but the more the discussion goes on, the more I feel that 
> there are hidden pieces. Does the proposal also mean removing version 
> restrictions and all of the other claimed maintenance burden for various 
> components of Sage? 
>
> Regarding item (2): if I clone the github repository, there is no upstream 
> directory at the start, but after building Sage, it ends up being almost as 
> large as in the current tarballs. (This is on OS X with a lot of homebrew 
> packages installed.) So how much savings are we actually talking about? 
> (Maybe it's not savings for the end user that are important, so *what* are 
> we saving? Disk space on the mirrors?) Dima, can you please provide data? 
> If we convert (according to (1)) to pip packages, those still need to be 
> downloaded, and while they may not end up in "upstream" — I don't actually 
> know how they work — don't they still take up disk space? So again, how 
> much savings are we talking about? Please provide data.
>
> By the way, the git clone yields a package that is 616M on my machine. A 
> good chunk of that is the .git directory. Are you proposing that we do not 
> distribute this? (A recent beta tarball is 1.4G, unpacked 1.6G.)
>
> Regarding item (1): can you provide a list of packages that would become 
> pip packages? Or describe how you would come up with a list?
>
>
> On Monday, February 12, 2024 at 3:52:29 PM UTC-8 Matthias Koeppe wrote:
>
> I'll now offer:
>
> *Opinion 1. Nobody needs to care in the slightest what the size of that 
> release tarball is. *
>
> In any use cases with internet connectivity, people will be better off by 
> just cloning the git repo, not use the release tarball.
>
> If there are relevant use cases without internet connectivity (I have no 
> opinion to offer on this), then the release tarball has exactly the right 
> contents.
>
> *Proposed action items: *
> *A.* Change https://github.com/sagemath/sage/blob/develop/README.md so 
> that "git clone" is described as the primary way to obtain the Sage 
> sources. That the big release tarball is available can be a footnote in the 
> Installation Guide (
> https://deploy-livedoc--sagemath.netlify.app/html/en/installation/source#installation-steps)
>  
> for the limited no-internet connectivity use case.
>
> *B. *Likewise, get rid of all of these "Download Sage source code" pages (
> https://www.sagemath.org/download-source.html, 
> https://www.sagemath.org/download-latest.html), mirror selection, etc. 
> from the Sage website. 
>
>
> On Sunday, February 11, 2024 at 11:23:42 AM UTC-8 Dima Pasechnik wrote:
>
> Currently the standard packages cannot be pip packages, i.e. we must, in 
> effect, vendor them. This entails an extra effort which is often not 
> needed, in particular as we patch only very few Python packages. 
> Pip packages are on the other hand installed straight from PyPI. 
>
> Good examples of standard packages which can become pip ones are tox, 
> pytest (not yet standard). 
>
>
> The other difference is that by default these packages are not included in 
> the Sage releases source tarball. 
>
> Rather than adding them there I propose to split the upstream/* part of 
> the tarball into something optional - which is represented by a list of 
> files to download, and which is just not needed if you build while 
> connected to the internet. 
>
> This is a huge saving on the tarball size: with upstream/* in, Sage 10.2 
> tarball is 1.3Gb, and without it is smaller than 0.25Gb. 
>
> Note that as William writes, the desire to have 

Re: [sage-devel] Re: [Proposal] allow standard packages to be pip packages, reduce source tarball size

[John H Palmieri]

On Monday, February 19, 2024 at 12:10:49 PM UTC-8 Dima Pasechnik wrote:

On Mon, Feb 19, 2024 at 7:42 PM John H Palmieri wrote:

This (A and B below) has the advantage of being quite explicit. The 
original proposal

1) allow standard packages to be pip packages 

2) drop the contents of upstream/ from the Sage source tarballs. 

sounds explicit, but the more the discussion goes on, the more I feel that 
there are hidden pieces. Does the proposal also mean removing version 
restrictions and all of the other claimed maintenance burden for various 
components of Sage? 


No, this is simply FUD spread by certain parties here. 


You said: "The difference between wheel packages vs pip packages is that 
the latter don't require pre-fetched wheels, and absence of the need for 
package (micro)management." The implication is that changing the package 
management system is, maybe not part of this proposal, but a next step. In 
other words, I'm getting this impression from your words, not by other 
"certain parties."

You said: "My proposal is in fact aimed at reducing the number of pinned 
Sage dependecies, drastically." (You have made similar comments elsewhere 
in this thread.) How does (1) accomplish this? Either I'm missing something 
or you have not spelled everything out in your proposal.

You said '"Allow" does not mean "Make all of the", it should be obvious.'

"Allow" does not cause any changes to happen drastically. So what exactly 
are you proposing to accomplish these drastic changes? If you have a 
roadmap in mind, it would be helpful if you described it.


 

pytest is good example of package which can be elevated to standard, but 
kept pip. In no place my
proposal 1) demands anything done for all packages.



Regarding item (2): if I clone the github repository, there is no upstream 
directory at the start, but after building Sage, it ends up being almost as 
large as in the current tarballs. (This is on OS X with a lot of homebrew 
packages installed.) So how much savings are we actually talking about? 
(Maybe it's not savings for the end user that are important, so *what* are 
we saving? Disk space on the mirrors?) Dima, can you please provide data? 
If we convert (according to (1)) to pip packages, those still need to be 
downloaded, and while they may not end up in "upstream" — I don't actually 
know how they work — don't they still take up disk space? So again, how 
much savings are we talking about? Please provide data.


I am talking about saving space on mirrors, and on bandwidth, by not 
packaging "upstream/".
(as I wrote: This is a huge saving on the tarball size: with upstream/* in, 
Sage 10.2 tarball is 1.3Gb, and without it is smaller than 0.25Gb.)
Local disk space nowadays is cheap, but space on mirrors, and bandwidth, 
don't come free.
(not everyone is on an unlimited internet)

As well, if you don't wipe up your local upstream/, its contents can  be 
reused.
(typically not so many packages are updated with each release after all)

However, as far as I can tell, by default pip package wheels are not stored 
in upstream/.
Perhaps there is an easy way to change this, I don't know.
 
 


By the way, the git clone yields a package that is 616M on my machine. A 
good chunk of that is the .git directory. Are you proposing that we do not 
distribute this? (A recent beta tarball is 1.4G, unpacked 1.6G.) 


Regarding item (1): can you provide a list of packages that would become 
pip packages? Or describe how you would come up with a list?


packages not involved in sagelib directly are good candidates, e.g. pytest, 
tox.
sphinx and jupyterlab are good candidates too, in my limited testing 
experiments.

Dima


On Monday, February 12, 2024 at 3:52:29 PM UTC-8 Matthias Koeppe wrote:

I'll now offer:

*Opinion 1. Nobody needs to care in the slightest what the size of that 
release tarball is. *

In any use cases with internet connectivity, people will be better off by 
just cloning the git repo, not use the release tarball.

If there are relevant use cases without internet connectivity (I have no 
opinion to offer on this), then the release tarball has exactly the right 
contents.

*Proposed action items: *
*A.* Change https://github.com/sagemath/sage/blob/develop/README.md so that 
"git clone" is described as the primary way to obtain the Sage sources. 
That the big release tarball is available can be a footnote in the 
Installation Guide (
https://deploy-livedoc--sagemath.netlify.app/html/en/installation/source#installation-steps)
 
for the limited no-internet connectivity use case.

*B. *Likewise, get rid of all of these "Download Sage source code" pages (
https://www.sagemath.org/download-source.html, 
https://www.sagemath.org/download-latest.html), mirror selection, etc. from 
the Sage website. 


On Sunday, February 11, 2024 at 11:23:42 AM UTC-8 Dima Pasechnik wrote:

Currently the st

[sage-devel] Re: [Proposal] allow standard packages to be pip packages, reduce source tarball size

[John H Palmieri]

This (A and B below) has the advantage of being quite explicit. The 
original proposal

1) allow standard packages to be pip packages 

2) drop the contents of upstream/ from the Sage source tarballs. 

sounds explicit, but the more the discussion goes on, the more I feel that 
there are hidden pieces. Does the proposal also mean removing version 
restrictions and all of the other claimed maintenance burden for various 
components of Sage? 

Regarding item (2): if I clone the github repository, there is no upstream 
directory at the start, but after building Sage, it ends up being almost as 
large as in the current tarballs. (This is on OS X with a lot of homebrew 
packages installed.) So how much savings are we actually talking about? 
(Maybe it's not savings for the end user that are important, so *what* are 
we saving? Disk space on the mirrors?) Dima, can you please provide data? 
If we convert (according to (1)) to pip packages, those still need to be 
downloaded, and while they may not end up in "upstream" — I don't actually 
know how they work — don't they still take up disk space? So again, how 
much savings are we talking about? Please provide data.

By the way, the git clone yields a package that is 616M on my machine. A 
good chunk of that is the .git directory. Are you proposing that we do not 
distribute this? (A recent beta tarball is 1.4G, unpacked 1.6G.)

Regarding item (1): can you provide a list of packages that would become 
pip packages? Or describe how you would come up with a list?


On Monday, February 12, 2024 at 3:52:29 PM UTC-8 Matthias Koeppe wrote:

> I'll now offer:
>
> *Opinion 1. Nobody needs to care in the slightest what the size of that 
> release tarball is. *
>
> In any use cases with internet connectivity, people will be better off by 
> just cloning the git repo, not use the release tarball.
>
> If there are relevant use cases without internet connectivity (I have no 
> opinion to offer on this), then the release tarball has exactly the right 
> contents.
>
> *Proposed action items: *
> *A.* Change https://github.com/sagemath/sage/blob/develop/README.md so 
> that "git clone" is described as the primary way to obtain the Sage 
> sources. That the big release tarball is available can be a footnote in the 
> Installation Guide (
> https://deploy-livedoc--sagemath.netlify.app/html/en/installation/source#installation-steps)
>  
> for the limited no-internet connectivity use case.
>
> *B. *Likewise, get rid of all of these "Download Sage source code" pages (
> https://www.sagemath.org/download-source.html, 
> https://www.sagemath.org/download-latest.html), mirror selection, etc. 
> from the Sage website. 
>
>
> On Sunday, February 11, 2024 at 11:23:42 AM UTC-8 Dima Pasechnik wrote:
>
>> Currently the standard packages cannot be pip packages, i.e. we must, in 
>> effect, vendor them. This entails an extra effort which is often not 
>> needed, in particular as we patch only very few Python packages. 
>> Pip packages are on the other hand installed straight from PyPI. 
>>
>> Good examples of standard packages which can become pip ones are tox, 
>> pytest (not yet standard). 
>>
>>
>> The other difference is that by default these packages are not included 
>> in the Sage releases source tarball. 
>>
>> Rather than adding them there I propose to split the upstream/* part of 
>> the tarball into something optional - which is represented by a list of 
>> files to download, and which is just not needed if you build while 
>> connected to the internet. 
>>
>> This is a huge saving on the tarball size: with upstream/* in, Sage 10.2 
>> tarball is 1.3Gb, and without it is smaller than 0.25Gb. 
>>
>> Note that as William writes, the desire to have Sage buildable without an 
>> internet connection was a requirement by a past Sage funder, gone about 10 
>> years ago. Thus there's no longer an obligation to have this option. 
>> I am not aware of a similar to Sage which provides tarballs allowing for 
>> an offline build. 
>>
>> Thus, I would like to call a vote on these two topics: 
>>
>> 1) allow standard packages to be pip packages 
>>
>> 2) drop the contents of upstream/ from the Sage source tarballs. 
>>
>>
>> --- 
>> 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/0a3c1c0b-ed3f-41eb-ab4a-5235432475dbn%40googlegroups.com.

Re: [sage-devel] Re: [Proposal] allow standard packages to be pip packages, reduce source tarball size

[John H Palmieri]

What does this (a discussion of how Sage specifies version restrictions) 
have to do with the proposal? If it's relevant, that was not clear in the 
original proposal, so please clarify. It sounds like you might be proposing 
removing version checks on many of the packages Sage uses, or at least 
that's a conclusion I might draw from your critique of the amount of 
maintenance for Sage packages. Or maybe you are proposing redesigning the 
version specification system? In any case, it wasn't stated as part of the 
original proposal, so I don't know what was intended. If it is not relevant 
to the proposal, let's drop this part of the discussion.

I would also suggest dropping the question of whether we're "vendoring." 
The proposal clearly says that we should stop distributing the tarballs in 
the upstream directory, so whatever we call it, that part is clear.

(Maybe by "vendoring" you meant the combination of including the tarballs 
and the maintenance on the allowed versions, or maybe just including the 
tarballs, or maybe something else. The word "vendoring" does not seem to be 
helpful, so instead spelling out exactly what's meant for Sage could be 
helpful, at least if you meant more than just removing "upstream".)

On Monday, February 12, 2024 at 3:07:38 PM UTC-8 Dima Pasechnik wrote:

> On Mon, Feb 12, 2024 at 10:01 PM Matthias Koeppe
>  wrote:
> >
> > On Monday, February 12, 2024 at 10:49:04 AM UTC-8 Dima Pasechnik wrote:
> >
> > requirements.txt might as well specify the range, and this is used too 
> e.g.
> >
> > build/pkgs/phitigra/requirements.txt has
> > phitigra>=0.2.6
> >
> >
> > Yes, as I said in 
> https://groups.google.com/g/sage-devel/c/5kmxaw105lg/m/9rF77fvFAAAJ, 
> ""Pip" packages can either be pinned to a specific version, or set 
> acceptable version ranges, or be entirely unconstrained. This is set in the 
> file requirements.txt in the package directory."
> >
> > So this is all [...] confusing
> >
> >
> > That's why I'm taking the time to explain it clearly for the benefit of 
> everyone.
>
> I am sorry: I claimed that Sage has about 5 different ways to
> specify/restrict versions of its packages,
> and this makes it hugely confusing.
> You disagreed, but now you say that it needs an explanation.
>
> What really needs an explanation is how we ever went this far on a
> garden path. :-)
>

-- 
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/b89c5e20-0fb0-4c92-8333-4f1766a2bfa1n%40googlegroups.com.

[Ubuntu-x-swat] [Bug 2051875] [NEW] monitor goes to sleep (power save) mode as soon as the system attempts to display the graphical login screen. Attempting to switch to a character console wakes the

[John H Gray]

Public bug reported:

https://askubuntu.com/questions/1500676/is-there-a-solution-
for-22-04-and-kernel-6-5-0-14-or-6-5-0-15-22-04-for-users?noredirect=1


I'm running 22.04 LTS with an Asus NVidia GeForce GT 730.
I'm using the Ubuntu provided video driver (Nouveau).

Since upgrading my kernel to 6.5, I notice that my monitor goes to sleep
(power save) mode as soon as the system attempts to display the
graphical login screen. Attempting to switch to a character console
wakes the monitor but I still have a blank screen. Switching back to the
graphical login screen puts the monitor back to sleep.

My current solution is to use my previous 6.2 kernel.

I've been reading in the forums about users having problems with
recompiling their driver source, gcc version mismatches v11 (6.2 kernel)
vs v12 (6.5 kernel) and some driver source incompatibilities with the
new compiler.

I'm wondering how soon users might expect a fix for the stock driver or if we 
should expect a fix?
I've got a 2nd Linux systems also 22.04 with a GT 610 that has no issues with 
the latest 6.5 kernel.

The command

dkms status

returns nothing. And

apt-cache policy gcc-12

returns

gcc-12:
Installed: (none)
Candidate: 12.3.0-1ubuntu1~22.04

ProblemType: Bug
DistroRelease: Ubuntu 22.04
Package: xserver-xorg-video-nouveau 1:1.0.17-2build1
ProcVersionSignature: Ubuntu 6.5.0-15.15~22.04.1-generic 6.5.3
Uname: Linux 6.5.0-15-generic x86_64
ApportVersion: 2.20.11-0ubuntu82.5
Architecture: amd64
BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
CasperMD5CheckResult: unknown
CompositorRunning: None
CurrentDmesg: Error: command ['pkexec', 'dmesg'] failed with exit code 127: 
Error creating textual authentication agent: Error opening current controlling 
terminal for the process (`/dev/tty'): No such device or address
Date: Wed Jan 31 11:18:16 2024
DistUpgraded: Fresh install
DistroCodename: jammy
DistroVariant: ubuntu
ExtraDebuggingInterest: Yes, if not too technical
GraphicsCard:
 NVIDIA Corporation GK208B [GeForce GT 730] [10de:1287] (rev a1) (prog-if 00 
[VGA controller])
   Subsystem: ASUSTeK Computer Inc. GK208B [GeForce GT 730] [1043:881a]
 ASPEED Technology, Inc. ASPEED Graphics Family [1a03:2000] (rev 21) (prog-if 
00 [VGA controller])
   Subsystem: Gigabyte Technology Co., Ltd ASPEED Graphics Family [1458:2000]
InstallationDate: Installed on 2023-05-05 (271 days ago)
InstallationMedia: Ubuntu 22.04.1 LTS "Jammy Jellyfish" - Release amd64 
(20220809.1)
MachineType: Cirrascale VB1416
ProcEnviron:
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-6.5.0-15-generic 
root=UUID=8138fb3d-3187-4185-9154-470cb45cf4c4 ro quiet splash vt.handoff=7
SourcePackage: xserver-xorg-video-nouveau
UpgradeStatus: No upgrade log present (probably fresh install)
acpidump: Error: command ['pkexec', '/usr/share/apport/dump_acpi_tables.py'] 
failed with exit code 127: Error creating textual authentication agent: Error 
opening current controlling terminal for the process (`/dev/tty'): No such 
device or address
dmi.bios.date: 06/26/2018
dmi.bios.release: 4.6
dmi.bios.vendor: GIGABYTE
dmi.bios.version: R17
dmi.board.asset.tag: 01234567890123456789AN
dmi.board.name: GA-7PESH2
dmi.board.vendor: GIGABYTE
dmi.board.version: 0001
dmi.chassis.asset.tag: 01234567890123456789AN
dmi.chassis.type: 17
dmi.chassis.vendor: Cirrascale
dmi.chassis.version: 240272-101
dmi.modalias: 
dmi:bvnGIGABYTE:bvrR17:bd06/26/2018:br4.6:svnCirrascale:pnVB1416:pvr0002:rvnGIGABYTE:rnGA-7PESH2:rvr0001:cvnCirrascale:ct17:cvr240272-101:sku:
dmi.product.family: GIGABYTE Server
dmi.product.name: VB1416
dmi.product.version: 0002
dmi.sys.vendor: Cirrascale
version.compiz: compiz N/A
version.libdrm2: libdrm2 2.4.113-2~ubuntu0.22.04.1
version.libgl1-mesa-dri: libgl1-mesa-dri 23.0.4-0ubuntu1~22.04.1
version.libgl1-mesa-glx: libgl1-mesa-glx N/A
version.xserver-xorg-core: xserver-xorg-core 2:21.1.4-2ubuntu1.7~22.04.8
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A
version.xserver-xorg-video-ati: xserver-xorg-video-ati N/A
version.xserver-xorg-video-intel: xserver-xorg-video-intel N/A
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.17-2build1

** Affects: xserver-xorg-video-nouveau (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug jammy ubuntu

-- 
You received this bug notification because you are a member of Ubuntu-X,
which is subscribed to xserver-xorg-video-nouveau in Ubuntu.
https://bugs.launchpad.net/bugs/2051875

Title:
  monitor goes to sleep (power save) mode as soon as the system attempts
  to display the graphical login screen. Attempting to switch to a
  character console wakes the monitor but I still have a blank screen.
  Switching back to the graphical login screen puts the monitor back to
  sleep.

To manage notifications about this bug go to:

[Desktop-packages] [Bug 2051875] [NEW] monitor goes to sleep (power save) mode as soon as the system attempts to display the graphical login screen. Attempting to switch to a character console wakes t

[John H Gray]

Public bug reported:

https://askubuntu.com/questions/1500676/is-there-a-solution-
for-22-04-and-kernel-6-5-0-14-or-6-5-0-15-22-04-for-users?noredirect=1


I'm running 22.04 LTS with an Asus NVidia GeForce GT 730.
I'm using the Ubuntu provided video driver (Nouveau).

Since upgrading my kernel to 6.5, I notice that my monitor goes to sleep
(power save) mode as soon as the system attempts to display the
graphical login screen. Attempting to switch to a character console
wakes the monitor but I still have a blank screen. Switching back to the
graphical login screen puts the monitor back to sleep.

My current solution is to use my previous 6.2 kernel.

I've been reading in the forums about users having problems with
recompiling their driver source, gcc version mismatches v11 (6.2 kernel)
vs v12 (6.5 kernel) and some driver source incompatibilities with the
new compiler.

I'm wondering how soon users might expect a fix for the stock driver or if we 
should expect a fix?
I've got a 2nd Linux systems also 22.04 with a GT 610 that has no issues with 
the latest 6.5 kernel.

The command

dkms status

returns nothing. And

apt-cache policy gcc-12

returns

gcc-12:
Installed: (none)
Candidate: 12.3.0-1ubuntu1~22.04

ProblemType: Bug
DistroRelease: Ubuntu 22.04
Package: xserver-xorg-video-nouveau 1:1.0.17-2build1
ProcVersionSignature: Ubuntu 6.5.0-15.15~22.04.1-generic 6.5.3
Uname: Linux 6.5.0-15-generic x86_64
ApportVersion: 2.20.11-0ubuntu82.5
Architecture: amd64
BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
CasperMD5CheckResult: unknown
CompositorRunning: None
CurrentDmesg: Error: command ['pkexec', 'dmesg'] failed with exit code 127: 
Error creating textual authentication agent: Error opening current controlling 
terminal for the process (`/dev/tty'): No such device or address
Date: Wed Jan 31 11:18:16 2024
DistUpgraded: Fresh install
DistroCodename: jammy
DistroVariant: ubuntu
ExtraDebuggingInterest: Yes, if not too technical
GraphicsCard:
 NVIDIA Corporation GK208B [GeForce GT 730] [10de:1287] (rev a1) (prog-if 00 
[VGA controller])
   Subsystem: ASUSTeK Computer Inc. GK208B [GeForce GT 730] [1043:881a]
 ASPEED Technology, Inc. ASPEED Graphics Family [1a03:2000] (rev 21) (prog-if 
00 [VGA controller])
   Subsystem: Gigabyte Technology Co., Ltd ASPEED Graphics Family [1458:2000]
InstallationDate: Installed on 2023-05-05 (271 days ago)
InstallationMedia: Ubuntu 22.04.1 LTS "Jammy Jellyfish" - Release amd64 
(20220809.1)
MachineType: Cirrascale VB1416
ProcEnviron:
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-6.5.0-15-generic 
root=UUID=8138fb3d-3187-4185-9154-470cb45cf4c4 ro quiet splash vt.handoff=7
SourcePackage: xserver-xorg-video-nouveau
UpgradeStatus: No upgrade log present (probably fresh install)
acpidump: Error: command ['pkexec', '/usr/share/apport/dump_acpi_tables.py'] 
failed with exit code 127: Error creating textual authentication agent: Error 
opening current controlling terminal for the process (`/dev/tty'): No such 
device or address
dmi.bios.date: 06/26/2018
dmi.bios.release: 4.6
dmi.bios.vendor: GIGABYTE
dmi.bios.version: R17
dmi.board.asset.tag: 01234567890123456789AN
dmi.board.name: GA-7PESH2
dmi.board.vendor: GIGABYTE
dmi.board.version: 0001
dmi.chassis.asset.tag: 01234567890123456789AN
dmi.chassis.type: 17
dmi.chassis.vendor: Cirrascale
dmi.chassis.version: 240272-101
dmi.modalias: 
dmi:bvnGIGABYTE:bvrR17:bd06/26/2018:br4.6:svnCirrascale:pnVB1416:pvr0002:rvnGIGABYTE:rnGA-7PESH2:rvr0001:cvnCirrascale:ct17:cvr240272-101:sku:
dmi.product.family: GIGABYTE Server
dmi.product.name: VB1416
dmi.product.version: 0002
dmi.sys.vendor: Cirrascale
version.compiz: compiz N/A
version.libdrm2: libdrm2 2.4.113-2~ubuntu0.22.04.1
version.libgl1-mesa-dri: libgl1-mesa-dri 23.0.4-0ubuntu1~22.04.1
version.libgl1-mesa-glx: libgl1-mesa-glx N/A
version.xserver-xorg-core: xserver-xorg-core 2:21.1.4-2ubuntu1.7~22.04.8
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A
version.xserver-xorg-video-ati: xserver-xorg-video-ati N/A
version.xserver-xorg-video-intel: xserver-xorg-video-intel N/A
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.17-2build1

** Affects: xserver-xorg-video-nouveau (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug jammy ubuntu

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to xserver-xorg-video-nouveau in Ubuntu.
https://bugs.launchpad.net/bugs/2051875

Title:
  monitor goes to sleep (power save) mode as soon as the system attempts
  to display the graphical login screen. Attempting to switch to a
  character console wakes the monitor but I still have a blank screen.
  Switching back to the graphical login screen puts the monitor back to
  sleep.

Status in xserver-xorg-video-nouveau package in Ubuntu:
  New

Bug description:
  

Re: [sage-support] Re: sage 10.3.b2 build problem on OSX 12.7.1

[John H Palmieri]

Another quick solution (cherry-picked from the PR I mentioned) would be to 
change the first line of build/pkgs/editables/dependencies from 

 | $(PYTHON_TOOLCHAIN) $(PYTHON)

to 

 | flit_core $(PYTHON)


On Saturday, December 16, 2023 at 6:45:44 AM UTC-8 Heiko Knospe wrote:

> Hi, 
>
> same build problem with flit_core for sage 10.3.b2 on Debian 11:
>
> [editables-0.5] Thread model: posix
>
> [editables-0.5] Supported LTO compression algorithms: zlib zstd
>
> [editables-0.5] gcc version 10.2.1 20210110 (Debian 10.2.1-6) 
>
> [editables-0.5] 
>
> [editables-0.5] Package 'editables' is currently not installed
>
> [editables-0.5] No legacy uninstaller found for 'editables'; nothing to do
>
> [editables-0.5] Installing editables-0.5
>
> [editables-0.5] Looking in links: 
> /home/xxx/sage/local/var/lib/sage/venv-python3.9/var/lib/sage/wheels
>
> [editables-0.5] Processing 
> /home/xxx/sage/local/var/lib/sage/venv-python3.9/var/tmp/sage/build/editables-0.5/src
>
> [editables-0.5]   Installing build dependencies: started
>
> [editables-0.5]   Running command pip subprocess to install build 
> dependencies
>
> [editables-0.5]   Looking in links: 
> /home/xxx/sage/local/var/lib/sage/venv-python3.9/var/lib/sage/wheels
>
> [editables-0.5]   ERROR: Could not find a version that satisfies the 
> requirement flit_core>=3.3 (from versions: none)
>
> [editables-0.5]   ERROR: No matching distribution found for flit_core>=3.3
>
> [editables-0.5]   error: subprocess-exited-with-error
>
> [editables-0.5]   
>
> [editables-0.5]   × pip subprocess to install build dependencies did not 
> run successfully.
>
> [editables-0.5]   │ exit code: 1
>
> [editables-0.5]   ╰─> See above for output.
>
> My (quick and dirty) workaround was to copy 
> flit_core-3.9.0-py3-none-any.whl 
> <https://www.piwheels.org/simple/flit-core/flit_core-3.9.0-py3-none-any.whl#sha256=e5b2a84881cf1f40eb5b0115e1d3a429765e0f43743b79e871352bb8e0c95952>
>  from https://www.piwheels.org/project/flit-core/ to 
> local/var/lib/sage/venv-python3.9/var/lib/sage/wheels. Then compiling sage 
> works and flit_core-3.9.0 is installed.
>
> - Heiko
>
> David Joyner schrieb am Samstag, 16. Dezember 2023 um 12:40:00 UTC+1:
>
>> On Fri, Dec 15, 2023 at 3:04 PM John H Palmieri  
>> wrote:
>>
>>> In sage-release, Matthias pointed to missing dependencies for editables, 
>>> fixed in https://github.com/sagemath/sage/pull/36885. Maybe you can 
>>> just do "make flit_core" (to build the missing dependency) and then "make".
>>>
>>
>> That works, thanks!!
>>
>> BTW, on startup I got this:
>>
>> ./sage
>>
>> ┌┐
>>
>> │ SageMath version 10.3.beta2, Release Date: 2023-12-13  │
>>
>> │ Using Python 3.11.1. Type "help()" for help.   │
>>
>> └┘
>>
>> ┏┓
>>
>> ┃ Warning: this is a prerelease version, and it may be unstable. ┃
>>
>> ┗┛
>>
>> /Users/davidjoyner/sagefiles/sage-10.3.beta2/local/var/lib/sage/venv-python3.11.1/lib/python3.11/site-packages/prompt_toolkit/application/application.py:988:
>>  
>> DeprecationWarning: There is no current event loop
>>   loop = asyncio.get_event_loop()
>>
>> Seems to be working fine though.
>>
>> Thanks again, John.
>>  
>>
>>>
>>>
>>> On Friday, December 15, 2023 at 10:52:10 AM UTC-8 David Joyner wrote:
>>>
>>>> Hi:
>>>>
>>>> I tried to compile sage and got this:
>>>>
>>>> The following package(s) may have failed to build (not necessarily
>>>>
>>>> during this run of 'make all-start'):
>>>>
>>>>
>>>> * package: editables-0.5
>>>>
>>>>   last build time: Dec 15 10:48
>>>>
>>>>   log file:
>>>> /Users/davidjoyner/sagefiles/sage-10.3.beta2/logs/pkgs/editables-0.5.log
>>>>
>>>>
>>>> The corresponding log is attached.
>>>>
>>>>
>>>> Does anyone have any suggestions on how to fix this?
>>>>
>>>> - David
>>>>
>>>>
>>>> -- 
>>> You received this message because you are subscribed 

[sage-support] Re: sage 10.3.b2 build problem on OSX 12.7.1

[John H Palmieri]

In sage-release, Matthias pointed to missing dependencies for editables, 
fixed in https://github.com/sagemath/sage/pull/36885. Maybe you can just do 
"make flit_core" (to build the missing dependency) and then "make".


On Friday, December 15, 2023 at 10:52:10 AM UTC-8 David Joyner wrote:

> Hi:
>
> I tried to compile sage and got this:
>
> The following package(s) may have failed to build (not necessarily
>
> during this run of 'make all-start'):
>
>
> * package: editables-0.5
>
>   last build time: Dec 15 10:48
>
>   log file:
> /Users/davidjoyner/sagefiles/sage-10.3.beta2/logs/pkgs/editables-0.5.log
>
>
> The corresponding log is attached.
>
>
> Does anyone have any suggestions on how to fix this?
>
> - David
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-support+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-support/ce30cd4c-f431-4eb8-ac35-f4ab5e941e49n%40googlegroups.com.

[sage-release] Re: Sage 10.3.beta2 released

[John H Palmieri]

In fact I don't understand alarm(...) at all. Maybe it works better on 
linux or older OS X releases, but on the OS X machines to which I have 
access, it feels broken. If I do:

sage: alarm(0.3)

then after 0.3 seconds I see a message

KeyboardInterrupt escaped interact()

That's fine. But then the next command I issue tends to get interrupted:

┌┐
│ SageMath version 10.3.beta2, Release Date: 2023-12-13  │
│ Using Python 3.11.6. Type "help()" for help.   │
└┘
┏┓
┃ Warning: this is a prerelease version, and it may be unstable. ┃
┗┛
sage: alarm(0.3)
sage:   
  

KeyboardInterrupt escaped interact()

sage: identity_matrix(10)
---
AlarmInterruptTraceback (most recent call last)
Cell In[2], line 1
> 1 identity_matrix(Integer(10))
...

Why? The alarm should have already happened. As I said before, if I exit 
Sage, then it does not do so gracefully. Furthermore, if instead of exiting 
I issue a second alarm, Sage crashes:

┌┐
│ SageMath version 10.3.beta2, Release Date: 2023-12-13  │
│ Using Python 3.11.6. Type "help()" for help.   │
└┘
┏┓
┃ Warning: this is a prerelease version, and it may be unstable. ┃
┗┛
sage: alarm(0.3)
sage:   
  

KeyboardInterrupt escaped interact()

sage: alarm(0.3)
sage:   
  

KeyboardInterrupt escaped interact()

Error in sys.excepthook:
Traceback (most recent call last):
  File 
"/usr/local/Cellar/python@3.11/3.11.6_1/Frameworks/Python.framework/Versions/3.11/lib/python3.11/pathlib.py",
 
line 1250, in is_dir
return S_ISDIR(self.stat().st_mode)
   ^
AttributeError: 'str' object has no attribute 'stat'

Original exception was:
Traceback (most recent call last):
  File "/Users/palmieri/Sage/TESTING/sage-10.3.beta2/src/bin/sage-ipython", 
line 16, in 
app.start()
  File 
"/Users/palmieri/Sage/TESTING/sage-10.3.beta2/local/var/lib/sage/venv-python3.11/lib/python3.11/site-packages/IPython/terminal/ipapp.py",
 
line 317, in start
self.shell.mainloop()
  File 
"/Users/palmieri/Sage/TESTING/sage-10.3.beta2/local/var/lib/sage/venv-python3.11/lib/python3.11/site-packages/IPython/terminal/interactiveshell.py",
 
line 899, in mainloop
self.restore_term_title()
  File 
"/Users/palmieri/Sage/TESTING/sage-10.3.beta2/local/var/lib/sage/venv-python3.11/lib/python3.11/site-packages/IPython/terminal/interactiveshell.py",
 
line 602, in restore_term_title
restore_term_title()
  File 
"/Users/palmieri/Sage/TESTING/sage-10.3.beta2/local/var/lib/sage/venv-python3.11/lib/python3.11/site-packages/IPython/utils/terminal.py",
 
line 115, in restore_term_title
_restore_term_title()
  File 
"/Users/palmieri/Sage/TESTING/sage-10.3.beta2/local/var/lib/sage/venv-python3.11/lib/python3.11/site-packages/IPython/utils/terminal.py",
 
line 83, in _restore_term_title_xterm
assert _xterm_term_title_saved
AssertionError


Something seems to be pretty broken.

On Friday, December 15, 2023 at 10:52:41 AM UTC-8 John H Palmieri wrote:

> Perhaps related, and I also see this with 10.3.beta1: after using 
> alarm(...), Sage does not exit gracefully. 
>
> % ./sage
> ┌┐
> │ SageMath version 10.3.beta2, Release Date: 2023-12-13  │
> │ Using Python 3.11.6. Type "help()" for help.   │
> └┘
> ┏┓
> ┃ Warning: this is a prerelease version, and it may be unstable. ┃
> ┗┛
> sage: alarm(0.3)
> sage: 
> 
>
> KeyboardInterrupt escaped interact()
>
> sage: exit()   
> 
> Error in sys.excepthook:
> Traceback (most r

[sage-release] Re: Sage 10.3.beta2 released

[John H Palmieri]

Perhaps related, and I also see this with 10.3.beta1: after using 
alarm(...), Sage does not exit gracefully. 

% ./sage
┌┐
│ SageMath version 10.3.beta2, Release Date: 2023-12-13  │
│ Using Python 3.11.6. Type "help()" for help.   │
└┘
┏┓
┃ Warning: this is a prerelease version, and it may be unstable. ┃
┗┛
sage: alarm(0.3)
sage:   
  

KeyboardInterrupt escaped interact()

sage: exit()   

Error in sys.excepthook:
Traceback (most recent call last):
  File 
"/usr/local/Cellar/python@3.11/3.11.6_1/Frameworks/Python.framework/Versions/3.11/lib/python3.11/pathlib.py",
 
line 1250, in is_dir
return S_ISDIR(self.stat().st_mode)
   ^
AttributeError: 'str' object has no attribute 'stat'

Original exception was:
Traceback (most recent call last):
  File "/Users/palmieri/Sage/TESTING/sage-10.3.beta2/src/bin/sage-ipython", 
line 16, in 
app.start()
  File 
"/Users/palmieri/Sage/TESTING/sage-10.3.beta2/local/var/lib/sage/venv-python3.11/lib/python3.11/site-packages/IPython/terminal/ipapp.py",
 
line 317, in start
self.shell.mainloop()
  File 
"/Users/palmieri/Sage/TESTING/sage-10.3.beta2/local/var/lib/sage/venv-python3.11/lib/python3.11/site-packages/IPython/terminal/interactiveshell.py",
 
line 899, in mainloop
self.restore_term_title()
  File 
"/Users/palmieri/Sage/TESTING/sage-10.3.beta2/local/var/lib/sage/venv-python3.11/lib/python3.11/site-packages/IPython/terminal/interactiveshell.py",
 
line 602, in restore_term_title
restore_term_title()
  File 
"/Users/palmieri/Sage/TESTING/sage-10.3.beta2/local/var/lib/sage/venv-python3.11/lib/python3.11/site-packages/IPython/utils/terminal.py",
 
line 115, in restore_term_title
_restore_term_title()
  File 
"/Users/palmieri/Sage/TESTING/sage-10.3.beta2/local/var/lib/sage/venv-python3.11/lib/python3.11/site-packages/IPython/utils/terminal.py",
 
line 83, in _restore_term_title_xterm
assert _xterm_term_title_saved
AssertionError



The same happens if I execute several commands between the alarm and exit().

On Friday, December 15, 2023 at 7:07:53 AM UTC-8 Dima Pasechnik wrote:

> On Thursday, December 14, 2023 at 4:05:31 PM UTC John H Palmieri wrote:
>
> On OS X (both Intel and Apple Silicon) I'm getting a lot of new failures, 
> many of the form "Killed due to alarm":
>
> sage -t --long --random-seed=144845266083009760424007645487960076680 
> src/sage/libs/flint/nmod_poly_linkage.pxi  # Killed due to alarm
> sage -t --long --random-seed=144845266083009760424007645487960076680 
> src/sage/data_structures/bounded_integer_sequences.pyx  # Killed due to 
> alarm
> sage -t --long --random-seed=144845266083009760424007645487960076680 
> src/sage/libs/gap/element.pyx  # Killed due to alarm
> sage -t --long --random-seed=144845266083009760424007645487960076680 
> src/sage/interfaces/gap.py  # Killed due to alarm
> sage -t --long --random-seed=144845266083009760424007645487960076680 
> src/sage/geometry/integral_points.pxi  # Killed due to alarm
> sage -t --long --random-seed=144845266083009760424007645487960076680 
> src/sage/libs/libecm.pyx  # Killed due to alarm
> sage -t --long --random-seed=144845266083009760424007645487960076680 
> src/sage/coding/linear_code.py  # Killed due to alarm
> sage -t --long --random-seed=144845266083009760424007645487960076680 
> src/sage/rings/factorint_pari.pyx  # Killed due to alarm
> sage -t --long --random-seed=144845266083009760424007645487960076680 
> src/sage/rings/integer.pyx  # Killed due to alarm
> sage -t --long --random-seed=144845266083009760424007645487960076680 
> src/sage/rings/complex_arb.pyx  # Killed due to alarm
> sage -t --long --random-seed=144845266083009760424007645487960076680 
> src/sage/parallel/decorate.py  # Killed due to alarm
> sage -t --long --random-seed=144845266083009760424007645487960076680 
> src/sage/rings/polynomial/polynomial_element.pyx  # Killed due to alarm
> sage -t --long --random-seed=144845266083009760424007645487960076680 
> src/sage/rings/polynomial/polynomial_zmod_flint.pyx  # Killed due to alarm
> sage -t --long --random-seed=144845266083009760424007645487960076680 
> src/sage/sets/recursively_enumerated_set.pyx  # Killed due to alarm
> sage -t --long --random-seed=144845266083009760424007645487960076680 
> src/sage/structure/coerce_actions.pyx  # Killed due to alarm
> sage -t --long --

Re: [sage-release] Sage 10.3.beta2 released

[John H Palmieri]

I'm using Venture 13.6.3 on one machine, Sonoma 14.2 on the other, plus a 
lot of homebrew packages.


On Thursday, December 14, 2023 at 1:05:44 PM UTC-8 david@gmail.com 
wrote:

> I don’t see these errors on Apple M1 with macOS 12.7.1.
>
> Le 14 déc. 2023 à 17:05, John H Palmieri  a écrit :
>
> On OS X (both Intel and Apple Silicon) I'm getting a lot of new failures, 
> many of the form "Killed due to alarm":
>
> sage -t --long --random-seed=144845266083009760424007645487960076680 
> src/sage/libs/flint/nmod_poly_linkage.pxi  # Killed due to alarm
> sage -t --long --random-seed=144845266083009760424007645487960076680 
> src/sage/data_structures/bounded_integer_sequences.pyx  # Killed due to 
> alarm
> sage -t --long --random-seed=144845266083009760424007645487960076680 
> src/sage/libs/gap/element.pyx  # Killed due to alarm
> sage -t --long --random-seed=144845266083009760424007645487960076680 
> src/sage/interfaces/gap.py  # Killed due to alarm
> sage -t --long --random-seed=144845266083009760424007645487960076680 
> src/sage/geometry/integral_points.pxi  # Killed due to alarm
> sage -t --long --random-seed=144845266083009760424007645487960076680 
> src/sage/libs/libecm.pyx  # Killed due to alarm
> sage -t --long --random-seed=144845266083009760424007645487960076680 
> src/sage/coding/linear_code.py  # Killed due to alarm
> sage -t --long --random-seed=144845266083009760424007645487960076680 
> src/sage/rings/factorint_pari.pyx  # Killed due to alarm
> sage -t --long --random-seed=144845266083009760424007645487960076680 
> src/sage/rings/integer.pyx  # Killed due to alarm
> sage -t --long --random-seed=144845266083009760424007645487960076680 
> src/sage/rings/complex_arb.pyx  # Killed due to alarm
> sage -t --long --random-seed=144845266083009760424007645487960076680 
> src/sage/parallel/decorate.py  # Killed due to alarm
> sage -t --long --random-seed=144845266083009760424007645487960076680 
> src/sage/rings/polynomial/polynomial_element.pyx  # Killed due to alarm
> sage -t --long --random-seed=144845266083009760424007645487960076680 
> src/sage/rings/polynomial/polynomial_zmod_flint.pyx  # Killed due to alarm
> sage -t --long --random-seed=144845266083009760424007645487960076680 
> src/sage/sets/recursively_enumerated_set.pyx  # Killed due to alarm
> sage -t --long --random-seed=144845266083009760424007645487960076680 
> src/sage/structure/coerce_actions.pyx  # Killed due to alarm
> sage -t --long --random-seed=144845266083009760424007645487960076680 
> src/sage/matrix/matrix_integer_dense.pyx  # Killed due to alarm
> sage -t --long --random-seed=144845266083009760424007645487960076680 
> src/sage/schemes/elliptic_curves/descent_two_isogeny.pyx  # Killed due to 
> alarm
> sage -t --long --random-seed=144845266083009760424007645487960076680 
> src/sage/doctest/forker.py  # 5 doctests failed
> sage -t --long --random-seed=144845266083009760424007645487960076680 
> src/sage/doctest/control.py  # 8 doctests failed
>
> Plus some doctests that have been failing for a while:
>
> sage -t --long --random-seed=144845266083009760424007645487960076680 
> src/sage/rings/polynomial/multi_polynomial_ideal.py  # Killed due to 
> segmentation fault
> sage -t --long --random-seed=144845266083009760424007645487960076680 
> src/sage/libs/giac/__init__.py  # Timed out
> sage -t --long --random-seed=144845266083009760424007645487960076680 
> src/sage/tests/books/computational-mathematics-with-sagemath/mpoly_doctest.py 
>  # 1 doctest failed
>
>
>
> On Wednesday, December 13, 2023 at 4:42:36 PM UTC-8 Volker Braun wrote:
>
>> As always, you can get the latest beta version from the "develop" git 
>> branch. Alternatively, the self-contained source tarball is at 
>> http://www.sagemath.org/download-latest.html
>>
>>
>> e2e0f8db21e (github/develop, tag: 10.3.beta2) Updated SageMath version to 
>> 10.3.beta2
>> 2395f7bb45f gh-36862: Fix one doctest for giac 1.9.0-73
>> c85cb61919a gh-36859: src/sage/libs/pari/convert_sage_matrix.pyx: Remove 
>> `sage_setup: distribution`
>> 69d5801de36 gh-36856: various details in modules folder (ruff, 
>> cython-lint, roles)
>> 3d9dc8d3daa gh-36855: some ruff details in modular (unicode)
>> c4bebb1988a gh-36854: various details in categories (ruff C4 and UP02)
>> dd54b42ad4e gh-36853: various details in algebras (ruff mostly)
>> 033d95a9500 gh-36852: `failing doctest on Apple M1`: corrected the test 
>> case by sorting the result
>> 49e6c9f99c4 gh-36851: various details in group (ruff and pycodestyle)
>> 1abf5c643ff gh-36846: Resolve nice tree decomp bug in #36843, and allow 
>> `label_nice_tree_decomposition` to return a digraph
>> f98a4c5176d gh-36837: update

[sage-release] Re: Sage 10.3.beta2 released

[John H Palmieri]

On OS X (both Intel and Apple Silicon) I'm getting a lot of new failures, 
many of the form "Killed due to alarm":

sage -t --long --random-seed=144845266083009760424007645487960076680 
src/sage/libs/flint/nmod_poly_linkage.pxi  # Killed due to alarm
sage -t --long --random-seed=144845266083009760424007645487960076680 
src/sage/data_structures/bounded_integer_sequences.pyx  # Killed due to 
alarm
sage -t --long --random-seed=144845266083009760424007645487960076680 
src/sage/libs/gap/element.pyx  # Killed due to alarm
sage -t --long --random-seed=144845266083009760424007645487960076680 
src/sage/interfaces/gap.py  # Killed due to alarm
sage -t --long --random-seed=144845266083009760424007645487960076680 
src/sage/geometry/integral_points.pxi  # Killed due to alarm
sage -t --long --random-seed=144845266083009760424007645487960076680 
src/sage/libs/libecm.pyx  # Killed due to alarm
sage -t --long --random-seed=144845266083009760424007645487960076680 
src/sage/coding/linear_code.py  # Killed due to alarm
sage -t --long --random-seed=144845266083009760424007645487960076680 
src/sage/rings/factorint_pari.pyx  # Killed due to alarm
sage -t --long --random-seed=144845266083009760424007645487960076680 
src/sage/rings/integer.pyx  # Killed due to alarm
sage -t --long --random-seed=144845266083009760424007645487960076680 
src/sage/rings/complex_arb.pyx  # Killed due to alarm
sage -t --long --random-seed=144845266083009760424007645487960076680 
src/sage/parallel/decorate.py  # Killed due to alarm
sage -t --long --random-seed=144845266083009760424007645487960076680 
src/sage/rings/polynomial/polynomial_element.pyx  # Killed due to alarm
sage -t --long --random-seed=144845266083009760424007645487960076680 
src/sage/rings/polynomial/polynomial_zmod_flint.pyx  # Killed due to alarm
sage -t --long --random-seed=144845266083009760424007645487960076680 
src/sage/sets/recursively_enumerated_set.pyx  # Killed due to alarm
sage -t --long --random-seed=144845266083009760424007645487960076680 
src/sage/structure/coerce_actions.pyx  # Killed due to alarm
sage -t --long --random-seed=144845266083009760424007645487960076680 
src/sage/matrix/matrix_integer_dense.pyx  # Killed due to alarm
sage -t --long --random-seed=144845266083009760424007645487960076680 
src/sage/schemes/elliptic_curves/descent_two_isogeny.pyx  # Killed due to 
alarm
sage -t --long --random-seed=144845266083009760424007645487960076680 
src/sage/doctest/forker.py  # 5 doctests failed
sage -t --long --random-seed=144845266083009760424007645487960076680 
src/sage/doctest/control.py  # 8 doctests failed

Plus some doctests that have been failing for a while:

sage -t --long --random-seed=144845266083009760424007645487960076680 
src/sage/rings/polynomial/multi_polynomial_ideal.py  # Killed due to 
segmentation fault
sage -t --long --random-seed=144845266083009760424007645487960076680 
src/sage/libs/giac/__init__.py  # Timed out
sage -t --long --random-seed=144845266083009760424007645487960076680 
src/sage/tests/books/computational-mathematics-with-sagemath/mpoly_doctest.py 
 # 1 doctest failed



On Wednesday, December 13, 2023 at 4:42:36 PM UTC-8 Volker Braun wrote:

> As always, you can get the latest beta version from the "develop" git 
> branch. Alternatively, the self-contained source tarball is at 
> http://www.sagemath.org/download-latest.html
>
>
> e2e0f8db21e (github/develop, tag: 10.3.beta2) Updated SageMath version to 
> 10.3.beta2
> 2395f7bb45f gh-36862: Fix one doctest for giac 1.9.0-73
> c85cb61919a gh-36859: src/sage/libs/pari/convert_sage_matrix.pyx: Remove 
> `sage_setup: distribution`
> 69d5801de36 gh-36856: various details in modules folder (ruff, 
> cython-lint, roles)
> 3d9dc8d3daa gh-36855: some ruff details in modular (unicode)
> c4bebb1988a gh-36854: various details in categories (ruff C4 and UP02)
> dd54b42ad4e gh-36853: various details in algebras (ruff mostly)
> 033d95a9500 gh-36852: `failing doctest on Apple M1`: corrected the test 
> case by sorting the result
> 49e6c9f99c4 gh-36851: various details in group (ruff and pycodestyle)
> 1abf5c643ff gh-36846: Resolve nice tree decomp bug in #36843, and allow 
> `label_nice_tree_decomposition` to return a digraph
> f98a4c5176d gh-36837: update qepcad to B 1.74
> 31541b6b79a gh-36828: README.md: Update section on macOS arm64
> 4f34f9226af gh-36823: `ipython` 8.18 and related upgrades, remove 
> `backcall`
> f2be9758869 gh-36822: Fix linter failure in 10.3.beta0
> 0121df0e205 gh-36818: Corrected the typo in documentation - Permutation 
> Groups
> c7443b1a9cd gh-36815: Add badges to README.md
> 2ec492a4c57 gh-36812: made changes to the documentaiton of developer in 
> python3 print
> 27a07dad385 gh-36802: Python toolchain as wheel packages
> 990525bcbe7 gh-36799: Create index-pdf.html in html build
> 1c19a98dbc0 gh-36794: `sage --package create --pypi`: Create a wheel 
> package by default if possible
> 74122cc0704 gh-36785: `build/pkgs/cython`: Update to 3.0.6
> 1bbdb3e8339 gh-36778: Remove Cygwin 

[sage-support] Re: Problems viewing crystals from sage

[John H Palmieri]

Please add comments to that ticket.

On Tuesday, December 12, 2023 at 6:15:31 PM UTC-8 Andrew wrote:

> Thanks John. 
>
> Yes, I think you are right because this PR is about exactly this issue 
> and, more importantly, it adds the code that I want to brutalise. I missed 
> this when used git blame to look for recent changes to sage.misc.latex. 
> This fits as view() was working without issues for me a month or so ago and 
> this was only merged at the end of October.
>
> Since https://github.com/sagemath/sage/pull/36529 is already merged is it 
> too late to add a comment on the ticket?
>
> Andrew
>
>
> On Wednesday 13 December 2023 at 12:30:03 pm UTC+11 John H Palmieri wrote:
>
>> Could this be related to https://github.com/sagemath/sage/pull/36529?
>>
>>
>> On Tuesday, December 12, 2023 at 3:50:55 PM UTC-8 Andrew wrote:
>>
>>> Playing around with this a little more, I think that this is a 
>>> bug/timing issue in sage.misc.latex.py (or in subprocess.run, or a mac 
>>> oddity since it only started happening recently). 
>>>
>>> What seems to be happening is that the generated PDF file, output_file, 
>>> is being deleted before the viewer is able to open it. Specifically, if I 
>>> add time.sleep(2) before the tmp.cleanup  then the viewer opens as expected.
>>>
>>> def run_viewer():
>>> run([viewer, output_file], capture_output=True)
>>> time.sleep(1)## adding this, together with import time, 
>>> fixes the problem
>>> tmp.cleanup()
>>>
>>> (This around line 1957 of latex.py.) Certainly this explains my 
>>> experience of the command working sometimes and failing at other times. On 
>>> the other hand, it is a little strange because subprocess.run is supposed 
>>> to wait for the process to finish. A shorter example that exhibits the 
>>> problem, at least on the two macs that I have available, is
>>>
>>> sage: view(crystals.LSPaths( 
>>> RootSystem(['A',4]).weight_space().basis()[1] ) )
>>>
>>> If people agree that this is a bug then I am happy to post a fix.
>>>
>>> Andrew
>>>
>>>
>>> On Monday 11 December 2023 at 4:35:59 pm UTC+11 Andrew wrote:
>>>
>>>> I am trying to view crystal graphs from inside sage, and I am going a 
>>>> little nuts. Sometimes view(...) works as I expect but most of the time it 
>>>> doesn't, and I see the error message:
>>>>
>>>> The document “sage.pdf” could not be opened. The file doesn’t exist.
>>>>
>>>> (my emphasis). I compiled sage from source and I am running:
>>>>
>>>> SageMath version 10.3.beta1
>>>> Release Date: 2023-12-10 
>>>> Using Python 3.11.6.
>>>>
>>>> on a 2022 macbook pro (M1 max), running Sonoma 14.1.2. I installed 
>>>> dot2tex using:
>>>> sage -i dot2tex, which 
>>>> which installed without errors. Running
>>>> sage: from sage.graphs.graph_latex import check_tkz_graph
>>>> sage: check_tkz_graph() 
>>>> does not report any problems with my set up.
>>>>
>>>> I get the error message above using the the sage commands:
>>>>
>>>> sage: L=RootSystem(['A',4]).weight_space().basis()
>>>> sage: G=crystals.LSPaths(['A',4], L[1])
>>>> sage: G
>>>> The crystal of LS paths of type ['A', 4] and weight Lambda[2]
>>>> sage: view(G)
>>>>
>>>> I get the same error if I try the examples from the "Classical 
>>>> crystals" thematic tutorial, 
>>>> <https://doc.sagemath.org/html/en/thematic_tutorials/lie/crystals.html#installing-dot2tex>
>>>>  
>>>> such as:
>>>>
>>>> sage: B = crystals.Tableaux(['A',2], shape=[2,1])
>>>> sage: view(B, tightpage=True) 
>>>>
>>>> When it does work, a nice tikz generated pdf file pops up. Am I missing 
>>>> some steps? Can anyone tell me what I am doing wrong?
>>>>
>>>> Andrew
>>>>
>>>>
>>>>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-support+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-support/7227e438-d87f-4ec7-8511-8be2413a68d1n%40googlegroups.com.

[sage-support] Re: Problems viewing crystals from sage

[John H Palmieri]

Could this be related to https://github.com/sagemath/sage/pull/36529?


On Tuesday, December 12, 2023 at 3:50:55 PM UTC-8 Andrew wrote:

> Playing around with this a little more, I think that this is a bug/timing 
> issue in sage.misc.latex.py (or in subprocess.run, or a mac oddity since 
> it only started happening recently). 
>
> What seems to be happening is that the generated PDF file, output_file, is 
> being deleted before the viewer is able to open it. Specifically, if I add 
> time.sleep(2) before the tmp.cleanup  then the viewer opens as expected.
>
> def run_viewer():
> run([viewer, output_file], capture_output=True)
> time.sleep(1)## adding this, together with import time, fixes 
> the problem
> tmp.cleanup()
>
> (This around line 1957 of latex.py.) Certainly this explains my experience 
> of the command working sometimes and failing at other times. On the other 
> hand, it is a little strange because subprocess.run is supposed to wait for 
> the process to finish. A shorter example that exhibits the problem, at 
> least on the two macs that I have available, is
>
> sage: view(crystals.LSPaths( 
> RootSystem(['A',4]).weight_space().basis()[1] ) )
>
> If people agree that this is a bug then I am happy to post a fix.
>
> Andrew
>
>
> On Monday 11 December 2023 at 4:35:59 pm UTC+11 Andrew wrote:
>
>> I am trying to view crystal graphs from inside sage, and I am going a 
>> little nuts. Sometimes view(...) works as I expect but most of the time it 
>> doesn't, and I see the error message:
>>
>> The document “sage.pdf” could not be opened. The file doesn’t exist.
>>
>> (my emphasis). I compiled sage from source and I am running:
>>
>> SageMath version 10.3.beta1
>> Release Date: 2023-12-10 
>> Using Python 3.11.6.
>>
>> on a 2022 macbook pro (M1 max), running Sonoma 14.1.2. I installed 
>> dot2tex using:
>> sage -i dot2tex, which 
>> which installed without errors. Running
>> sage: from sage.graphs.graph_latex import check_tkz_graph
>> sage: check_tkz_graph() 
>> does not report any problems with my set up.
>>
>> I get the error message above using the the sage commands:
>>
>> sage: L=RootSystem(['A',4]).weight_space().basis()
>> sage: G=crystals.LSPaths(['A',4], L[1])
>> sage: G
>> The crystal of LS paths of type ['A', 4] and weight Lambda[2]
>> sage: view(G)
>>
>> I get the same error if I try the examples from the "Classical crystals" 
>> thematic tutorial, 
>> 
>>  
>> such as:
>>
>> sage: B = crystals.Tableaux(['A',2], shape=[2,1])
>> sage: view(B, tightpage=True) 
>>
>> When it does work, a nice tikz generated pdf file pops up. Am I missing 
>> some steps? Can anyone tell me what I am doing wrong?
>>
>> Andrew
>>
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-support+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-support/c47fda1e-16dc-4a87-a17b-dc5393aca1afn%40googlegroups.com.

[sage-release] Re: Sage 10.3.beta0 released

[John H Palmieri]

Builds fine for me on OS X, both Intel and Apple Silicon. No new doctest 
failures.

On Tuesday, December 5, 2023 at 4:26:09 PM UTC-8 Volker Braun wrote:

> As always, you can get the latest beta version from the "develop" git 
> branch. Alternatively, the self-contained source tarball is at 
> http://www.sagemath.org/download-latest.html
>
> 272582be9e0 (github/develop, tag: 10.3.beta0) Updated SageMath version to 
> 10.3.beta0
> 9b1e18ffc02  gh-36664: ruff auto-fix for C4 in modular
> 3253ed95cdb gh-36658: `sage.sat`: Update `# needs`
> b707b299324 gh-36657: `sage.tests`: Update `# needs`
> 34b6321efb2 gh-36655: `sage.misc.explain_pickle`: Docstring cosmetics
> c9e28a84924 gh-36654: More fixes for e221
> 0394ea33387 gh-36653: clean E702 etc in integer.pyx
> bf801b1edfb gh-36644: `sage.combinat.words`: Update `# needs`
> 5a22cce2510 gh-36643: `sage.combinat.species`: Update `# needs`
> 91c9fa67907 gh-36642: `sage.algebras`: Update `# needs`, modularization 
> fixes, doctest cosmetics
> ef9b2792302 gh-36638: return Weierstrass scaling factor in base field for 
> EllipticCurveIsogeny
> 2b9f3e0e4ff gh-36637: sums of elliptic-curve morphisms
> 3a9254d73ae gh-36630: Allow to specify output directory for generated 
> interpreters
> 69d03d36651 gh-36623: cylint cleanup in combinatorial polyhedra
> 7b3e208631f gh-36597: Replace relative imports by absolute ones in modules
> 779a502cd5e gh-36592: Add pull_from_function_field to curves
> 54dbcbf46a6 gh-36589: Replace relative imports by absolute ones in a few 
> packages
> 671f7d56ba0 gh-36588: Replace relative imports by absolute ones in rings
> caa10685ff2 gh-36584: implemented power of graph function under basic 
> methods
> 8801f6e24cd gh-36574: rename the backtrack algorithm of method 
> `longest_path` with deprecation
> 9014410efb7 gh-36572: Replace relative imports by absolute ones in 
> categories
> e86721e0b97 gh-36562: `pkgs/sage-{docbuild,setup,sws2rst}`: Migrate from 
> `setup.cfg` to `pyproject.toml`
> d67dba4740c gh-36505: `sage --tox -e coverage.py`
> a5107c61cf4 gh-36504: Functions for nice tree decomposition and its 
> labelling
> 8bcebb19169 gh-36457: check coprimality of moduli in CRT_basis()
> a6f2c461733 gh-36368: Laurent polynomials, Fitting ideals and 
> characteristic varieties
> d2b457895c4 gh-36223: src/sage/doctest/control.py: double the default test 
> timeout
> fb7ef07389d gh-36190: establish interface for instantiated classical 
> modular polynomials
> 839327af1f2 gh-36184: add class groups of binary quadratic forms
> c1a38172852 gh-36135: `sage -fixdistributions`
> f336f6a8bef gh-36129: Notebook 7, ipykernel 6.27, ipython 8.17
> c31f22e8167 gh-36031: Cythonize 
> `LatticePolytope.normal_form(algorithm='palp_native')`, change to default, 
> add as a `Polyhedron` method
> b60398e7ef6 gh-35936: generalize EllipticCurve_field.division_field() to 
> composite orders
> a7b9ebc569a gh-35848: upgrade to flint3
> 9c4fc776b5f gh-35838: FriCAS spkg-configure and Feature
> 9bc89775786 gh-35830: Bliss spkg config
> 69b0671b0f2 gh-35799: test whether point is actually on the curve when 
> evaluating elliptic-curve isomorphism
> 82174474780 gh-35486: fix documentation and random doctest failure for 
> Cornacchia algorithm
> 2a9a4267f93 (tag: 10.2, github/master) Updated SageMath version to 10.2
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-release" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-release+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-release/d8f641a4-64e0-4f29-95d6-b5ceed8fab6an%40googlegroups.com.

[cctalk] Re: Current SOA scsi disk emulators for DEC

[John H. Reinhardt via cctalk]

On 12/3/2023 10:27 AM, Douglas Taylor via cctalk wrote:

That is my question.

I have used a couple of versions of the SCSI2SD boards in the past with Viking, 
Emulex QC07, DEC RQXZ1 controllers in the past, and also direct connections to 
MicroVax SCSI buss's.

There are other manufacturers of these SD to SCSI emulators now. What is the 
current SOA?  What works, what doesn't work with DEC hardware?

Doug



State of the Art SCSI replacement is the ZuluSCSI RP2040 which is from the same 
people as SCSI2HD (I think - at least the same US Store).  In any case the 
SCSI2HD is generally out of stock unless there is some NOS left.  The ZuluSCSI 
is what is in production now.

It's under continual development with fixes and new features are being added 
(for better or worse).  I have two in a MicroVAX3100-95.  One is the main file 
systems - I have a 256GB SD card where there are 4 drives allocated.  There are 
two 50GB main drives and 2 9GB system drives. I have them mirrored under VMS 
Volume Shadowing.  I aim to use about 50% of the capacity of the SD card to 
allow plenty of space for the card's firmware to do wear leveling.  They are 
SAMSUNG PRO Endurance cards with an estimated endurance of 140k hours.  The 
other ZuluSCSI RP2040 card is mounted for external access and is the backup 
device.  This gets rotated regularly.

All that said, in the MV3100 they are still slower by a touch than rotating 
disks.  But after having several Ebay SCSI disks have controller issues 
(shorting and burnt out controllers) I am hoping these are more trouble free.

I also have 2 older SCSI2HD in my AlphaServer DS10 systems for removable 
storage.  When I get a chance I am swapping them out for the ZuluSCSI RP2040 
models because they are slightly faster and much easier to manage.

The ZuluSCSI is a hybrid of the SCSI2HD hardware and SCSI firmware and the 
BlueSCSI management firmware.  With the SCSI2HD you needed a utility (mostly) 
to mange the settings of the SCSI2HD card.  COpying the data to the card 
usually meant using a utility like dd or something that could write to specific 
places on the card.  With the ZuluSCI you format the SD card in FAT or EX-FAT 
(if your disks are bigger than 4GB) and put them on the card with a specific 
name format.  The documentation explains it all pretty clearly.

www.zuluscsi.com - US Store and some documentation
https://github.com/ZuluSCSI/ZuluSCSI-firmware/wiki/ZuluSCSI-Manual - 
Documentation
https://github.com/ZuluSCSI/ZuluSCSI-firmware - firmware

https://www.amazon.com/gp/product/B09WB3D5GQ - Samsung PRO Endurance
https://semiconductor.samsung.com/consumer-storage/memory-card/micro-sd-pro-endurance/
 - marketing info

--
John H. Reinhardt

[cctalk] Re: Current SOA scsi disk emulators for DEC

[John H. Reinhardt via cctalk]

On 12/3/2023 10:27 AM, Douglas Taylor via cctalk wrote:

That is my question.

I have used a couple of versions of the SCSI2SD boards in the past with Viking, 
Emulex QC07, DEC RQXZ1 controllers in the past, and also direct connections to 
MicroVax SCSI buss's.

There are other manufacturers of these SD to SCSI emulators now. What is the 
current SOA?  What works, what doesn't work with DEC hardware?

Doug



State of the Art SCSI replacement is the ZuluSCSI RP2040 which is from the same 
people as SCSI2HD (I think - at least the same US Store).  In any case the 
SCSI2HD is generally out of stock unless there is some NOS left.  The ZuluSCSI 
is what is in production now.

It's under continual development with fixes and new features are being added 
(for better or worse).  I have two in a MicroVAX3100-95.  One is the main file 
systems - I have a 256GB SD card where there are 4 drives allocated.  There are 
two 50GB main drives and 2 9GB system drives. I have them mirrored under VMS 
Volume Shadowing.  I aim to use about 50% of the capacity of the SD card to 
allow plenty of space for the card's firmware to do wear leveling.  They are 
SAMSUNG PRO Endurance cards with an estimated endurance of 140k hours.  The 
other ZuluSCSI RP2040 card is mounted for external access and is the backup 
device.  This gets rotated regularly.

All that said, in the MV3100 they are still slower by a touch than rotating 
disks.  But after having several Ebay SCSI disks have controller issues 
(shorting and burnt out controllers) I am hoping these are more trouble free.

I also have 2 older SCSI2HD in my AlphaServer DS10 systems for removable 
storage.  When I get a chance I am swapping them out for the ZuluSCSI RP2040 
models because they are slightly faster and much easier to manage.

The ZuluSCSI is a hybrid of the SCSI2HD hardware and SCSI firmware and the 
BlueSCSI management firmware.  With the SCSI2HD you needed a utility (mostly) 
to mange the settings of the SCSI2HD card.  COpying the data to the card 
usually meant using a utility like dd or something that could write to specific 
places on the card.  With the ZuluSCI you format the SD card in FAT or EX-FAT 
(if your disks are bigger than 4GB) and put them on the card with a specific 
name format.  The documentation explains it all pretty clearly.

www.zuluscsi.com - US Store and some documentation
https://github.com/ZuluSCSI/ZuluSCSI-firmware/wiki/ZuluSCSI-Manual - 
Documentation
https://github.com/ZuluSCSI/ZuluSCSI-firmware - firmware

https://www.amazon.com/gp/product/B09WB3D5GQ - Samsung PRO Endurance
https://semiconductor.samsung.com/consumer-storage/memory-card/micro-sd-pro-endurance/
 - marketing info

--
John H. Reinhardt

[sage-devel] Re: Policy for disputed PRs: discussion

[John H Palmieri]

The original proposal allows for anyone to post to sage-devel to try to 
raise awareness ("Also note that an objector is welcome to attempt to bring 
others into the discussion on their side if they remain firmly opposed"). I 
prefer allowing the various participants the freedom to decide whether to 
start a discussion in sage-devel rather than forcing this to happen, but 
I'm happy to hear arguments for changing it as you propose.

For some topics and disputes, it is clear that they should be discussed on 
sage-devel, perhaps even discussed here before getting to the point of a 
PR. Recalling one of William's old April 1 jokes, if we wanted to consider 
switching the infrastructure from Python to Lisp, that would require a 
discussion on sage-devel first. You mentioned 
https://github.com/sagemath/sage/pull/35403, and I think that's another 
good example. That deals with which versions of Python we support and 
whether to automatically reject certain versions. Python plays such a 
central role in Sage, but at the same time that PR is somewhat technical, 
so I feel that it's on the border of "clearly should be discussed first on 
sage-devel" vs. "can be handled in the background". Once the conflict 
arose, it made a lot of sense to bring it to sage-devel. A third example: 
Kwankyu raised https://github.com/sagemath/sage/pull/36726, and in my view 
this one is very minor and technical, and I don't see a case for a long 
discussion or vote on sage-devel. Mentioning it here to raise awareness 
makes sense, but that should be the extent of it; the rest of the 
discussion can happen on github.

To the extent that this specific PR is emblematic of a particular approach 
to Sage development (a flawed approach in Dima's view, if I understand 
right), then the whole approach should be discussed here. Probably many of 
these issues in Sage development have been discussed already, but it's 
probably time to revisit them, to see if we can reestablish a baseline 
level of consensus.
 
On Wednesday, November 29, 2023 at 7:12:31 AM UTC-8 tobia...@gmx.de wrote:

> At first I was very enthusiastic about this proposed policy, but after 
> thinking about this for a bit I'm no longer convinced this is a good idea. 
>
> First of all, the policy sets out to solve the case "where there is a 
> general consensus, but one person (or a few people) disagree". In my 
> experience, this case is not a problem. All the examples mentioned so far 
> (and the few other examples I'm aware of), have usually one positive 
> reviewer and one negative review. This is not a general consensus. The 
> problem is more that a general consensus cannot be reached. Another aspect 
> of the issue is that usually only a very small group of 2 to 3 people is 
> involved in discussing the PR, which perhaps not surprisingly then more 
> easily results in a state where all arguments have been exchanged without 
> finding a solution satisfying everyone. 
> For example, with the proposed policy, Dima and me would have outvoted 
> Matthias in https://github.com/sagemath/sage/pull/35403. But this PR was 
> largely improved by the discussion on the mailing list (that it is still 
> not clear how to proceed with this PR is another sad story).
>
> In light of this, I would like to propose to change the policy proposal to 
> an automatic system that draws more attention to the PR, with the hope that 
> new people bring new input and ideas, which then resolves the conflict in a 
> natural way. The proposal is something along the following: if a PR is say 
> a week in the "disputed state" as defined above by Kwankyu, both parties 
> write a short statement of why they think it should or should not be 
> merged, and this summary is then posted to the mailing list. Not to start a 
> voting, but to raise awareness and invite other devs to join the 
> discussion. Similar calls for PR reviews are not uncommon on the mailing 
> list, so I don't think it would annoy subscribers too much.
>
> Finally, I think Dima raises a very important point. Most of the 
> discussions in these "disputed PRs" are a result of a lack of a common 
> vision for the project and agreement on what projects to work on. It would 
> be immensely more productive to have a general discussion e.g. about how to 
> proceed with sage-the-distribution (replace it?, with what?, how to sunset 
> it? reduce it? enlarge it?). As an example, I think conda is a good 
> candidate to replace sage-the-distribution and thus naturally open PRs with 
> changes in that direction. But if you don't agree with this general 
> direction, it's easy to find these changes annoying. On the other hand, if 
> there would be an agreement that conda was a nice experiment that we don't 
> want to continue, then I'm happy to delete it completely. But instead of a 
> general direction, we have this situation where every developer is having 
> their own ideas and little projects that they are working on, and that are 
> bound to step 

[sage-devel] Re: Policy for disputed PRs: discussion

[John H Palmieri]

I agree that we need a policy, and I am happy with David's proposal.

A tangential follow-up to Matthias: I think that our code of conduct should 
be part of the distributed documentation. Should it be in the Developer's 
Guide? In some other existing documentation? As a standalone document?

-- 
John

On Saturday, November 25, 2023 at 1:24:42 AM UTC-8 Kwankyu Lee wrote:

> I agree that we need a policy for disputed PRs.
>
> Such a policy should not operate in a way to condemn those raising 
> objections to the PR since we want to keep kind, productive, caring 
> atmosphere as Matthias put it. The policy should be clear and operate 
> semi-automatically. So I suggest the following detail:
>
> (1) When a PR becomes a disputed PR? A PR becomes a disputed PR when one 
> reviewer adds "positive review" label, another reviewer removes it, and the 
> author does not plan to work more on the PR according to the reviewer 
> objections.
>
> (2) How do we count approvers and disapprovers for a disputed PR: A 
> reviewer becomes an approver (who is in favor of the PR) when he/she sets 
> "Approve" in the github review system. A reviewer becomes a disapprover 
> (who objects the PR) when he/she sets "Request changes" in the github 
> review system.
>
> Kwankyu
>

-- 
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/e50b04dc-0e94-4440-9b0e-0c6e12bb470an%40googlegroups.com.

[sage-devel] Help with matroids (and more generally?), PR #36492

[John H Palmieri]

This post concerns https://github.com/sagemath/sage/pull/36492. The main 
topic of that PR is matroids about which I know almost nothing, so I am not 
the right person to review it. The structure of the PR perhaps opens up 
broader questions. The author has some new code, along with a PDF 
documenting it, and it is currently not designed to be incorporated into 
the existing sage.matroids module, but as more of a standalone piece of 
code.

- Should we have a "contrib" directory where we can easily include efforts 
like this?
- Should this particular code be instead included in our thematic 
tutorials? (If so, it needs someone to shepherd it through the process.)
- Or should this code be folded into the existing `sage.matroids` stuff?

-- 
John

-- 
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/fb6eea67-444c-4408-95e0-66119a535e11n%40googlegroups.com.

[sage-devel] Re: Errors with make on macOS

[John H Palmieri]

Try:

% make distclean # remove all progress, just in case
% brew install cddlib fplll gsl maxima python3 singular suite-sparse  # as 
recommended at the end of `./configure`
% ./configure

Then read the output and see if it still recommends installing gsl. I hope 
not. Then

% make


On Sunday, November 19, 2023 at 1:01:09 PM UTC-8 Josh Maglione wrote:

> When running 'make' in my sage directory, I encounter an error with the 
> gsl package. I am on a MacBook Pro using macOS Sonoma 14.1.1. I have also 
> attached logs. 
>
> Any help will be most appreciated. Thank you.
>
> Josh
>

-- 
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/ed2c4de3-e0f1-4795-b85d-a401aefb3f27n%40googlegroups.com.

Re: [sage-devel] Re: Question about make dependencies

[John H Palmieri]

If I respond using "verb" as a verb, do you really think I'm seriously 
criticizing you about using "vendor" as a verb? You're telling me to get a 
life? Get a sense of humor.

On Tuesday, November 14, 2023 at 3:45:07 PM UTC-8 Dima Pasechnik wrote:

> I have not invented the verb "to vendor", I merely picked it up from 
> Python docs and PEPs, e.g.
> https://www.python.org/dev/peps/pep-0518/#configparser
> (this one was written by  native English speakers, I think)
>
> You seem to prefer to pick on my supposedly broken English, rather than 
> read Python docs, as it's much less fun.
>
> Get a life.
>
>
>
> On Tue, 14 Nov 2023, 23:19 John H Palmieri,  wrote:
>
>> Not all Americans like to verb things so profligately.
>>
>> On Tuesday, November 14, 2023 at 1:15:07 PM UTC-8 Dima Pasechnik wrote:
>>
>>>
>>>
>>> On Tue, 14 Nov 2023, 20:39 Matthias Koeppe,  
>>> wrote:
>>>
>>>> On Tuesday, November 14, 2023 at 11:39:52 AM UTC-8 Dima Pasechnik wrote:
>>>>
>>>> On Tue, Nov 14, 2023 at 7:22 PM Marc Culler  
>>>> wrote: 
>>>> > On Tue, Nov 14, 2023 at 11:58 AM Dima Pasechnik  
>>>> wrote: 
>>>> >> I imagine it might be an artifact of the design of Sage on Mac app 
>>>> >> Marc is releasing: 
>>>> >> vendor everything. 
>>>> > 
>>>> > Vendor is a noun, not a verb. 
>>>>
>>>> It's a curse, to be precise, and it slows down the project a lot. 
>>>> We have to worry about over 400 packages!!! 
>>>> Bloody hell, pardon my UK French, we have more interesting problems to 
>>>> work on...
>>>>
>>>>
>>>> FWIW, I consider Marc's effort to provide a self-contained macOS app of 
>>>> Sage to be very valuable for the project.
>>>>
>>>> Dima is indeed using the word "vendor" incorrectly. I'm not concerned 
>>>> about the grammar; I use it as a verb, too, in this specific context.
>>>> For source code, "vendoring" (= including a copy of the source code of 
>>>> a dependency, modified or not, in the source code) is problematic for 
>>>> various well known reasons.
>>>> But to accuse a binary distribution of "vendoring" is simply 
>>>> meaningless. A binary distribution is made for the benefit of users.
>>>>
>>>
>>> I am not accusing Marc of vendoring, I am saying that him asking to 
>>> supply essentially all the components of Sage in source form is asking too 
>>> much, as it saddles us with extremely heavy maintenance task, for reasons 
>>> questionable.
>>>
>>> Suppose we remove gmp from the list of packages we vendor (yes, "to 
>>> vendor", i.e. "to perform vendoring", may be a verb, as we see here. As 
>>> Americans make verbs out of everything, I find myself being gaslighted here 
>>> by one of them.)
>>>
>>> What then, will it make the task of making a macOS Sage app impossible, 
>>> or much harder, all of a sudden?
>>> I have trouble believing this.
>>>
>>>
>>>> -- 
>>>> 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+...@googlegroups.com.
>>>>
>>> To view this discussion on the web visit 
>>>> https://groups.google.com/d/msgid/sage-devel/fa119cf9-49bc-4b16-b6af-b1b6fd6584aen%40googlegroups.com
>>>>  
>>>> <https://groups.google.com/d/msgid/sage-devel/fa119cf9-49bc-4b16-b6af-b1b6fd6584aen%40googlegroups.com?utm_medium=email_source=footer>
>>>> .
>>>>
>>> -- 
>> 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+...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/sage-devel/943e37ef-0a11-4331-9e20-52141ccdddc7n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/sage-devel/943e37ef-0a11-4331-9e20-52141ccdddc7n%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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/25a17216-502e-4c4d-b70d-73e6e028881cn%40googlegroups.com.

Re: [sage-devel] Re: Question about make dependencies

[John H Palmieri]

Not all Americans like to verb things so profligately.

On Tuesday, November 14, 2023 at 1:15:07 PM UTC-8 Dima Pasechnik wrote:

>
>
> On Tue, 14 Nov 2023, 20:39 Matthias Koeppe,  wrote:
>
>> On Tuesday, November 14, 2023 at 11:39:52 AM UTC-8 Dima Pasechnik wrote:
>>
>> On Tue, Nov 14, 2023 at 7:22 PM Marc Culler  wrote: 
>> > On Tue, Nov 14, 2023 at 11:58 AM Dima Pasechnik  
>> wrote: 
>> >> I imagine it might be an artifact of the design of Sage on Mac app 
>> >> Marc is releasing: 
>> >> vendor everything. 
>> > 
>> > Vendor is a noun, not a verb. 
>>
>> It's a curse, to be precise, and it slows down the project a lot. 
>> We have to worry about over 400 packages!!! 
>> Bloody hell, pardon my UK French, we have more interesting problems to 
>> work on...
>>
>>
>> FWIW, I consider Marc's effort to provide a self-contained macOS app of 
>> Sage to be very valuable for the project.
>>
>> Dima is indeed using the word "vendor" incorrectly. I'm not concerned 
>> about the grammar; I use it as a verb, too, in this specific context.
>> For source code, "vendoring" (= including a copy of the source code of a 
>> dependency, modified or not, in the source code) is problematic for various 
>> well known reasons.
>> But to accuse a binary distribution of "vendoring" is simply meaningless. 
>> A binary distribution is made for the benefit of users.
>>
>
> I am not accusing Marc of vendoring, I am saying that him asking to supply 
> essentially all the components of Sage in source form is asking too much, 
> as it saddles us with extremely heavy maintenance task, for reasons 
> questionable.
>
> Suppose we remove gmp from the list of packages we vendor (yes, "to 
> vendor", i.e. "to perform vendoring", may be a verb, as we see here. As 
> Americans make verbs out of everything, I find myself being gaslighted here 
> by one of them.)
>
> What then, will it make the task of making a macOS Sage app impossible, or 
> much harder, all of a sudden?
> I have trouble believing this.
>
>
>> -- 
>> 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+...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/sage-devel/fa119cf9-49bc-4b16-b6af-b1b6fd6584aen%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/943e37ef-0a11-4331-9e20-52141ccdddc7n%40googlegroups.com.

[sage-support] Re: Integral result differ from Wolfram|Alpha

[John H Palmieri]

Isn't log(log(x)^2) = 2 * log(log(x))? Is this your concern, or is it the 
absolute value?

On Monday, November 13, 2023 at 1:32:11 PM UTC-8 Bùi Gia Nghĩa wrote:

> Hi!
> I have used Sage Cell Server to integrate the function (ln(x)^2 - 1) / (x 
> * ln(x)). It should resulted in (ln(x)^2) / 2 - |ln(ln(x))| + C, as noted 
> by my textbook and Wolfram|Alpha, but instead resulted in 1/2*log(x)^2 - 
> 1/2*log(log(x)^2). 
> (I do notice that SageMath use log(a) to denote natural logarithm, so 
> that's not the question here).
> Anyone knows why it happen? I think that this is a bug from some system 
> SageMath use to calculate this, but I am new to SageMath so have zero 
> knowledge about the system.
> Here is the exact code I input:
> var("x")
> f = (log(x)**2 - 1) / (x * log(x))
> integral(f, x)
>
> Thanks in advance!
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-support+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-support/cdc2eaeb-3201-46e3-a37e-c90e747756c1n%40googlegroups.com.

[sage-release] Re: Sage 10.2.rc1 released

[John H Palmieri]

A better link for the 3rd and 4th failures is #36631 
(https://github.com/sagemath/sage/issues/36631).

On Saturday, November 11, 2023 at 9:52:26 AM UTC-8 John H Palmieri wrote:

> On OS X Intel, looks good. Four doctest failures, all of which have been 
> reported:
>
> sage -t --long --random-seed=120467112235779717922036180522489127126 
> src/sage/libs/giac/__init__.py  # Timed out
> sage -t --long --random-seed=120467112235779717922036180522489127126 
> src/sage/rings/polynomial/multi_polynomial_ideal.py  # Timed out
> sage -t --long --random-seed=120467112235779717922036180522489127126 
> src/sage/rings/polynomial/polynomial_element.pyx  # 1 doctest failed
> sage -t --long --random-seed=120467112235779717922036180522489127126 
> src/sage/tests/books/computational-mathematics-with-sagemath/mpoly_doctest.py 
>  # 1 doctest failed
>
> (The first two at #35646, the second two at #36509. I have not seen 
> progress fixing either, so there are no associated blocker PRs.)
>
> On Friday, November 10, 2023 at 11:18:19 AM UTC-8 Volker Braun wrote:
>
>> As always, you can get the latest beta version from the "develop" git 
>> branch. Alternatively, the self-contained source tarball is at 
>> http://www.sagemath.org/download-latest.html
>>
>> I just corrected a mistake, so if your head commit is not e349b002499 
>> then please reset.
>>
>> e349b002499  (tag: 10.2.rc1, github/develop) Updated SageMath version to 
>> 10.2.rc1
>> 81bf4e52c66 gh-36668: CI Linux: Fix "optional", "experimental" jobs
>> dfde868e2f2 gh-36663: Upgrade `zeromq` to 4.3.5, `pyzmq` to 25.1.1, patch 
>> out broken tests in setup
>> 7cad4fc0026 gh-36661: .github/workflows/doc-build.yml: Fix live doc 
>> building
>> 781dbff5cb4 gh-36659: prompt_toolkit: Set version constraint for conda
>> a88fe91eae2 gh-36652: src/sage/misc/sageinspect.py: Fix pycodestyle 
>> complaint
>> 9d2750c52bd gh-36648: CI macOS: Update
>> 07ea7e18328 gh-36636: Deploy live doc on push to develop
>> 88984731816 gh-36599: sage-env: identify the version of command-line 
>> tools (OS X) and set LDFLAGS accordingly
>> 31a1ae59c46 gh-36534: CI Linux: Fix `centos-7` after #36435, remove 
>> `gentoo-python3.12` for now, use `conda-forge` with `-python3.11`
>> b7d34011471 gh-36533: `pkgs/sage-conf_pypi`: Repair after #36400, #36435
>> ebef87aa8db (tag: 10.2.rc0) Updated SageMath version to 10.2.rc0
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-release" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-release+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-release/ec391ab5-8a30-4400-985e-3f67bfa7d5e0n%40googlegroups.com.

[sage-release] Re: Sage 10.2.rc1 released

[John H Palmieri]

Same on OS X Apple M2 chip. In both this and the earlier case, I ran 
`./configure` — no need to do `./configure --with-system-gfortran=no`.

On Saturday, November 11, 2023 at 9:52:26 AM UTC-8 John H Palmieri wrote:

> On OS X Intel, looks good. Four doctest failures, all of which have been 
> reported:
>
> sage -t --long --random-seed=120467112235779717922036180522489127126 
> src/sage/libs/giac/__init__.py  # Timed out
> sage -t --long --random-seed=120467112235779717922036180522489127126 
> src/sage/rings/polynomial/multi_polynomial_ideal.py  # Timed out
> sage -t --long --random-seed=120467112235779717922036180522489127126 
> src/sage/rings/polynomial/polynomial_element.pyx  # 1 doctest failed
> sage -t --long --random-seed=120467112235779717922036180522489127126 
> src/sage/tests/books/computational-mathematics-with-sagemath/mpoly_doctest.py 
>  # 1 doctest failed
>
> (The first two at #35646, the second two at #36509. I have not seen 
> progress fixing either, so there are no associated blocker PRs.)
>
> On Friday, November 10, 2023 at 11:18:19 AM UTC-8 Volker Braun wrote:
>
>> As always, you can get the latest beta version from the "develop" git 
>> branch. Alternatively, the self-contained source tarball is at 
>> http://www.sagemath.org/download-latest.html
>>
>> I just corrected a mistake, so if your head commit is not e349b002499 
>> then please reset.
>>
>> e349b002499  (tag: 10.2.rc1, github/develop) Updated SageMath version to 
>> 10.2.rc1
>> 81bf4e52c66 gh-36668: CI Linux: Fix "optional", "experimental" jobs
>> dfde868e2f2 gh-36663: Upgrade `zeromq` to 4.3.5, `pyzmq` to 25.1.1, patch 
>> out broken tests in setup
>> 7cad4fc0026 gh-36661: .github/workflows/doc-build.yml: Fix live doc 
>> building
>> 781dbff5cb4 gh-36659: prompt_toolkit: Set version constraint for conda
>> a88fe91eae2 gh-36652: src/sage/misc/sageinspect.py: Fix pycodestyle 
>> complaint
>> 9d2750c52bd gh-36648: CI macOS: Update
>> 07ea7e18328 gh-36636: Deploy live doc on push to develop
>> 88984731816 gh-36599: sage-env: identify the version of command-line 
>> tools (OS X) and set LDFLAGS accordingly
>> 31a1ae59c46 gh-36534: CI Linux: Fix `centos-7` after #36435, remove 
>> `gentoo-python3.12` for now, use `conda-forge` with `-python3.11`
>> b7d34011471 gh-36533: `pkgs/sage-conf_pypi`: Repair after #36400, #36435
>> ebef87aa8db (tag: 10.2.rc0) Updated SageMath version to 10.2.rc0
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-release" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-release+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-release/1dc6aae1-c767-4705-b626-84640fdc9b53n%40googlegroups.com.

[sage-release] Re: Sage 10.2.rc1 released

[John H Palmieri]

On OS X Intel, looks good. Four doctest failures, all of which have been 
reported:

sage -t --long --random-seed=120467112235779717922036180522489127126 
src/sage/libs/giac/__init__.py  # Timed out
sage -t --long --random-seed=120467112235779717922036180522489127126 
src/sage/rings/polynomial/multi_polynomial_ideal.py  # Timed out
sage -t --long --random-seed=120467112235779717922036180522489127126 
src/sage/rings/polynomial/polynomial_element.pyx  # 1 doctest failed
sage -t --long --random-seed=120467112235779717922036180522489127126 
src/sage/tests/books/computational-mathematics-with-sagemath/mpoly_doctest.py 
 # 1 doctest failed

(The first two at #35646, the second two at #36509. I have not seen 
progress fixing either, so there are no associated blocker PRs.)

On Friday, November 10, 2023 at 11:18:19 AM UTC-8 Volker Braun wrote:

> As always, you can get the latest beta version from the "develop" git 
> branch. Alternatively, the self-contained source tarball is at 
> http://www.sagemath.org/download-latest.html
>
> I just corrected a mistake, so if your head commit is not e349b002499 then 
> please reset.
>
> e349b002499  (tag: 10.2.rc1, github/develop) Updated SageMath version to 
> 10.2.rc1
> 81bf4e52c66 gh-36668: CI Linux: Fix "optional", "experimental" jobs
> dfde868e2f2 gh-36663: Upgrade `zeromq` to 4.3.5, `pyzmq` to 25.1.1, patch 
> out broken tests in setup
> 7cad4fc0026 gh-36661: .github/workflows/doc-build.yml: Fix live doc 
> building
> 781dbff5cb4 gh-36659: prompt_toolkit: Set version constraint for conda
> a88fe91eae2 gh-36652: src/sage/misc/sageinspect.py: Fix pycodestyle 
> complaint
> 9d2750c52bd gh-36648: CI macOS: Update
> 07ea7e18328 gh-36636: Deploy live doc on push to develop
> 88984731816 gh-36599: sage-env: identify the version of command-line tools 
> (OS X) and set LDFLAGS accordingly
> 31a1ae59c46 gh-36534: CI Linux: Fix `centos-7` after #36435, remove 
> `gentoo-python3.12` for now, use `conda-forge` with `-python3.11`
> b7d34011471 gh-36533: `pkgs/sage-conf_pypi`: Repair after #36400, #36435
> ebef87aa8db (tag: 10.2.rc0) Updated SageMath version to 10.2.rc0
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-release" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-release+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-release/a197488f-7731-4b34-8d60-8794c335152fn%40googlegroups.com.

[sage-devel] Re: https://github.com/sagemath/sage/wiki/Sage-10.2-Release-Tour

[John H Palmieri]

Where might changes to the Sage library go? I might want to highlight 
#36310.

On Friday, November 10, 2023 at 10:38:00 AM UTC-8 Matthias Koeppe wrote:

> So far we have:
>
> Sage 10.2 Release Tour 
> 
>
>- Live Documentation 
>
> 
>- Package upgrades and configuration changes 
>
> 
>- Python / Cython 
>
> 
>- NumPy / SciPy / Matplotlib 
>
> 
>- Bordeaux / Kaiserslautern / Paris 
>
> 
>- Other upgrades 
>
> 
>- New developer tools, modularization, deprecations 
>
> 
>- Open blocker PRs are applied automatically in CI workflows 
>
> 
>- ./configure --enable-system-site-packages (experimental) 
>
> 
>- make sagemath_categories-check 
>
> 
>- Deprecations 
>
>- Availability of Sage 10.2 and installation help 
>
> 
>- Sources 
>
>- Known problems and workarounds 
>
> 
>- Help 
>
>- More details 
>
>
>
>
>

-- 
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/91b0e53e-7d13-4bc0-aed9-8a42c506c761n%40googlegroups.com.

[sage-release] Re: Sage 10.2.rc0 released

[John H Palmieri]

On OS X, 10.2.rc0 behaves similarly to the previous release, no new doctest 
failures. 

On Sunday, November 5, 2023 at 1:18:52 PM UTC-8 John H Palmieri wrote:

> It would be great if #36599 could be merged in the 10.2 cycle: this should 
> allow scipy to build with recent versions of OS X + command-line tools, 
> without having to build our own gfortran. (It also silences some warnings 
> and therefore avoids some doctest failures.)
>
>
> On Sunday, November 5, 2023 at 9:22:44 AM UTC-8 Volker Braun wrote:
>
>> As always, you can get the latest beta version from the "develop" git 
>> branch. Alternatively, the self-contained source tarball is at 
>> http://www.sagemath.org/download-latest.html
>>
>>
>> ebef87aa8db (tag: 10.2.rc0, github/develop) Updated SageMath version to 
>> 10.2.rc0
>> be0b5cf887f gh-36647: fix random doctest error in 
>> `src/sage/rings/polynomial/skew_polynomial_finite_field.pyx`
>> 4533ffbea9b gh-36639: fix broken pyright in CI
>> 636c96c96f8 gh-36636: Deploy live doc on push to develop
>> d1da6ba6e3f gh-36635: clean the file hexad.py
>> a54d377cc16 gh-36634: permutation_normal_form : case of empty matrices
>> 505b6a40e99 gh-36632: .ci/merge-fixes.sh: Reduce output
>> 29e95c5847a gh-36628: some simplifications in doctest/ folder (ruff C4)
>> 7354bdb96a0 gh-36627: CI Linux: Build the default platform in one job
>> 407909de675 gh-36625: RSA primes must be odd (textbook code fix)
>> 411b0007256 gh-36621: Build CI: Fix configuration of coverage upload 
>> action
>> 34c4a783f90 gh-36619: `sage.combinat`: Update `# needs`
>> 5151d130641 gh-36618: `sage.modular`: Update `# needs`, doctest cosmetics
>> 6454751583c gh-36616: CI Linux: Increase max_parallel for `standard-pre`, 
>> decrease for `standard`, `minimal-pre`
>> 9f448dd44ad gh-36614: .github/workflows/doc-build-pdf.yml: Do not build 
>> HTML documentation, fix upload of PDFs
>> 6ea89459402 gh-36613: .github/workflows/dist.yml: Fix deprecation message
>> 2df7af70dc9 gh-36612: Replace relative imports by absolute ones in 
>> `sage.libs` except `.ntl`
>> 31f1948f139 gh-36611: fix the links to msolve spkg
>> a0b2ecdb2a3 gh-36609: avoid using `itertools.pairwise`
>> 904519d50d5 gh-36608: some changes by ruff UP
>> 5660360605d gh-36607: write Weyl with a capital letter
>> 23f7eeb0002 gh-36606: ruff fix UP027 (list comprehension)
>> b655bed0b17 gh-36605: Replace relative imports by absolute ones in 
>> `sage.libs.ntl`
>> 2230ce24fb1 gh-36604: Calculation of Maximum Leaf Number graph parameter
>> 92b27f6bdfa gh-36601: Doc preview for all languages
>> d0b1490658f gh-36600: Support giac 1.9.0-67
>> d9868b59c33 gh-36598: Relativize header imports
>> 1a2624f26c9 gh-36596: Replace relative imports by absolute ones in 
>> `sage.{geometry,groups,numerical,plot}`
>> 571320b289f gh-36595: Replace relative imports by absolute ones in 
>> `sage.{coding,combinat,graphs}`
>> 8b52cc35935 gh-36594: Replace relative imports by absolute ones in 
>> `sage.{matrix,matroids,modules,stats}`
>> a717ac0d024 gh-36593: some cleanup in free algebras
>> 1950399d579 gh-36590: Allow to import `sage.cpython` module multiple times
>> 46346a9bcb7 gh-36578: add an example of a divisor on a curve
>> cae95572dca gh-36577: NetworkX: Allow version 3.2
>> d48a8092c12 gh-36573: Replace relative imports by absolute ones in 
>> structure
>> f53e80835da gh-36571: Add method to check whether a (di)graph is geodetic
>> bb7d1466482 gh-36569: `sage.matrix`, `sage.modules`: Update `# needs`
>> e5b774dc629 gh-36568: `sage.manifolds`, `sage.tensor`: Update `# needs`
>> 89f286c0806 gh-36567: `sage.numerical`: Update `# needs`
>> e6c966219af gh-36565: Limit wait for slow mirrors
>> 9c4a5718a3b gh-36563: 
>> `pkgs/sagemath-{objects,categories,environment,repl}`: Move metadata from 
>> `setup.cfg` to `pyproject.toml`
>> 3ee8d4ec871 gh-36559: care for E702 in fast_arith.pyx
>> 28111086e07 gh-36557: src/doc/en/developer: Describe static typing 
>> workflow
>> 1a4599f5f2f gh-36556: some fixes for pycodestyle E221
>> 4b52f1022b5 gh-36555: refresh the file cluster_algebra
>> e48a5c19875 gh-36549: cleanup in number_field_element
>> 8c93da94b61 gh-36548: Support a few more Cython system packages
>> 1674ef85759 gh-36546: refine category of RAAGs
>> 540e835eae7 gh-36544: Support networkx 3.2
>> bfdbb632ce9 gh-36543: Cleanup conditional assert
>> ff67b4425e4 gh-36517: `sage.misc.lazy_attribute`: Add typestub file for 
>> pyright
>> 41625b80277 gh-36477: fplll 5.4.5, fpylll 0.6
>> bfc9c01c09b gh-36453: Exclude Cython 3.0.3
>> 3de6e2

[sage-release] Re: Sage 10.2.rc0 released

[John H Palmieri]

It would be great if #36599 could be merged in the 10.2 cycle: this should 
allow scipy to build with recent versions of OS X + command-line tools, 
without having to build our own gfortran. (It also silences some warnings 
and therefore avoids some doctest failures.)


On Sunday, November 5, 2023 at 9:22:44 AM UTC-8 Volker Braun wrote:

> As always, you can get the latest beta version from the "develop" git 
> branch. Alternatively, the self-contained source tarball is at 
> http://www.sagemath.org/download-latest.html
>
>
> ebef87aa8db (tag: 10.2.rc0, github/develop) Updated SageMath version to 
> 10.2.rc0
> be0b5cf887f gh-36647: fix random doctest error in 
> `src/sage/rings/polynomial/skew_polynomial_finite_field.pyx`
> 4533ffbea9b gh-36639: fix broken pyright in CI
> 636c96c96f8 gh-36636: Deploy live doc on push to develop
> d1da6ba6e3f gh-36635: clean the file hexad.py
> a54d377cc16 gh-36634: permutation_normal_form : case of empty matrices
> 505b6a40e99 gh-36632: .ci/merge-fixes.sh: Reduce output
> 29e95c5847a gh-36628: some simplifications in doctest/ folder (ruff C4)
> 7354bdb96a0 gh-36627: CI Linux: Build the default platform in one job
> 407909de675 gh-36625: RSA primes must be odd (textbook code fix)
> 411b0007256 gh-36621: Build CI: Fix configuration of coverage upload action
> 34c4a783f90 gh-36619: `sage.combinat`: Update `# needs`
> 5151d130641 gh-36618: `sage.modular`: Update `# needs`, doctest cosmetics
> 6454751583c gh-36616: CI Linux: Increase max_parallel for `standard-pre`, 
> decrease for `standard`, `minimal-pre`
> 9f448dd44ad gh-36614: .github/workflows/doc-build-pdf.yml: Do not build 
> HTML documentation, fix upload of PDFs
> 6ea89459402 gh-36613: .github/workflows/dist.yml: Fix deprecation message
> 2df7af70dc9 gh-36612: Replace relative imports by absolute ones in 
> `sage.libs` except `.ntl`
> 31f1948f139 gh-36611: fix the links to msolve spkg
> a0b2ecdb2a3 gh-36609: avoid using `itertools.pairwise`
> 904519d50d5 gh-36608: some changes by ruff UP
> 5660360605d gh-36607: write Weyl with a capital letter
> 23f7eeb0002 gh-36606: ruff fix UP027 (list comprehension)
> b655bed0b17 gh-36605: Replace relative imports by absolute ones in 
> `sage.libs.ntl`
> 2230ce24fb1 gh-36604: Calculation of Maximum Leaf Number graph parameter
> 92b27f6bdfa gh-36601: Doc preview for all languages
> d0b1490658f gh-36600: Support giac 1.9.0-67
> d9868b59c33 gh-36598: Relativize header imports
> 1a2624f26c9 gh-36596: Replace relative imports by absolute ones in 
> `sage.{geometry,groups,numerical,plot}`
> 571320b289f gh-36595: Replace relative imports by absolute ones in 
> `sage.{coding,combinat,graphs}`
> 8b52cc35935 gh-36594: Replace relative imports by absolute ones in 
> `sage.{matrix,matroids,modules,stats}`
> a717ac0d024 gh-36593: some cleanup in free algebras
> 1950399d579 gh-36590: Allow to import `sage.cpython` module multiple times
> 46346a9bcb7 gh-36578: add an example of a divisor on a curve
> cae95572dca gh-36577: NetworkX: Allow version 3.2
> d48a8092c12 gh-36573: Replace relative imports by absolute ones in 
> structure
> f53e80835da gh-36571: Add method to check whether a (di)graph is geodetic
> bb7d1466482 gh-36569: `sage.matrix`, `sage.modules`: Update `# needs`
> e5b774dc629 gh-36568: `sage.manifolds`, `sage.tensor`: Update `# needs`
> 89f286c0806 gh-36567: `sage.numerical`: Update `# needs`
> e6c966219af gh-36565: Limit wait for slow mirrors
> 9c4a5718a3b gh-36563: 
> `pkgs/sagemath-{objects,categories,environment,repl}`: Move metadata from 
> `setup.cfg` to `pyproject.toml`
> 3ee8d4ec871 gh-36559: care for E702 in fast_arith.pyx
> 28111086e07 gh-36557: src/doc/en/developer: Describe static typing workflow
> 1a4599f5f2f gh-36556: some fixes for pycodestyle E221
> 4b52f1022b5 gh-36555: refresh the file cluster_algebra
> e48a5c19875 gh-36549: cleanup in number_field_element
> 8c93da94b61 gh-36548: Support a few more Cython system packages
> 1674ef85759 gh-36546: refine category of RAAGs
> 540e835eae7 gh-36544: Support networkx 3.2
> bfdbb632ce9 gh-36543: Cleanup conditional assert
> ff67b4425e4 gh-36517: `sage.misc.lazy_attribute`: Add typestub file for 
> pyright
> 41625b80277 gh-36477: fplll 5.4.5, fpylll 0.6
> bfc9c01c09b gh-36453: Exclude Cython 3.0.3
> 3de6e29ddc8 gh-36259: `sage.rings.padics`: Update `# needs`
> a901ccc0ebd gh-35269: Implement characteristic polynomial computation for 
> Drinfeld modules of any Rank
> 16dadc96d78 gh-35053: Added kth roots to Permutation
> eb8417b6107 (tag: 10.2.beta9) Updated SageMath version to 10.2.beta9
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-release" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-release+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-release/2f2e6e4a-2ea4-4e7c-9239-73570cedf220n%40googlegroups.com.

[sage-release] Re: Sage 10.2.beta9 released

[John H Palmieri]

I'm seeing one new failure on two different OS X machines (one Intel, one 
M2):

File 
"src/sage/tests/books/computational-mathematics-with-sagemath/mpoly_doctest.py",
 
line 398, in 
sage.tests.books.computational-mathematics-with-sagemath.mpoly_doctest
Failed example:
[CDF['x'](p(y=ys[0][0])).roots() for p in J.gens()] # abs tol 2e-15
Expected:
[[(-0.5999, 1), (0.6001, 1)], 
[(0.6001, 1), (2.601, 1)]]
Got:
[[(-0.5998, 1), (0.5999, 1)],
 [(0.6001 - 6.162975822039155e-33*I, 1),
  (2.6 + 3.0814879110195774e-32*I, 1)]]
**
1 item had failures:
   1 of 161 in 
sage.tests.books.computational-mathematics-with-sagemath.mpoly_doctest
[160 tests, 1 failure, 9.54 s]
--
sage -t --random-seed=151162198507806711540314627633568329221 
src/sage/tests/books/computational-mathematics-with-sagemath/mpoly_doctest.py 
 # 1 doctest failed


On Monday, October 30, 2023 at 5:22:19 PM UTC-7 Volker Braun wrote:

> As always, you can get the latest beta version from the "develop" git 
> branch. Alternatively, the self-contained source tarball is at 
> http://www.sagemath.org/download-latest.html
>
> I'm proposing 10.2.rc0 next, so if there is anything that you want to be 
> merged before then now would be a good time to do so ;)
>
>
> eb8417b6107 (github/develop, tag: 10.2.beta9) Updated SageMath version to 
> 10.2.beta9
> c0221f90a86 gh-36554: Speedup of the method to reduce ternary quadratic 
> forms in the class TernaryQF
> f5bdda94fd4 gh-36553: Add a hash function for the class TernaryQF.
> 37f7f5d5028 gh-36552: `src/sage/misc/cython.py`: Fix the workaround for 
> setuptools_scm
> ccb093422cd gh-36550: remove deprecated name parameter in category ; 
> capital for Coxeter
> 5c6004be074 gh-36547: expurge parent_old from cryptosystem
> 7c6cda9559f gh-36541: `build/pkgs/nauty`: Upgrade to 2.8.6, require nauty 
> >= 2.8
> c8299c7b1b6 gh-36540: `build/pkgs/pip`: Increase lower version bound; 
> upgrade `pip`, `wheel`, `packaging`, `platformdirs`
> 970d7f27c88 gh-36537: refresh the maple(tm) interface
> ee0adcdad3d gh-36535: build/pkgs/openssl: Update to 3.0.12
> 81665ba4a36 gh-36532: `pkgs/sagemath-standard`: Fix sdist
> fef74127ec2 gh-36528: some cleanup in quadratic forms
> d2523e70b00 gh-36522: Fix linter failure E401 multiple imports on one line
> 7c974480400 gh-36521: GH Actions: Fix wheel build
> ac7ed0e2478 gh-36520: `pkgs/sagemath-{bliss,sirocco,tdlib}`: Fix sdists
> dff2b2db763 gh-36516: `sage.schemes.toric`: Remove pyright 'is possibly 
> unbound' warnings
> f79dc7a181f gh-36514: `build/pkgs/sagenb_export`: Fix install-requires.txt
> 5eb0dba9618 gh-36513: `networkx`, `scipy`, `ipywidgets`: Update version 
> ranges in `conda.txt`
> 15b24deb5d7 gh-36511: Exclude symlinks from vscode search config via glob 
> pattern
> 0a0f14180e1 gh-36510: Add pyright ci annotations
> 97b06bd9b4c gh-36509: meson 1.2.3, numpy 1.26.1, require meson >= 1.2.0
> 1185345f0f4 gh-36507: Fix implicit noexcept warnings
> 5b0af6777f8 gh-36506: Support launching notebook 7
> b0569410e72 gh-36499: Remove conda patchelf distro
> a49c36b8d50 gh-36497: lint.yml: Always run all 3 linters
> ca7de640ef3 gh-36496: build*.yml: Fix application of CI fixes broken in 
> #36442
> 26dca91d79e gh-36495: Conditional documentation
> 2c7b52eb7e6 gh-36493: improve method `cycle_basis` for graphs with 
> multiple edges
> 6d304484897 gh-36491: Fix size of varchenko_matrix
> 7a37e8ff681 gh-36488: Fix func_persist: do not use the (now removed) 
> inspect.formatargspec, but instead use inspect.signature.
> 4d20a26e6fb gh-36484: Fix typos in Italian docs
> 83dcc176064 gh-36483: Remove spurious diffs in doc build changes
> d052d9f99e3 gh-36482: Loosen version requirement on fpylll and align its 
> conda version
> 4e658387593 gh-36478: some details in pyx files in combinat
> b297c4d8ec7 gh-36475: .github/workflows/doc-build.yml: Repair display of 
> changes
> 9d3e427285a gh-36466: Run incremental linux ci only when packages changed
> a1e100a22e6 gh-36462: using ruff for UP004, UP008, UP028
> 980f28c681d gh-36444: upgrade cypari2 to 2.1.4
> b62d8401917 gh-36416: `build/pkgs/cython`: Update to 3.0.4
> 652d42948ef gh-36292: Fix sync labels issues for step 2 going live 
> completion
> 6afeae8285b gh-36271: `sage.{dynamics,schemes}`: Modularization fixes, 
> docstring cosmetics, update `# needs`
> b42b3818706 gh-36246: Use URLs to online Sage documents for JupyterLab
> c59ebbb4e18 gh-36144: Revive sage live doc using jupyter-sphinx
> 94682909ba4 gh-35302: update pari to 2.15.4, drop patch
> 07a2afd65fb (tag: 10.2.beta8) Updated SageMath version to 10.2.beta8
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-release" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 

[sage-release] Re: Sage 10.2.beta9 released

[John H Palmieri]

I'm seeing one new failure:

File 
"src/sage/tests/books/computational-mathematics-with-sagemath/mpoly_doctest.py",
 
line 398, in 
sage.tests.books.computational-mathematics-with-sagemath.mpoly_doctest
Failed example:
[CDF['x'](p(y=ys[0][0])).roots() for p in J.gens()] # abs tol 2e-15
Expected:
[[(-0.5999, 1), (0.6001, 1)], 
[(0.6001, 1), (2.601, 1)]]
Got:
[[(-0.5998, 1), (0.5999, 1)],
 [(0.6001 - 6.162975822039155e-33*I, 1),
  (2.6 + 3.0814879110195774e-32*I, 1)]]
**
1 item had failures:
   1 of 161 in 
sage.tests.books.computational-mathematics-with-sagemath.mpoly_doctest
[160 tests, 1 failure, 9.54 s]
--
sage -t --random-seed=151162198507806711540314627633568329221 
src/sage/tests/books/computational-mathematics-with-sagemath/mpoly_doctest.py 
 # 1 doctest failed


On Tuesday, October 31, 2023 at 4:36:41 PM UTC-7 Volker Braun wrote:

> looks like the upload hit a network error, tarball is on the way to the 
> mirrors now
>
> On Tuesday, October 31, 2023 at 6:29:38 PM UTC+1 John H Palmieri wrote:
>
>> I don't see this yet on any mirrors. 
>>
>> On Monday, October 30, 2023 at 5:22:19 PM UTC-7 Volker Braun wrote:
>>
>>> As always, you can get the latest beta version from the "develop" git 
>>> branch. Alternatively, the self-contained source tarball is at 
>>> http://www.sagemath.org/download-latest.html
>>>
>>> I'm proposing 10.2.rc0 next, so if there is anything that you want to be 
>>> merged before then now would be a good time to do so ;)
>>>
>>>
>>> eb8417b6107 (github/develop, tag: 10.2.beta9) Updated SageMath version 
>>> to 10.2.beta9
>>> c0221f90a86 gh-36554: Speedup of the method to reduce ternary quadratic 
>>> forms in the class TernaryQF
>>> f5bdda94fd4 gh-36553: Add a hash function for the class TernaryQF.
>>> 37f7f5d5028 gh-36552: `src/sage/misc/cython.py`: Fix the workaround for 
>>> setuptools_scm
>>> ccb093422cd gh-36550: remove deprecated name parameter in category ; 
>>> capital for Coxeter
>>> 5c6004be074 gh-36547: expurge parent_old from cryptosystem
>>> 7c6cda9559f gh-36541: `build/pkgs/nauty`: Upgrade to 2.8.6, require 
>>> nauty >= 2.8
>>> c8299c7b1b6 gh-36540: `build/pkgs/pip`: Increase lower version bound; 
>>> upgrade `pip`, `wheel`, `packaging`, `platformdirs`
>>> 970d7f27c88 gh-36537: refresh the maple(tm) interface
>>> ee0adcdad3d gh-36535: build/pkgs/openssl: Update to 3.0.12
>>> 81665ba4a36 gh-36532: `pkgs/sagemath-standard`: Fix sdist
>>> fef74127ec2 gh-36528: some cleanup in quadratic forms
>>> d2523e70b00 gh-36522: Fix linter failure E401 multiple imports on one 
>>> line
>>> 7c974480400 gh-36521: GH Actions: Fix wheel build
>>> ac7ed0e2478 gh-36520: `pkgs/sagemath-{bliss,sirocco,tdlib}`: Fix sdists
>>> dff2b2db763 gh-36516: `sage.schemes.toric`: Remove pyright 'is possibly 
>>> unbound' warnings
>>> f79dc7a181f gh-36514: `build/pkgs/sagenb_export`: Fix 
>>> install-requires.txt
>>> 5eb0dba9618 gh-36513: `networkx`, `scipy`, `ipywidgets`: Update version 
>>> ranges in `conda.txt`
>>> 15b24deb5d7 gh-36511: Exclude symlinks from vscode search config via 
>>> glob pattern
>>> 0a0f14180e1 gh-36510: Add pyright ci annotations
>>> 97b06bd9b4c gh-36509: meson 1.2.3, numpy 1.26.1, require meson >= 1.2.0
>>> 1185345f0f4 gh-36507: Fix implicit noexcept warnings
>>> 5b0af6777f8 gh-36506: Support launching notebook 7
>>> b0569410e72 gh-36499: Remove conda patchelf distro
>>> a49c36b8d50 gh-36497: lint.yml: Always run all 3 linters
>>> ca7de640ef3 gh-36496: build*.yml: Fix application of CI fixes broken in 
>>> #36442
>>> 26dca91d79e gh-36495: Conditional documentation
>>> 2c7b52eb7e6 gh-36493: improve method `cycle_basis` for graphs with 
>>> multiple edges
>>> 6d304484897 gh-36491: Fix size of varchenko_matrix
>>> 7a37e8ff681 gh-36488: Fix func_persist: do not use the (now removed) 
>>> inspect.formatargspec, but instead use inspect.signature.
>>> 4d20a26e6fb gh-36484: Fix typos in Italian docs
>>> 83dcc176064 gh-36483: Remove spurious diffs in doc build changes
>>> d052d9f99e3 gh-36482: Loosen version requirement on fpylll and align its 
>>> conda version
>>> 4e658387593 gh-36478: some details in pyx files in combinat
>>> b297c4d8ec7 gh-36475: .github/w

[sage-release] Re: Sage 10.2.beta9 released

[John H Palmieri]

I don't see this yet on any mirrors. 

On Monday, October 30, 2023 at 5:22:19 PM UTC-7 Volker Braun wrote:

> As always, you can get the latest beta version from the "develop" git 
> branch. Alternatively, the self-contained source tarball is at 
> http://www.sagemath.org/download-latest.html
>
> I'm proposing 10.2.rc0 next, so if there is anything that you want to be 
> merged before then now would be a good time to do so ;)
>
>
> eb8417b6107 (github/develop, tag: 10.2.beta9) Updated SageMath version to 
> 10.2.beta9
> c0221f90a86 gh-36554: Speedup of the method to reduce ternary quadratic 
> forms in the class TernaryQF
> f5bdda94fd4 gh-36553: Add a hash function for the class TernaryQF.
> 37f7f5d5028 gh-36552: `src/sage/misc/cython.py`: Fix the workaround for 
> setuptools_scm
> ccb093422cd gh-36550: remove deprecated name parameter in category ; 
> capital for Coxeter
> 5c6004be074 gh-36547: expurge parent_old from cryptosystem
> 7c6cda9559f gh-36541: `build/pkgs/nauty`: Upgrade to 2.8.6, require nauty 
> >= 2.8
> c8299c7b1b6 gh-36540: `build/pkgs/pip`: Increase lower version bound; 
> upgrade `pip`, `wheel`, `packaging`, `platformdirs`
> 970d7f27c88 gh-36537: refresh the maple(tm) interface
> ee0adcdad3d gh-36535: build/pkgs/openssl: Update to 3.0.12
> 81665ba4a36 gh-36532: `pkgs/sagemath-standard`: Fix sdist
> fef74127ec2 gh-36528: some cleanup in quadratic forms
> d2523e70b00 gh-36522: Fix linter failure E401 multiple imports on one line
> 7c974480400 gh-36521: GH Actions: Fix wheel build
> ac7ed0e2478 gh-36520: `pkgs/sagemath-{bliss,sirocco,tdlib}`: Fix sdists
> dff2b2db763 gh-36516: `sage.schemes.toric`: Remove pyright 'is possibly 
> unbound' warnings
> f79dc7a181f gh-36514: `build/pkgs/sagenb_export`: Fix install-requires.txt
> 5eb0dba9618 gh-36513: `networkx`, `scipy`, `ipywidgets`: Update version 
> ranges in `conda.txt`
> 15b24deb5d7 gh-36511: Exclude symlinks from vscode search config via glob 
> pattern
> 0a0f14180e1 gh-36510: Add pyright ci annotations
> 97b06bd9b4c gh-36509: meson 1.2.3, numpy 1.26.1, require meson >= 1.2.0
> 1185345f0f4 gh-36507: Fix implicit noexcept warnings
> 5b0af6777f8 gh-36506: Support launching notebook 7
> b0569410e72 gh-36499: Remove conda patchelf distro
> a49c36b8d50 gh-36497: lint.yml: Always run all 3 linters
> ca7de640ef3 gh-36496: build*.yml: Fix application of CI fixes broken in 
> #36442
> 26dca91d79e gh-36495: Conditional documentation
> 2c7b52eb7e6 gh-36493: improve method `cycle_basis` for graphs with 
> multiple edges
> 6d304484897 gh-36491: Fix size of varchenko_matrix
> 7a37e8ff681 gh-36488: Fix func_persist: do not use the (now removed) 
> inspect.formatargspec, but instead use inspect.signature.
> 4d20a26e6fb gh-36484: Fix typos in Italian docs
> 83dcc176064 gh-36483: Remove spurious diffs in doc build changes
> d052d9f99e3 gh-36482: Loosen version requirement on fpylll and align its 
> conda version
> 4e658387593 gh-36478: some details in pyx files in combinat
> b297c4d8ec7 gh-36475: .github/workflows/doc-build.yml: Repair display of 
> changes
> 9d3e427285a gh-36466: Run incremental linux ci only when packages changed
> a1e100a22e6 gh-36462: using ruff for UP004, UP008, UP028
> 980f28c681d gh-36444: upgrade cypari2 to 2.1.4
> b62d8401917 gh-36416: `build/pkgs/cython`: Update to 3.0.4
> 652d42948ef gh-36292: Fix sync labels issues for step 2 going live 
> completion
> 6afeae8285b gh-36271: `sage.{dynamics,schemes}`: Modularization fixes, 
> docstring cosmetics, update `# needs`
> b42b3818706 gh-36246: Use URLs to online Sage documents for JupyterLab
> c59ebbb4e18 gh-36144: Revive sage live doc using jupyter-sphinx
> 94682909ba4 gh-35302: update pari to 2.15.4, drop patch
> 07a2afd65fb (tag: 10.2.beta8) Updated SageMath version to 10.2.beta8
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-release" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-release+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-release/0bef2957-1ae5-42cc-8b37-6d35e8a8f5fdn%40googlegroups.com.

Re: [sage-support] Computing the kernel of a map between polynomial algebras

[John H Palmieri]

Thanks, Dima. That works for me, too, and it's much faster than Sage was. 
Now I'm trying some bigger examples...


On Monday, October 30, 2023 at 3:56:00 PM UTC-7 Dima Pasechnik wrote:

> Hi John,
> I tried running msolve on your input (more precisely, converting it
> into the problem of
> finding the Grobner basis w.r.t. to the elimination order, as I
> explained), and I see that
> it's an injective map.
>
> Computation takes about 3 minutes on an old laptop.
> Specifically, I merely run msolve at the command line, on the attached
> input file x2,
> and output file y2
> as follows. Here -v 2 is verbosity level, -t 4 means 4 threads, -e 10
> means eliminate
> the 1st 10 variables.
> (I renamed the variables in (almost) alphabetical order, as I thought
> msolve cannot
> handle variable names like you have, but, no it wasn't actually necessary)
>
> As far as I can see, the outputted basis does not have elements which only
> have the varibles in the domain of your map (in x2 they are p, q, r,
> s, t, u, v),
> meaning that the map has no nontrivial kernel.
>
> $ msolve -f x2 -o y2 -v 2 -g 2 -t 4 -e 10
>
> On Mon, Oct 30, 2023 at 9:02 PM Dima Pasechnik  wrote:
> >
> >
> >
> > On Mon, 30 Oct 2023, 20:50 Dima Pasechnik,  wrote:
> >>
> >>
> >>
> >> On Mon, 30 Oct 2023, 20:25 John H Palmieri,  
> wrote:
> >>>
> >>>
> >>>
> >>> On Monday, October 30, 2023 at 12:28:18 PM UTC-7 Dima Pasechnik wrote:
> >>>
> >>> On Mon, Oct 30, 2023 at 5:04 PM John H Palmieri  
> wrote:
> >>> >
> >>> > Are endomorphisms better to work with? I might be able to extend my 
> map to an endomorphism of the larger ring, if that would make the 
> computation easier. Probably just send xi1 -> xi1, xi2 -> xi2, etc.
> >>>
> >>> these are "already there", as if phi is an endomorphism then ker(phi)
> >>> is generated by a-phi(a) - so
> >>> whenever phi(a)=a this reduces to 0.
> >>>
> >>>
> >>>
> >>> I don't understand this. Define phi: k[x,y,z] -> k[x,y,z] by
> >>>
> >>> x -> y
> >>> y -> z
> >>> z -> 0
> >>>
> >>> Then x - phi(x) = x - y is not in the kernel. What do you mean by 
> "ker(phi) is generated by a-phi(a)"?
> >>
> >>
> >> OK, sorry, we're getting confused.
> >> You are interested in checking whether phi, like this:
> >> phi: k[x,y,z] -> k[x',y',z']
> >> x->y', y->z', z->0
> >>
> >> is an epimorphism. This is the same as saying that the kernel of phi, 
> which is the intersection of the ideal
> >> (x-y', y-z', z) in k[x,y,z,x',y',z'] with k[x,y,z], is trivial, i.e., 
> zero. (in this case it's not trivial, it contains z).
> >>
> >> So yes, one can think of phi as inducing an endomorphism of 
> k[x,y,z,x',y',z'], of a special kind.
> >> How this relates to endomorphisms of k[x,y,z], I don't know.
> >
> >
> > if phi had a fixed point, like x->cx with c in k^*,
> > then one could be a bit more economic, and do not introduce x' (and the 
> corresponding ideal generator x-cx'), but immediately substitute it with 
> x/c.
> >
> >
> >>
> >>
> >>>
> >>>
> >>>
> >>> >
> >>> > On Monday, October 30, 2023 at 7:14:16 AM UTC-7 Dima Pasechnik wrote:
> >>> >>
> >>> >> On Mon, Oct 30, 2023 at 12:54 PM Kwankyu  wrote:
> >>> >> >
> >>> >> > Isn't this what you want?
> >>> >> >
> >>> >> > sage: R. = QQ[]
> >>> >> > sage: phi = R.hom([x,x])
> >>> >> > sage: phi
> >>> >> > Ring endomorphism of Multivariate Polynomial Ring in x, y over 
> Rational Field
> >>> >> > Defn: x |--> x
> >>> >> > y |--> x
> >>> >> > sage: phi.kernel()
> >>> >> > Ideal (x - y) of Multivariate Polynomial Ring in x, y over 
> Rational Field
> >>> >>
> >>> >> that's the kernel of the endomorphism phi of R.
> >>> >> John's question is a bit different, and it will require
> >>> >> finding the intersection of such an ideal with the domain of his 
> map.
> >>> >> His R=F_2[h20,...,h50,xi1,...,xi5] and phi induces an endomorphism 
> of
> >>> >> R with the kernel .
> >>> >> Then phi

Re: [sage-support] Computing the kernel of a map between polynomial algebras

[John H Palmieri]

On Monday, October 30, 2023 at 12:28:18 PM UTC-7 Dima Pasechnik wrote:

On Mon, Oct 30, 2023 at 5:04 PM John H Palmieri  
wrote: 
> 
> Are endomorphisms better to work with? I might be able to extend my map 
to an endomorphism of the larger ring, if that would make the computation 
easier. Probably just send xi1 -> xi1, xi2 -> xi2, etc. 

these are "already there", as if phi is an endomorphism then ker(phi) 
is generated by a-phi(a) - so 
whenever phi(a)=a this reduces to 0. 



I don't understand this. Define phi: k[x,y,z] -> k[x,y,z] by

x -> y
y -> z
z -> 0

Then x - phi(x) = x - y  is not in the kernel. What do you mean by 
"ker(phi) is generated by a-phi(a)"?



> 
> On Monday, October 30, 2023 at 7:14:16 AM UTC-7 Dima Pasechnik wrote: 
>> 
>> On Mon, Oct 30, 2023 at 12:54 PM Kwankyu  wrote: 
>> > 
>> > Isn't this what you want? 
>> > 
>> > sage: R. = QQ[] 
>> > sage: phi = R.hom([x,x]) 
>> > sage: phi 
>> > Ring endomorphism of Multivariate Polynomial Ring in x, y over 
Rational Field 
>> > Defn: x |--> x 
>> > y |--> x 
>> > sage: phi.kernel() 
>> > Ideal (x - y) of Multivariate Polynomial Ring in x, y over Rational 
Field 
>> 
>> that's the kernel of the endomorphism phi of R. 
>> John's question is a bit different, and it will require 
>> finding the intersection of such an ideal with the domain of his map. 
>> His R=F_2[h20,...,h50,xi1,...,xi5] and phi induces an endomorphism of 
>> R with the kernel . 
>> Then phi is injective iff the intersection of this ideal with 
>> F_2[h20,...,h50]={0}. 
>> And this needs a Grobner basis computation. 
>> 
>> By the way, using 
>> h30 |--> h20*xi1^4 + h21*xi1 + h30 
>> h31 |--> h21*xi1^8 + h31 
>> 
>> one can split the problem into cases 
>> 1) xi1=0 
>> 2) h21=h20=0 
>> (but perhaps it's only specific to this particular example) 
>> 
>> > 
>> > On Monday, October 30, 2023 at 6:08:16 PM UTC+9 Dima Pasechnik wrote: 
>> >> 
>> >> 
>> >> 
>> >> On Mon, 30 Oct 2023, 05:57 John H Palmieri,  
wrote: 
>> >>> 
>> >>> Does anyone have any tips for how to compute the kernel of a map 
between polynomial algebras, or for checking whether the map is injective? 
I have families of such maps involving algebras with many generators. I'm 
working over GF(2), if that matters. In one example I defined the map phi: 
R -> S where R has 12 generators, S has 19 generators, and did 
>> >>> 
>> >>> sage: phi.is_injective() 
>> >>> 
>> >>> After about 30 hours, Sage quit on me, perhaps running out of memory 
("Killed: 9"). An example of the sort of map I'm interested in: 
>> >>> 
>> >>> sage: phi 
>> >>> Ring morphism: 
>> >>> From: Multivariate Polynomial Ring in h20, h21, h30, h31, h40, h41, 
h50 over Finite Field of size 2 
>> >>> To: Multivariate Polynomial Ring in h20, h21, h30, h31, h40, h41, 
h50, xi1, xi2, xi3, xi4, xi5 over Finite Field of size 2 
>> >>> Defn: h20 |--> h20 
>> >>> h21 |--> h21 
>> >>> h30 |--> h20*xi1^4 + h21*xi1 + h30 
>> >>> h31 |--> h21*xi1^8 + h31 
>> >>> h40 |--> h21*xi1^9 + h30*xi1^8 + h20*xi2^4 + h31*xi1 
>> >>> h41 |--> h31*xi1^16 + h21*xi2^8 
>> >>> h50 |--> h31*xi1^17 + h21*xi1*xi2^8 + h30*xi2^8 + h20*xi3^4 
>> >>> 
>> >>> Any suggestions? 
>> >> 
>> >> 
>> >> The standard way to find the kernel of a map 
>> >> phi: A->B is to take the 
>> >> ring R generated by the gens of A and B and compute the Gröbner basis 
of the ideal I generated by {a-phi(a)|a in gens(A)}, and then 
>> >> take the intersection of I with A. 
>> >> (for the latter you have to take R with an appropriate order) 
>> >> 
>> >> The Gröbner basis would be done by Singular. 
>> >> Better Gröbner basis routines are available in the msolve spkg. 
>> >> 
>> >> I'd try using msolve. There are also options such as computing I 
w.r.t. to an "easier" order and then chaniging the order (so-called Gröbner 
walk), they might work better here (it's all more of art than science here) 
>> >> 
>> >> 
>> >> 
>> >> HTH 
>> >> Dima 
>> >> 
>> >>> 
>> >>> -- 
>> >>> John 
>> >>> 
>> >>> 
>> >>> -- 
>&g

Re: [sage-support] Computing the kernel of a map between polynomial algebras

[John H Palmieri]

Are endomorphisms better to work with? I might be able to extend my map to 
an endomorphism of the larger ring, if that would make the computation 
easier. Probably just send xi1 -> xi1, xi2 -> xi2, etc.

On Monday, October 30, 2023 at 7:14:16 AM UTC-7 Dima Pasechnik wrote:

> On Mon, Oct 30, 2023 at 12:54 PM Kwankyu  wrote:
> >
> > Isn't this what you want?
> >
> > sage: R. = QQ[]
> > sage: phi = R.hom([x,x])
> > sage: phi
> > Ring endomorphism of Multivariate Polynomial Ring in x, y over Rational 
> Field
> > Defn: x |--> x
> > y |--> x
> > sage: phi.kernel()
> > Ideal (x - y) of Multivariate Polynomial Ring in x, y over Rational Field
>
> that's the kernel of the endomorphism phi of R.
> John's question is a bit different, and it will require
> finding the intersection of such an ideal with the domain of his map.
> His R=F_2[h20,...,h50,xi1,...,xi5] and phi induces an endomorphism of
> R with the kernel .
> Then phi is injective iff the intersection of this ideal with
> F_2[h20,...,h50]={0}.
> And this needs a Grobner basis computation.
>
> By the way, using
> h30 |--> h20*xi1^4 + h21*xi1 + h30
> h31 |--> h21*xi1^8 + h31
>
> one can split the problem into cases
> 1) xi1=0
> 2) h21=h20=0
> (but perhaps it's only specific to this particular example)
>
> >
> > On Monday, October 30, 2023 at 6:08:16 PM UTC+9 Dima Pasechnik wrote:
> >>
> >>
> >>
> >> On Mon, 30 Oct 2023, 05:57 John H Palmieri,  
> wrote:
> >>>
> >>> Does anyone have any tips for how to compute the kernel of a map 
> between polynomial algebras, or for checking whether the map is injective? 
> I have families of such maps involving algebras with many generators. I'm 
> working over GF(2), if that matters. In one example I defined the map phi: 
> R -> S where R has 12 generators, S has 19 generators, and did
> >>>
> >>> sage: phi.is_injective()
> >>>
> >>> After about 30 hours, Sage quit on me, perhaps running out of memory 
> ("Killed: 9"). An example of the sort of map I'm interested in:
> >>>
> >>> sage: phi
> >>> Ring morphism:
> >>> From: Multivariate Polynomial Ring in h20, h21, h30, h31, h40, h41, 
> h50 over Finite Field of size 2
> >>> To: Multivariate Polynomial Ring in h20, h21, h30, h31, h40, h41, h50, 
> xi1, xi2, xi3, xi4, xi5 over Finite Field of size 2
> >>> Defn: h20 |--> h20
> >>> h21 |--> h21
> >>> h30 |--> h20*xi1^4 + h21*xi1 + h30
> >>> h31 |--> h21*xi1^8 + h31
> >>> h40 |--> h21*xi1^9 + h30*xi1^8 + h20*xi2^4 + h31*xi1
> >>> h41 |--> h31*xi1^16 + h21*xi2^8
> >>> h50 |--> h31*xi1^17 + h21*xi1*xi2^8 + h30*xi2^8 + h20*xi3^4
> >>>
> >>> Any suggestions?
> >>
> >>
> >> The standard way to find the kernel of a map
> >> phi: A->B is to take the
> >> ring R generated by the gens of A and B and compute the Gröbner basis 
> of the ideal I generated by {a-phi(a)|a in gens(A)}, and then
> >> take the intersection of I with A.
> >> (for the latter you have to take R with an appropriate order)
> >>
> >> The Gröbner basis would be done by Singular.
> >> Better Gröbner basis routines are available in the msolve spkg.
> >>
> >> I'd try using msolve. There are also options such as computing I w.r.t. 
> to an "easier" order and then chaniging the order (so-called Gröbner walk), 
> they might work better here (it's all more of art than science here)
> >>
> >>
> >>
> >> HTH
> >> Dima
> >>
> >>>
> >>> --
> >>> John
> >>>
> >>>
> >>> --
> >>> You received this message because you are subscribed to the Google 
> Groups "sage-support" group.
> >>> To unsubscribe from this group and stop receiving emails from it, send 
> an email to sage-support...@googlegroups.com.
> >>> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-support/97318b8e-f4c9-4af3-a8ff-b901a4f2c971n%40googlegroups.com
> .
> >
> > --
> > You received this message because you are subscribed to the Google 
> Groups "sage-support" group.
> > To unsubscribe from this group and stop receiving emails from it, send 
> an email to sage-support...@googlegroups.com.
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-support/487bf189-fce6-4b6b-9752-178602ff9808n%40googlegroups.com
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-support+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-support/0ddf54b3-1778-4fca-932c-bb5521963db2n%40googlegroups.com.

Re: [sage-support] Computing the kernel of a map between polynomial algebras

[John H Palmieri]

So Sage doesn't already use Gröbner bases when computing kernels of such 
maps? Okay, I'll try that.

Now that I've looked at the code a little bit, I see that 
`phi.is_injective()` just calls `phi.kernel()` and checks whether it's 
zero. I was hoping that there was something more clever: if I want to know 
whether something is injective, I only care whether the kernel is zero, not 
precisely what the kernel is. 

By the way, this struck me as odd:

sage: phi
Ring morphism:
  From: Multivariate Polynomial Ring in h20, h21, h30, h31, h40, h41 over 
Finite Field of size 2
  To:   Multivariate Polynomial Ring in h20, h21, h30, h31, xi1, xi2, xi3, 
xi4 over Finite Field of size 2
  Defn: h20 |--> h20
h21 |--> h21
h30 |--> h20*xi1^4 + h21*xi1 + h30
h31 |--> h21*xi1^8 + h31
h40 |--> h21*xi1^9 + h30*xi1^8 + h20*xi2^4 + h31*xi1
h41 |--> h31*xi1^16 + h21*xi2^8
sage: %time phi.is_injective()
CPU times: user 7.32 s, sys: 58.7 ms, total: 7.38 s
Wall time: 7.44 s
True

Note that phi doesn't do anything very interesting with h20 and h21: it 
sends each of those to itself. If I remove them from the domain (I need to 
keep them in the codomain because they're involved in other terms), the 
computation is slower:

sage: phi
Ring morphism:
  From: Multivariate Polynomial Ring in h30, h31, h40, h41 over Finite 
Field of size 2
  To:   Multivariate Polynomial Ring in h20, h21, h30, h31, xi1, xi2, xi3, 
xi4 over Finite Field of size 2
  Defn: h30 |--> h20*xi1^4 + h21*xi1 + h30
h31 |--> h21*xi1^8 + h31
h40 |--> h21*xi1^9 + h30*xi1^8 + h20*xi2^4 + h31*xi1
h41 |--> h31*xi1^16 + h21*xi2^8
sage: %time phi.is_injective()
CPU times: user 15.7 s, sys: 101 ms, total: 15.8 s
Wall time: 15.9 s
True

I've seen this on two different machines: roughly double the time to do the 
second computation.

On Monday, October 30, 2023 at 7:14:16 AM UTC-7 Dima Pasechnik wrote:

> On Mon, Oct 30, 2023 at 12:54 PM Kwankyu  wrote:
> >
> > Isn't this what you want?
> >
> > sage: R. = QQ[]
> > sage: phi = R.hom([x,x])
> > sage: phi
> > Ring endomorphism of Multivariate Polynomial Ring in x, y over Rational 
> Field
> > Defn: x |--> x
> > y |--> x
> > sage: phi.kernel()
> > Ideal (x - y) of Multivariate Polynomial Ring in x, y over Rational Field
>
> that's the kernel of the endomorphism phi of R.
> John's question is a bit different, and it will require
> finding the intersection of such an ideal with the domain of his map.
> His R=F_2[h20,...,h50,xi1,...,xi5] and phi induces an endomorphism of
> R with the kernel .
> Then phi is injective iff the intersection of this ideal with
> F_2[h20,...,h50]={0}.
> And this needs a Grobner basis computation.
>
> By the way, using
> h30 |--> h20*xi1^4 + h21*xi1 + h30
> h31 |--> h21*xi1^8 + h31
>
> one can split the problem into cases
> 1) xi1=0
> 2) h21=h20=0
> (but perhaps it's only specific to this particular example)
>
> >
> > On Monday, October 30, 2023 at 6:08:16 PM UTC+9 Dima Pasechnik wrote:
> >>
> >>
> >>
> >> On Mon, 30 Oct 2023, 05:57 John H Palmieri,  
> wrote:
> >>>
> >>> Does anyone have any tips for how to compute the kernel of a map 
> between polynomial algebras, or for checking whether the map is injective? 
> I have families of such maps involving algebras with many generators. I'm 
> working over GF(2), if that matters. In one example I defined the map phi: 
> R -> S where R has 12 generators, S has 19 generators, and did
> >>>
> >>> sage: phi.is_injective()
> >>>
> >>> After about 30 hours, Sage quit on me, perhaps running out of memory 
> ("Killed: 9"). An example of the sort of map I'm interested in:
> >>>
> >>> sage: phi
> >>> Ring morphism:
> >>> From: Multivariate Polynomial Ring in h20, h21, h30, h31, h40, h41, 
> h50 over Finite Field of size 2
> >>> To: Multivariate Polynomial Ring in h20, h21, h30, h31, h40, h41, h50, 
> xi1, xi2, xi3, xi4, xi5 over Finite Field of size 2
> >>> Defn: h20 |--> h20
> >>> h21 |--> h21
> >>> h30 |--> h20*xi1^4 + h21*xi1 + h30
> >>> h31 |--> h21*xi1^8 + h31
> >>> h40 |--> h21*xi1^9 + h30*xi1^8 + h20*xi2^4 + h31*xi1
> >>> h41 |--> h31*xi1^16 + h21*xi2^8
> >>> h50 |--> h31*xi1^17 + h21*xi1*xi2^8 + h30*xi2^8 + h20*xi3^4
> >>>
> >>> Any suggestions?
> >>
> >>
> >> The standard way to find the kernel of a map
> >> phi: A->B is to take the
> >> ring R generated by the gens of A and B and compute the Gröbner basis 
> of the ideal I generat

[sage-support] Computing the kernel of a map between polynomial algebras

[John H Palmieri]

Does anyone have any tips for how to compute the kernel of a map between 
polynomial algebras, or for checking whether the map is injective? I have 
families of such maps involving algebras with many generators. I'm working 
over GF(2), if that matters. In one example I defined the map phi: R -> S 
where R has 12 generators, S has 19 generators, and did

sage: phi.is_injective()

After about 30 hours, Sage quit on me, perhaps running out of memory 
("Killed: 9"). An example of the sort of map I'm interested in:

sage: phi
Ring morphism:
  From: Multivariate Polynomial Ring in h20, h21, h30, h31, h40, h41, h50 
over Finite Field of size 2
  To:   Multivariate Polynomial Ring in h20, h21, h30, h31, h40, h41, h50, 
xi1, xi2, xi3, xi4, xi5 over Finite Field of size 2
  Defn: h20 |--> h20
h21 |--> h21
h30 |--> h20*xi1^4 + h21*xi1 + h30
h31 |--> h21*xi1^8 + h31
h40 |--> h21*xi1^9 + h30*xi1^8 + h20*xi2^4 + h31*xi1
h41 |--> h31*xi1^16 + h21*xi2^8
h50 |--> h31*xi1^17 + h21*xi1*xi2^8 + h30*xi2^8 + h20*xi3^4

Any suggestions?

-- 
John


-- 
You received this message because you are subscribed to the Google Groups 
"sage-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-support+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-support/97318b8e-f4c9-4af3-a8ff-b901a4f2c971n%40googlegroups.com.

Re: [sage-support] Re: Canonical divisor help

[John H Palmieri]

Nils, thanks to you, too, for your responses.

On Saturday, October 28, 2023 at 11:16:39 AM UTC-7 Nils Bruin wrote:

> On Saturday, 28 October 2023 at 05:39:26 UTC-7 Kwankyu wrote:
>
> I looked the Magma code in ask.sagemath. There's no problem in computing a 
> canonical divisor for the curve (through the attached function field). 
> Computing a basis of the Riemann-Roch space is no problem as well. Actually 
> the hard part is to construct the morphism from C to P2 from the basis. 
> Magma does this seamlessly. But Sage lacks this functionality (perhaps 
> because I did not implement it). I think, the gist of the matter is to 
> convert an element of the function field to a rational function of the 
> coordinate ring of P2.
>
>
> That's actually trivially simple: if [f1,f2,f3] is the basis of your 
> Riemann-Roch space, you just consider the map defined by [f1:f2:f3]. So you 
> lift f1,f2,f3 to rational functions on the affine space that contains your 
> curve: you just take the rational function representation and forget the 
> algebraic relations between the variables. You now have rational functions 
> in a rational function field, so you can clear denominators there. Now you 
> have a rational map (described by polynomials) A^2->P^r under which the 
> rational image of your curve C in A^2 is the corresponding projective 
> image. Computing that image is the usual groebner-basis operation for 
> finding images of rational maps, so that's potentially quite expensive.
>
> In practice, you know something about the denominators of the 
> representations of f1,f2,f3, so you can probably do a little better.
>
> At its core, that is what the magma code does too, although perhaps it has 
> some smart tricks here and there to try and keep degrees in check a bit.
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-support+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-support/9449eaa0-6470-4cd2-91a5-6780f1faab86n%40googlegroups.com.

Re: [sage-support] Re: Canonical divisor help

[John H Palmieri]

Thanks for all of your posts, Kwankyu. Helpful and informative.

  John


On Saturday, October 28, 2023 at 6:19:48 AM UTC-7 Kwankyu wrote:

> To answer John's question:
>
> sage: P2. = ProjectiveSpace(QQ, 2)
> sage: f = 2*x^5 - 4*x^3*y*z + x^2*y*z^2 + 2*x*y^3*z + 2*x*y^2*z^2+ y^5
> sage: C = P2.curve(f)
> sage: F = C.function_field()
> sage: z, = F.gens()
> sage: K = z.differential().divisor()  # canonical divisor
> sage: (-K).dimension()
> 3
> sage: f1, f2, f3 = (-K).basis_function_space()
> sage: phi = C.hom(P2, [f1,f2,f3]). <--- does not work
> sage: phi.image()  # will work
>
> On Saturday, October 28, 2023 at 9:59:58 PM UTC+9 Kwankyu wrote:
>
>> Let me mention also the related PR 
>>
>> https://github.com/sagemath/sage/pull/35467
>>
>> which implements Jacobian groups of curves (again via function field), 
>> referencing Nils' old code. The PR is long sleeping in draft state. If 
>> anyone finds it useful, I may wake it up. 
>>
>> On Saturday, October 28, 2023 at 9:39:26 PM UTC+9 Kwankyu wrote:
>>
>>> Hi,
>>>
>>> I replied to Dima's comment in 
>>> https://github.com/sagemath/sage/commit/977ace651af9b99689f7b6507f91f8b4e2588ae9#r131138149
>>> . 
>>>
>>> Note that the "divisor" method of a curve had existed long before I 
>>> added function field machinery and attached function fields to curves. 
>>> Hence actually there are two systems of "divisors" of curves in Sage. 
>>>
>>> The old system was implemented by William Stein, David Kohel, and Volker 
>>> Braun. In the old system, a divisor is a formal sum of rational points with 
>>> multiplicities. It is mainly implemented in 
>>> `src/sage/schemes/generic/divisor.py`. Overall it is very rudimentary. Dima 
>>> and John is attempting to use this system.
>>>
>>> The new system was implemented by me. Here a divisor is a formal sum of 
>>> places of a function field with multiplicities. This system is available 
>>> via the function field attached to a curve. This is much more powerful than 
>>> the old system. You can compute the Riemann-Roch space of a divisor. Nils 
>>> is using this system.
>>>
>>> I never attempted to combine the two systems, being afraid of breaking 
>>> the old system (or just being lazy :-) There are similarly two systems in 
>>> Magma too. But in Magma, the two systems are integrated tightly and 
>>> seamlessly. I did some integration in Sage too but far from complete 
>>> compared with Magma.
>>>
>>> I looked the Magma code in ask.sagemath. There's no problem in computing 
>>> a canonical divisor for the curve (through the attached function field). 
>>> Computing a basis of the Riemann-Roch space is no problem as well. Actually 
>>> the hard part is to construct the morphism from C to P2 from the basis. 
>>> Magma does this seamlessly. But Sage lacks this functionality (perhaps 
>>> because I did not implement it). I think, the gist of the matter is to 
>>> convert an element of the function field to a rational function of the 
>>> coordinate ring of P2. I have no idea how to do this now... Once you 
>>> construct the morphism, Sage can also compute the image of the morphism 
>>> (perhaps I implemented this). Hence unfortunately the Magma code cannot be 
>>> line by line converted to Sage code at present.
>>>
>>> On Saturday, October 28, 2023 at 8:27:07 AM UTC+9 Dima Pasechnik wrote:
>>>
>>>> On Sat, Oct 28, 2023 at 1:02 AM John H Palmieri  
>>>> wrote: 
>>>>
>>>> > Yes, I noticed that, too. It also fails to provide any information 
>>>> about what ``v`` should be (beyond saying that it should be a "valid 
>>>> object"): there is no INPUT block. 
>>>>
>>>> I've left a comment here: 
>>>>
>>>> https://github.com/sagemath/sage/commit/977ace651af9b99689f7b6507f91f8b4e2588ae9#r131117132
>>>>  
>>>>
>>>> fortunately, the author, @kwankyu is active 
>>>>
>>>> I can't locate the ticket, but it was merged in 9.0.beta9 
>>>>
>>>>
>>>> > 
>>>> > 
>>>> > On Friday, October 27, 2023 at 3:51:10 PM UTC-7 Dima Pasechnik wrote: 
>>>> >> 
>>>> >> By the way, the docstring of divisor() misses an example, it's 
>>>> >> 
>>>> >> def divisor(self, v, base_ring=None, check=True, reduce=True): 
>>>>

Re: [sage-support] Re: Canonical divisor help

[John H Palmieri]

Hi Dima,

Yes, I noticed that, too. It also fails to provide any information about 
what ``v`` should be (beyond saying that it should be a "valid object"): 
there is no INPUT block.


On Friday, October 27, 2023 at 3:51:10 PM UTC-7 Dima Pasechnik wrote:

> By the way, the docstring of divisor() misses an example, it's
>
> def divisor(self, v, base_ring=None, check=True, reduce=True):
> r"""
> Return the divisor specified by ``v``.
>
> .. WARNING::
>
> The coefficients of the divisor must be in the base ring
> and the terms must be reduced. If you set ``check=False``
> and/or ``reduce=False`` it is your responsibility to pass
> a valid object ``v``.
>
> EXAMPLES::
>
> sage: x,y,z = PolynomialRing(QQ, 3, names='x,y,z').gens()
> sage: C = Curve(y^2*z - x^3 - 17*x*z^2 + y*z^2)
>
> """
>
> Is there an issue for this?
>
> On Sat, Oct 28, 2023 at 12:42 AM Nils Bruin  wrote:
> >
> > A canonical divisor is the divisor of any differential on C so the 
> following does the trick:
> >
> > sage: kC=C.function_field()
> > sage: kC(kC.base_field().gen(0)).differential().divisor()
> >
> > It doesn't look like we quite have computation of Riemann-Roch spaces 
> natively in sage yet, so finding effective representatives requires a 
> little more work. In the RiemannSurface code this is done using singular's 
> adjoint ideal code (or by Baker's theorem in cases where it applies). For 
> this curve the canonical class is of degree -2, so there are no effective 
> representatives in this case.
> >
> > On Friday, 27 October 2023 at 15:14:00 UTC-7 John H Palmieri wrote:
> >>
> >> If anyone here knows anything about canonical divisors and their 
> implementation in Sage, please see 
> https://ask.sagemath.org/question/74034/converting-algebraic-geometry-magmas-code-to-sage/.
>  
> The setup:
> >>
> >> sage: P2. = ProjectiveSpace(QQ, 2)
> >> sage: f = 2*x^5 - 4*x^3*y*z + x^2*y*z^2 + 2*x*y^3*z + 2*x*y^2*z^2+ y^5
> >> sage: C = P2.curve(f)
> >>
> >> How do you get the canonical divisor for C?
> >>
> >> (I encourage you to post answers directly to ask.sagemath.org, if 
> you're willing.)
> >>
> >> --
> >> John
> >>
> > --
> > You received this message because you are subscribed to the Google 
> Groups "sage-support" group.
> > To unsubscribe from this group and stop receiving emails from it, send 
> an email to sage-support...@googlegroups.com.
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-support/91b14570-b83e-4dbf-8bca-0a2eff538a50n%40googlegroups.com
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-support+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-support/391d8ee7-0329-4a15-bc88-4b84973389abn%40googlegroups.com.

[sage-support] Canonical divisor help

[John H Palmieri]

If anyone here knows anything about canonical divisors and their 
implementation in Sage, please see 
https://ask.sagemath.org/question/74034/converting-algebraic-geometry-magmas-code-to-sage/.
 
The setup:

sage: P2. = ProjectiveSpace(QQ, 2)
sage: f = 2*x^5 - 4*x^3*y*z + x^2*y*z^2 + 2*x*y^3*z + 2*x*y^2*z^2+ y^5
sage: C = P2.curve(f)

How do you get the canonical divisor for C?

(I encourage you to post answers directly to ask.sagemath.org, if you're 
willing.)

-- 
John

-- 
You received this message because you are subscribed to the Google Groups 
"sage-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-support+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-support/47f02ff1-8125-4328-a2db-0db270e8eed8n%40googlegroups.com.

[sage-devel] Re: Need Some guidance

[John H Palmieri]

Read the Sage Developer's Guide 
(https://doc.sagemath.org/html/en/developer/) and take a look at the 
current issues for the project (https://github.com/sagemath/sage/issues).

On Tuesday, October 17, 2023 at 10:54:25 AM UTC-7 Himanshu Sharma wrote:

> Hello everyone I am currently new to open source and would love to 
> contribute something. My techstack includes 
> java,Django,python,mysql,apache,phpmyadmin. 
>
> > Please suggest me how to contribute furthur.
> Thank you all
>

-- 
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/f52b88a4-20ef-4cf8-9e82-0d74b0f22f89n%40googlegroups.com.

Re: [sage-release] Re: Sage 10.2.beta6 released

[John H Palmieri]

On Monday, October 9, 2023 at 2:53:57 PM UTC-7 Dima Pasechnik wrote:

On Mon, Oct 9, 2023 at 10:44 PM John H Palmieri  
wrote: 
> 
> 
> 
> On Monday, October 9, 2023 at 9:44:02 AM UTC-7 Dima Pasechnik wrote: 
> 
> On Mon, Oct 9, 2023 at 5:39 PM John H Palmieri  
wrote: 
> > 
> > (I tried to send this last night and I see some indication that the 
message was deleted, so I'm reposting. Apologies if this has already 
appeared.) 
> > 
> > I see some error message (aside from those already reported) but the 
build completes anyway. These are probably not new. 
> > 
> > In pythran's log: 
> > 
> > ERROR: Could not find a version that satisfies the requirement numpy 
(from pythran) (from versions: none) 
> > ERROR: No matching distribution found for numpy 
> 
> numpy is a dependency of pythran, apparently - but it's not listed. 
> 
> 
> It looks like pythran is an order-only dependency of cython which is an 
order-only dependency of numpy, so I guess we're trying to avoid circular 
dependencies by not listing numpy as a dependency of pythran? 

How is it going to help? A circle is not null-homotopic (topology!), 
thus one would need to bootstrap one of the packages... 


How is what going to help? I didn't make any suggestions, although I'm 
wondering how the whole thing works.
 
 



> 
> 
> > 
> > In notebook's log: 
> > 
> > ERROR: Could not find a version that satisfies the requirement 
jupyter_packaging~=0.9 (from versions: none) 
> > ERROR: No matching distribution found for jupyter_packaging~=0.9 
> 
> not sure - I guess it's a good idea to make sure we're switching to 
> modern notebook (7) asap. 
> 
> > 
> > Should we be concerned about these? 
> > 
> > 
> > On Monday, October 9, 2023 at 9:25:44 AM UTC-7 emanuel.c...@gmail.com 
wrote: 
> >> 
> >> 
> >> 
> >> Le lundi 9 octobre 2023 à 18:17:11 UTC+2, Dima Pasechnik a écrit : 
> >> 
> >> [ Snip... ] 
> >> 
> >> > The key seems to be “ERROR: Could not find a version that satisfies 
the requirement hatchling (from versions: none)“, which I do not 
understand.. 
> >> 
> >> just a missing dependency (hatchling) for attrs. 
> >> 
> >> 
> >> as a hotfix, run 
> >> 
> >> make hatchling 
> >> 
> >> 
> >> Seems to work... but fails again : 
> >> 
> >> ``` 
> >> Processing 
/usr/local/sage-10/local/var/lib/sage/venv-python3.11/var/lib/sage/wheels/hatch_vcs-0.3.0-py3-none-any.whl
 

> >> ERROR: Could not find a version that satisfies the requirement 
hatch-fancy-pypi-readme (from versions: none) 
> >> ERROR: No matching distribution found for hatch-fancy-pypi-readme 
> >> error: subprocess-exited-with-error 
> >> ``` 
> >> 
> >> Stuck again... 
> >> 
> >> [ Re-Snip... ] 
> >> 
> >> 
> > -- 
> > You received this message because you are subscribed to the Google 
Groups "sage-release" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
an email to sage-release...@googlegroups.com. 
> > To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-release/44895efa-3007-441d-ae1c-681d7c314d87n%40googlegroups.com.
 

> 
> -- 
> You received this message because you are subscribed to the Google Groups 
"sage-release" group. 
> To unsubscribe from this group and stop receiving emails from it, send an 
email to sage-release...@googlegroups.com. 
> To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-release/46c0210b-17df-43eb-96c1-87855dd38af2n%40googlegroups.com.
 


-- 
You received this message because you are subscribed to the Google Groups 
"sage-release" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-release+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-release/1aa0b02e-50ba-4131-9018-627d48f06b6an%40googlegroups.com.

Re: [sage-release] Re: Sage 10.2.beta6 released

[John H Palmieri]

On Monday, October 9, 2023 at 9:44:02 AM UTC-7 Dima Pasechnik wrote:

On Mon, Oct 9, 2023 at 5:39 PM John H Palmieri  wrote: 
> 
> (I tried to send this last night and I see some indication that the 
message was deleted, so I'm reposting. Apologies if this has already 
appeared.) 
> 
> I see some error message (aside from those already reported) but the 
build completes anyway. These are probably not new. 
> 
> In pythran's log: 
> 
> ERROR: Could not find a version that satisfies the requirement numpy 
(from pythran) (from versions: none) 
> ERROR: No matching distribution found for numpy 

numpy is a dependency of pythran, apparently - but it's not listed. 


It looks like pythran is an order-only dependency of cython which is an 
order-only dependency of numpy, so I guess we're trying to avoid circular 
dependencies by not listing numpy as a dependency of pythran?


> 
> In notebook's log: 
> 
> ERROR: Could not find a version that satisfies the requirement 
jupyter_packaging~=0.9 (from versions: none) 
> ERROR: No matching distribution found for jupyter_packaging~=0.9 

not sure - I guess it's a good idea to make sure we're switching to 
modern notebook (7) asap. 

> 
> Should we be concerned about these? 
> 
> 
> On Monday, October 9, 2023 at 9:25:44 AM UTC-7 emanuel.c...@gmail.com 
wrote: 
>> 
>> 
>> 
>> Le lundi 9 octobre 2023 à 18:17:11 UTC+2, Dima Pasechnik a écrit : 
>> 
>> [ Snip... ] 
>> 
>> > The key seems to be “ERROR: Could not find a version that satisfies 
the requirement hatchling (from versions: none)“, which I do not 
understand.. 
>> 
>> just a missing dependency (hatchling) for attrs. 
>> 
>> 
>> as a hotfix, run 
>> 
>> make hatchling 
>> 
>> 
>> Seems to work... but fails again : 
>> 
>> ``` 
>> Processing 
/usr/local/sage-10/local/var/lib/sage/venv-python3.11/var/lib/sage/wheels/hatch_vcs-0.3.0-py3-none-any.whl
 

>> ERROR: Could not find a version that satisfies the requirement 
hatch-fancy-pypi-readme (from versions: none) 
>> ERROR: No matching distribution found for hatch-fancy-pypi-readme 
>> error: subprocess-exited-with-error 
>> ``` 
>> 
>> Stuck again... 
>> 
>> [ Re-Snip... ] 
>> 
>> 
> -- 
> You received this message because you are subscribed to the Google Groups 
"sage-release" group. 
> To unsubscribe from this group and stop receiving emails from it, send an 
email to sage-release...@googlegroups.com. 
> To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-release/44895efa-3007-441d-ae1c-681d7c314d87n%40googlegroups.com.
 


-- 
You received this message because you are subscribed to the Google Groups 
"sage-release" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-release+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-release/46c0210b-17df-43eb-96c1-87855dd38af2n%40googlegroups.com.

Re: [sage-release] Re: Sage 10.2.beta6 released

[John H Palmieri]

Or as was suggested already, "make -k" to make as many packages as 
possible, and repeat until done.

On Monday, October 9, 2023 at 9:37:49 AM UTC-7 Dima Pasechnik wrote:

> well, I'm sure it's the same story, same fix:
>
> make  hatch-fancy-pypi-readme
>
>
> On Mon, 9 Oct 2023, 17:25 Emmanuel Charpentier,  
> wrote:
>
>>
>>
>> Le lundi 9 octobre 2023 à 18:17:11 UTC+2, Dima Pasechnik a écrit :
>>
>> [ Snip... ]
>>
>> > The key seems to be “ERROR: Could not find a version that satisfies the 
>> requirement hatchling (from versions: none)“, which I do not understand.. 
>>
>> just a missing dependency (hatchling) for attrs. 
>>
>>
>> as a hotfix, run 
>>
>> make hatchling
>>
>>
>> Seems to work...  but fails again :
>>
>> ```
>>   Processing 
>> /usr/local/sage-10/local/var/lib/sage/venv-python3.11/var/lib/sage/wheels/hatch_vcs-0.3.0-py3-none-any.whl
>>   ERROR: Could not find a version that satisfies the requirement 
>> hatch-fancy-pypi-readme (from versions: none)
>>   ERROR: No matching distribution found for hatch-fancy-pypi-readme
>>   error: subprocess-exited-with-error
>> ```
>>
>> Stuck again...
>>
>> [ Re-Snip... ]
>>
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "sage-release" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to sage-release...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/sage-release/8178c74e-4301-4cb1-afd8-798433d4ae42n%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-release" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-release+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-release/5e7570df-d349-4920-a1fd-afaa111a979an%40googlegroups.com.

Re: [sage-release] Re: Sage 10.2.beta6 released

[John H Palmieri]

(I tried to send this last night and I see some indication that the message 
was deleted, so I'm reposting. Apologies if this has already appeared.)

I see some error message (aside from those already reported) but the build 
completes anyway. These are probably not new.

In pythran's log:

ERROR: Could not find a version that satisfies the requirement numpy (from 
pythran) (from versions: none)
ERROR: No matching distribution found for numpy

In notebook's log:

  ERROR: Could not find a version that satisfies the requirement 
jupyter_packaging~=0.9 (from versions: none)
  ERROR: No matching distribution found for jupyter_packaging~=0.9

Should we be concerned about these?


On Monday, October 9, 2023 at 9:25:44 AM UTC-7 emanuel.c...@gmail.com wrote:

>
>
> Le lundi 9 octobre 2023 à 18:17:11 UTC+2, Dima Pasechnik a écrit :
>
> [ Snip... ]
>
> > The key seems to be “ERROR: Could not find a version that satisfies the 
> requirement hatchling (from versions: none)“, which I do not understand.. 
>
> just a missing dependency (hatchling) for attrs. 
>
>
> as a hotfix, run 
>
> make hatchling
>
>
> Seems to work...  but fails again :
>
> ```
>   Processing 
> /usr/local/sage-10/local/var/lib/sage/venv-python3.11/var/lib/sage/wheels/hatch_vcs-0.3.0-py3-none-any.whl
>   ERROR: Could not find a version that satisfies the requirement 
> hatch-fancy-pypi-readme (from versions: none)
>   ERROR: No matching distribution found for hatch-fancy-pypi-readme
>   error: subprocess-exited-with-error
> ```
>
> Stuck again...
>
> [ Re-Snip... ]
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-release" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-release+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-release/44895efa-3007-441d-ae1c-681d7c314d87n%40googlegroups.com.

[sage-release] Re: Sage 10.2.beta6 released

[John H Palmieri]

I see some error message (aside from those already reported) but the build 
completes anyway. These are probably not new.

In pythran's log:

ERROR: Could not find a version that satisfies the requirement numpy (from 
pythran) (from versions: none)
ERROR: No matching distribution found for numpy

In notebook's log:

  ERROR: Could not find a version that satisfies the requirement 
jupyter_packaging~=0.9 (from versions: none)
  ERROR: No matching distribution found for jupyter_packaging~=0.9

Should we be concerned about these?

On Sunday, October 8, 2023 at 12:54:18 PM UTC-7 Volker Braun wrote:

> As always, you can get the latest beta version from the "develop" git 
> branch. Alternatively, the self-contained source tarball is at 
> http://www.sagemath.org/download-latest.html
>
> This release drops support for GCC < 8.4 (Debian 10 "Buster")
>
> 2f1a76dc24a (tag: 10.2.beta6, github/develop) Updated SageMath version to 
> 10.2.beta6
> 46997739f9b gh-36388: fix typographic typos
> 970fd9f1864 gh-36383: Update flint to 2.9.0, arb to 2.23.0
> 6d838ba174a gh-36382: `configure --enable-system-site-packages`: First 
> check all non-site packages
> 5da52a71923 gh-36381: Python package upgrades cherry-picked from notebook 
> 7 upgrade PR
> 726c438330b gh-36378: Add README.md Table of Contents and Links
> f1ac6c1c573 gh-36377: clean one test file
> d2fa61b433c gh-36376: src/sage/databases/sql_db.py: replace tmp_dir()
> aadad8bf506 gh-36375: src/sage/interfaces/gap_workspace.py: replace 
> tmp_dir()
> bc8d82abede gh-36374: refresh the cython file real_roots (pep8, range, etc)
> 16c78cab8ca gh-36373: Enable conda ci for all PRs and remove experimental 
> label
> 17f07d5f076 gh-36371: fix remaining W605 warnings in pxi files
> d8e55296e17 gh-36369: partial cython-lint cleanup in padics/
> 0405d07dde8 gh-36367: Simplify experimental all-conda installation 
> instructions via `pkgs/sage-conf_conda`
> 1af197b2066 gh-36365: Libgap cubegroup
> 16aaae1e34d gh-36364: Do not run sage-env more than once, for real.
> dfcd25fab60 gh-36363: Fix dependencies of `packaging`, update `flit_core` 
> to 3.9.0, `pip` to 23.2.1
> 56533be695f gh-36362: a few more links to errors in the doc
> e33c041bd73 gh-36359: a few details in combinat (designs)
> afd8d0e8194 gh-36358: CI: Fix the multi-stage build in ci-linux.yml, fix 
> conda/centos/archlinux system packages
> b30cc4b7751 gh-36357: CI: Remove ci-wsl, ci-cygwin-standard
> 8550060f96a gh-36355: fixing pep8 E275 in rings/ and combinat/
> 0421fd1745f gh-36352: fix E228 and E225 in coding, crypto, dynamics, 
> geometry, manifolds, modular
> a4017212c20 gh-36348: .github/workflows/build.yml, doc-build.yml: Fix 
> get_ci_fixes
> e1a0794ba97 gh-36344: src/sage/misc/cython.py: replace tmp_dir()
> 0c63ee37742 gh-36343: src/sage/repl/interpreter.py: replace tmp_dir()
> 14c055e0818 gh-36324: src/sage/tests/cmdline.py: replace tmp_dir()
> cb0cea09278 gh-36314: add q-Fuss-Catalan numbers
> fe963ca5a4d gh-36310: Mod 2 (co)homology as a module over the Steenrod 
> algebra
> 119429042c2 gh-36285: add Rémy Oudompheng's implementation of the BMSS 
> algorithm
> 7591b1efafc gh-36277: `sage.graphs`: some care with return ... else 
> statements in `graph.py`, `digraph.py` and `bipartite_graph.py`
> 71428337f16 gh-36273: `sage.graphs`, `sage.combinat.{designs,posets}`, 
> `sage.sandpiles`: Update # needs
> 7c62ef8112b gh-36272: `sage.sets`: Update `# needs`
> 8ebaeff5496 gh-36261: `sage.rings.padics`: Import fixes (modularization)
> ab6f53b50f2 gh-36161: Upgrade pplpy to 0.8.9
> 868fefa1289 gh-36123: Upgrade numpy to 1.26.0, setuptools to 68.2.2
> fdf30fbb1bc gh-35786: onetbb: Upgrade to 2021.9.0 + GCC13 patch
> 1738235b962 gh-35546: compute traces of elliptic-curve endomorphisms
> bd434dae42a gh-35373: Fix workflow "Build documentation (PDF)"
> 1ed5b510362 gh-35285: System package information   tox ini   gh actions 
> for alpine linux
> d687f2e7a73 gh-35062: Enable merge_group trigger for merge queues
> d5d7c461a11 gh-35008: Implement Covering Arrays
> 1cf0c13e527 (tag: 10.2.beta5) Updated SageMath version to 10.2.beta5
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-release" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-release+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-release/7aa351aa-2f96-4843-b873-7cbaeb3c278fn%40googlegroups.com.

Re: [sage-devel] Poll: deprecate backslash operator

[John H Palmieri]

Right. According to the Sage Developer's Guide, "Deprecated code can only 
be removed one year after the first stable release in which it appeared," 
so it will work for at least a year, and then someone would have to take 
further action to remove it completely.

On Wednesday, October 4, 2023 at 12:26:01 PM UTC-7 John Cremona wrote:

> I assume that deprecation means that for a year or so people can still use 
> the backslash but will see a deprecation warning. This could last for quite 
> a long time, so existing code would not immediately break.
>
> On Wed, 4 Oct 2023, 18:41 Thierry Dumont,  
> wrote:
>
>> In "Computational Mathematics with SageMath" we have some backslash...
>>
>> So, if we deprecate it, we will have problems with the doctests 
>> asociated,... and with the book.
>>
>> I don't like the backslash for solving linear systems, but even Julia 
>> has adopted it, probably for Matlab users...
>>
>> t.d.
>>
>> Le 01/10/2023 à 05:17, Nils Bruin a écrit :
>> > Deprecate please.
>> > 
>> > -- 
>> > 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+...@googlegroups.com 
>> > .
>> > To view this discussion on the web visit 
>> > 
>> https://groups.google.com/d/msgid/sage-devel/699f7d70-4222-4f64-8ce4-e606478377a9n%40googlegroups.com
>>  
>> <
>> https://groups.google.com/d/msgid/sage-devel/699f7d70-4222-4f64-8ce4-e606478377a9n%40googlegroups.com?utm_medium=email_source=footer
>> >.
>>
>> -- 
>> 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+...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/sage-devel/90aec6f5-e47d-4981-941b-a7e909bcf518%40math.univ-lyon1.fr
>> .
>>
>

-- 
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/e1253d39-8856-4dae-b631-9e0c406293edn%40googlegroups.com.

[sage-devel] Re: Poll: deprecate backslash operator

[John H Palmieri]

By the way, see https://github.com/sagemath/sage/issues/36194 for a bug 
related to the preparser and "\".

On Tuesday, October 3, 2023 at 9:59:47 PM UTC-7 John H Palmieri wrote:

> The votes are overwhelmingly in favor of deprecating. I have opened 
> https://github.com/sagemath/sage/pull/36394 for this.
>
>
> On Monday, October 2, 2023 at 3:42:38 AM UTC-7 kcrisman wrote:
>
>> Though I am sympathetic to the pro-deprecation arguments and recognize 
>> they will win, I vote do not deprecate, as mission includes Matlab, and for 
>> backwards compatibility.  As an example, the first edition of the 
>> AMS-published "Sage for Undergraduates" used the backslash operator in a 
>> number of examples (comparing it explicitly with other solving methods for 
>> linear systems), so I presume the second edition has maintained that 
>> (though I don't personally own it and can't verify immediately; a related 
>> website does not seem to have all code examples).
>>
>> On Sunday, October 1, 2023 at 6:59:39 AM UTC-4 Ricardo Buring wrote:
>>
>>> Deprecate the pre-parsing of \
>>> the backslash operator please.
>>>
>>>

-- 
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/b6a41814-e185-4d8e-93e3-e868f0115436n%40googlegroups.com.

[sage-devel] Re: Poll: deprecate backslash operator

[John H Palmieri]

The votes are overwhelmingly in favor of deprecating. I have opened 
https://github.com/sagemath/sage/pull/36394 for this.


On Monday, October 2, 2023 at 3:42:38 AM UTC-7 kcrisman wrote:

> Though I am sympathetic to the pro-deprecation arguments and recognize 
> they will win, I vote do not deprecate, as mission includes Matlab, and for 
> backwards compatibility.  As an example, the first edition of the 
> AMS-published "Sage for Undergraduates" used the backslash operator in a 
> number of examples (comparing it explicitly with other solving methods for 
> linear systems), so I presume the second edition has maintained that 
> (though I don't personally own it and can't verify immediately; a related 
> website does not seem to have all code examples).
>
> On Sunday, October 1, 2023 at 6:59:39 AM UTC-4 Ricardo Buring wrote:
>
>> Deprecate the pre-parsing of \
>> the backslash operator please.
>>
>>

-- 
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/41076a42-da81-4875-ad20-6f355c496f08n%40googlegroups.com.

[sage-devel] Poll: deprecate backslash operator

[John H Palmieri]

I asked this already but with a different subject heading, so people may 
have missed it. 

BackslashOperator is defined in "sage/misc/misc.py", and the preparser 
converts "A \ b" to the appropriate Python code. The docstring for 
BackslashOperator says "Implements Matlab-style backslash operator for 
solving systems A \ b". 

This is not used much: for matrices, matroids, and a tiny bit (at least in 
the Sage library) for binary trees. Should we deprecate it?

Arguments for deprecation: the less we rely on the preparser, the better 
(at least as far as easing a transition between Python and Sage, for 
instance). The backslash operator is not in wide use in Sage. Currently its 
implementation breaks the standard Python use of "\" as a line-continuation 
marker.

Arguments against deprecation: it provides a convenient shorthand, and 
people may be familiar with it from Matlab or other systems.

-- 
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/a0659b81-f50f-4b59-91ed-42650409435an%40googlegroups.com.

Re: [sage-release] Sage 10.2.beta5 released

[John H Palmieri]

Some of the doctest failures that I see are being dealt with at #36364; see 
also #36337.

On Friday, September 29, 2023 at 4:39:39 AM UTC-7 Kenji Iohara wrote:

> John: Thanks ! As you mentioned, it worked with `./configure 
> --with-system-gfortran=no`.
>
> But ptestlong has created several doc test failed….
>
> 28/09/2023 23:30、John H Palmieri のメール:
>
> As with the past few releases — and I think this is due to OS X and 
> command-line tool upgrades, not Sage — I have been getting a number of 
> failures due to some warning messages. These continue with 10.2.beta5, and 
> they are addressed by https://github.com/sagemath/sage/pull/36337. The 
> giac-related failures, perhaps starting with OS X 13.3 (
> https://github.com/sagemath/sage/issues/35646), are also still there.
>
>
> On Wednesday, September 27, 2023 at 3:56:29 PM UTC-7 Volker Braun wrote:
>
>> As always, you can get the latest beta version from the "develop" git 
>> branch. Alternatively, the self-contained source tarball is at 
>> http://www.sagemath.org/download-latest.html
>>
>>
>> 1cf0c13e527 (tag: 10.2.beta5, github/develop) Updated SageMath version to 
>> 10.2.beta5
>> b01856309bc gh-36345: `ecm`: Work around build failure with Xcode 15
>> 2c714728fd0 gh-36339: fix expect interface for newer ptyprocess
>> bb04839a5d5 gh-36338: CI: Merge open blocker PRs in all CI workflows + 
>> other improvements
>> a9cb852973a gh-36336: add some class roles for linking Errors in doc
>> 247ea886f0e gh-36335: using more itertools.product
>> f4dc2bc1c8e gh-36330: src/sage/repl/load.py: replace tmp_dir()
>> f6a9058bca4 gh-36327: fix the linter once more
>> 496fb917960 gh-36326: more fixes for E228 and E225 in combinat and some 
>> other folders
>> ccf337e8443 gh-36323: src/sage/combinat/words/words.py: replace tmp_dir()
>> feed3d41ef9 gh-36319: build/pkgs/setuptools_scm_git_archive: Remove 
>> (obsolete)
>> 22a32e79929 gh-36316: build/pkgs/lrcalc_python: add standard python 
>> spkg-configure.m4
>> 034f1f643b7 gh-36299: Generic implementation of fitting ideal
>> c325311ba47 gh-36284: improve checks
>> 0b5fc8e97a0 gh-36276: Yet more spkg_configure for standard python packages
>> ed478e76787 gh-36275: `sage.graphs.generic_graph`: some care with return 
>> ... else statements
>> 602b57114df gh-36270: full pep8 for modular/hecke
>> 4f8a8af331f gh-36267: Change `ipympl`/`pkgconfig`/`widgetsnbextension` to 
>> wheel packages, drop build deps
>> 1af7f8f2b6b gh-36234: Use patchelf from the system
>> ce855de61cb gh-36166: Additions to the bigraded Betti number methods
>> 05d7d1dceeb gh-36110: Update Cython to 3.0.2
>> 5cef467b357 gh-35866: CI build.yml, doc-build.yml: Use output groups
>> 2829cf2182f gh-35537: Fix Sphinx markup in some file
>> 4d3e807ba54 (tag: 10.2.beta4) Updated SageMath version to 10.2.beta4
>>
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "sage-release" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to sage-release...@googlegroups.com.
>
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-release/00d8cc0b-ee7d-424e-a389-1b2130216c8bn%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/sage-release/00d8cc0b-ee7d-424e-a389-1b2130216c8bn%40googlegroups.com?utm_medium=email_source=footer>
> .
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-release" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-release+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-release/3fad5f7a-9d05-4ff5-be3c-1c5b4b9f7ef3n%40googlegroups.com.

Re: [sage-devel] What's the point of GF(2, impl='ntl')?

[John H Palmieri]

First, an error in the original message: it should have been 
"identity_matrix(F, 1)". That doesn't make any difference in the behavior. 
A little exploration suggests that the problem goes away if you make the 
identity matrix sparse: the problem may be with multiplying a dense matrix 
with a vector. I'm not sure about this, though.

This is with the most recent beta, built from scratch on several different 
OS X machines. It also happens on Sagecell. I have not yet opened an issue, 
because there are deeper existential questions: if linear algebra over this 
field is broken, and if there are no doctests to detect that it's broken, 
how viable is this implementation? How long has it been broken? Why has no 
one noticed? What is it used for? Should we keep it?

I think that if someone wanted to add a new implementation of a field to 
Sage today, we would insist on doctests verifying that it worked as a 
drop-in replacement for the existing implementations everywhere in Sage 
where fields get used. GF(2, impl='ntl') does not meet this standard. 
Someone can presumably fix this one bug, but is someone willing to add all 
of the doctests that should really be added?

On Friday, September 29, 2023 at 12:32:14 AM UTC-7 Vincent Delecroix wrote:

> What is your sage version? How did you install it? Did you open an
> issue on github?
>
> Best
> Vincent
>
> On Tue, 26 Sept 2023 at 07:00, John H Palmieri  
> wrote:
> >
> > Setup:
> >
> > sage: F = GF(2, impl='ntl')
> > sage: m_ntl = identity_matrix(1, F)
> > sage: v_ntl = vector(F, (1,))
> >
> > Now consider
> >
> > sage: m_ntl * v_ntl
> > sage: v_ntl * m_ntl
> >
> > I'm trying to multiply a 1x1 matrix by a 1-dimensional vector, in one 
> order or the other. Here's what happens: the first line fails with a 
> SignalError, and the second actually crashes Sage. If we are defining a 
> field that can't do linear algebra, shouldn't there be big warnings posted 
> somewhere? If we are defining a field like this, are there any expectations 
> that it should work broadly with Sage types and constructions? I just 
> discovered that cup products in mod 2 cohomology don't work when "mod 2" 
> means coefficients in GF(2, impl='ntl'), and I don't know if I should 
> bother trying to fix this.
> >
> > For what it's worth, I get the same with `GF(2, impl='givaro')`. Also 
> for what it's worth, explicitly converting `v_ntl` to a matrix allows the 
> matrix multiplication to work.
> >
> > I see this on two different OS X machines, one Intel and one Apple 
> Silicon.
> >
> > --
> > John
> >
> > --
> > 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+...@googlegroups.com.
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-devel/faeffb72-3b16-4f37-90c4-f969e4d5c017n%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/378f06a5-2008-42fb-8642-32019a3a4976n%40googlegroups.com.

[sage-release] Re: Sage 10.2.beta5 released

[John H Palmieri]

As with the past few releases — and I think this is due to OS X and 
command-line tool upgrades, not Sage — I have been getting a number of 
failures due to some warning messages. These continue with 10.2.beta5, and 
they are addressed by https://github.com/sagemath/sage/pull/36337. The 
giac-related failures, perhaps starting with OS X 13.3 
(https://github.com/sagemath/sage/issues/35646), are also still there.


On Wednesday, September 27, 2023 at 3:56:29 PM UTC-7 Volker Braun wrote:

> As always, you can get the latest beta version from the "develop" git 
> branch. Alternatively, the self-contained source tarball is at 
> http://www.sagemath.org/download-latest.html
>
>
> 1cf0c13e527 (tag: 10.2.beta5, github/develop) Updated SageMath version to 
> 10.2.beta5
> b01856309bc gh-36345: `ecm`: Work around build failure with Xcode 15
> 2c714728fd0 gh-36339: fix expect interface for newer ptyprocess
> bb04839a5d5 gh-36338: CI: Merge open blocker PRs in all CI workflows + 
> other improvements
> a9cb852973a gh-36336: add some class roles for linking Errors in doc
> 247ea886f0e gh-36335: using more itertools.product
> f4dc2bc1c8e gh-36330: src/sage/repl/load.py: replace tmp_dir()
> f6a9058bca4 gh-36327: fix the linter once more
> 496fb917960 gh-36326: more fixes for E228 and E225 in combinat and some 
> other folders
> ccf337e8443 gh-36323: src/sage/combinat/words/words.py: replace tmp_dir()
> feed3d41ef9 gh-36319: build/pkgs/setuptools_scm_git_archive: Remove 
> (obsolete)
> 22a32e79929 gh-36316: build/pkgs/lrcalc_python: add standard python 
> spkg-configure.m4
> 034f1f643b7 gh-36299: Generic implementation of fitting ideal
> c325311ba47 gh-36284: improve checks
> 0b5fc8e97a0 gh-36276: Yet more spkg_configure for standard python packages
> ed478e76787 gh-36275: `sage.graphs.generic_graph`: some care with return 
> ... else statements
> 602b57114df gh-36270: full pep8 for modular/hecke
> 4f8a8af331f gh-36267: Change `ipympl`/`pkgconfig`/`widgetsnbextension` to 
> wheel packages, drop build deps
> 1af7f8f2b6b gh-36234: Use patchelf from the system
> ce855de61cb gh-36166: Additions to the bigraded Betti number methods
> 05d7d1dceeb gh-36110: Update Cython to 3.0.2
> 5cef467b357 gh-35866: CI build.yml, doc-build.yml: Use output groups
> 2829cf2182f gh-35537: Fix Sphinx markup in some file
> 4d3e807ba54 (tag: 10.2.beta4) Updated SageMath version to 10.2.beta4
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-release" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-release+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-release/00d8cc0b-ee7d-424e-a389-1b2130216c8bn%40googlegroups.com.

Re: [sage-release] Sage 10.2.beta5 released

[John H Palmieri]

Kenji: for me with updated homebrew etc., I can only get scipy to build if 
I configure Sage with `./configure --with-system-gfortran=no`.

On Thursday, September 28, 2023 at 3:49:04 AM UTC-7 Kenji Iohara wrote:

> On my Mac OS 13.6 with Intel Core i5, with updated homebrew and Xcode 15, 
> Python 3.11.5, 
> The first built has failed with the package  scipy-1.11.2 and not with 
> ecm…. !
> Here is its log file: 
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-release" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-release+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-release/50635a88-807f-49f4-9a34-2b85a8f0875fn%40googlegroups.com.

Re: [sage-devel] Discussion and poll: should Sage Integers have a backslash operator?

[John H Palmieri]

Okay, so maybe we should open this to other options: should we get rid of 
preparsing "\" into "BackslashOperator"?

For what it's worth, I removed the line defining `_backslash_` in 
binary_tree.py and and I only say one doctest failure in any obvious places 
(combinat and thematic_tutorials). So it's not even used much. Same for 
matroids.

I think that using \ to escape characters in strings still works, but 
line-continuation does not: in Sage, these fail:

sage: a = 3 + \

and

sage: \

whereas in pure Python, such backslashes would be treated as 
line-continuations. It should be possible to fix this while keeping the 
current preparser behavior for "\" in the middle of a line. Or as Nils 
proposes, getting rid of the current preparser behavior should also solve 
it.

On Wednesday, September 27, 2023 at 2:44:19 PM UTC-7 Nils Bruin wrote:

> I'm quite strongly against because it collides with a well-established 
> meaning of `\` in python: escape character. It's used to avoid command 
> termination by newline in things like formulas (as "\ parsed as whitespace rather than command termination outside of brackets).
>
> I'm in fact rather shocked that `\` in sage already doesn't work as it's 
> supposed to in python but instead gets substituted as "BackslashOperator()".
>
> Searching the codebase currently only shows "_backslash_" implemented on 
> matroid, matrix, and binary_tree, so extinguishing it should be doable. We 
> should definitely not entrench its use further.
>
> If you want to write your denominator first, you can already do ~2 * 3 . I 
> think that's already sufficiently perverse that we don't need another way 
> to spell that.
> On Wednesday, 27 September 2023 at 12:16:57 UTC-7 David Joyner wrote:
>
>> On Wed, Sep 27, 2023 at 2:32 PM John H Palmieri  
>> wrote:
>>
>>> The github issue #36060 (https://github.com/sagemath/sage/issues/36060) 
>>> proposes adding a backslash operator for Sage integers, so that "2 \ 3" 
>>> will return the same as "3 / 2". Do you support this?
>>>
>>>
>> I'm not for or against. However, I don't see the problem that 
>> implementing this "\" is going to solve. The ticket suggests that users 
>> will naturally type 2\3 instead of 3/2, if I am reading between the lines 
>> correctly. 
>>  
>>
>>> BackslashOperator is defined in "sage/misc/misc.py", and the preparser 
>>> converts "A \ b" to the appropriate Python code. The docstring for 
>>> BackslashOperator says "Implements Matlab-style backslash operator for 
>>> solving systems A \ b". 
>>>
>>> It seems pretty innocuous to me — in fact I don't care much either way — 
>>> but since Sage integers are so ubiquitous, it seems like a good idea to ask 
>>> before implementing it.
>>>
>>> -- 
>>> John
>>>
>>> -- 
>>> 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+...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/sage-devel/3f157aa4-74cd-4c5c-bc76-f198c6417432n%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/sage-devel/3f157aa4-74cd-4c5c-bc76-f198c6417432n%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>>

-- 
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/941e7314-5f78-454a-9017-fe752c630233n%40googlegroups.com.

[sage-devel] Discussion and poll: should Sage Integers have a backslash operator?

[John H Palmieri]

The github issue #36060 (https://github.com/sagemath/sage/issues/36060) 
proposes adding a backslash operator for Sage integers, so that "2 \ 3" 
will return the same as "3 / 2". Do you support this?

BackslashOperator is defined in "sage/misc/misc.py", and the preparser 
converts "A \ b" to the appropriate Python code. The docstring for 
BackslashOperator says "Implements Matlab-style backslash operator for 
solving systems A \ b". 

It seems pretty innocuous to me — in fact I don't care much either way — 
but since Sage integers are so ubiquitous, it seems like a good idea to ask 
before implementing it.

-- 
John

-- 
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/3f157aa4-74cd-4c5c-bc76-f198c6417432n%40googlegroups.com.

[sage-devel] What's the point of GF(2, impl='ntl')?

[John H Palmieri]

Setup:

sage: F = GF(2, impl='ntl')
sage: m_ntl = identity_matrix(1, F)
sage: v_ntl = vector(F, (1,))

Now consider

sage: m_ntl * v_ntl
sage: v_ntl * m_ntl

I'm trying to multiply a 1x1 matrix by a 1-dimensional vector, in one order 
or the other. Here's what happens: the first line fails with a SignalError, 
and the second actually crashes Sage. If we are defining a field that can't 
do linear algebra, shouldn't there be big warnings posted somewhere? If we 
are defining a field like this, are there any expectations that it should 
work broadly with Sage types and constructions? I just discovered that cup 
products in mod 2 cohomology don't work when "mod 2" means coefficients in 
GF(2, impl='ntl'), and I don't know if I should bother trying to fix this.

For what it's worth, I get the same with `GF(2, impl='givaro')`. Also for 
what it's worth, explicitly converting `v_ntl` to a matrix allows the 
matrix multiplication to work. 

I see this on two different OS X machines, one Intel and one Apple Silicon.

-- 
John

-- 
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/faeffb72-3b16-4f37-90c4-f969e4d5c017n%40googlegroups.com.

Re: [sage-release] Sage 10.2.beta4 released

[John H Palmieri]

I opened up https://github.com/sagemath/sage/pull/36337 for these ld 
warnings, in case anyone else runs into the same problems.

On Monday, September 25, 2023 at 12:05:38 PM UTC-7 John H Palmieri wrote:

> I'm see these warning messages cause doctests to fail:
>
> ld: warning: duplicate -rpath 
> '/Users/jpalmier/Desktop/Sage/TESTING/sage-10.2.beta4/local/lib' ignored
>
> and
>
> ld: warning: ignoring duplicate libraries: '-lpari'
>
> Should we bypass them in doctest/parsing.py, the way we have in the past?
>
> On Monday, September 25, 2023 at 12:50:45 AM UTC-7 Kenji Iohara wrote:
>
>> On MacOS 13.5.2, with  updated homebrew, updated python, the first built 
>> compilation failed owing to two packages:
>>
>> ecm-7.0.5 and scipy-1.11.2. Here is their log files.
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-release" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-release+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-release/320593db-c47e-415e-8127-1cde44c7c8d6n%40googlegroups.com.

Re: [sage-release] Sage 10.2.beta4 released

[John H Palmieri]

I'm see these warning messages cause doctests to fail:

ld: warning: duplicate -rpath 
'/Users/jpalmier/Desktop/Sage/TESTING/sage-10.2.beta4/local/lib' ignored

and

ld: warning: ignoring duplicate libraries: '-lpari'

Should we bypass them in doctest/parsing.py, the way we have in the past?

On Monday, September 25, 2023 at 12:50:45 AM UTC-7 Kenji Iohara wrote:

> On MacOS 13.5.2, with  updated homebrew, updated python, the first built 
> compilation failed owing to two packages:
>
> ecm-7.0.5 and scipy-1.11.2. Here is their log files.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-release" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-release+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-release/72131ba6-11b6-4a05-96bb-cdb7d6a68c59n%40googlegroups.com.

Re: [sage-release] Re: Sage 10.2.beta3 released

[John H Palmieri]

I've already tried uninstalling and reinstalling every homebrew package, 
and it didn't help. I've also been doing "make distclean" and "./configure" 
in between attempts. 

I'm confused about your comment about meson_python: I don't think that Sage 
ordinarily uses a system package of this (except on gentoo?), so it always 
builds its own. It is using the homebrew installation of meson. I do not 
have the homebrew meson-python package.

On Sunday, September 24, 2023 at 3:28:22 AM UTC-7 Dima Pasechnik wrote:

> both meson and meson_python may potentially come from the system (homebrew 
> in your case).
> Make sure they are up to date, and you don't have these packages installed 
> in Sage.
> And run ./configure
>
> Perhaps the whole homebrew must be reinstated after an OS update, too. 
>
> On Sun, 24 Sept 2023, 03:07 John H Palmieri,  wrote:
>
>> Building Sage's own gfortran worked to build scipy (and this is an 
>> argument to keep the gfortran package around, by the way).
>>
>> Alternatively, building all of scipy's dependencies and then using 
>> `./sage --python3 -m pip install scipy` also seems to have worked. I then 
>> "touch"ed the appropriate file to convince Sage that scipy had built, and 
>> the rest of the build succeeded, except for some extra warnings during 
>> doctests: "ld: warning: duplicate -rpath [...SAGE_ROOT/local/lib...] 
>> ignored"
>>
>> On Saturday, September 23, 2023 at 3:59:40 PM UTC-7 John H Palmieri wrote:
>>
>>> If by "they" you mean scipy, then: I have no problems building scipy on 
>>> another OS X machine: an Intel machine running OS X 13.5.2 (rather than 
>>> 13.6). "xcode-select --version" reports the same for both machines, but I 
>>> don't know how informative this is. "gfortran --version" says
>>>
>>> GNU Fortran (Homebrew GCC 13.2.0) 13.2.0
>>> Copyright (C) 2023 Free Software Foundation, Inc.
>>> This is free software; see the source for copying conditions.  There is 
>>> NO
>>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR 
>>> PURPOSE.
>>>
>>> and this is the one that scipy finds. On the M2 machine, Sage's scipy 
>>> built back in August with earlier versions of the OS (probably 13.5.2) and 
>>> command-line tools and gfortran (13.1.0).
>>>
>>>
>>> On Saturday, September 23, 2023 at 3:34:29 PM UTC-7 Dima Pasechnik wrote:
>>>
>>>> do they even support gcc/gfortran 13?
>>>>
>>>> On Sat, 23 Sept 2023, 23:04 John H Palmieri,  
>>>> wrote:
>>>>
>>>>> Same result if I do `pip3 install scipy --no-binary scipy` (another of 
>>>>> their suggested ways of building from source). I guess something is 
>>>>> broken 
>>>>> with my fortran compiler, but I don't know how to troubleshoot it.
>>>>>
>>>>> On Saturday, September 23, 2023 at 2:35:52 PM UTC-7 John H Palmieri 
>>>>> wrote:
>>>>>
>>>>>> It didn't work for me. At least directly attempting a scipy build 
>>>>>> left an intact log file. Any clues about what's broken on this machine?
>>>>>>
>>>>>> Build started at 2023-09-23T14:31:26.723020
>>>>>> Main binary: /Users/palmieri/Downloads/scipy-1.11.2/venv/bin/python3
>>>>>> Build Options: 
>>>>>> -Dprefix=/Users/palmieri/Downloads/scipy-1.11.2/build-install
>>>>>> Python system: Darwin
>>>>>> The Meson build system
>>>>>> Version: 1.2.1
>>>>>> Source dir: /Users/palmieri/Downloads/scipy-1.11.2
>>>>>> Build dir: /Users/palmieri/Downloads/scipy-1.11.2/build
>>>>>> Build type: native build
>>>>>> Project name: SciPy
>>>>>> Project version: 1.11.2
>>>>>> ---
>>>>>> Detecting compiler via: `cc --version` -> 0
>>>>>> stdout:
>>>>>> Apple clang version 15.0.0 (clang-1500.0.40.1)
>>>>>> Target: arm64-apple-darwin22.6.0
>>>>>> Thread model: posix
>>>>>> InstalledDir: /Library/Developer/CommandLineTools/usr/bin
>>>>>> ---
>>>>>> Running command: cc -E -dM -
>>>>>> -
>>>>>> ---
>>>>>> Detecting linker via: `cc -Wl,--version` -> 1
>>>>>> stderr:
>>>>>> ld: unknown options: --version 
>>>&

Re: [sage-release] Re: Sage 10.2.beta3 released

[John H Palmieri]

Building Sage's own gfortran worked to build scipy (and this is an argument 
to keep the gfortran package around, by the way).

Alternatively, building all of scipy's dependencies and then using `./sage 
--python3 -m pip install scipy` also seems to have worked. I then "touch"ed 
the appropriate file to convince Sage that scipy had built, and the rest of 
the build succeeded, except for some extra warnings during doctests: "ld: 
warning: duplicate -rpath [...SAGE_ROOT/local/lib...] ignored"

On Saturday, September 23, 2023 at 3:59:40 PM UTC-7 John H Palmieri wrote:

> If by "they" you mean scipy, then: I have no problems building scipy on 
> another OS X machine: an Intel machine running OS X 13.5.2 (rather than 
> 13.6). "xcode-select --version" reports the same for both machines, but I 
> don't know how informative this is. "gfortran --version" says
>
> GNU Fortran (Homebrew GCC 13.2.0) 13.2.0
> Copyright (C) 2023 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> and this is the one that scipy finds. On the M2 machine, Sage's scipy 
> built back in August with earlier versions of the OS (probably 13.5.2) and 
> command-line tools and gfortran (13.1.0).
>
>
> On Saturday, September 23, 2023 at 3:34:29 PM UTC-7 Dima Pasechnik wrote:
>
>> do they even support gcc/gfortran 13?
>>
>> On Sat, 23 Sept 2023, 23:04 John H Palmieri,  wrote:
>>
>>> Same result if I do `pip3 install scipy --no-binary scipy` (another of 
>>> their suggested ways of building from source). I guess something is broken 
>>> with my fortran compiler, but I don't know how to troubleshoot it.
>>>
>>> On Saturday, September 23, 2023 at 2:35:52 PM UTC-7 John H Palmieri 
>>> wrote:
>>>
>>>> It didn't work for me. At least directly attempting a scipy build left 
>>>> an intact log file. Any clues about what's broken on this machine?
>>>>
>>>> Build started at 2023-09-23T14:31:26.723020
>>>> Main binary: /Users/palmieri/Downloads/scipy-1.11.2/venv/bin/python3
>>>> Build Options: 
>>>> -Dprefix=/Users/palmieri/Downloads/scipy-1.11.2/build-install
>>>> Python system: Darwin
>>>> The Meson build system
>>>> Version: 1.2.1
>>>> Source dir: /Users/palmieri/Downloads/scipy-1.11.2
>>>> Build dir: /Users/palmieri/Downloads/scipy-1.11.2/build
>>>> Build type: native build
>>>> Project name: SciPy
>>>> Project version: 1.11.2
>>>> ---
>>>> Detecting compiler via: `cc --version` -> 0
>>>> stdout:
>>>> Apple clang version 15.0.0 (clang-1500.0.40.1)
>>>> Target: arm64-apple-darwin22.6.0
>>>> Thread model: posix
>>>> InstalledDir: /Library/Developer/CommandLineTools/usr/bin
>>>> ---
>>>> Running command: cc -E -dM -
>>>> -
>>>> ---
>>>> Detecting linker via: `cc -Wl,--version` -> 1
>>>> stderr:
>>>> ld: unknown options: --version 
>>>> clang: error: linker command failed with exit code 1 (use -v to see 
>>>> invocation)
>>>> ---
>>>> ---
>>>> Detecting Apple linker via: `cc -Wl,-v` -> 1
>>>> stderr:
>>>> @(#)PROGRAM:ld  PROJECT:dyld-1015.7
>>>> BUILD 18:48:48 Aug 22 2023
>>>> configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 
>>>> i386 x86_64 x86_64h armv6m armv7k armv7m armv7em
>>>> will use ld-classic for: armv6 armv7 armv7s arm64_32 i386 armv6m armv7k 
>>>> armv7m armv7em
>>>> LTO support using: LLVM version 15.0.0 (static support for 29, runtime 
>>>> is 29)
>>>> TAPI support using: Apple TAPI version 15.0.0 (tapi-1500.0.12.3)
>>>> Library search paths:
>>>> /opt/homebrew/opt/primesieve/lib
>>>> /opt/homebrew/opt/bdw-gc/lib
>>>> /opt/homebrew/opt/libpng/lib
>>>> /opt/homebrew/opt/ntl/lib
>>>> /opt/homebrew/opt/bzip2/lib
>>>> /opt/homebrew/opt/readline/lib
>>>> /opt/homebrew/lib
>>>> /usr/local/lib
>>>> Framework search paths:
>>>> ld: Undefined symbols:
>>>>   _main, referenced from:
>>>>   
>>>> clang: error: linker command failed with exit code 1 (use -v to see 
>>>> invocation)
>>>> ---
>>>> Sanity testing C compiler: cc
>&g

Re: [sage-release] Re: Sage 10.2.beta3 released

[John H Palmieri]

If by "they" you mean scipy, then: I have no problems building scipy on 
another OS X machine: an Intel machine running OS X 13.5.2 (rather than 
13.6). "xcode-select --version" reports the same for both machines, but I 
don't know how informative this is. "gfortran --version" says

GNU Fortran (Homebrew GCC 13.2.0) 13.2.0
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

and this is the one that scipy finds. On the M2 machine, Sage's scipy built 
back in August with earlier versions of the OS (probably 13.5.2) and 
command-line tools and gfortran (13.1.0).


On Saturday, September 23, 2023 at 3:34:29 PM UTC-7 Dima Pasechnik wrote:

> do they even support gcc/gfortran 13?
>
> On Sat, 23 Sept 2023, 23:04 John H Palmieri,  wrote:
>
>> Same result if I do `pip3 install scipy --no-binary scipy` (another of 
>> their suggested ways of building from source). I guess something is broken 
>> with my fortran compiler, but I don't know how to troubleshoot it.
>>
>> On Saturday, September 23, 2023 at 2:35:52 PM UTC-7 John H Palmieri wrote:
>>
>>> It didn't work for me. At least directly attempting a scipy build left 
>>> an intact log file. Any clues about what's broken on this machine?
>>>
>>> Build started at 2023-09-23T14:31:26.723020
>>> Main binary: /Users/palmieri/Downloads/scipy-1.11.2/venv/bin/python3
>>> Build Options: 
>>> -Dprefix=/Users/palmieri/Downloads/scipy-1.11.2/build-install
>>> Python system: Darwin
>>> The Meson build system
>>> Version: 1.2.1
>>> Source dir: /Users/palmieri/Downloads/scipy-1.11.2
>>> Build dir: /Users/palmieri/Downloads/scipy-1.11.2/build
>>> Build type: native build
>>> Project name: SciPy
>>> Project version: 1.11.2
>>> ---
>>> Detecting compiler via: `cc --version` -> 0
>>> stdout:
>>> Apple clang version 15.0.0 (clang-1500.0.40.1)
>>> Target: arm64-apple-darwin22.6.0
>>> Thread model: posix
>>> InstalledDir: /Library/Developer/CommandLineTools/usr/bin
>>> ---
>>> Running command: cc -E -dM -
>>> -
>>> ---
>>> Detecting linker via: `cc -Wl,--version` -> 1
>>> stderr:
>>> ld: unknown options: --version 
>>> clang: error: linker command failed with exit code 1 (use -v to see 
>>> invocation)
>>> ---
>>> ---
>>> Detecting Apple linker via: `cc -Wl,-v` -> 1
>>> stderr:
>>> @(#)PROGRAM:ld  PROJECT:dyld-1015.7
>>> BUILD 18:48:48 Aug 22 2023
>>> configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 
>>> i386 x86_64 x86_64h armv6m armv7k armv7m armv7em
>>> will use ld-classic for: armv6 armv7 armv7s arm64_32 i386 armv6m armv7k 
>>> armv7m armv7em
>>> LTO support using: LLVM version 15.0.0 (static support for 29, runtime 
>>> is 29)
>>> TAPI support using: Apple TAPI version 15.0.0 (tapi-1500.0.12.3)
>>> Library search paths:
>>> /opt/homebrew/opt/primesieve/lib
>>> /opt/homebrew/opt/bdw-gc/lib
>>> /opt/homebrew/opt/libpng/lib
>>> /opt/homebrew/opt/ntl/lib
>>> /opt/homebrew/opt/bzip2/lib
>>> /opt/homebrew/opt/readline/lib
>>> /opt/homebrew/lib
>>> /usr/local/lib
>>> Framework search paths:
>>> ld: Undefined symbols:
>>>   _main, referenced from:
>>>   
>>> clang: error: linker command failed with exit code 1 (use -v to see 
>>> invocation)
>>> ---
>>> Sanity testing C compiler: cc
>>> Is cross compiler: False.
>>> Sanity check compiler command line: cc sanitycheckc.c -o sanitycheckc.exe
>>> Sanity check compile stdout:
>>>
>>> -
>>> Sanity check compile stderr:
>>>
>>> -
>>> Running test binary command: 
>>>  /Users/palmieri/Downloads/scipy-1.11.2/build/meson-private/sanitycheckc.exe
>>> C compiler for the host machine: cc (clang 15.0.0 "Apple clang version 
>>> 15.0.0 (clang-1500.0.40.1)")
>>> C linker for the host machine: cc ld64 1015.7
>>> ---
>>> Detecting linker via: `ar --version` -> 1
>>> stderr:
>>> usage:  ar -d [-TLsv] archive file ...
>>> ar -m [-TLsv] archive file ...
>>> ar -m [-abiTLsv] position archive file ...
>>> ar -p [-TLsv] archive [file ...]
>>> ar -q [-cTLsv] archive file ...
>>> ar -r 

Re: [sage-release] Re: Sage 10.2.beta3 released

[John H Palmieri]

Same result if I do `pip3 install scipy --no-binary scipy` (another of 
their suggested ways of building from source). I guess something is broken 
with my fortran compiler, but I don't know how to troubleshoot it.

On Saturday, September 23, 2023 at 2:35:52 PM UTC-7 John H Palmieri wrote:

> It didn't work for me. At least directly attempting a scipy build left an 
> intact log file. Any clues about what's broken on this machine?
>
> Build started at 2023-09-23T14:31:26.723020
> Main binary: /Users/palmieri/Downloads/scipy-1.11.2/venv/bin/python3
> Build Options: 
> -Dprefix=/Users/palmieri/Downloads/scipy-1.11.2/build-install
> Python system: Darwin
> The Meson build system
> Version: 1.2.1
> Source dir: /Users/palmieri/Downloads/scipy-1.11.2
> Build dir: /Users/palmieri/Downloads/scipy-1.11.2/build
> Build type: native build
> Project name: SciPy
> Project version: 1.11.2
> ---
> Detecting compiler via: `cc --version` -> 0
> stdout:
> Apple clang version 15.0.0 (clang-1500.0.40.1)
> Target: arm64-apple-darwin22.6.0
> Thread model: posix
> InstalledDir: /Library/Developer/CommandLineTools/usr/bin
> ---
> Running command: cc -E -dM -
> -
> ---
> Detecting linker via: `cc -Wl,--version` -> 1
> stderr:
> ld: unknown options: --version 
> clang: error: linker command failed with exit code 1 (use -v to see 
> invocation)
> ---
> ---
> Detecting Apple linker via: `cc -Wl,-v` -> 1
> stderr:
> @(#)PROGRAM:ld  PROJECT:dyld-1015.7
> BUILD 18:48:48 Aug 22 2023
> configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 i386 
> x86_64 x86_64h armv6m armv7k armv7m armv7em
> will use ld-classic for: armv6 armv7 armv7s arm64_32 i386 armv6m armv7k 
> armv7m armv7em
> LTO support using: LLVM version 15.0.0 (static support for 29, runtime is 
> 29)
> TAPI support using: Apple TAPI version 15.0.0 (tapi-1500.0.12.3)
> Library search paths:
> /opt/homebrew/opt/primesieve/lib
> /opt/homebrew/opt/bdw-gc/lib
> /opt/homebrew/opt/libpng/lib
> /opt/homebrew/opt/ntl/lib
> /opt/homebrew/opt/bzip2/lib
> /opt/homebrew/opt/readline/lib
> /opt/homebrew/lib
> /usr/local/lib
> Framework search paths:
> ld: Undefined symbols:
>   _main, referenced from:
>   
> clang: error: linker command failed with exit code 1 (use -v to see 
> invocation)
> ---
> Sanity testing C compiler: cc
> Is cross compiler: False.
> Sanity check compiler command line: cc sanitycheckc.c -o sanitycheckc.exe
> Sanity check compile stdout:
>
> -
> Sanity check compile stderr:
>
> -
> Running test binary command: 
>  /Users/palmieri/Downloads/scipy-1.11.2/build/meson-private/sanitycheckc.exe
> C compiler for the host machine: cc (clang 15.0.0 "Apple clang version 
> 15.0.0 (clang-1500.0.40.1)")
> C linker for the host machine: cc ld64 1015.7
> ---
> Detecting linker via: `ar --version` -> 1
> stderr:
> usage:  ar -d [-TLsv] archive file ...
> ar -m [-TLsv] archive file ...
> ar -m [-abiTLsv] position archive file ...
> ar -p [-TLsv] archive [file ...]
> ar -q [-cTLsv] archive file ...
> ar -r [-cuTLsv] archive file ...
> ar -r [-abciuTLsv] position archive file ...
> ar -t [-TLsv] archive [file ...]
> ar -x [-ouTLsv] archive [file ...]
> ---
> ---
> Detecting compiler via: `c++ --version` -> 0
> stdout:
> Apple clang version 15.0.0 (clang-1500.0.40.1)
> Target: arm64-apple-darwin22.6.0
> Thread model: posix
> InstalledDir: /Library/Developer/CommandLineTools/usr/bin
> ---
> Running command: c++ -E -dM -
> -
> ---
> Detecting linker via: `c++ -Wl,--version` -> 1
> stderr:
> ld: unknown options: --version 
> clang: error: linker command failed with exit code 1 (use -v to see 
> invocation)
> ---
> ---
> Detecting Apple linker via: `c++ -Wl,-v` -> 1
> stderr:
> @(#)PROGRAM:ld  PROJECT:dyld-1015.7
> BUILD 18:48:48 Aug 22 2023
> configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 i386 
> x86_64 x86_64h armv6m armv7k armv7m armv7em
> will use ld-classic for: armv6 armv7 armv7s arm64_32 i386 armv6m armv7k 
> armv7m armv7em
> LTO support using: LLVM version 15.0.0 (static support for 29, runtime is 
> 29)
> TAPI support using: Apple TAPI version 15.0.0 (tapi-1500.0.12.3)
> Library search paths:
> /opt/homebrew/opt/primesieve/lib
> /opt/homebrew/opt/bdw-gc/lib
> /opt/homebrew/opt/libpng/lib
> /opt/homebrew/opt/ntl/lib
> /opt/homebrew/opt/bzip2/lib
> /opt/homebrew/opt/readline/lib
> /opt/homebrew/lib
> /usr/local/lib
> Framework search paths:
> ld: Undefined symbols:
>   _main, referenced from:
>   
>

Re: [sage-release] Re: Sage 10.2.beta3 released

[John H Palmieri]

nt i;

---
Command line: `cc 
/Users/palmieri/Downloads/scipy-1.11.2/build/meson-private/tmpo1xh1ad5/testfile.c
 
-o 
/Users/palmieri/Downloads/scipy-1.11.2/build/meson-private/tmpo1xh1ad5/output.obj
 
-c -O0 -Werror=implicit-function-declaration -Werror=unknown-warning-option 
-Werror=unused-command-line-argument -Werror=ignored-optimization-argument 
-Wmisleading-indentation -Wno-misleading-indentation` -> 0
Compiler for C supports arguments -Wno-misleading-indentation: YES 
Running compile:
Working directory: 
 /Users/palmieri/Downloads/scipy-1.11.2/build/meson-private/tmp__jom5wq
Code:
 int main(void) { return 0; }

---
Command line: `cc 
/Users/palmieri/Downloads/scipy-1.11.2/build/meson-private/tmp__jom5wq/testfile.c
 
-o 
/Users/palmieri/Downloads/scipy-1.11.2/build/meson-private/tmp__jom5wq/output.exe
 
-O0 -Werror=implicit-function-declaration -lm 
-Wl,-undefined,dynamic_lookup` -> 0
Library m found: YES
---
Detecting compiler via: `gfortran --version` -> 0
stdout:
GNU Fortran (Homebrew GCC 13.2.0) 13.2.0
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
---
Running command: gfortran -E -dM -
-
---
Detecting linker via: `gfortran -Wl,--version` -> 1
stderr:
collect2 version 13.2.0
/usr/bin/ld -syslibroot 
/Library/Developer/CommandLineTools/SDKs/MacOSX13.sdk/ -dynamic -arch arm64 
-platform_version macos 13.0.0 0.0 -o a.out 
-L/opt/homebrew/Cellar/gcc/13.2.0/bin/../lib/gcc/current/gcc/aarch64-apple-darwin22/13
 
-L/opt/homebrew/Cellar/gcc/13.2.0/bin/../lib/gcc/current/gcc 
-L/opt/homebrew/opt/primesieve/lib -L/opt/homebrew/opt/bdw-gc/lib 
-L/opt/homebrew/opt/libpng/lib -L/opt/homebrew/opt/ntl/lib 
-L/opt/homebrew/opt/bzip2/lib -L/opt/homebrew/opt/readline/lib 
-L/opt/homebrew/lib 
-L/opt/homebrew/Cellar/gcc/13.2.0/bin/../lib/gcc/current/gcc/aarch64-apple-darwin22/13/../../..
 
--version -lemutls_w -lgcc -lSystem -lgcc -no_compact_unwind -rpath 
@loader_path -rpath 
/opt/homebrew/Cellar/gcc/13.2.0/lib/gcc/current/gcc/aarch64-apple-darwin22/13 
-rpath /opt/homebrew/Cellar/gcc/13.2.0/lib/gcc/current/gcc -rpath 
/opt/homebrew/Cellar/primesieve/11.1/lib -rpath 
/opt/homebrew/Cellar/bdw-gc/8.2.4/lib -rpath 
/opt/homebrew/Cellar/libpng/1.6.40/lib -rpath 
/opt/homebrew/Cellar/ntl/11.5.1/lib -rpath 
/opt/homebrew/Cellar/bzip2/1.0.8/lib -rpath 
/opt/homebrew/Cellar/readline/8.2.1/lib -rpath /opt/homebrew/lib -rpath 
/opt/homebrew/Cellar/gcc/13.2.0/lib/gcc/current
ld: unknown options: --version 
collect2: error: ld returned 1 exit status
---

meson.build:82:0: ERROR: Unable to detect linker for compiler `gfortran 
-Wl,--version`
stdout: 
stderr: collect2 version 13.2.0
/usr/bin/ld -syslibroot 
/Library/Developer/CommandLineTools/SDKs/MacOSX13.sdk/ -dynamic -arch arm64 
-platform_version macos 13.0.0 0.0 -o a.out 
-L/opt/homebrew/Cellar/gcc/13.2.0/bin/../lib/gcc/current/gcc/aarch64-apple-darwin22/13
 
-L/opt/homebrew/Cellar/gcc/13.2.0/bin/../lib/gcc/current/gcc 
-L/opt/homebrew/opt/primesieve/lib -L/opt/homebrew/opt/bdw-gc/lib 
-L/opt/homebrew/opt/libpng/lib -L/opt/homebrew/opt/ntl/lib 
-L/opt/homebrew/opt/bzip2/lib -L/opt/homebrew/opt/readline/lib 
-L/opt/homebrew/lib 
-L/opt/homebrew/Cellar/gcc/13.2.0/bin/../lib/gcc/current/gcc/aarch64-apple-darwin22/13/../../..
 
--version -lemutls_w -lgcc -lSystem -lgcc -no_compact_unwind -rpath 
@loader_path -rpath 
/opt/homebrew/Cellar/gcc/13.2.0/lib/gcc/current/gcc/aarch64-apple-darwin22/13 
-rpath /opt/homebrew/Cellar/gcc/13.2.0/lib/gcc/current/gcc -rpath 
/opt/homebrew/Cellar/primesieve/11.1/lib -rpath 
/opt/homebrew/Cellar/bdw-gc/8.2.4/lib -rpath 
/opt/homebrew/Cellar/libpng/1.6.40/lib -rpath 
/opt/homebrew/Cellar/ntl/11.5.1/lib -rpath 
/opt/homebrew/Cellar/bzip2/1.0.8/lib -rpath 
/opt/homebrew/Cellar/readline/8.2.1/lib -rpath /opt/homebrew/lib -rpath 
/opt/homebrew/Cellar/gcc/13.2.0/lib/gcc/current
ld: unknown options: --version 
collect2: error: ld returned 1 exit status



On Saturday, September 23, 2023 at 11:06:06 AM UTC-7 Dima Pasechnik wrote:

> As far as I can gather from scipy bug tracker,
> they can build on M2 just fine
> https://github.com/scipy/scipy/issues/18308
>
>
> On Sat, 23 Sept 2023, 18:07 John H Palmieri,  wrote:
>
>> This is with an Apple Silicon laptop, M2 chip, in case that matters.
>>
>> On Saturday, September 23, 2023 at 10:06:36 AM UTC-7 John H Palmieri 
>> wrote:
>>
>>> I tried the venv approach in the scipy docs, and I ran into the same 
>>> error.
>>>
>>> On Saturday, September 23, 2023 at 1:31:34 AM UTC-7 Dima Pasechnik wrote:
>>>
>>>> Can you build scipy from source using their instructions?
>>>>
>>>> On Sat, 23 Sept 2023, 06:25 John H Palmieri,  
>>>> wrote:
>>>>
>&

Re: [sage-release] Re: Sage 10.2.beta3 released

[John H Palmieri]

This is with an Apple Silicon laptop, M2 chip, in case that matters.

On Saturday, September 23, 2023 at 10:06:36 AM UTC-7 John H Palmieri wrote:

> I tried the venv approach in the scipy docs, and I ran into the same error.
>
> On Saturday, September 23, 2023 at 1:31:34 AM UTC-7 Dima Pasechnik wrote:
>
>> Can you build scipy from source using their instructions?
>>
>> On Sat, 23 Sept 2023, 06:25 John H Palmieri,  wrote:
>>
>>> It's from homebrew's gcc. I did `brew reinstall gcc` followed by `make 
>>> distclean && ./configure && make meson_python && make` and it still fails 
>>> at scipy, same error. I removed the cached download file for homebrew's gcc 
>>> and tried again, same result. I have not yet tried Sage's gcc.
>>>
>>> On Thursday, September 21, 2023 at 11:18:15 PM UTC-7 Dima Pasechnik 
>>> wrote:
>>>
>>>> Where is gfortran coming from here?
>>>> Do you build it with Sage, or use an external one?
>>>>
>>>> If the external one, e.g. from Homebrew, you most probably need to 
>>>> update/reinstall.
>>>> Ditto in Sage 
>>>>
>>>>
>>>> On Fri, 22 Sept 2023, 00:52 John H Palmieri,  
>>>> wrote:
>>>>
>>>>> A new problem, after upgrading to OS X 13.6 and the newest version of 
>>>>> the command-line tools: scipy fails to build again, this time with the 
>>>>> error:
>>>>>
>>>>>   ../../meson.build:82:0: ERROR: Unable to detect linker for compiler 
>>>>> `gfortran -Wl,--version 
>>>>> -L/Users/palmieri/Desktop/Sage/TESTING/sage-10.2.beta3/local/lib 
>>>>> -Wl,-rpath,/Users/palmieri/Desktop/Sage/TESTING/sage-10.2.beta3/local/lib 
>>>>> -L/Users/palmieri/Desktop/Sage/TESTING/sage-10.2.beta3/local/lib 
>>>>> -Wl,-rpath,/Users/palmieri/Desktop/Sage/TESTING/sage-10.2.beta3/local/lib`
>>>>>   stdout:
>>>>>   stderr: collect2 version 13.2.0
>>>>>   /usr/bin/ld -syslibroot 
>>>>> /Library/Developer/CommandLineTools/SDKs/MacOSX13.sdk/ -dynamic -arch 
>>>>> arm64 
>>>>> -platform_version macos 13.0.0 0.0 -o a.out 
>>>>> -L/Users/palmieri/Desktop/Sage/TESTING/sage-10.2.beta3/local/lib 
>>>>> -L/Users/palmieri/Desktop/Sage/TESTING/sage-10.2.beta3/local/lib 
>>>>> -L/opt/homebrew/Cellar/gcc/13.2.0/bin/../lib/gcc/current/gcc/aarch64-apple-darwin22/13
>>>>>  
>>>>> -L/opt/homebrew/Cellar/gcc/13.2.0/bin/../lib/gcc/current/gcc 
>>>>> -L/Users/palmieri/Desktop/Sage/TESTING/sage-10.2.beta3/local/lib 
>>>>> -L/Users/palmieri/Desktop/Sage/TESTING/sage-10.2.beta3/local/lib 
>>>>> -L/opt/homebrew/opt/primesieve/lib -L/opt/homebrew/opt/bdw-gc/lib 
>>>>> -L/opt/homebrew/opt/libpng/lib -L/opt/homebrew/opt/ntl/lib 
>>>>> -L/opt/homebrew/opt/bzip2/lib -L/opt/homebrew/opt/readline/lib 
>>>>> -L/opt/homebrew/lib 
>>>>> -L/opt/homebrew/Cellar/gcc/13.2.0/bin/../lib/gcc/current/gcc/aarch64-apple-darwin22/13/../../..
>>>>>  
>>>>> --version -rpath 
>>>>> /Users/palmieri/Desktop/Sage/TESTING/sage-10.2.beta3/local/lib -rpath 
>>>>> /Users/palmieri/Desktop/Sage/TESTING/sage-10.2.beta3/local/lib -lemutls_w 
>>>>> -lgcc -lSystem -lgcc -no_compact_unwind -rpath @loader_path -rpath 
>>>>> /opt/homebrew/Cellar/gcc/13.2.0/lib/gcc/current/gcc/aarch64-apple-darwin22/13
>>>>>  
>>>>> -rpath /opt/homebrew/Cellar/gcc/13.2.0/lib/gcc/current/gcc -rpath 
>>>>> /Users/palmieri/Desktop/Sage/TESTING/sage-10.2.beta3/local/lib -rpath 
>>>>> /Users/palmieri/Desktop/Sage/TESTING/sage-10.2.beta3/local/lib -rpath 
>>>>> /opt/homebrew/Cellar/primesieve/11.1/lib -rpath 
>>>>> /opt/homebrew/Cellar/bdw-gc/8.2.4/lib -rpath 
>>>>> /opt/homebrew/Cellar/libpng/1.6.40/lib -rpath 
>>>>> /opt/homebrew/Cellar/ntl/11.5.1/lib -rpath 
>>>>> /opt/homebrew/Cellar/bzip2/1.0.8/lib -rpath 
>>>>> /opt/homebrew/Cellar/readline/8.2.1/lib -rpath /opt/homebrew/lib -rpath 
>>>>> /opt/homebrew/Cellar/gcc/13.2.0/lib/gcc/current
>>>>>   ld: unknown options: --version
>>>>>   collect2: error: ld returned 1 exit status
>>>>>
>>>>> Suggestions?
>>>>>
>>>>> On Sunday, September 17, 2023 at 11:25:02 AM UTC-7 John H Palmieri 
>>>>> wrote:
>>>>>
>>>

Re: [sage-release] Re: Sage 10.2.beta3 released

[John H Palmieri]

I tried the venv approach in the scipy docs, and I ran into the same error.

On Saturday, September 23, 2023 at 1:31:34 AM UTC-7 Dima Pasechnik wrote:

> Can you build scipy from source using their instructions?
>
> On Sat, 23 Sept 2023, 06:25 John H Palmieri,  wrote:
>
>> It's from homebrew's gcc. I did `brew reinstall gcc` followed by `make 
>> distclean && ./configure && make meson_python && make` and it still fails 
>> at scipy, same error. I removed the cached download file for homebrew's gcc 
>> and tried again, same result. I have not yet tried Sage's gcc.
>>
>> On Thursday, September 21, 2023 at 11:18:15 PM UTC-7 Dima Pasechnik wrote:
>>
>>> Where is gfortran coming from here?
>>> Do you build it with Sage, or use an external one?
>>>
>>> If the external one, e.g. from Homebrew, you most probably need to 
>>> update/reinstall.
>>> Ditto in Sage 
>>>
>>>
>>> On Fri, 22 Sept 2023, 00:52 John H Palmieri,  
>>> wrote:
>>>
>>>> A new problem, after upgrading to OS X 13.6 and the newest version of 
>>>> the command-line tools: scipy fails to build again, this time with the 
>>>> error:
>>>>
>>>>   ../../meson.build:82:0: ERROR: Unable to detect linker for compiler 
>>>> `gfortran -Wl,--version 
>>>> -L/Users/palmieri/Desktop/Sage/TESTING/sage-10.2.beta3/local/lib 
>>>> -Wl,-rpath,/Users/palmieri/Desktop/Sage/TESTING/sage-10.2.beta3/local/lib 
>>>> -L/Users/palmieri/Desktop/Sage/TESTING/sage-10.2.beta3/local/lib 
>>>> -Wl,-rpath,/Users/palmieri/Desktop/Sage/TESTING/sage-10.2.beta3/local/lib`
>>>>   stdout:
>>>>   stderr: collect2 version 13.2.0
>>>>   /usr/bin/ld -syslibroot 
>>>> /Library/Developer/CommandLineTools/SDKs/MacOSX13.sdk/ -dynamic -arch 
>>>> arm64 
>>>> -platform_version macos 13.0.0 0.0 -o a.out 
>>>> -L/Users/palmieri/Desktop/Sage/TESTING/sage-10.2.beta3/local/lib 
>>>> -L/Users/palmieri/Desktop/Sage/TESTING/sage-10.2.beta3/local/lib 
>>>> -L/opt/homebrew/Cellar/gcc/13.2.0/bin/../lib/gcc/current/gcc/aarch64-apple-darwin22/13
>>>>  
>>>> -L/opt/homebrew/Cellar/gcc/13.2.0/bin/../lib/gcc/current/gcc 
>>>> -L/Users/palmieri/Desktop/Sage/TESTING/sage-10.2.beta3/local/lib 
>>>> -L/Users/palmieri/Desktop/Sage/TESTING/sage-10.2.beta3/local/lib 
>>>> -L/opt/homebrew/opt/primesieve/lib -L/opt/homebrew/opt/bdw-gc/lib 
>>>> -L/opt/homebrew/opt/libpng/lib -L/opt/homebrew/opt/ntl/lib 
>>>> -L/opt/homebrew/opt/bzip2/lib -L/opt/homebrew/opt/readline/lib 
>>>> -L/opt/homebrew/lib 
>>>> -L/opt/homebrew/Cellar/gcc/13.2.0/bin/../lib/gcc/current/gcc/aarch64-apple-darwin22/13/../../..
>>>>  
>>>> --version -rpath 
>>>> /Users/palmieri/Desktop/Sage/TESTING/sage-10.2.beta3/local/lib -rpath 
>>>> /Users/palmieri/Desktop/Sage/TESTING/sage-10.2.beta3/local/lib -lemutls_w 
>>>> -lgcc -lSystem -lgcc -no_compact_unwind -rpath @loader_path -rpath 
>>>> /opt/homebrew/Cellar/gcc/13.2.0/lib/gcc/current/gcc/aarch64-apple-darwin22/13
>>>>  
>>>> -rpath /opt/homebrew/Cellar/gcc/13.2.0/lib/gcc/current/gcc -rpath 
>>>> /Users/palmieri/Desktop/Sage/TESTING/sage-10.2.beta3/local/lib -rpath 
>>>> /Users/palmieri/Desktop/Sage/TESTING/sage-10.2.beta3/local/lib -rpath 
>>>> /opt/homebrew/Cellar/primesieve/11.1/lib -rpath 
>>>> /opt/homebrew/Cellar/bdw-gc/8.2.4/lib -rpath 
>>>> /opt/homebrew/Cellar/libpng/1.6.40/lib -rpath 
>>>> /opt/homebrew/Cellar/ntl/11.5.1/lib -rpath 
>>>> /opt/homebrew/Cellar/bzip2/1.0.8/lib -rpath 
>>>> /opt/homebrew/Cellar/readline/8.2.1/lib -rpath /opt/homebrew/lib -rpath 
>>>> /opt/homebrew/Cellar/gcc/13.2.0/lib/gcc/current
>>>>   ld: unknown options: --version
>>>>   collect2: error: ld returned 1 exit status
>>>>
>>>> Suggestions?
>>>>
>>>> On Sunday, September 17, 2023 at 11:25:02 AM UTC-7 John H Palmieri 
>>>> wrote:
>>>>
>>>>> Similar problem for me on OS X. I don't understand something: the 
>>>>> dependencies for scipy include meson_python, but that package is not 
>>>>> installed before scipy attempts to build, and fails. Running "make 
>>>>> meson_python" and then "make scipy" succeeds, as does "make".
>>>>>
>>>>>
>>>>>
>>>>> On Saturday, Se

Re: [sage-release] Re: Sage 10.2.beta3 released

[John H Palmieri]

It's from homebrew's gcc. I did `brew reinstall gcc` followed by `make 
distclean && ./configure && make meson_python && make` and it still fails 
at scipy, same error. I removed the cached download file for homebrew's gcc 
and tried again, same result. I have not yet tried Sage's gcc.

On Thursday, September 21, 2023 at 11:18:15 PM UTC-7 Dima Pasechnik wrote:

> Where is gfortran coming from here?
> Do you build it with Sage, or use an external one?
>
> If the external one, e.g. from Homebrew, you most probably need to 
> update/reinstall.
> Ditto in Sage 
>
>
> On Fri, 22 Sept 2023, 00:52 John H Palmieri,  wrote:
>
>> A new problem, after upgrading to OS X 13.6 and the newest version of the 
>> command-line tools: scipy fails to build again, this time with the error:
>>
>>   ../../meson.build:82:0: ERROR: Unable to detect linker for compiler 
>> `gfortran -Wl,--version 
>> -L/Users/palmieri/Desktop/Sage/TESTING/sage-10.2.beta3/local/lib 
>> -Wl,-rpath,/Users/palmieri/Desktop/Sage/TESTING/sage-10.2.beta3/local/lib 
>> -L/Users/palmieri/Desktop/Sage/TESTING/sage-10.2.beta3/local/lib 
>> -Wl,-rpath,/Users/palmieri/Desktop/Sage/TESTING/sage-10.2.beta3/local/lib`
>>   stdout:
>>   stderr: collect2 version 13.2.0
>>   /usr/bin/ld -syslibroot 
>> /Library/Developer/CommandLineTools/SDKs/MacOSX13.sdk/ -dynamic -arch arm64 
>> -platform_version macos 13.0.0 0.0 -o a.out 
>> -L/Users/palmieri/Desktop/Sage/TESTING/sage-10.2.beta3/local/lib 
>> -L/Users/palmieri/Desktop/Sage/TESTING/sage-10.2.beta3/local/lib 
>> -L/opt/homebrew/Cellar/gcc/13.2.0/bin/../lib/gcc/current/gcc/aarch64-apple-darwin22/13
>>  
>> -L/opt/homebrew/Cellar/gcc/13.2.0/bin/../lib/gcc/current/gcc 
>> -L/Users/palmieri/Desktop/Sage/TESTING/sage-10.2.beta3/local/lib 
>> -L/Users/palmieri/Desktop/Sage/TESTING/sage-10.2.beta3/local/lib 
>> -L/opt/homebrew/opt/primesieve/lib -L/opt/homebrew/opt/bdw-gc/lib 
>> -L/opt/homebrew/opt/libpng/lib -L/opt/homebrew/opt/ntl/lib 
>> -L/opt/homebrew/opt/bzip2/lib -L/opt/homebrew/opt/readline/lib 
>> -L/opt/homebrew/lib 
>> -L/opt/homebrew/Cellar/gcc/13.2.0/bin/../lib/gcc/current/gcc/aarch64-apple-darwin22/13/../../..
>>  
>> --version -rpath 
>> /Users/palmieri/Desktop/Sage/TESTING/sage-10.2.beta3/local/lib -rpath 
>> /Users/palmieri/Desktop/Sage/TESTING/sage-10.2.beta3/local/lib -lemutls_w 
>> -lgcc -lSystem -lgcc -no_compact_unwind -rpath @loader_path -rpath 
>> /opt/homebrew/Cellar/gcc/13.2.0/lib/gcc/current/gcc/aarch64-apple-darwin22/13
>>  
>> -rpath /opt/homebrew/Cellar/gcc/13.2.0/lib/gcc/current/gcc -rpath 
>> /Users/palmieri/Desktop/Sage/TESTING/sage-10.2.beta3/local/lib -rpath 
>> /Users/palmieri/Desktop/Sage/TESTING/sage-10.2.beta3/local/lib -rpath 
>> /opt/homebrew/Cellar/primesieve/11.1/lib -rpath 
>> /opt/homebrew/Cellar/bdw-gc/8.2.4/lib -rpath 
>> /opt/homebrew/Cellar/libpng/1.6.40/lib -rpath 
>> /opt/homebrew/Cellar/ntl/11.5.1/lib -rpath 
>> /opt/homebrew/Cellar/bzip2/1.0.8/lib -rpath 
>> /opt/homebrew/Cellar/readline/8.2.1/lib -rpath /opt/homebrew/lib -rpath 
>> /opt/homebrew/Cellar/gcc/13.2.0/lib/gcc/current
>>   ld: unknown options: --version
>>   collect2: error: ld returned 1 exit status
>>
>> Suggestions?
>>
>> On Sunday, September 17, 2023 at 11:25:02 AM UTC-7 John H Palmieri wrote:
>>
>>> Similar problem for me on OS X. I don't understand something: the 
>>> dependencies for scipy include meson_python, but that package is not 
>>> installed before scipy attempts to build, and fails. Running "make 
>>> meson_python" and then "make scipy" succeeds, as does "make".
>>>
>>>
>>>
>>> On Saturday, September 16, 2023 at 2:59:58 PM UTC-7 Kwankyu Lee wrote:
>>>
>>>> Succeeded after sage -pip install meson-python.
>>>>
>>>> On Sunday, September 17, 2023 at 6:52:59 AM UTC+9 Kwankyu Lee wrote:
>>>>
>>>>> Incremental build failed
>>>>>
>>>>> [scipy-1.11.2] 
>>>>> [..]
>>>>> [scipy-1.11.2] scipy-1.11.2
>>>>> [scipy-1.11.2] 
>>>>> [sagelib-10.2.beta3]   Removing file or directory 
>>>>> /Users/kwankyu/GitHub/sage-dev/local/var/lib/sage/venv-python3.10/lib/python3.10/site-packages/sagemath-standard.egg-link
>>>>> [sagelib-10.2.beta3]   Removing pth entries from 
>>>>> /Users/kwankyu/GitHub/sage-dev/local/var/lib/sage/venv-pyth

[sage-release] Re: Sage 10.2.beta3 released

[John H Palmieri]

By the way, it also says

A full log can be found at 
/Users/palmieri/Desktop/Sage/TESTING/sage-10.2.beta3/local/var/lib/sage/venv-python3.11/var/tmp/sage/build/scipy-1.11.2/src/.mesonpy-sxi6gtt6/build/meson-logs/meson-log.txt

but there is no such file, indeed no such directory ".mesonpy-".

On Thursday, September 21, 2023 at 4:52:56 PM UTC-7 John H Palmieri wrote:

> A new problem, after upgrading to OS X 13.6 and the newest version of the 
> command-line tools: scipy fails to build again, this time with the error:
>
>   ../../meson.build:82:0: ERROR: Unable to detect linker for compiler 
> `gfortran -Wl,--version 
> -L/Users/palmieri/Desktop/Sage/TESTING/sage-10.2.beta3/local/lib 
> -Wl,-rpath,/Users/palmieri/Desktop/Sage/TESTING/sage-10.2.beta3/local/lib 
> -L/Users/palmieri/Desktop/Sage/TESTING/sage-10.2.beta3/local/lib 
> -Wl,-rpath,/Users/palmieri/Desktop/Sage/TESTING/sage-10.2.beta3/local/lib`
>   stdout:
>   stderr: collect2 version 13.2.0
>   /usr/bin/ld -syslibroot 
> /Library/Developer/CommandLineTools/SDKs/MacOSX13.sdk/ -dynamic -arch arm64 
> -platform_version macos 13.0.0 0.0 -o a.out 
> -L/Users/palmieri/Desktop/Sage/TESTING/sage-10.2.beta3/local/lib 
> -L/Users/palmieri/Desktop/Sage/TESTING/sage-10.2.beta3/local/lib 
> -L/opt/homebrew/Cellar/gcc/13.2.0/bin/../lib/gcc/current/gcc/aarch64-apple-darwin22/13
>  
> -L/opt/homebrew/Cellar/gcc/13.2.0/bin/../lib/gcc/current/gcc 
> -L/Users/palmieri/Desktop/Sage/TESTING/sage-10.2.beta3/local/lib 
> -L/Users/palmieri/Desktop/Sage/TESTING/sage-10.2.beta3/local/lib 
> -L/opt/homebrew/opt/primesieve/lib -L/opt/homebrew/opt/bdw-gc/lib 
> -L/opt/homebrew/opt/libpng/lib -L/opt/homebrew/opt/ntl/lib 
> -L/opt/homebrew/opt/bzip2/lib -L/opt/homebrew/opt/readline/lib 
> -L/opt/homebrew/lib 
> -L/opt/homebrew/Cellar/gcc/13.2.0/bin/../lib/gcc/current/gcc/aarch64-apple-darwin22/13/../../..
>  
> --version -rpath 
> /Users/palmieri/Desktop/Sage/TESTING/sage-10.2.beta3/local/lib -rpath 
> /Users/palmieri/Desktop/Sage/TESTING/sage-10.2.beta3/local/lib -lemutls_w 
> -lgcc -lSystem -lgcc -no_compact_unwind -rpath @loader_path -rpath 
> /opt/homebrew/Cellar/gcc/13.2.0/lib/gcc/current/gcc/aarch64-apple-darwin22/13 
> -rpath /opt/homebrew/Cellar/gcc/13.2.0/lib/gcc/current/gcc -rpath 
> /Users/palmieri/Desktop/Sage/TESTING/sage-10.2.beta3/local/lib -rpath 
> /Users/palmieri/Desktop/Sage/TESTING/sage-10.2.beta3/local/lib -rpath 
> /opt/homebrew/Cellar/primesieve/11.1/lib -rpath 
> /opt/homebrew/Cellar/bdw-gc/8.2.4/lib -rpath 
> /opt/homebrew/Cellar/libpng/1.6.40/lib -rpath 
> /opt/homebrew/Cellar/ntl/11.5.1/lib -rpath 
> /opt/homebrew/Cellar/bzip2/1.0.8/lib -rpath 
> /opt/homebrew/Cellar/readline/8.2.1/lib -rpath /opt/homebrew/lib -rpath 
> /opt/homebrew/Cellar/gcc/13.2.0/lib/gcc/current
>   ld: unknown options: --version
>   collect2: error: ld returned 1 exit status
>
> Suggestions?
>
> On Sunday, September 17, 2023 at 11:25:02 AM UTC-7 John H Palmieri wrote:
>
>> Similar problem for me on OS X. I don't understand something: the 
>> dependencies for scipy include meson_python, but that package is not 
>> installed before scipy attempts to build, and fails. Running "make 
>> meson_python" and then "make scipy" succeeds, as does "make".
>>
>>
>>
>> On Saturday, September 16, 2023 at 2:59:58 PM UTC-7 Kwankyu Lee wrote:
>>
>>> Succeeded after sage -pip install meson-python.
>>>
>>> On Sunday, September 17, 2023 at 6:52:59 AM UTC+9 Kwankyu Lee wrote:
>>>
>>>> Incremental build failed
>>>>
>>>> [scipy-1.11.2] 
>>>> [..]
>>>> [scipy-1.11.2] scipy-1.11.2
>>>> [scipy-1.11.2] 
>>>> [sagelib-10.2.beta3]   Removing file or directory 
>>>> /Users/kwankyu/GitHub/sage-dev/local/var/lib/sage/venv-python3.10/lib/python3.10/site-packages/sagemath-standard.egg-link
>>>> [sagelib-10.2.beta3]   Removing pth entries from 
>>>> /Users/kwankyu/GitHub/sage-dev/local/var/lib/sage/venv-python3.10/lib/python3.10/site-packages/easy-install.pth:
>>>> [sagelib-10.2.beta3]   Removing entry: 
>>>> /Users/kwankyu/GitHub/sage-dev/src
>>>> [sagelib-10.2.beta3]   Successfully uninstalled 
>>>> sagemath-standard-10.2b3
>>>> [sagelib-10.2.beta3]   Running setup.py develop for sagemath-standard
>>>> [sagelib-10.2.beta3] Running command python setup.py develop
>>>> [scipy-1.11.2] Setting up build directory for scipy-1.11.2
>>>> [scipy-1.11.2] Finished extraction
>>>