LibGAP spkg vote!

75 views
Skip to first unread message

Volker Braun

unread,
Sep 23, 2012, 9:40:40 AM9/23/12
to sage-...@googlegroups.com
LibGAP (the C library interface to GAP) is finally usable and ready to be released into the wild! We will ship it as a separate spkg since
  * Upstream doesn't build a shared library
  * The build system is replaced by standard autotools
  * To avoid symbol collisions every gap function and global variable is renamed with a libGAP_ prefix
  * We add hooks to input/output, error handling, and the GAP memory manager.

Actually, prefixing the symbols in a library might be a good idea in other libraries that were not originally written with sharing in mind. If two functions have the same name in two shared libraries, then (at least on Linux) the first one wins which is almost certainly not what the second library wants. LibGAP does the prefixing with a script using the python ply module to identify the globals.

Per the usual rules, new spkgs need a vote so now is your chance to be heard ;-)


mmarco

unread,
Sep 23, 2012, 9:48:42 AM9/23/12
to sage-devel
I am really excited about this. My vote would be a big +1.

I guess that, at least for a (long) while, both gap interfaces will
coexist, since lot of code deppends on the old pexpect one. But the
speed difference is so big that i think it would be worth the effort
of porting old code to the new interface.

John Cremona

unread,
Sep 23, 2012, 9:57:39 AM9/23/12
to sage-...@googlegroups.com
About prefixing symbols: is there an automatic way to do this or is
it a question of editing all source files (tedious and prone to
error)? And how does it related to using namespaces?

John
> --
> You received this message because you are subscribed to the Google Groups "sage-devel" group.
> To post to this group, send email to sage-...@googlegroups.com.
> To unsubscribe from this group, send email to sage-devel+...@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-devel?hl=en.
>
>

William Stein

unread,
Sep 23, 2012, 9:57:54 AM9/23/12
to sage-...@googlegroups.com
On Sun, Sep 23, 2012 at 6:48 AM, mmarco <mma...@unizar.es> wrote:
> I am really excited about this. My vote would be a big +1.
>
> I guess that, at least for a (long) while, both gap interfaces will
> coexist, since lot of code deppends on the old pexpect one. But the
> speed difference is so big that i think it would be worth the effort
> of porting old code to the new interface.

How hard will porting code be? How much different is the interface
that Volker ended up developing for libGAP?

And +1 for a new libgap spkg.

-- William

>
> On 23 sep, 15:40, Volker Braun <vbraun.n...@gmail.com> wrote:
>> LibGAP (the C library interface to GAP) is finally usable and ready to be
>> released into the wild! We will ship it as a separate spkg since
>> * Upstream doesn't build a shared library
>> * The build system is replaced by standard autotools
>> * To avoid symbol collisions every gap function and global variable is
>> renamed with a libGAP_ prefix
>> * We add hooks to input/output, error handling, and the GAP memory
>> manager.
>>
>> Actually, prefixing the symbols in a library might be a good idea in other
>> libraries that were not originally written with sharing in mind. If two
>> functions have the same name in two shared libraries, then (at least on
>> Linux) the first one wins which is almost certainly not what the second
>> library wants. LibGAP does the prefixing with a script using the python ply
>> module to identify the globals.
>>
>> Per the usual rules, new spkgs need a vote so now is your chance to be
>> heard ;-)
>
> --
> You received this message because you are subscribed to the Google Groups "sage-devel" group.
> To post to this group, send email to sage-...@googlegroups.com.
> To unsubscribe from this group, send email to sage-devel+...@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-devel?hl=en.
>
>



--
William Stein
Professor of Mathematics
University of Washington
http://wstein.org

William Stein

unread,
Sep 23, 2012, 10:03:11 AM9/23/12
to sage-...@googlegroups.com
On Sun, Sep 23, 2012 at 6:57 AM, John Cremona <john.c...@gmail.com> wrote:
> About prefixing symbols: is there an automatic way to do this or is
> it a question of editing all source files (tedious and prone to
> error)? And how does it related to using namespaces?

From the original post: "LibGAP does the prefixing with a script using
the python ply module to identify the globals."

- William

John Cremona

unread,
Sep 23, 2012, 10:11:32 AM9/23/12
to sage-...@googlegroups.com
On 23 September 2012 15:03, William Stein <wst...@gmail.com> wrote:
> On Sun, Sep 23, 2012 at 6:57 AM, John Cremona <john.c...@gmail.com> wrote:
>> About prefixing symbols: is there an automatic way to do this or is
>> it a question of editing all source files (tedious and prone to
>> error)? And how does it related to using namespaces?
>
> From the original post: "LibGAP does the prefixing with a script using
> the python ply module to identify the globals."

Thanks, I had missed that.

John

>
> - William
>

David Joyner

unread,
Sep 23, 2012, 10:12:36 AM9/23/12
to sage-...@googlegroups.com
On Sun, Sep 23, 2012 at 9:40 AM, Volker Braun <vbrau...@gmail.com> wrote:
> LibGAP (the C library interface to GAP) is finally usable and ready to be
> released into the wild! We will ship it as a separate spkg since

...

>
> Per the usual rules, new spkgs need a vote so now is your chance to be heard
> ;-)
>

+1

John Cremona

unread,
Sep 23, 2012, 10:13:24 AM9/23/12
to sage-...@googlegroups.com
+1

John

Volker Braun

unread,
Sep 23, 2012, 10:24:33 AM9/23/12
to sage-...@googlegroups.com
This is the script that does the dirty work:

https://bitbucket.org/vbraun/libgap/src/e3a3adc06dd8/spkg/libGAPify.py

C doesn't have namespaces, its a C++ feature. Of course thats would be a good solution, but not for GAP which is written in (pre-ansi) C. Other good solutions are only exporting the functions that you know you need using __attribute__ visibility but that requires some foresight to what will be useful in the shared library ;-)

Simon King

unread,
Sep 23, 2012, 10:57:23 AM9/23/12
to sage-...@googlegroups.com
Hi Volker,

On 2012-09-23, Volker Braun <vbrau...@gmail.com> wrote:
> Per the usual rules, new spkgs need a vote so now is your chance to be
> heard ;-)

As you may guess from my talk in St Andrews, it is a big +1 from me as
well!

Thank you very much,
Simon


Dima Pasechnik

unread,
Sep 23, 2012, 11:34:04 AM9/23/12
to sage-...@googlegroups.com
+100, definitely!
Finally, a hope to resurrect some Sage/GAP code of mine that was chocking on pexpect interface speed...

Julien Puydt

unread,
Sep 23, 2012, 2:49:10 PM9/23/12
to sage-...@googlegroups.com
Le 23/09/2012 15:40, Volker Braun a �crit :
> Per the usual rules, new spkgs need a vote so now is your chance to be
> heard ;-)

+1 direct interface is so much better than through a pexpect...


Snark on #sagemath

mmarco

unread,
Sep 23, 2012, 4:00:36 PM9/23/12
to sage-devel

> How hard will porting code be? How much different is the interface
> that Volker ended up developing for libGAP?
>

Porting my fpgroups code was pretty much straightforward. It is
(almost) a mechanical work... but a work that has to be done. I am not
sure if it is automatic enough to be done by a script. What i did is
to change by hand all the definitions of the gap objects i use. After
that, it is a matter of tuning stuff like opening and closing
brackets, quotes and so on.

To give you an idea: my poroject is about 2000 lines of code, a big
part of it dealing with the gap interface. I don't remember exactly
how much time it took to port itby hand it to the libgap interface;
but i am sure i did it in less than a day.

Benjamin Jones

unread,
Sep 23, 2012, 5:09:12 PM9/23/12
to sage-...@googlegroups.com
Thanks Volker, libGAP us a great contribution!

+1

--
Benjamin Jones

Justin C. Walker

unread,
Sep 23, 2012, 10:01:55 PM9/23/12
to sage-...@googlegroups.com

On Sep 23, 2012, at 06:40 , Volker Braun wrote:

> LibGAP (the C library interface to GAP) is finally usable and ready to be
> released into the wild! We will ship it as a separate spkg since
> * Upstream doesn't build a shared library
> * The build system is replaced by standard autotools
> * To avoid symbol collisions every gap function and global variable is
> renamed with a libGAP_ prefix
> * We add hooks to input/output, error handling, and the GAP memory
> manager.

> Per the usual rules, new spkgs need a vote so now is your chance to be
> heard ;-)

Nice!

+1

Justin

--
Justin C. Walker, Curmudgeon-At-Large
Institute for the Enhancement of the Director's Income
--------
Experience is what you get
when you don't get what you want.
--------



Rob Beezer

unread,
Sep 24, 2012, 12:28:04 AM9/24/12
to sage-...@googlegroups.com
On Sunday, September 23, 2012 6:40:40 AM UTC-7, Volker Braun wrote:
Per the usual rules, new spkgs need a vote so now is your chance to be heard ;-)

Anything that improves the reliability and speed of code built on GAP is a +1 from me.

Thanks, Volker, for this, and your recent work (along with others) on the upgrade to the latest GAP version!

Rob
 
 

Nicolas M. Thiery

unread,
Sep 24, 2012, 5:09:40 AM9/24/12
to sage-...@googlegroups.com
> LibGAP (the C library interface to GAP) is finally usable and
> ready to be released into the wild!

Yippee!!! That will make such a difference!

> Per the usual rules, new spkgs need a vote so now is your chance to be
> heard ;-)

+1 without a question.

Thanks!
Nicolas
--
Nicolas M. Thi�ry "Isil" <nth...@users.sf.net>
http://Nicolas.Thiery.name/

William Stein

unread,
Sep 24, 2012, 6:13:47 AM9/24/12
to sage-...@googlegroups.com
I wrote the first version of libGAP at the Barcelona Sage days a few
years, and at that time I had planned it to basically be a drop-in
replacement for the pexpect interface. Did the design diverge a lot
from that?


William

Volker Braun

unread,
Sep 24, 2012, 7:32:05 AM9/24/12
to sage-...@googlegroups.com
A lot of things should work if you just replace gap with libgap (or import libgap as gap). One difference is that the libgap() element constructor prioritizes creating the analogous gap object, in particular for strings:

sage: libgap('string')
"string"
sage: type(_)
<type 'sage.libs.gap.element.GapElement_String'>

If you want to evaluate a gap command as string, you need to use libgap.eval(). I think this is less confusing than mashing conversion and command execution into the same call.

Also, more Python <-> GAP type correspondences are supported, and there is a class hierarchy of GapElements. For example dict<->rec:

sage: r = libgap({'one':1}); r
rec( one := 1 )
sage: type(r)
<type 'sage.libs.gap.element.GapElement_Record'>
sage: r['one']
1

kcrisman

unread,
Sep 24, 2012, 8:09:39 AM9/24/12
to sage-devel
Since this wasn't an optional spkg before, in theory it needs a test
run as optional... though I strongly suspect that would be overridden
in this case :)

Franco Saliola

unread,
Sep 24, 2012, 9:34:14 AM9/24/12
to sage-...@googlegroups.com
+1!

And thank you!

Franco

--

P Purkayastha

unread,
Sep 24, 2012, 1:47:50 PM9/24/12
to sage-...@googlegroups.com
+1

Reply all
Reply to author
Forward
0 new messages