Poly/ML July 2012

polyml@lists.polyml.org

6 participants
9 discussions

Inspecting structures
by ramana.kumar＠gmail.com 27 Jan '16

27 Jan '16

Is there a way to look at the contents (i.e. signature) of a structure without opening it? (I suppose you could just open it then call a lot of PolyML.Compiler.forgetXXX, but that's quite tedious) Also, is it possible to retrieve the long path of an identifier in scope? Something that will, for example, take the rev in scope and say that it came from List. Finally, what about searching for an identifier that would come into scope if you opened some structures?

3 5

[Fwd: Re: [polyml] Building Poly/ML on MacOS X 10.6]
by rda＠lemma-one.com 29 Dec '14

29 Dec '14

I wrote: > I am completely baffled. I thought I hada solved all my problems on > MacOS X > 10.6 and was just tidying up, when I had to recompile a 32 bit > version of > Poly/ML to test a tidied up make file. This failed because > PolyML.Compiler.printTypesWithStructureName no longer exists. The same > problem happened when i rebuild a 64 bit version. What has happened? but it was a false alarm: my make file was wrong for other reasons and the absence of PolyML.Compiler.printTypesWithStructureName was not relevant. No doubt there are good reasons why this variable has been withdrawn. Regards, Rob.

3 6

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

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

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

userGCRatio default value
by Jeremy.Singer＠glasgow.ac.uk 12 Jul '12

12 Jul '12

Hi David, Thanks for your superb progress on heap resizing in the Poly/ML runtime. I am adapting my control theory heap sizer to fit into your new scheme. I notice that you set the default userGCRatio to 1.0/9.0 in heapsizing.cpp: HeapSizeParameters::SetHeapParameters However the comment says that the default target is 10%. Should we change the userGCRatio to 1.0/10.0 ? Cheers, Jeremy The University of Glasgow, charity number SC004401

1 0

BasicXXXFun vs XXXToolsFun
by aleks0＠gmail.com 06 Jul '12

06 Jul '12

This is a question mainly for Lucas. Probably we've been over this before, but I don't remember well. 1. What is included in these two things separately? It seems to me the BasicXXXFun's only define getters, setters, and pretty print. I.e. they are dumb data structures. 2. Why are they needed?

1 1

Storage management update
by David.Matthews＠prolingua.co.uk 05 Jul '12

05 Jul '12

On 05/07/2012 12:03, Gerwin Klein wrote: > Hi David, > > sounds excellent, we'll definitely be trying it out. > > Should we expect the Darwin version to be close to stable as well or should we concentrate on Linux only? > > Cheers, > Gerwin Hi Gerwin, The reason I've concentrated on Linux is simply that I don't have a Mac. I can use the Macs at T?M but provoking them to start paging isn't friendly to other users. It's likely that the current code will work equally well on Mac OS so go ahead and try it. Windows/Cygwin is a somewhat different matter. There's no easy way to detect paging on Windows. The page fault counter that is available actually returns the soft page count and apparently this is what Cygwin returns as the hard page count. I've had to use an undocumented interface to get the paging count in that case and it may overestimate it. I'll just have to see how that works. Regards, David

1 0

CInterface causing poly to crash
by aleks0＠gmail.com 03 Jul '12

03 Jul '12

Any idea why calling symbols from certain shared libraries would cause poly/ML to crash on OS X? Example: > val gtk = load_lib "libgtk-quartz-2.0.dylib"; val gtk = ?: dylib > val gtk_init = call2 (load_sym gtk "gtk_init") (INT,INT) VOID; val gtk_init = fn: int * int -> unit > gtk_init(0,0); [1] 96630 killed rlwrap -z poly This (or rather, the equivalent) code works fine on linux, and "libgtk-quartz-2.0.dylib" will link with C code in OS X with no problems. It seems to only do this for some libraries. For instance, the "difference" example from the poly docs (http://www.polyml.org/docs/CInterface.html) also works fine on OS X.

3 9

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 July 2012