coke's Journal coke's use Perl Journal en-us use Perl; is Copyright 1998-2006, Chris Nandor. Stories, comments, journals, and other submissions posted on use Perl; are Copyright their respective owners. 2012-01-25T02:19:55+00:00 pudge Technology hourly 1 1970-01-01T00:00+00:00 coke's Journal For future partcl updates, see Regards. coke 2008-09-29T15:34:11+00:00 journal partcl running with tcltest.tcl <p>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] </p><p> 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. </p><p> The current version of make spectest is actually processing the raw<nobr> <wbr></nobr>.test files from the CVS repository.[2] </p><p> 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:</p><p> <code> $<nobr> <wbr></nobr>./tclsh t_tcl/llength.test<br> llength.test: Total 6 Passed 6 Skipped 0 Failed 0 </code> </p><p> I've checked a file into the repository to track the progress of the suite.<br> <tt><nobr>s<wbr></nobr> v?view=markup<br> </tt> </p><p> <code>"date","revision","files","test","pass","fail","skip"<br> "2008-09-25 00:00",31396,38,1481,743,290,448 </code> </p><p> This is analogous to the file rakudo (Perl 6 on parrot) is using. </p><p> 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. </p><p> <i>[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</i></p> coke 2008-09-25T06:22:28+00:00 journal Parrot 0.4.17 Released <p>On behalf of the Parrot team, I'm proud to announce Parrot 0.4.17<br>"Two for Finching." Parrot ( is a virtual machine aimed<br>at running all dynamic languages.</p><p>Parrot 0.4.17 can be obtained via CPAN (soon), or follow the<br>download instructions at<br>For those who would like to develop on Parrot, or help develop<br>Parrot itself, we recommend using Subversion or SVK on the<br>source code repository to get the latest and best Parrot code.</p><p>Parrot 0.4.17 News:<br>- Implementation<br> &nbsp; + Bug fixes (including Coverity IDs 20, 22, 30, 119-122, 124-126, 129-131)<br> &nbsp; &nbsp; &nbsp; Also various GC, memory, and segfault issues<br> &nbsp; + Fix &amp; reenable CGP core<br> &nbsp; + Parrot's -r flag now works again (compile to and execute bytecode)<br> &nbsp; + Updates to pmc2c &amp; PIR syntaxes<br> &nbsp; + Fix Complex PMC<br> &nbsp; + Minor performance improvements, especially in PGE<br>- Documentation<br> &nbsp; + PDD02 "Vtables" - superceded by PDD17<br> &nbsp; + PDD06 "PASM" - minor updates<br> &nbsp; + PDD17 "PMC" - add VTABLE syntax, update core PMC struct, restore UnionVal<br> &nbsp; + PDD19 "PIR" - early review started<br> &nbsp; + PDD21 "Namespaces" - cleanup<br> &nbsp; + PDD24 "Events" - draft approved<br> &nbsp; + PDD25 "Concurrency" - minor updates<br> &nbsp; + PDD26 "AST" - draft version begun<br> &nbsp; + PIR tutorials updated<br>- Languages/Compilers<br> &nbsp; + Make scheme work with the current calling conventions, other major work.<br> &nbsp; + Updates to m4, lua, compilers/pirc, languages/PIR, dotnet, tcl<br>- Miscellaneous:<br> &nbsp; + make -j functional again<br> &nbsp; + Code cleanup (refactoring, optimizations)</p><p>Thanks to all our contributors for making this possible, and our<br>sponsors for supporting this project.</p><p>Enjoy!</p> coke 2007-10-17T06:15:58+00:00 journal Parrot 0.4.10 Released <p>See the <a href="">Parrot 0.4.10 release announcement</a>.</p> coke 2007-03-21T11:10:08+00:00 journal partcl update <p>We're able to run quite a few more tests now with some judicious skips of certain tests. We're still not running tcltest.tcl natively (though we're getting close!); So, this is with our Test::More like 'test' proc, which doesn't parse all the variants of tcl's test proc. (We've recently modified it to run tests with simple constraint specs: we run it regardless of whether the constraint would have said don't bother.)</p><p>446 subtests skipped.<br>Failed 41/65 test scripts, 33.85% okay. 4131/7608 subtests failed, 45.70% okay.</p><p>That's 3031 tests passing, out of 20683 in a recent cvs checkout of tcl's test suite. That's 14.65%</p> coke 2006-11-28T14:48:20+00:00 journal tcl update <p>Recent tcl on parrot work:</p><p>1) update [expr] to use the parrot compiler tools, PGE, TGE - this allows us to write the expr grammar using perl6 rules instead of handrolled PIR.</p><p>2) create a test::more like set of procedures which allow us to run the tcl tests with only very minor modifications. This lets us drop the huge (and incomplete) test conversions to a perl based suite. partcl tests are mostly converted to using this like test::more - we provide a 'test' sub that is implemented in terms of the test::more subs - this lets us generate the normal (to us) TAP output, even on the tclsh tests.</p><p>The conversion means we're running larger tcl files (in the form of tests) than we have to date. This is exposing issues in both partcl and parrot that are spurring development on both fronts.</p><p>Because the tests are now being written in tcl, we can easily run them with the latest tclsh to verify we're testing for the right things: this helped find a <a href=";aid=1534628&amp;group_id=10894&amp;atid=110894">bug in tcl8.5a4.</a></p><p>Here's the result of all the tcl tests we can currently parse ``natively'' (in quotes because we're still not using tcltest.tcl):</p><p><code><br>Failed 34/38 test scripts, 10.53% okay. 568/937 subtests failed, 39.38% okay.<br></code></p><p>So, passing 369 tests using the current method. We'd be shown passing more, but some test files die because of their size (chokes the compiler), or for other reasons after some passes. Any test that dies prematurely isn't counted in this list.</p> coke 2006-08-07T06:19:03+00:00 journal Tcl update <p>tcl on parrot is still not dead.</p><p>Matt Diephouse is effectively taking over partcl, though I anticipate I will help out with some PGE/TGE commits; I just committed some changes to the tcl-test harness so we can once again run the transformed test suite. (still hovering at just under 6%)</p> coke 2006-06-09T12:33:45+00:00 journal templates too verbose... <p>If you look at the last posting, you'll see the template is very verbose and optimized for the build tool. Changed it to be more like the actual usage mentioned on the man page: so, exit's manpage says:</p><p> &nbsp; &nbsp; exit ?returnCode?</p><p>And our exit template now says:</p><p> &nbsp; &nbsp; usage =&gt; "?returnCode:int=0?",</p><p>Which automatically generates code to treat it as an optional argument, generates the appropriate usage message if the user miscalls, expects the argument to be an integer (and carps properly if it's not), and sets the default value to 0.</p> coke 2006-01-09T14:25:52+00:00 journal better partcl compilation framework <p>partcl is still failing a few tests, but things are looking up. Fixed a bug that was bringing down our tcl test suite numbers, added regression tests to tcl to track them. Also did some expr cleanup (octal, ~ operator, more tests.)</p><p>In the past few days, added a build tool that lets us declare inline'd tcl builtins (originally, everything was interpreted. Now several commands have a version that generates PIR), rather than hand rolling them. this lets you declare the argument types (and whether they are optional, default values, etc.) and have them compiled automatically, and just define the small bit of PIR code that you need to process the arguments. It also automatically generates errors for bad calls, etc.</p><p>By moving all this setup code into the build script, we should lower the bar for implementing the builtins. as of this writing, six builtins have been converted to the new template style. Here's a sample:</p><p>{<br> &nbsp; &nbsp; command =&gt; 'join',<br> &nbsp; &nbsp; args =&gt;<br> &nbsp; &nbsp; [<br> &nbsp; &nbsp; &nbsp; &nbsp; {<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; name =&gt; 'list',<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; type =&gt; 'list',<br> &nbsp; &nbsp; &nbsp; &nbsp; },<br> &nbsp; &nbsp; &nbsp; &nbsp; {<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; name =&gt; 'joinString',<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; type =&gt; 'string',<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; optional =&gt; 1,<br> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; default =&gt; " ",<br> &nbsp; &nbsp; &nbsp; &nbsp; }<br> &nbsp; &nbsp; ],<br> &nbsp; &nbsp; code =&gt; &lt;&lt;'END_PIR',</p><p>$S{register_joinString} = $P{register_joinString}<br>$S{register_num} = join $S{register_joinString}, $P{register_list}<br>$P{register_num} = new<nobr> <wbr></nobr>.TclString<br>$P{register_num} = $S{register_num}<br>END_PIR<br>}</p><p>Most of the declaration is pulled right from the manpage, as far as arguments go. The actual PIR code that does the work is actually a bit longer than it needs to be, due to boxing. (The compiler currently assumes that the result of the compilation is always a PMC - being able to specify a specific register as opposed to a PMC will let us reduce the amount of code even further.)</p> coke 2006-01-06T17:25:45+00:00 journal Tcl Version <p>Committed a patch last night changing some tests to expect error messages that are nowhere to seen in tcl 8.4, which prompted some confusion.</p><p>Just added a comment to partcl's README which will hopefully explain:</p><p>Note that we are targetting Tcl's cvs-latest, which is going to be 8.5. This allows us to test against what will likely be state of the art by the time we approach completion. As we get closer to that day, we'll probably settle down and code against the most recent version (which hopefully won't be 9.x by then).</p><p>This has the disadvantage that for side by side testing, you'll need to build your own tcl. Partcl users don't need to worry about this, and even most partcl developers can simply code against the test suite.</p> coke 2005-12-30T14:09:23+00:00 journal The 5.28% Solution <p>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.</p><p>But, that's alright, because Matt Diephouse has been fixing quite a few things up; Alberto Sim&#245;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!</p><p>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,<br>we'll have a fully functional version of tcl in 307 days. ^_^</p><p>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...</p><p>We also got a <a href=";q=larry+wall+tcl+parrot+group%3Aperl.perl6.language&amp;rnum=1&amp;hl=en#52f23649ce9e7804">mention by Larry Wall</a>:</p><blockquote><div><p>Likewise Parrot is targeting Perl as its "first" language, but if you<br>look at recent history you'd think they were mainly targeting TCL.<br>And that's fine by us, both officially and unofficially.</p></div></blockquote><p>Current stats with the converted tcl suite: 5.28%.</p><p>This is lower than the last reported percentage, because:</p><p>1) I'm not skipping [clock] anymore (7568 tests out of 16210!)<br>2) we've lost a bit of ground on some tests because of internal changes in the past year (including -&gt; compiler). But, given these reorgs, we seem to be gaining passing tests now faster than we have in the past.</p><p>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.</p><p>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.</p><p>Thanks to all the folks that have been working on partcl!</p> coke 2005-12-30T01:07:46+00:00 journal flushing. <p>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.</p><p>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</p><p>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).</p> coke 2005-12-03T21:41:52+00:00 journal tcl me elmo <p>Wow. Haven't written anything here in a while.</p><p>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.</p><p>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.</p><p>You can also use -e to specify tcl on the command line:<nobr> <wbr></nobr>../../parrot tcl.pbc -e='puts {hello world}'</p><p>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.</p><p>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.</p><p>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.</p> coke 2005-12-02T07:02:49+00:00 journal current partcl status <p>most of the work lately is going on in the leo-ctx5 branch of parrot.</p><p>- everything's converted to the new calling conventions.</p><p>- taking advantage of the new CC, we eliminate a lot of boxing and unboxing of values between simple registers and PMCs.</p><p>- 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</p><p>We're now passing 100% of the tests (thanks to leo for a recent GC fix.)</p> coke 2005-09-16T01:06:33+00:00 journal more [partcl] submitters! <p>We are now back up to 11.94%</p><p>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!</p><p>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.</p><p>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.)</p> coke 2005-08-18T17:49:59+00:00 journal 1 step forward, 2 steps back <p>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. <tt>^_^</tt></p><p>partcl down to 10.49% of the tcl test modulo [clock].</p> coke 2005-08-07T16:39:27+00:00 journal partcl odds and ends <p>Just after the 0.2.3 release, we've got some refactoring and cleanup (on top of mdiep's new parser).</p><p>Passing a few more tests, improved how we're counting: we're at 14.51% (usual caveats: converted test suite, skip [clock])</p><p>added support for [string bytelength].</p> coke 2005-08-06T03:09:53+00:00 journal partcl now passes all tests on win32! Thanks to Jonathan Worthington, all tests now pass for partcl on win32! coke 2005-07-29T19:18:47+00:00 journal cross one more test off! <p>Literally. Just one. Slow night for partcl. It was even a lame one, calling a builtin with no args.</p><p>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!</p> coke 2005-07-08T03:31:11+00:00 journal 13% solution... <p>With more error handling, we're up to 13% (minus [clock]) of tcl's test suite.</p><p>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.</p><p>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.</p> coke 2005-07-07T13:50:43+00:00 journal more test cleanups for partcl <p>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.</p><p>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.</p><p>Oddly enough, we're passing a test here or there for builtins we haven't implemented. That can't be right. =-)</p><p>Matt is going to implement [lindex], which would give us some more easy passes.</p><p>I've pinged the list about getting PGE to support character classes, which will help any failing [string match] tests.</p><p>Current passing percentage of tcl's tests (not including [clock]): 12.00%</p> coke 2005-07-06T04:03:31+00:00 journal tcl-interactive, avoiding the real work. <p>Whee. partcl now passes along unknown commands to the shell as its big brother does:</p><p>$ make tclsh<br>(cd<nobr> <wbr></nobr>../../ &amp;&amp;<nobr> <wbr></nobr>./parrot --output=languages/tcl/tcl.pbc languages/tcl/tcl.imc)<br>(cd<nobr> <wbr></nobr>../../ &amp;&amp;<nobr> <wbr></nobr>./parrot --gc-debug languages/tcl/tcl.pbc)<br>% echo "whee"<br>whee</p><p>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</p> coke 2005-07-05T05:02:27+00:00 journal YAPC::NA aftermath It was nice actually *meeting* some of the people that I've been interacting with since beginning working on/targetting parrot several years ago. <br> <br> It's too bad that <a href=""> Matt Diephouse</a> couldn't go - I suspect we'd have been able to advance partcl quite a bit. <br> <br> Matt's currently working on a patch to improve list to string shimmering, which should raise our test percentage quite a bit. I'm working on updating [expr] handling. When I started writing this, parrot was in its infancy - the only real way to write a parser was to do it externally (and I didn't want to introduce any external dependencies), or by rolling your own in PIR or C: so I rolled my own parser. <br> <br> With <a href="">Patrick Michaud's</a> latest work on PGE, however, it looks like I'll be able to rewrite these bits into a Perl 6 grammar. I'm in progress on this, though after 3 days in Toronto, I have some real work to get done first. <tt>^_^</tt>. coke 2005-06-30T16:24:41+00:00 journal Inching towards parrot 0.1.2 Looks like we're getting very close to <a href="">another point release of parrot</a>, which will include <a href="">Dan's string patch</a>, as well as <a href="">Leo's new generational GC system</a>. <i>use guest/guest as an RT login</i> <br> <br> The other items that were scheduled for the 0.1.2 release are mainly design-related TODOs which are getting bumped until at least the next point release, until we get Dan back -- Dan's been offlist for a few months now. <a href="/~jesse">Jesse</a> is working on getting some information out of him regarding the <a href="">TPF grant</a>, hopefully that'll generate some movement soon. coke 2005-03-03T20:10:46+00:00 journal ParTcl: Dynamic Tcl PMCs A few months ago, I put together a cargo cult version of basic PMC types for Tcl based on their Perl counterparts. I ripped out all reference to PerlUndef, and made sure the shimmering (automatic conversion of datatypes) was working between the various types. <br> <br> After posting this to the list, I was told that this was good, but these PMCs needed to be dynamic. That is, rather than being types that are shipped with the basic parrot core, they should be available as a dynamically loadable library. Makes sense. (Note: This also means that <b>Perl's</b> PMCs should also be moved to a dynamic library, especially now that parrot has its own, non-Perl base types.). <br> <br> Things sat for a bit after that. Thanks to Mattia Barbon who provided a way to group related pmcs together into a single library to load (Before this, interrelated pmcs were uncompilable, as each depended on another that hadn't been compiled yet.). Also thanks to Steve Fink, who got <b>that</b> working under OS X, which is my primary development environment. <br> <br> Now, if you<blockquote><div><p> <tt>cd dynclasses &amp;&amp; make</tt></p></div> </blockquote><p> you get <code>runtime/parrot/dynext/</code> (or something like it.) (If you don't, there's a bug, and please report it to the perl6 internals list. ) <br> <br> Now, at the top level parrot directory, you can create <code>foo.imc</code> containing:</p><blockquote><div><p><nobr> <wbr></nobr><tt>.sub main<br>&nbsp; loadlib $P0, "tclgroup"&nbsp; &nbsp; # Load combined tcl lib<br>&nbsp; $I0 = find_type "TclInt"&nbsp; &nbsp;# Find ID for a TclInt *<br>&nbsp; $P0 = new $I0&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; # Instantiate<br>&nbsp; $P0 = "asdf"&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;# Assign<br>&nbsp; print $P0<br>&nbsp; print "\n"<br>&nbsp; $S0 = typeof $P0&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;# Get the type description.<br>&nbsp; print $S0<br>&nbsp; print "\n"<br>&nbsp; end<br>.end</tt></p></div> </blockquote><p>This snippet prints out </p><blockquote><div><p> <tt>asdf<br>TclString</tt></p></div> </blockquote><p> 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. <br> <br> Next steps: </p><ol> <li> Remove any dependence in Tcl's PIR on the Perl* PMCs.</li><li>Provide the ability to generate Tcl Lists from within Tcl<br> (that is, write [list]), and insure that the right thing happens when shimmering between a list and a string. For example, insure that:<blockquote><div><p> <tt>puts '[string range [list 1 2 3] 0 2]'</tt></p></div> </blockquote><p>Actually generates</p><blockquote><div><p> <tt>'1 2'</tt></p></div> </blockquote><p>which will have been shimmered from a TclList (returned by [list]) to a TclString</p> </li></ol><p> <i> [*] - 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 <code>String</code>, which you can, thanks to <code>runtime/parrot/include/pmctypes.pasm</code>, just create with <code>$P0 = new String</code>) </i></p> coke 2004-10-13T23:49:26+00:00 journal ParTcl <p>I'm working on implementing Tcl (<a href=""></a>) from scratch on top of parrot (<a href=""></a>). The code so far is available as part of the parrot distribution.</p><p>I've spoken briefly with some of the folks on the Tcl Core team, who suggested that this version of Tcl be called "ParTcl"<nobr> <wbr></nobr>... which is so bad, I'm going to have to use it.</p><p>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.</p><p>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).</p><p>Volunteers welcome. ^_^</p> coke 2004-10-12T17:03:39+00:00 journal