Poly/ML

polyml@lists.polyml.org

704 discussions

End of life for native code Sparc and PPC
by David.Matthews＠prolingua.co.uk 05 Sep '12

05 Sep '12

I'm in the final stages of preparing Poly/ML 5.5 for release and making the pre-built compilers for the various architectures. I have decided not to include support for native code on Sparc and PPC. I don't expect anyone will still be using these architectures for real work and the interpreted version should continue to work. David

1 0

Storage management update
by David.Matthews＠prolingua.co.uk 30 Aug '12

30 Aug '12

The version of Poly/ML in SVN is the result of over a year's work on the storage management. I'm currently testing the final phase of that and I'd be interested in feedback. The garbage collector has been almost completely rewritten and is now parallelised. The minor GC is completely different and uses a copying collector rather than the mark-sweep scheme used for major collections. The final phase is the heap sizing strategy. From the user's point of view the main differences are the options that control the heap management. The old --heap, --mutable and --immutable arguments have been removed. In their place are a new set of arguments: --minheap, --maxheap, --gcpercent and --gcthreads. I have retained the -H argument as a synonym for --minheap. The storage management adjusts the heap size within the range --minheap (default 1/8th of the physical memory) to --maxheap (default 100% of the physical memory) to keep the garbage collection overhead close to --gcpercent (default 10%). If it detects paging it may reduce the heap size to try to avoid paging since the effect of paging is to slow the whole execution down quite substantially. In that case the GC overhead will rise above the target. If necessary it may run an extra "sharing" pass in the GC to reduce the heap size. This is a sort of cut-down version of PolyML.shareCommonData. It adds a considerable overhead to the GC so is only run when absolutely necessary but reducing the live data size can allow a program to proceed when it is bumping up against the --maxheap limit or the paging limit. The overall aim is to try to adjust the heap size for optimum performance with a wide range of programs on a wide range of memory sizes. The larger the heap available the less frequent the GC needs to run so the faster the program runs. This holds up to the point that paging sets in. The available memory, though, depends on what else is running on the machine so in general the heap starts off small and grows while watching for paging. If you know how much memory you have available you may get better performance by setting --minheap and --maxheap. The --gcthreads option sets the number of threads to be used for the parallel GC. The default, 0, uses as many threads as there are processors (cores) on the machine. Setting this to 1 makes the GC single-threaded. It's probably best left at the default unless you want to run other programs at the same time on other cores. I have tested the latest version with Isabelle, primarily on 64-bit Linux. The paging avoidance seems to work well and even large examples will run in 2Gbytes. I haven't tested it much on other platforms. I did notice occasional cases of poly being killed by the over-commit manager. This was fixed by increasing the amount of swap space available. I'd be interested in feedback, particularly if there are pathological cases where the performance is significantly worse. David

2 3

From SML/NJ to Poly/ML
by Gael.Mulat＠mathworks.fr 24 Aug '12

24 Aug '12

Hi, I'm developing in SML for years (so with a big number of lines of code, different projects, in-house libraries, ...). The code compiles well in MLton (for production) and in SML/NJ (for dev and debug). I am considering using Poly/ML to benefit of its debugger. I wonder what will be the effort in order to port the code to Poly/ML. I have already found that: - The organization of the code has to be adapted: sources.cm and mlb files have to be rewritten in some equivalent for polyml - Some libraries will be missing (from my first attempt, it seems that smlnj basis is bigger than what is provided in polyml) - Interfaces with C will have to be adapted (among others: does it exist an easy way to have nlffi in polyml?) - Some grammar constructs may not be accepted by polyml. For example: case x of (0 | 1) => true | _ => false; is not accepted in polyml Does someone have such an experience? Are there documents somewhere that give hints? Are there other big tasks to anticipate for this port? Thanks, Gael Mulat.

9 20

Word31 from SMLNJ
by Gael.Mulat＠mathworks.fr 23 Aug '12

23 Aug '12

Hi, Trying to port my code from SML/NJ to Poly/ML, I'm stuck with the Word31 structure. In SML/NJ, Word = Word31 and WORD signature defines operators <<, >> and ~>> like this: val op << : word * Word31.word -> word This means that Word31 is the right operand for this operator, even in word32 and in Word64 structures. My code base is built on this signature (would be hard to change it everywhere; and would no more be OK for SML/NJ). Does someone have a trick to port this to Poly/ML ? Thanks, Gael.

4 6

CInterface and CType union
by pabourdi＠laas.fr 23 Aug '12

23 Aug '12

Hi, i'm looking for an easy way to map CType union. By easy way i mean, either a Conversion or a make_union/break_union. Having a look at the source code of CInterface, i see that conversion are managed by a union signature so i guess there's a way. But is there a solution that already exists ? Regards, Pierre-Alain

3 7

Emacs mode
by Gael.Mulat＠mathworks.fr 17 Aug '12

17 Aug '12

Hi, I'm new to Poly/ML. I'd like to start using it, but I still have to work with SML/NJ. I use the well-known sml-mode-4.0. What should I use also to be able to work both with SML/NJ and Poly/ML? I've found this link: http://www.cs.cmu.edu/~fp/courses/98-linear/lib/emacs/sml-poly-ml.el Allows to start. But I'm not able to go back to SML/NJ after using Poly/ML. And 'next-error seems to be missing. Would someone have advices there? Thanks, Gael.

2 1

Finalizers not called on termination
by phil.clayton＠lineone.net 16 Aug '12

16 Aug '12

According to profiling messages that I'm generating, when a stand-alone executable terminates, any remaining finalizers (added with CInterface.setFinal) are not run. Consequently, resources that should be freed may not be. I think I would probably expect the semantics of finalizers to be such that they are run at some point before the program terminates. Does that sound sensible? This can be worked around easily, for example by creating a variant of PolyML.export that adds a final PolyML.fullGC to the exported function (for both normal and exception paths). However, there is the question of whether, on termination, a full GC is needed or does a call to each finalizer suffice. If it is the latter, the work-around with an explicit GC does more work than required. By comparison, for stand-alone executables created with MLton, any remaining finalizers (added with MLton.Finalizable.addFinalizer) are called prior to termination - possibly due to a final GC, I don't know. Phil

3 4

FFI conversions for larger C types
by phil.clayton＠lineone.net 16 Aug '12

16 Aug '12

My bindings for GLib/GTK+ etc. involve some functions with 64 bit parameter/return values, using the C types gint64/guint64 - GLib's portable 64 bit integers. On Linux i386, these types are defined using 'signed/unsigned long long int'. I believe the C library stdint.h defines portable types too, e.g. int64_t. (C99 provides 'long long int' that is defined to be at least 64 bits.) At present, I am working on GNU/Linux x86_64 where 'long' is 64 bits, so the conversion LONG can be used to pass 64 bit values over the FFI. However, I can't see a way to pass 64 bit values on platforms where 'long' is not 64 bits. Is there a way? I have no immediate need, but I'm thinking that support for e.g. Linux i386 would be desirable at some point. Conversions such as LONGLONG/ULONGLONG could provide the FFI capability on i386, where 'long long' is 64 bits. However, SML applications would still need to choose between LONG and LONGLONG if 'long long' is larger. So conversions such as INT64/UINT64 for exactly 64 bits on any platform may be a better approach for a portable 64 bit C type. If I have a moment, I'll have a look at foreign.cpp to see what is involved. Phil

2 3

Lifespan of pointers to callback functions passed via C FFI
by phil.clayton＠lineone.net 13 Aug '12

13 Aug '12

I have been assuming that the pointer back to an ML function passed to a foreign C function will still be valid after the C function has returned, so the callback can occur sometime later (from a different C function). Is that a valid assumption? I made this assumption based on some tests in which one such callback pointer remained valid for the life of the application. It would be nice to know I wasn't just being (un)lucky! Phil

2 5

FFI conversion for unsigned long int
by phil.clayton＠lineone.net 08 Aug '12

08 Aug '12

The conversion INT has an unsigned counterpart UINT but there is no corresponding unsigned version of LONG. In order to use LONG to pass unsigned values, it is necessary to adjust the value on the SML side (which is an int) so that the range checking of LONG does not reject valid values. For example, see my definition of ULONG below. However, I can't see way to define ULONG portably - the SML side adjustment needs to know the size of an unsigned long. Is this available somewhere? Is there some clever way to define a portable ULONG in terms of LONG? Phil local val m = case PolyML.architecture () of "X86_64" => IntInf.pow (2, 64) | "I386" => IntInf.pow (2, 32) | _ => raise Fail "unknown architecture" val half_m = m div 2 fun fromLong x = (* Assume x in range of (signed) long int. *) if x < 0 then x + m else x fun toLong x = (* * Ensure result outside range of (signed) long int if and only * if x is outside the range of unsigned long int by swapping * regions [~m/2, 0) and [m/2, m). *) if half_m <= x andalso x < m then x - m else if ~ half_m <= x andalso x < 0 then x + m else x in val ULONG = CInterface.mapConversion (fromLong, toLong) CInterface.LONG end (* Test ULONG *) local open CInterface in fun printULong n = call2 (get_sym "libc.so.6" "printf") (STRING, ULONG) VOID ("n = %lX\n", n) end val pow_2_32 = IntInf.pow (2, 32); val pow_2_64 = IntInf.pow (2, 64); printULong ~1; (* should fail *) printULong 0; (* always ok *) printULong (pow_2_32 - 1); (* always ok *) printULong pow_2_32; (* should fail when long is 32 bits *) printULong (pow_2_64 - 1); (* ok when long is at least 64 bits *) printULong pow_2_64; (* should fail when long is 64 bits *)

1 0

← Newer
1
...
33
34
35
36
37
38
39
...
71
Older →

Jump to page:

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