Poly/ML

polyml@lists.polyml.org

2 participants
698 discussions

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

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

rlwrap filter for Poly/ML
by aleks0＠gmail.com 01 Jun '12

01 Jun '12

Hi all, I've written a very basic rlwrap filter for using Poly/ML from the command line. Currently, it does tab-completion for globals and expands two macros that are useful for reading off info about signatures and structures: ?s FOO ====> signature SIG = FOO; ?S Foo ====> structure Str = Foo; It's available here: https://github.com/akissinger/sublime-polyml/blob/master/poly_filter.pl Obviously there are many ways this could be enhanced. If you have good ideas, let me know, or fork the repo yourself on github. Best, Aleks Kissinger

1 0

Poly/ML SVN: assertion failure when attempting to dump heap
by aleks0＠gmail.com 01 Jun '12

01 Jun '12

I'm attempting to build a large poly/ML program (Quantomatic) which makes use of many load/save states (incremental compiling via Lucas Dixon's PolyML.Project). Works fine in fixes-54, but in trunk I get this error: poly: statistics.cpp:241: void Statistics::decSize(int, size_t): Assertion `s <= statMemory->psSizes[which]' failed. Aborted (core dumped) Seems it only fails after compiling a large amount of code at once.

2 1

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