On Oct 25, 2013 11:00 AM, "Alex Harui" <aha...@adobe.com> wrote:
>
>
>
> 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.
>
If you can post your thoughts on what it would take to get the Installer to
support this, that would be good to know.
Thanks,
Om
> >
> >> 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
>
