LibGAP spkg vote!

[Volker Braun]

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]

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]

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]

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]

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]

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]

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]

+1

John

[Volker Braun]

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]

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]

+100, definitely!

Finally, a hope to resurrect some Sage/GAP code of mine that was chocking on pexpect interface speed...

[Julien Puydt]

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]

> 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]

Thanks Volker, libGAP us a great contribution!

+1

--
Benjamin Jones

[Justin C. Walker]

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]

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]

> 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]

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]

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]

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]

+1!

And thank you!

Franco

--

[P Purkayastha]

+1