Blog Closed

This blog has moved to Github. This page will not be updated and is not open for comments. Please go to the new site for updated content.
Showing posts with label Release. Show all posts
Showing posts with label Release. Show all posts

Thursday, September 23, 2010

PLA: Release 1

I'm happy to finally announce the first official release of Parrot-Linear-Algebra (PLA). PLA is an extension project for the Parrot Virtual Machine which brings linear algebra support and bindings to the BLAS library.

PLA has several dependencies (see below). Once you have those installed properly, you can obtain and install PLA using Plumage, the Parrot package manager:

plumage install parrot-linear-algebra

Or, if you prefer to do things the hard way, you can use this series of commands to obtain and build PLA like this:

git clone git://github.com/Whiteknight/parrot-linear-algebra.git pla
cd pla
parrot-nqp setup.nqp build
parrot-nqp setup.nqp test
parrot-nqp setup.nqp install 
 
Dependencies

Before you get started with PLA, you must install some dependencies.

Parrot

You must have an installed copy of the Parrot Virtual Machine, version 2.8.0 or later.

BLAS

PLA links to the BLAS library. You can use either the standard reference BLAS library from netlib.org, or you can use one of the ATLAS or CBLAS variants. There are other implementations of BLAS, though PLA may not currently be compatible with all of them (patches and error reports welcomed!)

Kakapo

Kakapo is a development framework for the NQP language. It provides a unit testing library which PLA uses to implement its test suite. A special version of Kakapo is required for PLA release 1. You can use this sequence of commands to get and install that version:

git clone git://github.com/Whiteknight/kakapo.git kakapo
cd kakapo
checkout tag PLA-version-1
parrot-nqp setup.nqp build
parrot-nqp setup.nqp install

Linux

Sorry Windows guys! At the moment PLA only runs on Linux and other Unixy systems. Windows support is planned for future releases, but didn't make it into this one.

Next Release

PLA releases are not on a regular schedule. A new release might not come out again until new features are added or until something in the toolchain becomes incompatible.

Here are a list of TO-DO features that will eventually make it into future releases:
  1. Bindings to the LAPACK library, to add more linear algebra utilities
  2. Windows support, including a Windows installer
  3. Writing bindings for other programming languages which run on Parrot, including Rakudo Perl 6.
  4. Adding additional types, including special vector types and multi-dimensional tensor types.
If any of these things interest you, or if you have other cool ideas, please feel free to let me know and get involved!

New Participants Welcome!

Interested in PLA or linear algebra in general? You can fork a copy of PLA and start contributing right now! I'm happy to talk to interested contributors, and to add patches for bugfixes and new features into the core repository. Please let me know if you're interested in helping out.

If you have specific feature requests that you would like to see added to PLA, but aren't able to implement them yourself, please let me know.

Thanks

I want to offer a big thanks to the greater Parrot community for helping in various ways. PLA relies on several tools and libraries, the result of many man-hours of work by Parrot community contributors.

Tuesday, September 7, 2010

PLA Release Is Near

I added in support for HLL mapping of autboxed types in Parrot-Linear-Algebra, and with that I feel like I'm getting pretty close to a good point for cutting a release. I don't yet have any tests for the autoboxing behavior, so I do need to write those first. Shortly thereafter I think I can get to work on the release.

HLL mapping, for readers who may not be familiar with the term, is a very cool feature in Parrot. It allows the user to manually re-map basic types to user-defined types instead of the built-in varieties. When the VM would normally create an Integer PMC, for instance, it would instead create a custom "MyInteger" type (or whatever you called it). You can use the HLL mapping functionality to override many built-in types in many operations. What's super-cool about HLL mapping is that the mapping is defined in a particular HLL namespace, so programs with modules written in different languages could allow each module to define it's own type mappings that do not conflict with each other.

In Parrot, an "HLL namespace" is a special type of top-level namespace object which allows the use of type mappings, among other things. In PIR code, defining an HLL is simple with the .HLL directive:

.HLL "MyLanguage"

All regular namespaces defined below that directive will be inside the HLL namespace. This means that so long as we make proper use of .HLL directives, we can maintain almost perfect encapsulation between modules written in different languages, which can be an extremely valuable thing for proper interoperation.

The default HLL is called "parrot". If you don't specify an HLL directive, you will automatically be inside the "parrot" HLL namespace. To get back to there, you can type (in PIR):

.HLL "parrot"

I started writing some tests on Saturday, and discovered two problems that brought me to a halt: First, NQP doesn't have any built-in way to specify an HLL namespace. I also wasn't able to find any crafty, sneaky way to inject one either. Second, HLL type mapping doesn't work in the parrot namespace.

The second problem turned out to be the most frustrating because the test programs I was writing were silently failing for no visible reason. The mapping method appeared to execute and return correctly, but none of my types were being mapped. Dutifully, I filed a bug about it. It turns out that this is by design, not accident, although I wish that it had been a little bit better documented. HLL mapping lookup operations can be a little bit expensive, so we don't want to be doing that all the time. Also, the parrot HLL is supposed to be a default, neutral space and one module shouldn't be able to break encapsulation and modify that HLL namespace in a way that would adversely affect other modules written in other languages. NotFound put together a commit that throws an exception when a type mapping is attempted in this HLL, so that allays my concerns that not only was it failing, but it was failing silently.

I also started putting together a patch in my fork of NQP-RX that adds HLL support, but the patch isn't very mature yet. If I can get this patch ready and merged into NQP-RX master in time for the 2.8.0 release, I will write up the last remaining PLA tests for this feature in NQP. Otherwise, I will write them in PIR.

The PLA release is going to target Parrot 2.8.0. There are a few things that I want to do first, before the release is out the door:
  1. Finish writing the tests for the HLL mapping behavior, which might involve finishing up that patch to NQP
  2. Write up some decent public documentation. The default output of pod2html is pretty ugly looking, so I may end up writing a custom converter. I've started experimenting with Github Pages, though my experiments so far in using the pod2html output there have not been too attractive. I may go through and reorganize all the POD documentation source anyway. I definitely want to expand documentation and examples of certain features.
  3. Get a release, or pseudo-release of Kakapo that targets Parrot 2.8.0. If Austin isn't able to get a working release of that software that's up to his standards in the next two weeks, I may pick a revision that works well for my purposes and tag it on my Github fork. It won't be the same as a real release of Kakapo, but at least it won't be a stumbling block for me.
  4. I need to check and double-check that the setup script for PLA is doing all the correct things with respect to releasing. I need to check that the generated Plumage metadata is correct and allows complete and functional installations using Plumage. I also need to check that I can generate correct .deb and .rpm packages for those systems.
  5. I want to look into creating a windows installer, but I make absolutely no promises about that. I certainly haven't done any testing whatsoever on Windows so far, and I do not have high hopes that it will work at all there. This may be a task for the next release, or later.
In the span of about two weeks, we could have a release of a high-performance linear algebra toolkit for Parrot. It obviously doesn't have a huge amount of functionality yet, but it is a good start and provides a solid base of some important standard operations. I've got a lot of plans for the future of this little project, but we're at a good point right now and I think it will make for a very nice release.

Friday, June 25, 2010

EmbedVideo Version 1.0 Released

I'm pleased to announce the 1.0 release of the EmbedVideo extension for Mediawiki.

EmbedVideo is a highly capable and configurable extension for embedding flash video content from hosting sites such as YouTube. The extension is being developed on Github and is available for download from there as well. Information is also available on the extension page at mediawiki.org.

Major new features include:
  • Completely rewritten code base to follow current MediaWiki best practices
  • i18n internationalization support
  • Support for new hosting services
  • Backwards-compatibility support for EmbedVideoPlus
  • Thumbnailing, floating alignment, and attached descriptions
  • Support for custom embedding clauses
  • Support for per-service default width and width/height ratios
Contributions and patches, especially those that add support for new video hosting services, will be much appreciated.

Tuesday, May 18, 2010

Parrot 2.4.0 "Sulfur Crest" Released!

"So there me was beating boulder into powder because me couldn't eat it, and magic ball land in lap. Naturally me think, "All right, free egg." because me stupid and me caveman. So me spent about three days humping and bust open with thigh bone so me could eat it good. Then magic ball shoot Oog with beam, and next thing me know me go out and invent wheel out of dinosaur brain. Magic dino wheel rolls for three short distance until me eat it. The point is, me get smarter. Soon me walk upright, me feather back dirty, matted hair into wings for style, and me stop to use bathroom as opposed to me just doing it as me walk. " -- Oog, Aqua Teen Hunger Force

On behalf of the Parrot team, I'm proud to announce Parrot 2.4.0 "Sulfur Crest." Parrot is a virtual machine aimed at running all dynamic languages.

Parrot 2.4.0 is available on Parrot's FTP site, or follow the download instructions. For those who would like to develop on Parrot, or help develop Parrot itself, we recommend using Subversion on our source code repository to get the latest and best Parrot code.

Parrot 2.4.0 News:


- Core
  + Various long-standing bugs in IMCC were fixed
  + STRINGs are now immutable.
  + use STRINGNULL instead of NULL when working with strings
  + Fixed storage of methods in the NameSpace PMC
  + Added :nsentry flag to force method to be stored in the NameSpace
  + Added StringBuilder and PackfileDebug PMCs
  + Added experimental opcodes find_codepoint and unroll
- Compilers
  + Fixed reporting of line numbers in IMCC
  + Removed deprecated NQP compiler, replaced with new NQP-RX
  + Removed NCIGen compiler
- Deprecations
  + Tools to distribute on CPAN were removed
  + Deprecated dynpmcs have been removed to external repositories
  + Removed RetContinuation PMC
  + Removed CGoto, CGP, and Switch runcores
- Tests
  + Many tests for the extend/embed interface were added
  + done_testing() is now implemented in Test::More
- Tools
  + The fakexecutable tapir is renamed parrot-prove
  + Performance fixes to the pbc_to_exe tool
  + Fix data_json to work outside of trunk
  + The dynpmc GzipHandle (zlib wrapper) was added
  + The library Archive/Tar.pir was added.
  + The library Archive/Zip.pir was added.
  + The libraries LWP.pir, HTTP/Message.pir & URI.pir were added.
- Miscellaneous
  + Six Parrot-related projects accepted to GSoC
  + Improve use of const and other compiler hints

Thanks to all our contributors for making this possible, and our sponsors for supporting this project. Our next release is 15 June 2010.

Enjoy!

Friday, February 19, 2010

Special Release: Parrot 2.1.1

Earlier today we got a bug report from the #perl6 folks that Parrot was leaking memory. chromatic put a fix together and it was decided to cut an emergency bug-fix release. Since Rakudo bases it's releases on the previous Parrot release, and they can't really put out a release that is known to leak memory, they now have the special Parrot 2.1.1.

So if you were using 2.1.0 for your application and would like to plug a memory leak in long-running programs, please update to 2.1.1 instead.

Tuesday, February 16, 2010

Parrot 2.1.0 Released

Just a few moments ago Daniel Arbelo (darbelo) released Parrot 2.1.0 "As Scheduled". It's always nice to see a software project released on time and under budget!

Parrot 2.2.0 is scheduled for 16 March, and will be released by Christoph Otto (cotto).

Friday, January 22, 2010

Parrot 2.0: Personal Retrospective

A while ago I put out a list of tasks that I wanted to see in Parrot 2.0. This wasn't necessarily a list of tasks I wanted to perform personally, more like a wishlist of tasks that I wanted to see in 2.0 and would have been willing and capable of doing myself if necessary. In other words, it was a list of projects I was personally interested in, even if I didn't have the time to complete them all myself.

Now that 2.0 is fresh out of the factory I think it's a good time to go back over this list and review the status of all the things I wanted to have been included.

GC Internals: At the time I wrote the list this task was already done. What I wanted to do was clean up the GC internals and properly encapsulate things so we could add new cores more easily. I had done that work back in May, and since then other work has happened to cleanup and improve the GC internals for clarity and encapsulation. In large part, I consider this task complete. Final Result: Done.

Incremental GC: This didn't happen, though in the buildup for the 2.0 release a lot of excitement and motivation has been generated to improve the GC. I suspect we will see a Generational GC first, but an incremental GC cannot be far behind (especially if interest in the RTEMS port continues to grow). Final Result: Not Done.

Generational GC: See my comments above. Interest is building and I think the community has at least a tenative agreement that the next GC core we work on will need to be a generational one. Downside to this is the likely need to add write barriers throughout the codebase which can be costly in terms of performance and code bloat. However, we should see performance improvements from it. Final Result: Not Done.

Boehm GC: Bacek put this together recently, but unfortunately the results were not as good as we expected. I did a brief analysis about why performance might have been a problem with the Boehm collector in Parrot, but without doing more benchmarking myself I really don't know what the problem is. Maybe 2010 will see some improvements to this core and better performance as a result. Final Result: Done.

Context PMCs: This was another project that Bacek put together, and the result was quite spectacular. It only lasted for a while, however, before the Context PMC got merged with the CallSignature PMC into the new CallContext. Some tests broke and performance isn't as good yet as I think it could be, but the hardest part is done now. Final Result: Done.

RetContinuation Unification: I had anticipated that RetContinuation would be merged into Context first, and then that PMC would have been merged with CallSignature. Things happened in the opposite order with CallSignature and Context being merged into CallContext instead. As of the 2.0 release RetContinuation is still a separate entity, though there are rumblings about changing that and cashing in on the performance win. Final Result: Not Done.

Subclassable Exception Handlers: I'm not really sure where this task ended up, though I assume the work on the Context PMC would have enabled it. At the very least (and I say this without doing any testing or exploring the codebase) the hardest part of the work is now done. I'll mark it off as a success. Final Result: Done.

PCC Refactoring: This was done and ended up being a herculean task. Also, the new (and cleaner!) code brought along a performance penalty that we've been scraping and clawing to mitigate. One thing that cannot be argued though is that the mechanism has been significantly improved and various optimizations and feature additions will be much easier now. Final Result: Done.

CallSignature Unification: My original intention for this task was that the Context+RetContinuation PMC would be merged into CallSignature. Things happened in the wrong order and CallSignature got merged into Context first. Final Result: Done.

Subclassable Everything: This task, which would allow all PMC types to be completely subclassable from PIR, was daunting and perhaps a little bit too ambitious. First stage required that most fields in existing PMCs were converted to one of the "big 4" types (INTVAL, FLOATVAL, STRING, PMC). Second stage required that we come up with a sane way of working with opaque pointers and data items from PIR, which we don't have yet. Final Result: Not Done.

:invocant: To my knowledge this one hasn't been added yet. With the new PCC system in place it should be trivial to add, but i haven't seen it done yet. Final Result: Not Done.

Morphable Objects: I can't even really remember what I wanted out of this task, but in hindsight the idea of morphing objects between types doesn't sound like something I would really want to stress. Final Result: Not Done.

Override VTABLE Invoke: I believe this one was added shortly after the PCC refactors landed, though I haven't played with the new implementation myself. I'll mark it as being completed for now. Final Result: Done.

IO Cleanups: The IO system is decent but does need some work still. I was hoping we would see a proper pipes implementation, and then once we have all the major fundamentals I was hoping we could get some of the various codepaths unified and simplified. This one, unfortunately, did not happen the way I wanted. Final Result: Not Done.

PIR IO Objects: The goal was to properly subclass IO object types from PIR. This would require both the aforementioned "IO Cleanups" with the pipes implementation, and maybe some variation of "Subclassable Everything" so we could manipulate the low-level buffers from PIR. Sadly, this did not get completed. Final Result: Not Done.

Asynch IO: I got derailed on this project, which I put quite a lot of planning effort into, when the IO Cleanups project got stalled. I still have all the best intentions of getting this feature added, but sadly it did not make it into 2.0. Final Result: Not Done.

IO Unification: This was dependent on the Asynch IO task. The goal was that we could merge the code paths between AIO and regular IO, implementing some blocking primitives in terms of their non-blocking counterparts. Without AIO, this was impossible. Final Result: Not Done.

Concurrency Cleanups: The concurrency system is a mess and I was hoping to change that. Plus, AIO needed improvements in this area to allow us to properly integrate things the way they should be. I never took the time to tackle this one and since it was deemed lower priority I don't think anybody else did either. Final Result: Not Done.

Update PDDs: I haven't spent hardly any time on documentation recently, and the docs didn't get improved to the standard that I was envisioning. Other people did work on these but I am not sure if it's the kind of comprehensive overview that I was hoping for. Final Result: Not Done.

Parrot Developer Guide: The first published book was a PIR users guide. I was hoping to at least start second book, a more in-depth guide for internals developers. This never got off the ground. Final Result: Not Done.

From among 20 tasks that I was personally interested in seeing included in the 2.0 release, 7 of them were completed. That's actually not a bad number considering the work we did accomplish as a development team, the pathetic level that I have been contributing at for the previous few months, and the enormous scope of some of these tasks.

Sometime soon I will try to post a wishlist for the upcoming supported releases: 2.3, 2.6, 2.9, and 3.0.

Wednesday, January 20, 2010

Parrot 2.0 is Out

Behold! Parrot 2.0 has been released by chromatic. 2.0 is going to be a supported release that most other projects and end users should be able to target confidently for the next several months.

Keep in mind that Parrot uses time-based and not feature-based releases. So 2.0 doesn't strictly satisfy any pre-set group of specifications. It does represent a stable and well-tested version of the software however. The number of feature addititions or performance enhancements from 1.9.0 is actually relatively small, but we have a lot of confidence in this release because of all the testing that has been done to it.

I'll have plenty more things to say about 2.0 in the coming days.

Wednesday, August 19, 2009

Parrot Release Managers

A while back Coke said I could take over the job of herding release managers, and I gleefully took him up on the offer. A few days ago I sent out an email asking for people to fill in for the remaining releases this year. Specifically we're looking for some fresh blood, new people to give the release a shot. Every new person we get doing releases helps to increase our bus number ever higher, and a good bus number is good for us (and bad for buses).

Shortly after the announcement I got a few emails from interested people, including a few from people who have never done a release before. Signed up fo the rest of the year are: particle (1.6), dukeleto (1.7), bernhard (1.8) and gerd (1.9). After that the schedule is wide open.

I've managed a few releases at this point, and I can say with some confidence that it's really not a hard process at all. Actually, there are several steps that I think would be ripe for automation and could become even easier, if an intrepid releaser were interested in doing so. I won't opine about that too much here, just mentioning it off-hand.

Here are the basic steps for making a release.
  1. Send out some messages on IRC and on the mailing list for people to update NEWS and PLATFORMS.
  2. Update NEWS and PLATFORMS yourself, because everybody ignored your messages to the mailing list.
  3. Update the version number in a variety of files, even though we have computer programs and programming languages capable of incrementing digits.
  4. Come up with a name that's too clever by half. Don't tell anybody, that would ruin the surprise (Since our release schedule is so regular and predictable, we need to have some surprises!)
  5. Waste 20 minutes of your life Run fulltest. I like to spend this time watching TV, chatting on IRC, eating junk food, or looking up funny pictures of cats on the interwebs.
  6. Make the release. This is the hard part: Type "make release VERSION=a.b.c".
  7. Unpack the tarball into a new directory. Build it and waste 20 more minutes of your life run make fulltest again.
  8. Upload the tarball to the FTP server
  9. Send out a bunch of announcement emails telling people that we've made a release even though we could program Google Calendar to do this on the third tuesday of the month, every month, for the next thousand years. Tell everybody it's a big deal regardless of how dependable and boring our release cycle is.
  10. Rake in the karma on IRC.
I am joking about several of these things, obviously. I make light precisely because it's not a big deal by design. We want Parrot releases to be quick, easy, and regular. Unextraordinary (ordinary?). It's easy to do, and we want lots of people to do it. It's easy, it's no big deal, there is no reason why you shouldn't be involved in it.

Branches Come Crashing In

The release wasn't barely out the door before some branches started merging into trunk. Just like I predicted, there were a few changes ripe and waiting to land as soon as the feature freeze was listed, and so they did.

First, NotFound's auto_attrs branch landed, bringing with it a change to almost every PMC type and a major simplification to the way PMC attribute structures are managed. Also, it is the first major user of the fixed-size structure allocator I developed last month, so it's a cool test of that. My hope is that once we've given it a good exercise we can start using the allocator in a variety of other places where we need small, fixed-size structure allocations and we are able to manage the lifetimes of those structures manually. This branch represents a big algorithmic improvement and with a few cleanups, improvements, and optimizations, this could usher in some other big changes in the near future.

Closely thereafter, bacek (who I swear is some sort of magical coding robot) landed his branch to cleanup the Sub PMC and remove the Parrot_Sub structure. This brought with it another huge changeset that swept most of the repo, but provided us with some major improvements to subroutine allocation and management (not to mention some much-needed code aesthetics). Very nice.

That success out of the way, I suggested he take a look at the context_pmc2 branch and see if he could work some similar magic on the Parrot_Context structure and the new Context PMC. Less then 24 hours later he had a gigantic change committed that not only cleaned up the structure but completed the conversion and got Parrot to build! There were some segfaults in miniparrot during initialization though (trying to create the first context before all the PMC types were initialized, and things like that) so it wasn't perfect, but was quite good progress. I just committed a fix to the initialization logic, and bacek claims that he'll be able to get the branch finished by the end of the day. Magical robot indeed!

I talked with Allison last night about the pmc_sans_unionval branch which I had gotten building and passing all tests (including codingstd tests) and was ready to merge in. However, by the time I got the thumbs up and was ready to merge, the above two branches had already landed and I could no longer merge that branch cleanly. Now, the branch segfaults on one particular test (t/pmc/complex.t) because of a bad pointer in a RetContinuation PMC, which I haven't been able to track down yet. As soon as I can get that last test to STFU, I'll merge that branch in as well.

I'm hearing good news about the pluggable runcores branch and the profiling stuff from chromatic and Cotto. Not to mention the long-awaited PCC refactors that Allison has been working on. With any luck we could see both these two branches landed into trunk soon, folloed by a flurry of activity from people wanting to use and improve these new toys.

Yesterday at the #parrotskech meeting, chromatic asked what the weekly development priority should be and I suggested, knowing how many branches were poised to land, that we should focus on basic, raw stability. With a few test failures being reported here and there it seems that might not have been such a bad suggestion. Plus, as I mentioned above, there are at least three branches that could plausibly land soon, which will just increase the short-term instability. Basic program stability is a very good thing to focus on (and it gives us a good excuse to write a bunch more tests for all the fun new things).

So things are moving quickly and I hope that the rest of this release cycle stays as eventful as the first two days were. I'm also looking forward to tomorrow's Rakudo release because I've heard good things about that too.

Tuesday, August 18, 2009

Parrot 1.5.0 "TEH PARROTZ!" Released!

I released Parrot 1.5.0 a few moments ago. Here's the release announcement:
On behalf of the Parrot team, I'm proud to announce Parrot 1.5.0 "TEH PARROTZ!." Parrot is a virtual machine aimed at running all dynamic languages.

Parrot 1.5.0 is available on Parrot's FTP site, or follow the download instructions. For those who would like to develop on Parrot, or help develop Parrot itself, we recommend using Subversion on our source code repository to get the latest and best Parrot code.

Parrot 1.5.0 News:
- Core
+ Removed several deprecated functions and features
+ Removed bsr, jsr, branch_cs, and ret opcodes
+ Removed global stacks system
+ Changed OPS file format to include explicit preamble
+ Changed all "new 'Iterator'" instructions into 'iter' instructions
+ Removed Configure.pl options for specifying non-working GC cores
+ Removed unexecuting code as found by Coverity
+ Improvements to the Parrot Debugger
+ Added experimental fixed-size structure allocator to the GC
+ Added experimental lazy arena allocation to the GC
+ Removed the defunct PASM1 compiler object
+ Refactored hashes, keys, and iterators
+ Added "corevm" make target to build Parrot without all the supporting libraries
+ Removed Random PMC type and added in a "rand" dynop
+ Optimization and Improvements to the NCI thunk generator
+ New include file libpaths.pasm
- Compilers
+ Multiple .local with same name and different type is now an error on IMCC.
- Platforms
+ Improved support for detecting Fink and Macports
+ Updated search directories for libraries
- Documentation
+ "Parrot Developers Guide: PIR" released to publisher and available to purchase
+ Improved documentation about Parrot Debugger
+ Update PGE Documentation
- Miscellaneous
+ Added tests
+ Fixes to code, documentation, and standards

Thanks to all our contributors for making this possible, and our sponsors
for supporting this project. Our next release is 15 September 2009.

"TEH PARROTZ!" is a name that I've been wanting to use for a while. It pays nice homage to a popular internet meme and shows that we're having fun and that development isn't always SRS BIZNS!!



It can be a lot of fun, especially as more new people are getting involved. And with the release out of the way, we can get back to some serious development.

Sunday, August 16, 2009

Approaching the 1.5.0 Release

I'm dressing up as the release manager for Parrot this month, hoping to push 1.5.0 out the door without any major issues. This is going to be quite an impressive release for our community because 1.4.0 was a deprecation point, and 1.5.0 is going to be the first release where not all features present in 1.0.0 will still be available. And a lot of old "features" have been through the grinder this month.

Because of all the massive changes and removals of features, I sent an email to the list a few days ago asking for a freeze on big changes or branch merges starting today and lasting through Tuesday. I want to make damn certain that trunk is stable when it's time to push it out of the nest. To that end, I am asking everybody who is reading this blog post right now to get the latest version of Parrot trunk from SVN and submit a smolder report on your platform. These reports are very important, and will give us the information we need to be confident about Parrot's stability on Tuesday. It doesn't take much time to put together a smolder report, and it's amazingly helpful to us.

Because of the feature freeze there is active development going on in some branches. I expect some of these to be merged in to trunk shortly after the 1.5.0 release. I'll post some information about a few of these tomorrow.

Saturday, August 1, 2009

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.