27;%s' LIBDIR1='%s' test > make.output" % (sys.executable,
> libdir)) == 0)
> | AssertionError
> `---
>
> what could be done about it or should it be excluded?
>
I've pushed some fixes. Now this testcase should run from ancient
Python 2.3 to head Python 3.2, both
code
def compile_time_value(self, env):
+if sys.version_info[0] >= 3 and self.unicode_value:
+return self.unicode_value
return self.value
--
Lisandro Dalcin
---
CIMEC (INTEC/CONICET-UNL)
Predio CONICET-Santa Fe
Colectora RN 168 Km 472, Paraje El P
On 17 February 2011 11:35, W. Trevor King wrote:
> On Thu, Feb 17, 2011 at 10:53:15AM -0300, Lisandro Dalcin wrote:
>> Cython could certainly support "cpdef struct", it is just a matter to
>> define a proposal and find a contributor to implement it :-)
>
> Is there
line 1248, in __run
compileflags, 1), test.globs)
File "", line 1, in
print(test_packed_align(np.zeros((1,), dtype=np.dtype('b,i',
align=False
File "numpy_test.pyx", line 404, in numpy_test.test_packed_align
(numpy_test.c:6367)
Valu
clear...
>
> yeap
>
And now we should be crystal clear, finally! Could you confirm?
--
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 101
2011/2/18 Yaroslav Halchenko :
>
> On Fri, 18 Feb 2011, Lisandro Dalcin wrote:
>> > awesome! I will test it asap -- just let me know if there would be
>> > another commit for above or I should tune up $HOME ;)
>> https://github.com/cython/cython/commit/475e9a0856
t's what I was thinking.
>>
>>> cpdef readonly struct ...
>>>
>>> I think that's a lot clearer than adding to the double meaning of
>>> "public".
>>> I would also prefer if Python accessible cdef class attributes we
t the same as
builtins.hasattr(), it swallows any exception (do you think this is a
bug in core Python?). I'm inclined to fix the behavior for ALL Python
versions to suppress only AttributeError.
--
Lisandro Dalcin
---
CIMEC (INTEC/CONICET-UNL)
Predio CONICET-Santa Fe
Colector
On 22 February 2011 18:21, Stefan Behnel wrote:
> Lisandro Dalcin, 22.02.2011 21:41:
>>
>> I'm inclined to fix the behavior for ALL Python
>> versions to suppress only AttributeError.
>
> How? Would you implement a hasattr() helper that uses PyObject_GetAttr() an
On 22 February 2011 19:09, Lisandro Dalcin wrote:
> On 22 February 2011 18:21, Stefan Behnel wrote:
>> Lisandro Dalcin, 22.02.2011 21:41:
>>>
>>> I'm inclined to fix the behavior for ALL Python
>>> versions to suppress only AttributeError.
>>
>
Should we try to support Py_LIMITED_API for Py>=3.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-4511594 (ext 1011)
Tel/Fax: +54-342-4511
Bringing up this old post...
On 21 June 2010 15:41, Robert Bradshaw wrote:
> On Jun 17, 2010, at 9:31 AM, Lisandro Dalcin wrote:
>
>> If we special case a __dict__ attribute in extension types, i.e:
>>
>> cdef class Foo:
>> cdef dict __dict__
>>
>>
On 28 February 2011 15:09, Robert Bradshaw wrote:
> On Mon, Feb 28, 2011 at 8:33 AM, Lisandro Dalcin wrote:
>> Bringing up this old post...
>>
>> On 21 June 2010 15:41, Robert Bradshaw wrote:
>>> On Jun 17, 2010, at 9:31 AM, Lisandro Dalcin wrote:
>>
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
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
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 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
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 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
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
; 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
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
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".
--
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]"
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:
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
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
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.
>>> Traceback (most recent call last):
>>> File "runtests.py", line 569, in run
>>> self.runCompileTest()
>>> File "runtests.py", line 400, in runCompileTest
>>> sel
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
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
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
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
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
>
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 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 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:
>>>>>
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!
__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
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
---
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
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
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
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
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 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
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 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
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 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
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 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
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 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
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 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
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 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
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
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
(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
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
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
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
--
"%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
__
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);" %
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
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 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
--- 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
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
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
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
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
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
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 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
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
./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
#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
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
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
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
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
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
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
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
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:
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 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 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 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 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
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
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)
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
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
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
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
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
1 - 100 of 113 matches
Mail list logo
