Release 0.4 - Known Problems

The following is collected email of reported problems with release 0.4 of the Mercury distribution. Included, where possible, are patches.

On SunOS 4 (and any other systems which don't have `mkfifo'), you need to make a shell script version of `mkfifo' which calls `mknod', and put it in your $PATH. The following shell script should do the trick:

	if [ $# -ne 1 ]; then
		echo "Usage: `basename $0` filename" 1>&2
		exit 1
	exec mknod "$1" p

On Linux, if you use `mc' directly (rather than via `mmake'), you need use the option ` --cflags "-fno-builtin -fno-omit-frame-pointer" '.

On Irix, if you use `mc' directly (rather than via `mmake'), and specify a grade that includes "jump" or "fast", you need use the option ` --cflags "-non_shared -mno-abicalls" '.

The interface to NU-Prolog / SICStus Prolog is broken: to fix it, apply this patch to library/ before installing.

For SICStus Prolog, you also need to make sure that somewhere in your path is a file `sp' which is a link to $SP_PATH/Emulator/spdump.

For SICStus Prolog on x86 CPUs (and other architectures for which SICStus Prolog does not have a native-code generator), you must replace all occurrences of `fastcode' with `compactcode' in scripts/, scripts/, and library/Mmake.

SICStus Prolog version 3 has some incompatibilities with earlier versions. These incompatibilities means that Mercury 0.4 will not work with SICStus Prolog version 3. If you want to use SICStus version 3, a patch contributed by Peter Szeredi is available here, but we don't have SICStus version 3, so we haven't been able to test this patch.

The `jump' and `fast' grades don't work. (This should not cause any problems - `asm_jump' and `asm_fast' work fine. The auto-configuration script won't select `jump' or `fast' grades as the default.)

There is a bug in the implementation of higher-order predicates; the work-around is to always use explicit lambda closures (e.g. instead of `solutions(foo(X),List)' use `solutions(lambda([X::in, Y::out] is det, foo(X, Y)), List)').

There is another bug in the implementation of higher-order predicates which means that the compiler sometimes generates incorrect code for semidet higher-order preds. The work-around for this one is to not use semidet higher-order preds.

If you attempt to use the unimplemented predicates io__read_anything/3, io__write_anything/3, type_to_term/3, or term_to_type/3, you will get a crash rather than a "sorry, not implemented" message.

This list is too long - we will release a new version which fixes these problems sometime in the near future.

Comments? Mail, or see our contact page.
Last update was 1997/04/22 01:22:27 by