flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From OmPrakash Muppirala <bigosma...@gmail.com>
Subject Re: [FALCON] Basic Tests pass
Date Fri, 25 Oct 2013 18:41:49 GMT
On Oct 25, 2013 11:00 AM, "Alex Harui" <aharui@adobe.com> wrote:
> On 10/25/13 10:03 AM, "Erik de Bruin" <erik@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
> >> 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
> >> 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.


> >
> >> And so next for me is BasicTests with the new MXML codegen, then
> >> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message