Bryce Lelbach wrote:
There's a lot of room in the grammar for refactoring; some of the productions in the grammar are now deprecated in the XML standard (in favor of less annoying rules).
However, I really don't want to refactor the XML grammar half-heartedly. Currently, the grammar works perfectly, and the tests should reflect that.
Smart move - one battle at a time.
If my schedule is freed up a bit in the future (I have recently taken on and am currently working on something of an ambitious scope), I would implement the following changes to Serialization archives:
* Rewrite all the existing archives using Spirit 2.x (Karma for output archives, Qi for input archives). * Create a new interface, allowing users to write new archive types using Qi and Karma.
A more interesting task would be to make karma/qi archive. Using the serialization interface, one could generate the karma/qi code that would implement a text editor for the created archive.
I could make it work better and perform faster at runtime and compile time, but the best way to do that would involve ripping up a lot of the existing archive internals.
As I remember, aside from creating the grammer, there was hardly any code to write so I'm not sure what archive internals refers to. In any case, I'm please that someone has taken responsability for this. This same set of problems - compiler quirks, stack overflows at compile time, etc ocurred with the original version. These were handled by a few minor re-factorings in the grammer. The original grammer was derived from Dan Nuffers XML grammer which was part of the original spirit package.
I'll contact the test runner. IMHO, timeouts should not have a fixed value; instead, new tests should not timeout at all on their first run, but the time they take to run should be recorded. The runtime duration of each run after the first should also be recorded. This would allow a range of predicted durations to be computed, and the high value in that range should be used to compute a timeout duration. This would also be helpful because it could show Boost TMP maintainers how changes in their libraries affect compile times.
It looks to me that this time overflow should only occur during the build of the library - a one time thing. That is, it wouldn't have to be increased for each test. Robert Ramey