unfortunately 0.13 leads to FTBFS (on my system, not a clean environment) for 3
dependent packages in the archive. So, I will postpone upload of 0.13 (current
HG tip causes the same problems) and consulting [1] cython upstream regarding
__getsegcount__ (listed deeper below), but as for segfault in djvu -- Jakub?
python-djvulibre -- segfault during unittesting
*$>
PYTHONPATH=/home/yoh/deb/debs/build-area/cython-test-bdepeds/python-djvulibre-0.1.18/build/lib.linux-x86_64-2.6
python -c 'from djvu.const import *'
Traceback (most recent call last):
File "<string>", line 1, in <module>
File
"/home/yoh/deb/debs/build-area/cython-test-bdepeds/python-djvulibre-0.1.18/build/lib.linux-x86_64-2.6/djvu/const.py",
line 15, in <module>
import djvu.sexpr
File "sexpr.pyx", line 1, in init djvu.sexpr (djvu/sexpr.c:10615)
AttributeError: 'module' object has no attribute 'Symbol__new__'
*$>
PYTHONPATH=/home/yoh/deb/debs/build-area/cython-test-bdepeds/python-djvulibre-0.1.18/build/lib.linux-x86_64-2.6
python2.6 /usr/bin/nosetests --with-doctest --verbose const.py sexpr.py
Failure: AttributeError ('module' object has no attribute
'Symbol__new__') ... ERROR
sexpr.test_symbols ... ok
Doctest: sexpr.ExpressionParser ... Segmentation fault
from valgrind:
==3294== Process terminating with default action of signal 11 (SIGSEGV)
==3294== Access not within mapped region at address 0x8
==3294== at 0x4491D6: PyObject_GetAttr (object.c:1110)
==3294== by 0xC39674C: __Pyx_GetName (sexpr.c:10718)
==3294== by 0xC3A21B2: __pyx_pf_4djvu_5sexpr_Expression__new__ (sexpr.c:3385)
==3294== by 0x418492: PyObject_Call (abstract.c:1861)
==3294== by 0x45D79C: slot_tp_new (typeobject.c:5019)
==3294== by 0x46B672: type_call (typeobject.c:422)
==3294== by 0x418492: PyObject_Call (abstract.c:1861)
==3294== by 0x48F62D: PyEval_EvalFrameEx (ceval.c:3823)
==3294== by 0x4915F8: PyEval_EvalCodeEx (ceval.c:2875)
==3294== by 0x491721: PyEval_EvalCode (ceval.c:514)
==3294== by 0x4A4CED: PyImport_ExecCodeModuleEx (import.c:675)
==3294== by 0x4A6736: load_source_module (import.c:959)
and pyx code is somewhat puzzling to me since unbound Symbol__new__ gets
explicitly deleted and I do not know Cython well enough to comprehend this
pattern:
def Symbol__new__(cls, name):
'''
Symbol(name) -> a symbol
'''
self = None
if is_unicode(name):
name = encode_utf8(name)
try:
if cls is _Symbol_:
self = symbol_dict[name]
except KeyError:
pass
if self is None:
name = str(name)
self = BaseSymbol.__new__(cls, name)
if cls is _Symbol_:
symbol_dict[name] = self
return self
class Symbol(BaseSymbol):
__new__ = staticmethod(Symbol__new__)
cdef object _Symbol_
_Symbol_ = Symbol
del Symbol__new__
python-evas and -ecore -- seems to be cython's problem since
__getsegcount__(self, int *)
still part of Cython's API described in Doc/special_methods.html
Error converting Pyrex file to C:
------------------------------------------------------------
...
if ptrptr != NULL:
buf =
<void*>ecore_evas_buffer_pixels_get(self.obj);
ptrptr[0] = buf
return self._get_buf_size()
def __getsegcount__(self, int *lenp):
^
------------------------------------------------------------
Error converting Pyrex file to C:
------------------------------------------------------------
...
f = flags
else:
f = NULL
evas_object_image_save(self.obj, filename, k, f)
def __getsegcount__(self, int *p_len):
^
[1]
http://groups.google.com/group/cython-users/browse_thread/thread/49e694288b79d17c
On Fri, 24 Sep 2010, Sandro Tosi wrote:
> On Fri, Sep 24, 2010 at 23:01, Yaroslav Halchenko <deb...@onerussian.com>
> wrote:
> > FWIW -- 0.13 uupdates and seems to build and function just fine
> > (didn't check in clean pbuilder though)
> I know Ondrej is quite busy with his RL, and given you're interested
> in cython, you might want to co-maintain it with Ondrej under the PAPT
> umbrella: Ondrej, what do you think?
> Regards,
--
.-.
=------------------------------ /v\ ----------------------------=
Keep in touch // \\ (yoh@|www.)onerussian.com
Yaroslav Halchenko /( )\ ICQ#: 60653192
Linux User ^^-^^ [175555]
_______________________________________________
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/python-modules-team
