Hi,

At Limor's suggestion (and that of others), I'm in the process of
adding file seek() to the SD library. This raised lots of other
questions, however, which I'd like your opinions on.

One question is which modes to support opening a file in. The current
options don't really work well with the seek() command. I now think
we can get away with just two modes: FILE_READ and FILE_WRITE. The
former (the default), would not support writing, would signal an error
if the file didn't exist (via bool() operator), and would place the
cursor at the start of the file. The latter would create the file if
it didn't exist, and place the cursor at the end of the file. In
either case, you could seek elsewhere in the file.

The current FILE_APPEND mode automatically seeks to the end before
writing new data. With FILE_WRITE, instead, I propose that if you
called seek() to move away from the end of the file, you'd have to
seek back to the end if that's where you wanted to write.

The current FILE_TRUNCATE mode automatically truncates the file on
opening. Instead, I propose that you'd need to explicitly call a new
truncate() function to do this; it would also you to truncate the file
from other positions. If we think this is a common use case
(remember, you can also delete a file through SD.remove()), we could
add FILE_REWRITE (or similar) in addition to FILE_READ and FILE_WRITE,
but it seems redundant with a truncate() function (and less flexible).

I'll also add size() to get the size of the file and position() to get
the current cursor position within the file.

Finally, I propose making sync mode the default; that is,
automatically physically saving written data to the SD card rather
than buffering it in RAM. If necessary for performance reasons, we
could add a buffer() function which would turn the buffering back on
and require explicit syncing when desired.

Thoughts?

David

_______________________________________________
___________________________________________________

Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.

Hi,

At Limor's suggestion (and that of others), I'm in the process of
adding file seek() to the SD library. This raised lots of other
questions, however, which I'd like your opinions on.

One question is which modes to support opening a file in. The current
options don't really work well with the seek() command. I now think
we can get away with just two modes: FILE_READ and FILE_WRITE. The
former (the default), would not support writing, would signal an error
if the file didn't exist (via bool() operator), and would place the
cursor at the start of the file. The latter would create the file if
it didn't exist, and place the cursor at the end of the file. In
either case, you could seek elsewhere in the file.

The current FILE_APPEND mode automatically seeks to the end before
writing new data. With FILE_WRITE, instead, I propose that if you
called seek() to move away from the end of the file, you'd have to
seek back to the end if that's where you wanted to write.

The current FILE_TRUNCATE mode automatically truncates the file on
opening. Instead, I propose that you'd need to explicitly call a new
truncate() function to do this; it would also you to truncate the file
from other positions. If we think this is a common use case
(remember, you can also delete a file through SD.remove()), we could
add FILE_REWRITE (or similar) in addition to FILE_READ and FILE_WRITE,
but it seems redundant with a truncate() function (and less flexible).

I'll also add size() to get the size of the file and position() to get
the current cursor position within the file.

Finally, I propose making sync mode the default; that is,
automatically physically saving written data to the SD card rather
than buffering it in RAM. If necessary for performance reasons, we
could add a buffer() function which would turn the buffering back on
and require explicit syncing when desired.

Thoughts?

David

_______________________________________________
___________________________________________________

Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe. On 12/22/2010 2:27 PM, David A. Mellis wrote:
> Hi,
>
> At Limor's suggestion (and that of others), I'm in the process of
> adding file seek() to the SD library. This raised lots of other
> questions, however, which I'd like your opinions on.
>
> One question is which modes to support opening a file in. The current
> options don't really work well with the seek() command. I now think
> we can get away with just two modes: FILE_READ and FILE_WRITE. The
> former (the default), would not support writing, would signal an error
> if the file didn't exist (via bool() operator), and would place the
> cursor at the start of the file. The latter would create the file if
> it didn't exist, and place the cursor at the end of the file. In
> either case, you could seek elsewhere in the file.
>
> The current FILE_APPEND mode automatically seeks to the end before
> writing new data. With FILE_WRITE, instead, I propose that if you
> called seek() to move away from the end of the file, you'd have to
> seek back to the end if that's where you wanted to write.

that is correct. i think most people will use seekSet() on reading, 99%
of writing operations we have seen in the wild have been datalogging -
strict append operation. but for reading i think its very valuable to be
able to rewind, or jump to a location.

> I'll also add size() to get the size of the file and position() to get
> the current cursor position within the file.

yes plz.

> Finally, I propose making sync mode the default; that is,
> automatically physically saving written data to the SD card rather
> than buffering it in RAM. If necessary for performance reasons, we
> could add a buffer() function which would turn the buffering back on
> and require explicit syncing when desired.

yes!

i do suggest calling seek seekSet() or positionSet() just to avoid any
confusion with the 'classic' seek() which takes an additional argument.
its totally not a big deal tho.

_______________________________________________
___________________________________________________

Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.

Hi,

At Limor's suggestion (and that of others), I'm in the process of
adding file seek() to the SD library. This raised lots of other
questions, however, which I'd like your opinions on.

One question is which modes to support opening a file in. The current
options don't really work well with the seek() command. I now think
we can get away with just two modes: FILE_READ and FILE_WRITE. The
former (the default), would not support writing, would signal an error
if the file didn't exist (via bool() operator), and would place the
cursor at the start of the file. The latter would create the file if
it didn't exist, and place the cursor at the end of the file. In
either case, you could seek elsewhere in the file.

The current FILE_APPEND mode automatically seeks to the end before
writing new data. With FILE_WRITE, instead, I propose that if you
called seek() to move away from the end of the file, you'd have to
seek back to the end if that's where you wanted to write.

The current FILE_TRUNCATE mode automatically truncates the file on
opening. Instead, I propose that you'd need to explicitly call a new
truncate() function to do this; it would also you to truncate the file
from other positions. If we think this is a common use case
(remember, you can also delete a file through SD.remove()), we could
add FILE_REWRITE (or similar) in addition to FILE_READ and FILE_WRITE,
but it seems redundant with a truncate() function (and less flexible).

I'll also add size() to get the size of the file and position() to get
the current cursor position within the file.

Finally, I propose making sync mode the default; that is,
automatically physically saving written data to the SD card rather
than buffering it in RAM. If necessary for performance reasons, we
could add a buffer() function which would turn the buffering back on
and require explicit syncing when desired.

Thoughts?

David

_______________________________________________
___________________________________________________

Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe. On 12/22/2010 2:27 PM, David A. Mellis wrote:
> Hi,
>
> At Limor's suggestion (and that of others), I'm in the process of
> adding file seek() to the SD library. This raised lots of other
> questions, however, which I'd like your opinions on.
>
> One question is which modes to support opening a file in. The current
> options don't really work well with the seek() command. I now think
> we can get away with just two modes: FILE_READ and FILE_WRITE. The
> former (the default), would not support writing, would signal an error
> if the file didn't exist (via bool() operator), and would place the
> cursor at the start of the file. The latter would create the file if
> it didn't exist, and place the cursor at the end of the file. In
> either case, you could seek elsewhere in the file.
>
> The current FILE_APPEND mode automatically seeks to the end before
> writing new data. With FILE_WRITE, instead, I propose that if you
> called seek() to move away from the end of the file, you'd have to
> seek back to the end if that's where you wanted to write.

that is correct. i think most people will use seekSet() on reading, 99%
of writing operations we have seen in the wild have been datalogging -
strict append operation. but for reading i think its very valuable to be
able to rewind, or jump to a location.

> I'll also add size() to get the size of the file and position() to get
> the current cursor position within the file.

yes plz.

> Finally, I propose making sync mode the default; that is,
> automatically physically saving written data to the SD card rather
> than buffering it in RAM. If necessary for performance reasons, we
> could add a buffer() function which would turn the buffering back on
> and require explicit syncing when desired.

yes!

i do suggest calling seek seekSet() or positionSet() just to avoid any
confusion with the 'classic' seek() which takes an additional argument.
its totally not a big deal tho.

_______________________________________________
___________________________________________________

Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe. I'm all for all of these, but I'm not sure the difference between seekSet() which seems like an awkward name, and positionSet(), which seems clear?

t.

On Dec 22, 2010, at 2:33 PM, Limor wrote:

>
>
> On 12/22/2010 2:27 PM, David A. Mellis wrote:
>> Hi,
>>
>> At Limor's suggestion (and that of others), I'm in the process of
>> adding file seek() to the SD library. This raised lots of other
>> questions, however, which I'd like your opinions on.
>>
>> One question is which modes to support opening a file in. The current
>> options don't really work well with the seek() command. I now think
>> we can get away with just two modes: FILE_READ and FILE_WRITE. The
>> former (the default), would not support writing, would signal an error
>> if the file didn't exist (via bool() operator), and would place the
>> cursor at the start of the file. The latter would create the file if
>> it didn't exist, and place the cursor at the end of the file. In
>> either case, you could seek elsewhere in the file.
>>
>> The current FILE_APPEND mode automatically seeks to the end before
>> writing new data. With FILE_WRITE, instead, I propose that if you
>> called seek() to move away from the end of the file, you'd have to
>> seek back to the end if that's where you wanted to write.
>
> that is correct. i think most people will use seekSet() on reading, 99% of writing operations we have seen in the wild have been datalogging - strict append operation. but for reading i think its very valuable to be able to rewind, or jump to a location.
>
>> I'll also add size() to get the size of the file and position() to get
>> the current cursor position within the file.
>
> yes plz.
>
>> Finally, I propose making sync mode the default; that is,
>> automatically physically saving written data to the SD card rather
>> than buffering it in RAM. If necessary for performance reasons, we
>> could add a buffer() function which would turn the buffering back on
>> and require explicit syncing when desired.
>
> yes!
>
> i do suggest calling seek seekSet() or positionSet() just to avoid any confusion with the 'classic' seek() which takes an additional argument. its totally not a big deal tho.
>
> _______________________________________________
___________________________________________________

Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.

Hi,

At Limor's suggestion (and that of others), I'm in the process of
adding file seek() to the SD library. This raised lots of other
questions, however, which I'd like your opinions on.

One question is which modes to support opening a file in. The current
options don't really work well with the seek() command. I now think
we can get away with just two modes: FILE_READ and FILE_WRITE. The
former (the default), would not support writing, would signal an error
if the file didn't exist (via bool() operator), and would place the
cursor at the start of the file. The latter would create the file if
it didn't exist, and place the cursor at the end of the file. In
either case, you could seek elsewhere in the file.

The current FILE_APPEND mode automatically seeks to the end before
writing new data. With FILE_WRITE, instead, I propose that if you
called seek() to move away from the end of the file, you'd have to
seek back to the end if that's where you wanted to write.

The current FILE_TRUNCATE mode automatically truncates the file on
opening. Instead, I propose that you'd need to explicitly call a new
truncate() function to do this; it would also you to truncate the file
from other positions. If we think this is a common use case
(remember, you can also delete a file through SD.remove()), we could
add FILE_REWRITE (or similar) in addition to FILE_READ and FILE_WRITE,
but it seems redundant with a truncate() function (and less flexible).

I'll also add size() to get the size of the file and position() to get
the current cursor position within the file.

Finally, I propose making sync mode the default; that is,
automatically physically saving written data to the SD card rather
than buffering it in RAM. If necessary for performance reasons, we
could add a buffer() function which would turn the buffering back on
and require explicit syncing when desired.

Thoughts?

David

_______________________________________________
___________________________________________________

Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe. On 12/22/2010 2:27 PM, David A. Mellis wrote:
> Hi,
>
> At Limor's suggestion (and that of others), I'm in the process of
> adding file seek() to the SD library. This raised lots of other
> questions, however, which I'd like your opinions on.
>
> One question is which modes to support opening a file in. The current
> options don't really work well with the seek() command. I now think
> we can get away with just two modes: FILE_READ and FILE_WRITE. The
> former (the default), would not support writing, would signal an error
> if the file didn't exist (via bool() operator), and would place the
> cursor at the start of the file. The latter would create the file if
> it didn't exist, and place the cursor at the end of the file. In
> either case, you could seek elsewhere in the file.
>
> The current FILE_APPEND mode automatically seeks to the end before
> writing new data. With FILE_WRITE, instead, I propose that if you
> called seek() to move away from the end of the file, you'd have to
> seek back to the end if that's where you wanted to write.

that is correct. i think most people will use seekSet() on reading, 99%
of writing operations we have seen in the wild have been datalogging -
strict append operation. but for reading i think its very valuable to be
able to rewind, or jump to a location.

> I'll also add size() to get the size of the file and position() to get
> the current cursor position within the file.

yes plz.

> Finally, I propose making sync mode the default; that is,
> automatically physically saving written data to the SD card rather
> than buffering it in RAM. If necessary for performance reasons, we
> could add a buffer() function which would turn the buffering back on
> and require explicit syncing when desired.

yes!

i do suggest calling seek seekSet() or positionSet() just to avoid any
confusion with the 'classic' seek() which takes an additional argument.
its totally not a big deal tho.

_______________________________________________
___________________________________________________

Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe. I'm all for all of these, but I'm not sure the difference between seekSet() which seems like an awkward name, and positionSet(), which seems clear?

t.

On Dec 22, 2010, at 2:33 PM, Limor wrote:

>
>
> On 12/22/2010 2:27 PM, David A. Mellis wrote:
>> Hi,
>>
>> At Limor's suggestion (and that of others), I'm in the process of
>> adding file seek() to the SD library. This raised lots of other
>> questions, however, which I'd like your opinions on.
>>
>> One question is which modes to support opening a file in. The current
>> options don't really work well with the seek() command. I now think
>> we can get away with just two modes: FILE_READ and FILE_WRITE. The
>> former (the default), would not support writing, would signal an error
>> if the file didn't exist (via bool() operator), and would place the
>> cursor at the start of the file. The latter would create the file if
>> it didn't exist, and place the cursor at the end of the file. In
>> either case, you could seek elsewhere in the file.
>>
>> The current FILE_APPEND mode automatically seeks to the end before
>> writing new data. With FILE_WRITE, instead, I propose that if you
>> called seek() to move away from the end of the file, you'd have to
>> seek back to the end if that's where you wanted to write.
>
> that is correct. i think most people will use seekSet() on reading, 99% of writing operations we have seen in the wild have been datalogging - strict append operation. but for reading i think its very valuable to be able to rewind, or jump to a location.
>
>> I'll also add size() to get the size of the file and position() to get
>> the current cursor position within the file.
>
> yes plz.
>
>> Finally, I propose making sync mode the default; that is,
>> automatically physically saving written data to the SD card rather
>> than buffering it in RAM. If necessary for performance reasons, we
>> could add a buffer() function which would turn the buffering back on
>> and require explicit syncing when desired.
>
> yes!
>
> i do suggest calling seek seekSet() or positionSet() just to avoid any confusion with the 'classic' seek() which takes an additional argument. its totally not a big deal tho.
>
> _______________________________________________
___________________________________________________

Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe. seekSet() is the name of the underlying function

On 12/22/2010 11:31 PM, Tom Igoe wrote:
> I'm all for all of these, but I'm not sure the difference between seekSet() which seems like an awkward name, and positionSet(), which seems clear?
>
> t.
>
> On Dec 22, 2010, at 2:33 PM, Limor wrote:
>
>>
>>
>> On 12/22/2010 2:27 PM, David A. Mellis wrote:
>>> Hi,
>>>
>>> At Limor's suggestion (and that of others), I'm in the process of
>>> adding file seek() to the SD library. This raised lots of other
>>> questions, however, which I'd like your opinions on.
>>>
>>> One question is which modes to support opening a file in. The current
>>> options don't really work well with the seek() command. I now think
>>> we can get away with just two modes: FILE_READ and FILE_WRITE. The
>>> former (the default), would not support writing, would signal an error
>>> if the file didn't exist (via bool() operator), and would place the
>>> cursor at the start of the file. The latter would create the file if
>>> it didn't exist, and place the cursor at the end of the file. In
>>> either case, you could seek elsewhere in the file.
>>>
>>> The current FILE_APPEND mode automatically seeks to the end before
>>> writing new data. With FILE_WRITE, instead, I propose that if you
>>> called seek() to move away from the end of the file, you'd have to
>>> seek back to the end if that's where you wanted to write.
>>
>> that is correct. i think most people will use seekSet() on reading, 99% of writing operations we have seen in the wild have been datalogging - strict append operation. but for reading i think its very valuable to be able to rewind, or jump to a location.
>>
>>> I'll also add size() to get the size of the file and position() to get
>>> the current cursor position within the file.
>>
>> yes plz.
>>
>>> Finally, I propose making sync mode the default; that is,
>>> automatically physically saving written data to the SD card rather
>>> than buffering it in RAM. If necessary for performance reasons, we
>>> could add a buffer() function which would turn the buffering back on
>>> and require explicit syncing when desired.
>>
>> yes!
>>
>> i do suggest calling seek seekSet() or positionSet() just to avoid any confusion with the 'classic' seek() which takes an additional argument. its totally not a big deal tho.
>>
>> _______________________________________________
___________________________________________________

Posted on the Developers mailing list. Go to http://arduino.cc/mailman/listinfo/developers_arduino.cc to subscribe.