Closed teotigraphix closed 8 years ago
I haven't seen that error before. However, I don't think I've actually tried building a library project with the Feathers SDK yet. Well, other than the SWC files that are included in the SDK.
Are you referencing feathers.swc in your library project? If so, where exactly did you get this SWC? I'm asking because you might run into trouble if you try to use a feathers.swc that didn't come from your copy of the Feathers SDK.
I am using the SDK's libs directory. (FeathersSDK/frameworks/libs) as a Global Library in IDEA for "code highlighting" and then the normal Feathers SDK entry for building.
My projects are pretty complex with some deps so I haven't tried to really narrow if I have some weird circular conflict but I don't think I do.
I realized, after I asked you that question, that it didn't make sense. The appropriate feathers.swc would be loaded automatically by the IDE.
You can close this if you want, since I doubt it will be anything you can figure out. Was more a question to see if you had run into it.
I'll leave it open, in case anyone else has the same issue and they can provide more details.
I was just working in FB 4.7 and I get this same error with a Library Project.
Basically I have ONE library project and just try to use [Bindable] in it and I get the "Unknown error".
So this means it's a problem with the SWC compiler and not just IntelliJ.
I can reproduce. Thanks.
It appears to be related to using [Bindable] metadata without an explicit event. When I specified an event, like [Bindable("change")], it works. Weird.
So that means I have to add dispatchEvent to use it correct? I didn't even think to try that. Being able to add Bindable in a SWC would be great now. :)
Maybe there is a null pointer in the code generation or something. So the unknown error is catching something like that.
So that means I have to add dispatchEvent to use it correct?
Yeah, you'll need to dispatch the event manually when you specify it in the metadata.
Maybe there is a null pointer in the code generation or something. So the unknown error is catching something like that.
When compiling with compc on the command line, I see "Error: null" in the output. I just need to find where that's happening.
OT - Do you still use FB for any dev?
I only test with Flash Builder. I do real development in IntelliJ IDEA.
More details: The result of analyzeClass() at BindableFirstPassEvaluator line 254 is unexpectedly returning null.
ClassInfo classInfo = typeTable.getSymbolTable().getTypeAnalyzer().analyzeClass(context, new MultiName(NameFormatter.toColon(NodeMagic.getClassName(node))));
If I recall correctly, I encountered the same "Error: null" message at this location when I was originally working on adding support for [Bindable]. I tried to call bindableInfo.getClassInfo() and received null. Using analyzeClass() instead was an alternate solution that worked for the mxmlc compiler. It seems that is not the case in compc, for some reason.
I'm going to be getting some time coming up in the spring, I use this MXML stuff so heavily now in my business I am thinking about Falcon support. I pretty much know that compiler inside and out and am curious what I would have to do to get initial hello world happening with it.
Josh, FYI I am seriously thinking about this, do you see anything that would be a no go or do you think you could offer some guidance to get me going on principles some time?
That would be really cool, Mike! Off the top of my head, there needs to be some kind of Starling initialization that happens behind the scenes. The older compiler generates a class that extends feathers.core.StarlingBootstrap
, and it overrides a method named info()
.
As I understand it, Falcon handles binding a little differently than the older compiler. I haven't looked into the details, but Alex said that more happens on the ActionScript side. A lot of code is generated by the older compiler for binding, so this part could be challenging.
If you can get a prototype up and limping, I can probably handle cleaning up the rest.
Okay, I've been doing some more investigation, and I figured out why the call to analyzeClass() in BindableFirstPassEvalulator works in mxmlc but not compc.
In mxmlc, it works because the class with [Bindable] metadata is pretty much always referenced by another class that gets handled first. The [Bindable] class will already be registered in the SymbolTable. In compc, it may not be referenced by anything, so it won't be in the SymbolTable yet.
So I was able to move the import into a different class after the SymbolTable was populated, and it appears to be working!
Just curious if you have ever run into this before trying to use [Bindable] in a library project.
Months ago I go it as well but just was tinkering again with a mxml component in a library and ran into this again.