Poly/ML

polyml@lists.polyml.org

2 participants
711 discussions

5.8.2 Release
by David.Matthews＠prolingua.co.uk 10 May '21

10 May '21

The current master has now been released as 5.8.2. There is a fixes-5.8.2 branch for any bug fixes that are needed. The release notes at https://github.com/polyml/polyml/releases includes a list of the various changes. The major change is the replacement of libffi with the internal FFI compiler. Other changes include the addition of IPv6 structures and PackReal32Big and PackReal32Little structures. The master branch has been stable for a while so there should not be any big surprises but as ever let me know if there are problems. David

2 1

PackReal32
by cannam＠all-day-breakfast.com 27 Apr '21

27 Apr '21

Hello! I find I could do with the PackReal32{Big,Little} structures, 32-bit floats being often more amenable to serialisation and used in some storage formats. Would there be any appetite for adding these? Thanks, Chris

2 7

PolyML and windows
by kostirya＠gmail.com 11 Apr '21

11 Apr '21

Hello. I have questions about PolyML and Windows. Can PolyML run in Windows 32-bit? I see than last version PolyML have binary distribution for 64-bit Windows only. Is it possible to compile PolyML for 32-bit Windows with help Clang? Can I make executable files from PolyML for Windows (with help polyc)? Can I do cross-compiling from UNIX to Windows? Nick.

3 2

Updates in git master including major change to FFI
by David.Matthews＠prolingua.co.uk 11 Mar '21

11 Mar '21

Hi, I've just pushed a collection of changes to master that have been in the pipeline for quite a long time. Some of these are internal changes to the run-time system and some are extensions, such as the addition of IPv6 networking with INet6Sock and Net6HostDB structures. The major change, though, is with the foreign function interface. On X86 platforms libffi is no longer used and the version of it included in the libpolyml directory has been removed. Libffi is still used in the interpreted version but only if the library is installed on the system. Instead the foreign function interface is handled essentially as part of the compiler. The high-level interface in the Foreign structure remains unchanged but the buildCallN functions now actually compile interface functions. This results in foreign function calls being substantially faster than with libffi; at least 10 times faster for trivial calls on the X86/64. The cost is, of course, some extra work when buildCallN is called, meaning that it is essential that these functions are only used at the top level. The reason for the speed-up is that the interface has to place the arguments in the correct registers for the ABI and the rules for placing arguments can be quite complicated, particular on the X86/64 on Unix. Libffi computes the placement on every call whereas the compiler can do this once and build code that moves the arguments into the right registers and returns the result. For backwards compatibility buildClosureN functions have been retained but these are wrappers around new buildCallback functions. The buildCallback functions differ in two respects. Closures created with buildCallback are garbage-collected which means that if they are used to register callbacks with a C library it may be necessary to keep a reference in ML. There is a touchClosure function that should be called when the callback is no longer needed. For compatibility closures created with buildClosure are retained in a global list to avoid garbage collection. The other difference is that the buildCallback functions have a slightly different type from buildClosure and that reflects the underlying implementation. For example, val buildCallback1: 'a conversion * 'b conversion -> ('a -> 'b) -> ('a -> 'b) closure The first application builds the interface code that handle the conversion between the ML and C ABIs. The second application applies this to an ML function to build a closure value that can be passed to C. This second application builds a small additional piece of code that simply loads the address of the ML function into a register and jumps to the interface code. What this means is that while the first application should always be done at the top level it is possible to embed an application of this to a particular ML function inside ML code. There is still an overhead compared with creating a closure in ML and it is better if possible to do the application at the top level but the cost is significantly less than if the whole buildCallback function were called within a function. As always please give this a try and let me know if there are problems. Regards, David

4 22

the design of Poly/ML
by buday.gergely.istvan＠uni-mate.hu 17 Feb '21

17 Feb '21

Hi, is there an academic description of the design of Poly/ML, regarding compilation strategies, intermediate languages etc? Cheers - Gergely

1 0

Announcement: Giraffe Library
by phil.clayton＠veonix.com 17 Feb '21

17 Feb '21

[Apologies if you receive multiple copies this message] Dear Poly/ML users, I would like to announce the first public release of Giraffe Library, an SML interface to libraries that support GObject Introspection, such as GTK. The latest release, 1.0.0-alpha.11, provides GTK 3 and supporting libraries, enabling applications with GUIs to be written entirely in SML. Applications without GUIs may also find some features useful, for example, in GLib, sockets using UDP multicast and various checksums, which are not available in the current Basis Library. For more information, download, documentation and examples, please see: http://giraffelibrary.org/ Regards, Phil

2 2

How to use the interactive debugger?
by morten＠lysgaard.no 06 Nov '20

06 Nov '20

Hi. I have tried so evaluate the available debuggers for standard ML and as far as I can see the only one available is the poly/ml interactive debugger. It is documented here: https://www.polyml.org/documentation/Tutorials/Debugging.html I have tried to run the example in the linked documentation but I am not getting any sensible feedback. The shell seems to hang when I run the line > addList 0 [(1,2), (3, 4)]; and no debug prompt shows up. I have tried to enter the example line by line into the interactive shell as well as putting it in a .sml file and running it with poly --use my_file.sml The same thing happens in both. The shell hangs and no debug prompt shows up. I am running the standard poly/ml from the Ubuntu-provided .deb package available on Ubuntu 20.04 Do you have any suggestions to what I might be doing wrong? Regards, Morten

2 2

Can't build trunk (cea4c79c) on macOS 10.15
by binghe.lisp＠gmail.com 29 Oct '20

29 Oct '20

Hi, when I try to build latest polyml trunk (master) on macOS 10.15, I got the following errors: Making all in libpolyml /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -O3 -DMACOSX -DGIT_VERSION=\"v5.8.1-286-gcea4c79c\" -Wall -DMODULEDIR=\"/usr/local/lib/polyml/modules\" -DMACOSX -MT x86assembly_gas64.lo -MD -MP -MF .deps/x86assembly_gas64.Tpo -c -o x86assembly_gas64.lo x86assembly_gas64.S libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -O3 -DMACOSX -DGIT_VERSION=\"v5.8.1-286-gcea4c79c\" -Wall -DMODULEDIR=\"/usr/local/lib/polyml/modules\" -DMACOSX -MT x86assembly_gas64.lo -MD -MP -MF .deps/x86assembly_gas64.Tpo -c x86assembly_gas64.S -fno-common -DPIC -o .libs/x86assembly_gas64.o x86assembly_gas64.S:223:5: error: unsupported symbol modifier in branch relocation call X86TrapHandler at plt ^ make[2]: *** [x86assembly_gas64.lo] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 My last (successful) build was: Poly/ML 5.8.2 Testing (Git version v5.8.1-68-gb4786634). GCC is from Xcode 12.1: $ gcc -v Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/4.2.1 Apple clang version 12.0.0 (clang-1200.0.32.21) Target: x86_64-apple-darwin19.6.0 Thread model: posix InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin Please let me know if any further information is needed. Regards, Chun Tian

2 2

Install to users home directory
by dtopham＠gmail.com 20 Oct '20

20 Oct '20

I know it is most efficient to install software system wide so all users share same code. But I have a situation where I want to install only to my home directory. i.e. It is Linux system where I don't have sudo privilege. Is that possible? I am building from source, so perhaps ./configure --prefix=$HOME make make install Or does polyml have too many dependencies on other system libraries to make that impractical?

4 6

Install to users home directory
by dtopham＠gmail.com 20 Oct '20

20 Oct '20

Thanks Phil, I found I needed to set LD_LIBRARY_PATH as well as PATH to $HOME to use interpreter. I really appreciate the helpful information from this community! On Tue, Oct 20, 2020 at 4:00 AM <polyml-request at inf.ed.ac.uk> wrote: > Send polyml mailing list submissions to > polyml at inf.ed.ac.uk > > 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 > polyml-request at inf.ed.ac.uk > > You can reach the person managing the list at > polyml-owner at inf.ed.ac.uk > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of polyml digest..." > > > Today's Topics: > > 1. Re: Install to users home directory (Phil Clayton) > 2. Re: polyml install to Alpine Linux (David Matthews) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 20 Oct 2020 10:12:37 +0100 > From: Phil Clayton <phil.clayton at veonix.com> > To: polyml at inf.ed.ac.uk > Subject: Re: [polyml] Install to users home directory > Message-ID: <090b6bb7-106a-eb9e-0732-2b00a050ebee at veonix.com> > Content-Type: text/plain; charset=utf-8; format=flowed > > On 20/10/20 05:40, David Topham wrote: > > I know it is most efficient to install software system wide so all users > > share same code. But I have a situation where I want to install only to > > my home directory. i.e. It is Linux system where I don't have sudo > > privilege. > > Is that possible? > > I am building from source, so perhaps > > ./configure ?--prefix=$HOME > > make > > make install > > > > Or does polyml have too many dependencies on other system libraries to > > make that impractical? > > You can specify any prefix to install to - this does not affect how > dependencies are found. However, depending on your choice of prefix, > you may need to manually add <prefix>/bin to PATH. Depending on your > Linux distribution, it would probably be more idiomatic to do a per-user > install to > $HOME/.local > to avoid cluttering the home directory. Also, if you have Poly/ML > installed system-wide via the package manager, you would need to make > sure that <prefix>/bin occurs in the path before the system bin > directory, to ensure your user version is found first. > > There are some instructions previously posted here: > http://lists.inf.ed.ac.uk/pipermail/polyml/2017-July/002038.html > which also show how to disable the package manager version of Poly/ML on > Fedora. > > Phil > > > ------------------------------ > > Message: 2 > Date: Tue, 20 Oct 2020 11:56:55 +0100 > From: David Matthews <David.Matthews at prolingua.co.uk> > To: polyml at inf.ed.ac.uk > Subject: Re: [polyml] polyml install to Alpine Linux > Message-ID: <5bca1bc6-063e-b199-65f1-31e259038413 at prolingua.co.uk> > Content-Type: text/plain; charset=utf-8; format=flowed > > On 19/10/2020 21:08, David Matthews wrote: > >> Yes, using .data.rel.ro., i.e. relocatable read-only data. > > > > Thanks, Jess.? That seems to work, at least on SELinux and Alpine. > > OpenBSD seems to still want it to be writeable. > > I've now changed the ELF exporter to write the data to .data.rel.ro. > The byte code interpreted version (--disable-native-codegeneration) now > builds without a problem on Alpine Linux and on SELinux with hardening > turned on. That isn't a complete solution because it doesn't deal with > native code but it does show that if code could be handled everything > else will work. > > I see this primarily as future-proofing Poly/ML. It's not unlikely that > a future release of, say Mac OS X, might outlaw TEXTRELs. > > David > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > polyml mailing list > polyml at inf.ed.ac.uk > http://lists.inf.ed.ac.uk/mailman/listinfo/polyml > > ------------------------------ > > End of polyml Digest, Vol 168, Issue 9 > ************************************** > > -- > The University of Edinburgh is a charitable body, registered in > Scotland, with registration number SC005336. > >

3 2

← Newer
1
2
3
4
5
6
7
8
9
...
72
Older →

Jump to page:

2026

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