Is this why I can only make scipy.spatial.cKDTree support pickle on Python
3? Since scipy.spatial.cKDTree comes from a relative import of
.ckdtree.cKDTree into scipy.spatial, it somehow works on Python 3 but fails
on Python 2.
Sturla
Nathaniel Smith wrote:
> On Mar 14, 2015 2:03 PM, "Robert Bra
Zaxebo Yaxebo wrote:
>
> Zaxebo>>
> I am NOT saying to implement datatyping(that is already part of cython by
> "cdef int","cdef double"). I am NOT saying to turn off duck typing.
> What i am requesting is: declaration of variables without data
> typing (like: cdef "var" ). And "opti
Zaxebo Yaxebo wrote:
> NOTE: This feature request is analogous to VisualBasic's "Option Explicit"
> and perl's "use strict"
Originally Fortran's "implicit none".
I am not sure why you use Python (including Cython) if you prefer to turn
off duck typing, though. You know where to find Java or C+
64-bit Python cannot be used to build 32-bit extensions. Yes, you can build
extensions for 32-bit Python on 64-bit Windows, but not with 64-bit Python.
Sturla
Andriy Kornatskyy wrote:
> Here is a link to complete output with python3.4:
>
> https://bitbucket.org/akorn/wheezy.template/issue/10/
On 21/08/14 13:30, Lisandro Dalcin wrote:
Sturla, isn't this supposed to be handled in pyconfig.h (at least when
using MSVC) ? I see these lines in PC/pyconfig.h (from Python
sources):
Yes, it is supposed to, but the error message suggest it was not and the
compile line does not have it.
St
To build a Python extension for Win64 you must define the symbol MS_WIN64,
typically -DMS_WIN64.
Sturla
Andriy Kornatskyy wrote:
> Here is an issue when trying to install wheezy.template (it uses
> cythonize) into environment with cython.
>
> Host: windows 7 64bit Python version: 3.4.1 32 bit
Dave Hirschfeld
wrote:
> Just wanting to clarify that it's only the GNU OpenMP implementation that
> isn't fork-safe? AFAIK the intel OpenMP runtime is and will at some stage be
> available in the master branch of clang.
That is correct.
___
cython-
"Leon Bottou" wrote:
> I am making heavy uses of OpenBlas which also uses OpenMP.
> Using the same queue manager prevents lots of CPU provisioning problem.
> Using multiple queue managers in the same code does not work as well because
> they are not aware of what the other one is doing.
Normally
Brett Calcott
wrote:
> For someone who has bumbled around trying to use prange & openmp on the
> mac
> (but successfully used python threading), this sounds great. Is there an
> example of this somewhere that you can point us to?
No, but I could make one :)
ipython notebook?
Sturla
14 um 04:34:
>> On Sun, Aug 10, 2014 at 12:41 PM, Sturla Molden wrote:
>>> Ian Henriksen wrote:
>>>> Maybe I should clarify a little about why eigen is a good place to start.
>>>> According to >>> href="http://eigen.tuxfamily.org/dox/T
Cython does not do an error here:
- i is recognized as private
- r is recognized as reduction
- w is (correctly) recognized as shared
If you need thread local storage, use threading.local()
I agree that scoped cdefs would be an advantage.
Personally I prefer to avoid OpenMP and just use Python
Ian Henriksen
wrote:
> Maybe I should clarify a little about why eigen is a good place to start.
> According to href="http://eigen.tuxfamily.org/dox/TopicLazyEvaluation.html";>http://eigen.tuxfamily.org/dox/TopicLazyEvaluation.html
> it
> already takes care of things like the elimination of temp
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
generate
Benjamin Lerman wrote:
> Would cython accept to add such a copyright header on its files?
You want to display the Apache licence in every single file, even those
with utility C code?
Can't you do this in your own copy of Cython? I am quite sure the license
allows you to modify the source files
Pauli Virtanen wrote:
> The n**m explosion starts to hurt quite quickly when there are several
> array arguments and more than one fused type. I think this issue is
> also accompanied by some signature resolution bugs (I'll try to come
> up with an example case).
I warned that fused types would
On 26 Nov 2013, at 16:18, Daniele Nicolodi wrote:
> Hello,
>
> I believe there is a bug in how assignment to typed memoryviews is
> handled in the compiler. I think the following code should be valid code:
>
> cdef double[::1] a = np.arange(10, dtype=np.double)
> cdef double[::1] b = np.emp
On Sep 12, 2013, at 6:33 PM, Stefan Behnel wrote:
> Robert Bradshaw, 10.09.2013 02:14:
Wow. The first version of this PR used Cython memoryviews, which added a
whopping 14 kLOC of generated C to the repo. Switched back to bare
pointers to keep the compile times within bounds.
>>
Den 10. sep. 2013 kl. 02:14 skrev Robert Bradshaw :
>>> Wow. The first version of this PR used Cython memoryviews, which added a
>>> whopping 14 kLOC of generated C to the repo. Switched back to bare pointers
>>> to keep the compile times within bounds.
>> It would be interesting to hear the Cyt
Den 22. aug. 2013 kl. 06:01 skrev Robert Bradshaw :
> On Sat, Aug 17, 2013 at 3:31 AM, yi huang wrote:
>> I use cython 0.19.1, when compile following code:
>>
>> cdef void some_function():
>>cdef char buf[sizeof(long)*8/3+6]
>>
>> Got error message:
>>
>> Error compiling Cython file:
>>
Den 3. juni 2013 kl. 14:24 skrev "Yury V. Zaytsev" :
>
> When I cythonize the following code in my bt.pyx file and run the test
> below with Python 2.7.1 and NumPy 1.7.1 everything works fine, but when
> I try Python 2.6.6 and NumPy 1.3.0 I get the following exception:
>
>
> Is there a minimu
On 03.04.2013 12:53, Nikita Nemkin wrote:
offsetof() is not supported by current Cython, and I have not found any
workaround (except hardcoding offsets for a specific architecture and
compiler, but this is obviously wrong).
offsetof() would certainly be very useful, but in the meantime
offseto
Den 20. feb. 2013 kl. 11:55 skrev Sturla Molden :
>
> Den 18. feb. 2013 kl. 19:32 skrev Sturla Molden :
>
>> The problem this addresses is when GCC does not use atomic builtins and
>> emits __synch_fetch_and_add_4 and __synch_fetch_and_sub_4 when Cython are
>
On 28.02.2013 15:55, Dave Hirschfeld wrote:
So the issue is that at present memoryviews can't be readonly?
https://github.com/cython/cython/blob/master/Cython/Compiler/MemoryView.py#L33
Typed memoryviews are thus acquired with the PyBUF_WRITEABLE flag. If
the the assigned buffer is readonly,
On 28.02.2013 15:46, Yury V. Zaytsev wrote:
My method call is actually wrapped in a try { ... } catch clause,
because I declared it as being able to throw exceptions, so the
reference can't be defined in this block, or it will not be accessible
to the outside world.
If Cython generates illegal
On 28.02.2013 13:58, Yury V. Zaytsev wrote:
Hi,
I'm sorry if my question would appear to be trivial, but what am I
supposed to do, if I want to wrap class methods, that return a reference
to another class?
From reading the list, I've gathered that apparently the best strategy
of dealing with r
On 27.02.2013 20:05, Dave Hirschfeld wrote:
Is this a required restriction? Is there any workaround?
http://www.python.org/dev/peps/pep-3118/
What you should consider is the "readonly" field in "struct bufferinfo"
or the access flag "PyBUF_WRITEABLE".
In short:
A PEP3118 buffer can be r
Den 18. feb. 2013 kl. 19:32 skrev Sturla Molden :
> The problem this addresses is when GCC does not use atomic builtins and emits
> __synch_fetch_and_add_4 and __synch_fetch_and_sub_4 when Cython are
> internally refcounting memoryview buffers. For some reason it can even happen
>
As Stefan suggested, I have posted a PR for a better fix for the issue
when MinGW for some reason emits the symbol "__synch_fetch_and_add_4"
instead of generating atomic opcode for the __synch_fetch_and_add builtin.
The PR is here:
https://github.com/cython/cython/pull/185
The discussion proba
On 02.02.2013 01:23, Greg Ewing wrote:
If you're suggesting that 'def object foo' should give Python
reference semantics and 'cdef object foo' raw C pointer
semantics,
No I was not.
I was suggesting that static declarations of Python and C variables
should have different keywords.
Because
On 01.02.2013 01:11, Greg Ewing wrote:
Without the cdef, these variables would be stored wherever Python
normally stores variables for the relevant scope, which could be
in a module or instance dict, and the usual Python/C API machinery
is used to access them.
Distinguishing between Python an
On 29.01.2013 22:15, Sal wrote:
I don't have any 'typical' Python code yet, everything is 'cdef' type
stuff, but reference counting is still performed by Cython on 'cdef'
types, so sticking them into a C++ array probably ignores that fact.
I think the main difficulty with Cython (for beginners
es, the code is different on Unix and Windows, something the
auto-pickler could not possibly know either.
Auto-pickling cdef classes is not doable, IMHO.
And by the way, implementing a __reduce__ method manually is not very
difficult either.
Sturla Molden
___
While I have not tried this yet, array expressions in Cython might be
the final nails in the coffin for Fortran 90 as far as I am concerned.
Great work!
:-)
Sturla
On 24.08.2012 20:40, mark florisson wrote:
Hey,
Here a pull request for element-wise array expressions for Cython:
https://git
Sendt fra min iPad
Den 4. juli 2012 kl. 14:33 skrev Stefan Behnel :
>>
>> Indeed. But how to tell? malloc a small buffer and see if it works?
>
> In the worst case, you'd get another memory error during cleanup and it
> would keep rippling up the stack.
>
>
Which is why I wrote 'malloc' in
Den 4. juli 2012 kl. 08:06 skrev Stefan Behnel :
>
>
> Also, the allocation may have failed on a larger block of memory, which is
> then unused when the exception gets raised and can be used by cleanup code.
> I really don't think the world is all that dark here.
>
>
Indeed. But how to tel
Den 03.07.2012 20:43, skrev Dag Sverre Seljebotn:
Except for the fact that any code touching "new" could be raising
exceptions? That propagates.
There is a lot of C++ code out there using exceptions. I'd guess that
both mathematical code and Google-written code is unlike most C++ code
out t
On 02.07.2012 14:49, Sturla Molden wrote:
I think (in C++11) std::unordered_set and std::unordered_map should be
used instead. They are hash-based with O(1) lookup.
std::set and std::map are binary search threes with average O(log n)
lookup and worst-case O(n**2).
Sorry typo, that should be
unordered_set and std::unordered_map should be
used instead. They are hash-based with O(1) lookup.
std::set and std::map are binary search threes with average O(log n)
lookup and worst-case O(n**2).
Also beware that C++11 has a std:tuple type.
Sturla Molden
_
On 18.06.2012 16:12, Stefan Behnel wrote:
the PyPy folks have come up with a new FFI library (called cffi) for
CPython (and eventually PyPy, obviously).
It looks like ctypes albeit with a smaller API. (C definitions as text
strings instead of Python objects.)
Sometimes I think Python and a
On 12.06.2012 21:46, Dag Sverre Seljebotn wrote:
But for much NumPy-using code you'd typically use int32 or int64, and
since long is 32 bits on 32-bit Windows and 64 bits on Linux/Mac,
choosing long sort of maximises inter-platform variation of signatures...
The size of a long is compiler depe
On 01.03.2012 19:33, Dag Sverre Seljebotn wrote:
Yeah, I proposed this on another thread as one of the options, but the
support wasn't overwhelming at the time...
I think it is worse to break parts of it, thus introducing bugs that
might go silent for a long time.
Rather deprecate the whole
On 01.03.2012 17:18, Dag Sverre Seljebotn wrote:
I'm anyway leaning towards deprecating arr.data, as it's too different
from what the Python attribute does.
This should be preferred, I think
&arr[0]
or
&arr[0]
The latter is exacty what arr.data will currently do in Cython (but not
On 01.03.2012 17:18, Dag Sverre Seljebotn wrote:
are saying we (somehow) stick with supporting "arr.shape[0]" in
the future, and perhaps even support "print arr.shape"? (+ arr.dim,
arr.strides).
What if you just deprecate ndarray support completely, and just focus on
memory views?
Yes, you
On 07.02.2012 18:22, Dimitri Tcaciuc wrote:
I'm not sure I understand you, maybe you could elaborate on that?
OpenCL code is a text string that is compiled when the program runs. So
it can be generated from run-time data. Think of it like dynamic HTML.
Again, not sure what you mean here. A
On 05.02.2012 23:39, Dimitri Tcaciuc wrote:
3. Does it make sense to make OpenCL more explicit?
No, it takes the usefuness of OpenCL away, which is that kernels are
text strings and compiled at run-time.
Heuristics and
automatic switching between, say, CPU and GPU is great for eg. Sage
use
Den 12.12.2011 21:09, skrev Wes McKinney:
I'm interested in using the Cython OpenMP extensions in pandas for
various calculations, but I'm concerned about cross-platform issues,
especially distributing built binaries of the extensions to Windows
users. Is there a clean way to bundle the relevant
Den 03.05.2011 16:06, skrev Dag Sverre Seljebotn:
Well, if you do something like
ctypedef fused_type(float, double) speed_t
ctypedef fused_type(float, double) acceleration_t
cdef func(speed_t x, acceleration_t y)
then you get 4 specializations. Each new typedef gives a new
polymorphic type.
Den 02.05.2011 11:15, skrev Dag Sverre Seljebotn:
I.e., your question is very vague.
Ok, what I wanted to ask was "why have one syntax for interfacing C++
templates and another for generics?" It seems like syntax bloat to me.
You're welcome to draft your own proposal for full-blown templat
Den 01.05.2011 16:36, skrev Stefan Behnel:
Not everyone uses C++. And the C++ compiler cannot adapt the code to
specific Python object types.
Ok, that makes sence.
Second question: Why not stay with the current square-bracket syntax?
Does Cython
need a fused-type in addition?
I'd also thi
Den 01.05.2011 02:24, skrev Greg Ewing:
Stefan Behnel wrote:
Meaning, we'd find a new type during type analysis or inference,
split off a new version of the function and then analyse it.
I'm not sure that this degree of smartness would really
be a good idea. I'd worry that if I made a type err
Den 22.04.2011 23:22, skrev josef.p...@gmail.com:
after a facelift
http://www.mathworks.com/matlabcentral/fileexchange/?sort=date_desc_updated&term=
Josef
This is indeed something I miss for scientific Python as well.
I also miss a similar file exchange for Cython (not limited to
scientif
Den 19.04.2011 07:08, skrev Stefan Behnel:
Yes, that's what this is all about.
https://github.com/markflorisson88/cython/commits/master
Great :)
Sturla
___
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cy
Den 18.04.2011 22:26, skrev Robert Bradshaw:
On Mon, Apr 18, 2011 at 12:08 PM, mark florisson
wrote:
Can I add a gilnanny to refnanny? I want to do a PyThreadState_Get()
for every refnanny inc- and decref, so that it will issue a fatal
error whenever reference counting is done without the gil,
Den 17.04.2011 21:16, skrev Stefan Behnel:
However, the different number of functions calls also makes the
profiling results less comparable, since there are fewer calls into
the profiler. This leads to a lower performance penalty for Cython in
the absolute timings, and consequently to an unf
Den 17.04.2011 20:07, skrev Arthur de Souza Ribeiro:
I've profilled the module I created and the module that is in Python
3.2, the result is that the cython module spent about 73% less time
then python's one, the output to the module was like this (blue for
cython, red for python):
The n
Den 12.04.2011 14:59, skrev Arthur de Souza Ribeiro:
1 - Compile package modules - json module is inside a package (files:
__init__.py, decoder.py, encoder.py, decoder.py) is there a way to
generate the cython modules just like its get generated by cython?
I'll propose these 10 guidelines
Den 04.04.2011 15:04, skrev Stefan Behnel:
What I would like to avoid is having to tell users "and now for
something completely different". It looks like a loop, but then
there's a whole page of new semantics for it. And this also cannot be
used in plain Python code due to the differing scopi
Den 04.04.2011 01:49, skrev Sturla Molden:
Also observe that we do not release the GIL here. That is not because
these functions are not thread-safe, they are, but yielding the GIL
will slow things terribly.
Oh, actually they are not thread-safe because we set errno... Sorry.
Sturla
Den 03.04.2011 04:17, skrev Arthur de Souza Ribeiro:
static PyMethodDef cmath_methods[] = {
{"acos", cmath_acos, METH_VARARGS, c_acos_doc},
{"acosh", cmath_acosh, METH_VARARGS, c_acosh_doc},
{"asin", cmath_asin, METH_VARARGS, c_asin_doc},
{"asinh", cmath_asinh, METH_VARAR
Den 29.03.2011 02:09, skrev Robert Bradshaw:
We are very concerned about Python compatibility.
I did not intend to say you are not.
Judging from Guido's answer to Stephan, I think Guido is worried you are
not.
And that, BTW, is sufficient to prevent the use of Cython in CPython stdlib.
Stu
Den 25.03.2011 19:03, skrev Robert Bradshaw:
Looking at Guido's comment, Cython must be able to compile all valid
Python if this will have any chance of success.
Good thing that's our goal (pending an actual definition of "all valid Python.")
In lack of a Python language specification it ca
Den 24.03.2011 20:38, skrev Robert Bradshaw:
I started a list at http://wiki.cython.org/Unsupported . I'd say we
can be as compatible as Jython/IronPython is, and more than CPython is
between minor versions. I would be happy with a short, well-justified
list of differences. This will be clearer o
The free C/C++ compiler in Windows SDK supports OpenMP. This is the
system C compiler on Windows.
Visual C++ Express is an IDE for beginners and hobbyists.
OpenMP on GCC is the same on Windows as on any other platform.
Sturla
A Friday 11 March 2011 11:42:26 Matej Laitl escrigué:
I'm stro
Den 11.03.2011 12:43, skrev Stefan Behnel:
What's your use actual case for this?
Just avoid different syntax inside and outside nogil-blocks. I like this
style
with openmp.critical:
better than what is currently legal with nogil:
openmp.critical()
if 1:
openmp.end_criti
Den 11.03.2011 11:42, skrev Matej Laitl:
#pragma omp parallel for private(var1) reduction(+:var2) schedule(guided)
for i in range(n):
do_work(i)
I do like this, as it is valid Python and can be turned on/off with a
compiler flag to Cython.
Issues to warn about:
- We cannot jump out of
Den 11.03.2011 01:46, skrev Robert Bradshaw:
On a slightly higher level, are we just trying to use OpenMP from
Cython, or are we trying to build it into the language?
OpenMP is a specification, not a particular implementation.
Implementation for Cython should either be compiler pragmas or a li
Den 08.03.2011 20:34, skrev Stefan Behnel:
... but that could be put into a builtin Cython library, right? At
least a couple of primitives, decorators, helpers, etc.
Yes.
Sturla
___
cython-devel mailing list
cython-devel@python.org
http://mail.pyth
Den 08.03.2011 20:13, skrev Francesc Alted:
And another problem that should be taken in account is that MS Visual
Studio does not offer OpenMP in the Express edition (the free, as in
beer, one).
Which is why one should get the Windows 7 SDK instead :-)
As I see this, if we could stick using j
Den 08.03.2011 18:50, skrev Stefan Behnel:
Note that the queue is only needed to tell the thread what to work on.
A lot of things can be shared over the closure. So the queue may not
even be required in many cases.
Instead of putting a "#pragma omp parallel for" over the for loop, we
put the
Den 08.03.2011 18:00, skrev mark florisson:
Sure, that's not what I was hinting at. What I meant was that the
wrapper returned by the decorator would have to call the closure for
every iteration, which introduces function call overhead.
OpenMP does this too, in addition to work-scheduling overh
Den 08.03.2011 17:33, skrev mark florisson:
With OpenMP code, exactly how common are exceptions and error handling?
Error handling is always needed, but OpenMP does not help with this.
One can use an integer variable as error flag, and use an atomic write
in case of error.
Sturla
__
Den 08.03.2011 17:04, skrev Stefan Behnel:
Could you elaborate what you are referring to here?
Nothing, except my own ignorance :-)
As for OpenMP I'd like to add that closures in Cython/Python more
cleanly map to Apple's "grand central dispatch" than OpenMP.
Yet a third way to easy parallel
Den 08.03.2011 17:10, skrev mark florisson:
But how useful is it to parallelize CPU-bound code while holding GIL?
Or do you mean to run the CPU-intensive section in a 'with nogil'
block and when you need to do locking, or when you need to deal with
Python objects you reaqcuire the GIL?
The Python
Den 08.03.2011 11:34, skrev mark florisson:
However, considering that OpenMP has quite a few constructs,
No, OpenMP has very few contructs, not quite a few. And most of them are
not needed, nor wanted, because the functionality is covered by the
Python language (such as scoping rules).
I.e.
Reposting this, seems it got lost in cyber space.
Sturla
Den 8. mars 2011 kl. 16.10 skrev Sturla Molden :
Den 08.03.2011 11:34, skrev mark florisson:
However, considering that OpenMP has quite a few constructs,
No, OpenMP has very few contructs, not quite a few. And most of them
are
Den 08.03.2011 11:34, skrev mark florisson:
What do you guys think?
Make Cython fully support closures, then we can easily implement our own
"OpenMP" using Python threads. No change to the compiler is needed. You
might not realise this at first, but OpenMP is just a way of
implementing closu
Den 08.03.2011 11:34, skrev mark florisson:
What do you guys think?
Make Cython fully support closures, then we can easily implement our own
"OpenMP" using Python threads. No change to the compiler is needed. You
might not realise this at first, but OpenMP is just a way of
implementing closu
Den 08.03.2011 11:34, skrev mark florisson:
could be written
for i in openmp.prange(..., firstprivate=('a', 'b'), reduction='+:result'):
...
How would you deal with name mangling, aliases, unboxing of numpy
arrays, etc.?
Sturla
___
78 matches
Mail list logo
