Lies! Apple is full of lies!

| | Comments (0)

An Apple tech note says:

The AEBuild* suite of routines provide simple to use and easy to maintain facilities for constructing complex Apple event structures in memory for sending information to other applications. AEPrint provides a symmetrical pretty printer routine for viewing complex Apple event structures as strings formatted using the same syntax as the strings AEBuild* is able to read.

And later, more explicitly:

When AEPrintDescToHandle is asked to print an AEDesc, an AERecord, or an AEDescList, then the format of the printed output will match the input expected by AEBuildDesc.

Similarly, in the API docs, Apple says:

AEPrintDescToHandle prints the contents of AEDesc, AERecord, and AEDescList descriptors in a format that is suitable for input to AEBuildDesc. AEPrintDescToHandle also attempts display coerced Apple event records as the coerced record type instead of as the original type. Any data structures that cannot be identified are displayed as hexadecimal data.

Don't be fooled, though. It's a pack of lies.

I was writing some tests and took this at its word, thinking I could just make slight modifications to the AEPrint output. Indeed, however, if you feed AEPrint output back intp AEBuild, it will fail, because the AEPrint output is broken severely.

In just one simple test with an object descriptor record, it's easy to see some of the problems:

print AEPrint(AEBuild(q['obj '{ 'want':type(prop), 'name':'prop', 'from':'null'(), 'seld':type(sdsk) }]));
# <- 'obj '{ 'want':type(prop), 'name':'prop', 'from':'null'(),   'seld':type(sdsk) }
# -> 'obj '{ 'want':'prop',     'name':'prop', 'from':''null''(), 'seld':'sdsk' }

The first thing to notice is the difference between type(prop) and prop. By default, the string would be taken as an enum (as the docs note), so it is coerced to a type in the former. But according to AEPrint's output, those are enums, not types. That's a run-time error. Similar too for type(sdsk). So while AEPrint "attempts (to) display coerced Apple event records as the coerced record type instead of the original type," it fails.

The other thing which is just crazy is the double-single-quotes around null. That's a compile-time syntax error (which is helpfully placed in $@, as: Expected "," or "}" at character 53).

There's probably more, as my tests are pretty inexhaustive. One more thing to note, though: AEPrint will truncate binary data (rendered in hex, such as ($DEADBEEF$)) if it gets too long, so it's one more reason you can't just feed back the AEPrint output to AEBuild.

I also can't find out how floats are supposed to be passed in. The docs say I can do float(@) and pass in the float as an argument (AEBuild works sorta like sprintf), but that doesn't seem to work. Nor does passing integers in as arguments (such as long(@)), although for those, I can include it literally in the format string, instead of passing it in as an argument.

But, as those problems having nothing to do with the Intel port, it's time to move on, for now.

Leave a comment

<pudge/*> (pronounced "PudgeGlob") is thousands of posts over many years by Pudge.

"It is the common fate of the indolent to see their rights become a prey to the active. The condition upon which God hath given liberty to man is eternal vigilance; which condition if he break, servitude is at once the consequence of his crime and the punishment of his guilt."

About this Entry

This page contains a single entry by pudge published on June 17, 2006 9:02 PM.

Mac::Carbon Porting Day ... What? was the previous entry in this site.

Mac::AppleEvents Porting is the next entry in this site.

Find recent content on the main index or look in the archives to find all content.