On May 30, 2010, at 2:18 AM, Daniel Rothman wrote:
> sounds good - as I've been working through the code I haven't seen
> it used
> an awful lot.
> If this chunk of the code is on the table, any thought to using the
> logging facility (in java.util) for system-focused logging, rather
> than domain-
> focused reporting and progress monitoring?
I considered it but have for now rejected it for now. Two reasons.
First, Java's logging facility doesn't actually do the same thing as
ECJ's: it can't store messages in memory and re-emit them. And the
Java's logger is a one-log-per-class thing which doesn't do the
job. :-( But second, the refactoring would be gigantic and would
break everyone's code in a way that would be challenging to rewrite
for. I'm okay with breaking code, but not for adding a major burden.
When Java came out with its logger I was a bit disappointed in it.
But that was many moons ago. Another option would be to sit
ec.util.Output on top of Java logging. I'm not sure if that would do
anything of relevance though.
[btw: Not sure what you mean by "domain-focused"... ec.util.Output is
entirely independent of ECJ. Not saying it's not creaky...]
> I'd like to see/work on some more general instrumentation though. The
> statistics and fitness classes could use some generalization. I'm
> that trying to build in deeper instrumentation is requiring tweaks to
> fundamental classes (like Problem classes, Individual and Population
> classes...). There aren't a lot of hooks for things like Observer
No there aren't, mostly because of speed concerns. Most observation
stuff is handled by Statistics. But I don't think this stuff should
be too hard to add in a clean and useful way. Get with me and let's
think about how we can add it.