headers
Paul King | 1 Dec 2007 01:02
Picon
Favicon
Gravatar

Re: [groovy-dev] Fwd: [groovy-scm] groovy Build Failed


It was "just" noise. So, the next build worked fine
and it was working for me locally the whole time.

I can understand timing based tests to be a little
fragile when the server is under load but one or
two other tests do "blink" very occasionally (often
when the server is under load) and I can't understand
why. It seems to be very rare so I don't think it is
a huge concern. Probably something in our tests doesn't
clean up after itself as fully as it could and relies
on garbage collection to tidy something up. Every now
and then it hasn't finished tidying up and the assumptions
of a subsequent test are violated.

Paul.

Alexandru Popescu ☀ wrote:
> Guys, I have noticed this failure after my commit. However, I am
> pretty sure that the failure has nothing to do with my change in
> AnnotationVisitor. The failing test reported is in
> SwingBuilderTest.testDoOutside, which doesn't have anything to do with
> annotations.
> 
> ./alex
> --
> .w( the_mindstorm )p.
> 
> 
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andres Almiray | 1 Dec 2007 01:11
Picon
Favicon
Gravatar

Re: [groovy-dev] Strange behavior calling super


No, I don't get any errors anymore once I run groovy with your patch applied.

Paul King wrote:
> 
> 
> You get errors with this on HEAD?
> The example below (including the commented out line) seems to work for me.
> 
> Paul.
> 
> Andres Almiray wrote:
>> You are right Jochen, even Java will return "class Bar" calling
>> super.getClass() inside Bar.
>> But then it seems like accessing properties with super is broken in some
>> cases, as reported on the issue,
>> because as you can see on the following example calling super.getX()+"y"
>> works but super.x+"y" blows.
>> 
>> class GFoo {
>>    protected String foo
>>    void setFoo( String foo ){ this.foo = foo }
>>    String getFoo(){ foo }
>>    String doit(){ "FOO" }
>>    String getX(){ "x" }
>> }
>> 
>> class GBar extends GFoo {
>>    protected String foo
>>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul King | 1 Dec 2007 04:18
Picon
Favicon
Gravatar

Re: [groovy-dev] Strange behavior calling super

Jochen Theodorou wrote:
> Paul King schrieb:
>> The interesting thing is that if I comment out the getSuperField() method
>> then I can't do the set property anymore:
>>
>> class Base {
>>     protected String field = 'bar'
>> }
>>
>> class Child extends Base {
>>     protected String field = 'bar'
>>     public setSuperField(value) {super.field = value}
>> //     public getSuperField() {super.field}
>> }
>>
>>
>> def child = new Child()
>> //assert child.superField == "bar"
>> child.superField = "1"
>> //assert child.superField == "1"
>>
>> Caught: groovy.lang.MissingPropertyException: No such property: 
>> superField for class: Child
>>
>> I don't think this has anything to do with super.
> 
> that is strange, yes, that should have nothing to do with super

It is the same issue as here:
(Continue reading)

Permalink | Reply | 6 comments |
headers
Andres Almiray | 1 Dec 2007 08:52
Picon
Favicon
Gravatar

Re: [groovy-dev] Strange behavior calling super


Yes, for some reason getProperty() is called when assigning a value to a
write-only property instead of calling setProperty() alone.

Paul King wrote:
> 
> Jochen Theodorou wrote:
>> Paul King schrieb:
>>> The interesting thing is that if I comment out the getSuperField()
>>> method
>>> then I can't do the set property anymore:
>>>
>>> class Base {
>>>     protected String field = 'bar'
>>> }
>>>
>>> class Child extends Base {
>>>     protected String field = 'bar'
>>>     public setSuperField(value) {super.field = value}
>>> //     public getSuperField() {super.field}
>>> }
>>>
>>>
>>> def child = new Child()
>>> //assert child.superField == "bar"
>>> child.superField = "1"
>>> //assert child.superField == "1"
>>>
>>> Caught: groovy.lang.MissingPropertyException: No such property: 
>>> superField for class: Child
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul King | 1 Dec 2007 08:56
Picon
Favicon
Gravatar

Re: [groovy-dev] Strange behavior calling super


Ok, here is what I found. If you run this script:

----------
class Base {
    protected String field = 'bar'
}

class Child extends Base {
    protected String field = 'baz'
    public setSuperField(value) { super.field = value }
    def contents() { super.field }
}

def x = new Child()
assert x.contents() == 'bar'
x.superField = 'foo'
//assert x.contents() == 'foo'
----------

with the last line commented out (as shown above) it
fails saying that getSuperField() cannot be found.
It is trying to "reevaluate" x.superField (not in the
context of being the LHS of an assignment) for the
purposes of determining the return value for the script.
If you uncomment the last line, the return value will
be null and it will never try to evaluate x.superField
as a RHS expression.

To get around the problem I changed AsmClassGenerator#createReturnLHSExpression
(Continue reading)

Permalink | Reply | 4 comments |
headers
Martin Kempf | 1 Dec 2007 12:39
Picon
Favicon

[groovy-dev] isDynamicTyped in class VariableExpression

Hi

while writing the AST-Writer I recognized the following behaviour which 
I think is strange.

in the follwoing code:
---- SNIP ------
def foo = 42
---- SNIP ------

I expected that the variable foo is represented as VariableExpression 
with isDynamicTyped = true in the AST. But it isn't. Also 
isDynamicTyped() of the instance variable 'accessedVariable' (which is 
also of type VariableExpression) returns false.
The variable isDynamicTyped is initialised with false. The only point 
where this variable is set is in setType() but setType() is never 
called. So it is traceable why it always returns false.

I saw, that the method isDynamicTyped() is used somewhere in the 
ASMClassGenerator to determine the type of an expression. So a change in 
bahaviour of isDynamicTyped() in VariableExpression would affect other 
parts in groovy.

It seems the classgeneration works out fine but I have doubts that the 
behaviour of VariableExpression is correct.

regards
martin

---------------------------------------------------------------------
(Continue reading)

Permalink | Reply | 2 comments |
headers
Russel Winder | 1 Dec 2007 13:35
Gravatar

[groovy-dev] Groovy in MacPorts

I know a lot of you out there are Mac fans, I suspect MacPorts needs a
volunteer.  I just spotted that the Groovy port in MacPorts is  <at> 1.0.  I
guess we should plan for 1.1 getting into MacPorts.

--

-- 
Russel.
====================================================
Dr Russel Winder                 Partner

Concertant LLP                   t: +44 20 7193 9203
41 Buckmaster Road,              f: +44 8700 516 084
London SW11 1EN, UK.             m: +44 7770 465 077
Permalink | Reply | 0 comments |
headers
Jochen Theodorou | 1 Dec 2007 20:38
Picon
Gravatar

Re: [groovy-dev] Strange behavior calling super

Paul King schrieb:
> Jochen Theodorou wrote:
>>> I think visitAttributeOrProperty() should find 'field' as a field?
>>
>> if it uses the right class.. I think it searches only in the current 
>> class
> 
> Should this not do the trick?
> 
>                    field = classNode.getSuperClass().getField(name);

no, because super means the super class and all its super classes. and 
for properties we need to know not only the field, but also the 
setterg/getter, or.. if we want to do it totally right, also the generic 
get/set methods and... one more I forgot. it dpeends on how much of the 
dynamic aspects we want to have for super.

bye blackdrag

--

-- 
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/
http://www.g2one.com/

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jochen Theodorou | 1 Dec 2007 20:50
Picon
Gravatar

Re: [groovy-dev] Strange behavior calling super

Paul King schrieb:
> 
> Ok, here is what I found. If you run this script:
> 
> ----------
> class Base {
>    protected String field = 'bar'
> }
> 
> class Child extends Base {
>    protected String field = 'baz'
>    public setSuperField(value) { super.field = value }
>    def contents() { super.field }
> }
> 
> def x = new Child()
> assert x.contents() == 'bar'
> x.superField = 'foo'
> //assert x.contents() == 'foo'
> ----------
> 
> with the last line commented out (as shown above) it
> fails saying that getSuperField() cannot be found.

that's because of the return... if we have a closure {x.foo = bar}, then 
the compiler will do: {x.foo = bar; return x.foo} and the last one 
requires a getter. I say this just so that others on the list can follow

[...]
> The real solution I guess is to get the result stored in a temp variable
(Continue reading)

Permalink | Reply | 2 comments |
headers
Andres Almiray | 1 Dec 2007 21:09
Picon
Favicon
Gravatar

Re: [groovy-dev] Strange behavior calling super


Paul King wrote:
> 
> I am also not sure if it solves the issue from:
> 
> http://jira.codehaus.org/browse/GROOVY-2244
> 
> I haven't tried it yet but if 2244 is builder code then I imagine
> it is using closures which this "hack" doesn't address.
> 

The problem was discovered doing builder code but it is not related to them,
the real problem is that the 'locationRelativeTo' property in JFrame is
write only. The reporter was surprised that he was able to set a
value for that property inside a builder, but not outside. The builder code
eventually uses InvokerHelper.setProperty to set the property's value on the
target bean, and that seems not to trigger a
getProperty before.

-- Andres
--

-- 
View this message in context: http://www.nabble.com/Strange-behavior-calling-super-tf4901930.html#a14109103
Sent from the groovy - dev mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email
(Continue reading)

Permalink | Reply | 0 comments |

Gmane