Phil Steitz wrote:
Mark R. Diggory wrote:
Sorry, that may have be a bit naive. More specifically, I know that open/closeReplay file reloads the values file inputstream. I suspect that these are only used in one other location in the ValueServer. Maybe they should be private or consolidated into the getNExtReplay method.
Yes. Open should not be public. What would make sense is a reset() method. The file needs to remain open across calls to getNextReplay(), since REPLAY_MODE amounts to cycling through the "replay file" in sequence repeatedly. Since the file might be large, it is not loaded into memory. This creates the awkward situation of the user needing to close the file, which is why close() needs to be public.
sounds good.
<snip/>
Mark R. Diggory wrote:
Yes, I agree too, although it would be beneficial to maintain so convenience methods that allow one to set the source of the streams to be a File or other often used objects.
Ack. My initial thought is to add another load() to EmpiricalDistribution that takes a URI and modify internals of impls to not use URL.toFile() (which apparently does not work reliably on Windows).
Why not use URL.openStream() and wrap it in an InputStreamReader? Then the stream can generically come from any resource reachable by URL (ie, a file in the filesystem, in a jar, or as a resource on the classpath, http, ftp, etc).
public void openReplayFile() throws IOException {
filePointer = new BufferedReader(
new java.io.InputStreamReader(
valuesFileURL.openStream()
)
);
}Besides, URL.getFile() returns the string representation of the path plus the query in the URL. If the URL doesn't represent a File, this code will break if handed any other protocol.
-M.
-- Mark Diggory Software Developer Harvard MIT Data Center http://osprey.hmdc.harvard.edu
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
