On Thu, Apr 04, 2002 at 06:56:07PM -0500, Nathan Froyd wrote:
> On Thu, 2002-04-04 at 11:54, Christophe Rhodes wrote:
> > Work on the runtime is far from over; not counting the warnings from
> > pointer<->integer games, an x86/linux build gives 6 warnings and a
> > sparc/solaris build 13... most of these are probably trivially fixable
> > -- I haven't started looking into them yet.
> Are there only 13 on sparc/solaris? I thought there were more than that
> when I watched the build go...
Oh, there are plenty more here; most of them, though, are known
"harmless" integer and pointer confusion (making pointer from integer
without cast, comparing two pointers of incompatible types, etc, etc,
etc); they should be fixed, of course, but they're a class of warning of
themselves, as the rest are not.
> > Slightly worryingly, I have been unable to compile a solaris core from
> > the solaris binaries produced from cross-compiling from x86; I'm
> > slightly inclined to blame the hardware I'm working with (in that errors
> > occur in different places) and I don't believe that any of the changes
> > in the merged patch could have made the situation worse; nevertheless, I
> > would welcome independent confirmation or denial.
> I just compiled 0.7.2.6 from solaris binaries; the host was compiled
> from an x86 0.7.2.4 build. This was on Solaris 2.8 (I can try 2.6) with
> gcc 3.0.
> Do you mean "can't compile solaris core" in the sense that the build
> doesn't work or that the tests don't pass? The core I just made doesn't
> past tests (I think it horks on irrat.pure.lisp, but it appears to be
> fine otherwise.
In the sense that the build doesn't work, but not in any repeatable
manner -- I'm more inclined to blame the hardware, since I'm causing my
machine to thrash quite significantly.
As to irrat.pure.lisp: I'm not convinced of the utility of the tests in
there for the most part, actually; there are problems with the tests in
that they assume the weirdo 80-bit x86 precision. They do seem to have
caught some interestingness: pi can differ in the last significant digit
between architectures (and I don't know why -- it may depend on whether
the core was cross-compiled from a different architecture or not), but I
would have thought that tests for equality ± epsilon might be more
useful than exact string comparison.
Certainly I get tired that at every time having a heartstop, thinking
"what have I broken now?", before realizing that the tests failed in
irrat.pure.lisp, and deleting it again :-) This will probably motivate
me to do something about it...
Jesus College, Cambridge, CB5 8BL +44 1223 510 299
http://www-jcsu.jesus.cam.ac.uk/~csr21/ (defun pling-dollar
(str schar arg) (first (last +))) (make-dispatch-macro-character #\! t)
(set-dispatch-macro-character #\! #\$ #'pling-dollar)