Poly/ML December 2017

polyml@lists.polyml.org

8 participants
9 discussions

linking polyML modules to C
by dtopham＠gmail.com 09 Nov '18

09 Nov '18

After more experimenting with GUI in SML, I would like to now try calling an SML module from a C program. That way, the GUI could be built using traditional imperative techniques and the program logic could be written in SML. I see how to call a C function from SML, but and not so clear on how to call an SML function from a C program. I want to build code using polyc and then link with a C main program, but could anyone show me a simple example of calling that function and getting its return value? for example, I have defined: fun sum i n f = if i > n then 0.0 else f i + sum (i+1) n f ; fun int2real x = real x ; in linkToC.sml and #include <iostream> #include <fstream> std::ofstream ofs; int main() { std::cout << sum(1,10,int2real) << std::endl; ofs.open("table.dat"); for(int i = 0; i < 20; i++) ofs << i << '\t' << sum(1,i,int2real) << std::endl; } in linkToC.cpp Looking in the polyc script, I thought adding the -c option might allow me to build the object code which I could then link to the sml functions, but it complains about not having a main. Could someone point me in the right direction? Thanks, Dave On Mon, Dec 15, 2014 at 11:44 AM, David Topham <dtopham at gmail.com> wrote: > David, Thank you so much! I really appreciate your help with this. Your > sample below builds fine with polyc on my system (PolyML 5.5.2). I am using > a minimal Linux distribution named TinyCore ( > http://distro.ibiblio.org/tinycorelinux/) which comes with OpenMotif > 2.3.3 It runs in a virtual machine within another computer only taking up > a few hundred MBs! > > I am going to use it to help my students explore Discrete Math next > semester (this textbook uses SML for that purpose: > http://cs.wheaton.edu/~tvandrun/dmfp/). > > I also found a reasonably current project using PolyML and Motif here: > http://www.lemma-one.com/ProofPower/index/ > > ...however it was built on PolyML 4 and has not yet been ported to the > newer version (e.g. depends on PolyML.commit which no longer seems to be > supported). > > Happy Holidays to everyone in the PolyML community! > > -David Topham > > >> Re: GUI Interface (David Matthews) >> >> I've experimented with building a stand-alone executable with Motif and >> succeeded in getting it to work for me using polyc. (It required >> building Poly/ML with --with-x). I took the example from >> http://www.polyml.org/docs/Motif.html and wrapped it up in a function. >> I did find a problem, though. It looks as though the function has to >> suspend itself with something like Posix.Process.pause otherwise nothing >> happens. I seem to recall that the Motif stuff is handled on a separate >> thread to allow the REPL to continue to accept commands. With a >> stand-alone application there isn't a REPL so without the "pause" it >> terminates immediately. >> >> David >> >> open XWindows ; >> open Motif ; >> >> fun main() = >> let >> val shell = >> XtAppInitialise "" "xed" "Editor" [] [XmNwidth 400, XmNheight 400] ; >> >> val main = XmCreateMainWindow shell "main" [] ; >> >> val bar = XmCreateMenuBar main "bar" [] ; >> >> val fileMenu = XmCreateCascadeButton bar "file" [XmNlabelString "File"] ; >> val editMenu = XmCreateCascadeButton bar "edit" [XmNlabelString "Edit"] ; >> val viewMenu = XmCreateCascadeButton bar "view" [XmNlabelString "View"] ; >> val helpMenu = XmCreateCascadeButton bar "help" [XmNlabelString "Help"] ; >> >> val command = XmCreateText main "command" [XmNeditMode >> XmSINGLE_LINE_EDIT] ; >> >> val hscroll = XmCreateScrollBar main "hscroll" [XmNorientation >> XmHORIZONTAL] ; >> val vscroll = XmCreateScrollBar main "vscroll" [XmNorientation >> XmVERTICAL] ; >> >> val work = XmCreateDrawingArea main "work" [] ; >> in >> >> XtManageChildren [fileMenu, editMenu, viewMenu, helpMenu] ; >> XtManageChildren [bar, command, hscroll, vscroll, work] ; >> >> XmMainWindowSetAreas main bar command hscroll vscroll work ; >> >> XtManageChild main ; >> XtRealizeWidget shell; >> Posix.Process.pause() >> end; >> >> >> ------------------------------ >> >> _______________________________________________ >> polyml mailing list >> polyml at inf.ed.ac.uk >> http://lists.inf.ed.ac.uk/mailman/listinfo/polyml >> >> End of polyml Digest, Vol 110, Issue 12 >> *************************************** >> >> -- >> The University of Edinburgh is a charitable body, registered in >> Scotland, with registration number SC005336. >> >>

2 3

polyc and libraries
by David.Matthews＠prolingua.co.uk 15 Jan '18

15 Jan '18

The polyc script has been developed mainly to simplify the linking of an exported ML function and in particular to try to capture the libraries that need to be included. I've been having another look at this because of an issue that was reported a while back. Up till now the linking step has included all the libraries that were needed in order to link libpolyml itself. That was extracted by the configure script. It turns out that this is right if libpolyml is compiled as a static library but has a problem if libpolyml is a dynamic library. Object files exported by PolyML.export make reference to external symbols from libpolyml but do not directly reference anything else. If libpolyml is a dynamic library it exports these symbols but all the other dependencies are satisfied by loading the appropriate libraries dynamically. The issue was reported in the Fedora distribution but may also affect other distributions that package up Poly/ML and have separate packages for libraries (e.g. libgmp and libffi) and development packages. They were building libpolyml as a shared library but because polyc included the dependencies of libpolyml itself polyc was including -lgmp -lffi in the link step. This meant that it needed the development versions of these libraries even though they were not actually used. I've now modified the configure script so that polyc only includes the dependent libraries if libpolyml has been built with shared libraries disabled and at the same time changed the default so that it builds a shared library unless --disable-shared is given. Hopefully this hasn't broken anything but I'd appreciate any reports of problems. David

4 11

More portable poly compilation
by makarius＠sketis.net 24 Dec '17

24 Dec '17

Dear experts on building and linking C++ applications, according to the blog "Creating portable Linux binaries" http://insanecoding.blogspot.de/2012/07/creating-portable-linux-binaries.ht… the following options could make the poly executable more portable accross different Linux versions: CFLAGS="-static-libgcc -static-libstdc++ -Wl,-Bstatic -lgmp -Wl,-Bdynamic" On the surface this works fine on x86_64-linux (Ubuntu 16.04 LTS), but there is a remaining dependency on libpolyml.so, which itself depends on dynamic gcc and stdc++ libraries. Including "-lpolyml" next to "-lgmp" above does not work, probably because these options also apply to the build process of libpolyml itself. How can I make libpolyml a static part of poly? Alternatively, how can I make libgcc and libstdc++ a static part of libpolyml? Makarius

3 2

C++ standard in use
by matthew.fernandez＠gmail.com 23 Dec '17

23 Dec '17

Hi David et al, While experimenting with some of the recent PolyML commits, I realised the build system doesn?t seem to set any particular C++ standard. I guess this results in the compiler default (e.g. GNU++14 in the latest GCC [0]). Is this intentional? Relatedly, coming up on 2018 it seems like it would be reasonable to require a compiler with C++11 support. I?m not sure how backwards compatible PolyML needs to be these days, but e.g. support for Windows 95/98 has been dropped. I notice some comments in interpreter.cpp that imply whatever is in Debian stable is a lower bound. Moving to C++11 would allow some parts of the code base to be replaced with their C++11 equivalents, reducing the maintenance burden. Some candidates: - Bitmap -> std::vector<bool> - NORETURNFN -> [[noreturn]] - PCondVar -> std::condition_variable - PLock -> std::mutex - PLocker -> std::lock_guard Perhaps this will provide a performance boost as well, but I wouldn?t necessarily count on it. I?d be curious to hear if anyone has strong feelings about this or if any PolyML devs out there are living with a pre-C++11 compiler. Thanks, Matt [0]: https://gcc.gnu.org/onlinedocs/gcc/Standards.html#C_002b_002b-Language

3 6

FFI conversions that are portable across Poly/ML versions
by phil.clayton＠veonix.com 22 Dec '17

22 Dec '17

I am trying to define LargeInt.int conversions for C integer types in terms of those supplied in Foreign in a way that will work with both Poly/ML 5.6 or 5.7. This requires that e.g. - Foreign.cUint64 is used for Poly/ML = 5.6 but - Foreign.cUint64Large is used for Poly/ML >= 5.7 I am thinking of achieving this by having separate SML files for different Poly/ML versions and using the right one as follows: let val version = PolyML.rtsVersion () in PolyML.use ( if version >= 570 then "src-5.7.sml" else if version = 560 then "src-5.6.sml" else raise Fail "unsupported Poly/ML version" ) end Is this a future-proof way to choose based on Poly/ML version? Another option might be to copy the implementation of these conversions from Foreign.sml but that may not be possible - for example I couldn't see how to get the flag bigEndian in an application. Is there a better way altogether with some compiler trickery? Phil

2 1

Retiring CInterface?
by David.Matthews＠prolingua.co.uk 18 Dec '17

18 Dec '17

Now that the Foreign structure has been around for a while I was wondering whether it was time to remove CInterface and the related structures. Is there any specific need to keep it? David

3 3

More robust shell script: allow spaces in directory names.
by Makarius 15 Dec '17

15 Dec '17

diff --git a/polyc.in b/polyc.in index adaa586..e460305 100755 --- a/polyc.in +++ b/polyc.in @@ -1,14 +1,14 @@ #! /bin/sh -prefix=@prefix@ -exec_prefix=@exec_prefix@ -BINDIR=@bindir@ -LINK=@CXX@ -LIBDIR=@libdir@ +prefix="@prefix@" +exec_prefix="@exec_prefix@" +BINDIR="@bindir@" +LINK="@CXX@" +LIBDIR="@libdir@" LIBS="@dependentlibs@" CFLAGS="@polyc_CFLAGS@" DEFAULT_COMPILER="${BINDIR}/poly" -COMPILER=${DEFAULT_COMPILER} +COMPILER="${DEFAULT_COMPILER}" # Extra options for Windows. config.status sets these conditionals to either "" or "#". @@ -25,27 +25,27 @@ COMPILER=${DEFAULT_COMPILER} # Msys passes the Windows TEMP in temp (lower case) # On other systems allow TMPDIR to override /tmp. - at NATIVE_WINDOWS_TRUE@TEMPORARYDIR=${temp:-/tmp} - at NATIVE_WINDOWS_FALSE@TEMPORARYDIR=${TMPDIR:-/tmp} + at NATIVE_WINDOWS_TRUE@TEMPORARYDIR="${temp:-/tmp}" + at NATIVE_WINDOWS_FALSE@TEMPORARYDIR="${TMPDIR:-/tmp}" # Extra options for Mac OS X @MACOSLDOPTS_TRUE at EXTRALDFLAGS="-Wl,-no_pie" -TMPOBJFILE=${TEMPORARYDIR}/polyobj.$$.$SUFFIX +TMPOBJFILE="${TEMPORARYDIR}/polyobj.$$.$SUFFIX" trap 'rm -f "$TMPOBJFILE"' 0 compile() { - echo "val () = use (List.nth(CommandLine.arguments(), 2)); val () = PolyML.export(List.nth(CommandLine.arguments(), 3), main);" | ${COMPILER} -q --error-exit "$1" "$2" + echo "val () = use (List.nth(CommandLine.arguments(), 2)); val () = PolyML.export(List.nth(CommandLine.arguments(), 3), main);" | "${COMPILER}" -q --error-exit "$1" "$2" } link() { if [ X"$2" = "X" ] then - ${LINK} ${EXTRALDFLAGS} ${CFLAGS} "$1" -L${LIBDIR} -Wl,-rpath,${LIBDIR} -lpolymain -lpolyml ${LIBS} + "${LINK}" ${EXTRALDFLAGS} ${CFLAGS} "$1" "-L${LIBDIR}" "-Wl,-rpath,${LIBDIR}" -lpolymain -lpolyml ${LIBS} else - ${LINK} ${EXTRALDFLAGS} ${CFLAGS} "$1" -o "$2" -L${LIBDIR} -Wl,-rpath,${LIBDIR} -lpolymain -lpolyml ${LIBS} + "${LINK}" ${EXTRALDFLAGS} ${CFLAGS} "$1" -o "$2" "-L${LIBDIR}" "-Wl,-rpath,${LIBDIR}" -lpolymain -lpolyml ${LIBS} fi } @@ -112,8 +112,8 @@ done case "$compileonly" in yes) if [ "x$outputfile" = "x" ]; then - basename=${sourcefile##*/} - outputfile=${basename%.*}.o + basename="${sourcefile##*/}" + outputfile="${basename%.*}.o" fi compile "$sourcefile" "$outputfile" ;;

1 0

Build error: Exception- InternalError: Too many passes raised while compiling
by kostirya＠gmail.com 15 Dec '17

15 Dec '17

Hello. Poly/ML broken on FreeBSD i386 (clang version 3.8.0). ./polyimport polytemp.txt -I . < ./exportPoly.sml Use: basis/build.sml ... Use: basis/FinalPolyML.sml Exception- InternalError: Too many passes raised while compiling The error appeared due to commit 3886935542311d70fec94a3bc5da8b302792a79b (Tue Nov 28 17:45:49 2017) Turn byte moves of four or eight bytes (on X86/64) into moves of single words provided the alignment is correct. This is primarily to handle moves between SysWord.word and volatileRef. Nick.

2 1

PolyML sources [InternalError: asGenReg raised while compiling]
by David.Matthews＠prolingua.co.uk 01 Dec '17

01 Dec '17

Hi Bernard, Thanks for sending me that. I've committed a fix to Git master (6af4a34) which seems to fix it. This is a fix to the compiler so will need make compiler to rebuild the compiler. It's very simple so may be a candidate for the fixes branch once it's been tested a bit more widely. Regards, David On 30/11/2017 14:11, Bernard Berthomieu wrote: > Hello David, > > Many thanks for you help. > > I could isolate the part of my code in which the failure is raised. > To reproduce the problem, unpack the archive attached then type: > > ??? cd src_bb > ??? poly < build.ML > > > With release aa3b02654b38ad3faadc60c5960702cba6be87df or older, > all files in build.ML are loaded successfully. > > With current 5.7.1, compiling the last file fails and it prints: > > ??? Exception- InternalError: asGenReg raised while compiling > > ??? Exception- Fail "Exception- InternalError: asGenReg raised while > compiling" > ??? ?? raised > > > The last file simply applies two functors defined in the previous files. > > Regards, > ? Bernard. >

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Poly/ML December 2017