groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ed Clark <eacl...@ameritech.net>
Subject Re: help with an AST
Date Fri, 17 Feb 2017 04:46:26 GMT
Hi Paul,

No I don't have that.  Let me play around with it.
Thanks for the pointer.

Ed

On 02/16/2017 04:41 PM, Paul King wrote:
> Do you have something like:
>
> VariableScopeVisitor scopeVisitor = new VariableScopeVisitor(source)
> scopeVisitor.visitClass(cNode)
>
> for each of your closure(s)? Where cNode is a closure's classNode?
>
> Cheers, Paul.
>
>
> On Thu, Feb 16, 2017 at 9:35 PM, Ed Clark <eaclark@ameritech.net> wrote:
>> Ok, a little more headbanging and I seem to have gotten farther (maybe?).
>> At least the error message has changed.  Now I'm getting:
>>
>> BUG! exception in phase 'class generation' in source unit 'CtxTest2.groovy'
>> Operation: (<assignment operator>:  "=" ) not supported
>>
>> Searching hasn't helped with this one.
>>
>> The xform-ed code looks good -- in fact, if I type the code into a separate
>> groovyConsole, it will run.  (The console AST generation works up thru
>> the Instruction Selection phase, obviously.)
>>
>> I'm guessing it's still with how I'm setting up the scoping (or how I'm not
>> setting up the scoping).
>>
>> Ideas, please?
>>
>> Thanks,
>>
>> Ed
>>
>>
>> On 02/14/2017 12:58 PM, Ed Clark wrote:
>>> On 02/14/2017 12:16 PM, Jochen Theodorou wrote:
>>>>
>>>>
>>>> On 14.02.2017 12:41, Ed Clark wrote:
>>>>> Hi Jochen,
>>>>>
>>>>> Well, I've been slowly making progress on this; kind of feels like
>>>>> bashing my
>>>>> head against a wall at times, but I have made a small hole in the wall
>>>>> through
>>>>> which I can see my goal. ;-)
>>>>
>>>> making holes my lead to brain damage.. then things get really hard to
>>>> solve ;)
>>> Maybe I'm too late, and that's why things aren't coming together ;)
>>>
>>>> [...]
>>>>> Specifically, I haven't figured out how to inject a variable into the
>>>>> scope of an outer
>>>>> with's closure that can be used by code in an interior with's closure.
>>>>> For example,
>>>>> consider
>>>>>
>>>>>    myCtx1.with {
>>>>>        __outerCtx1 = null            // injected statement
>>>>>        __currCtx1 = myCtx1       // injected statement
>>>>>        .... some code ...
>>>>>        myCtx2.with {
>>>>>            __outerCtx2 = __currCtx1   // injected statement <--- 
doesn't
>>>>> work
>>>>>            __currCtx2 = myCtx2          // injected statement
>>>>
>>>> where is __currCtx1 and __outerCtx1 coming from? Are they supposed to be
>>>> new local variables? in that case you will have to add a
>>>> DeclarationStatement, not just an assignment to a VariableExpression.
>>>> Otherwise the compiler will thnk they are dynamic properties and tries to
>>>> resolve them against the context.
>>>>
>>>> as for the logic behind __outerCtxN... with number wouldn't have to be
>>>> null I would have said you should think of using getOwner on Closure
>>>>
>>> Hmmm, I'm close to that, but not quite the same.  I was trying
>>>
>>>     ExpressionStatement currCtx = new ExpressionStatement(
>>>         new DeclarationExpression (
>>>             new VariableExpression( "__currCtx$levelcnt"),
>>>             new Token( Types.ASSIGNMENT_OPERATOR, "=", -1, -1),
>>>             new MethodCallExpression( new VariableExpression( 'this'),
>>> 'getDelegate', new ArgumentListExpression())
>>>         )
>>>     )
>>>
>>> Would a DeclarationStatment act differently from an ExpressionStatement
>>> with an embedded
>>> DeclarationExpression?  If my foggy memory is correct, I wrote my code
>>> after looking at the
>>> AST displayed for a short test script in groovyConsole.
>>>
>>> Plus, if foggy memory serves, I tried using getOwner and it came back with
>>> the closure being
>>> owned by the test script, not the object doing the with.  Calling
>>> getDelegate gave me the object.
>>> If foggy memory serves.
>>>
>>> I also tried playing around with setClosureSharedVariable( true) and
>>> putReferencedLocalVariable()
>>> without success.  But, those were somewhat blind stabs in the dark, so I
>>> might not have been
>>> using them correctly.
>>>
>>> Looking at the AST generated by groovyConsole, my transform looks like it
>>> is working, but
>>> the compiler complains about things not being in scope (in the inner
>>> closure).  So, I'm doing
>>> something wrong with setting up the scoping.
>>>
>>>>   bye Jochen
>>>
>>> Thanks,
>>>
>>> Ed
>>>


Mime
View raw message