From: Andrew Cristina
Subject: Random Access File IO question
Date: 
Message-ID: <pan.2004.05.08.17.53.17.328000@cox.net>
Hello,

I would like to know if Common Lisp actually supports random access files,
or if it just "fakes" them using streams.  I.e., if I call file-position
stream 32000) will that read all of the bytes upto 32000, or will it try
to move to the block containing 32000, and set the position that way?  

The reason I ask is that I'm working on a B-tree (for a class), and it
seems that having to scan through a file to get to a certain offset will
kill the B-tree's only real benefit.  

I have a strong feeling that this is implementation dependent, so I'll
mention that I'm pretty much constrained to cmucl.  If it turns out that
cmucl doesn't work as I'd really like, and another implementation does,
please feel free to let me know as well.  

Anyway, thanks for any help.

Andy

From: Barry Margolin
Subject: Re: Random Access File IO question
Date: 
Message-ID: <barmar-AE10D5.14394608052004@comcast.ash.giganews.com>
In article <······························@cox.net>,
 Andrew Cristina <········@cox.net> wrote:

> Hello,
> 
> I would like to know if Common Lisp actually supports random access files,
> or if it just "fakes" them using streams.  I.e., if I call file-position
> stream 32000) will that read all of the bytes upto 32000, or will it try
> to move to the block containing 32000, and set the position that way?  
> 
> The reason I ask is that I'm working on a B-tree (for a class), and it
> seems that having to scan through a file to get to a certain offset will
> kill the B-tree's only real benefit.  
> 
> I have a strong feeling that this is implementation dependent, so I'll
> mention that I'm pretty much constrained to cmucl.  If it turns out that
> cmucl doesn't work as I'd really like, and another implementation does,
> please feel free to let me know as well.  

As long as the operating system's file system interface provides a way 
to perform random access, I can't imagine a high-quality implementation 
not using it.

There's also nothing in the spec that says that arithmetic operations 
should use the hardware's built-in arithmetic opcodes.

-- 
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
From: Johannes Groedem
Subject: Re: Random Access File IO question
Date: 
Message-ID: <lzekpuycqw.fsf@unity.copyleft.no>
* Andrew Cristina <········@cox.net>:

> I would like to know if Common Lisp actually supports random access
> files, or if it just "fakes" them using streams.  I.e., if I call
> file-position stream 32000) will that read all of the bytes upto
> 32000, or will it try to move to the block containing 32000, and set
> the position that way?

I'm assuming that it's common for implementations to use lseek (or
whatever underlying operating system primitive is available for this
purpose), at least for streams with fixed-width elements, such as
byte-streams.  (I imagine that if your Lisp supports UTF-8 character
streams, you want to seek to a specific character, not a specific byte
in the stream, for example.)

> I have a strong feeling that this is implementation dependent, so
> I'll mention that I'm pretty much constrained to cmucl.  If it turns
> out that cmucl doesn't work as I'd really like, and another
> implementation does, please feel free to let me know as well.

CMUCL uses lseek to seek in files, so this should work fine for you.

(By the way, SLIME is nice for navigating Lisp-source, including the
CMUCL source.  Oh, and that's not all it is good for, either.)

See http://www.cliki.net/SLIME .

-- 
Johannes Gr�dem <OpenPGP: 5055654C>
From: Andrew Cristina
Subject: Re: Random Access File IO question
Date: 
Message-ID: <pan.2004.05.08.18.53.02.184000@cox.net>
On Sat, 08 May 2004 20:50:31 +0200, Johannes Groedem wrote:

> CMUCL uses lseek to seek in files, so this should work fine for you.
> 
> (By the way, SLIME is nice for navigating Lisp-source, including the
> CMUCL source.  Oh, and that's not all it is good for, either.)
> 
> See http://www.cliki.net/SLIME .

Thanks to both of you.  I should have thought to check the source, and in
the future, I probably will think to do that.  Google made me lazy :-)

Andy