chricht-----
> Von: Gordon Smith [mailto:gsmit...@hotmail.com]
> Gesendet: Freitag, 25. Juli 2014 04:10
> An: dev@flex.apache.org
> Betreff: RE: AW: AW: AW: AW: AW: Falcon and Antlr4
>
>> I am sort of confused what JBurg is actually working on ... Does it directly
>> w
014 04:10
An: dev@flex.apache.org
Betreff: RE: AW: AW: AW: AW: AW: Falcon and Antlr4
> I am sort of confused what JBurg is actually working on ... Does it directly
> work on FalconAST or is there some sort of "ReducedFalconAST"?
The input to the BURM (Bottom-Up Rewrite Machine)
;t want to decouple JBurg from Antlr, one option would be for us to
fork JBurg and remove its dependency on the Antlr Stringtemplate. Is another
option for JBurg to continue using whatever old Antlr it has been using and the
AS and CSS lexer/parser to use the latest Antlr?
- Gordon
> From:
:57
An: dev@flex.apache.org
Betreff: AW: AW: AW: AW: AW: Falcon and Antlr4
So let's just define some words that might help avoid confusion.
A typical Antlr parser geneates a parse-tree consisting of Antlr objects ...
let's call that AntlrAST.
Falcon has it's own internal represe
e:
src/main/java
src/main/resources
src/main/antlr4
src/main/jburg
This way you don't have one directory with mixted content.
Chris
Von: Gordon Smith
Gesendet: Mittwoch, 23. Juli 2014 18:12
An: dev@flex.apache.org
Betreff: RE: AW: AW: AW:
xt part (If its not slower than the current solution I would
prefer the simpler process).
Chris
Von: Gordon Smith
Gesendet: Mittwoch, 23. Juli 2014 18:05
An: dev@flex.apache.org
Betreff: RE: AW: AW: AW: AW: Falcon and Antlr4
CSSTree.g isn't involved in compi
e to do comparisions, one using
JBurg and one not using it.
Personally, I always found JBurg difficult to understand and debug, so I'm not
necessarily against eliminating it.
- Gordon
> From: aha...@adobe.com
> To: dev@flex.apache.org; gsmit...@hotmail.com
> Subject: RE: AW: AW
compiler doesn't do them
then the code will execute slower. However, if cross-compilation to JavaScript
is the main goal for the future, then perhaps slower AVM execution is tolerable.
- Gordon
> From: christofer.d...@c-ware.de
> To: dev@flex.apache.org
> Subject: AW: AW: AW: AW:
m as a calculator ;-)
Chris
Von: Alex Harui
Gesendet: Mittwoch, 23. Juli 2014 08:48
An: dev@flex.apache.org
Betreff: Re: AW: AW: AW: Falcon and Antlr4
On 7/22/14 12:07 PM, "Christofer Dutz" wrote:
>The way I understood JBurg is that it seems to have bee
code will execute slower. However, if cross-compilation to
> JavaScript is the main goal for the future, then perhaps slower AVM execution
> is tolerable.
>
> - Gordon
>
>
>> From: christofer.d...@c-ware.de
>> To: dev@flex.apache.org
>> Subject: AW: AW: AW: A
Regarding the proposed directory structure... I'm not familiar with Maven
conventions. What is the purpose of the 'main' subdirectory in src/main/java?
- Gordon
> From: gsmit...@hotmail.com
> To: dev@flex.apache.org
> Subject: RE: AW: AW: AW: AW: Falcon and Antlr4
>
don
> From: christofer.d...@c-ware.de
> To: dev@flex.apache.org
> Subject: AW: AW: AW: AW: Falcon and Antlr4
> Date: Wed, 23 Jul 2014 12:54:15 +
>
> Hi Eric,
>
> The question is definitely not silly.
>
> I'm not planning on changing anything here.
.org
Betreff: Re: AW: AW: AW: Falcon and Antlr4
I'm not at all familiar with the inner workings of Falcon, but I know that
FalconJX relies heavily on the current Falcon AST. Will the new AST be
compatible with the old (that may be a silly question, but it's the only
one I know to ask)?
Ed
with as
> much ram as a calculator ;-)
>
>
> Chris
>
>
>
> Von: Alex Harui
> Gesendet: Mittwoch, 23. Juli 2014 08:48
> An: dev@flex.apache.org
> Betreff: Re: AW: AW: AW: Falcon and Antlr4
>
> On 7/22/14 12:07 PM, &quo
parser generates a stream of events which
can be processed allowing you to process petabyte big documents with as much
ram as a calculator ;-)
Chris
Von: Alex Harui
Gesendet: Mittwoch, 23. Juli 2014 08:48
An: dev@flex.apache.org
Betreff: Re: AW: AW: AW: F
On 7/22/14 12:07 PM, "Christofer Dutz" wrote:
>The way I understood JBurg is that it seems to have been designed to
>manipulate ASTs produced by Antlr2 and Antlr3.
>Therefore it has a compile and runtime dependency to Antlr (I also sort
>of dislike them bundling the generator together with the
adobe.com]
Gesendet: Dienstag, 22. Juli 2014 17:23
An: dev@flex.apache.org
Betreff: Re: AW: AW: Falcon and Antlr4
Interesting. I did not know that Jburg used Antlr.
Another option is to remove Jburg as well and see if a simple AST walk like
FalconJX uses is faster or not. I know for sure it
lexmojos falcon support first :-(
>
>Chris
>
>
>Von: Christofer Dutz
>Gesendet: Dienstag, 22. Juli 2014 10:06
>An: dev@flex.apache.org
>Betreff: AW: AW: Falcon and Antlr4
>
>Ok ... so I created a "falcon-antlr4" branch (Haven't comitted/pushed
>
doesn't look that complex, but I think I should concentrate on
Flexmojos falcon support first :-(
Chris
Von: Christofer Dutz
Gesendet: Dienstag, 22. Juli 2014 10:06
An: dev@flex.apache.org
Betreff: AW: AW: Falcon and Antlr4
Ok ... so I created a &q
how to approach this task and I think I's absolutely
manageable ... really looking forward to this.
Chris
Von: Gordon Smith
Gesendet: Donnerstag, 17. Juli 2014 17:11
An: dev@flex.apache.org
Betreff: Re: AW: Falcon and Antlr4
> why are we mixing up
> why are we mixing up several tools that all seem to be doing similar thing
Falcon's lexer and parser were borrowed from the Flash Builder code base, where
they supported various edit-time code intelligence features, but not
compilation. I think the Flash Builder team had determined that JFlex
Ok so that would have been my second question ... why are we mixing up several
tools that all seem to be doing similar things :-)
I definitely like to do some cleaning up. But depending on if any or which
talks are accepter for the ApacheCon I might have to finish some other things
first ;-)
C
22 matches
Mail list logo
