Mailing-List: contact users-help@groovy.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@groovy.apache.org
Subject: Re: help with an AST
Reply-To: users@groovy.apache.org
References: <ef9e9540-74b4-5e79-e225-cfbfde46ac42@ameritech.net>
 <5866C1A8.6020809@gmx.org>
 <337fe01e-3af4-5345-cd5f-8836cd565a94@ameritech.net>
 <10564426-910c-7a84-1cdb-c6f3a75c57b1@gmx.org>
 <2af0d74f-d064-1bd2-d44e-830e7a49c086@ameritech.net>
 <dae4a31d-c682-1347-c426-8dbcf0403417@gmx.org>
 <c5115905-06a7-bd7e-3dc1-6fd324bedd9f@ameritech.net>
To: users@groovy.apache.org
From: Ed Clark <eaclark@ameritech.net>
Message-ID: <ffa19565-aec3-d873-480c-271018055b4d@ameritech.net>
Date: Thu, 16 Feb 2017 06:35:57 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <c5115905-06a7-bd7e-3dc1-6fd324bedd9f@ameritech.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
archived-at: Thu, 16 Feb 2017 11:36:12 -0000

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
>