|
Hi again,
Thanks to Stan and Axel for running tests and reporting back,
confirming it's not just my imagination (that is, assuming Stan
and Axel aren't just figments of my imagination too…:).
On 04/03/2016 22:01, Stan Cleveland wrote:
Is it possible that `Number.unittest.scpt` has an outdated dependency stored in its maintained state? Adding a comment and recompiling would force a fresh copy of the dependency to load and, potentially, put things right.
Nope. Edit the Number.unittest.scpt script again to remove the
comment you put in, and the failure comes back. It's the shape of
the script that determines whether or not the problem occurs, and
the fact that even adding a comment makes it go away again
My best guess would be an obscure bug between the bytecode
serializer/deserializer (which converts live bytecode to/from .scpt
data) and OSACompile() when using kOSAModeAugmentContext that
sometimes produces subtly malformed bytecode that causes the
interpreter to puke in odd ways when it tries to interpret it.
Augmenting the unittest script's context is the only "unusual" thing
osatest does compared to other apps that load and execute AS
scripts, so I think it has to be related to that, otherwise we'd be
seeing similar problems in everyday use. (I don't like doing code
generation in non-Lispy languages, but compiling a custom
__performunittest__ handler into the unittest script was the easiest
way to prepare and run each test given all of AS's other
shortcomings.) The fact that one of the "nonsense" errors is
dsMixedModeFailure (1011) may also be a bit
of a clue, given the AS interpreter has hopped across multiple
architectures over the years (I think that one dates back to the
68K->PPC transition) while maintaining bytecode compatibility.
But eh, speculation only points to where the problem might be, not
fixes it.
I suppose with sufficient work I could redesign the test framework
to avoid doing anything that might set it off, but I don't want to
muck up its UI/UX and in any case I'm out of time so just want to
get these libraries tested, debugged, and off my hands ASAP. Given
that the behavior is replicable, I can work around it for now when
it appears just by fiddling unittest files till it goes away again.
Should Apple be persuaded to take these libraries (cold day in hell,
I know), getting to the bottom of it will be their problem. (Or
whoever else I finally dump them on.)
...
BTW, if you or anyone else has some spare hours in the next week or
so, I could use a hand assembing documentation. The Date, Number,
and Text libraries need self-contained documentation for their date
formatting, number formatting, and regular _expression_ syntaxes
respectively. Not an exciting job: it basically means trawling
through Apple's Data Formatting Guide and NSRegularExpression docs,
and the Unicode consortium and ICU pages that those link to, pulling
out the relevant bits of information, amending it for AS as
necessary, and assembling it into a plain HTML file that can be
embedded in the libraries and linked to by their SDEFs. But it needs
done, and it's a self-contained task so can be done without having
to spend time learning or working on the libraries themselves.
Oh, and thanks for flagging up a bunch of fresh problems with the
Date commands. (Dates and times are a giant PITA at the best of
times.) Obviously I need to extend the current test script to run
through all time zones automatically. Still, slowly getting there.
Cheers,
has
|