code development

[Stephen Weeks]

> What is the current development strategy you are using now for
> compiling and testing MLton sources?  I've started working on
> common-subexp, but am way out of the loop on the best way of
> compiling and testing it.

My file structure looks like

% pwd
/home/sweeks/mlton
% ls -1
bin/
include/
lib/
src/
src-stable/
...

I have one directory that I'm currently working in (src), and other directories
(src-stable, src-ssa, ...) for other working copies that I have
checked out.

Develop with SML/NJ 110.36.  

Within a working directory, I use an emacs with all my SML source
files and an *Inferior SML*, which I start in the src/mlton directory.
I have an emacs keybinding that saves all my SML buffers calls
CM.make() in the *Inferior SML* buffer.  I have another keybinding
that takes me to each type error in sequence.  Once I have the program
debugged, I do a 'make nj-mlton', which creates
~/mlton/lib/mlton.x86-linux.  Then, I can run ~/mlton/bin/mlton to use
the development version.  If I have a particular bug I am working on,
I usually have a test case in /tmp/z.sml and a /tmp/Makefile that
calls the compiler with the appropriate flags.  If I am doing general
testing, I run all the regressions with mlton/src/bin/regression.  If
the regressions pass (you should do a run with a stable compiler to
get used to the known failures), then I delete the mlton.x86-linux
and use an old stable version of mlton to do a self-compile.  If
that passes, then I do
 1. regressions
 2. self-compile
 3. regressions
 4. self-compile
The results of steps 2 and 4 should be identical. Once all those tests
pass, I do a checkin.

The only other thing that I can think of offhand is that I have a
remote machine that I use for testing that is faster than my machine
and has more memory free, so I have some scripts that tar up the
essential parts of my mlton directory, move them to the remote
machine, untar them, and run regressions or a self-compile. 

Also, I slightly lied about the above in one respect.  Since the
SML/NJ compiled G0 is 5x slower than a mlton compiled G0, if I am
fairly confident, I often build a mlton G0 before running any
regressions, just so the regressions are faster.

But, if I want to do any tracing using the -trace command-line switch,
then I use an NJ-G0 because tracing is turned off in a mlton G0.

Also, other switches that you will find useful are the -keep,
-keep-pass, and -diag switches, which save the output of selected
passes and turn on diagnostic output.  

All these expert options are briefly documented with "mlton -v -z".