[MLton] upcoming release
Mon, 1 Aug 2005 19:52:27 -0400 (EDT)
> It has been quite a while since our last release, so I would like to
> do a new one. There aren't any huge new features, but we have
> accumulated a number of bugfixes, as well as some small improvements:
> * better exception history
> * libraries: Int1, MLton.CallStack, MLton.Process.create, Word1
> * FFI improvements: support for symbols
Some other small improvments:
* better inclusion/exclusion of code for profiling
* warnExnMatch annotation
* updates of mllex and mlyacc (from SML/NJ)
There is also preliminary support for MLNLFFI, including a MLton specific
mlnlffigen program. I know that it does not work correctly on C-code with
functions accepting or returning structs/unions. (See the discussion
starting at http://mlton.org/pipermail/mlton/2005-January/026653.html )
Though, it is able to access fields of structs/unions.
Also, I haven't tested it on any platforms other than x86-Linux, though I
don't see any difficulties with other platforms. Currently, I believe
that all of our platforms agree on sizes for the basic C-types, though
some do have different alignment requirements for > 64-bit values. To
that end, I think the right way of factoring those dependencies is with
compiler set MLB path variables; see
I'm not pushing for these issues to be resolved before the release, but
it's just an update on a pile of code sitting in the repository. NLFFI
received only mediocre support in the 2005 Survey, and I'm happy enough to
let it go as is. If there are users out there who want/need better
support, we can grease them when they squeak. The question is whether or
not to incorporate it into tools/libraries targets of the top-level
Makefile and include them in a binary release.
> There is also a big improvement on the licensing front, as MLton will
> now be released under a BSD-ish license instead of the GPL. That
> alone is worth a new release in my opinion.
Agreed. Better to release soon with the new license and less features.
> I didn't try out MinGW, but I'd be happy for someone to give it a
> try. As I recall, we're still in the state where there is some
> strangeness in saving the world due to
Due to what? Not that I have a MinGW platform around to try it on.
> The biggest open question in my mind for the release is what to do
> about documentation. This will be our first release post wiki. It
> probably makes sense to include a snapshot of (some fragment of) the
> web site to include with each package in html format. I would like
> input on the following:
> * should we have other formats besides HTML? If so, what, and how
> should we obtain it?
> * should we include the whole website or a fragment? What fragment?
I presume we are still including the man pages, which should be
coordinated with the wiki pages.
I suspect the whole website (excluding the obvious links to Download
attachments and CVS/SVN/mail archives) isn't all that big, even in HTML
format. What I would find more annoying is the wikiness of the HTML
found in /usr/share/mlton/doc. I'd vote to post-process the HTML to
eliminate the wiki action links, though I don't know how hard that will