Wonderful! Thank you so much for posting that Phil! I was not able to build the code using the Makefile because my system does not have libpolyml.so; however, the commands within the Makefile did work, so perhaps that file is not needed? I put them within the attached tgz file in a shell script. Here are the commands in that file:
gcc -fPIC -g -Wall -c testlib.c -o testlib.o
gcc -shared -Wl,-soname,testlib.so.1 -o testlib.so.1 testlib.o
polyc call_c_test_10.sml
LD_LIBRARY_PATH=. ./a.out
and this runs successfully displaying the output in an X Window!
I think this is a viable approach to integrating PolyML with a GUI or at
least graphics output but of course will require lots of experimenting...I
wish I had tons of time, but will only be able to try things
once-in-a-while now that a new semester has begun.
Here is the modified C program that invokes the Motif window:
(but it is also in the attached tgz file if you want to try it)
#include <stdio.h>
#include <Xm/Xm.h>
#include <Xm/Label.h>
#include <stdlib.h>
double (*sml_hypot) (double x, double y);
void c_main (void)
{
double a, b, c;
a = 3.0;
b = 4.0;
printf("a = %.6f\n", a);
printf("b = %.6f\n", b);
c = sml_hypot (a, b); /* call back to SML! */
printf("c = %.6f\n", c);
fflush(stdout);
char msg[256];
sprintf(msg,"c = %.6f\n", c);
Widget shell;
XtAppContext app;
XmString xmstr;
int argc = 1;
char* argv[] = {"polygui" };
shell = XtAppInitialize ( &app, "Memo", NULL, 0,
&argc, argv, NULL, NULL, 0 );
xmstr = XmStringCreateLtoR ( msg, XmFONTLIST_DEFAULT_TAG );
XtVaCreateManagedWidget ( "message",
xmLabelWidgetClass, shell,
XmNlabelString, xmstr,
NULL );
XmStringFree ( xmstr );
XtRealizeWidget ( shell );
XtAppMainLoop ( app );
return;
}
On Thu, Jan 22, 2015 at 4:00 AM, <[email protected]> wrote:
> Send polyml mailing list submissions to
> [email protected]
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
> or, via email, send a message with subject or body 'help' to
> [email protected]
>
> You can reach the person managing the list at
> [email protected]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of polyml digest..."
>
>
> Today's Topics:
>
> 1. Re: linking polyML modules to C (Phil Clayton)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 21 Jan 2015 20:20:06 +0000
> From: Phil Clayton <[email protected]>
> To: [email protected]
> Subject: Re: [polyml] linking polyML modules to C
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
>
> 19/01/15 12:19, David Matthews wrote:
> > On 19/01/2015 04:34, David Topham wrote:
> >> Thanks David for your response.
> >>
> >> While searching I found this comment you made earlier:
> >>
> >> "The foreign-function interface allows for call-back functions so
> >> there is
> >> the mechanism to produce a C function that when called calls an ML
> >> function."
> >>
> >> in
> >> http://stackoverflow.com/questions/17580386/shared-libraries-in-poly-ml
> >>
> >> Doesn't this indicate a mechanism that allows an SML function to be
> >> called
> >> from C?
> >
> > Yes, but the "main program" still has to be in ML. You can call C
> > library functions and pass an ML function as an argument.
>
> Or the ML functions can be passed via global variables that are
> initialized from the ML side - see attached example. That may be easier
> if there are a large number of ML functions.
>
>
> > Actually, I did wonder whether this could be used as a way of exporting
> > ML functions to create a library that could be called from a C main
> > program and came to the conclusion that it was going to be too
> > complicated. Poly/ML uses libffi to interface with C. libffi can build
> > closures that wrap around ML functions so that these can be passed into
> > C. The format of the closure it constructs differs markedly depending
> > on the particular architecture since different architectures have
> > different calling conventions for C. The closure is a data structure
> > with pointers in it. Exporting it would require turning the pointers
> > into relocations that the linker/loader will understand. libffi simply
> > doesn't provide that information. It's there by implication in the
> > source code but not explicitly.
> >
> > David
> > _______________________________________________
> > polyml mailing list
> > [email protected]
> > http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
> >
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: call_c_test_10.tar.gz
> Type: application/x-gzip
> Size: 1438 bytes
> Desc: not available
> URL: <
> http://lists.inf.ed.ac.uk/pipermail/polyml/attachments/20150121/edcb7e81/attachment-0001.gz
> >
>
> ------------------------------
>
> _______________________________________________
> polyml mailing list
> [email protected]
> http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
>
> End of polyml Digest, Vol 111, Issue 7
> **************************************
>
> --
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
>
>
testlib.tgz
Description: GNU Zip compressed data
_______________________________________________ polyml mailing list [email protected] http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
