You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Erik de Bruin <er...@ixsoftware.nl> on 2012/12/27 11:39:23 UTC
[FalconJx::GoogEmmitter] Moving forward
Mike,
I've spent some time with the js.codegen this week... Nietzsche was
right: "Battle not with monsters lest ye become a monster; and if you
gaze into the abyss the abyss gazes into you." Having said that, I
think I might be ready to contribute to that part of FalconJx.
What are your plans (moving the project to the falcon/ repo so 'the
public' can commit; refactoring, etc.)?
EdB
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [FalconJx::GoogEmmitter] Moving forward
Posted by Frank Wienberg <fr...@jangaroo.net>.
On Thu, Dec 27, 2012 at 11:56 AM, Michael Schmalle
<ap...@teotigraphix.com>wrote:
> Also did a trick to allow a hook into the beginning of a function block to
> inject code. We can do that anywhere it's needed, I don't see a lot of
> situations like that though.
There is something quite similar in Jangaroo's JSCodeGenerator: you can
inject any CodeGenerator into a function, making it generate code at the
beginning of its body.
Another situation where I needed that was an aliased "this" reference (var
$this=this;) to be able to access it in inner anonymous functions. If it is
needed multiple times (i.e. by several anonymous functions), the alias
assignment is still generated only once.
-Frank-
Re: [FalconJx::GoogEmmitter] Moving forward
Posted by Erik de Bruin <er...@ixsoftware.nl>.
Ah, I think a 'never mind' is in order. Update early and update often :-)
My bad,
EdB
On Thu, Dec 27, 2012 at 12:06 PM, Erik de Bruin <er...@ixsoftware.nl> wrote:
>> The object is to NOT comment out or override anything in the ASBlockWalker.
>> I refactored that parameter code to the base ASEmitter, added API and then
>> overrode the method in JSGoogEmitter. Get it?
>
> Got it. Question: various methods in ASBlockWalker call
> 'emitter.write' explicitely. If I don't comment out those lines, or
> override those methods, how can I prevent those emits messing with the
> JS output? Case in point: in 'visitParameter()', a colon is emitted
> right before the TypeNode is parsed...
>
> EdB
>
>
>
> --
> Ix Multimedia Software
>
> Jan Luykenstraat 27
> 3521 VB Utrecht
>
> T. 06-51952295
> I. www.ixsoftware.nl
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [FalconJx::GoogEmmitter] Moving forward
Posted by Erik de Bruin <er...@ixsoftware.nl>.
> The object is to NOT comment out or override anything in the ASBlockWalker.
> I refactored that parameter code to the base ASEmitter, added API and then
> overrode the method in JSGoogEmitter. Get it?
Got it. Question: various methods in ASBlockWalker call
'emitter.write' explicitely. If I don't comment out those lines, or
override those methods, how can I prevent those emits messing with the
JS output? Case in point: in 'visitParameter()', a colon is emitted
right before the TypeNode is parsed...
EdB
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [FalconJx::GoogEmmitter] Moving forward
Posted by Michael Schmalle <ap...@teotigraphix.com>.
Sounds fine to me.
I'm still on vacation here, with a huge snow storm, so my day is going
to consist of moving snow and clearing driveways.
I might do that refactor later, but I'm not sure today. :)
Mike
Quoting Erik de Bruin <er...@ixsoftware.nl>:
> My day is really nearly over, so I won't do anything but dig around a
> bit more to get more 'into' the code. So you go ahead with your todo,
> please.
>
> Once I've figured out what I can do and how I should do it, I'll
> notify you to see if we're in a state to receive my efforts.
>
> Ok?
>
> EdB
>
>
>
> On Thu, Dec 27, 2012 at 3:09 PM, Michael Schmalle
> <ap...@teotigraphix.com> wrote:
>>
>> Quoting Erik de Bruin <er...@ixsoftware.nl>:
>>
>>> Excellent.
>>>
>>> Mike, question: can we somehow separate out the 'goog' specific code
>>> some more? Just wondering... If someone wants to start a different
>>> parsing for JS, it might be less work to separate out 'goog' entirely
>>> at this point than try and do that only when the need arises. I was
>>> thinking about the JSDocEmitter, which can do with an extra layer of
>>> abstraction, I think. And some code in JSEmitter is also 'goog'
>>> specific. As this requires 'some' refactoring, I'm hesitant to start
>>> without consulting with you first ;-)
>>
>>
>> Actually, the intent was that the JSEmitter holds all code that is universal
>> to JS.
>>
>> You are seeing reminiscence of goog because I haven't taken it all out yet
>> with the refactors.
>>
>> So, goog needs to be completely ripped out of the JSEmitter. I really don't
>> think we need another layer, since if you take out the goog stuff from
>> JSEmitter like I was going to do, you already have that layer in the
>> JSGoogEmitter.
>>
>> Does this make sense?
>>
>> The jsdoc emitter is the same, I need an injection point to give the emitter
>> an instance of it from the backend implementation. Probably need an
>> interface like IDocEmitter the IJSGoogEmitter extends.
>>
>> Anyway, what do you want to do, because that is to close of quarters for me
>> to work today if you are refactoring the JSEmitter.
>>
>> Mike
>>
>>
>>
>>
>>
>>> EdB
>>>
>>>
>>> On Thu, Dec 27, 2012 at 2:21 PM, Michael Schmalle
>>> <ap...@teotigraphix.com> wrote:
>>>>
>>>> Looks good Erik!
>>>>
>>>> Welcome to the party. Like I said, lets try to communicate what we are
>>>> working on so we aren't creating merge conflicts, I hate those.
>>>>
>>>> Not much I would have done differently. Just 1 thing;
>>>>
>>>> Pay special attention to indents a newlines.
>>>>
>>>> foo.bar.A.method1 = function(p1, p2, p3, p4) {
>>>> p3 = typeof p3 !== 'undefined' ? p3 : 3;
>>>> p4 = typeof p4 !== 'undefined' ? p4 : 4;
>>>>
>>>> return p1 + p2 + p3 + p4;
>>>> }
>>>>
>>>>
>>>> should probably be;
>>>>
>>>> foo.bar.A.method1 = function(p1, p2, p3, p4) {
>>>> p3 = typeof p3 !== 'undefined' ? p3 : 3;
>>>> p4 = typeof p4 !== 'undefined' ? p4 : 4;
>>>> return p1 + p2 + p3 + p4;
>>>> }
>>>>
>>>> Without the newline to keep the code generation consistent. How would I
>>>> get
>>>> it to work? ...svn update :)
>>>>
>>>> Check out my last commit 5 minutes ago. If you are confused why and what
>>>> I
>>>> did ask.
>>>>
>>>> PS For block headers, there is a special handling of indents with no body
>>>> code AST.
>>>>
>>>>
>>>> Mike
>>>>
>>>>
>>>>
>>>> Quoting Erik de Bruin <er...@ixsoftware.nl>:
>>>>
>>>>> Mike,
>>>>>
>>>>> I've implemented and committed an alternative way of handling default
>>>>> parameter values, including a test. Not particularly to make my point
>>>>> with regard to which we should use (if we have to chose at all), but
>>>>> mostly to see how I can contribute from my end.
>>>>>
>>>>> Please let me know how I did and what you would like me to do
>>>>> differently. Thanks.
>>>>>
>>>>> EdB
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Dec 27, 2012 at 11:56 AM, Michael Schmalle
>>>>> <ap...@teotigraphix.com> wrote:
>>>>>>
>>>>>>
>>>>>> Hey,
>>>>>>
>>>>>> I have no plans other than to keep trudging away. There is still a lot
>>>>>> of
>>>>>> work to be done.
>>>>>>
>>>>>> As far as moving to the falcon repo, I don't want to do that yet. You
>>>>>> are
>>>>>> more than welcome to commit code where it is (just happens to be in my
>>>>>> whiteboard).
>>>>>>
>>>>>> Did you notice what I did to implement the parameters? If you havn't,
>>>>>> you
>>>>>> might want to take a look at the commit and diffs.
>>>>>>
>>>>>> The object is to NOT comment out or override anything in the
>>>>>> ASBlockWalker.
>>>>>> I refactored that parameter code to the base ASEmitter, added API and
>>>>>> then
>>>>>> overrode the method in JSGoogEmitter. Get it?
>>>>>>
>>>>>> Also did a trick to allow a hook into the beginning of a function block
>>>>>> to
>>>>>> inject code. We can do that anywhere it's needed, I don't see a lot of
>>>>>> situations like that though.
>>>>>>
>>>>>> Rules are, you change something before you commit ALL unit tests must
>>>>>> pass,
>>>>>> how ever you changed code.
>>>>>>
>>>>>> This is exactly why I want it in the whiteboard still, I don't want
>>>>>> people
>>>>>> looking at it in falcon "thinking" something that it is not yet.
>>>>>>
>>>>>> PS You should post a thread here what you are currently working on so I
>>>>>> don't step on your feet.
>>>>>>
>>>>>> Oh yeah, I have had plenty of out of body experiences through the years
>>>>>> gazing at parser and compiler code, so I know exactly what you are
>>>>>> talking
>>>>>> about, I guess in current times, it's the light bulb going off. :)
>>>>>>
>>>>>> Mike
>>>>>>
>>>>>>
>>>>>>
>>>>>> Quoting Erik de Bruin <er...@ixsoftware.nl>:
>>>>>>
>>>>>>> Mike,
>>>>>>>
>>>>>>> I've spent some time with the js.codegen this week... Nietzsche was
>>>>>>> right: "Battle not with monsters lest ye become a monster; and if you
>>>>>>> gaze into the abyss the abyss gazes into you." Having said that, I
>>>>>>> think I might be ready to contribute to that part of FalconJx.
>>>>>>>
>>>>>>> What are your plans (moving the project to the falcon/ repo so 'the
>>>>>>> public' can commit; refactoring, etc.)?
>>>>>>>
>>>>>>> EdB
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Ix Multimedia Software
>>>>>>>
>>>>>>> Jan Luykenstraat 27
>>>>>>> 3521 VB Utrecht
>>>>>>>
>>>>>>> T. 06-51952295
>>>>>>> I. www.ixsoftware.nl
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Michael Schmalle - Teoti Graphix, LLC
>>>>>> http://www.teotigraphix.com
>>>>>> http://blog.teotigraphix.com
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Ix Multimedia Software
>>>>>
>>>>> Jan Luykenstraat 27
>>>>> 3521 VB Utrecht
>>>>>
>>>>> T. 06-51952295
>>>>> I. www.ixsoftware.nl
>>>>>
>>>>
>>>> --
>>>> Michael Schmalle - Teoti Graphix, LLC
>>>> http://www.teotigraphix.com
>>>> http://blog.teotigraphix.com
>>>>
>>>
>>>
>>>
>>> --
>>> Ix Multimedia Software
>>>
>>> Jan Luykenstraat 27
>>> 3521 VB Utrecht
>>>
>>> T. 06-51952295
>>> I. www.ixsoftware.nl
>>>
>>
>> --
>> Michael Schmalle - Teoti Graphix, LLC
>> http://www.teotigraphix.com
>> http://blog.teotigraphix.com
>>
>
>
>
> --
> Ix Multimedia Software
>
> Jan Luykenstraat 27
> 3521 VB Utrecht
>
> T. 06-51952295
> I. www.ixsoftware.nl
>
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
Re: [FalconJx::GoogEmmitter] Moving forward
Posted by Erik de Bruin <er...@ixsoftware.nl>.
My day is really nearly over, so I won't do anything but dig around a
bit more to get more 'into' the code. So you go ahead with your todo,
please.
Once I've figured out what I can do and how I should do it, I'll
notify you to see if we're in a state to receive my efforts.
Ok?
EdB
On Thu, Dec 27, 2012 at 3:09 PM, Michael Schmalle
<ap...@teotigraphix.com> wrote:
>
> Quoting Erik de Bruin <er...@ixsoftware.nl>:
>
>> Excellent.
>>
>> Mike, question: can we somehow separate out the 'goog' specific code
>> some more? Just wondering... If someone wants to start a different
>> parsing for JS, it might be less work to separate out 'goog' entirely
>> at this point than try and do that only when the need arises. I was
>> thinking about the JSDocEmitter, which can do with an extra layer of
>> abstraction, I think. And some code in JSEmitter is also 'goog'
>> specific. As this requires 'some' refactoring, I'm hesitant to start
>> without consulting with you first ;-)
>
>
> Actually, the intent was that the JSEmitter holds all code that is universal
> to JS.
>
> You are seeing reminiscence of goog because I haven't taken it all out yet
> with the refactors.
>
> So, goog needs to be completely ripped out of the JSEmitter. I really don't
> think we need another layer, since if you take out the goog stuff from
> JSEmitter like I was going to do, you already have that layer in the
> JSGoogEmitter.
>
> Does this make sense?
>
> The jsdoc emitter is the same, I need an injection point to give the emitter
> an instance of it from the backend implementation. Probably need an
> interface like IDocEmitter the IJSGoogEmitter extends.
>
> Anyway, what do you want to do, because that is to close of quarters for me
> to work today if you are refactoring the JSEmitter.
>
> Mike
>
>
>
>
>
>> EdB
>>
>>
>> On Thu, Dec 27, 2012 at 2:21 PM, Michael Schmalle
>> <ap...@teotigraphix.com> wrote:
>>>
>>> Looks good Erik!
>>>
>>> Welcome to the party. Like I said, lets try to communicate what we are
>>> working on so we aren't creating merge conflicts, I hate those.
>>>
>>> Not much I would have done differently. Just 1 thing;
>>>
>>> Pay special attention to indents a newlines.
>>>
>>> foo.bar.A.method1 = function(p1, p2, p3, p4) {
>>> p3 = typeof p3 !== 'undefined' ? p3 : 3;
>>> p4 = typeof p4 !== 'undefined' ? p4 : 4;
>>>
>>> return p1 + p2 + p3 + p4;
>>> }
>>>
>>>
>>> should probably be;
>>>
>>> foo.bar.A.method1 = function(p1, p2, p3, p4) {
>>> p3 = typeof p3 !== 'undefined' ? p3 : 3;
>>> p4 = typeof p4 !== 'undefined' ? p4 : 4;
>>> return p1 + p2 + p3 + p4;
>>> }
>>>
>>> Without the newline to keep the code generation consistent. How would I
>>> get
>>> it to work? ...svn update :)
>>>
>>> Check out my last commit 5 minutes ago. If you are confused why and what
>>> I
>>> did ask.
>>>
>>> PS For block headers, there is a special handling of indents with no body
>>> code AST.
>>>
>>>
>>> Mike
>>>
>>>
>>>
>>> Quoting Erik de Bruin <er...@ixsoftware.nl>:
>>>
>>>> Mike,
>>>>
>>>> I've implemented and committed an alternative way of handling default
>>>> parameter values, including a test. Not particularly to make my point
>>>> with regard to which we should use (if we have to chose at all), but
>>>> mostly to see how I can contribute from my end.
>>>>
>>>> Please let me know how I did and what you would like me to do
>>>> differently. Thanks.
>>>>
>>>> EdB
>>>>
>>>>
>>>>
>>>> On Thu, Dec 27, 2012 at 11:56 AM, Michael Schmalle
>>>> <ap...@teotigraphix.com> wrote:
>>>>>
>>>>>
>>>>> Hey,
>>>>>
>>>>> I have no plans other than to keep trudging away. There is still a lot
>>>>> of
>>>>> work to be done.
>>>>>
>>>>> As far as moving to the falcon repo, I don't want to do that yet. You
>>>>> are
>>>>> more than welcome to commit code where it is (just happens to be in my
>>>>> whiteboard).
>>>>>
>>>>> Did you notice what I did to implement the parameters? If you havn't,
>>>>> you
>>>>> might want to take a look at the commit and diffs.
>>>>>
>>>>> The object is to NOT comment out or override anything in the
>>>>> ASBlockWalker.
>>>>> I refactored that parameter code to the base ASEmitter, added API and
>>>>> then
>>>>> overrode the method in JSGoogEmitter. Get it?
>>>>>
>>>>> Also did a trick to allow a hook into the beginning of a function block
>>>>> to
>>>>> inject code. We can do that anywhere it's needed, I don't see a lot of
>>>>> situations like that though.
>>>>>
>>>>> Rules are, you change something before you commit ALL unit tests must
>>>>> pass,
>>>>> how ever you changed code.
>>>>>
>>>>> This is exactly why I want it in the whiteboard still, I don't want
>>>>> people
>>>>> looking at it in falcon "thinking" something that it is not yet.
>>>>>
>>>>> PS You should post a thread here what you are currently working on so I
>>>>> don't step on your feet.
>>>>>
>>>>> Oh yeah, I have had plenty of out of body experiences through the years
>>>>> gazing at parser and compiler code, so I know exactly what you are
>>>>> talking
>>>>> about, I guess in current times, it's the light bulb going off. :)
>>>>>
>>>>> Mike
>>>>>
>>>>>
>>>>>
>>>>> Quoting Erik de Bruin <er...@ixsoftware.nl>:
>>>>>
>>>>>> Mike,
>>>>>>
>>>>>> I've spent some time with the js.codegen this week... Nietzsche was
>>>>>> right: "Battle not with monsters lest ye become a monster; and if you
>>>>>> gaze into the abyss the abyss gazes into you." Having said that, I
>>>>>> think I might be ready to contribute to that part of FalconJx.
>>>>>>
>>>>>> What are your plans (moving the project to the falcon/ repo so 'the
>>>>>> public' can commit; refactoring, etc.)?
>>>>>>
>>>>>> EdB
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Ix Multimedia Software
>>>>>>
>>>>>> Jan Luykenstraat 27
>>>>>> 3521 VB Utrecht
>>>>>>
>>>>>> T. 06-51952295
>>>>>> I. www.ixsoftware.nl
>>>>>>
>>>>>
>>>>> --
>>>>> Michael Schmalle - Teoti Graphix, LLC
>>>>> http://www.teotigraphix.com
>>>>> http://blog.teotigraphix.com
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Ix Multimedia Software
>>>>
>>>> Jan Luykenstraat 27
>>>> 3521 VB Utrecht
>>>>
>>>> T. 06-51952295
>>>> I. www.ixsoftware.nl
>>>>
>>>
>>> --
>>> Michael Schmalle - Teoti Graphix, LLC
>>> http://www.teotigraphix.com
>>> http://blog.teotigraphix.com
>>>
>>
>>
>>
>> --
>> Ix Multimedia Software
>>
>> Jan Luykenstraat 27
>> 3521 VB Utrecht
>>
>> T. 06-51952295
>> I. www.ixsoftware.nl
>>
>
> --
> Michael Schmalle - Teoti Graphix, LLC
> http://www.teotigraphix.com
> http://blog.teotigraphix.com
>
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [FalconJx::GoogEmmitter] Moving forward
Posted by Michael Schmalle <ap...@teotigraphix.com>.
Quoting Erik de Bruin <er...@ixsoftware.nl>:
> Excellent.
>
> Mike, question: can we somehow separate out the 'goog' specific code
> some more? Just wondering... If someone wants to start a different
> parsing for JS, it might be less work to separate out 'goog' entirely
> at this point than try and do that only when the need arises. I was
> thinking about the JSDocEmitter, which can do with an extra layer of
> abstraction, I think. And some code in JSEmitter is also 'goog'
> specific. As this requires 'some' refactoring, I'm hesitant to start
> without consulting with you first ;-)
Actually, the intent was that the JSEmitter holds all code that is
universal to JS.
You are seeing reminiscence of goog because I haven't taken it all out
yet with the refactors.
So, goog needs to be completely ripped out of the JSEmitter. I really
don't think we need another layer, since if you take out the goog
stuff from JSEmitter like I was going to do, you already have that
layer in the JSGoogEmitter.
Does this make sense?
The jsdoc emitter is the same, I need an injection point to give the
emitter an instance of it from the backend implementation. Probably
need an interface like IDocEmitter the IJSGoogEmitter extends.
Anyway, what do you want to do, because that is to close of quarters
for me to work today if you are refactoring the JSEmitter.
Mike
> EdB
>
>
> On Thu, Dec 27, 2012 at 2:21 PM, Michael Schmalle
> <ap...@teotigraphix.com> wrote:
>> Looks good Erik!
>>
>> Welcome to the party. Like I said, lets try to communicate what we are
>> working on so we aren't creating merge conflicts, I hate those.
>>
>> Not much I would have done differently. Just 1 thing;
>>
>> Pay special attention to indents a newlines.
>>
>> foo.bar.A.method1 = function(p1, p2, p3, p4) {
>> p3 = typeof p3 !== 'undefined' ? p3 : 3;
>> p4 = typeof p4 !== 'undefined' ? p4 : 4;
>>
>> return p1 + p2 + p3 + p4;
>> }
>>
>>
>> should probably be;
>>
>> foo.bar.A.method1 = function(p1, p2, p3, p4) {
>> p3 = typeof p3 !== 'undefined' ? p3 : 3;
>> p4 = typeof p4 !== 'undefined' ? p4 : 4;
>> return p1 + p2 + p3 + p4;
>> }
>>
>> Without the newline to keep the code generation consistent. How would I get
>> it to work? ...svn update :)
>>
>> Check out my last commit 5 minutes ago. If you are confused why and what I
>> did ask.
>>
>> PS For block headers, there is a special handling of indents with no body
>> code AST.
>>
>>
>> Mike
>>
>>
>>
>> Quoting Erik de Bruin <er...@ixsoftware.nl>:
>>
>>> Mike,
>>>
>>> I've implemented and committed an alternative way of handling default
>>> parameter values, including a test. Not particularly to make my point
>>> with regard to which we should use (if we have to chose at all), but
>>> mostly to see how I can contribute from my end.
>>>
>>> Please let me know how I did and what you would like me to do
>>> differently. Thanks.
>>>
>>> EdB
>>>
>>>
>>>
>>> On Thu, Dec 27, 2012 at 11:56 AM, Michael Schmalle
>>> <ap...@teotigraphix.com> wrote:
>>>>
>>>> Hey,
>>>>
>>>> I have no plans other than to keep trudging away. There is still a lot of
>>>> work to be done.
>>>>
>>>> As far as moving to the falcon repo, I don't want to do that yet. You are
>>>> more than welcome to commit code where it is (just happens to be in my
>>>> whiteboard).
>>>>
>>>> Did you notice what I did to implement the parameters? If you havn't, you
>>>> might want to take a look at the commit and diffs.
>>>>
>>>> The object is to NOT comment out or override anything in the
>>>> ASBlockWalker.
>>>> I refactored that parameter code to the base ASEmitter, added API and
>>>> then
>>>> overrode the method in JSGoogEmitter. Get it?
>>>>
>>>> Also did a trick to allow a hook into the beginning of a function block
>>>> to
>>>> inject code. We can do that anywhere it's needed, I don't see a lot of
>>>> situations like that though.
>>>>
>>>> Rules are, you change something before you commit ALL unit tests must
>>>> pass,
>>>> how ever you changed code.
>>>>
>>>> This is exactly why I want it in the whiteboard still, I don't want
>>>> people
>>>> looking at it in falcon "thinking" something that it is not yet.
>>>>
>>>> PS You should post a thread here what you are currently working on so I
>>>> don't step on your feet.
>>>>
>>>> Oh yeah, I have had plenty of out of body experiences through the years
>>>> gazing at parser and compiler code, so I know exactly what you are
>>>> talking
>>>> about, I guess in current times, it's the light bulb going off. :)
>>>>
>>>> Mike
>>>>
>>>>
>>>>
>>>> Quoting Erik de Bruin <er...@ixsoftware.nl>:
>>>>
>>>>> Mike,
>>>>>
>>>>> I've spent some time with the js.codegen this week... Nietzsche was
>>>>> right: "Battle not with monsters lest ye become a monster; and if you
>>>>> gaze into the abyss the abyss gazes into you." Having said that, I
>>>>> think I might be ready to contribute to that part of FalconJx.
>>>>>
>>>>> What are your plans (moving the project to the falcon/ repo so 'the
>>>>> public' can commit; refactoring, etc.)?
>>>>>
>>>>> EdB
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Ix Multimedia Software
>>>>>
>>>>> Jan Luykenstraat 27
>>>>> 3521 VB Utrecht
>>>>>
>>>>> T. 06-51952295
>>>>> I. www.ixsoftware.nl
>>>>>
>>>>
>>>> --
>>>> Michael Schmalle - Teoti Graphix, LLC
>>>> http://www.teotigraphix.com
>>>> http://blog.teotigraphix.com
>>>>
>>>
>>>
>>>
>>> --
>>> Ix Multimedia Software
>>>
>>> Jan Luykenstraat 27
>>> 3521 VB Utrecht
>>>
>>> T. 06-51952295
>>> I. www.ixsoftware.nl
>>>
>>
>> --
>> Michael Schmalle - Teoti Graphix, LLC
>> http://www.teotigraphix.com
>> http://blog.teotigraphix.com
>>
>
>
>
> --
> Ix Multimedia Software
>
> Jan Luykenstraat 27
> 3521 VB Utrecht
>
> T. 06-51952295
> I. www.ixsoftware.nl
>
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
Re: [FalconJx::GoogEmmitter] Moving forward
Posted by Erik de Bruin <er...@ixsoftware.nl>.
Excellent.
Mike, question: can we somehow separate out the 'goog' specific code
some more? Just wondering... If someone wants to start a different
parsing for JS, it might be less work to separate out 'goog' entirely
at this point than try and do that only when the need arises. I was
thinking about the JSDocEmitter, which can do with an extra layer of
abstraction, I think. And some code in JSEmitter is also 'goog'
specific. As this requires 'some' refactoring, I'm hesitant to start
without consulting with you first ;-)
EdB
On Thu, Dec 27, 2012 at 2:21 PM, Michael Schmalle
<ap...@teotigraphix.com> wrote:
> Looks good Erik!
>
> Welcome to the party. Like I said, lets try to communicate what we are
> working on so we aren't creating merge conflicts, I hate those.
>
> Not much I would have done differently. Just 1 thing;
>
> Pay special attention to indents a newlines.
>
> foo.bar.A.method1 = function(p1, p2, p3, p4) {
> p3 = typeof p3 !== 'undefined' ? p3 : 3;
> p4 = typeof p4 !== 'undefined' ? p4 : 4;
>
> return p1 + p2 + p3 + p4;
> }
>
>
> should probably be;
>
> foo.bar.A.method1 = function(p1, p2, p3, p4) {
> p3 = typeof p3 !== 'undefined' ? p3 : 3;
> p4 = typeof p4 !== 'undefined' ? p4 : 4;
> return p1 + p2 + p3 + p4;
> }
>
> Without the newline to keep the code generation consistent. How would I get
> it to work? ...svn update :)
>
> Check out my last commit 5 minutes ago. If you are confused why and what I
> did ask.
>
> PS For block headers, there is a special handling of indents with no body
> code AST.
>
>
> Mike
>
>
>
> Quoting Erik de Bruin <er...@ixsoftware.nl>:
>
>> Mike,
>>
>> I've implemented and committed an alternative way of handling default
>> parameter values, including a test. Not particularly to make my point
>> with regard to which we should use (if we have to chose at all), but
>> mostly to see how I can contribute from my end.
>>
>> Please let me know how I did and what you would like me to do
>> differently. Thanks.
>>
>> EdB
>>
>>
>>
>> On Thu, Dec 27, 2012 at 11:56 AM, Michael Schmalle
>> <ap...@teotigraphix.com> wrote:
>>>
>>> Hey,
>>>
>>> I have no plans other than to keep trudging away. There is still a lot of
>>> work to be done.
>>>
>>> As far as moving to the falcon repo, I don't want to do that yet. You are
>>> more than welcome to commit code where it is (just happens to be in my
>>> whiteboard).
>>>
>>> Did you notice what I did to implement the parameters? If you havn't, you
>>> might want to take a look at the commit and diffs.
>>>
>>> The object is to NOT comment out or override anything in the
>>> ASBlockWalker.
>>> I refactored that parameter code to the base ASEmitter, added API and
>>> then
>>> overrode the method in JSGoogEmitter. Get it?
>>>
>>> Also did a trick to allow a hook into the beginning of a function block
>>> to
>>> inject code. We can do that anywhere it's needed, I don't see a lot of
>>> situations like that though.
>>>
>>> Rules are, you change something before you commit ALL unit tests must
>>> pass,
>>> how ever you changed code.
>>>
>>> This is exactly why I want it in the whiteboard still, I don't want
>>> people
>>> looking at it in falcon "thinking" something that it is not yet.
>>>
>>> PS You should post a thread here what you are currently working on so I
>>> don't step on your feet.
>>>
>>> Oh yeah, I have had plenty of out of body experiences through the years
>>> gazing at parser and compiler code, so I know exactly what you are
>>> talking
>>> about, I guess in current times, it's the light bulb going off. :)
>>>
>>> Mike
>>>
>>>
>>>
>>> Quoting Erik de Bruin <er...@ixsoftware.nl>:
>>>
>>>> Mike,
>>>>
>>>> I've spent some time with the js.codegen this week... Nietzsche was
>>>> right: "Battle not with monsters lest ye become a monster; and if you
>>>> gaze into the abyss the abyss gazes into you." Having said that, I
>>>> think I might be ready to contribute to that part of FalconJx.
>>>>
>>>> What are your plans (moving the project to the falcon/ repo so 'the
>>>> public' can commit; refactoring, etc.)?
>>>>
>>>> EdB
>>>>
>>>>
>>>>
>>>> --
>>>> Ix Multimedia Software
>>>>
>>>> Jan Luykenstraat 27
>>>> 3521 VB Utrecht
>>>>
>>>> T. 06-51952295
>>>> I. www.ixsoftware.nl
>>>>
>>>
>>> --
>>> Michael Schmalle - Teoti Graphix, LLC
>>> http://www.teotigraphix.com
>>> http://blog.teotigraphix.com
>>>
>>
>>
>>
>> --
>> Ix Multimedia Software
>>
>> Jan Luykenstraat 27
>> 3521 VB Utrecht
>>
>> T. 06-51952295
>> I. www.ixsoftware.nl
>>
>
> --
> Michael Schmalle - Teoti Graphix, LLC
> http://www.teotigraphix.com
> http://blog.teotigraphix.com
>
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [FalconJx::GoogEmmitter] Moving forward
Posted by Michael Schmalle <ap...@teotigraphix.com>.
Looks good Erik!
Welcome to the party. Like I said, lets try to communicate what we are
working on so we aren't creating merge conflicts, I hate those.
Not much I would have done differently. Just 1 thing;
Pay special attention to indents a newlines.
foo.bar.A.method1 = function(p1, p2, p3, p4) {
p3 = typeof p3 !== 'undefined' ? p3 : 3;
p4 = typeof p4 !== 'undefined' ? p4 : 4;
return p1 + p2 + p3 + p4;
}
should probably be;
foo.bar.A.method1 = function(p1, p2, p3, p4) {
p3 = typeof p3 !== 'undefined' ? p3 : 3;
p4 = typeof p4 !== 'undefined' ? p4 : 4;
return p1 + p2 + p3 + p4;
}
Without the newline to keep the code generation consistent. How would
I get it to work? ...svn update :)
Check out my last commit 5 minutes ago. If you are confused why and
what I did ask.
PS For block headers, there is a special handling of indents with no
body code AST.
Mike
Quoting Erik de Bruin <er...@ixsoftware.nl>:
> Mike,
>
> I've implemented and committed an alternative way of handling default
> parameter values, including a test. Not particularly to make my point
> with regard to which we should use (if we have to chose at all), but
> mostly to see how I can contribute from my end.
>
> Please let me know how I did and what you would like me to do
> differently. Thanks.
>
> EdB
>
>
>
> On Thu, Dec 27, 2012 at 11:56 AM, Michael Schmalle
> <ap...@teotigraphix.com> wrote:
>> Hey,
>>
>> I have no plans other than to keep trudging away. There is still a lot of
>> work to be done.
>>
>> As far as moving to the falcon repo, I don't want to do that yet. You are
>> more than welcome to commit code where it is (just happens to be in my
>> whiteboard).
>>
>> Did you notice what I did to implement the parameters? If you havn't, you
>> might want to take a look at the commit and diffs.
>>
>> The object is to NOT comment out or override anything in the ASBlockWalker.
>> I refactored that parameter code to the base ASEmitter, added API and then
>> overrode the method in JSGoogEmitter. Get it?
>>
>> Also did a trick to allow a hook into the beginning of a function block to
>> inject code. We can do that anywhere it's needed, I don't see a lot of
>> situations like that though.
>>
>> Rules are, you change something before you commit ALL unit tests must pass,
>> how ever you changed code.
>>
>> This is exactly why I want it in the whiteboard still, I don't want people
>> looking at it in falcon "thinking" something that it is not yet.
>>
>> PS You should post a thread here what you are currently working on so I
>> don't step on your feet.
>>
>> Oh yeah, I have had plenty of out of body experiences through the years
>> gazing at parser and compiler code, so I know exactly what you are talking
>> about, I guess in current times, it's the light bulb going off. :)
>>
>> Mike
>>
>>
>>
>> Quoting Erik de Bruin <er...@ixsoftware.nl>:
>>
>>> Mike,
>>>
>>> I've spent some time with the js.codegen this week... Nietzsche was
>>> right: "Battle not with monsters lest ye become a monster; and if you
>>> gaze into the abyss the abyss gazes into you." Having said that, I
>>> think I might be ready to contribute to that part of FalconJx.
>>>
>>> What are your plans (moving the project to the falcon/ repo so 'the
>>> public' can commit; refactoring, etc.)?
>>>
>>> EdB
>>>
>>>
>>>
>>> --
>>> Ix Multimedia Software
>>>
>>> Jan Luykenstraat 27
>>> 3521 VB Utrecht
>>>
>>> T. 06-51952295
>>> I. www.ixsoftware.nl
>>>
>>
>> --
>> Michael Schmalle - Teoti Graphix, LLC
>> http://www.teotigraphix.com
>> http://blog.teotigraphix.com
>>
>
>
>
> --
> Ix Multimedia Software
>
> Jan Luykenstraat 27
> 3521 VB Utrecht
>
> T. 06-51952295
> I. www.ixsoftware.nl
>
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
Re: [FalconJx::GoogEmmitter] Moving forward
Posted by Erik de Bruin <er...@ixsoftware.nl>.
Mike,
I've implemented and committed an alternative way of handling default
parameter values, including a test. Not particularly to make my point
with regard to which we should use (if we have to chose at all), but
mostly to see how I can contribute from my end.
Please let me know how I did and what you would like me to do
differently. Thanks.
EdB
On Thu, Dec 27, 2012 at 11:56 AM, Michael Schmalle
<ap...@teotigraphix.com> wrote:
> Hey,
>
> I have no plans other than to keep trudging away. There is still a lot of
> work to be done.
>
> As far as moving to the falcon repo, I don't want to do that yet. You are
> more than welcome to commit code where it is (just happens to be in my
> whiteboard).
>
> Did you notice what I did to implement the parameters? If you havn't, you
> might want to take a look at the commit and diffs.
>
> The object is to NOT comment out or override anything in the ASBlockWalker.
> I refactored that parameter code to the base ASEmitter, added API and then
> overrode the method in JSGoogEmitter. Get it?
>
> Also did a trick to allow a hook into the beginning of a function block to
> inject code. We can do that anywhere it's needed, I don't see a lot of
> situations like that though.
>
> Rules are, you change something before you commit ALL unit tests must pass,
> how ever you changed code.
>
> This is exactly why I want it in the whiteboard still, I don't want people
> looking at it in falcon "thinking" something that it is not yet.
>
> PS You should post a thread here what you are currently working on so I
> don't step on your feet.
>
> Oh yeah, I have had plenty of out of body experiences through the years
> gazing at parser and compiler code, so I know exactly what you are talking
> about, I guess in current times, it's the light bulb going off. :)
>
> Mike
>
>
>
> Quoting Erik de Bruin <er...@ixsoftware.nl>:
>
>> Mike,
>>
>> I've spent some time with the js.codegen this week... Nietzsche was
>> right: "Battle not with monsters lest ye become a monster; and if you
>> gaze into the abyss the abyss gazes into you." Having said that, I
>> think I might be ready to contribute to that part of FalconJx.
>>
>> What are your plans (moving the project to the falcon/ repo so 'the
>> public' can commit; refactoring, etc.)?
>>
>> EdB
>>
>>
>>
>> --
>> Ix Multimedia Software
>>
>> Jan Luykenstraat 27
>> 3521 VB Utrecht
>>
>> T. 06-51952295
>> I. www.ixsoftware.nl
>>
>
> --
> Michael Schmalle - Teoti Graphix, LLC
> http://www.teotigraphix.com
> http://blog.teotigraphix.com
>
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [FalconJx::GoogEmmitter] Moving forward
Posted by Michael Schmalle <ap...@teotigraphix.com>.
Hey,
I have no plans other than to keep trudging away. There is still a lot
of work to be done.
As far as moving to the falcon repo, I don't want to do that yet. You
are more than welcome to commit code where it is (just happens to be
in my whiteboard).
Did you notice what I did to implement the parameters? If you havn't,
you might want to take a look at the commit and diffs.
The object is to NOT comment out or override anything in the
ASBlockWalker. I refactored that parameter code to the base ASEmitter,
added API and then overrode the method in JSGoogEmitter. Get it?
Also did a trick to allow a hook into the beginning of a function
block to inject code. We can do that anywhere it's needed, I don't see
a lot of situations like that though.
Rules are, you change something before you commit ALL unit tests must
pass, how ever you changed code.
This is exactly why I want it in the whiteboard still, I don't want
people looking at it in falcon "thinking" something that it is not yet.
PS You should post a thread here what you are currently working on so
I don't step on your feet.
Oh yeah, I have had plenty of out of body experiences through the
years gazing at parser and compiler code, so I know exactly what you
are talking about, I guess in current times, it's the light bulb going
off. :)
Mike
Quoting Erik de Bruin <er...@ixsoftware.nl>:
> Mike,
>
> I've spent some time with the js.codegen this week... Nietzsche was
> right: "Battle not with monsters lest ye become a monster; and if you
> gaze into the abyss the abyss gazes into you." Having said that, I
> think I might be ready to contribute to that part of FalconJx.
>
> What are your plans (moving the project to the falcon/ repo so 'the
> public' can commit; refactoring, etc.)?
>
> EdB
>
>
>
> --
> Ix Multimedia Software
>
> Jan Luykenstraat 27
> 3521 VB Utrecht
>
> T. 06-51952295
> I. www.ixsoftware.nl
>
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com