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: Arthur J Knapp <email@hidden>
- Date: Fri, 14 Dec 2001 18:32:58 -0500
>
Date: Fri, 14 Dec 2001 11:36:54 -0800
>
Subject: Re: even better coerce to record with usrf
>
From: Paul Berkowitz <email@hidden>
>
On 12/14/01 10:25 AM, "Arthur J Knapp" <email@hidden> wrote:
>
>
> I have no idea where you can read up on this. Every thing I know
>
> has come from trial & error, as well as from discussions on this list.
>
Thank you very much for the synopsis. ...
>
... A couple
>
of questions follow inline:
>
> set dataString to {{a:12}} as string
>
> set dataAscii to every character of dataString
>
> repeat with i in dataAscii
>
> set i's contents to ASCII number i
>
> (*
>
> * 0, 0, 0, 1, 0, 0, 0, 0, 117, 115, 114, 102,
>
> * 108, 105, 115, 116, 0, 0, 0, 30, 0, 0, 0, 2,
>
> * 0, 0, 0, 0, 84, 69, 88, 84, 0, 0, 0, 1, 97,
>
> * 0, 108, 111, 110, 103, 0, 0, 0, 4,
>
> * 0, 0, 0, 12
>
> (* 1) 0001 0000 usrf
>
> * 2) list (30) 0002 0000
>
> * 3) TEXT 0001 a 0
>
> * 4) long 0004 (12)
>
> *)
>
> The (30) indicates that the list's data is 30 bytes in
>
> length, ie: count the bytes following 30. I refer to this
>
> as the "data-size".
>
What exactly is 30 bytes here? Where do these 30 bytes start and finish? (I
>
also note that ASCII character 30 is supposed to mean "RS - Record
>
Separator", which might have a bearing here.) Are you saying that this "0 0
>
0 30" identifies a "list" (looks like this might encompass both AppleScript
>
lists and records - arrays of any type)? Is "30" just an identifier for
>
"list", or do these 30 bytes quantify something?
I'm sorry, I must have been very, very unclear. I'm going to try
again:
Let's go back to the list of ascii numbers that we genereated
again, (all white space and indenting is mine):
0 0 0 1 0 0 0 0 117 115 114 102 -->header
108 105 115 116 0 0 0 30 0 0 0 2 0 0 0 0 -->list
84 69 88 84 0 0 0 1 97 0 -->label
108 111 110 103 0 0 0 4 0 0 0 12 -->value
So line 1 is the "header":
0 0 0 1 0 0 0 0 117 115 114 102
long(1) long(0) "usrf" --> ascii 117 == "u", etc
Line 2 contains the "list" header. This header proceeds a collection
of other data types. It seems that AppleScript stores "user-records"
as a special type of "list". So, when AppleScript reads "usrf", it
knows that a "list" is about to follow, but that the "list" should be
presented to the scripter as a "record".
108 105 115 116 0 0 0 30 0 0 0 2 0 0 0 0
"list" long(30) long(2) long(0)
data-type data-size item-count ???
Now, the actual word "list" tells AppleScript that the following
data is a "list", (where as the word "usrf" in the header tells
AppleScript to treat the following list as a "user-record", a record
created by a scripter).
Following the word "list" is a long. It's four bytes tell
AppleScript that the next (x) amount of bytes is a part of the
list. If you *literally* count how many bytes follow the "30" in
the ascii numbers, you will see that there are exactly 30 bytes,
(I guess I didn't make that clear the first time around). This
is what I call the "data-size".
Following the data-size is a long that tells how many items
there are in the list. In this case, there are 2, one label
and one value. A record of 2 properties would have a "list"
of 4 items, the first label, the first value, the second label,
etc.
Then there's that final long of four ascii character zeros.
Perhaps it is some kind of "padding" thing, I don't know.
Line 3, the property, (or label, or whatever we're calling it):
84 69 88 84 0 0 0 1 97 0
"TEXT" long(1) "a" 0
data-type data-size data-value pad-byte
The record we coerced was {a:12}. This line shows how the
"a" is represented. First is the data-type, "TEXT". Note
that ALL of the labels will be of type "TEXT".
Next is the data-size. "a" has exactly one character, (one
byte), so the data-size is a long representing 1.
Then is the actual string itself, "a".
ASCII character 97 = ASCII number "a".
The tricky thing to remember here is that last ASCII
character 0. AppleScript likes it's values to have a
total length that is even, (not odd). Becuase the length
of "a" is odd, the ascii 0 is appended to it.
For instance, if the record was {java:"script"}, then the
representation would be:
84 69 88 84 0 0 0 4 106 97 118 97
"TEXT" long(4) "java"
data-type data-size data-value no pad byte, 4 is even
Finally, there is the value, the representation of the integer 12:
108 111 110 103 0 0 0 4 0 0 0 12
"long" long(4) long(12)
data-type data-size data-value
The data-type is the literal text, "long". This is what
AppleScript uses to represent integers. Next is the data-size.
Because a long is, (by definition), a 4-byte value, the data-
size is 4. Finally, the number itself, 12 as a long.
>
What's 4 bytes here? "12" doesn't look like 4 bytes. So "0 0 0 12" are the 4
>
bytes?
Right. Remember, we coerced the string into ascii numbers. ASCII number
12 is just one byte.
>
Indeed it is. Can you go on to the next step and replay how all this
>
converts to string? I can see it coming, but i would appreciate a review.
I'm not sure I understand. The record was coerced to a string.
>
> P.S. I'm still just a scripter...
>
>
>
>
Yeah, sure. Cal would love this.;-)
Cal would be much better at explaining it than I am... ;-)
{ Arthur J. Knapp, of <
http://www.STELLARViSIONs.com>
<
mailto:email@hidden>
try
<
http://www.LateNightSW.com/>
on error number -128
end try
}