[Cython] buffmt.__test__.wrongsize gets stuck after common_include_dir?
while trying to re-test Debian package build, in an interactive shell, I get cython test stuck at: ... Doctest: buffmt.__test__.wrongsize ... ok runTest (__main__.EndToEndTest) End-to-end basic_cythonize ... ok runTest (__main__.EndToEndTest) End-to-end basic_distutils ... ok runTest (__main__.EndToEndTest) End-to-end build_dir ... ok runTest (__main__.EndToEndTest) End-to-end common_include_dir ... tests were executed using runtests.py --no-refnanny -v -v --exclude="parallel" --work-dir=build/work-dir any clues? is it multiprocessing to blame again? /bin/bash /tmp/hooks/C10shell /bin/bash /usr/bin/make -f debian/rules binary /usr/bin/perl -w /usr/bin/dh binary --with python2,python3 --buildsystem python_distutils /usr/bin/make -f debian/rules override_dh_auto_test /bin/sh -c set -e; for P in 2.7 3.4; do \ echo "PYTHON: $P"; \ export; \ PYTHONPATH=`/bin/ls -d /tmp/buildd/cython-0.20.2/build/lib.*-$P` \ /usr/bin/python$P runtests.py --no-refnanny -v -v --exclude="parallel" --work-dir=build/work-dir; \ done /usr/bin/python2.7 runtests.py --no-refnanny -v -v --exclude=parallel --work-dir=build/work-dir /bin/sh -c /usr/bin/python2.7 setup.py build_ext --inplace /usr/bin/python2.7 setup.py build_ext --inplace /usr/bin/python2.7 setup.py build_ext --inplace /usr/bin/python2.7 setup.py build_ext --inplace -- Yaroslav O. Halchenko, Ph.D. http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org Research Scientist,Psychological and Brain Sciences Dept. Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Cython bugfix release
On Mon, 21 Jul 2014, Julian Taylor wrote:
> I haven't tried it but its possibly related to the C locale the debian
> builders use. Try with LC_ALL=C
that is the one set
> @Yaroslav if this the the case, the workaround would be building with
> LC_ALL=C.UTF-8
good hint, although would not serve us as a workaround but rather possibly
reveals the actual problem if ran in interactive mode (if I pipe the output --
the same error)...
the original error happens in the code which reacts to unsuccessful execution
of GdbDebuggerTestCaseand apparently has a problem with that unicode string
(although it was decoded from UTF-8 without errors). To say the truth, unicode
handling philosophical understanding is not my strongest skill, BUT it seems to
spit out the actual error without failing if I explicitly encode that errmsg
back into UTF-8 and write that. Alternative more generic implementation there
could be get a custom writer for stderr:
class TestAll(GdbDebuggerTestCase):
def test_all(self):
if not test_gdb():
return
out, err = self.p.communicate()
err = err.decode('UTF-8')
exit_status = self.p.returncode
import codecs
stderr = codecs.getwriter('utf8')(sys.stderr)
if exit_status == 1:
stderr.write(err)
elif exit_status >= 2:
border = u'*' * 30
start = u'%s v INSIDE GDB v %s' % (border, border)
end= u'%s ^ INSIDE GDB ^ %s' % (border, border)
errmsg = u'\n%s\n%s%s' % (start, err, end)
stderr.write(errmsg)
With such code it spits out errmsg reliably:
python runtests.py --no-refnanny -v -v --exclude="parallel"
--work-dir=build/work-dir TestLibCython
Python 2.7.8 (default, Jul 4 2014, 13:08:34)
[GCC 4.9.0]
Running tests against Cython 0.20.2
Backends: c,cpp
test_all (Cython.Debugger.Tests.TestLibCython.TestAll) ...
** v INSIDE GDB v **
warning: .cygdbinit: No such file or directory
EE...Function "__pyx_pw_8codefile_5outer_1inner" not defined.
Python Exception (u'a',):
EFSystemError: ../Objects/moduleobject.c:50: bad argument to internal function
E...SystemError: ../Objects/moduleobject.c:50: bad argument to internal function
Python Exception The program being debugged was signaled
while in a function called from GDB.
GDB remains in the frame where the signal was received.
To change this behavior use "set unwindonsignal on".
Evaluation of the expression containing the function
(PyModule_GetDict) will be abandoned.
When the function is done executing, GDB will silently stop.:
ESystemError: ../Objects/moduleobject.c:50: bad argument to internal function
Python Exception The program being debugged was signaled
while in a function called from GDB.
GDB remains in the frame where the signal was received.
To change this behavior use "set unwindonsignal on".
Evaluation of the expression containing the function
(PyModule_GetDict) will be abandoned.
When the function is done executing, GDB will silently stop.:
EE.EEE.E.FFF
==
ERROR: test_cyset (Cython.Debugger.Tests.test_libcython_in_gdb.CySet)
--
Traceback (most recent call last):
File
"/tmp/buildd/cython-0.20.2/Cython/Debugger/Tests/test_libcython_in_gdb.py",
line 38, in wrapper
return func(self, *args, **kwargs)
File
"/tmp/buildd/cython-0.20.2/Cython/Debugger/Tests/test_libcython_in_gdb.py",
line 387, in test_cyset
gdb.execute('cy set a = $cy_eval("{None: []}")')
File "/tmp/buildd/cython-0.20.2/Cython/Debugger/libpython.py", line 1860, in
execute
_execute(command, from_tty)
error: Selected frame does not correspond with a Cython function we know about.
==
ERROR: test_backtrace
(Cython.Debugger.Tests.test_libcython_in_gdb.TestBacktrace)
--
Traceback (most recent call last):
File
"/tmp/buildd/cython-0.20.2/Cython/Debugger/Tests/test_libcython_in_gdb.py",
line 38, in wrapper
return func(self, *args, **kwargs)
File
"/tmp/buildd/cython-0.20.2/Cython/Debugger/Tests/test_libcython_in_gdb.py",
line 292, in test_backtrace
result = gdb.execute('cy bt', to_string=True)
File "/tmp/buildd/cython-0.20.2/Cython/Debugger/libpython.py", line 1857, in
execute
_execute(command, from_tty)
error: Error occurred in Python command: 'FakeRepr' object has no attribute
'__getitem__'
MORE
> On 21.07.2014 19:46, Robert Bradshaw wrote:
> > I wasn't able to reproduce this myself, which is why I haven't done
> > anything about it yet...
> > On Sat, Jul 19, 2014 at 9:39 PM, Yaroslav Halchenko
> > mailto:li...@onerussian.com>> wrote:
> > that was quite an underwhelming response, now it is "official"
> > https://bu
Re: [Cython] Cython bugfix release
apparently relates back to
"Failing cygdb tests on master and 0.19.x"
https://groups.google.com/forum/#!topic/cython-users/SRKdbfftjMM
and https://github.com/cython/cython/pull/264
blind attempt to run with python-dbg build doesn't provide a relief (gdb is
7.7.1-2)
# PYTHONPATH=$PWD/build/lib.linux-x86_64-2.7-pydebug python2.7-dbg runtests.py
--no-refnanny -v -v --exclude="parallel" --work-dir=build/work-dir TestLibCython
Python 2.7.8 (default, Jul 4 2014, 13:12:00)
[GCC 4.9.0]
Running tests against Cython 0.20.2
Backends: c,cpp
test_all (Cython.Debugger.Tests.TestLibCython.TestAll) ...
** v INSIDE GDB v **
warning: .cygdbinit: No such file or directory
EF...Function "__pyx_pw_8codefile_5outer_1inner" not defined.
Python Exception (u'a',):
EFTraceback (most recent call last):
File "", line 1, in
NameError: name 'a' is not defined
F...Traceback (most recent call last):
File "", line 1, in
NameError: name 'a' is not defined
FTraceback (most recent call last):
File "", line 1, in
NameError: name 'some_random_var' is not defined
FE.EEE.E.FFF
==
ERROR: test_cyset (Cython.Debugger.Tests.test_libcython_in_gdb.CySet)
--
Traceback (most recent call last):
File
"/tmp/buildd/cython-0.20.2/build/lib.linux-x86_64-2.7-pydebug/Cython/Debugger/Tests/test_libcython_in_gdb.py",
line 38, in wrapper
return func(self, *args, **kwargs)
File
"/tmp/buildd/cython-0.20.2/build/lib.linux-x86_64-2.7-pydebug/Cython/Debugger/Tests/test_libcython_in_gdb.py",
line 387, in test_cyset
gdb.execute('cy set a = $cy_eval("{None: []}")')
File
"/tmp/buildd/cython-0.20.2/build/lib.linux-x86_64-2.7-pydebug/Cython/Debugger/libpython.py",
line 1860, in execute
_execute(command, from_tty)
error: Selected frame does not correspond with a Cython function we know about.
==
ERROR: test_inner (Cython.Debugger.Tests.test_libcython_in_gdb.TestClosure)
--
Traceback (most recent call last):
File
"/tmp/buildd/cython-0.20.2/build/lib.linux-x86_64-2.7-pydebug/Cython/Debugger/Tests/test_libcython_in_gdb.py",
line 38, in wrapper
return func(self, *args, **kwargs)
File
"/tmp/buildd/cython-0.20.2/build/lib.linux-x86_64-2.7-pydebug/Cython/Debugger/Tests/test_libcython_in_gdb.py",
line 420, in test_inner
self.assertEqual(str(self.read_var('a')), "'an object'")
File
"/tmp/buildd/cython-0.20.2/build/lib.linux-x86_64-2.7-pydebug/Cython/Debugger/Tests/test_libcython_in_gdb.py",
line 38, in wrapper
return func(self, *args, **kwargs)
File
"/tmp/buildd/cython-0.20.2/build/lib.linux-x86_64-2.7-pydebug/Cython/Debugger/Tests/test_libcython_in_gdb.py",
line 72, in read_var
result = gdb.parse_and_eval('$cy_cvalue("%s")' % varname)
error: Error occurred in Python convenience function: (u'a',)
...
On Tue, 22 Jul 2014, Yaroslav Halchenko wrote:
> On Mon, 21 Jul 2014, Julian Taylor wrote:
> > I haven't tried it but its possibly related to the C locale the debian
> > builders use. Try with LC_ALL=C
> that is the one set
> > @Yaroslav if this the the case, the workaround would be building with
> > LC_ALL=C.UTF-8
> good hint, although would not serve us as a workaround but rather possibly
> reveals the actual problem if ran in interactive mode (if I pipe the output --
> the same error)...
> the original error happens in the code which reacts to unsuccessful execution
> of GdbDebuggerTestCaseand apparently has a problem with that unicode string
> (although it was decoded from UTF-8 without errors). To say the truth,
> unicode
> handling philosophical understanding is not my strongest skill, BUT it seems
> to
> spit out the actual error without failing if I explicitly encode that errmsg
> back into UTF-8 and write that. Alternative more generic implementation there
> could be get a custom writer for stderr:
> class TestAll(GdbDebuggerTestCase):
> def test_all(self):
> if not test_gdb():
> return
> out, err = self.p.communicate()
> err = err.decode('UTF-8')
> exit_status = self.p.returncode
> import codecs
> stderr = codecs.getwriter('utf8')(sys.stderr)
> if exit_status == 1:
> stderr.write(err)
> elif exit_status >= 2:
> border = u'*' * 30
> start = u'%s v INSIDE GDB v %s' % (border, border)
> end= u'%s ^ INSIDE GDB ^ %s' % (border, border)
> errmsg = u'\n%s\n%s%s' % (start, err, end)
> stderr.write(errmsg)
> With such code it spits out errmsg reliably:
> python runtests.py --no-refnanny -v -v --exclude="parallel"
> --work-dir=build/work-dir TestLibCython
> Python 2.7.8 (default, Jul 4 2014, 13:08:34)
Re: [Cython] License information on each individual files
On Sun, Jul 20, 2014 at 12:37 AM, Stefan Behnel wrote: > > Nathaniel Smith, 19.07.2014 19:42: > > On Sat, Jul 19, 2014 at 7:39 AM, Stefan Behnel wrote: > >> Sturla Molden, 19.07.2014 00:36: > >>> Robert Bradshaw wrote: > It's not just the initial patch; I'm primarily worried about the > maintenance burden > >>> > >>> And also, will it break utility code and binary blobs? It might not even > >>> be > >>> safe to put it in every file. > >>> > >>> And when put in files with utility C code, will it be included in the > >>> generated .c file and taint this file with a notification about Cython's > >>> Apache license? > >> > >> Well, on the technical side, stuff at the beginning of a utility code file > >> should just be ignored, up to the first header line (starting with a > >> sequence of at least 5 comment characters). Some of them already contain > >> leading comments anyway. > >> > >> On the legal side, the licensing state of the generated code does not > >> change by copying the license description from the global license file into > >> each code file, because the global license already applies to the complete > >> code base anyway (unless stated otherwise). > >> > >> However, what *is* the licensing state of the generated code? Strictly > >> speaking, the code generated by Cython, all parts of which are embedded in > >> Cython's own source code, could be considered a "derivative work" by some. > > > > I suspect that "some" includes most lawyers and judges ;-). There's > > tons of copyrightable code copied into Cython output. > > The bulk of what gets "copied" are really just tiny character sequences > each of which would be impossible to protect legally. And they even get > substantially modified before being written out. But there's probably still > plenty of room for lawyers to sell days of work here, and the utility code > files form a major piece of work by themselves that gets copied into the > generated code in substantial (i.e. protectable) chunks. Agreed, but if someone wrote a new Python-to-C compiler and grabbed all our UtilityCodes to do so that would IMHO constitute a derivative work. > >> From my side, that statement definitely still applies. I really don't want > >> to have anything to say on what users do with the code generated from their > >> own source code. I do not even consider the generated code a "derivative > >> work" myself, but IANAL... Yep. That's been the position every time the topic has come up, and has been on our wiki for quite a while. I've clarified it here: https://github.com/cython/cython/pull/306 ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] Compiler crash: forward declaration of cdef class with "public" attributes
On Tue, Jul 8, 2014 at 4:34 PM, Alok Singhal wrote: > Hi, > > I am getting a compiler crash with the following code: > > $ cat foo.pxd > cdef class Foo: > cdef public object x > $ cat foo.pyx > cdef class Foo > > cdef class Foo: > pass > $ ./cython.py foo.pyx > > Error compiling Cython file: > > ... > cdef class Foo > ^ > > > foo.pyx:1:5: Compiler crash in AnalyseDeclarationsTransform > > ModuleNode.body = StatListNode(foo.pyx:1:0) > StatListNode.stats[0] = CClassDefNode(foo.pyx:1:5, > as_name = u'Foo', > class_name = u'Foo', > module_name = '', > visibility = 'private') > > Compiler crash traceback from this point on: > File "/Users/alok/Downloads/repos/cython.git/Cython/Compiler/Visitor.py", > line 173, in _visit > return handler_method(obj) > File > "/Users/alok/Downloads/repos/cython.git/Cython/Compiler/ParseTreeTransforms.py", > line 1478, in visit_CClassDefNode > node.body.stats += stats > AttributeError: 'NoneType' object has no attribute 'stats' > > The problem seems to be due to having a .pxd file with the attributes of the > cdef class in it. Since the attributes are declared "public", Cython is > trying to generate property code for "Foo.x". But it's trying to do that at > the point of forward declaration in the .pyx file, instead of the definition > of the class. > > An easy fix seems to be to change > AnalyseDeclarationsTransform.visit_CClassDefNode in ParseTreeTransforms.py > to check for node.body not being none. I.e., the following patch seems to > work: > > diff --git a/Cython/Compiler/ParseTreeTransforms.py > b/Cython/Compiler/ParseTreeTransforms.py > index f8c2efa..7811d56 100644 > --- a/Cython/Compiler/ParseTreeTransforms.py > +++ b/Cython/Compiler/ParseTreeTransforms.py > @@ -1466,7 +1466,7 @@ if VALUE is not None: > > def visit_CClassDefNode(self, node): > node = self.visit_ClassDefNode(node) > -if node.scope and node.scope.implemented: > +if node.body and node.scope and node.scope.implemented: > stats = [] > for entry in node.scope.var_entries: > if entry.needs_property: > > Thanks, > Alok Thanks. https://github.com/cython/cython/commit/967c8e11da94ddae1ea7f1524f6beef2e030c4d9 FWIW, forward declarations should not generally be needed, and certainly not needed if the class is already declared in a pxd file. ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
