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