Poly/ML

polyml@lists.polyml.org

695 discussions

Type inference issue with phantom types
by phil.clayton＠lineone.net 06 Sep '12

06 Sep '12

I have been making use of phantom types (for encoding a single-inheritance class hierarchy) and have encountered a case where code accepted by MLton does not type check with Poly/ML. After investigating, it appears that MLton, Poly/ML and SML/NJ all take different views on what is a valid program! Attached are two small examples with a slight difference where type checking accepts/rejects as follows: test-1.sml test-2.sml MLton 20100608 accept accept Poly/ML 5.4, latest reject accept SML/NJ 110.73 reject reject I don't know which of the above is consistent with the Definition yet. (I would be very glad if test-1 is a legal program though!) Phil

4 12

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

← Newer
1
...
32
33
34
35
36
37
38
...
70
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