I just checked in a change that makes the component tests in samples go much faster related to logging. Logging is a bit of a mess right now, I don't want to change things too much going into release but I would like to make some changes soon after.
Current logging issues: 1. API/syntax is a bit weird. (For example there is a debug() method but you can't really set any state other than on/off, there are no distinct levels) 2. A lot of places in code generate a string to log even when logging is turned off. There is a check you can make but it is only loosely tied to whether debug log is on or off. That check is also kind of ugly. 3. The log window being a separate window is annoying and has some weird browser issues sometimes like the log window stealing the address of the main window after you close the main window. Here is what I would like to do: 1. Set up logging similar to log4j including appenders that can write to different destinations. (As similar as possible given perf/time constraints - most of it should be transferable but I have to read up a bit more on the log level inheritance between loggers and sub-loggers) 2. Allow logging to a div onscreen rather than a separate browser window through the use of an appender that will by default do that, and get rid of the browser window appender or at least make it not the default. 3. Clean up a lot of the log usage - the message texts themselves, be more careful about log names, etc. Logging is quite an annoyance right now as it often just gets in the way and is often a perf hit. There have already been a number of times where a performance issue turned out to be a something written to the log. In the component tests case there were some buttons that would react instantly when you pressed them and others that took over a second to respond, the only difference being a slightly different workflow that hit some extra log statements that always ran regardless of log settings. James Margaris
