decnum-dynpmcs: Week #00

This is the first weekly status report for the decnum-dynpmcs Summer of Code project, where I'll detail the current state of the implementation and outline my plans for the future
Right now we are on week 3 of the GSoC community bonding period. Progress has been a bit slow, a few details had to be adjusted from the initial proposal, a few design questions were raised and some prototyping is taking place.

First, due to the license decNumber is distributed under it was decided to develop the PMCs out-of-tree, and ship separately from the parrot core distribution. The code is hosted at http://code.google.com/p/decnum-dynpmcs/ and there is a google group at http://groups.google.com/group/decnum-dynpmcs
This separation forced some changes to approach I had in mind, as now the parrot build infrastructure would be unavailable, the pmcs would have to become dynpmcs and instead of adding to already-working Makefiles, I had to create new ones from scratch. This reminded me how hard it is to write portable Makefiles, even when leveraging the data in parrot_config and a prefabricated Configure.pl[1] it can be a mess. Right now, building only works properly with GNU make, and mostly-works with BSD make[2].
Also, since nobody we could find packaged the library for distribution, it became necessary to import it into the repository and build it alongside the PMCs. While preparing the build infrastructure, I cobbled together a minimal dynpmc based on the decQuad module[3]. This proved useful when cotto, my mentor, started a round of design questions on the project mailing list.
The first question was about the decContext data structure. I originally wanted to give each PMC a separate operating context, but the possibility came up to create a unique shared context for all PMCs of the same type. Both approaches have valid reasonings behind them, and anything that can be done with one approach can be done with the other as well. It all comes down to a matter of interface convenience and trying to anticipate what the common use case will be.
I don't really trust myself to know what users will need, so in an effort to spread the blame I'm prototyping both approaches on top of the decQuad module, and I'll throw them at people so that I can get some opinions and use cases.
The first prototype implements per-PMC contexts, can be used for +, -, * and / operations and has methods to get and set the rounding mode. This should be enough to get some comparative testing done, so I'll be working on the global-context prototype the next few days. Then I'll start inflicting the prototypes on a few sucke^W testers before making a decision. After that I think I'll tackle the exception-throwing on invalid results, but that still needs a round of discussion on the google-group.

[1] Plan for the future: Right after I get my magic-flying-pony-that-pisses-rainbows I want to change this into "Configure.pir" and start depending only on what an installed parrot provides.
[2] But then, I'm the only sucker developing on OpenBSD so it kind of works out.
[3] decQuad wasn't chosen because it would be useful, but because it was easier to build by hand while I wrote the makefiles. Sharp observers will note that it doesn't even provide any of the types mentioned in the original proposal.