Re: [Cython] Merging memoryview
Robert Bradshaw wrote: On Feb 3, 2010, at 1:22 AM, Dag Sverre Seljebotn wrote: Me and Kurt's been talking about (finally) getting the memory views merged. Initially I held back because I wanted to do my part of the job first (support indexing, currently they only support raw buffer access and copying), but in the light of how long that's been taking me it's better to get things merged now -- especially as Kurt has a use for the existing functionality in fwrap. I think we should probably be merging this stuff, but just to confirm what I'm reading below, it's all new stuff (not changing or breaking what's there, right)? Yep, new stuff (so people shouldn't notice it being there, modulo any bugs). Question first: - Should the memoryview namespace be named cython.view, cython.memview, cython.memoryview, cython.mview, cython.memory, cython.buffer? When will the user be seeing this namespace? Is it all hidden in the int[:] syntax (in which case it shouldn't matter much)? Are there a plethera of functions, or do you just need a place to stick a single class (in which case the namespace might be unneeded, though there's still the question of naming the class). 1) The main usecase is for the stride specifiers: cdef int[::cython.mview.indirect cython.mview.contig] for a contiguous array of pointers to single integers, for instance. 2) The cython.mview.array type. But in time I expect that will be enhanced more and can then live in the plain cython scope, so this doesn't affect naming. 3) Some things from that namespace is used in testcases, but that's not important. but it shouldn't interfer as long as you don't use the above namespace or the int[:]-syntax. The gsoc-kurt branch has had the changes from cython-devel merged into it and there's no real conflict, but some stuff left to do. The way things are looking I suggest that: a) The closure branch gets to merge first b) We try to keep gsoc-kurt updated and merge it afterwards. Kurt should hopefully be able to plan on gsoc-kurt being merged in time for 0.13 and use it for fwrap development. Open tasks before we can merge gsoc-kurt: - Types created by Cython output in wrong order (again!). This is getting silly, and somebody, meaning me I guess, should code up a DAG for outputting type declarations in their right order. See http://trac.cython.org/cython_trac/ticket/469. - memview_declarations fail due to invalid use of follow specifier. Kurt, could you have a look? If for whatever reason these don't look feasible by 0.13, let's not hold up the release for it. Sure. Dag Sverre ___ Cython-dev mailing list Cython-dev@codespeak.net http://codespeak.net/mailman/listinfo/cython-dev
Re: [Cython] 0.12.1 Tests failing on ppc
On Feb 4, 2010, at 10:29 AM, Neal Becker wrote: So, do you believe it is OK to release this code as is? I'm holding up updating Fedora. Yes, you should be fine releasing. We're erroneously testing something that's platform dependent here. - Robert Robert Bradshaw wrote: It looks like all of these have to do with char being unsigned in your environment. (Whether char is signed is implementation dependent...) We should fix/disable the tests on platforms where this is the case. On Feb 2, 2010, at 4:52 AM, Neal Becker wrote: Build log is here: http://koji.fedoraproject.org/koji/getfile?taskID=1958725name=build.log Errors start with: ERROR: Doctest: c_int_types_T255 -- Traceback (most recent call last): File /usr/lib/python2.6/doctest.py, line 2145, in runTest raise self.failureException(self.format_failure(new.getvalue())) AssertionError: Failed doctest test for c_int_types_T255 File /builddir/build/BUILD/Cython-0.12.1/BUILD/run/c/ c_int_types_T255.so, line 92, in c_int_types_T255 -- File /builddir/build/BUILD/Cython-0.12.1/BUILD/run/c/ c_int_types_T255.so, line 98, in c_int_types_T255 Failed example: test_char(CHAR_MIN) == CHAR_MIN Exception raised: Traceback (most recent call last): File /usr/lib/python2.6/doctest.py, line 1241, in __run compileflags, 1) in test.globs File doctest c_int_types_T255[1], line 1, in module test_char(CHAR_MIN) == CHAR_MIN File c_int_types_T255.pyx, line 8, in c_int_types_T255.test_char (c_int_types_T255.c:644) OverflowError: can't convert negative value to char ___ Cython-dev mailing list Cython-dev@codespeak.net http://codespeak.net/mailman/listinfo/cython-dev ___ Cython-dev mailing list Cython-dev@codespeak.net http://codespeak.net/mailman/listinfo/cython-dev ___ Cython-dev mailing list Cython-dev@codespeak.net http://codespeak.net/mailman/listinfo/cython-dev
Re: [Cython] Merging memoryview
On Fri, Feb 5, 2010 at 1:08 PM, Robert Bradshaw
rober...@math.washington.edu wrote:
On Feb 5, 2010, at 10:58 AM, Kurt Smith wrote:
Along with that: we discussed using the ampersand as the conjunctive
for the different stride and memory access flags (I thought it was
more pythonic, although less 'C'-like), or we could also go with the
pipe (|) symbol instead, ala C flags. If it's already decided and
behind us, then I'm fine with it.
Personally, I think the best would be and a la Python. When I see |
and , I instinctively parse that as C flags (and the example you gave
threw me for a loop for a sec, but I didn't want to bring it up
myself.) Of course using | as in C will probably be unfamiliar to
those with only Python experience, and doesn't read as well.
As I recall, we went with '' since it has some pedigree in
python-dev discussions on combining abstract base classes (I can't
recall the context), although I can't find the email thread ATM, and
it isn't implemented in Python. The and keyword has the benefit of
reading better and making it clearly a conjunction of objects, and
less a conjunction of C-flags. I'm fine with either, and will gladly
implement whatever is decided ('' is implemented currently, but it's
easy to change). I'm sure Dag has some thoughts on the matter.
Kurt
___
Cython-dev mailing list
Cython-dev@codespeak.net
http://codespeak.net/mailman/listinfo/cython-dev
Re: [Cython] Generate shorter string literals
On Fri, Feb 5, 2010 at 4:31 PM, Robert Bradshaw
rober...@math.washington.edu wrote:
On Feb 5, 2010, at 7:54 AM, Christoph Gohlke wrote:
Dear Cython developers,
This is related to http://trac.cython.org/cython_trac/ticket/50.
Cython 0.12.1 still generates string literals that can be too long
for MSVC*
compilers. Please consider the following patch.
diff -r 8bff3332e34f Cython/Compiler/Code.py
--- a/Cython/Compiler/Code.py Tue Feb 02 02:10:32 2010 -0800
+++ b/Cython/Compiler/Code.py Thu Feb 04 19:32:40 2010 -0800
@@ -667,7 +667,7 @@
decls_writer = self.parts['decls']
for _, cname, c in c_consts:
decls_writer.putln('static char %s[] = %s;' % (
- cname, c.escaped_value))
+ cname,
StringEncoding.split_docstring(c.escaped_value)))
if c.py_strings is not None:
for py_string in c.py_strings.itervalues():
py_strings.append((c.cname, len(py_string.cname),
py_string))
Thanks! http://hg.cython.org/cython-devel/rev/dc2a7157de42
I agree testcases would be good to have to ensure this doesn't happen
again.
Sorry, I should review the patch in the context of the whole code,
but... Is split_docstring() a proper name for the method, given that
IIUC it have to be used for any string literal and no just
docstrings... Sorry for being too pedantic ...
--
Lisandro Dalcín
---
Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
PTLC - Güemes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594
___
Cython-dev mailing list
Cython-dev@codespeak.net
http://codespeak.net/mailman/listinfo/cython-dev
Re: [Cython] Generate shorter string literals
On Feb 5, 2010, at 11:36 AM, Lisandro Dalcín wrote:
On Fri, Feb 5, 2010 at 4:31 PM, Robert Bradshaw
rober...@math.washington.edu wrote:
On Feb 5, 2010, at 7:54 AM, Christoph Gohlke wrote:
Dear Cython developers,
This is related to http://trac.cython.org/cython_trac/ticket/50.
Cython 0.12.1 still generates string literals that can be too long
for MSVC*
compilers. Please consider the following patch.
diff -r 8bff3332e34f Cython/Compiler/Code.py
--- a/Cython/Compiler/Code.py Tue Feb 02 02:10:32 2010 -0800
+++ b/Cython/Compiler/Code.py Thu Feb 04 19:32:40 2010 -0800
@@ -667,7 +667,7 @@
decls_writer = self.parts['decls']
for _, cname, c in c_consts:
decls_writer.putln('static char %s[] = %s;' % (
-cname, c.escaped_value))
+cname,
StringEncoding.split_docstring(c.escaped_value)))
if c.py_strings is not None:
for py_string in c.py_strings.itervalues():
py_strings.append((c.cname,
len(py_string.cname),
py_string))
Thanks! http://hg.cython.org/cython-devel/rev/dc2a7157de42
I agree testcases would be good to have to ensure this doesn't happen
again.
Sorry, I should review the patch in the context of the whole code,
but... Is split_docstring() a proper name for the method, given that
IIUC it have to be used for any string literal and no just
docstrings... Sorry for being too pedantic ...
I had exactly the same thought, but since I didn't have an immediate
better name I just left it as is. (split_string is to generic,
split_long_string? split_stringliteral?)
- Robert
___
Cython-dev mailing list
Cython-dev@codespeak.net
http://codespeak.net/mailman/listinfo/cython-dev
