Week 48/2012: Loose ends and Config

skyjake

skyjake's notes:

Last week I was tying up loose ends in preparation for the impending candidate phase, and did a lot of progress with Doomsday Script.

Tying loose ends:

• Fixing regressions due to recent changes (e.g., UnixInfo paths, reading saved .cfg). If you've noticed that your settings aren't being saved, this should now be fixed.
• FluidSynth on Linux: music volume control is now applied correctly, making it possible to use FluidSynth for audio output on its own (e.g., SDL_mixer + FluidSynth).
• The fixed-precision collision tests are not used with the player any more, only non-player mobjs. This will hopefully prevent the player from getting stuck in tight spaces.
• Continued code reorganization and moving to shared libraries (vector math, etc.).

Before the candidate phase locks in, I took the opportunity to push in a few significant improvements to libdeng2. My goal was to start integrating Doomsday and the new libdeng2 script engine, and start building some of the infrastructure for scripting.

• Cleaner log output by abbreviating parts of the messages. (Mostly helpful for developers, debugging.)
• Fixed a bug when writing ZIP archives.
• Doomsday Script: added "export" statement and keyword.
• Doomsday Script: number values can be marked with a 'boolean' flag so they appear as boolean True and False.
• Doomsday Script: fixed a bunch of parser bugs.
• Added "/home/persist.pack" for storing the application's persistent data into. The future equivalent of console variables (de::Config) is stored here.
• Doomsday Script: added TimeValue for manipulating time in expressions.
• Doomsday Script: added Record(), a built-in function to make copies of Records.
• Switched the automatic updater and window manager to use de::Config for settings.
• Replaced the "/config" folder with "/modules".
• Renamed deng.de to Config.de (sets up the Config namespace with default values).
• Created the first module of the Doomsday Script Standard Library: recutil.de.

This week we're going to start the candidate phase for 1.9.10. In practice this means that once again we'll try to put the long-term, big tasks aside for a while and focus on bug fixing and polishing.

gary

I remember the following mentioned before, but I kind of forgot what it means when a new build is uploaded and it says 'issues' and then lists the number of issues with the number itself contained inside a red or yellow box (border). Does it mean that the build itself is extremely buggy? If it is in a red box, then the build may not even be clickable, therefore not downloadable. I remember Dani saying it had to do with the number of issues with uploading the new build, but that doesn't make sense and I couldn't see how that would affect anyone downloading it. Maybe I misunderstood and it means the number of 'critical' issues in the new build itself and not the uploading process itself, like fatal bugs or show stoppers in the build.

skyjake

Does it mean that the build itself is extremely buggy?

Unstable builds should always be considered potentially buggy. The yellow issue counter means that the code has compiler warnings -- there's code that the compiler thinks is a little ambiguous or potentially faulty. More often than not it just means the code is a little messy and needs to be cleaned up.

So the issue count is not directly related to bugs or 'critical' issues or the stable to-do list; they measure the quality of the source code.