[comp.lang.functional] help request on edml installation

grass@unipas.fmi.uni-passau.de (Grass) (07/24/90)

Has anybody successfully ported Edinburgh SML to Apollo (SR 9.7 software) ?

Our problem is the following: starting SML in its raw state from
smlcore.exp.backup (step 3 in the README instructions) crashes immediately
with the message "Memory fault".
Invoking the program explicitly (by typing:
  /fam.src/fam -h 2000 smlcore.exp.backup smlcore.exp
) seems to work, but any simple input (e.g. - 3+2;) crashes with an access
violation in routine "RunState" at line 547.

Please can anybody give us a hint what might be wrong?

---
Wolf-Dieter Tiedemann    please email to:
Universitaet Passau      grass@unipas.fmi.uni-passau.de (Werner Grass)
Innstrasse 33
D-8390 Passau

nick@lfcs.ed.ac.uk (Nick Rothwell) (07/25/90)

In article <1990Jul24.114932.6727@forwiss.uni-passau.de>, grass@unipas (Grass) writes:
>Has anybody successfully ported Edinburgh SML to Apollo (SR 9.7 software) ?

Apollo's are horrible. We spent a week battling with the software when
doing the initial EdML port.

>Our problem is the following: starting SML in its raw state from
>smlcore.exp.backup (step 3 in the README instructions) crashes immediately
>with the message "Memory fault".
>Invoking the program explicitly (by typing:
>  /fam.src/fam -h 2000 smlcore.exp.backup smlcore.exp
>) seems to work, but any simple input (e.g. - 3+2;) crashes with an access
>violation in routine "RunState" at line 547.

My first guess: bugs in the C compiler. I've often had to simplify
expressions in the EdML interpreter to get correct behaviour. The
other thing to check is all the byte-sex flags and so on in the
configuration header file, but since it's getting as far as relocating
the heap and giving you a prompt, I doubt this is wrong.

>Wolf-Dieter Tiedemann

		Nick.
--
Nick Rothwell,	Laboratory for Foundations of Computer Science, Edinburgh.
		nick@lfcs.ed.ac.uk    <Atlantic Ocean>!mcsun!ukc!lfcs!nick
~ ~~ ~~ ~~ ~~ Hey, son, get that DeLorean off the track! And ~~ ~~ ~~ ~~ ~
            what have you done with all my lovely harpsichords?

lbn@iesd.auc.dk (Lars Bo Nielsen) (07/26/90)

In article <5301@castle.ed.ac.uk> nick@lfcs.ed.ac.uk (Nick Rothwell) writes:
>In article <1990Jul24.114932.6727@forwiss.uni-passau.de>, grass@unipas (Grass) writes:
>>Our problem is the following: starting SML in its raw state from
>>smlcore.exp.backup (step 3 in the README instructions) crashes immediately
>>with the message "Memory fault".
>>Invoking the program explicitly (by typing:
>>  /fam.src/fam -h 2000 smlcore.exp.backup smlcore.exp
>>) seems to work, but any simple input (e.g. - 3+2;) crashes with an access
>>violation in routine "RunState" at line 547.
>
>My first guess: bugs in the C compiler. I've often had to simplify
>expressions in the EdML interpreter to get correct behaviour. The
>other thing to check is all the byte-sex flags and so on in the
>configuration header file, but since it's getting as far as relocating
>the heap and giving you a prompt, I doubt this is wrong.
>
>>Wolf-Dieter Tiedemann
>
>  Nick.

I had a similar problem when I ported edml to the Atari ST. I found
the problem was in the macro isatty_() defined in system.h. I was
compiling with Gnu CC. It defines __STDC__ and isatty_() then gets
defined to always return 0.

So what I did in the port to the Atari ST was to place this in the end
of system.h:

	#ifdef atarist
	/* isatty_() was defined to 0 in #ifdef __STDC__. This is bad, as fam 
	   will just exit when an error is encountered (fam thinks that stdin 
	   is a file).
	   We set isatty_(fp) true, if fp is stdin, stdout or stderr. */
	#undef isatty_
	#include <stdio.h>
	#define isatty_(fp) (fileno(fp)==fileno(stdin)      \
			     || fileno(fp)==fileno(stdout)  \
			     || fileno(fp)==fileno(stderr))
	#endif

BTW. If somebody is interested in running edml on an Atari ST let me
know. I could post the a diff file (5K) or the executable (70K).

---
 Lars Bo Nielsen @ Aalborg University - Denmark
 lbn@iesd.auc.dk  -**-  {...}!mcsun!dkuug!auc!iesd!lbn
---