Poly/ML July 2009

polyml@lists.polyml.org

4 participants
5 discussions

FFI and C++?
by robertr＠rftp.com 05 Aug '09

05 Aug '09

Hi, Is there an update in the works for the Poly FFI? I may not be looking in the correct place, but I am seeing what may be a needed feature: let's say I am happy with Poly managing the lifetimes of "volatile" C-data values, and handling the freeing of malloced memory. What about C++? One would need some way to [at least] arrange for a delete operation (so as to invoke any needed destructor(s))... and this is assuming we wrap C++ objects created with new[] inside a "simple" new-created object - otherwise we need to be able to issue a delete[]. This could still potentially be handled by a C-style interface, if we could optionally associate a C "finalize" function with a volatile - this function could be called by the Poly memory reclamation when the volatile is truly unreachable; upon its return, Poly can go ahead and complete the free operation. This issue comes up both in the general case of talking to extra-Poly code (where we may have some control of the interface presented), but also in the case of talking to an existing library that is C++ rather than C based... in this case, we really need to allow the foreign code base to perform its own lifetime-management related operations. Like I said, this functionality may be available already... but if isn't, what are others' thoughts on the subject? Is this facility needed? Robert

2 13

Performance problems with saving and loading state
by David.Matthews＠prolingua.co.uk 29 Jul '09

29 Jul '09

Philip Clayton wrote: > I have rebuilt ProofPower using this file and the times to start up are > back to normal. I've set a build going to test the 150MB databases but > won't know the outcome until tomorrow. This is looking good so far... Good. I've committed that change. It looks like it has solved this problem without the difficulty of overestimating the size that I was trying to avoid. With the experimental IDE we build up very long chains of saved states, with the Poly/ML compiler which is a comparatively small project the chain is over 90 long, so overestimating the size can result in running out of memory. David

2 1

Performance problems with saving and loading state
by rda＠lemma-one.com 27 Jul '09

27 Jul '09

We have performance problems with ProofPower when compiled with Poly/ML using the latest sources as compared with version 5.2.1. The main problem is with loading a large state. In some of QinetiQ's tests, it now takes nearly 40 minutes to load a state (occupying about 150Mb on disc) that previously took about 20 seconds. Unfortunately, my attempts to create simple examples of this type problem do not exhibit much difference between 5.2.1 and the latest sources. I wondered if anyone else has had similar problems or has any suggestions about how to isolate the problem. I believe the problem is quite old. It apparently predates the move from CVS to SVN. Regards, Rob.

2 3

Syntax of fun bindings and constructor application
by David.Matthews＠prolingua.co.uk 03 Jul '09

03 Jul '09

I've just been updating the type checking error messages for fun declarations and as part of the process I've been looking at the parsing. The syntax of a fun binding is similar to a pattern in many ways and the overlap between them is such that the easiest way to parse them is to treat them just like patterns. The effect of this, though, is that Poly/ML has allowed forms that are not strictly allowed by ML97. This is mainly in the use of parentheses, accepting them in some cases where they are not allowed and not requiring them where they should be used, but also allowing type constraints in some places where they are not allowed. I've now fixed this so that these extensions are no longer allowed but this may mean that programs that previously compiled no longer will. Examples of incorrect syntax previously accepted are: fun (f x) y = x+y; infix ++; fun SOME x ++ SOME y = x = y; val (SOME) x = SOME 1; I'm mentioning this because this could affect long standing code. I found an example of the second case, where an infixed function was applied to a construction that wasn't parenthesised, in the C-interface code of Poly/ML. David.

1 0

New Scintilla plugin for Standard ML
by robertr＠rftp.com 03 Jul '09

03 Jul '09

I mentioned here recently that I was working on updating my Scintilla plugin for OCaml to also support Standard ML - and it is now "done"(*). Since this coincided fortuitously (and barely) with the release cycle for Scintilla/SciTE 1.79, the new version has been included in the just-released editing package. If you go to http://www.scintilla.org and look for binaries, you will be pointed to http://www.scintilla.org/SciTEDownload.html. Here you can get compiled versions of the full Scintilla package (supporting a lot of programming languages) as part of either Windows or GTK+/Linux builds of the SciTE editor. One thing which might be missed were one to jump right in and start editing SML with the SciTE editor + the aforementioned OCaml/SML plugin (called a "lexer" in Scintilla parlance): only ONE language at a time can be automagically associated with a given source file extension (file type). So, as things come out of the box, OCaml has .ml and .mli files, while SML has .sml files. This may be adjusted two ways: by selecting a specific language from the SciTE Language menu, a default binding may be overridden. Or, by adjusting configuration files, SML can "take over" .ml file support for itself. These issues are discussed in the caml.properties config file in the main SciTE directory - note that you probably don't want to count on .ml and .ML being distinguishable. Perhaps I am missing something, but it looks like Poly is all about an interactive read-eval-print loop sort of dev environment, as opposed to [also] supporting a non-interactive edit-compile-run model... this makes the efforts underway to have a richer interactive experience even more understandable. ;) As I have already built OCaml bindings for Scintilla, creating SML bindings should be doable... but would this really be usable, given that Scintilla is Windows or GTK+, while Poly seems to be more Windows or X (including Motif here) oriented. Hmmm. I bring this up, because I think Scintilla can be useful as the "editing and output window" part of an IDE. (*) - actually, while "done" as much as software projects ever are, some suggestions for updating the 3 [arbitrary] groups of keywords would be welcomed (again, see the caml.properties config file). ;) Robert

2 2

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 2009