[MLton] power pc "port"
Filip Pizlo
pizlo@purdue.edu
Sat, 4 Sep 2004 11:05:47 -0500 (EST)
> > bin/regression: line 213: gmake: command not found
> >
> > The problem here is that Mac OS X doesn't have a 'gmake', although 'make'
> > is the GNU version. Is there a need to make some of the scripts refer to
> > 'gmake' instead of 'make'? Anyway, for now, I'll make them use 'make'
> > just to see what the outcome of the tests is.
>
> It shouldn't really matter. gmake is only used to try to compile mllex,
> mlyacc, and mlprof, and that is only checking the type-checker. So, you
> won't learn anything new there.
Aren't there tests after mllex? The problem is that this error halts the
bin/regression script... so getting around it will let me run the rest of
the regressions. Or are there no others?
> That's probably expected. On a PC we can use the native codegen and a
> compiler built with the native codegen, so there is a decent speedup
> there. Your compiler is built using the C codegen and running on a laptop
> (IIRC), so two hours sounds o.k.
Good to know.
> I would think so, although it may still be worth trying Stephen's
> suggestion.
>
> Without much else to go on, here are a few little things that I would try:
> - see if fixed-int.sml succeeds with just the Int32 test.
> - see if fixed-int.sml succeeds with Int16, Int64, Int8
> - then start trying the non-standard sizes.
Will do both of those things.
> Unfortunately there aren't any other regressions that look at the
> non-standard integer sizes. On the other hand, all the operations are
> just implemented by lifting to the larger standard size, so there isn't
> much that can go wrong.
Right. I have a question, which is probably very naive: why can't I use
print from within basis-library/integer/int.sml? Is there some other
tracing facility (other than hacking the generated C code) that I can
invoke from within the basis?
--
Filip Pizlo
http://bocks.psych.purdue.edu/
pizlo@purdue.edu