I've been keeping busy lately with two projects. The first, a new one, is finally starting to implement the Matlab/Octave-on-parrot compiler. The second, an old one, is my continuing work on the calling_conventions refactor stuff.
I'll talk about the Matlab/Octave compiler, which is now called "Matrixy" later. For now you can check it out at it's Googlecode homepage.
My current cc work involves swapping out all the calls to Parrot_PCCINVOKE with calls to Parrot_pcc_invoke_method_from_c_args (or related variants). I had been trying to update the calls in the file src/io/api.c, but a few weird recursion situations were causing intermittent segfaults or coredumps. I worked on this for a few days, was getting pretty frustrated by it, and decided to do something else. So I picked up a Trac ticket where a segfault was causing problems involving overriding the init vtable method.
vtable overrides have been being handled by calls to Parrot_run_meth_fromc_args and related variants. While tracing through the segfault, I found that these functions are not very robust in their handling of contexts and were creating poisonous situations if they were used inside an invocation that used one of the different families of functions. I replaced the call to Parrot_run_method_fromc_args with Parrot_pcc_invoke_from_sig_object, and the segfault disappeared.
So, thinking back to some of the errors I was having with my cc work, I realized that Parrot_run_meth_fromc_args was poisoning recursive calls to Parrot_pcc_invoke_method_from_c_args, and I needed to destroy the former before I could make the switch over to the later. Working ast night and this morning, I finally made the switch. The switchover wasn't perfect because now I'm getting some weird errors in some of the tests, but it's better going then it was. I need to do some tests now to see if the functions in src/io/api.c can be updated now without causing more errors like it was earlier.
The calling_conventions refactor is large and sweeping, and is being done in multiple parts. Allison is working on another branch now to try and factor out common code from generated methods. I'm trying to unify all the various invocation functions to use common code. Once we get all the common code into one place, we're going to optimize the hell out of it (I already have lot of ideas for that!). The end result is that the system should be both more elegant and faster.
I don't think all of this work will land prior to 1.0, and in fact none of it might if we can't make the individual updates stable enough. Post-1.0 however, a lot is going to change under the hood, and all for the better.
