I burned the first half of the day reviewing a bunch of legal stuff that I need for the business -- the EULA, privacy policy, website terms, etc. This has to be the least exciting part of the whole project, and as much as I'd like to just skip it, if there's any chance that the product will be even moderately successful I really do need this stuff. Fortunately, the lawyer I hired specializes in small tech businesses, so he understood what I am doing super-quickly. Hopefully in another week or so I'll have final documents and won't have to use any further brain cells on legal matters.

Code-wise, I finally just got fed up with boost::numeric::interval and wrote my own. The frustrating thing is that I started with my own Interval class, and when I saw there was a Boost one I figured, "why not use it?" I needed a few of the handy methods it had (hull, median, etc) and figured it was a great implementation.

WRONG. The API is fine, but the implementation is vastly over-complex and it is incredibly difficult to understand what conditions it will throw exceptions under. For example, for my PrecisionSlider implementation, an interval where the lower and upper bound are the same (a "singleton") is used to represent a slider that displays a single point, not a range. (Duh.) This works fine most of the time, but some of the GUI fuzz tests were failing under rare/obscure cases where the boost library would throw a "not supposed to be a singleton" exception.

I looked into how to disable that, and what caused it in the first place, and... dear lord the code is horrible. After 10 minutes of noodling on whether I needed the policy "checking_no_nan<>" (which allows nan) or "checking_catch_nan<>" (which throws nan, i.e. the opposite of catching it), I threw the whole library in the incinerator and burned it.

Now I have a 25-line Interval class again that does exactly what I need and can be understood by a 6 year old. Sigh...