Libgap tab completion

[vbraun]

This ticket fixes tab completion on the libgap object

sage: libgap.[TAB]
sage: n = libgap(123)
sage: n.[TAB]

CC: @dimpase

Component: group theory

Author: Volker Braun

Branch/Commit: 47bc138

Reviewer: Dima Pasechnik

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

[vbraun]

Branch: u/vbraun/libgap_tab_completion

[vbraun]

Commit: ccc742e

[vbraun]

Author: Volker Braun

[vbraun]

New commits:

ccc742e

Fix libgap tab completion

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. New commits:

807d1a5

Improve tab completion on LibGAP elements

[sagetrac-git]

Changed commit from ccc742e to 807d1a5

[dimpase]

comment:5

Still, the tab completion on objects obtained from libgap does not work; not sure if it was intended to be fixed by this ticket:

sage: g=libgap.GeneralLinearGroup(3,2)
sage: g.
g.N                     g.cartesian_product     g.is_bool               g.is_permutation        g.matrix                g.parent                g.save                  g.version
g.abs                   g.category              g.is_function           g.is_prime              g.multiplicative_order  g.powers                g.subs                  
g.additive_order        g.db                    g.is_list               g.is_record             g.n                     g.rename                g.substitute            
g.base_extend           g.dump                  g.is_nilpotent          g.is_string             g.numerical_approx      g.reset_name            g.trait_names           
g.base_ring             g.dumps                 g.is_one                g.is_zero               g.order                 g.sage                  g.vector                
sage: g.Order()  # this choice not offered, but works...
168

[vbraun]

comment:6

Did you rebuild the Sage library? I get:

sage: g =libgap.GeneralLinearGroup(3,2)
sage: g.
Display all 727 possibilities? (y or n)
g.ANonReesCongruenceOfSemigroup                   g.IsReesMatrixSemigroup
g.AbelianGroupCons                                g.IsReesZeroMatrixSemigroup
g.AbelianInvariants                               g.IsRegular
g.AbelianInvariantsMultiplier                     g.IsRegularSemigroup
...

[dimpase]

comment:7

Replying to @vbraun:

Did you rebuild the Sage library?

hmm, no I didn't. However, are all there 727 options relevant here?
We only want functions which accept Group as the 1st parameter, no?

[vbraun]

comment:8

Its perhaps not too surprising that most GAP functions accept a group...

[videlec]

comment:9

Anyway

sage -t --long src/sage/libs/gap/element.pyx
**********************************************************************
File "src/sage/libs/gap/element.pyx", line 405, in sage.libs.gap.element.GapElement.__dir__
Failed example:
    'GeneratorsOfGroup' in dir(G)
Expected:
    True
Got:
    False
**********************************************************************
1 item had failures:
   1 of   5 in sage.libs.gap.element.GapElement.__dir__
    [356 tests, 1 failure, 1.97 s]

[dimpase]

comment:10

sage: from sage.libs.gap.all_documented_functions import *
sage: g=Group([ [ [ Z(3), 0*Z(3) ],[ Z(3), Z(3) ] ] ])
sage: g
Group([ [ [ Z(3), 0*Z(3) ], [ Z(3), Z(3) ] ] ])
sage: g.O
g.Omega                        g.OmegaOp                      g.OrbitLengthOp                g.OrbitOp                      g.Orbits                       
g.OmegaAndLowerPCentralSeries  g.OmegaSeries                  g.OrbitLengths                 g.OrbitStabilizerAlgorithm     g.OrbitsDomain                 
g.OmegaCons                    g.OneImmutable                 g.OrbitLengthsDomain           g.OrbitStabilizerOp            g.OrdinaryCharacterTable       
sage: g.Order()
6

although g.Size() does work.

sage: g.Si                    
g.Sigma                  g.SingleCollector        g.SingleValuedHashTable  g.Size

[dimpase]

comment:11

indeed, with g as above:

sage: 'Order' in dir(g)
False
sage: 'Size' in dir(g)
True

I'll ask GAP people...

[vbraun]

comment:12

Thats because Order is not a function

gap> IsFunction("Order");
false
gap> Order;
<Attribute "Order">

I guess we should treat attribute as function...

[vbraun]

comment:13

And the name of GeneratorsOfGroup is also susprising

gap> NameFunction(GeneratorsOfGroup);
"GeneratorsOfMagmaWithInverses"

[vbraun]

comment:14

The gap (not: libgap) tab completion also doesn't have GeneratorsOfGroup:

sage: G = gap.SymmetricGroup(3)
sage: G.GeneratorsOf[TAB]
G.GeneratorsOfDomain             G.GeneratorsOfMagmaWithInverses  
G.GeneratorsOfMagma              G.GeneratorsOfMagmaWithOne       
sage: G.GeneratorsOfMagmaWithInverses()
[ (1,2,3), (1,2) ]

[vbraun]

comment:15

Improving tab completion beyond what the gap interface currently does should go into a separate ticket.

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. New commits:

0dccd8d

Fix doctest

[sagetrac-git]

Changed commit from 807d1a5 to 0dccd8d

[dimpase]

comment:18

Replying to @vbraun:

Thats because Order is not a function

gap> IsFunction("Order");

it must be IsFunction(Order);
then you get true

[vbraun]

comment:19

Bump... tab completion is still borked

[dimpase]

comment:20

Aren't we GAP 4.8-based here, and waiting for it to be released?

[vbraun]

comment:21

This ticket is independent of the gap 4.8 update

[dimpase]

comment:22

Is the caching of keywords, etc done in sync with the updates of stored GAP workspaces?
(this is how it looks from reading the code, but perhaps I am missing something)

And what does happen if a GAP package is loaded? (e.g. Graph would only be available
after LoadPackage("grape"))

[vbraun]

comment:23

Caching is done on first use. Testing whether a function is documented is slow enough that we can't do it whenever tab completion is requested. Packages loaded by hand lateron will not be in the tab completion, just as when tab completion worked last time.

[dimpase]

comment:24

I think it is quite convoluted solution, also making it hard to hook up docs of GAP packages.

Namely, the documentation does not magically change once a workspace is updated, but only when libGAP and GAP packages/databases are (re)installed. I'd rather see the corresponding cache built at libGAP (and eventually at GAP packages/GAP database) installation time, and not updated at runtime. This would not be a big rewrite, basically all the functionality for this is already implemented.

I don't have a clear idea how to handle loadable packages, this can be postponed for another ticket.

[vbraun]

comment:25

I agree that there should be better handling of caches (including the workspace), but it should be a separate ticket.

[dimpase]

comment:26

could you add a description of what sage/libs/gap/operations.py is for in the top
part of this file? Is it meant to help with tab completion? How?
Something else?

[sagetrac-git]

Changed commit from 0dccd8d to 47bc138

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. New commits:

47bc138

Add explanation to the operations.py module docstring

[vbraun]

comment:28

Done

[dimpase]

comment:29

great, thanks!

[dimpase]

Reviewer: Dima Pasechnik

[vbraun]

Changed branch from u/vbraun/libgap_tab_completion to 47bc138