Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

libgap: distinct __str__ and __repr__ for GapElements #27946

Closed
embray opened this issue Jun 7, 2019 · 8 comments
Closed

libgap: distinct __str__ and __repr__ for GapElements #27946

embray opened this issue Jun 7, 2019 · 8 comments

Comments

@embray
Copy link
Contributor

embray commented Jun 7, 2019

Currently the libgap.GapElement objects have a __repr__ (but no explicit __str__, so the two are the same) which is taken from calling the GAP function ViewObj on the object and capturing and returning the result. This is essentially the same as when you display the object in a GAP interpreter prompt without using Print(), such as:

gap> a := "hello";
"hello"
gap> a;
"hello"

Although GAP has many options for displaying/printing variables, this makes ViewObj the closest possible thing to the __repr__ method on Python objects, which is called in similar circumstances:

>>> a = "hello"
>>> a
"hello"

This is in stark contrast with the pexpect interface's GapElement which (through a sequence of calls) effectively implements its __repr__ by calling Print(obj). Arguably this was not the best choice, but changing it might be tricky at this point. However, it does not explicitly implement __str__, so GapElement.__str__ does give a sensible result in this case.

Arguably Print(obj) is the right choice for __str__ since again in rough comparison with Python, when you print(...) an object in Python its __str__ is called.

This proposes to change just the libgap interface to meet this specification: libgap.GapElement.__str__ captures the output of Print(obj) and returns it. While libgap.GapElement.__repr__ captures and returns the output of ViewObj(obj).

This gives the best of both worlds, and better consistency in most contexts where GapElements are converted to strings, making replacing pexpect gap with libgap easier and less disruptive.

CC: @nthiery

Component: interfaces

Keywords: gap libgap

Author: Erik Bray

Branch/Commit: 63db722

Reviewer: Vincent Delecroix

Issue created by migration from https://trac.sagemath.org/ticket/27946

@embray embray added this to the sage-8.8 milestone Jun 7, 2019
@embray
Copy link
Contributor Author

embray commented Jun 7, 2019

comment:1

Here is a branch for this specific change that I extracted from the rest of my work on #18267, since this change is worth considering in its own right. Still needs a bit more testing to ensure it didn't inadvertently break any other tests.


New commits:

63db722Add a GapElement.__str__ that works the same as the pexpect GapElement._repr_ (and hence its `__str__` as well).

@embray
Copy link
Contributor Author

embray commented Jun 7, 2019

Author: Erik Bray

@embray
Copy link
Contributor Author

embray commented Jun 7, 2019

Commit: 63db722

@embray
Copy link
Contributor Author

embray commented Jun 7, 2019

Branch: u/embray/libs/gap/separate-str-repr

@embray
Copy link
Contributor Author

embray commented Jun 7, 2019

comment:2

Works without test failures for me.

@videlec
Copy link
Contributor

videlec commented Jun 8, 2019

Reviewer: Vincent Delecroix

@vbraun
Copy link
Member

vbraun commented Jun 27, 2019

Changed branch from u/embray/libs/gap/separate-str-repr to 63db722

@embray
Copy link
Contributor Author

embray commented Jul 3, 2019

comment:5

Not in Sage 8.8. Let's please to try keep tickets' milestones related to the release in which we actually intend to include them, and in particular the release in which they were actually included, especially when closing tickets.

@embray embray modified the milestones: sage-8.8, sage-8.9 Jul 3, 2019
vbraun pushed a commit that referenced this issue Mar 26, 2023
    
### 📚 Description

Trac branch `u/gh-collares/gap-gc` from #34701, now migrated to GitHub.
Currently based atop #35093; will rebase once that is merged.

The rest of the description below is copied from #34701:

A refactor in #27946 introduced "unprotected" (not surrounded by
`GAP_Enter`/`GAP_Leave`) `GAP_ValueGlobalVariable` calls. I believe this
might be a GC hazard, because after updating to GAP 4.12.1 I started
seeing aarch64 crashes on NixOS infrastructure such as:

```
#0  0x0000fffff79740e8 in wait4 ()
#1  0x0000fffff5dc6b78 in print_enhanced_backtrace ()
#2  0x0000fffff5dc8190 in sigdie ()
#3  0x0000fffff5dcb1c0 in cysigs_signal_handler ()
#4  0x0000fffff7ffb7cc in __kernel_rt_sigreturn ()
#5  0x0000ffff99a0bf28 in ConvString ()
#6  0x0000000000000000 in ?? ()
#7  0x0000000000000000 in ?? ()
#8  0x0000000000000000 in ?? ()
#9  0x0000ffff99989930 in Pr ()
#10 0x0000ffff9998aa18 in CloseOutput ()
#11 0x0000ffff99884828 in capture_stdout () at /build/sage-
src-9.7/pkgs/sagemath-standard/sage/libs/gap/element.pyx:154
...
```
I also see cases where `capture_stdout` throws errors such as
`sage.libs.gap.util.GAPError: Error, Length: <list> must be a list (not
the integer 255)` and then crashes. Both types of errors are fixed by
this ticket.

Note that I am nesting `GAP_Enter`/`GAP_Leave` calls because I didn't
remove the preexisting calls inside `capture_stdout`. That's because I
feared removing the innermost calls might create a new footgun (and I
believe nested `GAP_Enter`/`GAP_Leave` calls are explicitly supported),
but removing them should cause no problem. Removing them might even be
preferable for performance reasons, I don't know.

Fixes #34701

### 📝 Checklist

<!-- Put an `x` in all the boxes that apply. -->
<!-- If your change requires a documentation PR, please link it
appropriately -->
<!-- If you're unsure about any of these, don't hesitate to ask. We're
here to help! -->

- [x] I have made sure that the title is self-explanatory and the
description concisely explains the PR.
- [x] I have linked an issue or discussion.
- [ ] I have created tests covering the changes.
- [ ] I have updated the documentation accordingly.

### ⌛ Dependencies
<!-- List all open pull requests that this PR logically depends on -->
<!--
- #xyz: short description why this is a dependency
- #abc: ...
-->
- #35093: GAP 4.12.2 upgrade, which touches the same function and should
land first.
    
URL: #35114
Reported by: Mauricio Collares
Reviewer(s): Dima Pasechnik
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants