ambassador at fourthworld.com
Thu Oct 14 20:13:07 EDT 2010
Bob Sneidar wrote:
> Well I was thinking more in terms of low level file I/O.
Indeed, and here Rev bests HC by a wide margin. In HC you had no choice
but to read and write files in what is the equivalent of Rev's "text"
mode. To do a true binary read in HC you had to write or buy and
external, but in Rev you have that option built-in.
Let's explore this in action:
> Let's say I need to have a rev stack creating files at a low level
> on a server, for back end integration into something else. Those
> files will be accessed by another platform, let's say unix. If I
> terminated my lines with lf & cr, I would in effect only be creating
> two line feeds.
...unless you use Rev's built-in CRLF constant, which does what you want.
But if your OS is Unix, it would be using the same native line endings
that are native to Rev.
You'd only need to write CRLF when writing to Windows, but I believe
(though I could well be wrong) that IIS is now smart enough to do the
equivalent of what Rev does when reading files, since it knows that it
lives in a world dominated by Unix servers, processes, and tools.
Even simpler would be to not think about it at all, but just write your
data using CR and output it with a non-binary write like:
open file <filename>
put tData into url ("file:"&<filename>")
> It's not a big deal now that I know, because I can create my own
> constants and use them instead of the built in ones.
Just use CRLF when you need a return followed by a linefeed, CR when
you're writing to a Unix-based system, or not bother and let the engine
figure it out when it writes.
The only constant missing is one for ASCII 13, but since OS X stopped
using that I'm not sure any supported OS uses that anymore anyway.
> It's just an unexpected quirk that a Carriage Return constant that
> *should* mean ASCII 13 on ALL platforms and Line Feed constant that
> *should* mean ASCII 10 on All platforms, means different things
> depending on Livecode and what it's running on.
Almost. The constants are the same on all platforms. The only
difference between CR as used in Rev and CR as used in HC is that in Rev
it gives you ASCII 10 rather than 13. LF is always linefeed, CRLF is
always return+linefeed, on all platforms.
If HyperCard had never been born chances are CR would have been mapped
to ASCII 13 and all the xTalk code would have used LF.
But then again, if HyperCard had never been born chances are there would
never have been a MetaCard, and we wouldn't be here on this list
enjoying these historic quirks. ;)
> LiveCode or it's predecessors could have done all the internal
> conversions and still left these constants what you would expect
> them to be. That is just my opinion. I just don't think a keyword
> in any language should mean different things unless it's obvious.
In principle I agree with you wholeheartedly. But this is just one of
the several things in the language which are a bit quirky because of
their HyperTalk/platform-specific origins.
When MC was born in '92, the world was chock full 'o HyperTalk. If
Raney had demanded that folks change their scripting habits to adopt LF
because his text engine wasn't nearly as limited as HC's, that would
have just annoyed people and might well have killed adoption long before
it got healthy enough to warrant a company like RunRev to come along and
move it forward.
So he did something that is indeed impure, but which lets a lot of
legacy code and typing habits move into the 21st century with relative ease.
What kills me are the oddities like "destroyStack" which doesn't destroy
the stack at all, or the "listBehavior" which doesn't govern the
behavior but merely the selection appearance while the actual behavior
driven by other list-related properties, or the "traversalOn" which
could have been so less bizarre as simply "traversal", or the "dontWrap"
and "dontSearch", dontRefresh", and all the other "dont*" properties
that you have to set to true to get it to not do something, and the most
bizzare of all, being able to use property syntax ("the") for function
calls, but only with some functions and not others.
Ah, the mysteries....
LiveCode training and consulting: http://www.fourthworld.com
Webzine for LiveCode developers: http://www.LiveCodeJournal.com
LiveCode Journal blog: http://LiveCodejournal.com/blog.irv
More information about the Use-livecode