On Week 38
skyjake:
Last week I pushed the qmake build update to the master branch, which had some negative side-effects on the quality of the unstable builds. Build 266 was not working so well on all platforms, but it seems that today's build 269 fares a little better: at least it works for me on 32-bit Windows, various Macs, and Ubuntu. I've yet to try it on 64-bit Windows, but will do so in the near future. However, there's a number of issues to clear up, the least of which is not the Qt Creator debugging situation in Windows, so the old build files will remain in the repository for now.
Judging by last week's events it's pretty clear that introducing qmake and Qt to Doomsday will have a price. Team members (and others who want to deal with the source) will have to figure out how they want to do their daily development. Qt Creator is hands down the best option on Linux and Mac, but the life of portable open source software is never easy on Windows... Microsoft's native debugger seems somewhat incompatible with Qt Creator at the moment, so we may have to seriously look into gcc-based Windows builds, or some kind of MSVC-based solution. I'll spend some time investigating how Qt Creator is working on different versions of Windows to see if there is a reliable debugging setup out there.
My plan for this week is to clean up the remaining loose ends in the master branch. Currently I've closed the multiplayer servers for some system maintenance and upgrading, but they should be back online later in the week.
danij:
This week I completed the current series of filesystem refactorings I have been working on to reposition the functionality of DFILE. I ultimately settled on re-purposing DFILE into our new abstract public file handle, now named DFile.
All file objects in the vfs are now constructed from two core components named AbstractFile and DFile. Each AbstractFile instance owns an instance of DFile, used internally by AbstractFile specializations WadFile, ZipFile and the abstract LumpFile. References to AbstractFile-derived objects are implemented using additional, public DFile instances which internally implement a referencing mechanic(allowing for multiple concurrent handles on a single file).
In the process I encountered a few issues with other parts of the filesystem (in particular the way file-access testing was implemented via F_Open) which have too been refactored into a cleaner design.
The filesystem object hierarchy is now ready for me to move on to the next bout of refactoring. The aim of which being the reduction of unnecessary buffering/caching of file/lump data and the implementing of a generic file reference counting mechanism in DFile. Once this reference counting is in place I'll then be able to complete the implementation of the LumpCache component I've mentioned in previous updates.
Hopefully I'll be able to finish this stuff up over the coming week so I can then address the remaining resource management regressions in the ringzero branch(es).
Last week I pushed the qmake build update to the master branch, which had some negative side-effects on the quality of the unstable builds. Build 266 was not working so well on all platforms, but it seems that today's build 269 fares a little better: at least it works for me on 32-bit Windows, various Macs, and Ubuntu. I've yet to try it on 64-bit Windows, but will do so in the near future. However, there's a number of issues to clear up, the least of which is not the Qt Creator debugging situation in Windows, so the old build files will remain in the repository for now.
Judging by last week's events it's pretty clear that introducing qmake and Qt to Doomsday will have a price. Team members (and others who want to deal with the source) will have to figure out how they want to do their daily development. Qt Creator is hands down the best option on Linux and Mac, but the life of portable open source software is never easy on Windows... Microsoft's native debugger seems somewhat incompatible with Qt Creator at the moment, so we may have to seriously look into gcc-based Windows builds, or some kind of MSVC-based solution. I'll spend some time investigating how Qt Creator is working on different versions of Windows to see if there is a reliable debugging setup out there.
My plan for this week is to clean up the remaining loose ends in the master branch. Currently I've closed the multiplayer servers for some system maintenance and upgrading, but they should be back online later in the week.
danij:
This week I completed the current series of filesystem refactorings I have been working on to reposition the functionality of DFILE. I ultimately settled on re-purposing DFILE into our new abstract public file handle, now named DFile.
All file objects in the vfs are now constructed from two core components named AbstractFile and DFile. Each AbstractFile instance owns an instance of DFile, used internally by AbstractFile specializations WadFile, ZipFile and the abstract LumpFile. References to AbstractFile-derived objects are implemented using additional, public DFile instances which internally implement a referencing mechanic(allowing for multiple concurrent handles on a single file).
In the process I encountered a few issues with other parts of the filesystem (in particular the way file-access testing was implemented via F_Open) which have too been refactored into a cleaner design.
The filesystem object hierarchy is now ready for me to move on to the next bout of refactoring. The aim of which being the reduction of unnecessary buffering/caching of file/lump data and the implementing of a generic file reference counting mechanism in DFile. Once this reference counting is in place I'll then be able to complete the implementation of the LumpCache component I've mentioned in previous updates.
Hopefully I'll be able to finish this stuff up over the coming week so I can then address the remaining resource management regressions in the ringzero branch(es).