With recent updates (just in the past week), partcl (tcl on parrot) can now use the tcltest library that comes with tcl 8.5.4 [1]
For some time, we have been limping along with partcl's hand-rolled Test::More analog on a slightly processed version of tcl's *.test files.
The current version of make spectest is actually processing the raw .test files from the CVS repository.[2]
While tcltest doesn't generate TAP, being able to run the spec test using the native testing tool is a big step forward for partcl. Here's a sample:
$ ./tclsh t_tcl/llength.test
llength.test: Total 6 Passed 6 Skipped 0 Failed 0
I've checked a file into the repository to track the progress of the suite.
https://svn.perl.org/viewvc/parrot/trunk/languages/tcl/docs/spectest-progress.csv?view=markup
"date","revision","files","test","pass","fail","skip"
"2008-09-25 00:00",31396,38,1481,743,290,448
This is analogous to the file rakudo (Perl 6 on parrot) is using.
Hopefully a few more small tweaks will let us run more of the other 99 test files: we were passing many of those tests when they were lightly converted, so the number of passes should hopefully go up quickly soon as more functionality required by tcltest is implemented.
[1] Not exactly a pristine copy: one of the core features of tcltest (where should I send my output) requires some relatively advanced functionality - tcl's tests are not designed like perl6's to allow new implementations to ease into things. I've tacked on 2 replacement subs in our copy of tcltest that for now always say "just print to stdout/stderr". Still, that's a two oneline proc bodys compared to the original 3375 lines of tcltest.tcl
Maybe ask them if they would consider adopting TAP? That would be nice in a lot of different ways. The test suite would fit in with the rest of the Parrot languages, yet be applicable to both Tcl and partcl without conversions. They would get to use the TAP infrastructure that’s already built or just getting off the ground (Smolder, Ovid’s test history project, etc.). They could give us feedback about use cases they have that TAP does not currently cover (if any) so we would have more data for the TAP standardisation effort. They could go on to write their own TAP infrastructure and Perl stuff would then slot right into their bits (a win for them if they need to put bits of Perl into mainly-Tcl systems).