Thanks Sean,
This certainly fixed it.

In a rush of irrational optimism, I also added a JFileChooser dialog to
allow me to avoid the ugliness of the hard coded solution. Of course, as
soon as did this the Log was no longer backwards compatible with the
serialised version in the checkpoint file! 

Mea Culpa.

Shane Magrath

-----Original Message-----
From: ECJ Evolutionary Computation Toolkit
[mailto:[log in to unmask]] On Behalf Of Sean Luke
Sent: Monday, 20 August 2007 12:11 PM
To: [log in to unmask]
Subject: Re: Problem with restoring a checkpoint...

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

IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914.  If you have received this email in error, you are requested to contact the sender and delete the email.