extracting c interface to kona

[Neeraj Rai]

Hi Steven,

Based on Bakul's post to c - interface , I would like to suggest that main function be taken out of k.c into esparate file, (say main.c)

the exitsing obj files can be made into a lib then linked with main.c to make k executable.

People looking to use c interface in their code, can link with the lib.

this very little effort may give us c interface for free.

There may be concerns about linking a very large lib in the c interface.

However  those agreeable to using it can get going immediately.

Please let me know your thoughts.

thanks

Neeraj

P.S: I started this as a brain storming post and continuing my original post which is mainly for my learning/initiation into kona

[Bakul Shah]

On Tue, 30 Apr 2013 19:42:48 PDT Neeraj Rai <rneer...@gmail.com> wrote:
>
> Hi Steven,

Steven?

> Based on Bakul's post to c - interface , I would like to suggest that main
> function be taken out of k.c into esparate file, (say main.c)
> the exitsing obj files can be made into a lib then linked with main.c to
> make k executable.
> People looking to use c interface in their code, can link with the lib.
>
> this very little effort may give us c interface for free.
> There may be concerns about linking a very large lib in the c interface.
> However those agreeable to using it can get going immediately.
> Please let me know your thoughts.

Opinion: directly using any of kona's C functions from any
client C code is asking for trouble in the long term. A wider
interface means more things can go wrong and many more things
have to be clearly documented. A narrow C API allows the
implementation to change without (usually) impacting the API's
clients. I recall reading that Arthur Whitney wrote every new
major verion of K from scratch! This sort of complete rewrite
may not happen with kona but changes for optimization or
extensions etc seem certainly possible.

Incidentally the library is pretty small. Compile everything
with -O3 and the test program code size is about 184K.
Statically linking in libc & libm bloats it to 824K!

[Neeraj Rai]

Sorry for the mixup.  I meant Kevin.

I would like to hear your views about it too.

If you want to wait for or solicit more feedback, that is fine too.

Thanks for your feedback Bakul.

thx

Neeraj

[Kevin Lawler]

I think Bakul is right we should be cautious, but I think the code
base is stable enough that, with care, we could define a properly
working C API. (It's certainly been done before successfully.)

This would be a good project for anybody interested in Kona to take
on. I haven't split out a C API before I am not an expert in the
skills you apparently need (object files, make, etc.), so this is not
something I could push in a few minutes to the repo. Scott Vokes tends
to be better at this kind of thing, though I don't know if he wants to
be dragged into it. As a project I don't think it's any more advanced
than any of the other C stuff we've done. This one's feasible for
anyone with solid C skills and a cautious eye.

I would guess this would take a contributor anywhere from two hours to
two days, maybe more if you include building out missing K API
functions (gi, gf, gtn, gp, kap, sfn, etc.). Marking missing functions
as "not yet implemented" would be fine, provided the regular source
and the API source were partitioned correctly.

If someone wants to do this I would try it on your fork and then share
it with everyone for review. Once enough people have looked at it and
it's gone through a few revisions we could merge it to the main repo.
I wouldn't submit a pull request for a first draft---that would likely
get rejected.

Kevin

> --
> You received this message because you are subscribed to the Google Groups
> "Kona Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to kona-dev+u...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Neeraj Rai]

Hi Kevin,

I wouldn't expect people to switch to work on this unless they need it. 

I guess, the only one motivated enough to try this might be me.

I am glad that feasibility and need have been confirmed by you. I wasn't sure if alternatives exist.

I may take more that 2 days to get this done , with my current level of understanding. 

I will give it a shot, but you may see long gap before next activity.

Just to confirm the approach again.

If I start with pulling out XN and then follow the functions needed by XN, that should lead me to an expected end result ?

I am not sure what api you refered to, but we can discuss that once some  progress is made.

I am expecting to pull the functions out into new .c and .h file. These would be linked into a .o or .lib.

the k would be created by using the current obj and this new one.

In addition, anyone wishing to use c interface can link with the new one.

Please confirm my understanding of the task.

thx

Neeraj

[Bakul Shah]

FYI: I started investigating this and ended up spending a couple
of hours on it. It is *roughly* in the right shape. Details below.

Current k, k_test build and work as before. My test program
compiles but is useless at the moment. The main problem is ksk().
Example ksk() use:

K r = ksk("{x*y}", gnk(2,gi(10),gi(15)));
assert(Ki(r) == 150);
cd(r);
r = ksk("!10", 0);
if (r->t==6 && r->n)
fprintf(stderr, "Error: %s\n",(S)r->n);

I suspect Kevin can implement ksk() in minutes but I couldn't
see an easy way to hack it in (after an admittedly cursory
glance at the code). The rest of the k3 API seems easy.

This is on a separate branch. Basically this is the task list:

* create kona.h (the API header file)
- remove duplicate definitions from ts.h etc.
+ add kapi.c (the API glue code)
- implement api functions
- add tests
* move main() to a separate file & fix up Makefile
* Add rules for a kona library to the Makefile
- Add rules for a shared library for various platforms
- add lib + header install
[* == done, + == progress, - == no progress]

So not very far from having a working first cut of the APi
provided how to implement ksk() can be figured out.

[Kevin Lawler]

Yep, ksk is a few lines if you already know how. Any functions like
that it's fine to mark "R NYI;" and leave them for the next guy.

[Neeraj Rai]

Hi Bakul,

Wow, that's really good progress for 2 hours.

I am not sure I understand the issue you mention with ksk ?

Is ksk taking a string and converting to binary representation for kona ?

is that similar to what X () or XN() do ?

thanks

Neeraj