I was just bitten again by the buggy Flash IDE compiler, which seems to be
particularly moronic handling the infamous classes cache. I've read a number
of posts about this issue, and have come across it in the pass, especially
when working with network shares (which, admitedly, is not the ideal
setting, although it's not an excuse for this bug, either), but I think I
finally understand how to reproduce it reliably and can make a (hopefully)
educated guess about why it happens.
A little background: when Flash got AS 2.0 and a class syntax (Flash 7 or
was it Flash 6?), the IDE compiler began using a cache to cut down the
compiling times for ActionScript code. Sounds neat, but the implementation
left lots to be desired. Amazingly, it still does, since these problems
continue to exist in CS3.
The idea is simple. When you compile some fla, the compiler looks up for all
referenced classes and pre-compile them into an intermediate file, with the
extension .aso (from Action Script Object, I think). Those files are then
linked into the swf, and remain stored in a directory in your local drive
for future reuse. That is, if you recompile the fla but haven't changed the
code in the classes, it won't be recompiled. The bytecode from pre-compiled
aso file will be used instead. So far, so good. (Yet, I wonder how much of
the net compiling time is actually spent compiling AS code; I have the
impression that usually most time is spent compiling assets).
How does the IDE know whether the code in a class has changed? Basically, it
assumes that it will be able to determine that by comparing the timestamps
of the .as file, the .aso file. (And they say assumption is the mother of
all fuck-ups... but I digress).
If the .as file timestamp is greater than the .aso file timestamp, it means
the source code has been modified and should be recompiled. Else, there
isn't anything new, so go ahead and use the .aso file.
But, as soon as you start interchanging files with other people (especially
if they are in different time zones), the problems begin.
Let's assume there are 2 people involved. John, who lives somewhere in the
Atlantic Time Zone (GMT -4) and Paul, who lives the Pacific Time Zone (GMT
-8).
Scenario 1:
Paul edits the class ClassesCacheBug.as at 1 pm and sends it over to John.
It's 5 pm for John. He has made a minor change and compiled the fla an hour
ago, and so the IDE has created an .aso file with a timestamp of 4 pm. Now
he compiles again with Paul's changes, but since 1 pm (.as file) < 4 pm
(.aso file), Flash will refuse to compile the new .as code and will use the
old .aso file instead. He notices it, and since this "feature" has bitten
him before, he remembers there are some
yet-to-be-actually-and-finally-fixed-problems-regarding-aso-files-instead-of-adding-a-delete-aso-files-command-nobody-should-really-give-a-hoot-about,
and so decides to flush the cache clicking on "Delete ASO Files and Test
Movie". Problem solved.
Scenario 2:
Next day. John modifies again ClassesCacheBug.as at 5 pm (East) and sends
the changes back to Paul (it's 1 pm in the West). Paul is also aware of the
.aso-related problems, and has recently flushed his cache to force Flash to
compile some other "rebel" .as file. He doesn't have ClassesCacheBug.aso in
his local drive anymore. So his clock reads 1 pm, the .as file was last
modified at 5 pm, and there is no .aso file. He tries to compile the fla and
the compiler whines:
The name of this class, 'ClassesCacheBug', conflicts with the name of
another class that was loaded, 'ClassesCacheBug'.
class ClassesCacheBug {
WTF is that supposed to mean? He flushes again the cache, but no joy. He
tries to figure out what could be wrong but he finds no logic in it. If the
.aso file doesn't exists, couldn't Flash just be so kind as to recompile the
damn thing without further ado? What else could it do anyway? It certainly
has the source code available and there's nothing to get from the cache to
begin with. But Flash wouldn't do it. Paul curses badly, helplessly tries
deleting ASO files again for the 30th time, invokes different voodoo spirits
and finally decides to use brute force. After trying some really weird
things, he sets the date to the next day. And now, lo and behold, Flash has
stops complaining and gets the swf compiled.
Let's say I've been in Paul's shoes an hour or so ago, and I thought I would
post this message about this (at least to me) new manifestation of this old
and known bug / feature in the Flash IDE, for venting a bit and hopefully
alerting other people who might run into this problem.
So, to sum up, from observing this rather stupid behavior (and of course,
without knowing what is actually going on in the Flash logic), the problem
happens in both Flash 8 and Flash CS3 when:
1) There is no ASO file
AND
2) AS timestamp > current local timestamp
Like if it was coded (and yes, I'm exaggerating now):
if(ASO exists) {
if(AS < ASO) {
use ASO
} else {
compile AS
}
} else {
if(AS < LOCAL_TIME) {
compile AS
} else {
refuse to compile and give some misleading and useless error message
}
}
The workaround: open and save all the .as files involved so the timestamps
are updated (no, thanks) or temporarily adjust your clock so your local date
is greater than the .as files' timestamp (quick and dirty, yet it works).
Cheers
Juan Pablo Califano
PD: Yes, I'm aware that this doesn't happen with MTASC, HAXE and the Flex
SDK, but sometimes the project has been setup already by someone as an IDE
project with no real version control and I just have to use an existing fla
to make some minor code changes (which is precisely what happened today).
_______________________________________________
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
