gmane.comp.python.cython.devel

Neal Becker | 13 Aug 17:34

[Cython] Head fails tests

I did
hg pull -u
python setup.py build
sudo python setup.py install
python runtests.py

running doctests in wundram1 ...
======================================================================
ERROR: compiling and running ct_DEF
----------------------------------------------------------------------
Traceback (most recent call last):
  File "runtests.py", line 261, in run
    self.runCompileTest()
  File "runtests.py", line 159, in runCompileTest
    self.directory, self.expect_errors, self.annotate)
  File "runtests.py", line 248, in compile
    self.assertEquals(None, unexpected_error)
AssertionError: None != '38:19: Invalid compile-time expression'

Bunch more errors, including:
AttributeError: 'NoneType' object has no attribute 'groups'
ValueError: invalid literal for int() with base 10: '0F'
AssertionError: <unprintable AssertionError object>

headers

Dag Sverre Seljebotn | 13 Aug 18:39

Re: [Cython] Head fails tests

Neal Becker wrote:
> I did
> hg pull -u
> python setup.py build
> sudo python setup.py install
> python runtests.py
> 
> running doctests in wundram1 ...
> ======================================================================
> ERROR: compiling and running ct_DEF
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File "runtests.py", line 261, in run
>     self.runCompileTest()
>   File "runtests.py", line 159, in runCompileTest
>     self.directory, self.expect_errors, self.annotate)
>   File "runtests.py", line 248, in compile
>     self.assertEquals(None, unexpected_error)
> AssertionError: None != '38:19: Invalid compile-time expression'
> 
> Bunch more errors, including:
> AttributeError: 'NoneType' object has no attribute 'groups'
> ValueError: invalid literal for int() with base 10: '0F'
> AssertionError: <unprintable AssertionError object>

Strange, I cannot reproduce...so this could be a scary one.

Are you referring to the cython-devel repo? Can you do a fresh clone and 
try running only the wundram1 test?

(Continue reading)

headers

Robert Bradshaw | 13 Aug 18:39

Re: [Cython] Head fails tests

FYI, the beta is based on http://hg.cython.org/cython-dagss/ (which  
should have everything from cython-devel). Try pulling from there.

- Robert

On Aug 13, 2008, at 9:39 AM, Dag Sverre Seljebotn wrote:

> Neal Becker wrote:
>> I did
>> hg pull -u
>> python setup.py build
>> sudo python setup.py install
>> python runtests.py
>>
>> running doctests in wundram1 ...
>> ===================================================================== 
>> =
>> ERROR: compiling and running ct_DEF
>> --------------------------------------------------------------------- 
>> -
>> Traceback (most recent call last):
>>   File "runtests.py", line 261, in run
>>     self.runCompileTest()
>>   File "runtests.py", line 159, in runCompileTest
>>     self.directory, self.expect_errors, self.annotate)
>>   File "runtests.py", line 248, in compile
>>     self.assertEquals(None, unexpected_error)
>> AssertionError: None != '38:19: Invalid compile-time expression'
>>
>> Bunch more errors, including:

(Continue reading)

headers

Dag Sverre Seljebotn | 13 Aug 18:49

Re: [Cython] Head fails tests

Robert Bradshaw wrote:
> FYI, the beta is based on http://hg.cython.org/cython-dagss/ (which  
> should have everything from cython-devel). Try pulling from there.
> 

On that note..: As cython-dagss has everything in devel and is the basis 
of the beta, can't we just push it back to -devel and have -devel be the 
branch that will mature to the release?

I could then commit anything "stabilizing" into -devel and anything 
"destabilizing" to -dagss...

--

-- 
Dag Sverre

headers

Robert Bradshaw | 13 Aug 18:49

Re: [Cython] Head fails tests

On Aug 13, 2008, at 9:49 AM, Dag Sverre Seljebotn wrote:

> Robert Bradshaw wrote:
>> FYI, the beta is based on http://hg.cython.org/cython-dagss/ (which
>> should have everything from cython-devel). Try pulling from there.
>>
>
> On that note..: As cython-dagss has everything in devel and is the  
> basis
> of the beta, can't we just push it back to -devel and have -devel  
> be the
> branch that will mature to the release?
>
> I could then commit anything "stabilizing" into -devel and anything
> "destabilizing" to -dagss...

Yes. My only concern is that Stefan's lxml was having trouble  
compiling with the dagss branch (not sure if this is still the case)  
and I didn't want that to be a show-stopper for Stefan. If this is  
not the case anymore, then I would like to push -dagss into -devel.

- Robert

headers

Stefan Behnel | 14 Aug 07:38

Re: [Cython] Head fails tests

Hi Robert,

Robert Bradshaw wrote:
> My only concern is that Stefan's lxml was having trouble  
> compiling with the dagss branch (not sure if this is still the case)  
> and I didn't want that to be a show-stopper for Stefan. If this is  
> not the case anymore, then I would like to push -dagss into -devel.

Still having issues with it, but those were introduced by the new UnicodeType.
It seems that it doesn't behave well enough yet. It's currently a subtype of
BuiltinObjectType, but that induces problems with attribute access. Letting it
inherit from PyObjectType didn't provide a quick fix either.

I don't know when I will have time to look into this any further, sorry for
breaking it. May take a couple of days, unless someone else gets down to it.
If fixing it becomes too complicated, feel free to revert any of the unicode
changes for now that you consider offensive.

Stefan

headers

Robert Bradshaw | 14 Aug 08:02

Re: [Cython] Head fails tests

On Aug 13, 2008, at 10:38 PM, Stefan Behnel wrote:

> Hi Robert,
>
> Robert Bradshaw wrote:
>> My only concern is that Stefan's lxml was having trouble
>> compiling with the dagss branch (not sure if this is still the case)
>> and I didn't want that to be a show-stopper for Stefan. If this is
>> not the case anymore, then I would like to push -dagss into -devel.
>
> Still having issues with it, but those were introduced by the new  
> UnicodeType.
> It seems that it doesn't behave well enough yet. It's currently a  
> subtype of
> BuiltinObjectType, but that induces problems with attribute access.  
> Letting it
> inherit from PyObjectType didn't provide a quick fix either.
>
> I don't know when I will have time to look into this any further,  
> sorry for
> breaking it. May take a couple of days, unless someone else gets  
> down to it.
> If fixing it becomes too complicated, feel free to revert any of  
> the unicode
> changes for now that you consider offensive.

I haven't been able to get any failures on my end, and did fix some  
things related to this, so maybe I should try compiling lxml. Any  
tips, or do I just download and compile?

(Continue reading)

headers

Stefan Behnel | 14 Aug 08:34

Re: [Cython] Head fails tests

Robert Bradshaw wrote:
> On Aug 13, 2008, at 10:38 PM, Stefan Behnel wrote:
>> Still having issues with it, but those were introduced by the new
>> UnicodeType.
>> It seems that it doesn't behave well enough yet. It's currently a
>> subtype of
>> BuiltinObjectType, but that induces problems with attribute access.
>
> I haven't been able to get any failures on my end, and did fix some
> things related to this

I tried with the most recent -dagss branch and got an exception in
ExprNodes.py, line 2215, saying that the object_type doesn't have a scope.
That's because UnicodeType inherits from BuiltinPythonObject but does not
set up a local class scope (as the normal builtins do).

I think what we might try is to replace the UnicodeType class with the
actual BuiltinPythonObject instance that represents the unicode type, i.e.
the one that is created in Builtin.py. That sounds like a clean solution
to me (well, if it works, that is...)

> so maybe I should try compiling lxml. Any
> tips, or do I just download and compile?

If you can arrange it, that'd be nice. You'll need the -dev packages of
libxml2 and libxslt installed, the rest should work out of the box.

Stefan

(Continue reading)

headers

Robert Bradshaw | 14 Aug 09:50

Re: [Cython] Head fails tests

On Aug 13, 2008, at 11:34 PM, Stefan Behnel wrote:

> Robert Bradshaw wrote:
>> On Aug 13, 2008, at 10:38 PM, Stefan Behnel wrote:
>>> Still having issues with it, but those were introduced by the new
>>> UnicodeType.
>>> It seems that it doesn't behave well enough yet. It's currently a
>>> subtype of
>>> BuiltinObjectType, but that induces problems with attribute access.
>>
>> I haven't been able to get any failures on my end, and did fix some
>> things related to this
>
> I tried with the most recent -dagss branch and got an exception in
> ExprNodes.py, line 2215, saying that the object_type doesn't have a  
> scope.
> That's because UnicodeType inherits from BuiltinPythonObject but  
> does not
> set up a local class scope (as the normal builtins do).
>
> I think what we might try is to replace the UnicodeType class with the
> actual BuiltinPythonObject instance that represents the unicode  
> type, i.e.
> the one that is created in Builtin.py. That sounds like a clean  
> solution
> to me (well, if it works, that is...)

I'm really confused as to what the UnicodeType is suppose to  
represent. Is it a char* or a PyObject*? Currently it's both, which  
means that conversion doesn't happen either direction.

(Continue reading)

headers

Stefan Behnel | 14 Aug 11:08

Re: [Cython] Head fails tests

Robert Bradshaw wrote:
> On Aug 13, 2008, at 11:34 PM, Stefan Behnel wrote:
>> I think what we might try is to replace the UnicodeType class with the
>> actual BuiltinPythonObject instance that represents the unicode
>> type, i.e.
>> the one that is created in Builtin.py. That sounds like a clean
>> solution to me (well, if it works, that is...)
>
> I'm really confused as to what the UnicodeType is suppose to
> represent. Is it a char* or a PyObject*? Currently it's both, which
> means that conversion doesn't happen either direction.

It was supposed to be more or less what I describe above. The idea is to
let unicode literals have their actual Python type (i.e. PyUnicodeObject),
which is not compatible with a char*. That will assure that we always use
the right Python C-API operations on them instead of trying to handle them
as a special char*.

It's just that my current implementation is totally flawed and should have
used the 'real' unicode builtin type instead, that we create in Builtin.py
anyway. From a quick glance, this doesn't seem to be a quick change,
though, as we currently only declare builtin types and keep no further
(easy-to-find) reference to them, that we could retrieve in Symtab.py's
add_string_const().

Stefan

headers

Greg Ewing | 14 Aug 11:12

Re: [Cython] Head fails tests

Stefan Behnel wrote:
> From a quick glance, this doesn't seem to be a quick change,
> though, as we currently only declare builtin types and keep no further
> (easy-to-find) reference to them, that we could retrieve in Symtab.py's
> add_string_const().

You could put some init code in Builtin.py that looks
it up in the builtin scope and stashes it in a global
somewhere.

--

-- 
Greg

headers

Robert Bradshaw | 14 Aug 11:16

Re: [Cython] Head fails tests

On Aug 14, 2008, at 2:12 AM, Greg Ewing wrote:

> Stefan Behnel wrote:
>> From a quick glance, this doesn't seem to be a quick change,
>> though, as we currently only declare builtin types and keep no  
>> further
>> (easy-to-find) reference to them, that we could retrieve in  
>> Symtab.py's
>> add_string_const().
>
> You could put some init code in Builtin.py that looks
> it up in the builtin scope and stashes it in a global
> somewhere.

The commonly used ones do get stashed as global variables in the  
Builtin module, the rest one would have to do a lookup to get.

- Robert

headers

Robert Bradshaw | 14 Aug 11:16

Re: [Cython] Head fails tests

On Aug 14, 2008, at 2:08 AM, Stefan Behnel wrote:

> Robert Bradshaw wrote:
>> On Aug 13, 2008, at 11:34 PM, Stefan Behnel wrote:
>>> I think what we might try is to replace the UnicodeType class  
>>> with the
>>> actual BuiltinPythonObject instance that represents the unicode
>>> type, i.e.
>>> the one that is created in Builtin.py. That sounds like a clean
>>> solution to me (well, if it works, that is...)
>>
>> I'm really confused as to what the UnicodeType is suppose to
>> represent. Is it a char* or a PyObject*? Currently it's both, which
>> means that conversion doesn't happen either direction.
>
> It was supposed to be more or less what I describe above. The idea  
> is to
> let unicode literals have their actual Python type (i.e.  
> PyUnicodeObject),
> which is not compatible with a char*. That will assure that we  
> always use
> the right Python C-API operations on them instead of trying to  
> handle them
> as a special char*.
>
> It's just that my current implementation is totally flawed and  
> should have
> used the 'real' unicode builtin type instead, that we create in  
> Builtin.py
> anyway. From a quick glance, this doesn't seem to be a quick change,

(Continue reading)

headers

Stefan Behnel | 14 Aug 13:24

Re: [Cython] Head fails tests

Robert Bradshaw schrieb:
> On Aug 14, 2008, at 2:08 AM, Stefan Behnel wrote:
>> should have
>> used the 'real' unicode builtin type instead, that we create in
>> Builtin.py anyway.
>
> I changed it to use the buitin type, and am reverting back a bit to
> the old way of doing things. Unicode literals start out as python
> objects, so we don't need to worry about users doing C operations on
> them.

Ah, yes, I had forgotten about the global types in Builtin.py (and missed
them when skipping over it). I think that fixes it.

Stefan

headers

Robert Bradshaw | 14 Aug 11:23

Re: [Cython] Head fails tests

On Aug 14, 2008, at 2:08 AM, Stefan Behnel wrote:

> Robert Bradshaw wrote:
>> On Aug 13, 2008, at 11:34 PM, Stefan Behnel wrote:
>>> I think what we might try is to replace the UnicodeType class  
>>> with the
>>> actual BuiltinPythonObject instance that represents the unicode
>>> type, i.e.
>>> the one that is created in Builtin.py. That sounds like a clean
>>> solution to me (well, if it works, that is...)
>>
>> I'm really confused as to what the UnicodeType is suppose to
>> represent. Is it a char* or a PyObject*? Currently it's both, which
>> means that conversion doesn't happen either direction.
>
> It was supposed to be more or less what I describe above. The idea  
> is to
> let unicode literals have their actual Python type (i.e.  
> PyUnicodeObject),
> which is not compatible with a char*. That will assure that we  
> always use
> the right Python C-API operations on them instead of trying to  
> handle them
> as a special char*.
>
> It's just that my current implementation is totally flawed and  
> should have
> used the 'real' unicode builtin type instead, that we create in  
> Builtin.py
> anyway. From a quick glance, this doesn't seem to be a quick change,

(Continue reading)

headers

Robert Bradshaw | 13 Aug 18:49

Re: [Cython] Head fails tests

On Aug 13, 2008, at 8:35 AM, Neal Becker wrote:

> I did
> hg pull -u
> python setup.py build
> sudo python setup.py install
> python runtests.py
>
> running doctests in wundram1 ...
> ======================================================================
> ERROR: compiling and running ct_DEF
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File "runtests.py", line 261, in run
>     self.runCompileTest()
>   File "runtests.py", line 159, in runCompileTest
>     self.directory, self.expect_errors, self.annotate)
>   File "runtests.py", line 248, in compile
>     self.assertEquals(None, unexpected_error)
> AssertionError: None != '38:19: Invalid compile-time expression'
>
> Bunch more errors, including:
> AttributeError: 'NoneType' object has no attribute 'groups'
> ValueError: invalid literal for int() with base 10: '0F'
> AssertionError: <unprintable AssertionError object>

Thanks for the bug reports, I think I fixed these.

- Robert

(Continue reading)