Xojo Conferences
XDCMay2019MiamiUSA

Text versus Binary - was Re: Storing Application Settings (Real Studio network user group Mailinglist archive)

Back to the thread list
Previous thread: Linux builds and shared libraries
Next thread: Runtime.ObjectCount incorrect?


Storing Application Settings   -   Jason Glazer
  Text versus Binary - was Re: Storing Application Settings   -   Tim Jones
    Re: Text versus Binary - was Re: Storing Application Settings   -   Arnaud Nicolet
    Re: Text versus Binary - was Re: Storing Application Settings   -   Arnaud Nicolet
    Re: Text versus Binary - was Re: Storing Application Settings   -   Cameron McCormick
    Re: Text versus Binary - was Re: Storing Application Settings   -   Arnaud Nicolet
    Re: Text versus Binary - was Re: Storing Application Settings   -   Tim Jones
    Re: Text versus Binary - was Re: Storing Application Settings   -   Arnaud Nicolet
    Re: Text versus Binary - was Re: Storing Application Settings   -   Tim Jones
     Re: Text versus Binary - was Re: Storing Application Settings   -   Joe Strout
    Re: Text versus Binary - was Re: Storing Application Settings   -   Arnaud Nicolet

Text versus Binary - was Re: Storing Application Settings
Date: 10.08.09 19:18 (Mon, 10 Aug 2009 11:18:39 -0700)
From: Tim Jones
On Aug 10, 2009, at 11:04 AM, Arnaud Nicolet wrote:

> Le 10 août 09 à 16:05, Jan-Ivar Mellingen a écrit:
>
>> Well, as I see it you will always have to rely on somebody else to do
>> the low-level work.
>
> I find it more reliable, in fact.

Hmmm, there's one for serious debate :-).

>> You have no more or less control writing to a text file than to a
>> binary
>> file. In the end a text file is no more than a binary file in a
>> defined
>> format ;-)
>
> I always write in binary files, since I can write things as I want.
> I agree: a text file should be what it means (some text that the
> user should read if it's what he wants).

Ahem, not really wanting to nit-pick, but a text file **is** a binary
file; it simply has a different content format. The days of text
files and binary files being truly different creatures are really
long gone. In modern terms, any file created on a system is a binary
files, its definition is only changed by the method in which you
access the data within.

Just for discussion...

Tim

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Text versus Binary - was Re: Storing Application Settings
Date: 11.08.09 10:36 (Tue, 11 Aug 2009 11:36:40 +0200)
From: Arnaud Nicolet
Le 11 août 09 à 2:47, Cameron McCormick a écrit:

> I suppose I'll go ahead and say what I presume everyone else is
> thinking,
> that the primary difference is if you want the file to be readable
> by the
> user. If its something they would reasonably change, such as a
> httpd.conf
> file - then yeah go with a text file all the way. If its something
> that only
> the program is going to maintain then binary or text would be fine.
>
> that's my 2cents anyway...

I'd think like you.
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Text versus Binary - was Re: Storing Application Settings
Date: 11.08.09 00:57 (Tue, 11 Aug 2009 01:57:25 +0200)
From: Arnaud Nicolet
Le 11 août 09 à 1:27, Tim Jones a écrit:

>> I appreciate, thank you! Also, the French example makes me
>> smiling ;-)
>> So "although" is to be used only on the beginning, not in the
>> middle, of a sentence?
>
> It can be used in the middle, although many will question why we're
> bothering with this discussion :-) ...

;-)

>> Well, the same result, but you have to convert everything as
>> string (and same for reading). If you have a boolean, I prefer
>> bs.WriteBoolean b rather than:
>> s="false" 'or "0", etc.
>> if b then s="true" 'or "1", etc.
>> TextOutPutStream.WriteLine s
>
> Or simply
>
> TextOutputStream Str(b)
>
> Since the Str() function will turn the boolean into the text for
> "True" or "False" :-).
>
> As with the various Binary helpers, there are few string helpers, too.

Well, storing a boolean seems better to me as a bit rather than
"true" or "false" as text (perhaps because it's language independent
or more "computer-related").
I like the way RB does not allow assignment of different datatypes,
normally (i.e dim b As Boolean="True" fails, and it's a good thing).

>>> But, most modern ReadMe files are RTF rather than plain text. As
>>> you say with PDF, you wouldn't display the raw file to a user as
>>> it would be illegible without parsing it through something like
>>> TextEdit or WordPad. However, it is still plain text in the file
>>> itself.
>>
>> Not sure I get your point here... The plain text is inside the raw
>> data (so the entire file isn't really plain text).
>
> But, in an RTF file, there is no raw data, just text that instructs
> the display mechanism how to display the content such as:
>
> {\rtf1\ansi\ansicpg1252\cocoartf949\cocoasubrtf330
> {\fonttbl\f0\fswiss\fcharset0 Helvetica;}
> {\colortbl;\red255\green255\blue255;}
> \margl1440\margr1440\vieww10860\viewh15680\viewkind0
> \pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480
> \tx7200\tx7920\tx8640\qc
>
> \f0\fs28 \cf0 TOLIS Group, Inc.\
>
> Every character in that is ASCII text, but what displays when it's
> properly parsed is simply "TOLIS Group, Inc." in Helvetica font face.

So it's somewhat what I said ;-)
RTF is not text, it's styled text and the text is included in the
file. Now, perhaps someone has said "rtf means to be a text file" and
everyone has accepted, but it might be not accurate.

>>> It's not safe to think that because the "bytes" in a file can be
>>> printed using the US ASCII set that the file is plain text nor
>>> that because the file contains non-ASCII bytes that the file is
>>> binary.
>>
>> I agree. Especially since other languages have typically character
>> codes which go beyond 127.
>
> In what I was trying to say, the character values aren't
> important. As you state, simply typing some non-English names adds
> non-ASCII characters to a file. This can result in a combination
> of bytes that equate to the simple character if the file is
> displayed by software that understands the meaning of these
> combined bytes, but would otherwise appear as garbage bytes to
> software that doesn't understand them.

Indeed.

>>> This is what I mean when I say the distinction between text and
>>> binary files has been removed for the most part as it's more the
>>> parsing and display of the data that defines how the file's
>>> contents are handled.
>>
>> Yes, I agree again, but we are in fact speaking about two
>> different parts. You speak about "what is different in the file"
>> while I speak about "how we read and write a file, based on what
>> we must write to it". You're indeed talking about the resulting
>> file, you're more correct. I should had said that.
>
> Yes. By today's definitions, the contents of a file must define
> what that file contains. Even the system kernels understand this.
> Take a look at /usr/share/file/magic or /etc/magic (depending on
> your platform). Without that info to define the file types, even
> your O/S kernel doesn't know a file as more than a collection of
> bytes.

Hmm... The "today's definition" does not seem right to me (can't we
keep thinking like when we learnt things, at least the principles?).
You know... "today or not today... that is the question..."

Wow, the "magic" file is really magic! It's a file installed by the
system? Is Apple really aware of, say, nes files? It's amazing...
I'll check that out.
Thanks
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Text versus Binary - was Re: Storing Application Settings
Date: 11.08.09 01:47 (Mon, 10 Aug 2009 20:47:32 -0400)
From: Cameron McCormick
I suppose I'll go ahead and say what I presume everyone else is thinking,
that the primary difference is if you want the file to be readable by the
user. If its something they would reasonably change, such as a httpd.conf
file - then yeah go with a text file all the way. If its something that only
the program is going to maintain then binary or text would be fine.

that's my 2cents anyway...

I'd rather be considered lucky than good.
-Cameron

On Mon, Aug 10, 2009 at 7:57 PM, Arnaud Nicolet <<email address removed>> wrote:

> Le 11 août 09 à 1:27, Tim Jones a écrit:
>
> I appreciate, thank you! Also, the French example makes me smiling ;-)
>>> So "although" is to be used only on the beginning, not in the middle, of
>>> a sentence?
>>>
>> It can be used in the middle, although many will question why we're
>> bothering with this discussion :-) ...
>>
> ;-)
>
> Well, the same result, but you have to convert everything as string (and
>>> same for reading). If you have a boolean, I prefer bs.WriteBoolean b rather
>>> than:
>>> s="false" 'or "0", etc.
>>> if b then s="true" 'or "1", etc.
>>> TextOutPutStream.WriteLine s
>>>
>> Or simply
>>
>> TextOutputStream Str(b)
>>
>> Since the Str() function will turn the boolean into the text for "True" or
>> "False" :-).
>>
>> As with the various Binary helpers, there are few string helpers, too.
>>
> Well, storing a boolean seems better to me as a bit rather than "true" or
> "false" as text (perhaps because it's language independent or more
> "computer-related").
> I like the way RB does not allow assignment of different datatypes,
> normally (i.e dim b As Boolean="True" fails, and it's a good thing).
>
> But, most modern ReadMe files are RTF rather than plain text. As you say
>>>> with PDF, you wouldn't display the raw file to a user as it would be
>>>> illegible without parsing it through something like TextEdit or WordPad.
>>>> However, it is still plain text in the file itself.
>>>>
>>>
>>> Not sure I get your point here... The plain text is inside the raw data
>>> (so the entire file isn't really plain text).
>>>
>> But, in an RTF file, there is no raw data, just text that instructs the
>> display mechanism how to display the content such as:
>>
>> {\rtf1\ansi\ansicpg1252\cocoartf949\cocoasubrtf330
>> {\fonttbl\f0\fswiss\fcharset0 Helvetica;}
>> {\colortbl;\red255\green255\blue255;}
>> \margl1440\margr1440\vieww10860\viewh15680\viewkind0
>>
>> \pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480\tx7200\tx7920\tx8640\qc
>>
>> \f0\fs28 \cf0 TOLIS Group, Inc.\
>>
>> Every character in that is ASCII text, but what displays when it's
>> properly parsed is simply "TOLIS Group, Inc." in Helvetica font face.
>>
> So it's somewhat what I said ;-)
> RTF is not text, it's styled text and the text is included in the file.
> Now, perhaps someone has said "rtf means to be a text file" and everyone has
> accepted, but it might be not accurate.
>
> It's not safe to think that because the "bytes" in a file can be printed
>>>> using the US ASCII set that the file is plain text nor that because the file
>>>> contains non-ASCII bytes that the file is binary.
>>>>
>>>
>>> I agree. Especially since other languages have typically character codes
>>> which go beyond 127.
>>>
>> In what I was trying to say, the character values aren't important. As
>> you state, simply typing some non-English names adds non-ASCII characters to
>> a file. This can result in a combination of bytes that equate to the simple
>> character if the file is displayed by software that understands the meaning
>> of these combined bytes, but would otherwise appear as garbage bytes to
>> software that doesn't understand them.
>>
> Indeed.
>
> This is what I mean when I say the distinction between text and binary
>>>> files has been removed for the most part as it's more the parsing and
>>>> display of the data that defines how the file's contents are handled.
>>>>
>>>
>>> Yes, I agree again, but we are in fact speaking about two different
>>> parts. You speak about "what is different in the file" while I speak about
>>> "how we read and write a file, based on what we must write to it". You're
>>> indeed talking about the resulting file, you're more correct. I should had
>>> said that.
>>>
>> Yes. By today's definitions, the contents of a file must define what that
>> file contains. Even the system kernels understand this. Take a look at
>> /usr/share/file/magic or /etc/magic (depending on your platform). Without
>> that info to define the file types, even your O/S kernel doesn't know a file
>> as more than a collection of bytes.
>>
> Hmm... The "today's definition" does not seem right to me (can't we keep
> thinking like when we learnt things, at least the principles?). You know...
> "today or not today... that is the question..."
>
> Wow, the "magic" file is really magic! It's a file installed by the system?
> Is Apple really aware of, say, nes files? It's amazing... I'll check that
> out.
> Thanks
>
> _______________________________________________
> Unsubscribe or switch delivery mode:
> <http://www.realsoftware.com/support/listmanager/>
> Search the archives:
> <http://support.realsoftware.com/listarchives/lists.html>
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Text versus Binary - was Re: Storing Application Settings
Date: 11.08.09 00:57 (Tue, 11 Aug 2009 01:57:25 +0200)
From: Arnaud Nicolet
Le 11 août 09 à 1:27, Tim Jones a écrit:

>> I appreciate, thank you! Also, the French example makes me
>> smiling ;-)
>> So "although" is to be used only on the beginning, not in the
>> middle, of a sentence?
>
> It can be used in the middle, although many will question why we're
> bothering with this discussion :-) ...

;-)

>> Well, the same result, but you have to convert everything as
>> string (and same for reading). If you have a boolean, I prefer
>> bs.WriteBoolean b rather than:
>> s="false" 'or "0", etc.
>> if b then s="true" 'or "1", etc.
>> TextOutPutStream.WriteLine s
>
> Or simply
>
> TextOutputStream Str(b)
>
> Since the Str() function will turn the boolean into the text for
> "True" or "False" :-).
>
> As with the various Binary helpers, there are few string helpers, too.

Well, storing a boolean seems better to me as a bit rather than
"true" or "false" as text (perhaps because it's language independent
or more "computer-related").
I like the way RB does not allow assignment of different datatypes,
normally (i.e dim b As Boolean="True" fails, and it's a good thing).

>>> But, most modern ReadMe files are RTF rather than plain text. As
>>> you say with PDF, you wouldn't display the raw file to a user as
>>> it would be illegible without parsing it through something like
>>> TextEdit or WordPad. However, it is still plain text in the file
>>> itself.
>>
>> Not sure I get your point here... The plain text is inside the raw
>> data (so the entire file isn't really plain text).
>
> But, in an RTF file, there is no raw data, just text that instructs
> the display mechanism how to display the content such as:
>
> {\rtf1\ansi\ansicpg1252\cocoartf949\cocoasubrtf330
> {\fonttbl\f0\fswiss\fcharset0 Helvetica;}
> {\colortbl;\red255\green255\blue255;}
> \margl1440\margr1440\vieww10860\viewh15680\viewkind0
> \pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480
> \tx7200\tx7920\tx8640\qc
>
> \f0\fs28 \cf0 TOLIS Group, Inc.\
>
> Every character in that is ASCII text, but what displays when it's
> properly parsed is simply "TOLIS Group, Inc." in Helvetica font face.

So it's somewhat what I said ;-)
RTF is not text, it's styled text and the text is included in the
file. Now, perhaps someone has said "rtf means to be a text file" and
everyone has accepted, but it might be not accurate.

>>> It's not safe to think that because the "bytes" in a file can be
>>> printed using the US ASCII set that the file is plain text nor
>>> that because the file contains non-ASCII bytes that the file is
>>> binary.
>>
>> I agree. Especially since other languages have typically character
>> codes which go beyond 127.
>
> In what I was trying to say, the character values aren't
> important. As you state, simply typing some non-English names adds
> non-ASCII characters to a file. This can result in a combination
> of bytes that equate to the simple character if the file is
> displayed by software that understands the meaning of these
> combined bytes, but would otherwise appear as garbage bytes to
> software that doesn't understand them.

Indeed.

>>> This is what I mean when I say the distinction between text and
>>> binary files has been removed for the most part as it's more the
>>> parsing and display of the data that defines how the file's
>>> contents are handled.
>>
>> Yes, I agree again, but we are in fact speaking about two
>> different parts. You speak about "what is different in the file"
>> while I speak about "how we read and write a file, based on what
>> we must write to it". You're indeed talking about the resulting
>> file, you're more correct. I should had said that.
>
> Yes. By today's definitions, the contents of a file must define
> what that file contains. Even the system kernels understand this.
> Take a look at /usr/share/file/magic or /etc/magic (depending on
> your platform). Without that info to define the file types, even
> your O/S kernel doesn't know a file as more than a collection of
> bytes.

Hmm... The "today's definition" does not seem right to me (can't we
keep thinking like when we learnt things, at least the principles?).
You know... "today or not today... that is the question..."

Wow, the "magic" file is really magic! It's a file installed by the
system? Is Apple really aware of, say, nes files? It's amazing...
I'll check that out.
Thanks
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Text versus Binary - was Re: Storing Application Settings
Date: 11.08.09 00:27 (Mon, 10 Aug 2009 16:27:16 -0700)
From: Tim Jones
On Aug 10, 2009, at 2:15 PM, Arnaud Nicolet wrote:

>>> Not sure about that, though (or is it "thought"? I never know)...
>>
>> "though", or "although" to be more correct - the French "bien
>> que" or "malgré" :-). You would use the although form at the
>> begiining of the statement:
>>
>> "Although I'm not sure about that."
>>
>> End of English lesson :-).
>
> I appreciate, thank you! Also, the French example makes me smiling ;-)
> So "although" is to be used only on the beginning, not in the
> middle, of a sentence?

It can be used in the middle, although many will question why we're
bothering with this discussion :-) ...

> Your nice explanation will help me, since I will now use only
> "although" and not "though" (which confuses me with "through" and
> "thought" when I have to decide).
>
>>> There are several ways of writing {"Apple",14,RGB
>>> (0,255,255),False,23,True,"Bird"} to a file, but the simplest way
>>> is to use the binarystream (or equivalent in other languages)
>>> way, because it has everything to support writing the list
>>> (WritePString, WriteLong and WriteBoolean, for instance). Making
>>> it a "text formatted file" would, in my opinion, not make sense.
>>
>> But, you could as easily use
>>
>> TextOutPutStream.WriteLine "{""Apple"",14,RGB(0,255,255),False,
>> 23,True,""Bird""}"
>> or
>> TextOutputStream.Write SmartSplit(""Apple"",14,RGB
>> (0,255,255),False,23,True,""Bird"")
>>
>> (SmartSplit is an extension I wrote that knows if you're inside of
>> an element like "", '', {}. []. (), <> to split properly)
>
> So I assume you already have this alternate solution from a
> relatively-long time ;-)

Yep - I might even be convinced to share.

>> and get the same result.
>
> Well, the same result, but you have to convert everything as string
> (and same for reading). If you have a boolean, I prefer
> bs.WriteBoolean b rather than:
> s="false" 'or "0", etc.
> if b then s="true" 'or "1", etc.
> TextOutPutStream.WriteLine s

Or simply

TextOutputStream Str(b)

Since the Str() function will turn the boolean into the text for
"True" or "False" :-).

As with the various Binary helpers, there are few string helpers, too.

>>> On the other hand, if you are writing a "read me" file, making it
>>> a binary one seems to be wrong (the user should be able to open
>>> it with a viewer, so no special character is needed, so it
>>> becomes a "text file" (compliant with the format, I mean).
>>
>> But, most modern ReadMe files are RTF rather than plain text. As
>> you say with PDF, you wouldn't display the raw file to a user as
>> it would be illegible without parsing it through something like
>> TextEdit or WordPad. However, it is still plain text in the file
>> itself.
>
> Not sure I get your point here... The plain text is inside the raw
> data (so the entire file isn't really plain text).

But, in an RTF file, there is no raw data, just text that instructs
the display mechanism how to display the content such as:

{\rtf1\ansi\ansicpg1252\cocoartf949\cocoasubrtf330
{\fonttbl\f0\fswiss\fcharset0 Helvetica;}
{\colortbl;\red255\green255\blue255;}
\margl1440\margr1440\vieww10860\viewh15680\viewkind0
\pard\tx720\tx1440\tx2160\tx2880\tx3600\tx4320\tx5040\tx5760\tx6480
\tx7200\tx7920\tx8640\qc

\f0\fs28 \cf0 TOLIS Group, Inc.\

Every character in that is ASCII text, but what displays when it's
properly parsed is simply "TOLIS Group, Inc." in Helvetica font face.

>> It's not safe to think that because the "bytes" in a file can be
>> printed using the US ASCII set that the file is plain text nor
>> that because the file contains non-ASCII bytes that the file is
>> binary.
>
> I agree. Especially since other languages have typically character
> codes which go beyond 127.

In what I was trying to say, the character values aren't important.
As you state, simply typing some non-English names adds non-ASCII
characters to a file. This can result in a combination of bytes that
equate to the simple character if the file is displayed by software
that understands the meaning of these combined bytes, but would
otherwise appear as garbage bytes to software that doesn't understand
them.

>> This is what I mean when I say the distinction between text and
>> binary files has been removed for the most part as it's more the
>> parsing and display of the data that defines how the file's
>> contents are handled.
>
> Yes, I agree again, but we are in fact speaking about two different
> parts. You speak about "what is different in the file" while I
> speak about "how we read and write a file, based on what we must
> write to it". You're indeed talking about the resulting file,
> you're more correct. I should had said that.

Yes. By today's definitions, the contents of a file must define what
that file contains. Even the system kernels understand this. Take a
look at /usr/share/file/magic or /etc/magic (depending on your
platform). Without that info to define the file types, even your O/S
kernel doesn't know a file as more than a collection of bytes.

Tim

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Text versus Binary - was Re: Storing Application Settings
Date: 10.08.09 22:15 (Mon, 10 Aug 2009 23:15:11 +0200)
From: Arnaud Nicolet
Le 10 août 09 à 22:36, Tim Jones a écrit:

> On Aug 10, 2009, at 12:31 PM, Arnaud Nicolet wrote:
>
>> Le 10 août 09 à 20:18, Tim Jones a écrit:
>>
>>>> I always write in binary files, since I can write things as I
>>>> want. I agree: a text file should be what it means (some text
>>>> that the user should read if it's what he wants).
>>>
>>> Ahem, not really wanting to nit-pick, but a text file **is** a
>>> binary file; it simply has a different content format. In modern
>>> terms, any file created on a system is a binary files, its
>>> definition is only changed by the method in which you access the
>>> data within.
>>>
>>> Just for discussion...
>>
>> I agree with your definition (a text file is obviously a binary
>> file; how can one imagine a file, in a computer, that is not
>> binary?).
>>
>> However, the important part is how it is shown to the user (in my
>> opinion). For instance, a PDF, although still a binary file, won't
>> display glyphs and unprintable characters all the way. It's shown
>> as text. On the other hand, an application (the "binary" file in
>> case of a bundle) will hardly be something to show as text to the
>> user (so it's a binary file, not a text file).
>>
>>> The days of text files and binary files being truly different
>>> creatures are really long gone.
>>
>> Not sure about that, though (or is it "thought"? I never know)...
>
> "though", or "although" to be more correct - the French "bien que"
> or "malgré" :-). You would use the although form at the begiining
> of the statement:
>
> "Although I'm not sure about that."
>
> End of English lesson :-).

I appreciate, thank you! Also, the French example makes me smiling ;-)
So "although" is to be used only on the beginning, not in the middle,
of a sentence?

Your nice explanation will help me, since I will now use only
"although" and not "though" (which confuses me with "through" and
"thought" when I have to decide).

>> There are several ways of writing {"Apple",14,RGB(0,255,255),False,
>> 23,True,"Bird"} to a file, but the simplest way is to use the
>> binarystream (or equivalent in other languages) way, because it
>> has everything to support writing the list (WritePString,
>> WriteLong and WriteBoolean, for instance). Making it a "text
>> formatted file" would, in my opinion, not make sense.
>
> But, you could as easily use
>
> TextOutPutStream.WriteLine "{""Apple"",14,RGB(0,255,255),False,
> 23,True,""Bird""}"
> or
> TextOutputStream.Write SmartSplit(""Apple"",14,RGB
> (0,255,255),False,23,True,""Bird"")
>
> (SmartSplit is an extension I wrote that knows if you're inside of
> an element like "", '', {}. []. (), <> to split properly)

So I assume you already have this alternate solution from a
relatively-long time ;-)

> and get the same result.

Well, the same result, but you have to convert everything as string
(and same for reading). If you have a boolean, I prefer
bs.WriteBoolean b rather than:
s="false" 'or "0", etc.
if b then s="true" 'or "1", etc.
TextOutPutStream.WriteLine s

>> On the other hand, if you are writing a "read me" file, making it
>> a binary one seems to be wrong (the user should be able to open it
>> with a viewer, so no special character is needed, so it becomes a
>> "text file" (compliant with the format, I mean).
>
> But, most modern ReadMe files are RTF rather than plain text. As
> you say with PDF, you wouldn't display the raw file to a user as it
> would be illegible without parsing it through something like
> TextEdit or WordPad. However, it is still plain text in the file
> itself.

Not sure I get your point here... The plain text is inside the raw
data (so the entire file isn't really plain text).

> It's not safe to think that because the "bytes" in a file can be
> printed using the US ASCII set that the file is plain text nor that
> because the file contains non-ASCII bytes that the file is binary.

I agree. Especially since other languages have typically character
codes which go beyond 127.

> This is what I mean when I say the distinction between text and
> binary files has been removed for the most part as it's more the
> parsing and display of the data that defines how the file's
> contents are handled.

Yes, I agree again, but we are in fact speaking about two different
parts. You speak about "what is different in the file" while I speak
about "how we read and write a file, based on what we must write to
it". You're indeed talking about the resulting file, you're more
correct. I should had said that.
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Text versus Binary - was Re: Storing Application Settings
Date: 10.08.09 21:36 (Mon, 10 Aug 2009 13:36:04 -0700)
From: Tim Jones
On Aug 10, 2009, at 12:31 PM, Arnaud Nicolet wrote:

> Le 10 août 09 à 20:18, Tim Jones a écrit:
>
>>> I always write in binary files, since I can write things as I
>>> want. I agree: a text file should be what it means (some text
>>> that the user should read if it's what he wants).
>>
>> Ahem, not really wanting to nit-pick, but a text file **is** a
>> binary file; it simply has a different content format. In modern
>> terms, any file created on a system is a binary files, its
>> definition is only changed by the method in which you access the
>> data within.
>>
>> Just for discussion...
>
> I agree with your definition (a text file is obviously a binary
> file; how can one imagine a file, in a computer, that is not binary?).
>
> However, the important part is how it is shown to the user (in my
> opinion). For instance, a PDF, although still a binary file, won't
> display glyphs and unprintable characters all the way. It's shown
> as text. On the other hand, an application (the "binary" file in
> case of a bundle) will hardly be something to show as text to the
> user (so it's a binary file, not a text file).
>
>> The days of text files and binary files being truly different
>> creatures are really long gone.
>
> Not sure about that, though (or is it "thought"? I never know)...

"though", or "although" to be more correct - the French "bien que"
or "malgré" :-). You would use the although form at the begiining of
the statement:

"Although I'm not sure about that."

End of English lesson :-).

> There are several ways of writing {"Apple",14,RGB(0,255,255),False,
> 23,True,"Bird"} to a file, but the simplest way is to use the
> binarystream (or equivalent in other languages) way, because it has
> everything to support writing the list (WritePString, WriteLong and
> WriteBoolean, for instance). Making it a "text formatted file"
> would, in my opinion, not make sense.

But, you could as easily use

TextOutPutStream.WriteLine "{""Apple"",14,RGB(0,255,255),False,
23,True,""Bird""}"
or
TextOutputStream.Write SmartSplit(""Apple"",14,RGB(0,255,255),False,
23,True,""Bird"")

(SmartSplit is an extension I wrote that knows if you're inside of an
element like "", '', {}. []. (), <> to split properly)

and get the same result.

> On the other hand, if you are writing a "read me" file, making it a
> binary one seems to be wrong (the user should be able to open it
> with a viewer, so no special character is needed, so it becomes a
> "text file" (compliant with the format, I mean).

But, most modern ReadMe files are RTF rather than plain text. As you
say with PDF, you wouldn't display the raw file to a user as it would
be illegible without parsing it through something like TextEdit or
WordPad. However, it is still plain text in the file itself.

It's not safe to think that because the "bytes" in a file can be
printed using the US ASCII set that the file is plain text nor that
because the file contains non-ASCII bytes that the file is binary.

This is what I mean when I say the distinction between text and
binary files has been removed for the most part as it's more the
parsing and display of the data that defines how the file's contents
are handled.

Tim

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Text versus Binary - was Re: Storing Application Settings
Date: 10.08.09 21:56 (Mon, 10 Aug 2009 14:56:24 -0600)
From: Joe Strout
Tim Jones wrote:

> This is what I mean when I say the distinction between text and binary
> files has been removed for the most part as it's more the parsing and
> display of the data that defines how the file's contents are handled.

Right. I would say that the distinction is in the set of assumptions
that go with the file. If you tell me it's a text file, I assume that I
can open it with TextWrangler and usefully browse and edit it (though I
may or may not understand what it all means). If you say it's UTF-8
text, the assumptions are even stronger, as there are a lot of byte
sequences that are not valid UTF-8; a valid UTF-8 text file would
contain none of those.

But in the end, text vs. binary is in the eye of the beholder.

Best,
- Joe

Re: Text versus Binary - was Re: Storing Application Settings
Date: 10.08.09 20:31 (Mon, 10 Aug 2009 21:31:31 +0200)
From: Arnaud Nicolet
Le 10 août 09 à 20:18, Tim Jones a écrit:

>> I always write in binary files, since I can write things as I
>> want. I agree: a text file should be what it means (some text that
>> the user should read if it's what he wants).
>
> Ahem, not really wanting to nit-pick, but a text file **is** a
> binary file; it simply has a different content format. In modern
> terms, any file created on a system is a binary files, its
> definition is only changed by the method in which you access the
> data within.
>
> Just for discussion...

I agree with your definition (a text file is obviously a binary file;
how can one imagine a file, in a computer, that is not binary?).

However, the important part is how it is shown to the user (in my
opinion). For instance, a PDF, although still a binary file, won't
display glyphs and unprintable characters all the way. It's shown as
text. On the other hand, an application (the "binary" file in case of
a bundle) will hardly be something to show as text to the user (so
it's a binary file, not a text file).

> The days of text files and binary files being truly different
> creatures are really long gone.

Not sure about that, though (or is it "thought"? I never know)...
There are several ways of writing {"Apple",14,RGB(0,255,255),False,
23,True,"Bird"} to a file, but the simplest way is to use the
binarystream (or equivalent in other languages) way, because it has
everything to support writing the list (WritePString, WriteLong and
WriteBoolean, for instance). Making it a "text formatted file" would,
in my opinion, not make sense.

On the other hand, if you are writing a "read me" file, making it a
binary one seems to be wrong (the user should be able to open it with
a viewer, so no special character is needed, so it becomes a "text
file" (compliant with the format, I mean).
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>