Juggling Projects

Lot's of work has been going on in Parrot land post-YAPC. Lots of people are doing cool new work, and there has been a steady influx of interested new participants. Some people suggested that my Parrot4Newbies posts recently have been bringing them in, but the reality is that there are lots of interested people already who are just looking for opportunities to get involved, and anybody can make those opportunities public.

I have been blogging like a wild man this past week, and particle suggests I can lower the rate of Parrot4Newbies posts to give the community time to think of new ideas for it. I'm fine with that, I'll try to get a nice good post for it out again next week. As is my style, I have about half a dozen posts written, they just need some finishing touches before I publish them.

During YAPC I was working on a new IO architecture where IO PMC types delegated non-subclassable attributes to a new Handle type. The idea was to make things like FileHandle and Socket types subclassable from PIR, and just delegate the messy stuff to a non-subclassable type. Basically, it was a utilitarian solution that resolved the immediate need while not addressing the underlying problem of subclassing PMC types. Allison convinced me that the right way forward was not to write a hackaround that's specific to the IO system, but to fix PMC subclassability entirely.

The real problem is that some PMC attributes are subclassable (PMC*, STRING*, INTVAL, FLOATVAL), and all other types are not. So when you create an object of a C type, only the subclassable attributes are accessable. If you try to access non-subclassable attributes, Parrot throws an exception. This behavior is obviously wrong, we shouldn't be allowed to even create a subclass of a type that's going to be unusable for what we want. Or, we should find a way to make all attribute types properly subclassable. The way to do this is to allow arbitrary C types to autobox into PMCs so that they can be stored in the ResizablePMCArray of the Object's attributes. Then, the GETATTR/SETATTR macros need to be taught how to box and unbox types at runtime. It's simultaneously a very hard and very easy problem to solve, and if anybody is interested in attacking it before I am ready myself, that would be awesome.

So, I backed out all the changes concerning the subclassability issue from the IO work, and focused on other things. Right now I'm stalled on that because there are some issues involving the new Pipe code that Infinoid wrote not playing well with the old FileHandle code. Hopefully we can get that branch fixed and merged to trunk this week, and then the field is set for AIO.

Austin Hastings put his Close compiler source code up onto Google Code, and I've been eagerly reading through it. Haven't had a chance to play with it yet, but it looks awesome: like the replacement for PIR that we've always wanted. A few changes and improvements need to be made, but it's awesome already.

A few days ago Coke started a new branch to begin the conversion of Contexts into a new PMC type. This will make them properly garbage collectable and fix all the leaky memory that's associated with Contexts right now. At least, that's the hope. I started playing with this branch yesterday, doing some of the conversions, and I have to say that it is a lot of work. Contexts, simply put, are fundamental to the operations of Parrot. Also, interacting with them doesn't happen through a particularly clean or well-encapsulated API. In hindsight we probably should have worked to encapsulate it better first, but we've got an open branch right now and might as well get to work on it. Hopefully any lessones that we're going to learn the hard way can be learned quickly. I have some hopes that this branch may succeed, but I'm also planning backup steps in case it doesn't

I've also been looking closely at the GC now, and have even put together a little bit of test code locally for implementing a "very concurrent" GC core based on a paper cotto sent me a while back. I probably won't have time to break ground on this before 1.5, so if anybody is interested in helping with the GC please let me know and we can start putting together a game plan now.

I've also seen some interest in the threading system recently. Infinoid found some problems with it while trying to write tests for the new Pipe types, and we've had some new hackers interested in working on the threading system to support the concurrency primitives in Rakudo, so maybe we will get some good work done on that system in the near future.

So that's a brief glimpse of some of the things that are going on in Parrot this week, I would love to hear about some other projects that people are working on too (especially since we didn't have #parrotsketch last week to share).