Blogs

#parrotsketch report for this week:
# Worked mostly on the decTest parser.
# Parsing is basically done.
# Code emitting is mostly done as well.
# The support library still needs some additions.
# Integration into the testing infrastructure is pending.
# DecInt is the new priority.
# Have some preliminary work. Nothing commitable yet.

Nobody complained last week, so here's my #parrotsketch report for this week:
* Completed the GSoC midterm student survey.
* Still ~1 week behind schedule.
* Started cleaning the build system. Moved stuff around, removed a Makefile.
* Made the build procedure work for people on setups saner than mine :)
* Cleaned up the 'test' target a bit.
* We're still failing tests. But I found out why.
* Turned out the failures are coming out of the decNumber library and not the PMCs.

RL has been getting in the way of the schedule lately, I've fallen a week behind schedule, and the blogging has been sporadic. So I'm taking advantage of the new #parrotsketch format to kill two birds with one stone: I report to the blog, ensuring at least weekly posting and just post a link to it on IRC, allowing people who don't care about it to just skip it, and people who care to get the information in a more reachable place than the irc backlog.

A bit late, as Week 3 of the Summer of Code ended some days ago, but progress was made so I'll report it. This weeks the DecNum PMC got the last few VTABLEs and METHODs necessary to reach the feature level of the Parrot Big* PMCs. Some tests got written and the test conversion was starting to move forward when I went down with a case of acute bronchitis.

Week 1 of the Summer of Code has just ended, this week the DecNum PMC advanced some more on the road to completion. It now has most of the VTABLEs implemented by the parrot BigNum and should be usable when mixed with Integers, Numbers, and any other PMC with a get_number() VTABLE.

The community bonding period is over, that means that the actual Summer of Code begins now. Did I bond enough? Will I get paid? Have I already failed and not noticed? Will the bloody fedex package ever leave Memphis? Only the future can tell, but I'll take the chance to give a sketch of the current project status and what has changed from the original plans.

I've mentioned before that I was prototyping two different approaches to handling the operating context for the decnum-dynpmcs. Here are some results of the prototyping and some explanations of the choices made.

In my last status report I mentioned a prototype for DecNums with a unique global context. The easiest way to implement global data as parrot PMCs is by using a 'singleton' PMC, so that is what I set out to do: a DecContext singleton dynpmc. Doing it was simple enough once I figured out what the creation mechanism was. There is one problem, however, once you know the mechanism you know its potential for abuse. This post is about what singletons should be, what they shouldn't be, and what I think should be done about it.

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.

This is the first in a series of posts about "decnum-dynpmcs" the Google Summer of Code project I'll be developing. The project's aim is to create a set of dynpmcs implementing arbitrary-precision decimal arithmetic data-types based on IBM's decNumber library.

Today I'll give you an introduction to the problems arbitrary-precision decimal arithmetic solves, and the ways in which you can explode if you don't use it.