Re: even better coerce to record with usrf
Re: even better coerce to record with usrf
- Subject: Re: even better coerce to record with usrf
- From: Nigel Garvey <email@hidden>
- Date: Fri, 14 Dec 2001 18:18:06 +0000
Paul Berkowitz wrote on Fri, 14 Dec 2001 08:26:15 -0800:
>
On 12/14/01 7:21 AM, "Arthur J Knapp" <email@hidden> wrote:
>
>
> I see that you didn't care for my faster method: ;-)
>
>
>
> on IntegerToBytes(n)
>
>
>
> return ({{a:n}} as string)'s text -4 thru -1
>
>
>
> end IntegerToBytes
I'm sorry, Arthur. I care for it passionately. It's just that I - uh -
forgot about it during the creative process. Very remiss of me. I've now
corrected my home copy of the script. :-)
>
Arthur,
>
>
I must admit I've missed all of this. It seemed rather too esoteric for me.
>
But now I'm intrigued: what threads, or links, should i go to read up on
>
this? What's it do anyway? When I try out the line in the middle of it,
>
using the number 12 for n, all I get is a non-printing square character in
>
quotes (in SD 3). If I omit the text -4 thru -1 bit I get
>
>
"usrflistTEXTalong"
I hope you won't mind me butting in while I'm here, Paul. The thread was:
"interesting discovery (trying to get record labels as string)". It
stemmed from the rediscovery that it's possible to coerce a record to a
data string in one of the following related ways:
{myRecord} as string
list myRecord as string
record myRecord as string
All three produce the same result, which is essentially a series of byte
values which looks like a string and which describes the structure of the
record. Basically, it shows the type of the next item at this level, the
length of the data for it as a four-byte value, and the data itself. The
data itself can include similar entries for contained items. The
unreadable characters are bytes whose values do not fall within the ASCII
range. (For me, the result on screen is sometimes a windowful of
gibberish with no apparent connection to the record; but this seems to be
a Script Editor display problem as the scripts still work at these
times.) The string can be coerced back to a record in the normal way.
Exciting applications for this include: saving records and multi-level
lists as text files (more economical than saving them as scripts),
Arthur's lightning fast string-to-ascii and string-to-hex converters, and
the current discussion about using strings to access record labels.
The fly in the ointment - as Chris Nebel assures us - is that the
coercion to string (or maybe just the method of doing it) is due to a
bug. The only assurance given about this is that it won't be fixed until
the problems with the Standard Addition read and write commands are.
NG