commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark R. Diggory" <mdigg...@latte.harvard.edu>
Subject Re: [math] Bug fixes
Date Fri, 09 Jan 2004 05:17:11 GMT


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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message