On Thu, Jan 22, 2015 at 10:36 AM, David Topham <[email protected]> wrote:
> 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.
>>
>>
>
_______________________________________________
polyml mailing list
[email protected]
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
