Improved interactive mode

In real tcl, you can use interactive mode to run commands like a shell; There's now just enough logic in partcl to do this as well.

Most of the infrastructure for this was already in place; just added a minimal version of

• [file executable] - only checks executable status for other, not group or owner.
• [file split] - isn't windows-friendly, nor does it deal with potentially confusing chars like '~'
• [exec] - ignores all of the shell metachars and just invokes parrot's spawnw opcode as is.

$ ~/bird/bin/parrot tcl.pbc

% ls src

binary.c binary.h binary.o class grammar macros.pir mathops.pir ops pmc returncodes.pasm tclsh.pir

% rm src/binary.o

% ls src

binary.c binary.h class grammar macros.pir mathops.pir ops pmc returncodes.pasm tclsh.pir

Most of the heavy lifting is done by init.tcl from the standard library.

Partcl now passing 2,972 tcl spec tests

Thanks to prompting from kbk on irc (#tcl at freenode), I finally fixed the parsing of string.test.

It had been complaining about the \udead escape in that file; That isn't really a valid codepoint, and while Tcl accepts it as if it were, parrot (which uses ICU internally) throws an exception when trying to create a string that contains it. So, (at kbk's suggestion), I settled for now to convert any codepoints in the \udead range to \ufffd. That allowed the test to parse...

... but it then ran out of memory, as several other tests have been doing since I started running the tests again.

I've been working with chromatic to try to provide test cases to show where the memory leaks have been coming from, but I've only been going after things I could spot with valgrind. Today, someone on irc (#parrot at irc.parrot.org) posted a very small sample program that eventually ran out of memory... because the garbage collector apparently wasn't.

The small PIR example allowed chromatic to identify and fix that issue in parrot, and partcl has now reclaimed several files which had been exhausting a 1/2 gig of memory.

Current results, over 67 test files that run to completion:

Total 5145 Passed 2972 Skipped 1352 Failed 821

That's the highest number of attempted & passing tests since I started keeping track. It's an additional 1181 passing since the 8th, when I started running the spec tests again.

SpecTest updates

It's been about 4 and a half months since the last "official" spec test run -- partcl was offline for most of that time.

I've finally caught back up with parrot development, can build against svn-latest, an installed parrot, have added a few minor features.

We've lost several files (See http://code.google.com/p/partcl/wiki/SpecTestStatus). I'm running the tests on a machine with a 0.5G ram limit - previously these were running on a machine with no virtual memory limit, so they'd be able to complete. I've opened a ticket with the parrot developers for the biggest parrot memory leak I was able to find with a "hello word" in partcl (See https://trac.parrot.org/parrot/ticket/732). Hopefully they can get that and some other leaks closed.

So, since a lot has changed (including the hardware) between those last two runs, there's not much to compare directly. I'll try to get more, regular updates going forward.

Edit: Actual Spectest results

NaN support

Now that partcl is passing all tests again, took some time over the weekend to add NaN support.

NaN now parses in expressions, and is represented in bytecode as a TclFloat PMC with a value of NaN; most of the operators and functions now [error] appropriately when presented with NaN as an argument; all the partcl tests for NaN are un-skipped and passing.