On 10/25/13 10:03 AM, "Erik de Bruin" <e...@ixsoftware.nl> wrote:
>>Yes, some were linebreaks, that look like they came from 'older' FB or
>other IDE - since it didn't occur in my major project that was brought
>through multiple versions; but they did occur in code I downloaded for
>a recent addition. But they weren't all linebreaks. Some were at the
>start of a line (after the whitespace) and reported like this:
>
> ?if (this) {
> ^
>
>Where the question mark turned out to be an 'invisible' character.
OK, sounds like we should collect a list of chars and add them. Can you
file a bug and attach a couple of files that have the problem?
>>There is no embedded font support in Falcon at this time, so running
>> Mustella is guaranteed to generate a lot of failures. I suppose that
>>some
>> energetic person could make a branch that doesn't have the embedded font
>> libraries and use MXMLC and generate all new baselines and fix
>> AssertPropertyValues that expect numbers based on embedded font metrics
>> and then prove that Falcon can run and pass all of these tests, but
>>maybe
>> it would be better to either add in the ability to handle the Adobe font
>> libraries, or write an embedded font library that can be used both for
>> Falcon and for MXMLC so we can remove another dependency on Adobe
>> proprietary stuff.
>
>Ok, that first option sounds worth a try; not to entire thing, that
>would have to be automated somehow, but a proof of concept, like with
>the Label I was looking at. How do I remove embedded font support?
>Just download the SDK and answer 'no' to a question during the build,
>or do I need to manually remove/change stuff?
I haven't tried it, but yes, I think just not downloading or removing the
embedded font jars is sufficient.
FWIW, I was pondering whether it is a good test or not to simply run every
test and not care whether it passes or fails but only care if it throws
exceptions. I'm wondering what percentage of remaining bugs are subtle
enough to change results. Maybe most or all remaining bugs are going to
cause exceptions, especially verify errors.
>
>>>I think this is all very impressive, and I think with a little more
>>>work, and A LOT MORE TESTING, we are getting close...
>> Agreed. Not sure how to do that "more testing" other than having folks
>> try it.
>
>Well, making sure Mustella runs 'fairly' and passes would be 'a lot'
>of testing... But yes, we should work towards allowing people to play
>with this... Maybe create something that can overlay Falcon over an
>otherwise fully build SDK?
Yeah, an overlay "script" might be useful. I was thinking we'd beat up
Falcon a bit more then start talking about how to release it.
>
>> And so next for me is BasicTests with the new MXML codegen, then getting
>> my internal customer's huge app to get off the ground with the new MXML
>> codegen, and then, getting the huge app to cross-compile with FalconJX.
>
>I must have missed something... Is there another new MXML codegen?
>Something that's currently not included in Falcon?
The -compiler.mxml.children-as-data option is required for FlexJS and an
option for the current SDK. Without it, Falcon generates the same codegen
as MXMLC. The flag changes the MXML codegen to be data instead of code so
that Falcon can be more independent of Flex SDK versions, which is desired
if we release it separately from the SDK. The goal is to move all "code"
into the SDK itself. Right now, certain kinds of bug fixes, especially to
startup code, require knowing how to change the MXMLC compiler. I think
life would be better if that wasn't the case, and is definitely important
in abstracting differences between AS and JS output.
-Alex
