Did a lot of low hanging fruit - builtins that we had already implemented, but needed slightly different error messages, or that we hadn't yet written a test for, or were otherwise borked.
Also committed some udpates to the script that generates our tcl tests, making it more verbose so one might figure out what's going on while it's running.
Oddly enough, we're passing a test here or there for builtins we haven't implemented. That can't be right. =-)
Matt is going to implement [lindex], which would give us some more easy passes.
I've pinged the list about getting PGE to support character classes, which will help any failing [string match] tests.
Current passing percentage of tcl's tests (not including [clock]): 12.00%
Whee. partcl now passes along unknown commands to the shell as its big brother does:
$ make tclsh
(cd
(cd
% echo "whee"
whee
This done as I've committed a per6 grammar for [expr], which when run through the demo for PGE seems to work just fine: problem is being able to get at this data programmatically afterward. it's a bit convoluted, hopefully I can build on what autrijus has done in PGE.hs
cd dynclasses && make
you get runtime/parrot/dynext/tclgroup.so (or something like it.) (If you don't, there's a bug, and please report it
to the perl6 internals list. )
Now, at the top level parrot directory, you can create foo.imc containing:
.sub main
loadlib $P0, "tclgroup" # Load combined tcl lib
$I0 = find_type "TclInt" # Find ID for a TclInt *
$P0 = new $I0 # Instantiate
$P0 = "asdf" # Assign
print $P0
print "\n"
$S0 = typeof $P0 # Get the type description.
print $S0
print "\n"
end
.end
This snippet prints out
asdf
TclString
Note that the type of the PMC has
shimmered (morphed, if you prefer) to the appropriate data type. I need to do
more work to nail down the appropriate reactions for each kind of shimmer for
Tcl.
Next steps:
puts '[string range [list 1 2 3] 0 2]'
Actually generates
'1 2'
which will have been shimmered from a TclList (returned by [list]) to a TclString
[*] - these steps are, of course, unnecessary with built in types. They're
necessary here because when parrot started, we didn't know anything about Tcl.
We have to load the pmcs, and then, because the pmc types were created at
runtime, we have to use a runtime check to get our class ID. (As opposed to
the builtin type String, which you can, thanks to runtime/parrot/include/pmctypes.pasm, just create with $P0 = new String)
I'm working on implementing Tcl (http://www.tcl.tk/) from scratch on top of parrot (http://www.parrotcode.org/). The code so far is available as part of the parrot distribution.
I've spoken briefly with some of the folks on the Tcl Core team, who suggested that this version of Tcl be called "ParTcl"
Right now, I've got a big chunk of the interpreter working. Next two big steps are overhauling [expr], and swapping out the generic (and Perl) PMCs for dynamically loaded Tcl PMCs. Now that Parrot 0.1.1 is released, I should be able to switch over to the dynamic PMCs without a problem.
Once those are done, I can add in/flesh out all the tcl builtins that rely on lists and arrays. (Or, if you speak perl, arrays and hashes. Mostly).
Volunteers welcome. ^_^