2nd combinator parser example

[Anoq of the Sun]

Stephen Weeks wrote:
> Did you send the wrong file?  I tried to compile with an older MLton,
> but failed due to references to BinIO.
> 
> % mlton sources.cm
> FunctionalIO/srcSML/FunctionalIO.sml:166.33-166.47 Error: unbound tycon BinIO.instream
> FunctionalIO/srcSML/FunctionalIO.sml:167.33-167.45 Error: unbound variable BinIO.openIn
> FunctionalIO/srcSML/FunctionalIO.sml:168.34-168.47 Error: unbound variable BinIO.closeIn
> FunctionalIO/srcSML/FunctionalIO.sml:169.32-169.43 Error: unbound variable BinIO.input
> mlton: compilation aborted: elaborate reported errors

It's because the FunctionalIO functors are instantiated into both a
TextIO based and BinIO based version - as I guess you found out already
:)

Stephen Weeks wrote:
> That's OK.  I was able to make it work by commenting out some stuff.
> I have isolated the bug to one of our SSA optimization passes.  For
> now, you can avoid the bug by compiling with "-drop-pass knownCase",
> which turns off the buggy pass.  I'll let you know when we have a
> fix.

Thanks a lot! I have tried this now. And my converter works now - and it
is able to both read and write text and binary files, even something
which
looks correct when rendered :) So I guess this means that TextIO and
BinIO
are now quite well tested :)

I also have my 3D application up and running with GUI, real-time
RenderMan renderer and using SDL. It works like a charm - both when
compiled with the native and the gcc backends. And it's _much_ faster
to compile with the native x86 backend. And although I haven't done any
benchmarks everything "feels" even faster than before.

In the previous version of MLton that I used, when inline C-code ceased
to be
supported I had to remove the C-macros I used with the gcc backend for
writing
pixels to the framebuffer so that I got the extra overhead of having to
call
3 C-functions to write each pixel - but even then the improved speed of
the
compiler made the total speed faster.

And since this version seems even faster I must say that it's really
good work :)

Some time ago I also reported a bug in the backend which turned out to
be some floating-point errors in the x86 backend. I never got around to
testing it - but it's what I'm using now and it also works perfectly!


Cheers
-- 
http://www.HardcoreProcessing.com