Re: [Cython] Jenkins problem
2012/8/22 Stefan Behnel : > Vitja Makarov, 22.08.2012 06:51: >> I've a problem running jenknins job >> >> https://sage.math.washington.edu:8091/hudson/view/dev-vitek/job/cython-vitek-tests/137/BACKEND=c,PYVERSION=py27/console >> >> It says "No space left on device". Have something change there? > > Yes, we're now building in a ramdisk, which is restricted in size to 20GB. > Apparently, I had forgotten to add the final cleanup script to your tests > job. Should look better now. > > Stefan > Jenkins is down now. -- vitja. ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Jenkins problem
Vitja Makarov, 22.08.2012 17:44: > 2012/8/22 Stefan Behnel: >> Vitja Makarov, 22.08.2012 06:51: >>> I've a problem running jenknins job >>> >>> https://sage.math.washington.edu:8091/hudson/view/dev-vitek/job/cython-vitek-tests/137/BACKEND=c,PYVERSION=py27/console >>> >>> It says "No space left on device". Have something change there? >> >> Yes, we're now building in a ramdisk, which is restricted in size to 20GB. >> Apparently, I had forgotten to add the final cleanup script to your tests >> job. Should look better now. > > Jenkins is down now. Yes, the whole sage.math cluster is going through a mental post power-issues crisis. Stefan ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
[Cython] Fwd: sagemath cluster
FYI Original Message Subject: sagemath cluster Date: Wed, 22 Aug 2012 10:21:31 -0700 From: William Stein There were some (unknown-to-me) issue with the power in the server room at University of Washington, resulting from a UPS breaking yesterday. The main fileserver was power cycled and "doesn't work" now, which means that all services hosted on the sage.math cluster will be down until this is fixed (or I switch to using an rsync backup). ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
[Cython] cython-devel-tests-pyregr regression
I've found regression: https://sage.math.washington.edu:8091/hudson/job/cython-devel-tests-pyregr/ -- vitja. ___ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] cython-devel-tests-pyregr regression
Vitja Makarov, 22.08.2012 22:11:
> I've found regression:
>
> https://sage.math.washington.edu:8091/hudson/job/cython-devel-tests-pyregr/
Interesting. It's a Py2 list comprehension in a class body that's failing here:
"""
class TestHelpSubparsersOrdering(HelpTestCase):
subparsers_signatures = [Sig(name=name)
for name in ('a', 'b', 'c', 'd', 'e')]
"""
I wonder why "name" isn't declared as a variable yet at the point where it
is being looked up in the function call.
Stefan
___
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] cython-devel-tests-pyregr regression
2012/8/23 Stefan Behnel :
> Vitja Makarov, 22.08.2012 22:11:
>> I've found regression:
>>
>> https://sage.math.washington.edu:8091/hudson/job/cython-devel-tests-pyregr/
>
> Interesting. It's a Py2 list comprehension in a class body that's failing
> here:
>
> """
> class TestHelpSubparsersOrdering(HelpTestCase):
> subparsers_signatures = [Sig(name=name)
> for name in ('a', 'b', 'c', 'd', 'e')]
> """
>
> I wonder why "name" isn't declared as a variable yet at the point where it
> is being looked up in the function call.
>
> Stefan
>
def lookup_relative(self, name, pos):
if name == "name":
print name
from ipdb import set_trace; set_trace()
entry = self.lookup_here(name)
if entry is not None and entry.pos[1:] <= pos[1:]: # Lookup fails here
return entry
if self.outer_scope:
return self.outer_scope.lookup_relative(name, pos)
return None
What is that comparison for?
--
vitja.
___
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] cython-devel-tests-pyregr regression
Vitja Makarov, 22.08.2012 22:34:
> 2012/8/23 Stefan Behnel:
>> Vitja Makarov, 22.08.2012 22:11:
>>> I've found regression:
>>>
>>> https://sage.math.washington.edu:8091/hudson/job/cython-devel-tests-pyregr/
>>
>> Interesting. It's a Py2 list comprehension in a class body that's failing
>> here:
>>
>> """
>> class TestHelpSubparsersOrdering(HelpTestCase):
>> subparsers_signatures = [Sig(name=name)
>> for name in ('a', 'b', 'c', 'd', 'e')]
>> """
>>
>> I wonder why "name" isn't declared as a variable yet at the point where it
>> is being looked up in the function call.
>
> def lookup_relative(self, name, pos):
> if name == "name":
> print name
> from ipdb import set_trace; set_trace()
> entry = self.lookup_here(name)
> if entry is not None and entry.pos[1:] <= pos[1:]: # Lookup fails here
> return entry
> if self.outer_scope:
> return self.outer_scope.lookup_relative(name, pos)
> return None
>
>
> What is that comparison for?
Ah, yes, it is wrong in this context. It was meant to prevent names defined
further down in the class body from being considered assignments to the
name being looked up. Class bodies are not function bodies, assignments in
them do not make a name "local". As long as it's not assigned, it's not
defined and must be looked up in the outer scope.
I think comprehensions are actually the only case where a name is used in
the source before its declaration. It should work in all other cases.
I had considered solving this problem with the flow control analysis
information, but I can't see how that helps me to figure out if an entry is
already assigned (i.e. declared) at a given point in the class body.
Any idea?
Actually, I even wonder if it is a good idea to look up the name directly
in the class scope - we may want to inject a local comprehension scope
here, as for Py3 comprehensions and genexprs, and just switch the
fall-through of the declarations on or off based on the code semantics.
Stefan
___
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] cython-devel-tests-pyregr regression
2012/8/23 Stefan Behnel :
> Vitja Makarov, 22.08.2012 22:34:
>> 2012/8/23 Stefan Behnel:
>>> Vitja Makarov, 22.08.2012 22:11:
I've found regression:
https://sage.math.washington.edu:8091/hudson/job/cython-devel-tests-pyregr/
>>>
>>> Interesting. It's a Py2 list comprehension in a class body that's failing
>>> here:
>>>
>>> """
>>> class TestHelpSubparsersOrdering(HelpTestCase):
>>> subparsers_signatures = [Sig(name=name)
>>> for name in ('a', 'b', 'c', 'd', 'e')]
>>> """
>>>
>>> I wonder why "name" isn't declared as a variable yet at the point where it
>>> is being looked up in the function call.
>>
>> def lookup_relative(self, name, pos):
>> if name == "name":
>> print name
>> from ipdb import set_trace; set_trace()
>> entry = self.lookup_here(name)
>> if entry is not None and entry.pos[1:] <= pos[1:]: # Lookup fails
>> here
>> return entry
>> if self.outer_scope:
>> return self.outer_scope.lookup_relative(name, pos)
>> return None
>>
>>
>> What is that comparison for?
>
> Ah, yes, it is wrong in this context. It was meant to prevent names defined
> further down in the class body from being considered assignments to the
> name being looked up. Class bodies are not function bodies, assignments in
> them do not make a name "local". As long as it's not assigned, it's not
> defined and must be looked up in the outer scope.
>
Do you remember this ticket #671
If there is assignment in the class body we first lookup in the class
dict and then in globals.
B = 0
def foo():
B = 1
class Foo():
A = B
B = B
class Bar():
A = B
print Foo.A, Foo.B, Bar.A
foo()
prints "0 0 1"
> I think comprehensions are actually the only case where a name is used in
> the source before its declaration. It should work in all other cases.
>
> I had considered solving this problem with the flow control analysis
> information, but I can't see how that helps me to figure out if an entry is
> already assigned (i.e. declared) at a given point in the class body.
>
> Any idea?
>
What would you do with maybe assigned case?
> Actually, I even wonder if it is a good idea to look up the name directly
> in the class scope - we may want to inject a local comprehension scope
> here, as for Py3 comprehensions and genexprs, and just switch the
> fall-through of the declarations on or off based on the code semantics.
>
--
vitja.
___
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] cython-devel-tests-pyregr regression
Vitja Makarov, 23.08.2012 07:03:
> 2012/8/23 Stefan Behnel :
>> Vitja Makarov, 22.08.2012 22:34:
>>> 2012/8/23 Stefan Behnel:
Vitja Makarov, 22.08.2012 22:11:
> I've found regression:
>
> https://sage.math.washington.edu:8091/hudson/job/cython-devel-tests-pyregr/
Interesting. It's a Py2 list comprehension in a class body that's failing
here:
"""
class TestHelpSubparsersOrdering(HelpTestCase):
subparsers_signatures = [Sig(name=name)
for name in ('a', 'b', 'c', 'd', 'e')]
"""
I wonder why "name" isn't declared as a variable yet at the point where it
is being looked up in the function call.
>>>
>>> def lookup_relative(self, name, pos):
>>> if name == "name":
>>> print name
>>> from ipdb import set_trace; set_trace()
>>> entry = self.lookup_here(name)
>>> if entry is not None and entry.pos[1:] <= pos[1:]: # Lookup fails
>>> here
>>> return entry
>>> if self.outer_scope:
>>> return self.outer_scope.lookup_relative(name, pos)
>>> return None
>>>
>>>
>>> What is that comparison for?
>>
>> Ah, yes, it is wrong in this context. It was meant to prevent names defined
>> further down in the class body from being considered assignments to the
>> name being looked up. Class bodies are not function bodies, assignments in
>> them do not make a name "local". As long as it's not assigned, it's not
>> defined and must be looked up in the outer scope.
>
> Do you remember this ticket #671
>
> If there is assignment in the class body we first lookup in the class
> dict and then in globals.
>
> B = 0
> def foo():
> B = 1
> class Foo():
> A = B
> B = B
> class Bar():
> A = B
> print Foo.A, Foo.B, Bar.A
> foo()
>
> prints "0 0 1"
In the case at hand, it's not an assignment but a method declaration. Maybe
that makes a difference.
In any case, this needs some more investigation than I did for my change. I
think it can be rolled back completely.
>> I think comprehensions are actually the only case where a name is used in
>> the source before its declaration. It should work in all other cases.
>>
>> I had considered solving this problem with the flow control analysis
>> information, but I can't see how that helps me to figure out if an entry is
>> already assigned (i.e. declared) at a given point in the class body.
>>
>> Any idea?
>
> What would you do with maybe assigned case?
Hmm, yes - I guess we can't solve the general case at compile time. That's
unfortunate, though, because it prevents proper compile time optimisation
of builtins in class bodies when their names are assigned at some point,
e.g. with a ".type()" method or ".set()", as was the case here.
Stefan
___
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] cython-devel-tests-pyregr regression
2012/8/23 Stefan Behnel :
> Vitja Makarov, 23.08.2012 07:03:
>> 2012/8/23 Stefan Behnel :
>>> Vitja Makarov, 22.08.2012 22:34:
2012/8/23 Stefan Behnel:
> Vitja Makarov, 22.08.2012 22:11:
>> I've found regression:
>>
>> https://sage.math.washington.edu:8091/hudson/job/cython-devel-tests-pyregr/
>
> Interesting. It's a Py2 list comprehension in a class body that's failing
> here:
>
> """
> class TestHelpSubparsersOrdering(HelpTestCase):
> subparsers_signatures = [Sig(name=name)
> for name in ('a', 'b', 'c', 'd', 'e')]
> """
>
> I wonder why "name" isn't declared as a variable yet at the point where it
> is being looked up in the function call.
def lookup_relative(self, name, pos):
if name == "name":
print name
from ipdb import set_trace; set_trace()
entry = self.lookup_here(name)
if entry is not None and entry.pos[1:] <= pos[1:]: # Lookup fails
here
return entry
if self.outer_scope:
return self.outer_scope.lookup_relative(name, pos)
return None
What is that comparison for?
>>>
>>> Ah, yes, it is wrong in this context. It was meant to prevent names defined
>>> further down in the class body from being considered assignments to the
>>> name being looked up. Class bodies are not function bodies, assignments in
>>> them do not make a name "local". As long as it's not assigned, it's not
>>> defined and must be looked up in the outer scope.
>>
>> Do you remember this ticket #671
>>
>> If there is assignment in the class body we first lookup in the class
>> dict and then in globals.
>>
>> B = 0
>> def foo():
>> B = 1
>> class Foo():
>> A = B
>> B = B
>> class Bar():
>> A = B
>> print Foo.A, Foo.B, Bar.A
>> foo()
>>
>> prints "0 0 1"
>
> In the case at hand, it's not an assignment but a method declaration. Maybe
> that makes a difference.
>
> In any case, this needs some more investigation than I did for my change. I
> think it can be rolled back completely.
>
>
>>> I think comprehensions are actually the only case where a name is used in
>>> the source before its declaration. It should work in all other cases.
>>>
>>> I had considered solving this problem with the flow control analysis
>>> information, but I can't see how that helps me to figure out if an entry is
>>> already assigned (i.e. declared) at a given point in the class body.
>>>
>>> Any idea?
>>
>> What would you do with maybe assigned case?
>
> Hmm, yes - I guess we can't solve the general case at compile time. That's
> unfortunate, though, because it prevents proper compile time optimisation
> of builtins in class bodies when their names are assigned at some point,
> e.g. with a ".type()" method or ".set()", as was the case here.
>
> Stefan
>
This is NameNode related problem
The following code would fail as well:
XXX = 123
class Foo(object):
t1 = XXX # XXX cf_is_null = True
t2 = XXX # XXX cf_is_null = False
XXX = 123
CF assumes that after first apperence of NULL name it must be then set
otherwise exception must be raised.
NameNode code relays on CF here, so I think it mustn't. We must
allways check result of PyObject_GetItem() and if's NULL look at the
globals then.
I'll try to fix it soon.
--
vitja.
___
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] cython-devel-tests-pyregr regression
2012/8/23 Vitja Makarov :
> 2012/8/23 Stefan Behnel :
>> Vitja Makarov, 23.08.2012 07:03:
>>> 2012/8/23 Stefan Behnel :
Vitja Makarov, 22.08.2012 22:34:
> 2012/8/23 Stefan Behnel:
>> Vitja Makarov, 22.08.2012 22:11:
>>> I've found regression:
>>>
>>> https://sage.math.washington.edu:8091/hudson/job/cython-devel-tests-pyregr/
>>
>> Interesting. It's a Py2 list comprehension in a class body that's
>> failing here:
>>
>> """
>> class TestHelpSubparsersOrdering(HelpTestCase):
>> subparsers_signatures = [Sig(name=name)
>> for name in ('a', 'b', 'c', 'd', 'e')]
>> """
>>
>> I wonder why "name" isn't declared as a variable yet at the point where
>> it
>> is being looked up in the function call.
>
> def lookup_relative(self, name, pos):
> if name == "name":
> print name
> from ipdb import set_trace; set_trace()
> entry = self.lookup_here(name)
> if entry is not None and entry.pos[1:] <= pos[1:]: # Lookup fails
> here
> return entry
> if self.outer_scope:
> return self.outer_scope.lookup_relative(name, pos)
> return None
>
>
> What is that comparison for?
Ah, yes, it is wrong in this context. It was meant to prevent names defined
further down in the class body from being considered assignments to the
name being looked up. Class bodies are not function bodies, assignments in
them do not make a name "local". As long as it's not assigned, it's not
defined and must be looked up in the outer scope.
>>>
>>> Do you remember this ticket #671
>>>
>>> If there is assignment in the class body we first lookup in the class
>>> dict and then in globals.
>>>
>>> B = 0
>>> def foo():
>>> B = 1
>>> class Foo():
>>> A = B
>>> B = B
>>> class Bar():
>>> A = B
>>> print Foo.A, Foo.B, Bar.A
>>> foo()
>>>
>>> prints "0 0 1"
>>
>> In the case at hand, it's not an assignment but a method declaration. Maybe
>> that makes a difference.
>>
>> In any case, this needs some more investigation than I did for my change. I
>> think it can be rolled back completely.
>>
>>
I think comprehensions are actually the only case where a name is used in
the source before its declaration. It should work in all other cases.
I had considered solving this problem with the flow control analysis
information, but I can't see how that helps me to figure out if an entry is
already assigned (i.e. declared) at a given point in the class body.
Any idea?
>>>
>>> What would you do with maybe assigned case?
>>
>> Hmm, yes - I guess we can't solve the general case at compile time. That's
>> unfortunate, though, because it prevents proper compile time optimisation
>> of builtins in class bodies when their names are assigned at some point,
>> e.g. with a ".type()" method or ".set()", as was the case here.
>>
>> Stefan
>>
>
>
>
> This is NameNode related problem
>
> The following code would fail as well:
> XXX = 123
> class Foo(object):
> t1 = XXX # XXX cf_is_null = True
> t2 = XXX # XXX cf_is_null = False
> XXX = 123
>
> CF assumes that after first apperence of NULL name it must be then set
> otherwise exception must be raised.
> NameNode code relays on CF here, so I think it mustn't. We must
> allways check result of PyObject_GetItem() and if's NULL look at the
> globals then.
>
> I'll try to fix it soon.
>
>
I've reverted your commit and here is my fix:
https://github.com/vitek/cython/commit/198f254f62360b61c895ba68be0f4dbe0749
Cause of different class scope lookup rules I think we can't fully
trust CF here.
--
vitja.
___
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] cython-devel-tests-pyregr regression
2012/8/23 Vitja Makarov :
> 2012/8/23 Vitja Makarov :
>> 2012/8/23 Stefan Behnel :
>>> Vitja Makarov, 23.08.2012 07:03:
2012/8/23 Stefan Behnel :
> Vitja Makarov, 22.08.2012 22:34:
>> 2012/8/23 Stefan Behnel:
>>> Vitja Makarov, 22.08.2012 22:11:
I've found regression:
https://sage.math.washington.edu:8091/hudson/job/cython-devel-tests-pyregr/
>>>
>>> Interesting. It's a Py2 list comprehension in a class body that's
>>> failing here:
>>>
>>> """
>>> class TestHelpSubparsersOrdering(HelpTestCase):
>>> subparsers_signatures = [Sig(name=name)
>>> for name in ('a', 'b', 'c', 'd', 'e')]
>>> """
>>>
>>> I wonder why "name" isn't declared as a variable yet at the point where
>>> it
>>> is being looked up in the function call.
>>
>> def lookup_relative(self, name, pos):
>> if name == "name":
>> print name
>> from ipdb import set_trace; set_trace()
>> entry = self.lookup_here(name)
>> if entry is not None and entry.pos[1:] <= pos[1:]: # Lookup
>> fails here
>> return entry
>> if self.outer_scope:
>> return self.outer_scope.lookup_relative(name, pos)
>> return None
>>
>>
>> What is that comparison for?
>
> Ah, yes, it is wrong in this context. It was meant to prevent names
> defined
> further down in the class body from being considered assignments to the
> name being looked up. Class bodies are not function bodies, assignments in
> them do not make a name "local". As long as it's not assigned, it's not
> defined and must be looked up in the outer scope.
Do you remember this ticket #671
If there is assignment in the class body we first lookup in the class
dict and then in globals.
B = 0
def foo():
B = 1
class Foo():
A = B
B = B
class Bar():
A = B
print Foo.A, Foo.B, Bar.A
foo()
prints "0 0 1"
>>>
>>> In the case at hand, it's not an assignment but a method declaration. Maybe
>>> that makes a difference.
>>>
>>> In any case, this needs some more investigation than I did for my change. I
>>> think it can be rolled back completely.
>>>
>>>
> I think comprehensions are actually the only case where a name is used in
> the source before its declaration. It should work in all other cases.
>
> I had considered solving this problem with the flow control analysis
> information, but I can't see how that helps me to figure out if an entry
> is
> already assigned (i.e. declared) at a given point in the class body.
>
> Any idea?
What would you do with maybe assigned case?
>>>
>>> Hmm, yes - I guess we can't solve the general case at compile time. That's
>>> unfortunate, though, because it prevents proper compile time optimisation
>>> of builtins in class bodies when their names are assigned at some point,
>>> e.g. with a ".type()" method or ".set()", as was the case here.
>>>
>>> Stefan
>>>
>>
>>
>>
>> This is NameNode related problem
>>
>> The following code would fail as well:
>> XXX = 123
>> class Foo(object):
>> t1 = XXX # XXX cf_is_null = True
>> t2 = XXX # XXX cf_is_null = False
>> XXX = 123
>>
>> CF assumes that after first apperence of NULL name it must be then set
>> otherwise exception must be raised.
>> NameNode code relays on CF here, so I think it mustn't. We must
>> allways check result of PyObject_GetItem() and if's NULL look at the
>> globals then.
>>
>> I'll try to fix it soon.
>>
>>
>
> I've reverted your commit and here is my fix:
> https://github.com/vitek/cython/commit/198f254f62360b61c895ba68be0f4dbe0749
>
> Cause of different class scope lookup rules I think we can't fully
> trust CF here.
>
Another (maybe better) solution is to fix CF. It mustn't set
cf_maybe_null to False at class scope based on reference success.
--
vitja.
___
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel
