Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Clean's foreign function interface

1 view
Skip to first unread message

Siegfried Gonzi

unread,
May 2, 2003, 1:06:51 AM5/2/03
to
[Sorry if you feel: why the fuck does he write this post I am a C pro
and went sour of reading all this primitive things. Note: I am sure
there are a lot of people out there like myself for whom programming is
a second task -- I am a scientist and write my Phd in physics -- but
exactly this foreign function interfacing makes it that hard for
scientists to have a look at tools different from their favorite
environment, because interfacing looks intimidating at a first. For
example if you are used to Matlab then it is unlikely that you will ever
have to deal with foreign functions, and if so, rest assured someone
other has already done the job for you. But if you use something like
Clean for example it becomes hard or impossible to re-write everything
from scratch.]


Clean' s foreign function interface:

Ever wanting to know whether it is easy to include a C function which
has the following prototype:

int fuck(double off,double *ozzy);

By the way: ozzy (osbourne) should be a passed "array/memory-location"
which becomes "updated" in this specific C-function called "fuck".

I am not that versed in foreign function interfacing and C programming,
but what I have seen so far is the following:

-- very complicated and more or less the hell: Python, OCaml (way more
possibilities as opposed to Clean, though)

-- straightforward also for jerks like me: Bigloo (Scheme), Clean (with
the caveat that it lacks sophisticated C-types)

I write the instruction here for Clean, because from the htoclean manual
it is not all that clear whether you can use things other than integers:

Remember: integer offset = 4; double offset = 8; this is all guy what
you have to know.

1. Create the object C file: cc -O -c fuck_c.c

By the way: I often put everything into one big file and use a small
wrapper function therein in order to avoid all the fucking header file
dependencies.

Additionally your C file should include:

==
void *my_malloc (int size_in_bytes)
{
return malloc (size_in_bytes);
}

int my_free (void *p)
{
free (p);
return 0;
}

double val_p(double *p) {return *p;}
==

The first helper function my_malloc allocates memory in a Clean program
(e.g. my_malloc(8*10) creates space for 10 double-precision values); the
second one frees this memory and the third function lets you access a
double value in your "double pointer".

2. Use htoclean and make the header file from fuck.h: htoclean fuck.h

This fuck.h includes for example:

The 3 aforementioned helper-functions and the fuck-function from the
beginning:

==
int fuck(...);
void *my_malloc(...);
int my_free(...);
double val_p(...);
==

[By the way: after htoclean has created fuck.icl and fuck.dcl I have to
de-comment "from StdString import String"; do not ask me why baby]

Now you are ready to use it in your Clean program:

fuck_main.icl
==
module fuck_main
import StdEnv

import fuck

Start
#p=my_malloc(32) //a "32/8=4" element double(=8) vector
#s=fuck 2.34 p // your C function
|s==s \\/forces evaluation of the C-function/
// you want to access the updated values of p?:
# val1=val_p (p+0) \\first element of vector
# val2=val_p (p+24) \\last element of vector
=(val1+val2)
==

I think the scheme is clear. Now you can experiment a bit and copy
around for example the p-values to a list or the like.

Start the Clean program: clm -l fuck_c.o fuck_main
and then ./a.out

[I didn't use "my_free" in the Clean program because often it is
contending to simulate a C memory leak. Different strokes for different
people and I need this kind of kick.]

The above scheme is valid for Linux/Unix and it works with the Clean
2.02 compiler too. I mention this because after downloading Clean 2.02
it was not all that clear whether htoclean needs Clean 1.3.

I am not sure how this works on the Macintosh-platform and Windows. Sold
my Mac 1 1/2 years ago and since then I have more or less never seen
Windows or worked with it. But this foreign-function interfacing stuff,
I think, is always easier to realize under Unix like systems - or isn't?


S. Gonzi


Garry Hodgson

unread,
May 5, 2003, 3:44:36 PM5/5/03
to
Siegfried Gonzi <siegfri...@kfunigraz.ac.at> wrote:

> I am not that versed in foreign function interfacing and C programming,
> but what I have seen so far is the following:
>
> -- very complicated and more or less the hell: Python, OCaml (way more
> possibilities as opposed to Clean, though)

why is it hard in python? you run SWIG on the C headers, and it writes
the code for you. import the module and you're done.

----
Garry Hodgson, Senior Hacker, AT&T Labs

No act is more patriotic than speaking out when your government
is doing the wrong thing in your name. This is not your right
but your sacred duty. And none are more treasonous than those
who would silence these voices.

Donn Cave

unread,
May 6, 2003, 1:36:01 AM5/6/03
to
Quoth Garry Hodgson <ga...@sage.att.com>:

| Siegfried Gonzi <siegfri...@kfunigraz.ac.at> wrote:
|
| > I am not that versed in foreign function interfacing and C programming,
| > but what I have seen so far is the following:
| >
| > -- very complicated and more or less the hell: Python, OCaml (way more
| > possibilities as opposed to Clean, though)
|
| why is it hard in python? you run SWIG on the C headers, and it writes
| the code for you. import the module and you're done.

And ocaml's C interface is about as simple as it could be, in my limited
experience.

Donn Cave, do...@drizzle.com

0 new messages