Poly/ML

polyml@lists.polyml.org

2 participants
711 discussions

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

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

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