Week 47/2012: Refactoring
skyjake's notes:
Last week we made progress toward the next-generation engine architecture.
We are on the verge of the 1.9.10 candidate phase and are now pushing the final disruptive changes into the master branch. The week has been focused around the file system and the core data structures the engine uses (or will use) for organizing runtime data.
Discussions about where the engine's internal file system needs to be headed have progressed and we now have reached a better common understanding. While we can't yet fully integrate the libdeng2 file system into the engine, the same core components are gradually being incorporated onto both sides of the fence (legacy engine file system vs. the libdeng2 file system).
I did some major refactoring tasks to extract generic functionality out of special-purposes classes so that the former can be used elsewhere as well. This sort of work is good in the long term as it makes it easier to compose complex functionality out of simple, common building blocks.
From the looks of it 1.9.10 will be the largest step yet toward the Doomsday 2 architecture, but the changes are mostly under the hood. I'm quite happy with how this is positioning us for next year and even more aggressive progress.
This week I'm going over the roadmap and putting finishing touches on the nearly-done items.
danij's notes:
Last week my time was split between file system and resource management refactoring.
The week began with some important reassessment of the division between logical files and resources, in both the 2.0 architecture and the existing file system. From these discussions I effected a series of refactorings to the existing file system intended to crystallize this division; re-imagining resource namespaces as file system subspace domains and merging the old resource location logic into the file system.
After which I then turned my attention to cleaning up and updating the myriad bookkeeping systems for resource management. This code is now some of the oldest and crustiest in our codebase (some of these files had not seen a significant commit in five years or more). This work is ongoing but should be in a merge-able state in the next day or two.
This week I plan to return to my efficient-gridmap branch to see if I can ready this optimization in time for the 1.9.10 release.
Last week we made progress toward the next-generation engine architecture.
We are on the verge of the 1.9.10 candidate phase and are now pushing the final disruptive changes into the master branch. The week has been focused around the file system and the core data structures the engine uses (or will use) for organizing runtime data.
Discussions about where the engine's internal file system needs to be headed have progressed and we now have reached a better common understanding. While we can't yet fully integrate the libdeng2 file system into the engine, the same core components are gradually being incorporated onto both sides of the fence (legacy engine file system vs. the libdeng2 file system).
I did some major refactoring tasks to extract generic functionality out of special-purposes classes so that the former can be used elsewhere as well. This sort of work is good in the long term as it makes it easier to compose complex functionality out of simple, common building blocks.
From the looks of it 1.9.10 will be the largest step yet toward the Doomsday 2 architecture, but the changes are mostly under the hood. I'm quite happy with how this is positioning us for next year and even more aggressive progress.
This week I'm going over the roadmap and putting finishing touches on the nearly-done items.
danij's notes:
Last week my time was split between file system and resource management refactoring.
The week began with some important reassessment of the division between logical files and resources, in both the 2.0 architecture and the existing file system. From these discussions I effected a series of refactorings to the existing file system intended to crystallize this division; re-imagining resource namespaces as file system subspace domains and merging the old resource location logic into the file system.
After which I then turned my attention to cleaning up and updating the myriad bookkeeping systems for resource management. This code is now some of the oldest and crustiest in our codebase (some of these files had not seen a significant commit in five years or more). This work is ongoing but should be in a merge-able state in the next day or two.
This week I plan to return to my efficient-gridmap branch to see if I can ready this optimization in time for the 1.9.10 release.