Print

Print


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  
> java
> 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  
> discovering
> 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  
> patterns...

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.

Sean