I've not had much time the past few weeks to work on partcl, as I've a major work deadline that ended up going long.
But, that's alright, because Matt Diephouse has been fixing quite a few things up; Alberto Simões has picked up some PIR and begun fleshing out all the missing [string] subcommands (Yay!), and we got a commit from Bernhard Schmalhofer enabling us to have a test_like variant for our suite, giving us another passing test!
So, with no commits by me, we've increased our passing rate of the tcl test suite by nearly 100 tests in two days. At this rate,
we'll have a fully functional version of tcl in 307 days. ^_^
Robert Spier posted some preliminary yearly stats to parrot, which show me as the #2 contributor this year (behind Leo), and #3 the year before that (behind leo and dan): Leo and I are the only two on the top 10 two years running. Which might explain why...
We also got a mention by Larry Wall:
Likewise Parrot is targeting Perl as its "first" language, but if you
look at recent history you'd think they were mainly targeting TCL.
And that's fine by us, both officially and unofficially.
Current stats with the converted tcl suite: 5.28%.
This is lower than the last reported percentage, because:
1) I'm not skipping [clock] anymore (7568 tests out of 16210!)
2) we've lost a bit of ground on some tests because of internal changes in the past year (including -> compiler). But, given these reorgs, we seem to be gaining passing tests now faster than we have in the past.
Also, 5.28% is pretty good when I think about trying to figure out how much of Perl6 is working on parrot. At least I have a known test suite to run against.
On the short list coming up are namespaces (Chip? 'allo?), and some developer support for generating builtins using our compiler that should simplify things and allow us to start doing more, more quickly.
Thanks to all the folks that have been working on partcl!
Posted to RT (and mentioned on the internals list) a few smallish projects that could probably be tackled by someone looking to do some PIR work. Within 30 minutes, Klaas-Jan Stol had already started working on it. We now have a working [flush], at least for the most part. Thanks, KJ.
Talked to Donal Fellows on #tcl on freenode this week. We talked briefly about if any of tcl's builtins were implementable in terms of other builtins, which led to his posting at http://wiki.tcl.tk/15051
Having someone actually *implement* these for inclusion in partcl would allow us to reduce the amount of work necessary to pass more of tcl's test suite. (And, of course, for any other tcl implementors that aren't core-tcl).
Wow. Haven't written anything here in a while.
partcl has been compiling (as opposed to interpreting) for some time. Whenever possible, PIR code is generated and then inlined into a single subroutine which is then compiled and executed. If there's a chance the inline'd def has changed since it was compiled (via a call to proc or rename), then we lookup the appropriate sub and call that.
The generated PIR is compiled... unless you pass tcl the --pir option, which dumps the raw PIR: you can compile it in a separate pass and it should JFW.
You can also use -e to specify tcl on the command line:
We are now passing 970 converted Tcl tests. I just committed a bunch of stubbed out builtins for use by the real tcltest suite: the sooner we can run tcltest.tcl in even a limited capacity the better. However, there are two major blockers at the moment.
1) the namespace spec *just* hit the list for discussion. Knowing leo, it'll be implemented before I can write any speculative code against it.
2) Trying to run tcltest.tcl as is now... bus errors parrot. Should be a ticket open soon on this. Appears to be a parrot internal issue.
most of the work lately is going on in the leo-ctx5 branch of parrot.
- everything's converted to the new calling conventions.
- taking advantage of the new CC, we eliminate a lot of boxing and unboxing of values between simple registers and PMCs.
- eliminate "two value return" : before, if we called [error foo], it would return a tuple of (TCL_ERROR, "foo"). After this patch, it throws an exception. This was historically done because of the state of exceptions, but that hasn't been an issue for some time. Not only should this be faster in the non-error case, it's cleaner
We're now passing 100% of the tests (thanks to leo for a recent GC fix.)
We are now back up to 11.94%
We got a patch from Amos Robinson implementing [array get]. We are also soliciting a patch from another IRC user, which would double the number of contributors. Woot!
Matt Diephouse is currently working on [expr] - my efforts to use PGE's p6rules to parse expressions was going very slow, and it's a much more effective use of our time to continue along our current path - Matt's already refactored enough that adding support for nested [commands] in expr required a verrry small patch.
I also committed some doc updates, basic support for [gets], and an implementation of [namespace qualifiers] and [namespace tail] (parts of namespace which don't actually require namespaces.)
Matt just added an implementation of [lset] to partcl - and then noticed that our conversion of the tcl test suite missed a few of the original test scripts. With that fixed, we now have *even more tests* that, of course, we're not passing yet. Except for some of the [lset] tests. ^_^
partcl down to 10.49% of the tcl test modulo [clock].
Just after the 0.2.3 release, we've got some refactoring and cleanup (on top of mdiep's new parser).
Passing a few more tests, improved how we're counting: we're at 14.51% (usual caveats: converted test suite, skip [clock])
added support for [string bytelength].
Literally. Just one. Slow night for partcl. It was even a lame one, calling a builtin with no args.
BTW, a large part of the jump from 12% to 13% was patrick michaud's work on getting PGE's globs to support character classes. Thanks, patrick!
With more error handling, we're up to 13% (minus [clock]) of tcl's test suite.
I spoke on the tcl-core list about a test that I was passing that I hadn't written the builtin for yet - they had split up the error code checking, and the error message handling. Well, having no command generates the same error code as the bad arguments error code. They seem to be aware of the issue, and most of the tests are written in such a way to check both simultaneously, which avoids the false positive.
They did point out that lots of the new tests are in a different format than the old tests; this is probably reducing our pass rate. Yet another reason to move on being able to use tcltest directly; but tcltest uses a lot of the language itself, so it won't be simple.