On 05/26/2011 10:43 AM, Stefan Behnel wrote:
Dag Sverre Seljebotn, 26.05.2011 10:24:
On 05/26/2011 10:12 AM, Stefan Behnel wrote:
Robert Bradshaw, 26.05.2011 09:40:
the pattern of swapping out builtin methods (and perhaps
functions) with more optimized C versions is something that perhaps it
On 05/27/2011 02:41 PM, Vitja Makarov wrote:
2011/5/27 Stefan Behnel:
Hi,
could we please make it a requirement to run the complete test suite after a
branch merge? Or at least taking a close look at Jenkins after pushing a
merge? And then fixing the bugs it finds?
Stefan
There are failing
On 05/27/2011 03:54 PM, Stefan Behnel wrote:
[regarding the code for analysing uninitialised variables in the OpenMP
branch]
dagss, 27.05.2011 10:32:
I suggest this:
a) Vitja and Stefan notifies Mark of any issues that stops control flow
analysis from going into trunk (outright collisions etc.
On 05/27/2011 04:27 PM, Vitja Makarov wrote:
I've recently fixed some issues:
- closure variables were not tracked
- scoped expression variables were initialized to None
So, I should fix broken tests, here are some of them:
nogil (should be fixed)
purecdef (upstream)
cfunc_directive_in_pyc
On 05/31/2011 01:07 PM, Vitja Makarov wrote:
2011/5/24 Stefan Behnel:
Vitja Makarov, 23.05.2011 21:33:
2011/5/23 Stefan Behnel:
However, once we really know which values change between yield calls,
i.e.
which ones need to be stored away, it will actually be less expensive in
most cases. We c
On 06/02/2011 06:39 PM, Robert Bradshaw wrote:
In looking at merging fused types, it's time to nail down the syntax.
The current implementation is
ctypedef cython.fused_type(list, dict, object) fused_t
This requires an addition to the grammer to allow the "call" syntax in
a type declaratio
On 06/02/2011 11:51 PM, Robert Bradshaw wrote:
On Thu, Jun 2, 2011 at 2:42 PM, mark florisson
wrote:
On 2 June 2011 23:31, Robert Bradshaw wrote:
On Thu, Jun 2, 2011 at 2:18 PM, Dag Sverre Seljebotn
wrote:
On 06/02/2011 06:39 PM, Robert Bradshaw wrote:
In looking at merging fused types
On 07/07/2011 07:52 PM, Pauli Virtanen wrote:
On Thu, 07 Jul 2011 15:28:36 +0200, Stefan Behnel wrote:
there's something broken with the repo recently. Even in a fresh
checkout, I see 25 heads, most of which were supposed to be merges into
the master branch (mainly button merges). The github web
On 07/22/2011 12:12 PM, mark florisson wrote:
For my work on the _memview branch (and also on fused types) I noticed
that UtilityCodes started weighing heavily on me in their current
form, so I wrote a little loader in the _memview branch:
https://github.com/markflorisson88/cython/commit/e13debe
On 07/22/2011 01:10 PM, Stefan Behnel wrote:
mark florisson, 22.07.2011 12:12:
For my work on the _memview branch (and also on fused types) I noticed
that UtilityCodes started weighing heavily on me in their current
form, so I wrote a little loader in the _memview branch:
https://github.com/mar
On 07/22/2011 01:10 PM, Stefan Behnel wrote:
mark florisson, 22.07.2011 12:12:
For my work on the _memview branch (and also on fused types) I noticed
that UtilityCodes started weighing heavily on me in their current
form, so I wrote a little loader in the _memview branch:
https://github.com/mar
On 07/22/2011 03:07 PM, Stefan Behnel wrote:
Stefan Behnel, 22.07.2011 15:04:
Dag Sverre Seljebotn, 22.07.2011 13:54:
On 07/22/2011 01:10 PM, Stefan Behnel wrote:
I'm fine with using a template engine for the more involved cases
(which
are rare enough). However, I'd prefer not ad
On 07/22/2011 05:46 PM, Dag Sverre Seljebotn wrote:
On 07/22/2011 03:07 PM, Stefan Behnel wrote:
Stefan Behnel, 22.07.2011 15:04:
Dag Sverre Seljebotn, 22.07.2011 13:54:
On 07/22/2011 01:10 PM, Stefan Behnel wrote:
I'm fine with using a template engine for the more involved cases
(whic
On 07/22/2011 06:04 PM, Stefan Behnel wrote:
Dag Sverre Seljebotn, 22.07.2011 17:49:
On 07/22/2011 05:46 PM, Dag Sverre Seljebotn wrote:
On 07/22/2011 03:07 PM, Stefan Behnel wrote:
Stefan Behnel, 22.07.2011 15:04:
Dag Sverre Seljebotn, 22.07.2011 13:54:
On 07/22/2011 01:10 PM, Stefan
On 07/22/2011 06:48 PM, Hoyt Koepke wrote:
I know I'm a little late to the discussion, but I've been meaning to
ask about a feature like this myself.
As a point of information, Mako (http://www.makotemplates.org/) might
be a bit heavyweight for embedding in cython (I don't know for sure;
haven't
On 07/27/2011 06:32 PM, Stefan Behnel wrote:
Hi,
quick question before raising a poll on the users mailing list.
Would anyone mind dropping support for CPython 2.3?
1) it's long out of maintenance, even the last security release dates
back to early 2008
2) there have been seven main releases
On 07/27/2011 08:11 PM, Robert Bradshaw wrote:
On Wed, Jul 27, 2011 at 9:51 AM, mark florisson
wrote:
On 27 July 2011 18:46, Vitja Makarov wrote:
2011/7/27 Stefan Behnel:
Hi,
quick question before raising a poll on the users mailing list.
Would anyone mind dropping support for CPython 2.3
The reason you do not get answers is because people do not understand your
question. Please describe in detail what you want to do (on the users list).
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
"최원준" wrote:
because of no answer on the cython users..
anyone knows
Looks very much like a numpy-on-py3 bug to me. (NumPy has an RC up currently as
well, it'd be good to test them together but don't think I have time this
weekend...)
Do you know if the problem is there with Cython 0.14? Even if not, it could
simply be that the test cases now exercise more of Nu
My opinion is that we create a (short-lived) branch for the release, and
continue development (ignoring the release) on master.
If CyFunction solves no problems that blocks a release, I am -1 on merging it
into the release branch. But we shouldn't keep things in pull requests just
because we're
That sounds risky; I think we should consider master as non-rebaseable except
in emergencies. So fixes should be pushed to release and then merged into
master. Of course, for something like this with no development depending on it
one can just delay the merge for a day or two in case more fixes
On 08/02/2011 07:44 AM, Vitja Makarov wrote:
2011/8/2 Robert Bradshaw:
On Mon, Aug 1, 2011 at 3:04 PM, Arfrever Frehtes Taifersar Arahesis
wrote:
2011-07-31 09:45:15 Robert Bradshaw napisał(a):
On Thu, Jul 21, 2011 at 4:14 PM, Robert Bradshaw
wrote:
Cython has seen an enormous amount of d
On 08/03/2011 10:53 PM, Stefano wrote:
Hi everybody,
I've been a enthusiast Python programmer for 3 years now, and I've hailed
Cython project with great interest. Now, I'm willing to contribute. I've would
say I'm an quite an expert Python programmer and I've some-year-long
experience with C, mo
On 08/05/2011 01:31 AM, Robert Bradshaw wrote:
This is getting a bit OT but is worth discussing, so I'm starting a new thread.
On Thu, Aug 4, 2011 at 2:51 PM, Greg Ewing wrote:
Dag Sverre Seljebotn wrote:
- One idea is coercion of C pointers to ctypes Python objects and back
again.
On 08/09/2011 08:33 AM, Stefan Behnel wrote:
Stefano, 08.08.2011 22:36:
As a proof of its quality, Fedora, Ubuntu and SuSe all ship a
python-argparse
package for older versions of python (<2.7). Given that the module is
self-
contained and as small as 80KB, wouldn't be feasible to add it as a bu
On 08/11/2011 04:00 PM, Stefan Behnel wrote:
Actually, it's worth asking if even the prange loop was a good idea,
given the amount of confusion driven traffic that it currently produces
on the mailing list. I'm not arguing against it, but it seems to be a
trickier concept than it appears at first
On 08/11/2011 04:24 PM, Stefano wrote:
Hi,
now that I've nailed Cython code, I'd like to get into something more funny.
Currently, I'm working on a set of macros to seamlessy integrate Cython into
CMake build process (in fact, I love CMake). But, I'd like to work also on
something more essential
On 08/12/2011 02:45 PM, Stefan Behnel wrote:
> [second try in moving this discussion to cython-devel]
>
> Dag Sverre Seljebotn, 12.08.2011 08:50:
>> On 08/12/2011 06:44 AM, Robert Bradshaw wrote:
>>> On Thu, Aug 11, 2011 at 5:53 AM, Dag Sverre Seljebotn
>>> wrote
I read up on Go's interface model last week and am very excited about
it. Perhaps this was old news to a lot of you, but it was new to me.
This post is mostly just to make sure everybody is aware of prior art
here in case it is a good fit for Cython down the road. I hope I'm not
starting a lon
On 08/13/2011 02:28 PM, Stefan Behnel wrote:
Dag Sverre Seljebotn, 13.08.2011 13:09:
I read up on Go's interface model last week and am very excited about it.
Perhaps this was old news to a lot of you, but it was new to me.
This post is mostly just to make sure everybody is aware of prio
On 08/15/2011 11:42 AM, mark florisson wrote:
On 15 August 2011 02:22, Nikolaus Rath wrote:
mark florisson writes:
On 14 August 2011 17:50, Nikolaus Rath wrote:
mark florisson writes:
On 12 August 2011 20:23, Nikolaus Rath wrote:
Hello,
The following segfault is completely incomprehens
On 08/15/2011 12:35 PM, mark florisson wrote:
On Monday, 15 August 2011, Dag Sverre Seljebotn
wrote:
On 08/15/2011 11:42 AM, mark florisson wrote:
On 15 August 2011 02:22, Nikolaus Rathwrote:
mark florissonwrites:
On 14 August 2011 17:50, Nikolaus Rathwrote:
mark florisson
h has a cheap way of
achieving this.
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Stefan Behnel wrote:
Dag Sverre Seljebotn, 15.08.2011 11:54: > On 08/15/2011 11:42 AM, mark
florisson wrote: >> @Cython-dev: Do we merely want to update the docs, or
On 08/17/2011 09:12 AM, Robert Bradshaw wrote:
On Fri, Aug 12, 2011 at 6:13 AM, Dag Sverre Seljebotn
wrote:
On 08/12/2011 02:45 PM, Stefan Behnel wrote:
[second try in moving this discussion to cython-devel]
Dag Sverre Seljebotn, 12.08.2011 08:50:
On 08/12/2011 06:44 AM, Robert Bradshaw
On 08/17/2011 08:19 PM, Robert Bradshaw wrote:
That's a nice idea. I have to admit that all these special gil
declarations are a bit messy. I'd also rather introduce clear
decorators, e.g.
@cython.requires_gil # expects gil
cdef a(): ...
@cython.requires.gil(False) # nogil
cdef b(): ...
@cyth
On 08/17/2011 09:21 PM, Robert Bradshaw wrote:
On Wed, Aug 17, 2011 at 11:46 AM, Dag Sverre Seljebotn
wrote:
On 08/17/2011 08:19 PM, Robert Bradshaw wrote:
That's a nice idea. I have to admit that all these special gil
declarations are a bit messy. I'd also rather introduce clear
On 08/18/2011 08:39 AM, Dag Sverre Seljebotn wrote:
On 08/17/2011 09:21 PM, Robert Bradshaw wrote:
On Wed, Aug 17, 2011 at 11:46 AM, Dag Sverre Seljebotn
wrote:
On 08/17/2011 08:19 PM, Robert Bradshaw wrote:
That's a nice idea. I have to admit that all these special gil
declarations
On 08/18/2011 09:06 AM, Stefan Behnel wrote:
Dag Sverre Seljebotn, 18.08.2011 08:39:
The semantics are simple: For all cdef functions, if "nogil" could have
been applied without a syntax error, then it gets automatically applied.
The only time this isn't completely safe is
On 08/18/2011 09:27 PM, Robert Bradshaw wrote:
On Wed, Aug 17, 2011 at 11:39 PM, Dag Sverre Seljebotn
wrote:
On 08/17/2011 09:21 PM, Robert Bradshaw wrote:
On Wed, Aug 17, 2011 at 11:46 AM, Dag Sverre Seljebotn
wrote:
On 08/17/2011 08:19 PM, Robert Bradshaw wrote:
That's a nice
NumPy does not have a double** anywhere, what you did is the correct solution
(as long as you make sure the array is C-contiguous).
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
"Adrian Martínez Vargas" wrote:
Hi, I would like to get a double** from a 2d numpy array i
Note: The last field in a C struct can be of variable size, decided at
malloc-time. I can't think of a clear syntax for that, except perhaps a builtin
function cython.coercevariablesizestruct...
Dag Sverre
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
mark florisson
Are you saying that when coercing a struct to an object, one would copy scalar
fields by value but reference array fields? -1, that would be confusing. Either
the whole struct through a view, or copy it all.
It bothers me that structs are passed by value in Cython, but it seems
impossible to ch
On 10/02/2011 12:38 PM, mark florisson wrote:
Hey,
I'm unable to login in trac, but I found a bug in the buffer support:
cimport cython
cimport numpy as np
@cython.boundscheck(False)
@cython.wraparound(False)
cdef void func(np.ndarray[np.float32_t, ndim=2] a) nogil:
pass
This calls __Pyx
On 10/09/2011 02:11 PM, mark florisson wrote:
Hey,
So far people have been enthusiastic about the cython.parallel features,
I think we should introduce some new features. I propose the following,
Great!!
I only have time for a very short feedback now, perhaps more will follow.
assume parall
On 10/09/2011 02:18 PM, Dag Sverre Seljebotn wrote:
On 10/09/2011 02:11 PM, mark florisson wrote:
Hey,
So far people have been enthusiastic about the cython.parallel features,
I think we should introduce some new features. I propose the following,
Great!!
I only have time for a very short
On 10/12/2011 09:55 AM, Robert Bradshaw wrote:
On Sun, Oct 9, 2011 at 5:57 AM, Dag Sverre Seljebotn
wrote:
On 10/09/2011 02:18 PM, Dag Sverre Seljebotn wrote:
On 10/09/2011 02:11 PM, mark florisson wrote:
Hey,
So far people have been enthusiastic about the cython.parallel features,
I
On 10/12/2011 10:36 AM, Dag Sverre Seljebotn wrote:
On 10/12/2011 09:55 AM, Robert Bradshaw wrote:
On Sun, Oct 9, 2011 at 5:57 AM, Dag Sverre Seljebotn
wrote:
On 10/09/2011 02:18 PM, Dag Sverre Seljebotn wrote:
On 10/09/2011 02:11 PM, mark florisson wrote:
with parallel.critical():
this
On 10/12/2011 11:08 AM, Robert Bradshaw wrote:
On Wed, Oct 12, 2011 at 1:36 AM, Dag Sverre Seljebotn
I wouldn't resist a builtin "channel" type in Cython (since we don't have
full templating/generics, it would be the only way of sending typed data
conveniently?).
zerom
Meta: I've been meaning to respond to this thread, but can't find the
time. What's the time-frame for implementing this? If it's hypothetical
at the moment and just is a question of getting things spec-ed, one
could perhaps look at discussing it at the next Cython workshop, or
perhaps a Skype c
On 10/20/2011 11:13 AM, mark florisson wrote:
On 20 October 2011 09:42, Dag Sverre Seljebotn
wrote:
Meta: I've been meaning to respond to this thread, but can't find the time.
What's the time-frame for implementing this? If it's hypothetical at the
moment and just is a
On 10/20/2011 02:51 PM, mark florisson wrote:
On 20 October 2011 10:35, Dag Sverre Seljebotn
wrote:
On 10/20/2011 11:13 AM, mark florisson wrote:
On 20 October 2011 09:42, Dag Sverre Seljebotn
wrote:
Meta: I've been meaning to respond to this thread, but can't find the
ti
On 10/21/2011 09:31 PM, mark florisson wrote:
On 21 October 2011 18:43, Dag Sverre Seljebotn
wrote:
On 10/20/2011 02:51 PM, mark florisson wrote:
On 20 October 2011 10:35, Dag Sverre Seljebotn
wrote:
On 10/20/2011 11:13 AM, mark florisson wrote:
On 20 October 2011 09:42, Dag Sverre
On 10/24/2011 09:26 PM, Wes McKinney wrote:
I've been using
ndarray[uint8_t, cast=True] bool_arr
to work with dtype=bool arrays in Cython lately. When testing using
Python 2.5 / NumPy 1.6.1 on Windows, I'm getting "unknown dtype code
in numpy.pxd (0)". Everything works fine with Python 2.6/2.7
On 10/24/2011 09:40 PM, Wes McKinney wrote:
On Mon, Oct 24, 2011 at 3:37 PM, Dag Sverre Seljebotn
wrote:
On 10/24/2011 09:26 PM, Wes McKinney wrote:
I've been using
ndarray[uint8_t, cast=True] bool_arr
to work with dtype=bool arrays in Cython lately. When testing using
Python 2.5 /
On 10/25/2011 09:33 AM, Stefan Behnel wrote:
mark florisson, 24.10.2011 21:50:
This is in response to
http://groups.google.com/group/cython-users/browse_thread/thread/bcbc5fe0e329224f
and http://trac.cython.org/cython_trac/ticket/498 , and some of the
previous discussion on cython.parallel.
Ba
On 10/25/2011 06:58 PM, mark florisson wrote:
On 25 October 2011 12:22, Stefan Behnel wrote:
The problem is not so much the INCREF (which is just an indirect add), it's
the DECREF, which contains a conditional jump based on an unknown external
value, that may trigger external code. That can kil
On 10/25/2011 09:01 PM, Dag Sverre Seljebotn wrote:
On 10/25/2011 06:58 PM, mark florisson wrote:
On 25 October 2011 12:22, Stefan Behnel wrote:
The problem is not so much the INCREF (which is just an indirect
add), it's
the DECREF, which contains a conditional jump based on an un
On 10/25/2011 08:45 PM, mark florisson wrote:
On 25 October 2011 19:10, Stefan Behnel wrote:
See? That's what I mean with language complexity. These things quickly turn
into an open can of worms. I don't think the language should handle any of
these. Message passing is up to libraries, for exam
On 10/26/2011 11:45 AM, mark florisson wrote:
On 26 October 2011 08:56, Stefan Behnel wrote:
Greg Ewing, 26.10.2011 00:27:
Dag Sverre Seljebotn wrote:
I'd gladly take a factor two (or even four) slowdown of CPython code any
day to get rid of the GIL :-). The thing is, sometimes one h
On 10/26/2011 11:45 AM, mark florisson wrote:
On 26 October 2011 08:56, Stefan Behnel wrote:
Greg Ewing, 26.10.2011 00:27:
Dag Sverre Seljebotn wrote:
I'd gladly take a factor two (or even four) slowdown of CPython code any
day to get rid of the GIL :-). The thing is, sometimes one h
On 10/26/2011 12:29 PM, Dag Sverre Seljebotn wrote:
On 10/26/2011 11:45 AM, mark florisson wrote:
On 26 October 2011 08:56, Stefan Behnel wrote:
Greg Ewing, 26.10.2011 00:27:
Dag Sverre Seljebotn wrote:
I'd gladly take a factor two (or even four) slowdown of CPython
code any
day to ge
Re b), it would be better to disable object dtypes (or emit a warning about the
possible bug when using them) than to delay the release. Object memoryviews are
rare in the first place, and those who contain themselves should be very rare.
--
Sent from my Android phone with K-9 Mail. Please excus
On 01/21/2012 07:50 PM, Stefan Behnel wrote:
Hi,
I did some callgrind profiling on Cython's generators and was surprised to
find that AddTraceback() represents a serious performance penalty for short
running generators.
I profiled a compiled Python implementation of itertools.groupby(), which
y
On 01/24/2012 08:05 PM, Vitja Makarov wrote:
2012/1/24 mark florisson:
On 24 January 2012 18:30, Vitja Makarov wrote:
2012/1/24 Robert Bradshaw:
On Tue, Jan 24, 2012 at 6:09 AM, Vitja Makarov wrote:
2012/1/24 mark florisson:
On 24 January 2012 11:37, Konrad Hinsen wrote:
Compiling the at
On 01/25/2012 07:59 AM, Vitja Makarov wrote:
2012/1/25 mark florisson:
On 24 January 2012 19:18, Dag Sverre Seljebotn
wrote:
On 01/24/2012 08:05 PM, Vitja Makarov wrote:
2012/1/24 mark florisson:
On 24 January 2012 18:30, Vitja Makarovwrote:
2012/1/24 Robert Bradshaw:
On Tue, Jan
On 01/27/2012 05:58 PM, Stefan Behnel wrote:
mark florisson, 27.01.2012 17:30:
On 27 January 2012 16:22, mark florisson wrote:
On 27 January 2012 15:47, Simon King wrote:
Hi all,
I am still *very* frustrated about the fact that Cython does not tell
where the error occurs. Since about one we
On 01/31/2012 03:29 PM, mark florisson wrote:
On 30 January 2012 21:03, Lisandro Dalcin wrote:
I'm testing my code with numpy-dev. They are trying to discourage use
of deprecated APIs, this includes direct access to the ndarray struct.
In order to update your code, you have to pass -DNPY_NO_DEP
On 01/31/2012 05:30 PM, mark florisson wrote:
On 31 January 2012 02:12, Robert Bradshaw wrote:
On Fri, Jan 27, 2012 at 1:01 PM, Stefan Behnel wrote:
Dag Sverre Seljebotn, 27.01.2012 21:03:
the need to explicitly declare "except *" keeps coming up again and
again, and is really a
On 01/31/2012 09:53 PM, mark florisson wrote:
On 31 January 2012 15:40, Dag Sverre Seljebotn
wrote:
On 01/31/2012 03:29 PM, mark florisson wrote:
On 30 January 2012 21:03, Lisandro Dalcinwrote:
I'm testing my code with numpy-dev. They are trying to discourage use
of deprecated
I just realized that
cdef int[:] a = None
raises an exception; even though I'd argue that 'a' is of the
"reference" kind of type where Cython usually allow None (i.e., "cdef
MyClass b = None" is allowed even if type(None) is NoneType). Is this a
bug or not, and is it possible to do something
On 02/02/2012 10:16 PM, mark florisson wrote:
On 2 February 2012 12:19, Dag Sverre Seljebotn
wrote:
I just realized that
cdef int[:] a = None
raises an exception; even though I'd argue that 'a' is of the "reference"
kind of type where Cython usually allow None (i.e
On 02/03/2012 12:09 AM, mark florisson wrote:
On 2 February 2012 21:38, Dag Sverre Seljebotn
wrote:
On 02/02/2012 10:16 PM, mark florisson wrote:
On 2 February 2012 12:19, Dag Sverre Seljebotn
wrote:
I just realized that
cdef int[:] a = None
raises an exception; even though I&#
On 02/03/2012 06:53 PM, Dag Sverre Seljebotn wrote:
On 02/03/2012 12:09 AM, mark florisson wrote:
On 2 February 2012 21:38, Dag Sverre Seljebotn
wrote:
On 02/02/2012 10:16 PM, mark florisson wrote:
On 2 February 2012 12:19, Dag Sverre Seljebotn
wrote:
I just realized that
cdef int[:] a
On 02/03/2012 07:07 PM, mark florisson wrote:
On 3 February 2012 18:06, mark florisson wrote:
On 3 February 2012 17:53, Dag Sverre Seljebotn
wrote:
On 02/03/2012 12:09 AM, mark florisson wrote:
On 2 February 2012 21:38, Dag Sverre Seljebotn
wrote:
On 02/02/2012 10:16 PM, mark
On 02/03/2012 07:26 PM, mark florisson wrote:
On 3 February 2012 18:15, Dag Sverre Seljebotn
wrote:
On 02/03/2012 07:07 PM, mark florisson wrote:
On 3 February 2012 18:06, mark florisson
wrote:
On 3 February 2012 17:53, Dag Sverre Seljebotn
wrote:
On 02/03/2012 12:09 AM, mark
On 02/05/2012 10:57 PM, mark florisson wrote:
Hey,
I created a CEP for opencl support: http://wiki.cython.org/enhancements/opencl
What do you think?
To start with my own conclusion on this, my feel is that it is too
little gain, at least for a GPU solution. There's already Theano for
trivial
On 02/08/2012 11:11 PM, mark florisson wrote:
On 8 February 2012 14:46, Dag Sverre Seljebotn
wrote:
On 02/05/2012 10:57 PM, mark florisson wrote:
Hey,
I created a CEP for opencl support:
http://wiki.cython.org/enhancements/opencl
What do you think?
To start with my own conclusion on
On 02/09/2012 12:15 AM, Dag Sverre Seljebotn wrote:
On 02/08/2012 11:11 PM, mark florisson wrote:
On 8 February 2012 14:46, Dag Sverre Seljebotn
wrote:
On 02/05/2012 10:57 PM, mark florisson wrote:
Hey,
I created a CEP for opencl support:
http://wiki.cython.org/enhancements/opencl
What do
This has got to be the most incredible and interesting turn of events
I've seen in a while! :-)
Dag
Original Message
Subject:Re: [Numpy-discussion] Proposed Roadmap Overview
Date: Mon, 20 Feb 2012 22:04:00 -0600
From: Travis Oliphant
Reply-To: Discussion of
I'm wondering what the best course of action for deprecating the shape
field in numpy.pxd is.
The thing is, currently "shape" really gets in the way. In most
situations it is OK with slow access to shape through the Python layer,
and "arr.shape[0]" is often just fine, but currently one is in a
On 02/29/2012 09:42 AM, Stefan Behnel wrote:
Dag Sverre Seljebotn, 29.02.2012 18:06:
I'm wondering what the best course of action for deprecating the shape
field in numpy.pxd is.
The thing is, currently "shape" really gets in the way. In most situations
it is OK with slow
On 03/01/2012 04:03 AM, mark florisson wrote:
On 29 February 2012 17:57, Dag Sverre Seljebotn
wrote:
On 02/29/2012 09:42 AM, Stefan Behnel wrote:
Dag Sverre Seljebotn, 29.02.2012 18:06:
I'm wondering what the best course of action for deprecating the shape
field in numpy.pxd is.
On 03/01/2012 09:29 AM, Sturla Molden wrote:
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 depre
To whoever hasn't heard the news already, there's now a NumPy Foundation
for Open Code for Usable Science:
http://numfocus.org/
Cython is on the "looking for representatives" list (my English fails me
as to what exactly that means though).
They are seeking US tax-exempt status. So:
a) Cyth
I'm pretty sure you can't be a student and mentor at the same time... Something
to keep in mind...
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
mark florisson wrote:
On 8 March 2012 14:27, Stefan Behnel wrote:
> Hi,
>
> I noticed that people start rushing for the nex
On 03/21/2012 01:56 PM, Robert Bradshaw wrote:
On Sat, Mar 10, 2012 at 10:44 PM, mark florisson
wrote:
On 8 March 2012 14:27, Stefan Behnel wrote:
Hi,
I noticed that people start rushing for the next season on Python's GSoC
mailing lists. Do we have any interested developers here, or genera
On 03/22/2012 09:03 AM, Stefan Behnel wrote:
William Stein, 22.03.2012 14:11:
On Thu, Mar 22, 2012 at 9:04 AM, David Kirkby wrote:
On 22 March 2012 12:33, William Stein wrote:
The usb device (for /levi) never appeared after I remotely rebooted sage.math.
Physical access is thus probably requir
On 03/22/2012 10:52 AM, Stefan Behnel wrote:
Dag Sverre Seljebotn, 22.03.2012 17:58:
On 03/22/2012 09:03 AM, Stefan Behnel wrote:
I would prefer copying the original installation over
(including the build history), rather than rebuilding it.
I hope it doesn't come to this, but if it do
On 03/22/2012 05:40 AM, mark florisson wrote:
On 22 March 2012 07:18, Stefan Behnel wrote:
Robert Bradshaw, 21.03.2012 21:24:
On Wed, Mar 21, 2012 at 6:47 AM, mark florisson wrote:
On 20 March 2012 18:51, Stefan Behnel wrote:
mark florisson, 20.03.2012 17:40:
On 18 March 2012 11:58, Stefan
On 03/22/2012 11:50 AM, mark florisson wrote:
Hey,
For the fused type runtime dispatch I found it very convenient to use
the with statement, but that is not supported in Python 2.4. However,
the compiler could dynamically compile compiler code with the compiler
itself and import it (pyximport),
On 03/22/2012 11:39 AM, Robert Bradshaw wrote:
On Thu, Mar 22, 2012 at 10:52 AM, Stefan Behnel wrote:
Dag Sverre Seljebotn, 22.03.2012 17:58:
On 03/22/2012 09:03 AM, Stefan Behnel wrote:
I would prefer copying the original installation over
(including the build history), rather than
On 03/22/2012 12:03 PM, Stefan Behnel wrote:
Dag Sverre Seljebotn, 22.03.2012 19:21:
Slightly related: I believe the best thing we can do to attract more
developers is to seriously clean up the codebase. My new year's resolution
is that if I get some days for working on Cython this year (I
On 03/27/2012 02:17 PM, Philip Herron wrote:
Hey
I got linked to your idea
http://groups.google.com/group/cython-users/browse_thread/thread/cb8aa58083173b97/cac3cf12d438b122?show_docid=cac3cf12d438b122&pli=1
by David Malcolm on his plugin mailing list.
I am looking to apply to Gsoc once again t
On 03/27/2012 08:05 PM, Dag Sverre Seljebotn wrote:
On 03/27/2012 02:17 PM, Philip Herron wrote:
Hey
I got linked to your idea
http://groups.google.com/group/cython-users/browse_thread/thread/cb8aa58083173b97/cac3cf12d438b122?show_docid=cac3cf12d438b122&pli=1
by David Malcolm on his pl
.
Note that even before this, the 'dims' field was renamed 'shape', because it is
shape in the Python API.
Dag
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Stefan Behnel wrote:
Dag Sverre Seljebotn, 21.03.2012 22:36:
> NumPy is starting to seriousl
On 03/28/2012 07:58 PM, Philip Herron wrote:
Hey all
I am implemented a very crude and simplistic and very badly programmed
version of a pxd generator i think i understand what were after now
but i would appreciate if you look over what i did to make sure i have
grasped the basic idea for now:
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 using Cython's numpy.pxd file, Cython should let me decide how
to manage the beast.
Error compiling Cython file:
--
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 using Cython's numpy.pxd file, Cython should let me decide how
to manage the beast.
Error compiling C
On 04/12/2012 11:00 PM, Wes McKinney wrote:
On Thu, Apr 12, 2012 at 10:38 AM, mark florisson
wrote:
Yet another release candidate, this will hopefully be the last before
the 0.16 release. You can grab it from here:
http://wiki.cython.org/ReleaseNotes-0.16
There were several fixes for the nump
Travis Oliphant recently raised the issue on the NumPy list of what
mechanisms to use to box native functions produced by his Numba so that
SciPy functions can call it, e.g. (I'm making the numba part up):
@numba # Compiles function using LLVM
def f(x):
return 3 * x
print scipy.integrate.q
101 - 200 of 369 matches
Mail list logo
