[sage-devel] No more Cygwin support in Sage 9.7

[Matthias Koeppe]

https://trac.sagemath.org/ticket/34301 (needs review)

-- 
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/64ad201a-4b59-4b12-9866-2e821015ba8bn%40googlegroups.com.

[sage-devel] Re: Proposal: downgrade some packages to experimental

[Matthias Koeppe]

On Sunday, August 7, 2022 at 12:48:21 PM UTC-7 John H Palmieri wrote:

> I would like to see all of them fixed, p_group_cohomology especially, but 
> I think we are coming up on a release and if the package doesn't build on 
> supported platforms, we can't really call it optional. Once a package is 
> fixed, then it should immediately get promoted back to optional again.
>
>
+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/62abbb2f-718f-4935-ae6b-dfc833aaf5ffn%40googlegroups.com.

Re: [sage-devel] Re: Proposal: downgrade some packages to experimental

[Dima Pasechnik]

On Sun, 7 Aug 2022, 20:48 John H Palmieri,  wrote:

> I would like to see all of them fixed, p_group_cohomology especially,
>

there is a regression to solve with the package, which needs understanding
of the algorithm behind. (build problems are solved, I think).





but I think we are coming up on a release and if the package doesn't build
> on supported platforms, we can't really call it optional. Once a package is
> fixed, then it should immediately get promoted back to optional again.
>
> Regards,
>   John
>
> On Sunday, August 7, 2022 at 12:03:41 AM UTC-7 Travis Scrimshaw wrote:
>
>> I would like to see the p_group_cohomology fixed. Progress got stalled on
>> that, but I am happy to work on that (while I have time for August).
>>
>> Best,
>> Travis
>>
>>
>> On Sunday, August 7, 2022 at 5:23:46 AM UTC+9 Matthias Koeppe wrote:
>>
>>> The sage_numerical_backends_* packages are on their way out anyway.
>>> Coin support will switch to go through CVXPy in
>>> https://trac.sagemath.org/ticket/34251, and Gurobi/CPLEX likewise in a
>>> follow up ticket
>>>
>>> On Saturday, August 6, 2022 at 1:09:37 PM UTC-7 John H Palmieri wrote:
>>>
 Thank you for the link. With this ticket, the gurobi and cplex backends
 still fail because I don't have gurobi and cplex installed. It would be
 nice if that was detected earlier in the process and the build failed right
 away. Actually, it is detected early in the process:

   /bin/sh: gurobi.sh: No such file or directory
   GUROBI_HOME is not set, or it does not point to a directory with a
 Gurobi installation.  Trying to link against -lgurobi

 but the installation proceeds anyway. But this is a separate issue.

 On Saturday, August 6, 2022 at 12:39:00 PM UTC-7 Matthias Koeppe wrote:

> This one is https://trac.sagemath.org/ticket/34221
>
> On Saturday, August 6, 2022 at 11:55:36 AM UTC-7 John H Palmieri wrote:
>
>> Also, the various sage_numerical_backend_* packages fail to build,
>> with errors like
>>
>>
>>   Error compiling Cython file:
>>   
>>   ...
>>   from sage.numerical.backends.generic_backend cimport GenericBackend
>>   ^
>>   
>>
>>   check_add_col_untyped_args.pyx:1:0:
>> 'sage/numerical/backends/generic_backend.pxd' not found
>>
>>
>> Also downgrade? Is there a ticket for this?
>>
>> On Friday, August 5, 2022 at 11:07:51 PM UTC-7 Matthias Koeppe wrote:
>>
>>> On Friday, August 5, 2022 at 9:49:21 PM UTC-7 John H Palmieri wrote:
>>>
 The following packages do not build for me on OS X 12.5
 (Monterrey), Intel chip:

- polylib (#33758)
- symengine_py (#34141)
- p_group_cohomology (#30787)
- r_jupyter
- rubiks

 I propose that these be downgraded from optional to experimental
 until the issues are fixed. What do people think?


>>> Also on various Linux platforms (
>>> https://github.com/sagemath/sage/actions/runs/204587) I see
>>> failures for
>>> symengine_py,
>>> p_group_cohomology,
>>> r_jupyter
>>>
>>> So these 3 definitely need to be changed to "experimental".
>>>
>>>
>>>
>>>
>> --
> 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/53c18b02-c5fa-4dcf-9dd0-6c57955ccdf4n%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/CAAWYfq1zUPJrnjEkj8SPDfNfKGODAAhO1dm0k76LJsP%2Be8nWnQ%40mail.gmail.com.

[sage-devel] Re: Proposal: downgrade some packages to experimental

[John H Palmieri]

I would like to see all of them fixed, p_group_cohomology especially, but I 
think we are coming up on a release and if the package doesn't build on 
supported platforms, we can't really call it optional. Once a package is 
fixed, then it should immediately get promoted back to optional again.

Regards,
  John

On Sunday, August 7, 2022 at 12:03:41 AM UTC-7 Travis Scrimshaw wrote:

> I would like to see the p_group_cohomology fixed. Progress got stalled on 
> that, but I am happy to work on that (while I have time for August).
>
> Best,
> Travis
>
>
> On Sunday, August 7, 2022 at 5:23:46 AM UTC+9 Matthias Koeppe wrote:
>
>> The sage_numerical_backends_* packages are on their way out anyway.
>> Coin support will switch to go through CVXPy in 
>> https://trac.sagemath.org/ticket/34251, and Gurobi/CPLEX likewise in a 
>> follow up ticket
>>
>> On Saturday, August 6, 2022 at 1:09:37 PM UTC-7 John H Palmieri wrote:
>>
>>> Thank you for the link. With this ticket, the gurobi and cplex backends 
>>> still fail because I don't have gurobi and cplex installed. It would be 
>>> nice if that was detected earlier in the process and the build failed right 
>>> away. Actually, it is detected early in the process:
>>>
>>>   /bin/sh: gurobi.sh: No such file or directory
>>>   GUROBI_HOME is not set, or it does not point to a directory with a 
>>> Gurobi installation.  Trying to link against -lgurobi
>>>
>>> but the installation proceeds anyway. But this is a separate issue.
>>>
>>> On Saturday, August 6, 2022 at 12:39:00 PM UTC-7 Matthias Koeppe wrote:
>>>
 This one is https://trac.sagemath.org/ticket/34221

 On Saturday, August 6, 2022 at 11:55:36 AM UTC-7 John H Palmieri wrote:

> Also, the various sage_numerical_backend_* packages fail to build, 
> with errors like
>
>
>   Error compiling Cython file:
>   
>   ...
>   from sage.numerical.backends.generic_backend cimport GenericBackend
>   ^
>   
>
>   check_add_col_untyped_args.pyx:1:0: 
> 'sage/numerical/backends/generic_backend.pxd' not found
>
>
> Also downgrade? Is there a ticket for this?
>
> On Friday, August 5, 2022 at 11:07:51 PM UTC-7 Matthias Koeppe wrote:
>
>> On Friday, August 5, 2022 at 9:49:21 PM UTC-7 John H Palmieri wrote:
>>
>>> The following packages do not build for me on OS X 12.5 (Monterrey), 
>>> Intel chip:
>>>
>>>- polylib (#33758)
>>>- symengine_py (#34141)
>>>- p_group_cohomology (#30787)
>>>- r_jupyter
>>>- rubiks
>>>
>>> I propose that these be downgraded from optional to experimental 
>>> until the issues are fixed. What do people think?
>>>
>>>
>> Also on various Linux platforms (
>> https://github.com/sagemath/sage/actions/runs/204587) I see 
>> failures for
>> symengine_py, 
>> p_group_cohomology, 
>> r_jupyter
>>
>> So these 3 definitely need to be changed to "experimental".
>>
>>
>>  
>>
>

-- 
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/53c18b02-c5fa-4dcf-9dd0-6c57955ccdf4n%40googlegroups.com.

[sage-devel] Re: Proposal: downgrade some packages to experimental

[Marc Culler]

Incidentally, the patch for p_group_cohomology that I uploaded above also 
appeared in #30787  . 


- Marc

On Sunday, August 7, 2022 at 7:49:41 AM UTC-5 Marc Culler wrote:

> The p_group_cohomology package is included in the macOS binary release.  
> it requires a patch to its spkg-install,sh.  Symengine_py is also included 
> in the macOS binary and also needs a patch.  I am attaching a tarball of 
> the build/pkg directories for those two packages.
>
> - Marc
>
> On Sunday, August 7, 2022 at 2:03:41 AM UTC-5 Travis Scrimshaw wrote:
>
>> I would like to see the p_group_cohomology fixed. Progress got stalled on 
>> that, but I am happy to work on that (while I have time for August).
>>
>> Best,
>> Travis
>>
>>
>> On Sunday, August 7, 2022 at 5:23:46 AM UTC+9 Matthias Koeppe wrote:
>>
>>> The sage_numerical_backends_* packages are on their way out anyway.
>>> Coin support will switch to go through CVXPy in 
>>> https://trac.sagemath.org/ticket/34251, and Gurobi/CPLEX likewise in a 
>>> follow up ticket
>>>
>>> On Saturday, August 6, 2022 at 1:09:37 PM UTC-7 John H Palmieri wrote:
>>>
 Thank you for the link. With this ticket, the gurobi and cplex backends 
 still fail because I don't have gurobi and cplex installed. It would be 
 nice if that was detected earlier in the process and the build failed 
 right 
 away. Actually, it is detected early in the process:

   /bin/sh: gurobi.sh: No such file or directory
   GUROBI_HOME is not set, or it does not point to a directory with a 
 Gurobi installation.  Trying to link against -lgurobi

 but the installation proceeds anyway. But this is a separate issue.

 On Saturday, August 6, 2022 at 12:39:00 PM UTC-7 Matthias Koeppe wrote:

> This one is https://trac.sagemath.org/ticket/34221
>
> On Saturday, August 6, 2022 at 11:55:36 AM UTC-7 John H Palmieri wrote:
>
>> Also, the various sage_numerical_backend_* packages fail to build, 
>> with errors like
>>
>>
>>   Error compiling Cython file:
>>   
>>   ...
>>   from sage.numerical.backends.generic_backend cimport GenericBackend
>>   ^
>>   
>>
>>   check_add_col_untyped_args.pyx:1:0: 
>> 'sage/numerical/backends/generic_backend.pxd' not found
>>
>>
>> Also downgrade? Is there a ticket for this?
>>
>> On Friday, August 5, 2022 at 11:07:51 PM UTC-7 Matthias Koeppe wrote:
>>
>>> On Friday, August 5, 2022 at 9:49:21 PM UTC-7 John H Palmieri wrote:
>>>
 The following packages do not build for me on OS X 12.5 
 (Monterrey), Intel chip:

- polylib (#33758)
- symengine_py (#34141)
- p_group_cohomology (#30787)
- r_jupyter
- rubiks

 I propose that these be downgraded from optional to experimental 
 until the issues are fixed. What do people think?


>>> Also on various Linux platforms (
>>> https://github.com/sagemath/sage/actions/runs/204587) I see 
>>> failures for
>>> symengine_py, 
>>> p_group_cohomology, 
>>> r_jupyter
>>>
>>> So these 3 definitely need to be changed to "experimental".
>>>
>>>
>>>  
>>>
>>

-- 
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/1f063ec0-6018-4bf0-b08b-795f2e935f1cn%40googlegroups.com.

[sage-devel] Re: Proposal: downgrade some packages to experimental

[Marc Culler]

Yes, there is a ticket for this.  It is #34221 
.  The current version of Cython 
ignores .pxd files in directories with no __init__.py.  The ticket 
backports a cython fix for that problem which will appear in a future 
Cython release.

- Marc

On Saturday, August 6, 2022 at 1:55:36 PM UTC-5 John H Palmieri wrote:

> Also, the various sage_numerical_backend_* packages fail to build, with 
> errors like
>
>
>   Error compiling Cython file:
>   
>   ...
>   from sage.numerical.backends.generic_backend cimport GenericBackend
>   ^
>   
>
>   check_add_col_untyped_args.pyx:1:0: 
> 'sage/numerical/backends/generic_backend.pxd' not found
>
>
> Also downgrade? Is there a ticket for this?
>
> On Friday, August 5, 2022 at 11:07:51 PM UTC-7 Matthias Koeppe wrote:
>
>> On Friday, August 5, 2022 at 9:49:21 PM UTC-7 John H Palmieri wrote:
>>
>>> The following packages do not build for me on OS X 12.5 (Monterrey), 
>>> Intel chip:
>>>
>>>- polylib (#33758)
>>>- symengine_py (#34141)
>>>- p_group_cohomology (#30787)
>>>- r_jupyter
>>>- rubiks
>>>
>>> I propose that these be downgraded from optional to experimental until 
>>> the issues are fixed. What do people think?
>>>
>>>
>> Also on various Linux platforms (
>> https://github.com/sagemath/sage/actions/runs/204587) I see failures 
>> for
>> symengine_py, 
>> p_group_cohomology, 
>> r_jupyter
>>
>> So these 3 definitely need to be changed to "experimental".
>>
>>
>>  
>>
>

-- 
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/04dd20f0-eda0-4065-ac91-b140675bbabcn%40googlegroups.com.

[sage-devel] Re: Proposal: downgrade some packages to experimental

[Marc Culler]

The p_group_cohomology package is included in the macOS binary release.  it 
requires a patch to its spkg-install,sh.  Symengine_py is also included in 
the macOS binary and also needs a patch.  I am attaching a tarball of the 
build/pkg directories for those two packages.

- Marc

On Sunday, August 7, 2022 at 2:03:41 AM UTC-5 Travis Scrimshaw wrote:

> I would like to see the p_group_cohomology fixed. Progress got stalled on 
> that, but I am happy to work on that (while I have time for August).
>
> Best,
> Travis
>
>
> On Sunday, August 7, 2022 at 5:23:46 AM UTC+9 Matthias Koeppe wrote:
>
>> The sage_numerical_backends_* packages are on their way out anyway.
>> Coin support will switch to go through CVXPy in 
>> https://trac.sagemath.org/ticket/34251, and Gurobi/CPLEX likewise in a 
>> follow up ticket
>>
>> On Saturday, August 6, 2022 at 1:09:37 PM UTC-7 John H Palmieri wrote:
>>
>>> Thank you for the link. With this ticket, the gurobi and cplex backends 
>>> still fail because I don't have gurobi and cplex installed. It would be 
>>> nice if that was detected earlier in the process and the build failed right 
>>> away. Actually, it is detected early in the process:
>>>
>>>   /bin/sh: gurobi.sh: No such file or directory
>>>   GUROBI_HOME is not set, or it does not point to a directory with a 
>>> Gurobi installation.  Trying to link against -lgurobi
>>>
>>> but the installation proceeds anyway. But this is a separate issue.
>>>
>>> On Saturday, August 6, 2022 at 12:39:00 PM UTC-7 Matthias Koeppe wrote:
>>>
 This one is https://trac.sagemath.org/ticket/34221

 On Saturday, August 6, 2022 at 11:55:36 AM UTC-7 John H Palmieri wrote:

> Also, the various sage_numerical_backend_* packages fail to build, 
> with errors like
>
>
>   Error compiling Cython file:
>   
>   ...
>   from sage.numerical.backends.generic_backend cimport GenericBackend
>   ^
>   
>
>   check_add_col_untyped_args.pyx:1:0: 
> 'sage/numerical/backends/generic_backend.pxd' not found
>
>
> Also downgrade? Is there a ticket for this?
>
> On Friday, August 5, 2022 at 11:07:51 PM UTC-7 Matthias Koeppe wrote:
>
>> On Friday, August 5, 2022 at 9:49:21 PM UTC-7 John H Palmieri wrote:
>>
>>> The following packages do not build for me on OS X 12.5 (Monterrey), 
>>> Intel chip:
>>>
>>>- polylib (#33758)
>>>- symengine_py (#34141)
>>>- p_group_cohomology (#30787)
>>>- r_jupyter
>>>- rubiks
>>>
>>> I propose that these be downgraded from optional to experimental 
>>> until the issues are fixed. What do people think?
>>>
>>>
>> Also on various Linux platforms (
>> https://github.com/sagemath/sage/actions/runs/204587) I see 
>> failures for
>> symengine_py, 
>> p_group_cohomology, 
>> r_jupyter
>>
>> So these 3 definitely need to be changed to "experimental".
>>
>>
>>  
>>
>

-- 
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/afe6bf83-1147-49eb-8f9b-2343b671d8d7n%40googlegroups.com.


pgroup_symengine.tgz
Description: GNU Zip compressed data

[sage-devel] Re: Polling for sphinx background style

[Kwankyu Lee]

On Sunday, August 7, 2022 at 3:57:52 PM UTC+9 Travis Scrimshaw wrote:

> I slightly protest that one day of voting at the end of the week is not a 
> lot of time for such a consequential vote.
>

I agree. Sorry about that.
 

> That being said, I support grayish (but I also noticed there is so little 
> difference on dark mode).
>

I also support grayish. So two more unrealized votes to grayish :)

-- 
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/14a75a04-13a3-44ce-9ed2-8d8d6cca0227n%40googlegroups.com.

[sage-devel] Re: Proposal: downgrade some packages to experimental

['Travis Scrimshaw' via sage-devel]

I would like to see the p_group_cohomology fixed. Progress got stalled on 
that, but I am happy to work on that (while I have time for August).

Best,
Travis


On Sunday, August 7, 2022 at 5:23:46 AM UTC+9 Matthias Koeppe wrote:

> The sage_numerical_backends_* packages are on their way out anyway.
> Coin support will switch to go through CVXPy in 
> https://trac.sagemath.org/ticket/34251, and Gurobi/CPLEX likewise in a 
> follow up ticket
>
> On Saturday, August 6, 2022 at 1:09:37 PM UTC-7 John H Palmieri wrote:
>
>> Thank you for the link. With this ticket, the gurobi and cplex backends 
>> still fail because I don't have gurobi and cplex installed. It would be 
>> nice if that was detected earlier in the process and the build failed right 
>> away. Actually, it is detected early in the process:
>>
>>   /bin/sh: gurobi.sh: No such file or directory
>>   GUROBI_HOME is not set, or it does not point to a directory with a 
>> Gurobi installation.  Trying to link against -lgurobi
>>
>> but the installation proceeds anyway. But this is a separate issue.
>>
>> On Saturday, August 6, 2022 at 12:39:00 PM UTC-7 Matthias Koeppe wrote:
>>
>>> This one is https://trac.sagemath.org/ticket/34221
>>>
>>> On Saturday, August 6, 2022 at 11:55:36 AM UTC-7 John H Palmieri wrote:
>>>
 Also, the various sage_numerical_backend_* packages fail to build, with 
 errors like


   Error compiling Cython file:
   
   ...
   from sage.numerical.backends.generic_backend cimport GenericBackend
   ^
   

   check_add_col_untyped_args.pyx:1:0: 
 'sage/numerical/backends/generic_backend.pxd' not found


 Also downgrade? Is there a ticket for this?

 On Friday, August 5, 2022 at 11:07:51 PM UTC-7 Matthias Koeppe wrote:

> On Friday, August 5, 2022 at 9:49:21 PM UTC-7 John H Palmieri wrote:
>
>> The following packages do not build for me on OS X 12.5 (Monterrey), 
>> Intel chip:
>>
>>- polylib (#33758)
>>- symengine_py (#34141)
>>- p_group_cohomology (#30787)
>>- r_jupyter
>>- rubiks
>>
>> I propose that these be downgraded from optional to experimental 
>> until the issues are fixed. What do people think?
>>
>>
> Also on various Linux platforms (
> https://github.com/sagemath/sage/actions/runs/204587) I see 
> failures for
> symengine_py, 
> p_group_cohomology, 
> r_jupyter
>
> So these 3 definitely need to be changed to "experimental".
>
>
>  
>


-- 
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/975cb633-de43-4cba-8c67-286c413c4ceen%40googlegroups.com.

[sage-devel] Re: Group algebra bug

['Travis Scrimshaw' via sage-devel]

I posted on the ticket a long debug of the issue, which comes down to a 
subtlety with making copies of PermutationGroup_generic and its __dict__.

Best,
Travis


On Sunday, August 7, 2022 at 3:57:59 AM UTC+9 Trevor Karn wrote:

> Sorry of course the parent of kH(a) and kH.one() are the same. We do see 
> that the parents of the indexing elements are different despite being 
> mathematically the same:
>
> sage: a.parent()
> sage: list(kH.one().monomial_coefficients())[0].parent()
>
> Permutation Group with generators [(5,6,7)(12,14,18), (1,2)(3,4)]
> Permutation Group with generators [(5,6,7)(12,14,18), (1,2)(3,4)]
> sage: list(kH.one().monomial_coefficients())[0].parent() is a.parent()
> False
>
> On Saturday, August 6, 2022 at 11:53:03 AM UTC-7 Trevor Karn wrote:
>
>> The following bug was reported on sage-support, which I was able to 
>> reproduce on 9.7.beta7.
>>
>> sage: H = PermutationGroup([[(1,2), (3,4)], [(5,6,7),(12,14,18)]])
>> sage: kH = H.algebra(GF(2))
>> sage: H.gens()
>> ((5,6,7)(12,14,18), (1,2)(3,4))
>> sage: a, b = H.gens()
>> sage: x = kH(a) + kH(b) + kH.one(); x
>> (5,6,7)(12,14,18) + (1,2)(3,4) + ()
>> sage: x*x
>> Traceback (most recent call last):
>> ...
>> RuntimeError: There is a bug in the coercion code in Sage.
>> Both x (=()) and y (=(5,6,7)(12,14,18)) are supposed to have identical 
>> parents but they don't.
>> In fact, x has parent 'Permutation Group with generators 
>> [(5,6,7)(12,14,18), (1,2)(3,4)]'
>> whereas y has parent 'Permutation Group with generators 
>> [(5,6,7)(12,14,18), (1,2)(3,4)]'
>> Original elements () (parent Permutation Group with generators 
>> [(5,6,7)(12,14,18), (1,2)(3,4)]) and (5,6,7)(12,14,18) (parent Permutation 
>> Group with generators [(5,6,7)(12,14,18), (1,2)(3,4)]) and maps
>>  None
>>  (map 
>> internal to coercion system -- copy before use)
>> Coercion map:
>>   From: Permutation Group with generators [(5,6,7)(12,14,18), (1,2)(3,4)]
>>   To:   Permutation Group with generators [(5,6,7)(12,14,18), (1,2)(3,4)]
>>
>> I'm confused about why this is happening because
>>
>> sage: kH(a).parent()
>> Algebra of Permutation Group with generators [(5,6,7)(12,14,18), 
>> (1,2)(3,4)] over Finite Field of size 2
>> sage: kH.one().parent()
>> Algebra of Permutation Group with generators [(5,6,7)(12,14,18), 
>> (1,2)(3,4)] over Finite Field of size 2
>> sage: kH(a).parent() is kH.one().parent()
>> True
>>
>> which I would think should mean that the condition on line 1323 of 
>> sage/src/sage/structure/coerce.pyx that the parents are the same should be 
>> tripped, but for some reason, it is not. I printed the hash of the parents 
>> right before the bug (added it in between lines 1322 and 1323)  and they 
>> have the same hash (547464660303730434), so I am surprised that they are 
>> not considered the same. They are however recognized to be equal, and so 
>> the elif statment checking if they are equal (on line 1327) is triggered, 
>> but then the coercion of y_elt to parent(x_elt) on line 1329 seems to fail, 
>> so that the parent comparison on 1330 still fails, kicking it out to the 
>> coercion error.
>>
>> I'm unsure how to fix this but am willing to do the legwork to fix it if 
>> anyone can explain the problem. 
>>
>> Opening https://trac.sagemath.org/ticket/34292.
>>
>>
>> Full traceback:
>>
>> sage: H = PermutationGroup([[(*1*,*2*), (*3*,*4*)], [(*5*,*6*,*7*),(*12*,
>> *14*,*18*)]])
>>
>> sage: kH = H.algebra(GF(*2*))
>>
>> sage: H.gens()
>>
>> ((5,6,7)(12,14,18), (1,2)(3,4))
>>
>> sage: a, b = H.gens()
>>
>> sage: x = kH(a) + kH(b) + kH.one(); x
>>
>> (5,6,7)(12,14,18) + (1,2)(3,4) + ()
>>
>> sage: x*x
>>
>>
>> ---
>>
>> RuntimeError  Traceback (most recent call 
>> last)
>>
>> Input In [7], in ()
>>
>> > 1 x*x
>>
>>
>> File ~/Applications/sage/src/sage/structure/element.pyx:1514, in 
>> sage.structure.element.Element.__mul__()
>>
>> *   1512* cdef int cl = classify_elements(left, right)
>>
>> *   1513* if HAVE_SAME_PARENT(cl):
>>
>> -> 1514 return (left)._mul_(right)
>>
>> *   1515* if BOTH_ARE_ELEMENT(cl):
>>
>> *   1516* return coercion_model.bin_op(left, right, mul)
>>
>>
>> File ~/Applications/sage/src/sage/structure/element.pyx:1560, in 
>> sage.structure.element.Element._mul_()
>>
>> *   1558* raise bin_op_exception('*', self, other)
>>
>> *   1559* else:
>>
>> -> 1560 return python_op(other)
>>
>> *   1561* 
>>
>> *   1562* cdef _mul_long(self, long n):
>>
>>
>> File ~/Applications/sage/src/sage/categories/coercion_methods.pyx:53, in 
>> sage.categories.coercion_methods._mul_parent()
>>
>> * 51* True
>>
>> * 52* """
>>
>> ---> 53 return (self)._parent.product(self, other)
>>
>>
>> File ~/Applications/sage/src/sage/categories/magmatic_algebras.py:215, in 
>> MagmaticAlgebras.WithBasis.ParentMethods._product_from_product_on_basis_multiply(self,
>>  
>> left, right)
>>
>> *201* *def* _product_from