fibre~thread

A problem: given an object a of class A that aggregates a publicly accessible instance of class B determine if an instance changed by polling periodically. This comes up often in concurrent systems where an object change warrants a response while KVO is undesirable. The first thought that comes to mind is to a cache the instance of B during each cycle of polling after the comparison of the cached instance to the present value.

Our code might look like this

Unfortunately this fails miserable due to the fact that a newly allocated instance of B may occupy the same memory location as the previous one (assuming, of course, that we never retain the cached value). This is a low probability failure and is extremely hard to debug. This bug is solved by storing a timestamp upon change of instance of B inside a, and cacheing it instead of the memory address.

At last releasing SymbicLogKit. The kit is a simple logging/tracing framework polarized toward desktop (vs. server) development; an itch I’ve needed to scratch for quiet some time. I can already hear a poignant skeptic say that printf and NSLog do the job just fine, and that availability of other solutions such as Log4Coocoa and ASL (Apple System Logging) adds the insult to an injury.

I was not entirely happy with the existing solutions and the following points and decided to build my own framework.

• Tracing/logging/debugging code often serves a purpose long after its initial purpose, so it shouldn’t be removed much of the time following a debugging session. Instead logging code should be well thought out as to provide a developer with useful info in the future.
• If the above statement is accepted then we need a means of selectively blocking/enabling tracing code based on origin, level, thread, and other parameters. Without the ability to select what gets through we’ll simply get lost in the overly verbose output.
• Enabling/disabling parts of output should be snappy and should be done at runtime.
• A developer may want to do more useful things than printf with tracing output, so the output should be structured.
• The framework should be UI centric, nice to look at, and should be easy to include and take advantage of in desktop applications.

The core of the framework is a singleton class called SYLogger. The instance of this class allows a user to add objects conforming to SYLoggerChannel protocol. Such objects are essentially output channels for a logger instance. There are two such objects provided by the framework: SYConsoleView and NSLoggingChannel.

SYConsoleView is an NSView that can be embedded into your application much the same way as any NSView subclass. The view is a tabular console for your output. On the other hand NSLoggingChannel is a simplistic channel that forwards your output to NSLog(...) call having formatted it nicely.

In order to make use of the framework the channels must be added to SYLogger instance. Messages are sent to the logger by invoking one of the following macros. There are 4 debugging levels defined at the moment (Debug, Info, Warning, Error) each assigning an immediacy level to a message. The variadic macros take NSString*s as parameters, the first being a format string (think [NSString stringWithFormat:...]).

There’s also an SYConfiguratorView which enables a user (a developer typically) to configure the logger. By configure I mean to provide a list of class-selector-level tripples describing which output should be blocked. The control is nothing more than a table with the first column hosting an ICU regular expression for class-name, the second hosting an ICU regular expression for selector-name (e.g. “dictionaryWithObjects:forKeys:count:”, “array”, etc.).

The above screenshot, for example, represents a configuration that blocks output from within drawRect: selectors of all classes whose names end in “View” as well as from all selectors whose name begins in “run” irrespective of a class they belong to.