On 12/3/12 12:44 AM, "Frank Wienberg" wrote:
>> If you look at the prototype, it does not use nested object literals. I
>> was
>> unable to get them to perform as well as the data stream I am using or the
>> methods it is replacing.
>>
>
> So maybe we could output different code for debuggin
e like
> >>>>>>>>
> >>>>>>>> statement = Pattern labeledBreakStmt: 0
> >>>>>>>> JBurg.Reduction reducer.reduce_labeledBreakStmt(__p);
> >>>>>>>>
> >>>>>>>> tells
On Mon, Dec 3, 2012 at 6:45 AM, Alex Harui wrote:
> On 12/2/12 2:21 AM, "Frank Wienberg" wrote:
> > When you look at Jangaroo-generated JavaScript code, it closely resembles
> > the original ActionScript source code. We optimized the compiler as well
> as
> > the runtime to give the impression t
On 12/2/12 2:21 AM, "Frank Wienberg" wrote:
>>
> There is one important aspect to consider when deciding which route to take.
> If you, like Bernd Paradies, see JavaScript's role in this process as an
> machine language, it is completely valid to generate JS code from ABC.
Well, I would like
On 12/2/12 4:36 AM, "Michael Schmalle" wrote:
>
> I keep looking at the current FalconJS code generator and it's way
> over my head. I couldn't contribute to it until I knew how to use a
> couple key low level features such as ABC and JBurg. For now I have no
> reason and time to invest that
rule like
>>>>>>>>
>>>>>>>> statement = Pattern labeledBreakStmt: 0
>>>>>>>> JBurg.Reduction reducer.reduce_labeledBreakStmt(__p);
>>>>>>>>
>>>>>>>> tells the BURM w
is was Bernd's
approach when he
developed FalconJS. You just make the reduce_XXX() method
produce JS strings
rather than ABC InstructionLists.
- Gordon
-Original Message-
From: Michael Schmalle [mailto:apa...@teotigraphix.com]
Sent: Friday, November 30, 2012 4:11 PM
To: flex-dev@incuba
approach when he
developed FalconJS. You just make the reduce_XXX() method
produce JS strings
rather than ABC InstructionLists.
- Gordon
-Original Message-
From: Michael Schmalle [mailto:apa...@teotigraphix.com]
Sent: Friday, November 30, 2012 4:11 PM
To: flex-dev@incubator.a
approach when he
developed FalconJS. You just make the reduce_XXX() method produce JS strings
rather than ABC InstructionLists.
- Gordon
-Original Message-
From: Michael Schmalle [mailto:apa...@teotigraphix.com]
Sent: Friday, November 30, 2012 4:11 PM
To: flex-dev@incubator.apache.org
Subject:
gt;>>>> of "reduce_XXX()" methods for reducing various subtrees.
>>>>>>
>>>>>> 3. The result of a "reduction" can be any Java object which somehow
>>>>>> represents
>>>>>> the subtree that got reduced. Oft
InstructionLists.
- Gordon
-Original Message-
From: Michael Schmalle [mailto:apa...@teotigraphix.com]
Sent: Friday, November 30, 2012 4:11 PM
To: flex-dev@incubator.apache.org
Subject: RE: [FlaconJS] pseudo emitter algorithm
Quoting Gordon Smith :
I didn't follow the whole discu
ent stmts*);
>>>>
>>>> For example, this says that a block statement is a BlockNode with multiple
>>>> child nodes which have been reduced to a 'statement'.
>>>>
>>>> The BURM patterns and rules should be mostly the same wheth
Hi Alex,
perhaps I did not make the point about the output packaging format so clear.
Of course, for compilation reference, an SWC would suffice. But for
Jangaroo, it did not make any sense to use SWC or SWF for packaging, as we
would have needed to implement an additional format. Also, scanning t
Hi Frank,
Based on the last week of my rambling I know one thing, I don't have
enough knowledge of JavScript to be leading any concrete decisions
regarding the actual implementation.
I read up on the source maps, this does seem like a logical route
browser vendors would take since eventua
Sorry for joining this discussion so late. Like before, I just would like
to contribute how we approached the problem at Jangaroo.
Some time ago, we created our own declarative, XML-based language, targeted
at creating Ext JS UIs, thus called EXML. EXML is very similar to MXML. The
main difference
On 12/1/12 12:52 AM, "Daniel Wasilewski" wrote:
>>
> And that was my understanding as well. IT looks like you talking about
> ABC AST as the joint point. I don't know how different it might be from
> AS AST when you can rely on top level abstract set of OOP properties,
> when ABC seems to be
hen he developed FalconJS. You just make
the reduce_XXX() method produce JS strings rather than ABC
InstructionLists.
- Gordon
-Original Message-
From: Michael Schmalle [mailto:apa...@teotigraphix.com]
Sent: Friday, November 30, 2012 4:11 PM
To: flex-dev@incubator.apache.org
Subject: RE: [F
: Michael Schmalle [mailto:apa...@teotigraphix.com]
Sent: Friday, November 30, 2012 4:11 PM
To: flex-dev@incubator.apache.org
Subject: RE: [FlaconJS] pseudo emitter algorithm
Quoting Gordon Smith :
I didn't follow the whole discussion. Is the issue that you were
planning to work on MXM
The conversation was about exploring a straight AST to JS convertor
and bypassing the JS emitting using SWF reducer.
My point was in the discussion that I don't know SWF format and JBurg
so trying to maintain FalconJS in it's current state would be hard for
a lot of developers.
A lot of
>> planning to work on MXML->JS but Alex and I think
>>>> MXML->datastructure is a better approach? You don't have to accept
>>>> what we say. :)
>>>>
>>>> - Gordon
>>>
>>> The conversation was about exploring a st
hink you'd be doing most of your work
>> inside the JSGeneratingReducer. I believe this was Bernd's approach when he
>> developed FalconJS. You just make the reduce_XXX() method produce JS strings
>> rather than ABC InstructionLists.
>>
>> - Gordon
>>
>>
reduced. So I really think you'd be doing most of your work
> inside the JSGeneratingReducer. I believe this was Bernd's approach when he
> developed FalconJS. You just make the reduce_XXX() method produce JS strings
> rather than ABC InstructionLists.
>
> - Gordon
>
ething...
What do you think?
> -Original Message-
> From: Michael Schmalle [mailto:apa...@teotigraphix.com]
> Sent: Friday, November 30, 2012 3:55 PM
> To: flex-dev@incubator.apache.org
> Subject: RE: [FlaconJS] pseudo emitter algorithm
>
> Well considering the conversa
On 11/30/12 4:15 PM, "Michael Schmalle" wrote:
>
> Ok so instead of emitting JS from MXML generated ABC you want to emit
> it from MXML generated data structure from the AST?
I'm not sure yet. I just found the code I did a year ago. I made changes
to MXMLClassDirectiveProcessor and never ch
Quoting Alex Harui :
On 11/30/12 3:55 PM, "Michael Schmalle" wrote:
Well considering the conversation between you two, I will ditch pretty
much all I said in the last 3 days. This is what I get for living on a
mountain...
I'm not sure what we said that would change your mind. I thought l
om]
Sent: Friday, November 30, 2012 3:55 PM
To: flex-dev@incubator.apache.org
Subject: RE: [FlaconJS] pseudo emitter algorithm
Well considering the conversation between you two, I will ditch
pretty much all I said in the last 3 days. This is what I get for
living on a mountain...
I have
teotigraphix.com]
Sent: Friday, November 30, 2012 3:55 PM
To: flex-dev@incubator.apache.org
Subject: RE: [FlaconJS] pseudo emitter algorithm
Well considering the conversation between you two, I will ditch pretty much all
I said in the last 3 days. This is what I get for living on a mountain...
I have
On 11/30/12 3:55 PM, "Michael Schmalle" wrote:
> Well considering the conversation between you two, I will ditch pretty
> much all I said in the last 3 days. This is what I get for living on a
> mountain...
I'm not sure what we said that would change your mind. I thought lots of
folks, includ
..@adobe.com]
Sent: Friday, November 30, 2012 3:29 PM
To: flex-dev@incubator.apache.org
Subject: Re: [FlaconJS] pseudo emitter algorithm
On 11/30/12 3:22 PM, "Gordon Smith" wrote:
MXML->JS doesn't exist and is not the way to go.
MXML->datastructure is a good idea. Alex will
Subject: Re: [FlaconJS] pseudo emitter algorithm
On 11/30/12 3:22 PM, "Gordon Smith" wrote:
> MXML->JS doesn't exist and is not the way to go.
> MXML->datastructure is a good idea. Alex will do it first for
> MXML->interpretation
> by JS and later for inte
On 11/30/12 3:22 PM, "Gordon Smith" wrote:
> MXML->JS doesn't exist and is not the way to go.
> MXML->datastructure is a good idea. Alex will do it first for interpretation
> by JS and later for interpretation by an ABC library written in AS.
I'm pretty sure I had this all working last year in
S.
- Gordon
-Original Message-
From: Alex Harui [mailto:aha...@adobe.com]
Sent: Friday, November 30, 2012 3:04 PM
To: flex-dev@incubator.apache.org
Subject: Re: [FlaconJS] pseudo emitter algorithm
OK, what did I write that is confusing everybody?
IIUC, MXML is parsed into a different set of n
OK, what did I write that is confusing everybody?
IIUC, MXML is parsed into a different set of nodes which are then visited in
the tree walk to generate ABC codes directly. When compiling the AS in an
MXML script block or a .AS file, the AS AST nodes go through Jburg and
eventually become ABC.
F
I'm trying to follow, but I feel the same.
My main confusion came from the one thing. I've got in my mind AST is
just AST. Abstract by definition. It represents a code logic in abstract
form.
Why JS would collide with AS? Why the Falcon after AST coming back to
AS? AST says, create class, crea
Ok, I'm a bit confused but my brain is probably going to explode any
minute and that is about all from me for a bit.
I'll just sit back and see if any other conversations come up about as
-> js. Maybe I'm crazy and just want to create more work for myself.
Maybe the way it stands ABC -> js
On 11/30/12 11:05 AM, "Michael Schmalle" wrote:
> Quoting Gordon Smith :
>
>> I don't object to generating a data structure for V11, but I think
>> that it makes more sense to do that as a second phase after ABC
>> generation is working. Otherwise there are a lot of moving parts and
>> progre
]
Sent: Friday, November 30, 2012 10:54 AM
To: flex-dev@incubator.apache.org
Subject: RE: [FlaconJS] pseudo emitter algorithm
Before I do much more work on Falcon's MXML, we need to decide
whether we're completing MXML->ABC or discarding that work.
- Gordon
-Original Message---
udo emitter algorithm
I recommend completing MXML->ABC first and later switching over to
MXML->datastructure.
- Gordon
-Original Message-
From: Michael Schmalle [mailto:apa...@teotigraphix.com]
Sent: Friday, November 30, 2012 10:58 AM
To: flex-dev@incubator.apache.org
Subject: RE: [FlaconJ
a re you saying leave MXML in a model state?
Mike
>
> -Original Message-
> From: Alex Harui [mailto:aha...@adobe.com]
> Sent: Friday, November 30, 2012 10:46 AM
> To: flex-dev@incubator.apache.org
> Subject: Re: [FlaconJS] pseudo emitter algorithm
>
>
>
>
> O
:gosm...@adobe.com]
Sent: Friday, November 30, 2012 10:54 AM
To: flex-dev@incubator.apache.org
Subject: RE: [FlaconJS] pseudo emitter algorithm
Before I do much more work on Falcon's MXML, we need to decide whether we're
completing MXML->ABC or discarding that work.
- Gordon
---
a model state?
Mike
-Original Message-
From: Alex Harui [mailto:aha...@adobe.com]
Sent: Friday, November 30, 2012 10:46 AM
To: flex-dev@incubator.apache.org
Subject: Re: [FlaconJS] pseudo emitter algorithm
On 11/30/12 10:33 AM, "Michael Schmalle" wrote:
My point is
g
Subject: Re: [FlaconJS] pseudo emitter algorithm
On 11/30/12 10:33 AM, "Michael Schmalle" wrote:
>
> My point is, we would create a .js generator for MXML dialect. It
> "might" even be adeventagious for us to create this implementation
> becasue we "could&
On 11/30/12 10:33 AM, "Michael Schmalle" wrote:
>
> My point is, we would create a .js generator for MXML dialect. It
> "might" even be adeventagious for us to create this implementation
> becasue we "could" treat some parts of MXML differently than a plain
> ole ActionScript class.
>
Yup, b
0xFF);
- Gordon
-Original Message-
From: Michael Schmalle [mailto:apa...@teotigraphix.com]
Sent: Friday, November 30, 2012 10:36 AM
To: flex-dev@incubator.apache.org
Subject: RE: [FlaconJS] pseudo emitter algorithm
Gordon, can you give me a couple class references to look at?
Can these
ut not a BURM.
- Gordon
-Original Message-
From: Alex Harui [mailto:aha...@adobe.com]
Sent: Friday, November 30, 2012 10:08 AM
To: flex-dev@incubator.apache.org
Subject: Re: [FlaconJS] pseudo emitter algorithm
On 11/30/12 9:45 AM, "Michael Schmalle" wrote:
A note about MXM
Quoting Alex Harui :
On 11/30/12 9:45 AM, "Michael Schmalle" wrote:
A note about MXML, since the parse DOES create and AST during parsing
of an MXML file, and MXML uses the IDefinition API, we can catch MXML
code at the same intersection we are getting the AS code at, the AST
definition sta
MXML codegen uses a "class directive processor" but not a BURM.
- Gordon
-Original Message-
From: Alex Harui [mailto:aha...@adobe.com]
Sent: Friday, November 30, 2012 10:08 AM
To: flex-dev@incubator.apache.org
Subject: Re: [FlaconJS] pseudo emitter algorithm
On 11/30/
On 11/30/12 9:45 AM, "Michael Schmalle" wrote:
> A note about MXML, since the parse DOES create and AST during parsing
> of an MXML file, and MXML uses the IDefinition API, we can catch MXML
> code at the same intersection we are getting the AS code at, the AST
> definition stage.
OK, I wasn't
Quoting Alex Harui :
On 11/30/12 8:56 AM, "Michael Schmalle" wrote:
My only question was, were the engineers doing anything specific with
resolutions and such with the SWF.
My guess is that the engineers were just leveraging the file output portion
of Falcon. I pondered whether having t
On 11/30/12 8:56 AM, "Michael Schmalle" wrote:
>
> My only question was, were the engineers doing anything specific with
> resolutions and such with the SWF.
My guess is that the engineers were just leveraging the file output portion
of Falcon. I pondered whether having the SWF constant pool
Alex,
I have no idea what I am talking about. :)
I have not dealt with enterprise things at all. I'm just a programmer
in the woods so to speak.
I am just trying to clarify things before I head out on an arduous
path of creating some js from AST.
I do agree that there has to be savings b
You guys have lost me a bit.
IMO, all I want as output is a series of .JS files (that would later get
minified by GCC for release builds). I don't get how the JSEmitter's
reliance on SWF output constructs like traits would affect the output.
Seems like you should be able to generate the same thin
Quoting Frank Wienberg :
On Thu, Nov 29, 2012 at 6:42 PM, Michael Schmalle
wrote:
For FalconJS this process is totally bound to SWF format.
This was my point. For any developer to fix bugs here they have to know
the SWF format. Which I don't.
This is why I propsed another solution using pure
On Thu, Nov 29, 2012 at 6:42 PM, Michael Schmalle
wrote:
> For FalconJS this process is totally bound to SWF format.
>
> This was my point. For any developer to fix bugs here they have to know
> the SWF format. Which I don't.
>
> This is why I propsed another solution using pure AST like Jangaroo
OK, I think I get it now. Sounds like it is worth exploring.
On 11/29/12 10:02 AM, "Michael Schmalle" wrote:
> Quoting Alex Harui :
>
>> So if I understand you, the notion of traits is a SWF thing? The AST has
>> different representations maybe like member, variable, function?
>
> Well yes
Quoting Alex Harui :
So if I understand you, the notion of traits is a SWF thing? The AST has
different representations maybe like member, variable, function?
Well yes and no.
Traits IS an SWF thing. The AST is represented by like IClassNode,
IPackageNode etc.
Than we have an even more f
So if I understand you, the notion of traits is a SWF thing? The AST has
different representations maybe like member, variable, function?
On 11/29/12 9:42 AM, "Michael Schmalle" wrote:
> Quoting Alex Harui :
>
>> Very nice. Have you figured out the role of the generated CMCEmitter in
>> this
I'm typing to much (correction).
The CmcJSEmitter is used to "Generate an ABC file equivalent to the
input syntax tree."
NOT
traverse. The CmcJSEmitter traverses the AST and creates the SWF that
is then used to create the JS output.
Mike
Quoting Michael Schmalle :
Quoting Alex Harui
Quoting Alex Harui :
Very nice. Have you figured out the role of the generated CMCEmitter in
this process?
Yes,
The CmcJSEmitter (autogenerated by cmc-js.jbg) is used to traverse the
ISWF that is created.
The CmcJSEmitter and JSGeneratingReducer are created in the
JSGenerator construct
Very nice. Have you figured out the role of the generated CMCEmitter in
this process?
On 11/29/12 7:30 AM, "Michael Schmalle" wrote:
> Hi,
>
> For those asking question about "where to alter" code, it's not pretty
> but I think I know exactly what is going on now.
>
> If you can understand b
Thanks for detailed explanation Mike!
Everything below that, is actually clear without getting into details of
recursive methods itself.
On 11/29/2012 3:30 PM, Michael Schmalle wrote:
Hi,
For those asking question about "where to alter" code, it's not pretty
but I think I know exactly what
Thanks, Mike!
EdB
On Thu, Nov 29, 2012 at 4:30 PM, Michael Schmalle
wrote:
> Hi,
>
> For those asking question about "where to alter" code, it's not pretty but I
> think I know exactly what is going on now.
>
> If you can understand below, you will now have some insight to where and how
> the
Hi,
For those asking question about "where to alter" code, it's not pretty
but I think I know exactly what is going on now.
If you can understand below, you will now have some insight to where
and how the JS code actually gets created.
! Call the compiler load config compile().
JSGener
63 matches
Mail list logo
