ECJ-INTEREST-L Archives

August 2007

ECJ-INTEREST-L@LISTSERV.GMU.EDU

Options: Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Sender:
ECJ Evolutionary Computation Toolkit <[log in to unmask]>
Date:
Sun, 19 Aug 2007 22:40:37 -0400
MIME-version:
1.0 (Apple Message framework v752.3)
Reply-To:
ECJ Evolutionary Computation Toolkit <[log in to unmask]>
Content-type:
text/plain; charset=US-ASCII; delsp=yes; format=flowed
Subject:
From:
Sean Luke <[log in to unmask]>
In-Reply-To:
Content-transfer-encoding:
7bit
Comments:
To: ECJ Evolutionary Computation Toolkit <[log in to unmask]>
Parts/Attachments:
text/plain (75 lines)
On Aug 19, 2007, at 8:49 PM, Magrath, Shane wrote:

> I'm having a problem loading a checkpoint file that was produced on  
> a different system (Vista in this case).
> The issue is caused because the log file is required to be located  
> in **exactly** the same position in the directory tree, which under  
> Vista is different to XP.
> Viz,
> XP:    C:\Documents and Settings\Shane\My Documents\Java\ECJ\dist 
> \pop.stat
> Vista: C:\Users\Shane\Documents\dist\pop.stat
>
> I imagine thsi problem would also exist when sharing checkpoints  
> across other OSs as well, eg MAC and Linux...
>
> Error Message:
> STARTUP ERROR:
> An IO Exception was generated uponstarting up, probably in setting  
> up a log
> Here it is:
> java.io.FileNotFoundException: C:\Users\Shane\Documents\dist 
> \pop.stat (The system cannot find the path specified)

Interesting problem.  So a quick explanation of how the Output  
facility works.  Output basically maintains a collection of Logs.  A  
Log is an abstract wrapper around, typically, a PrintWriter.  Logs  
don't receive streams of data -- they receive String messages via the  
print, fatal, warning, or error functions in Output.  Logs can  
restart themselves after recovery from checkpoint, and they can keep  
everything in memory so as to spit out messages to the files when  
recovering from checkpoint.  This funkiness harkens back to 1998,  
when Java 1.1 had terrible logging facilities.  It's an obvious place  
to do cleanup in ECJ nowadays, but it works and is stable and so I  
tend to leave it be.

When ECJ recovers from checkpoint, it rebuilds its Logs and then it  
calls restart() on each of them.  The default operation of the restart 
() method is for the Log to all restart(this) on its LogRestarter, an  
abstract object whose job is to start the Log up again.  Different  
restarters know how to start up different kinds of logs (writing to  
Stdout, being gzipped, etc.).  See the ec/util/Log.java file for how  
this is done.

In your case, you're writing to pop.stat file, which is a non-gzipped  
ordinary file.  The LogRestarter is created by the Log on line 142 of  
Log.java for this kind of file.  Notice that the restart(Log) method  
in the LogRestarter does this:

	l.writer = new PrintWriter(new BufferedWriter(
		new FileWriter(l.filename.getPath(),l.appendOnRestart)));

What's getting locked into that LogRestarter is l.filename, which is  
what you want to change.  So here's what I recommend doing.  Go into  
Log.java and modify restart() to detect which Log is throwing an  
exception and hard-code the file from there, something crazy like this:


     public Log restart() throws IOException
         {
	try { return restarter.restart(this); }
	catch (FileNotFoundException e)
		{
		writer = new PrintWriter(new BufferedWriter(
			new FileWriter(new File(
				"C:\Users\Shane\whateverTheNewPathIs\pop.stat").getPath(),
				appendOnRestart)));
		return this;
		}
         }

Something like that.  You get the idea.  You're hard-coding setting  
up the log on restart.  This should do the trick (crosses fingers).

Sean

ATOM RSS1 RSS2