Sage C Library Files

[Chris Swierczewski]

I began looking at the implementation of opentick yesterday. It
consists of a bunch of header files and a library where all of the
code is stored.

How should I go about getting Sage to communicate with this library?
At first, I was thinking that Sage could install this library during
compilation. That way, one would only need to type

#include "OT<something>.h"

and one would be able to access that code. Otherwise, we would need to
explicitly link the corresponding C/C++ code with the library. So my
more precise question is "what conventions does Sage use to
communicate with libraries"?

--
Chris Swierczewski
cswi...@gmail.com
mobile: 253 2233721

[Glenn H Tarbox, PhD]

This will likely be answered by somebody with a clue... but there's a
way to have "experimental" spkg's. So, just go ahead and assume the
code will be installed for now. Until its stable, folks may need to add
the package using sage -i <package-name>

kinda what william did for pyprocessing where he wrote:

>>>>>>
It takes one second to install and works on OSX, Windows, Linux, etc.:
sage -i processing-0.52
<<<<<

so, whatever black magic is used to support the -i capability, we'll
figure out.

-glenn

>
> --
> Chris Swierczewski
> cswi...@gmail.com
> mobile: 253 2233721
>
> >

--
Glenn H. Tarbox, PhD || 206-494-0819 || gl...@tarbox.org
"Don't worry about people stealing your ideas. If your ideas are any
good you'll have to ram them down peoples throats" -- Howard Aiken

[mabshoff]

On Jul 7, 1:00 pm, "Glenn H Tarbox, PhD" <gl...@tarbox.org> wrote:
> On Mon, 2008-07-07 at 10:19 -0700, Chris Swierczewski wrote:

Hi,

> > I began looking at the implementation of opentick yesterday. It  
> > consists of a bunch of header files and a library where all of the  
> > code is stored.
>
> > How should I go about getting Sage to communicate with this library?  
> > At first, I was thinking that Sage could install this library during  
> > compilation. That way, one would only need to type
>
> > #include "OT<something>.h"
>
> > and one would be able to access that code. Otherwise, we would need to  
> > explicitly link the corresponding C/C++ code with the library. So my  
> > more precise question is "what conventions does Sage use to  
> > communicate with libraries"?

What do you mean by convention? In the end it is just Cython.

> This will likely be answered by somebody with a clue... but there's a
> way to have "experimental" spkg's.  So, just go ahead and assume the
> code will be installed for now.  Until its stable, folks may need to add
> the package using sage -i <package-name>
>
> kinda what william did for pyprocessing where he wrote:
> 
>
> It takes one  second to  install and works on OSX, Windows, Linux, etc.:
>       sage -i processing-0.52
> <<<<<
>
> so, whatever black magic is used to support the -i capability, we'll
> figure out.

Once you have an spkg and we merge it into the official repo "-i" just
magically works. You can also give "-i" some random url and it should
also work.

There is one problem: If you merge something into the Sage library and
it "C" includes something that is not in standard Sage it will fail.
Enabling optional packages to have Cython extensions is a desired
feature and currently unsolved. There is a ticket for it in trac.

> -glenn

Cheers,

Michael

>
>
> > --
> > Chris Swierczewski
> > cswie...@gmail.com

[Chris Swierczewski]

Hello,

> What do you mean by convention? In the end it is just Cython.

What I meant is "how do I introduce static libraries into Sage so that
my Cython code can communicate with it?"

> Once you have an spkg and we merge it into the official repo "-i" just
> magically works. You can also give "-i" some random url and it should
> also work.

Still being somewhat of a newbie to the structure of Sage, I just
discovered the $SAGE_ROOT/local/lib directory. I'm assuming that this
is where developers put their really fast C code for use in Sage
function. (e.g. GAP) So from what I understand, you suggest that I
create an spkg that simply puts the static library in $SAGE_ROOT/local/
lib and the related header files in $SAGE_ROOT/local/include? Then, I
can assume that if I type

#include "OTClient.h"

which is one of the header files for the opentick source, then
communication with the code in the static library will be established.
That is, $SAGE_ROOT/local/lib and header can be thought of as an
extension of /usr/local/lib and header that Sage exclusively uses.

Thanks for your help!

--
Chris

[Chris Swierczewski]

I'm also assuming that these guidelines are up to date?

http://modular.math.washington.edu/sage/doc/html/prog/node24.html

--
Chris

[Glenn H Tarbox, PhD]

On Mon, 2008-07-07 at 16:05 -0700, Chris Swierczewski wrote:
> Hello,
>
> > What do you mean by convention? In the end it is just Cython.
>
> What I meant is "how do I introduce static libraries into Sage so that
> my Cython code can communicate with it?"

I address "communicate" below...

>
> > Once you have an spkg and we merge it into the official repo "-i" just
> > magically works. You can also give "-i" some random url and it should
> > also work.
>
> Still being somewhat of a newbie to the structure of Sage, I just
> discovered the $SAGE_ROOT/local/lib directory. I'm assuming that this
> is where developers put their really fast C code for use in Sage
> function. (e.g. GAP) So from what I understand, you suggest that I
> create an spkg that simply puts the static library in $SAGE_ROOT/local/
> lib and the related header files in $SAGE_ROOT/local/include? Then, I
> can assume that if I type
>
> #include "OTClient.h"
>
> which is one of the header files for the opentick source, then
> communication with the code in the static library will be established.
> That is, $SAGE_ROOT/local/lib and header can be thought of as an
> extension of /usr/local/lib and header that Sage exclusively uses.

Interesting use of the word "communication"... perhaps in the abstract
its right. In more conventional terms, you wanna make sure your
"stuff" (another technical term :-) is on the path.

So, I think you have it right. do what you said above... but don't
worry this up front... get things going and we'll worry about the
spkg'ing once we have things partially working.

What mabshoff was saying is that to build your stuff might require other
stuff that isn't in the distro. I don't think this is an issue in our
case... but when it is, it begins to get into optionally grabing other
dependent packages... and we get closer to what the debian and fedora
folks do with their .debs and .rpms...

-glenn

>
> Thanks for your help!
>
> --
> Chris
> >

[William Stein]

> There is one problem: If you merge something into the Sage library and
> it "C" includes something that is not in standard Sage it will fail.
> Enabling optional packages to have Cython extensions is a desired
> feature and currently unsolved. There is a ticket for it in trac.

I strongly disagree with this assessment. An optional package can be any
Python package (e.g., sympy, twisted, whatever) which may or may not
use cython. An optional package should *not* install code into the sage
library itself (under sage.all).

william

[William Stein]

On Mon, Jul 7, 2008 at 6:25 PM, William Stein <wst...@gmail.com> wrote:
>> There is one problem: If you merge something into the Sage library and
>> it "C" includes something that is not in standard Sage it will fail.
>> Enabling optional packages to have Cython extensions is a desired
>> feature and currently unsolved. There is a ticket for it in trac.
>
> I strongly disagree with this assessment. An optional package can be any

Upon closer reading I see that you wrote "the Sage Library" above,
so I strongly disagree with myself. However, the right way to
have optional packages is to *not* make them part of the standard
sage library -- just make them other libraries (like the thousands
of other python packages out there).

> Python package (e.g., sympy, twisted, whatever) which may or may not
> use cython. An optional package should *not* install code into the sage
> library itself (under sage.all).
>
> william
>

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