Cat version 0.7

[Christopher Diggins]

There has been a new version of Cat released into the public domain at
http://www.cat-language.com . This version introduces a lot of bug
fixes, and is undergoing more rigorous testing.

The core functionality of Cat is now all present, I just need to
reintroduce all of the atomic operations (which are dormant in the
code) and do a ton more testing before I can officially declare a 1.0
definitely by Christmas.

Try out the type inference engine, it is neat-o!

- Christopher

[Mike Henley]

Hi. Will Cat be available for Linux? Thanks.

[Christopher Diggins]

Unfortunately not for a while. I am currently swamped with work. The
current implementation is in C#, and Mono (C# on Linux) isn't yet
mature enough to do a straight port. The source code is public, so you
are welcome to port it to Linux yourself.

Cheers,
Christopher

[Sandro Magi]

On 10/2/06, Christopher Diggins <cdig...@gmail.com> wrote:
>
> Unfortunately not for a while. I am currently swamped with work. The
> current implementation is in C#, and Mono (C# on Linux) isn't yet
> mature enough to do a straight port. The source code is public, so you
> are welcome to port it to Linux yourself.
>
> Cheers,
> Christopher

Running mono 1.1.17.1 on AMD64, and gave it a whirl; the source
compiles fine using gmcs, as long as Optimizer.cs is ommitted.

# mv Optimizer.cs Optimizer.cs.unused
# gmcs *.cs

Running the exe:

# mono CatStack.exe

doesn't work. Strangely enough, it chokes on a couple int.Parse()
routines in the code. The integers provided aren't large (just "1" and
"2"), so I'm not sure why this would occur.

The problems occur in Cat.Program.CreateProgram() and
Cat.Scope.LookupProgram(). Once those two are removed, in addition to
the Windows-specific Timer.cs (same as Optimizer.cs above), it
compiles and runs, though of course it's almost assuredly wrong.

Hmm, the following error occurs whenever one of the above two are enabled:

*** glibc detected *** mono: realloc(): invalid next size:
0x0000000000931720 ***

Seems to be performing an invalid length calculation somewhere. Either
a glibc bug, or a mono bug when calling into glibc perhaps.

So, replacing int.Parse() in the above two routines with the following
resolved the issue, though it's hardly the "right thing" to do
long-term:

string s = node.ToString();
switch (s) {
case "1": return new PushIntOp(1);
case "2": return new PushIntOp(2);
default: return new PushIntOp(int.Parse(s));
}

Whether everything runs correctly I don't know, but I don't see any
test failures. :-)

Sandro

[Christopher Diggins]

Thank you very much for rooting this out Sandro! I should be able to
make the next version Mono compliant as a result!

On a related note, I found some rather nasty bugs in the type
inference system which are in the middle of being repaired. I don't
expect another release for at least another week or two, while I
rebuild the type inference algorithms.

Cheers,
Christopher Diggins

[Sandro Magi]

You're welcome. :-)

I don't actually use mono, but it turned out to be surprisingly
straightforward to find the problems:

$ gmcs -debug *.cs
$ mono --profile=cov CatStack.exe

The above provided full stack traces at the appropriate points. You
could also use "--verbose", but that yields *a lot* of information.

Interestingly enough, mono 1.1.16.1 works perfectly out of the box on
Windows. My attempt with 1.1.17.1 was under gentoo linux. In fact,
just tested 1.1.17.1 on Windows and it works perfectly as well, so
it's either a linux thing, or an AMD64/64-bit thing.

Sandro