Changes between Version 192 and Version 193 of Ticket #22626


Ignore:
Timestamp:
11/13/18 16:20:21 (3 years ago)
Author:
embray
Comment:

Should I just go ahead and attach my branch to this ticket?

It's up to date with my current work, which mostly works pretty well except for three major issues that I'm aware of:

1) The weirdness with hanging during GAP initialization if there is an existing workspace. This might have something to do with the issue Markus has mentioned w.r.t. spawning a shell (??) for some reason. I'm going to look into that next since I consider it the most severe issue for getting something usable. I'm sure I can figure it out quickly; I just haven't investigated it at all yet.

2) General issues regarding signal handling. The situation there mostly isn't great--I found some cases where even GAP's eval loop can't be interrupted. I agree with Jeroen that ideally that's "not acceptable", but I believe we may need to compromise in the near term (and the situation isn't all that better in current Sage either).

3) The Panic issue. I've confirmed that affects current Sage as well. I believe Markus has made some comment to suggest he's thinking about that (among other related issues) so we may have a solution at some point (I think the obvious one, at least broadly speaking, is just having a hook for what Panic actually does). But I'm not going to worry about that for the purposes of GAP 4.10 integration since it's at least not a regression.

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #22626 – Description

    v192 v193  
    1616- Update a few doctests w.r.t. changes of output of some GAP functions
    1717
    18 - **Possibly controversial:** The new libgap currently *does not come* with symbol rewriting (`foobar` -> `libGAP_foobar`). This avoids messing around with GAP's sources; in particular opening the door for using a stock GAP from the OS distribution. However there always is a risk of name conflicts. And indeed, GAP's enums `T_INT`, `T_FLOAT`, ... conflict with Python's constants defined in `structmember.h`. This is hopefully not actually a problem in practice due to the way how Cython orders includes.
     18- **Possibly controversial:** The new libgap currently *does not come*
     19  with symbol rewriting (`foobar` -> `libGAP_foobar`). This avoids messing
     20  around with GAP's sources; in particular opening the door for using
     21  a stock GAP from the OS distribution. However there always is a risk
     22  of name conflict. And indeed, GAP's constants (actually cpp macros)
     23  T_INT, T_FLOAT, ... conflict with Python's constants. This is
     24  currently worked around by forcing the inclusion of Python's
     25  `structmember.h` before the gap headers.
    1926
    2027  Something similar was started by Volker at #19915.