Agreed (on the 'simple' fix). A thought: isn't doing this in Jx not somewhat over the top? I mean, if you are going to 'calculate' the parenthesis somehow, you might be fixing the user's code - after all, the user can put them in however he likes... Isn't there a way for the parenthesis to be (and this is probably going to sound silly, but I'm not so deep into this stuff that I know the actual jargon) part of the AST, so we can just 'visit' and 'emit' them?
EdB On Wed, Mar 6, 2013 at 4:37 PM, Michael Schmalle <apa...@teotigraphix.com> wrote: > Don't worry about this one. > > When I fix this, I'm just going to have to get every test working again > before I commit. I have time since this is a breaking bug that will render > complex binary expressions useless as it stands. > > What I plan on doing is the most simple fix. Since I know that the tree is > correct, I will probably implement this in the before and after strategy to > wrap any binary expression that is an operator in ( ). This might cause some > extra parenthesis that "might" not be needed but for now I see this as the > safest and most accurate way to proceed. > > Mike > > > Quoting Erik de Bruin <e...@ixsoftware.nl>: > >> Mike, >> >> Sure, no problem. I'm not planning any work on Jx the next couple of >> days, so if you figure something in that time, go ahead and implement. >> Also, if you need help fixing tests, I don't mind, so feel free to >> ask. >> >> EdB >> >> >> >> On Wed, Mar 6, 2013 at 4:22 PM, Michael Schmalle >> <apa...@teotigraphix.com> wrote: >>> >>> >>> Erik, >>> >>> Now that I'm getting back into the core framework again I am wishing that >>> I >>> would have taken care of a bug that I knew about. >>> >>> There is a serious problem that has to be fixed. Since we don't save >>> tokens >>> from the parser, a Binary AST tree knows nothing about it's order of >>> operations when output using the visitor framework. >>> >>> The fortunate thing here is that when the ASParser assembles these nodes, >>> they are assembled based on operator precedence. >>> >>> The unfortunate thing is, when I go to fix this its more than likely >>> going >>> to affect a huge amount of tests. >>> >>> My plan is to create tests based on my other project so I stay out of the >>> main framework for now. When I figure out something that works I will let >>> you know because we should again be on the same revision so there aren't >>> hard merge issues. >>> >>> Mike >>> >>> -- >>> 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