2012/1/7 Henrik Sperre Johansen <henrik.s.johansen@veloxit.no>:
On 07.01.2012 14:05, Henrik Sperre Johansen wrote:
On 07.01.2012 13:20, Stéphane Ducasse wrote:
sounds like :)
Stef
On Jan 7, 2012, at 1:10 PM, Mariano Martinez Peck wrote:
FSReadStream>>  next: count   | result |   result := ByteArray new: count.   handle at: position read: result startingAt: 1 count: count.   position := position + 1.    ^ result
shouldn't be
FSReadStream>>  next: count   | result |   result := ByteArray new: count.   handle at: position read: result startingAt: 1 count: count.   position := position + count.    ^ result
At least with that (among some extensions) Fuel tests pass with FS :)
Cheers
-- Mariano http://marianopeck.wordpress.com
Still wrong though, I think... It doesn't handle the case where you try to read past end of stream.
next: count ^self nextInto: (ByteArray new: count)
would probably be better.
Cheers, Henry
As for the API:
1) There's no next: into: (which returns the amount read). It's really the only way to do buffers without garbage allocations. 2) FSHandle >>at: offset read: buffer startingAt: start count: count is a weirdly named selector for what it does imho... Doesn't #at: offset read: count into: buffer startingAt: start  make more sense?
Sure. But without reading source code I also wonder why mixing two operations into a single ? I mean seek() and read() Since the underlying OS handle is most probably a stream, it should preserve its own position. Is it because the handle might be shared and FS thus has to provide some kind of atomic operation ? Nicolas
Cheers, Henry