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: email@hidden (Michael Sullivan)
- Date: Fri, 14 Dec 2001 17:08:56 -0500
- Organization: Business Card Express of Connecticut
Nigel Garvey writes:
>
Paul Berkowitz wrote on Fri, 14 Dec 2001 08:26:15 -0800:
>
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.)
It's an applescript memory leak. I was having the same problem, and
posted about it. After much speculation, Chris Nebel gave me the answer
-- it's a bug in applescript 1.5.5, fixed in 1.6.
It appears that the bug only affects script log displays, but when
displaying a string with certain ascii codes includding ascii zero,
instead of displaying whatever is supposed to display for that code
(box, blank, etc.) it displays a c-style string from a random memory
address. Which sometimes is a single character, or even an ascii zero,
but more often ends up being a arbitrarily long string of core junk.
It doesn't appear to be dangerous, since it only affects log displays.
I suppose it could be a mild security risk (it allows someone to read
memory addresses that they shouldn't) but if unauthorized parties are
running applescripts from an editor on your system it's pretty well
hacked already.
In any case, 1.6 and up are supposed to have fixed it, and that appears
to be the case since I installed the 1.6 update.
>
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 unfortunate thing about this is that Arthur's string to ascii and
ascii to string mods are *not* faster than using the standard additions
osax on single character strings. They break even around 4-5 characters
and then get much faster after that.
But they don't help for a routine that must step through characters one
at a time. I was hoping this would solve my problem with slow scripts
in Xpress. Alas.
Michael
--
Michael Sullivan email@hidden
Business Card Express of Connecticut Thermographers to the Trade
"You hate your job -- why didn't you say so? There's a support group
for that. It's called everybody; they meet at the bar." -Drew Carey