u are not in a rush to release 3.0.6, I would like to have some time
to properly investigate what's going on.
--
Lisandro Dalcin
Senior Research Scientist
Extreme Computing Research Center (ECRC)
King Abdullah University of Science and Technolo
What about adding a Cython compiler directive to set the default value of
the new macro? That way, it is up to the project's authors/maintainers to
decide on how to handle this, they are in a better position to weigh the
performance vs. portability trade-off. You still have to decide on the
defa
N_FAST_GIL=0" to your CFLAGS to disabled it (and "=1"
> to enable it explicitly). It's enabled by default in CPython 3.6-3.11 (but
> disabled in Cython 0.29.x on Python 3.11).
>
> Thanks,
> Stefan
> ___
&
think?
>
I would not say that mpi4py is a big project, but it is around 15K lines of
Cython code, and it is also ready for Cython 3. I'll update mpi4py
requirements to `cython>=3` as soon as Cython 3 is released.
--
Lisandro Dalcin
Senior Research Scientist
Extreme Computing
or` loop, and either let the C
compiler complain about the user code breaking the rules, or let users pay
for the consequences of breaking the Open MP rules with undefined behavior.
--
Lisandro Dalcin
Senior Research Scientist
Extreme Computing Research Center (ECRC)
King Abdullah U
n comment in sources.
In the face of ambiguity... give users various alternatives to the control
the behavior.
--
Lisandro Dalcin
Senior Research Scientist
Extreme Computing Research Center (ECRC)
King Abdullah University of Science and Technology (KAUST)
uld
> mean that we can start using f-strings, dict ordering, and what not.
>
> Any objections?
>
Not at all!
--
Lisandro Dalcin
Senior Research Scientist
Extreme Computing Research Center (ECRC)
King Abdullah University of Science and Technolog
what to do with
C/C++ types, and the interaction with the annotation typing directive.
> Also thinking of C++ types here…
>
>
OK. Material for further discussion.
Regards,
--
Lisandro Dalcin
Senior Research Scientist
Extreme Computing Research Center (ECRC)
King Abdullah Uni
tput.
But IMHO the new output looks way better and it is totally in line with the
new trend of using annotations and typing.
PS: I should have raised this proposal earlier, but I've been quite busy,
sorry about that.
--
Lisandro Dalcin
Senior Research Scientist
Extreme Computing Re
Folks, let me fix the the CYTHON_FALLTHROUGH the right way.
Additionally, I'll extend the Travis-CI build matrix with python 2/3
and a couple of xcode images.
On 14 October 2017 at 01:22, Stefan Behnel wrote:
> Lisandro Dalcin schrieb am 13.10.2017 um 21:42:
>> This is from a con
ribute(fallthrough)
#define CYTHON_FALLTHROUGH __attribute__((fallthrough))
#elif defined(__GNUC__) && defined(__attribute__)
#define CYTHON_FALLTHROUGH __attribute__((fallthrough))
#else
#define CYTHON_FALLTHROUGH
#endif
#endif
--
Lisandro Dalcin
R
On 27 September 2017 at 17:18, Stefan Behnel wrote:
> Lisandro Dalcin schrieb am 27.09.2017 um 15:53:
>> Annotations can be used for
>> type hinting, but they are not required to do that.
>
> Well, they sort of are, according to PEP 484.
>
I gently disagree. Third paragra
On 27 September 2017 at 15:54, Stefan Behnel wrote:
> Hi Lisandro,
>
> Lisandro Dalcin schrieb am 27.09.2017 um 14:42:
>> $ cython --version
>> Cython version 0.27
>>
>> $ cat tmp.pyx
>> def f() -> (list, list):
>> return [], []
>>
uct/union member cannot be a Python object
--
Lisandro Dalcin
Research Scientist
Computer, Electrical and Mathematical Sciences & Engineering (CEMSE)
Extreme Computing Research Center (ECRC)
King Abdullah University of Science and Technology (KAUST)
http://ecrc.kaust.edu.sa/
4700
b5506a3d8ddde646b7586d5703 Cython-0.23.4.zip
>
Stefan, should we upload wheels to PyPI? It is a bit of manual work,
as we would need to download artifacts for every build here:
https://ci.appveyor.com/project/cython/cython/build/0.23.x-31 then use
twine to do the uploads. I do
just dissabling them at the
command line. At some point, I'll need help to resolve them.
--
Lisandro Dalcin
Research Scientist
Computer, Electrical and Mathematical Sciences & Engineering (CEMSE)
Numerical Porous Media Center (NumPor)
King Abdullah University of Sc
On 2 October 2015 at 17:01, Stefan Behnel wrote:
> Lisandro Dalcin schrieb am 02.10.2015 um 15:18:
>> On 2 October 2015 at 15:07, Lisandro Dalcin wrote:
>>> On 2 October 2015 at 14:30, Stefan Behnel wrote:
>>>> Ah - note that Python 3.2 still uses the unicode fixe
On 2 October 2015 at 15:07, Lisandro Dalcin wrote:
> On 2 October 2015 at 14:30, Stefan Behnel wrote:
>> Ah - note that Python 3.2 still uses the unicode fixer of 2to3, so the code
>> is not entirely legacy. Would be nice if it could be moved out of the way,
>> though. Esp
aware of this. I'll push a fix in branch 0.23.x (I'm doing my
tests in OS X), then see what happens with the AppVeyor builds.
--
Lisandro Dalcin
Research Scientist
Computer, Electrical and Mathematical Sciences & Engineering (CEMSE)
Numerical Porous Media Center (NumPor)
required 2to3. BTW, in setup.py, compile_cython_modules()
follows quite a different path in Python 2 versus 3.
Unless some of you believe we should keep things that way, I'll try to
fix setup.py to be as much independent as possible of the major Python
version.
--
Lisandro Dalcin
Res
On 29 March 2015 at 21:02, Stefan Behnel wrote:
> Lisandro Dalcin schrieb am 29.03.2015 um 19:40:
>> On 29 March 2015 at 20:30, Lisandro Dalcin wrote:
>>> On 29 March 2015 at 16:10, Stefan Behnel wrote:
>>>> Why not call PyObject_RichCompareBool() to make cpyext itse
On 29 March 2015 at 20:30, Lisandro Dalcin wrote:
> On 29 March 2015 at 16:10, Stefan Behnel wrote:
>> Why not call PyObject_RichCompareBool() to make cpyext itself compare the
>> value to 0?
>
> That should definitely work. Let me try to put a patch together.
>
Stefa
On 29 March 2015 at 16:10, Stefan Behnel wrote:
> Why not call PyObject_RichCompareBool() to make cpyext itself compare the
> value to 0?
That should definitely work. Let me try to put a patch together.
--
Lisandro Dalcin
Research Scientist
Computer, Electrical and Mathem
On 29 March 2015 at 14:19, Lisandro Dalcin wrote:
> On 29 March 2015 at 13:33, Stefan Behnel wrote:
>> Lisandro Dalcin schrieb am 29.03.2015 um 12:17:
>>> At some point Cython lost the ability of using PY_LONG_LONG instead of
>>> "long long" in genera
On 29 March 2015 at 14:16, Stefan Behnel wrote:
> Lisandro Dalcin schrieb am 29.03.2015 um 12:23:
>> One thing that Cython developers really need is PyPy defining a macro
>> such as PYPY_VERSION_HEX in such a way us we can properly use
>> conditional compilation. For example,
On 29 March 2015 at 13:33, Stefan Behnel wrote:
> Lisandro Dalcin schrieb am 29.03.2015 um 12:17:
>> At some point Cython lost the ability of using PY_LONG_LONG instead of
>> "long long" in generated C code. The big offenders are the following
>> two files:
e
interpreter broke at runtime. This issue will be eventually fixed, I
hope. Unce that happens, how can we know it is save to use the call
for that pypy version and upwards? I mean, Cython should still support
previous PyPy releases...
--
Lisandro Dalcin
Research Scientist
Compu
compilers? Going back to PY_LONG_LONG everywhere is quite
easy right now, let me know and I'll contribute the patch for the
upcoming 0.22.1 release (if that ever happens).
--
Lisandro Dalcin
Research Scientist
Computer, Electrical and Mathematical Sciences & Engineering (CEMS
On 18 March 2015 at 17:07, Stefan Behnel wrote:
> LGTM. I tend to use the shorter "#ifndef" instead of "#if !defined()", though.
Do you want me to change it in master? No problem, just ask for it.
--
Lisandro Dalcin
Research Scientist
Computer, Elec
d not run the
full test suite with python3, my fault.
I'll look at this issue tomorrow and push a fix ASAP.
--
Lisandro Dalcin
Research Scientist
Computer, Electrical and Mathematical Sciences & Engineering (CEMSE)
Numerical Porous Media Center (NumPor)
King Abdullah
a.py?at=master#cl-13
Any suggestions about how to check signedness in Python 3 (CPython and
PyPy) without using Py_SIZE() ?
--
Lisandro Dalcin
Research Scientist
Computer, Electrical and Mathematical Sciences & Engineering (CEMSE)
Numerical Porous Media Center (NumPor)
King Abdul
0x030400a1 && !defined(Py_TPFLAGS_HAVE_FINALIZE)
+#if !defined(Py_TPFLAGS_HAVE_FINALIZE)
#define Py_TPFLAGS_HAVE_FINALIZE 0
#endif
--
Lisandro Dalcin
Research Scientist
Computer, Electrical and Mathematical Sciences & Engineering (CEMSE)
Numerical Porous Media Center
On 14 August 2014 08:20, Andriy Kornatskyy wrote:
> When installing either from pip3 or downloading the source with python3
> setup.py install
Could you please show us the full output of "python3 setup.py build" ?
--
Lisandro Dalcin
Research Scientist
Computer
#if defined(MS_WIN32) && !defined(MS_WIN64)
Some modules are disabled on Itanium processors, therefore we
have MS_WINI64 set for those targets, otherwise MS_WINX64
*/
#ifdef _WIN64
#define MS_WIN64
#endif
--
Lisandro Dalcin
---
CIMEC (UNL/CONICET)
Predio CONICET-San
./a.out[0x40080c]
[kw2060:20304] [ 5] /lib64/libc.so.6(__libc_start_main+0xf5)[0x327bc21d65]
[kw2060:20304] [ 6] ./a.out[0x4006f9]
[kw2060:20304] *** End of error message ***
Segmentation fault (core dumped)
--
Lisandro Dalcin
---
CIMEC (UNL/CONICET)
Predio CONICET-Santa Fe
Colect
I'm very sorry for this bogus email, please ignore.
On 21 April 2014 14:53, Lisandro Dalcin wrote:
> I believe the problem is in the following source code line
> (file:ompi_datatype_args.c, line:221):
>
> https://bitbucket.org/ompiteam/ompi-svn-mirror/src/v1.8/ompi/datatype/omp
On 1 November 2013 23:47, Lisandro Dalcin wrote:
> On 1 November 2013 21:53, Stefan Behnel wrote:
>>
>> Erm - interesting. I looked through the code lines above and couldn't find
>> anything that looked suspicious. I hope I used the same source version as
>> you d
t; saw looked rather reasonable...
>
Oh! Sorry, I've used branch 0.19.x, I'll check master and report back
my findings.
--
Lisandro Dalcin
---
CIMEC (UNL/CONICET)
Predio CONICET-Santa Fe
Colectora RN 168 Km 472, Paraje El Pozo
3000 Santa Fe, Argentina
Tel: +54-342-45
On 1 November 2013 15:55, Lisandro Dalcin wrote:
> On 31 October 2013 20:25, Stefan Behnel wrote:
>> Hi,
>>
>> I just came across this paper:
>>
>> http://pdos.csail.mit.edu/~xi/papers/stack-sosp13.pdf
>>
>> They describe an analysis tool that che
inl staff 420289 Oct 15 23:39 Cython/Compiler/ExprNodes.py
-rwxr-xr-x 1 dalcinl staff 137439 Oct 15 23:39 Cython/Compiler/PyrexTypes.py
--
Lisandro Dalcin
---
CIMEC (UNL/CONICET)
Predio CONICET-Santa Fe
Colectora RN 168 Km 472, Paraje El Pozo
3000 Santa Fe, Argentina
Tel: +54-3
o see if it finds something.
>
I tested with mpi4py and got 0 warnings. I'll run it on Cython's testsuite.
--
Lisandro Dalcin
---
CIMEC (UNL/CONICET)
Predio CONICET-Santa Fe
Colectora RN 168 Km 472, Paraje El Pozo
3000 San
I cannot find the tag 0.19.1 in the repository? Did you forget to push it?
--
Lisandro Dalcin
---
CIMEC (INTEC/CONICET-UNL)
Predio CONICET-Santa Fe
Colectora RN 168 Km 472, Paraje El Pozo
3000 Santa Fe, Argentina
Tel: +54-342-4511594 (ext 1011)
Tel/Fax: +54-342-4511169
x
echo 'cdef char buf[SIZE]' >> code1.pyx
$CYTHON code1.pyx
echo 'cimport defs' > code2.pyx
echo 'cdef char buf[defs.SIZE]' >> code2.pyx
$CYTHON code2.pyx
--
Lisandro Dalcin
---
CIMEC (INTEC/CONICET-UNL)
Predio CONICET-Santa F
--- a/tests/run/tp_new_cimport.srctree
+++ b/tests/run/tp_new_cimport.srctree
@@ -42,7 +42,7 @@ def test_sub():
a.pxd
-cdef class ExtTypeA:
+cdef api class ExtTypeA[type ExtTypeA_Type, object ExtTypeAObject]:
cdef readonly attrA
a.pyx
--
Lisandro
On 6 November 2012 16:22, Stefan Behnel wrote:
> Lisandro Dalcin, 02.10.2012 17:06:
>> After successfully porting mpi4py to PyPy 1.9, I want to share a few
>> issues I've encountered. The most serious onesare on PyPy's side, but
>> Cython do require a cuple of
ar feature for
> Cython's array and memory view types (no idea if hashability has been
> considered there yet).
>
readonly != immutable -> unhashable
--
Lisandro Dalcin
---
CIMEC (INTEC/CONICET-UNL)
Predio CONICET-Santa Fe
Colectora RN 168 Km 472, Paraje El Pozo
300
On 4 August 2012 17:50, Stefan Behnel wrote:
> Stefan Behnel, 04.08.2012 14:59:
>> Lisandro Dalcin, 03.08.2012 18:51:
>>> diff --git a/Cython/Compiler/ModuleNode.py b/Cython/Compiler/ModuleNode.py
>>> index 2472de3..255b047 100644
>>> --- a/Cython/Compiler/Mod
ly with module cleanup nullyfing these pointers.
+# Use instead the base type pointer from the
+# instance's type pointer.
+tp_dealloc = "Py_TYPE(o)->tp_base->tp_dealloc"
code.putln(
"%s(o);" %
"%s(o);" % tp_dealloc)
else:
--
Lisandro Dalcin
---
CIMEC (INTEC/CONICET-UNL)
Predio CONICET-Santa Fe
Colectora RN 168 Km 472, Paraje El Pozo
3000 Santa Fe, Argentina
Tel: +54-342-4511594 (ext 1011)
Tel/Fax: +54-342-4511169
__
install.rst in numpy-dev:
Disabling ATLAS and other accelerated libraries
---
Usage of ATLAS and other accelerated libraries in Numpy can be disabled
via::
BLAS=None LAPACK=None ATLAS=None python setup.py build
--
Lisandro Dalcin
--
ng the CPython interpreter (on first pass at least...)).
>
Are you all aware that "calling C" actually means a ctypes-like
functionality based in dlopen()/dlsym() ?
http://julialang.org/manual/calling-c-and-fortran-code/.
--
Lisandro Dalcin
---
CIMEC (INTEC/CONICET-UNL)
Predi
On 10 April 2012 22:53, Dag Sverre Seljebotn wrote:
> On 04/10/2012 09:52 PM, Dag Sverre Seljebotn wrote:
>>
>> On 04/10/2012 08:32 PM, Lisandro Dalcin wrote:
>>>
>>> Is there any way to disable special-casing of numpy arrays? IMHO, if
>>> I'm not u
(ai.shape, aj.shape, av.shape))
^
PETSc/petscmat.pxi:683:11: Cannot convert 'npy_intp *' to Python object
--
Lisandro Dalcin
---
CIMEC (INTEC/CONICET-UNL)
Predio CONICET-Santa Fe
Colectora RN 168 Km 472, Paraje El Pozo
3000 Santa Fe, Argentina
Tel: +54-342-451
hack to silent
"defined but not used" warnings about the import array/umath functions
defined in NumPy headers.
I think you can safely remove that file, it serves no useful purpose IMHO...
--
Lisandro Dalcin
---
CIMEC (INTEC/CONI
ute of
> always instantiating them, like CPython does.
+1
--
Lisandro Dalcin
---
CIMEC (INTEC/CONICET-UNL)
Predio CONICET-Santa Fe
Colectora RN 168 Km 472, Paraje El Pozo
3000 Santa Fe, Argentina
Tel: +54-342-4511594 (ext 1011)
Tel/Fa
On 14 March 2012 08:58, mark florisson wrote:
> On 9 March 2012 14:22, Lisandro Dalcin wrote:
>
> Could you give this fix a try?
> https://github.com/markflorisson88/cython/commit/2bffde15edc66c7416716051959e3b0cf1d6b41b
>
I'm still getting the linking error. Your fix does n
On 11 March 2012 09:46, mark florisson wrote:
> On 10 March 2012 14:00, Stefan Behnel wrote:
>> Lisandro Dalcin, 10.03.2012 10:51:
>>> On 10 March 2012 03:41, mark florisson wrote:
>>>> On 9 March 2012 14:22, Lisandro Dalcin wrote:
>>>>> I'm
On 10 March 2012 03:41, mark florisson wrote:
> On 9 March 2012 14:22, Lisandro Dalcin wrote:
>> I'm basically experiencing the issues here:
>> http://www.cocoabuilder.com/archive/xcode/310299-error-calling-builtin-expect-inside-omp-parallel-for.html
>>
>> Can y
is a Makefile issue.
--
Lisandro Dalcin
---
CIMEC (INTEC/CONICET-UNL)
Predio CONICET-Santa Fe
Colectora RN 168 Km 472, Paraje El Pozo
3000 Santa Fe, Argentina
Tel: +54-342-4511594 (ext 1011)
Tel/Fax: +54-342-4511169
___
cython-devel mailing
On 9 March 2012 16:22, Lisandro Dalcin wrote:
>
> PS: This is the only serious failure I get on OS X Lion. The embed
> test is not working, but it is a Makefile issue.
>
UPDATE: The embed test do work with system Python 2.7. The failure is
with EPD Python 7.2, it is caused by a bad d
track-origins=yes to see where uninitialised values come from
==6735== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2)
--
Lisandro Dalcin
---
CIMEC (INTEC/CONICET-UNL)
Predio CONICET-Santa Fe
Colectora RN 168 Km 472, Paraje El Pozo
3000 Santa Fe, Argentina
Tel: +54-342-4
On 24 February 2012 08:00, Stefan Behnel wrote:
> Lisandro Dalcin, 23.02.2012 22:00:
>> The commit below from Stefan broke C-API generation for extension
>> modules. The problem is that the code of __Pyx_ImportModule() and
>> __Pyx_ImportType() depeds
ns by using macro for
Py2/3 dependent PyString/PyUnicode_FromString() calls
--
Lisandro Dalcin
---
CIMEC (INTEC/CONICET-UNL)
Predio CONICET-Santa Fe
Colectora RN 168 Km 472, Paraje El Pozo
3000 Santa Fe, Argentina
Tel: +54-342-4511594 (ext 1011)
Tel/Fax: +54-342-45
On 31 January 2012 11:29, mark florisson wrote:
> On 30 January 2012 21:03, Lisandro Dalcin wrote:
>>
>> I think there is nothing Cython can do about this (other than
>> special-casing NumPy to disable this VERY useful warning).
>
> Weird, shouldn't you be getti
lude/numpy/ndarraytypes.h
@@ -695,6 +695,7 @@ typedef struct tagPyArrayObject_fields {
#ifdef NPY_NO_DEPRECATED_API
typedef struct tagPyArrayObject {
PyObject_HEAD
+char _npy_array_fields[sizeof(PyArrayObject_fields)-sizeof(PyObject)];
} PyArrayObject;
#else
/*
--
Lisandro Dalcin
---
On 2 January 2012 23:00, Robert Bradshaw wrote:
> On Mon, Jan 2, 2012 at 5:48 PM, Lisandro Dalcin wrote:
>> On 2 January 2012 22:37, Mansour Moufid wrote:
>>> Now my issue is as follows.
>>>
>>> (I CCed the cython-users list if this question is more appropr
on promotes them to
"int". Once again, Cython should have something like a "const" type
qualifier to poperly declare these compile-time constants.
As workaround, you could explicitly cast the constants like this
"print long(UINT8_MAX)"
--
Lisandro Dalcin
On 30 November 2011 04:15, Robert Bradshaw wrote:
>
> There should probably be at least a mode to give warnings for untyped
> arguments (and return types) of cdef functions.
>
Definitely +1.
--
Lisandro Dalcin
---
CIMEC (INTEC/CONICET-UNL)
Predio CONICET-Santa Fe
Cole
as that NumPy enum do is
declared in NumPy headers.
>
> But that doesn't work either. Any suggestions would be appreciated.
>
Try "ctypedef enum ..."
--
Lisandro Dalcin
---
CIMEC (INTEC/CONICET-UNL)
Predio CONICET-Santa Fe
Colectora RN 168 Km 472, Paraje
On 13 September 2011 01:09, Robert Bradshaw
wrote:
> On Mon, Sep 12, 2011 at 7:19 PM, Lisandro Dalcin wrote:
>> On 9 September 2011 05:26, Robert Bradshaw
>> wrote:
>>> Does it work with icc if you replace
>>>
>>> # define CYTHON_UNUSED
fer *__pyx_v_info, int __pyx_v_flags); /*proto*/
>> ^
>> Error: expected a type specifier.
>>
>> The problem is the definition of CYTHON_UNUSED.
>>
>> Please consider the attached patch. It works for me but maybe the problem is
>> icl version specific, not
with gil
cdef int foo() with gil except 0
cdef int bar() nogil except 0
cdef int bar() except 0 nogil
should be all valid.
--
Lisandro Dalcin
---
CIMEC (INTEC/CONICET-UNL)
Predio CONICET-Santa Fe
Colectora RN 168 Km 472, Paraje El Pozo
3000 Santa Fe, Argentina
Tel: +54-342-451159
mented. So, I
> decide to make a step further and try to hop into development.
>
That comment is outdated. Cython do support complex numbers in many
different flavors (native C99 complex, C++ std::complex, raw C structs
for pre-C99 compilers)
--
Lisandro Dalcin
---
CIMEC (INTE
omfortable with (keeping in mind that a lot of "big-lab environments"
> do not give you admin access). Centos 5.x end of life is in 2014.
>
I'm with David here.
I do not object dropping support for 2.3, but would like 2.4 to be supported.
--
Lisandro Dalcin
---
__pyx_why = 0; goto __pyx_L10;
>
> ___
> cython-devel mailing list
> cython-devel@python.org
> http://mail.python.org/mailman/listinfo/cython-devel
>
>
Your patch is OK. However now I'm wondering why not to initialize the
exc
trying to import the
>> objects. I suppose if cimport does not inject anything into the python
>> namespace, then "cimport" could just work and "import" would work iff
>> the module is available at runtime.
>
> +1
>
+1, too... That was my whole point!
On 20 July 2011 16:27, mark florisson wrote:
> On 20 July 2011 21:13, Lisandro Dalcin wrote:
>> On 20 July 2011 15:32, mark florisson wrote:
>>> On 20 July 2011 20:04, Lisandro Dalcin wrote:
>>>> On 20 July 2011 13:51, mark florisson wrote:
>>>>>
On 20 July 2011 15:32, mark florisson wrote:
> On 20 July 2011 20:04, Lisandro Dalcin wrote:
>> On 20 July 2011 13:51, mark florisson wrote:
>>> On 20 July 2011 18:06, Lisandro Dalcin wrote:
>>>> On 19 July 2011 20:48, Robert Bradshaw
>>>> wr
On 20 July 2011 13:51, mark florisson wrote:
> On 20 July 2011 18:06, Lisandro Dalcin wrote:
>> On 19 July 2011 20:48, Robert Bradshaw wrote:
>>> On Tue, Jul 19, 2011 at 3:02 PM, Lisandro Dalcin wrote:
>>>> On 19 July 2011 02:24, Vitja Makarov wrote:
&
On 19 July 2011 20:48, Robert Bradshaw wrote:
> On Tue, Jul 19, 2011 at 3:02 PM, Lisandro Dalcin wrote:
>> On 19 July 2011 02:24, Vitja Makarov wrote:
>>> 2011/7/18 Robert Bradshaw :
>>>> Trevor King and I discussed this quite a while back, but every time I
>
EV_WRITE
>
And what about this?
cdef extern from "ev.h":
cpdef enum:
EV_READ
EV_WRITE
BTW, how is this supposed to work with *.pxd files? I think the values
will be exposed just in the matching implementation .pyx file, and not
with cimport, right?
--
Li
sing "public" will
trigger the generation of a header file.
Perhaps we should support "cpdef enum: ..."
--
Lisandro Dalcin
---
CIMEC (INTEC/CONICET-UNL)
Predio CONICET-Santa Fe
Colectora RN 168 Km 472, Paraje El Pozo
3000 Santa Fe, Argentina
Tel: +54-342-4511594 (ext
rowse/setup.py?name=scikits.sparse-0.1
>
> Anyone have any ideas?
>
Your setup.py is mixing setuptools and Cython.Distutils. Both are
monkeypatching distutils, and in general that's a very bad idea.
--
Lisandro Dalcin
---
CIMEC (INTEC/CONICET-UNL)
Predio CONICET-Santa F
ix. Moreover, I think using
@classmethod is better than @staticmethod. @classmethod gives you some
extra context (the class) that could be useful in the case of
inheritance, specially if your method is a factory function.
So, as a workaround, try to use @classmethod, from an API point of
view they are
>>> Traceback (most recent call last):
>>> File "runtests.py", line 569, in run
>>> self.runCompileTest()
>>> File "runtests.py", line 400, in runCompileTest
>>> sel
r impression that the culprit was this commit:
>
> Commit SHA1: dd3da6c283a0750c9c6514991be719ac064e79b4
> Commit message: PEP 3118: fix for NULL Py_buffer arg
> Committer: Lisandro Dalcin 2011-04-08 00:25:45
>
This commit should be easy to cherry-pick and backport to latest
release.
ssions. But I'm using the
bleeding edge for every day development work of mpi4py/petsc4py.
>
> Do you have plans to make a new point release which includes this very
> important improvement anytime soon?
>
Not sure, we still have some (performance) regressions to fix, all of
them rel
get_py_string_const(self, encoding, identifier=*, is_str=*)
^
Cython/Compiler/Code.pxd:62:30: Previous declaration is here
Compilation failed
Cython
--
Lisandro Dalcin
---
CIMEC (INTEC
ld do
that with the current implementation).
5 - Faster code?
Comments?
--
Lisandro Dalcin
---
CIMEC (INTEC/CONICET-UNL)
Predio CONICET-Santa Fe
Colectora RN 168 Km 472, Paraje El Pozo
3000 Santa Fe, Argentina
Tel: +54-342-4511594 (ext 1011)
Tel/Fax:
On 29 March 2011 21:26, Lisandro Dalcin wrote:
> Error compiling Cython file:
>
> ...
>
> cdef int PyMPE_Raise(int ierr) except -1 with gil:
> __Pyx_Raise(RuntimeError, "MPE logging error [code: %d]"
In a previous thread, Robert asked about issuing a warning in the case
of unspecified return type for extern C++ functions. I'm definitely +1
for it... Moreover, I would extend it for ANY extern C function. IMHO,
this is a case for "explicit is better than implicit".
--
except -1:
^
/home/dalcinl/Devel/mpi4py-dev/src/MPE/helpers.pxi:22:5: Cannot
profile nogil function.
Do we REALLY want this to be an error? Why not just a warning?
--
Lisandro Dalcin
---
CIMEC (INTEC/CONICET-UNL)
Predio CONICE
; you guys should know that I had a problem with the file but managed to get a
>> fix. If my fix needs to be applied, I'll patch it on Github.
>>
>> This is GNU Emacs 23.2.1 x64 on Fedora 14, btw.
>>
>> Rafe
>>
>
> Emacs23 have native support for pyth
our previous history, I would go for Python semantics...
Perhaps you could add a compiler directive for these rare cases where
you need/want C/C++ semantics?
--
Lisandro Dalcin
---
CIMEC (INTEC/CONICET-UNL)
Predio CONICET-Santa Fe
Colectora RN 168 Km
On 3 March 2011 18:05, Robert Bradshaw wrote:
> On Wed, Mar 2, 2011 at 5:47 PM, Lisandro Dalcin wrote:
>>
>> BTW, do you all agree with this change?
>
> To summarize, the C signature of ipow takes three arguments, but the
> third is often/always garbage, so we shouldn
cute, the matching entries in sys.modules
is already there. The same happens in Python 2 for .so modules, as
Py_InitModule() add the entry in sys.modules early. However, in Python
3 that is not te case (and only for the .so, for .py is the same as in
Py2), the import machinery adds
On 2 March 2011 17:14, Lisandro Dalcin wrote:
> On 2 March 2011 16:18, Vitja Makarov wrote:
>> Hi!
>>
>> I noticed that this error came back again.
>>
>> https://sage.math.washington.edu:8091/hudson/view/cython-devel/job/cython-devel-tests-py26-c/la
om/cython/cython/commit/829d6485b77b5688671959f840712c01e6886556
--
Lisandro Dalcin
---
CIMEC (INTEC/CONICET-UNL)
Predio CONICET-Santa Fe
Colectora RN 168 Km 472, Paraje El Pozo
3000 Santa Fe, Argentina
Tel: +54-342-4511594 (ext 1011)
Tel/Fax: +54-342-4511169
_
On 2 March 2011 13:01, Stefan Behnel wrote:
> Dag Sverre Seljebotn, 02.03.2011 16:37:
>>
>> On 03/02/2011 04:11 PM, Lisandro Dalcin wrote:
>>>
>>> On 2 March 2011 08:35, Stefan Behnel wrote:
>>>>
>>>> Dag Sverre Seljebotn, 02.03.2011
Dynamic
linking details varies wildly across platforms... I'm very much
understand Dag's use case and concerns, and I do think that some
research in all this is worth it.
--
Lisandro Dalcin
---
CIMEC (INTEC/CONICET-UNL)
Predio CONICET-Santa Fe
Colectora RN 168 Km 472, Paraje
1 - 100 of 113 matches
Mail list logo
