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.

Sign up for GitHub

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

Jump to bottom

Don't use functions/macros not defined in the libgap API #2

Open
embray opened this issue Jan 6, 2021 · 0 comments
Open

Don't use functions/macros not defined in the libgap API #2

embray opened this issue Jan 6, 2021 · 0 comments
Labels
enhancement New feature or request

Comments

@embray
Copy link
Owner

embray commented Jan 6, 2021

Before there was an effort to strictly define a "public" C API for GAP, Sage's libgap interface used anything it could find from GAP's headers.

In most cases I believe the (still somewhat informal) public API should meet our needs; in cases where it does not it might indicate some surface area where the API needs to be expanded. There might also still be some cases where it is more efficient to go around the API and use GAP internals directly (though that too should be discussed).
@embray embray added the enhancement New feature or request label Jan 6, 2021
embray added a commit that referenced this issue Jan 13, 2021
@embray
Use public libgap API for list functions where possible. Refs #2.
80f610e
embray added a commit that referenced this issue Jan 13, 2021
@embray
Simplify GapFunction.__call__ using the public API GAP_CallFuncList
35c04c0 
Refs #2.
embray added a commit that referenced this issue Jan 13, 2021
@embray
Replace most use of internal functions for strings with the public
f284a12 
libgap API.  Refs #2.

The outlying exception currently is C_NEW_STRING which does not have an
exact analogue in the public libgap API.  The closest thing is
GAP_MakeString, but this assumes the string is NULL-terminated, meaning
it can't be used to convert arbitrary Python bytes objects containing
nulls.  In practice this won't often come up, but better safe than sorry
until a new API can be added.
embray added a commit that referenced this issue Jan 13, 2021
@embray
Replace C_NEW_STRING with MakeStringWithLen, as the former is mentioned
3fc9bd3 
in the GAP headers as being deprecated.

The latter is aliased to GAP_MakeStringWithLen in anticipation that this
will hopefully be added to the libgap API; see
gap-system/gap#4211

Refs #2
embray added a commit that referenced this issue Jan 13, 2021
@embray
Remove all use of internal functions for GAP records, and use the libgap
bab12bc 
API instead (refs #2)

Some things are simplified here; e.g. we no longer need
GapRecordIterator since Cython has supported generates well since
whenever this was first written.

However, some of this might also be less efficient, as iterating over
the record now requires first returning all names in the record as a
list.  It might be nice if the libgap API provided some sort of record
iterator interface.
embray added a commit that referenced this issue Jan 14, 2021
@embray
Use arithmetic operators from libgap-api.h. Refs #2.
fdc2f7b
embray added a commit that referenced this issue Jan 14, 2021
@embray
Use GAP_True and GAP_False from libgap-api.h. Refs #2.
164c35f
embray added a commit that referenced this issue Jan 14, 2021
@embray
Use GAP_ValueMacFloat in favor of internal VAL_MACFLOAT. Refs #2.
e3acb0c
embray added a commit that referenced this issue Jan 14, 2021
@embray
Get rid of remaining "private" includes from GAP headers that are not
63d3cea 
needed.

This winnows us down to the remaining bits that need interfaces in
libgap.  Refs #2
embray added a commit that referenced this issue Jan 14, 2021
@embray
Get rid of remaining includes from gap/objects.h by using equivalents
df477cf 
that are exposed at the GAP level.

This might still be worthwhile candidates for the public libgap C-API
but I'm not sure it's that important at the moment.

Refs #2
embray added a commit that referenced this issue Jan 14, 2021
@embray
Rename MarkBag -> GAP_MarkBag and CollectBags -> GAP_CollectBags in
f379d30 
anticipation that they will be added to the libgap API.

See gap-system/gap#3030

Refs #2
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement New feature or request
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@embray