flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Schmalle <teotigraphix...@gmail.com>
Subject Re: [FalconJX] AS for Native HTML JS (was Re: [FalconJX FlexJS] JIRA issues and helping with the compiler)
Date Wed, 27 May 2015 20:13:55 GMT
On Wed, May 27, 2015 at 4:02 PM, Alex Harui <aharui@adobe.com> wrote:

> This is where, for Apache projects, it gets tricky/messy.  Tamarin code is
> MPL (or xGPL) and Apache doesn’t like have source code dependencies on
> those licenses.  You can have a dependency on compiled MPL code so if
> there was a swc in a stable place that contained those compiled Tamarin
> .as files then we’d be good to go.  Otherwise, we may need to get an
> exception or get Adobe to re-license.  Not sure how hard that will be.
> And just linking to Randori may be seen as a valid way to get around it
> either since the Randori folks are also Flex committers.

Ok, well I emailed Roland and asked if he could enlighten me it's been so
long, I feel dumb when talking about Randori.

We did not have playerglobal.swc and used FalconJX so it has to work and if
the wheel has already been created, I see no reason in reinventing it, we
would just use built, could I for instance as a separate entity "fork" that
repo to mine and then I maintain the code and compile it if wee need to,
then get the swc from my repo?

> >>>HTML.swc:
> >>> Window
> >>> Event
> >>> UIEvent
> >>> MouseEvent
> >>> HTMLElement
> >>> etc.
> >>>
> >>>
> >> See for HTML lib, Roland used WebIDL parser to create it;
> >>
> >> https://github.com/RandoriAS/randori-libraries/tree/master/HTMLCoreLib
> I couldn’t quickly find the rules around IDL and WebIDL Parser to figure
> out if we can do the same.  Can you point us to links and licenses?

I need Roland's advice here, I had nothing to do with this part of the

> >>
> >>
> >> Question; So the code style, you said we might use the FlexJS emitter
> >>but
> >> I don't see how that is possible since it's not a vanilla emitter.
> >>
> >> It seems to me I need to know the exact code style that a vanilla
> >> transpiler will create and I can make that emitter as another backend,
> >>what
> >> do you think?
> >>
> >> @Josj you have any thoughts? I am ready to start writing it. :)
> I’m not clear what isn’t vanilla about the current emitter if you are
> writing code against these two SWCs.  I don’t know how much Google Closure
> Library code will actually get sucked in.  But it seems reasonable to at
> least start with the FlexJS emitter then figure out what needs to change.

Hmm, ok maybe it's me being numb, I guess I am confusing the MXMLEmitter
with the JSEmitter. and what it's doing.

I swear I looked at the JSEmitter and it had a bunch of GCC stuff in it and
all the comments and such. If I was to maintain a straight transpiler I
would want it to be as clean and extensible as possible.

On that note; In the Randori emitter I used about 8 class compositions in
the JS emitter whcih decoupled a huge amount of code. I think we could do
that with the current GFLexJS emitter and share 1/2 to 2/3 of the code base
that exists right now.

What do you think?


> -Alex

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