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: Paul Berkowitz <email@hidden>
- Date: Fri, 14 Dec 2001 11:36:54 -0800
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.
Arthur,
Thank you very much for the synopsis. I was searching for the actual thread
that everyone had contributed to before it got changed, and Nigel has
supplied that. But this synopsis is succinct and fills in the gaps. I had
run into 'longs' before and figured out what their upper limits were, but
didn't know how they were actually represented. This helps a lot. A couple
of questions follow inline:
>
>
> "usrflistTEXTalong"
>
>
>
Yeah, allow me to try to explain as much as I know:
>
>
>
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
>
end repeat
>
(*
>
* 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
>
*)
>
>
-- Let me rewrite the above in an understandable way,
>
-- (all whitespace is mine):
>
>
(* 1) 0001 0000 usrf
>
* 2) list (30) 0002 0000
>
* 3) TEXT 0001 a 0
>
* 4) long 0004 (12)
>
*)
>
>
Line 1 is some type of header. This is appearently what
>
allows AppleScript to know that the data is a record of
>
some kind.
>
>
Line 2 identifies a "list" type. The (30) is actually
>
(ASCII number 0) & (ASCII number 0) & (ASCII number 0) &
>
(ASCII number 30). This type of data is called a "long",
>
where 4 bytes are used to represent a numerical value. You
>
can think of the number system as being base 256, ie: the
>
right-most byte is the ones place, the second byte from the
>
right is the 256ths place, etc.
>
>
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?
>
>
The 0002 following the data-size is another "long",
>
indicating how many items are in the list. The 0000
>
following that is appearently another long, though
>
I don't know what it's purpose is. It always follows
>
a "list"'s data-size.
>
>
Line 3 is the data for the record label "a". It's
>
type is given first, "TEXT". Although record properties
>
are not considered "strings" in AppleScripting, they
>
are in this data-structure.
>
Next is the data-size, a "long" indicating the number 1,
>
(ie: "a" is one byte). If the label had been {Hello:"Paul"},
>
then the data-size would be 5, (0005).
You mean if the record label-plus-value-pair had been |Hello:"Paul"|. I
guess the label itself is "Hello" : 5 bytes?
>
>
It is also important to notice the final ASCII number 0
>
on this line. Appearently, AppleScript needs to "pad"
>
values whose data-size is not even. The data-size does not
>
reflect this.
>
>
Line 4 is the value of a of {a:12}, ie: it is the number
>
12 itself. First the type, "long". Then the data-size,
>
0004, (4). Last, the number-as-long itself: 0 0 0 12.
What's 4 bytes here? "12" doesn't look like 4 bytes. So "0 0 0 12" are the 4
bytes? Hmm. But "a" is just one byte. Interesting. If the value were a
string, rather than an integer, then it would be as many bytes as there were
characters, I guess?
|a:"12"|
would give a 0002 data-size? So AppleScript integers are really longs?
>
>
A more generic way to describe all of this is as follows:
>
>
long(1) & long(0) & "usrf"
>
>
"list" & dataSize(30) & itemCount(2) & long(0)
>
>
"TEXT" & dataSize(1) & "a" & nullPadByte
>
>
"long" & dataSize(4) & long(12)
>
>
I'm not good at explaining these sort of things, but
>
I hope some of this was enlightening.
>
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.
>
>
P.S. I'm still just a scripter...
>
Yeah, sure. Cal would love this.;-)
--
Paul Berkowitz