Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@www.apache.org Received: (qmail 69054 invoked from network); 9 Jan 2004 05:12:05 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 9 Jan 2004 05:12:05 -0000 Received: (qmail 79009 invoked by uid 500); 9 Jan 2004 05:11:41 -0000 Delivered-To: apmail-jakarta-commons-dev-archive@jakarta.apache.org Received: (qmail 78983 invoked by uid 500); 9 Jan 2004 05:11:41 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 78969 invoked from network); 9 Jan 2004 05:11:41 -0000 Received: from unknown (HELO latte.harvard.edu) (140.247.210.252) by daedalus.apache.org with SMTP; 9 Jan 2004 05:11:41 -0000 Received: from latte.harvard.edu (207-172-79-45.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com [::ffff:207.172.79.45]) (AUTH: PLAIN mdiggory, ) by latte.harvard.edu with esmtp; Fri, 09 Jan 2004 00:11:50 -0500 Message-ID: <3FFE3957.9070109@latte.harvard.edu> Date: Fri, 09 Jan 2004 00:17:11 -0500 From: "Mark R. Diggory" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; rv:1.6a) Gecko/20031030 X-Accept-Language: en-us, en, zh, zh-cn, zh-hk, zh-sg, zh-tw MIME-Version: 1.0 To: Jakarta Commons Developers List Subject: Re: [math] Bug fixes References: <20040108142253.35289.qmail@web41301.mail.yahoo.com> <3FFD749A.5030609@steitz.com> <3FFD7F25.4060605@latte.harvard.edu> <3FFD811B.8040409@latte.harvard.edu> <3FFE1201.6080202@steitz.com> In-Reply-To: <3FFE1201.6080202@steitz.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N 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. > > >> 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