Programming, Software and Code

Parrot: 1.4 and 1.5

The 1.4 release of Parrot was a big deal because it was a major deprecation point. Items for which a deprecation notice had been added prior to 1.4 can now be removed. Some such "features" have been deprecated for months, and were sorely in need of being violently removed. Plus, unwanted features that exist in Parrot now cannot be removed without a proper deprecation notice until after 2.0 in January, which is quite a long way to wait to remove or improve some of the remaining ugly warts that are littered here and there.

In addition to the things that need to be removed, a few important things need to be added as well. The pcc_rewiring branch that Allison started back in days of yore is supposed to be a priority in the coming weeks. About 50% of the tickets assigned to me in trac are blocking on this work, and I've blogged about some projects that are dependent on it ad nausea. I sincerely hope that pcc_rewiring makes it into trunk before 1.5, for a large variety of reasons.

Another branch that I've been working on with Infinoid, io_cleanups, is running behind schedule and really needs to make it in before 1.5 or else it will just keep getting older, more stale, and more out of sync with the rapid development in trunk. chromatic and cotto are working on a cool new project to make runloops pluggable, and I hope that makes it into 1.5 as well (although I don't know the status of it right now). That would be a very cool addition to Parrot. Bacek has been continuing his work on keys and hashes, and has another branch to cleanup OrderedHash that I hope lands before 1.5 also.

I personally had hoped to start on the AIO project before 1.5, but I'm blocking that on the io_cleanups branch. There are two good reasons for this: First, I want to make sure we have all the necessary primitives in place (files, sockets, pipes) so that when we add AIO it can properly handle everything and will be generic enough to be expanded to new types in the future. Second, I don't want to be opening two branches of sweeping changes in the same subsystem. It's a recipe for disaster and the time we spent cleaning up the fallout could be used to just get io_cleanups working first.

A while back Coke started a branch to convert Contexts into a properly-encapsulated PMC type, and I jumped right in to help with the conversion. I didn't suspect the branch would succeed, it's a huge task and we had a lot of things we needed to learn about it. Luckily, I think we have learned a lot from this context_pmc branch, and we can now make a more intelligent attempt at the conversion. Here is a basic work list for how we can make this work:
  1. Begin properly encapsulating Contexts behind a standard (if temporary) internal interface.
  2. Figure out the kinds of ways Contexts are being used, and separate them out into different interfaces and possibly different storage structures
  3. Begin converting Contexts into PMCs, only having to change things behind the abstraction barrier we've set up in #1 and #2.
I have more to write about the Contexts conversion, so I will save the rest for another post. However, I think it's reasonable that we could start on task #1 and get a few cleanups merged into trunks before 1.5. It's a big job and it makes sense to break it up into small pieces.

The PIR book finally hit the press this week, and I've already gotten three copies of it sitting here in my apartment. It's a very small little book, more of a "pocket guide" then anything, but it's still a very cool start and I am looking forward to expanding it and improving it in the coming months. I think Allison mentioned that she wanted to have a larger book out for the 2.0 release, and I'm antsy to get working on that.

Speaking of 1.5, I'm going to be playing the role of release manager for it. rgrjr was schedule to do the release, but he has become busy in real life, so I am going to fill in. It's really a testament to the Parrot project management that so many people are capable of doing a release, because having one person become busy doesn't harm us or slow us down at all. You don't realize how important the Bus Number is until you're working on a project with a very high one.

The next two weeks are going to be busy in preparation for 1.5, and I think it's going to turn out to be an awesome release with lots of changes and improvements.


orderedhash_revamp will not be merged before after 2.0... I failed to add deprecation notice into DEPRECATED.pod

This entry was originally posted on Blogger and was automatically converted. There may be some broken links and other errors due to the conversion. Please let me know about any serious problems.