Permalink
Commits on Jan 28, 2013
  1. prepare release of 0.18

    scoder committed Jan 28, 2013
Commits on Jan 27, 2013
  1. Fix overflow_check CompileError with msvc

    --HG--
    extra : transplant_source : %3FH%B6t%1FFL%D8%2BF%7CV%7D%10T9%EA%CB%A0%00
    cgohlke committed Jan 27, 2013
  2. set version to 0.18rc1

    scoder committed Jan 27, 2013
  3. fix new test in Py2.[45]

    scoder committed Jan 27, 2013
Commits on Jan 26, 2013
  1. changelog

    scoder committed Jan 26, 2013
  2. fix test when using NumPy 1.7

    scoder committed Jan 26, 2013
  3. fix new memory view error test in Py2.4

    --HG--
    extra : transplant_source : %8A%F1%17%5C%A7%CA%1C%B1%17%A1%C5t%06O%5BI%F2%19Vq
    scoder committed Jan 26, 2013
Commits on Jan 25, 2013
  1. Fix calling an "except +" cpp function in a nogil function

    For a source:
    |cdef extern from "<foo>":
    |    cdef void foo_cpp() nogil except +
    |
    |cdef call_foo() nogil:
    |    foo_cpp()
    
    We used to generate something like this to actually call foo_cpp() in call_foo():
    |try{foo_cpp();}
    |catch(...) {
    |  Py_BLOCK_THREADS; __Pyx_CppExn2PyErr(); Py_UNBLOCK_THREADS
    |  `code.error_goto(self.pos))`
    |}
    
    where Py_BLOCK_THREADS expands to "PyEval_RestoreThread(_save);".
    __Pyx_CppExn2PyErr() (and alternatives, see SimpleCallNode) calls CPython A API
    methods so it needs to be guarded in a nogil environment.
    
    One problem is that "PyThreadState *_save" is only declared by "with nogil:"
    block, so a .cpp file that doesn't compile is generated for the above code.
    
    However, I think the real issue is that Py_(UN)BLOCK_THREADS is inappropriate
    here, as it isn't allowed to be called recursively and is valid only directly
    in a Py_BEGIN_ALLOW_THREADS ... Py_END_ALLOW_THREADS. IMO PyGILState_Ensure()
    and PyGILState_Release() (through `code.put_ensure_gil()` and a friend) is the
    correct thing to call here as it is allowed to be called recursively and
    actually ensures the current thread can call CPython C API.
    
    This patch does exactly this (and it breaks the generated code to multiple
    lines as it would be way too long otherwise), plus it extends the
    cpp_exceptions_nogil.pyx test with above example that doesn't compile with this
    fix not applied.
    
    Note that we explicitly pass declare_gilstate=True to put_ensure_gil(), as
    PyGILState_Ensure() docs state that recursive calls to it must not share the
    PyGILState_STATE. C++-style declaring a variable inside a block should be
    no-problem here, as try{} .. catch() is obviously valid only in a C++ code.
    
    --HG--
    extra : transplant_source : %AA%F3%BDk%FE%F9%01%7F%8C%A4n%5E%DA4%97%A5%D9%AF%D60
    strohel committed Jan 25, 2013
Commits on Jan 24, 2013
  1. Fix error propagation from memoryview-returning functions

    A code like
    |cdef double[:] foo():
    |    raise AttributeError('dummy')
    
    generated C code like this:
    |  __pyx_L1_error:;
    |  (...)
    |  __pyx_r.memview = NULL;
    |  __Pyx_AddTraceback("view_return_errors.foo", __pyx_clineno, __pyx_lineno, __pyx_filename);
    |  __pyx_L0:;
    |  if (unlikely(!__pyx_r.memview)) {
    |    PyErr_SetString(PyExc_TypeError,"Memoryview return value is not initialized");
    |  }
    |  __Pyx_RefNannyFinishContext();
    |  return __pyx_r;
    |}
    
    Which is incorrect in error case, because we set __pyx_r.memview to NULL and
    then we test it, so that the PyErr_SetString() is always called in the error
    case, which swallows previously-set error. (it also swallowed the traceback,
    which I don't understand)
    
    A fix is to jump to return_from_error_cleanup label in case return type is
    memoryview, as it is currently done for the case when buffers are present.
    
    A testcase that fauils w/out this fix applied is included, too.
    
    v2: fix test under Python 3 by not using StandardError
    
    --HG--
    extra : transplant_source : G%B5%99Og%D1%81%25k%8F%1F%7B%02V%3E%B9%A4y%FF%EA
    strohel committed Jan 24, 2013
Commits on Jan 21, 2013
  1. fix indentation error in userguide

    --HG--
    extra : transplant_source : %7B%A4%F1%C4/%E4l%2C_%BFF%5B%B7%9C%9F%E0_%2B%15%3D
    larsmans committed Jan 21, 2013
  2. fix compiler crash in error case

    scoder committed Jan 21, 2013
  3. simplify abs() optimisation for C integers and fix it for the most ne…

    …gative int/long value
    scoder committed Jan 21, 2013
Commits on Jan 20, 2013
  1. fix test

    scoder committed Jan 20, 2013
  2. move exception class into shadow function as we may not want to expor…

    …t it under the cython.* namespace at this point
    scoder committed Jan 20, 2013
Commits on Jan 19, 2013
  1. set version to 0.18b1

    scoder committed Jan 19, 2013
  2. removed broken minivect related code from branch since minivect will …

    …not be released as part of 0.18
    scoder committed Jan 19, 2013
Commits on Jan 18, 2013
  1. changelog

    scoder committed Jan 18, 2013
  2. fix cimport in libcpp.string

    --HG--
    extra : transplant_source : %E6%CA%F8%11%E8%81u%B9%95%3D%27%C1%0F%F3O%8A%12%3Cnl
    scoder committed Jan 18, 2013
  3. update 'const' section in string handling tutorial to reflect the new…

    … 'const' language support
    
    --HG--
    extra : transplant_source : U%15%0B%8E%81%02%F2kE%AA%07u%EF%82%3D14%F1C%86
    scoder committed Jan 18, 2013
  4. replace 'const_xyz' work-arounds in standard .pxd files by real 'cons…

    …t' declarations
    
    --HG--
    extra : transplant_source : H%91%CF%08t%B1%908%AE%26%81%1B%F9%2C%9A%3Fh%ECWK
    scoder committed Jan 18, 2013
Commits on Jan 16, 2013
  1. fix import of pyx modules when '' is in sys.path

    If '' is in sys.path and a module is found the package_path
    is relative and breaks the build process.
    
    --HG--
    extra : transplant_source : 9%EA%CC%A6%3D%1B9R%EF%0DmM%CFZ%18%F3%EC%06%3B%B7
    steinn committed Jan 16, 2013
Commits on Jan 15, 2013
  1. Use OS-dependent directory separator - a / on windows is interpreted …

    …by LINK as a command line switch
    
    --HG--
    extra : transplant_source : %A8%F23%AF%26%BC%82y1%86S%1Ac%D3%40%089o%DCQ
    stevenwinfield committed Jan 15, 2013
Commits on Jan 14, 2013
Commits on Jan 12, 2013
Commits on Jan 10, 2013
  1. preprocess byte string literal escaping instead of doing repeated rep…

    …lacements at runtime
    scoder committed Jan 10, 2013
Commits on Nov 29, 2012
  1. Add test for memoryview of extension type

    A test for a bug fixed in commit 478b939.
    
    v2: add commit link above
    v3: # tag: instead of # tags:, drop cpp tag as it means something different
        that I originally thought
    
    There was a bug that produced C code where gcc emitted warnings:
    extension_type_memoryview.c: In function ‘__pyx_pf_25extension_type_memoryview_test_getitem’:
    extension_type_memoryview.c:1468:15: warning: assignment from incompatible pointer type
    extension_type_memoryview.c: In function ‘__pyx_pf_25extension_type_memoryview_2test_getitem_typed’:
    extension_type_memoryview.c:1565:15: warning: assignment from incompatible pointer type
    extension_type_memoryview.c:1568:18: warning: assignment from incompatible pointer type
    
    And g++ failed with errors:
    extension_type_memoryview.c: In function ‘PyObject* __pyx_pf_25extension_type_memoryview_test_getitem(PyObject*)’:
    extension_type_memoryview.c:1468:213: error: cannot convert ‘__pyx_obj_25extension_type_memoryview_ExtensionType*’ to ‘PyObject*’ in assignment
    extension_type_memoryview.c: In function ‘PyObject* __pyx_pf_25extension_type_memoryview_2test_getitem_typed(PyObject*)’:
    extension_type_memoryview.c:1565:213: error: cannot convert ‘__pyx_obj_25extension_type_memoryview_ExtensionType*’ to ‘PyObject*’ in assignment
    extension_type_memoryview.c:1568:20: error: cannot convert ‘PyObject*’ to ‘__pyx_obj_25extension_type_memoryview_ExtensionType*’ in assignment
    
    --HG--
    extra : transplant_source : %02N%D4%B99N%D6%FBv%7C%F0%94%E5%BE%CE%C9t%D6%04%11
    strohel committed Nov 29, 2012