On Tue, Mar 27, 2012 at 11:49 PM, Stefan Behnel wrote:
> Lisandro Dalcin, 27.03.2012 21:34:
>> On 27 March 2012 17:20, Stefan Behnel wrote:
>>> the NumPy related tests use a file "numpy_common.pxi" that contains this
>>> useless code:
>>>
>>> """
>>> cdef extern from *:
>>> bint FALSE "0"
>>>
On Thu, Mar 29, 2012 at 2:25 AM, Stefan Behnel wrote:
> Robert Bradshaw, 29.03.2012 11:19:
>>>> On 27 March 2012 17:20, Stefan Behnel wrote:
>>>>> the NumPy related tests use a file "numpy_common.pxi" that contains this
>>>>> useless code:
On Fri, Mar 30, 2012 at 10:24 AM, mark florisson
wrote:
> The release build looks good now, I'm thinking of pushing a second and
> final beta out there tomorrow. If anyone wants to get something in,
> now is the time to raise voice.
Excellent. I personally don't know of anything that can't wait
On Thu, Apr 12, 2012 at 11:21 AM, mark florisson
wrote:
> Hey,
>
> Could we run the pyregr test suite manually instead of automatically?
> It takes a lot of resources to build, and a single simple push to the
> cython-devel branch results in the build slots being hogged for hours,
> making the con
On Thu, Apr 12, 2012 at 3:34 PM, Dag Sverre Seljebotn
wrote:
> On 04/13/2012 12:11 AM, Dag Sverre Seljebotn wrote:
>>
>> 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.
On Fri, Apr 13, 2012 at 1:52 AM, Dag Sverre Seljebotn
wrote:
> On 04/13/2012 01:38 AM, Robert Bradshaw wrote:
>>
>> On Thu, Apr 12, 2012 at 3:34 PM, Dag Sverre Seljebotn
>> wrote:
>>>
>>> On 04/13/2012 12:11 AM, Dag Sverre Seljebotn wrote:
>>>
On Fri, Apr 13, 2012 at 4:59 AM, Dag Sverre Seljebotn
wrote:
> On 04/13/2012 01:38 PM, Stefan Behnel wrote:
>>
>> Robert Bradshaw, 13.04.2012 12:17:
>>>
>>> On Fri, Apr 13, 2012 at 1:52 AM, Dag Sverre Seljebotn wrote:
>>>>
>>>> On 04/13/2
On Fri, Apr 13, 2012 at 5:48 AM, mark florisson
wrote:
> On 13 April 2012 12:59, Dag Sverre Seljebotn
> wrote:
>> On 04/13/2012 01:38 PM, Stefan Behnel wrote:
>>>
>>> Robert Bradshaw, 13.04.2012 12:17:
>>>>
>>>> On Fri, Apr 13, 2012 at 1:5
On Fri, Apr 13, 2012 at 10:26 AM, Robert Bradshaw wrote:
> On Fri, Apr 13, 2012 at 4:59 AM, Dag Sverre Seljebotn
> wrote:
>> On 04/13/2012 01:38 PM, Stefan Behnel wrote:
>>> That would only apply at a per-module level, though, so it would require
>>> an
>>
On Fri, Apr 13, 2012 at 12:15 PM, Stefan Behnel wrote:
> Stefan Behnel, 13.04.2012 07:24:
>> Dag Sverre Seljebotn, 13.04.2012 00:34:
>>> On 04/13/2012 12:11 AM, Dag Sverre Seljebotn wrote:
>>> http://wiki.cython.org/enhancements/cep1000
>>
>> I'm all for doing something in this direction and have
On Fri, Apr 13, 2012 at 12:52 PM, Stefan Behnel wrote:
> Robert Bradshaw, 13.04.2012 20:21:
>> On Fri, Apr 13, 2012 at 10:26 AM, Robert Bradshaw wrote:
>>> On Fri, Apr 13, 2012 at 4:59 AM, Dag Sverre Seljebotn wrote:
>>>> On 04/13/2012 01:38 PM, Stefan Behnel wrote:
On Fri, Apr 13, 2012 at 1:27 PM, Dag Sverre Seljebotn
wrote:
> Ah, I didn't think about 6-bit or huffman. Certainly helps.
Yeah, we don't want to complicate the ABI too much, but I think
something like 8 4-bit common chars and 32 6-bit other chars (or 128
8-bit other chars) wouldn't be outrageous
On Fri, Apr 13, 2012 at 2:24 PM, Nathaniel Smith wrote:
> On Fri, Apr 13, 2012 at 9:27 PM, Dag Sverre Seljebotn
> wrote:
>> Ah, I didn't think about 6-bit or huffman. Certainly helps.
>>
>> I'm almost +1 on your proposal now, but a couple of more ideas:
>>
>> 1) Let the key (the size_t) spill ove
On Fri, Apr 13, 2012 at 3:06 PM, Dag Sverre Seljebotn
wrote:
>
>
> Robert Bradshaw wrote:
>
>>On Fri, Apr 13, 2012 at 1:27 PM, Dag Sverre Seljebotn
>> wrote:
>>> Ah, I didn't think about 6-bit or huffman. Certainly helps.
>>
>>Yeah, we don&
On Sat, Apr 14, 2012 at 1:56 AM, Stefan Behnel wrote:
> Dag Sverre Seljebotn, 14.04.2012 10:41:
>> Greg Ewing wrote:
>>> Dag Sverre Seljebotn wrote:
>>>
1) It doesn't work well with multiple interpreter states. Ok, nothing
works with that at the moment, but it is on the roadmap for Pytho
On Sat, Apr 14, 2012 at 2:00 PM, mark florisson
wrote:
> On 14 April 2012 20:08, Dag Sverre Seljebotn
> wrote:
>> On 04/13/2012 12:11 AM, Dag Sverre Seljebotn wrote:
>>>
>>> Travis Oliphant recently raised the issue on the NumPy list of what
>>> mechanisms to use to box native functions produced
On Sat, Apr 14, 2012 at 5:28 PM, Greg Ewing wrote:
> Robert Bradshaw wrote:
>
>> Has anyone done any experiments/timings to see if having constants vs.
>> globals even matters?
>
>
> My gut feeling is that one extra memory read is going to be
> insignificant compared
On Sat, Apr 14, 2012 at 2:02 PM, Stefan Behnel wrote:
> Hi,
>
> thanks for writing this up. Comments inline as I read through it.
>
> Dag Sverre Seljebotn, 14.04.2012 21:08:
>> === GIL-less accesss ===
>>
>> It is OK to access the native-call table without holding the GIL. This
>> should of course
On Sat, Apr 14, 2012 at 11:16 PM, Stefan Behnel wrote:
> Robert Bradshaw, 15.04.2012 07:59:
>> On Sat, Apr 14, 2012 at 2:00 PM, mark florisson wrote:
>>> There may be a lot of promotion/demotion (you likely only want the
>>> former) combinations, especially for multip
On Sat, Apr 14, 2012 at 11:39 PM, Stefan Behnel wrote:
> Robert Bradshaw, 15.04.2012 08:32:
>> On Sat, Apr 14, 2012 at 11:16 PM, Stefan Behnel wrote:
>>> Robert Bradshaw, 15.04.2012 07:59:
>>>> On Sat, Apr 14, 2012 at 2:00 PM, mark florisson wrote:
>>>>
typed value?
>>
>> What about signatures that require a C typed argument when we have an
>> arbitrary object value in our call parameters?
>>
>> We should also strip the "self" argument from the parameter list of
>> methods. That's handled by the a
On Sat, Apr 14, 2012 at 9:14 PM, Al Danial wrote:
> On Thu, Apr 12, 2012 at 7: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
>
>> If there are an
On Thu, Apr 19, 2012 at 3:53 AM, mark florisson
wrote:
> On 19 April 2012 08:17, Dag Sverre Seljebotn
> wrote:
>> On 04/19/2012 08:41 AM, Stefan Behnel wrote:
>>>
>>> Dag Sverre Seljebotn, 18.04.2012 23:35:
from numpy import sqrt, sin
cdef double f(double x):
return
On Thu, Apr 19, 2012 at 11:49 PM, Dag Sverre Seljebotn
wrote:
> On 04/20/2012 08:21 AM, Stefan Behnel wrote:
>>
>> Robert Bradshaw, 20.04.2012 02:52:
>>>
>>> On Thu, Apr 19, 2012 at 3:53 AM, mark florisson wrote:
>>>>
>>>> On 19 April 201
On Thu, Apr 19, 2012 at 11:55 PM, Dag Sverre Seljebotn
wrote:
> On 04/20/2012 08:49 AM, Dag Sverre Seljebotn wrote:
>>
>> On 04/20/2012 08:21 AM, Stefan Behnel wrote:
>>>
>>> Robert Bradshaw, 20.04.2012 02:52:
>>>>
>>>> On Thu, Apr 19,
On Thu, Apr 19, 2012 at 6:18 AM, Dag Sverre Seljebotn
wrote:
> On 04/19/2012 01:20 PM, Nathaniel Smith wrote:
>>
>> On Thu, Apr 19, 2012 at 11:56 AM, Dag Sverre Seljebotn
>> wrote:
>>>
>>> I thought of some drawbacks of getfuncptr:
>>>
>>> - Important: Doesn't allow you to actually inspect the
Yes, Julia looks really cool. It's been on my radar for a while, but I
haven't had a chance to really try it out for anything yet. But I
hadn't thought about low-level Python/Cython <-> Julia integration.
That sounds very interesting. I wonder if Jython could give any
insight into to the tight inte
On Sun, Apr 22, 2012 at 1:59 AM, Lisandro Dalcin wrote:
> On 22 April 2012 08:10, Robert Bradshaw wrote:
>> Yes, Julia looks really cool. It's been on my radar for a while, but I
>> haven't had a chance to really try it out for anything yet. But I
>> hadn't t
On Tue, May 1, 2012 at 1:02 PM, Stefan Behnel wrote:
> Francesc Alted, 01.05.2012 21:49:
>> On 5/1/12 2:39 PM, mark florisson wrote:
>>> On 1 May 2012 20:22, Stefan Behnel wrote:
Stefan Behnel, 01.05.2012 21:14:
> 2) Use math.pxd as an override for the math module. I'm not sure yet how
>>
On Sun, Apr 29, 2012 at 11:48 PM, Stefan Behnel wrote:
> mark florisson, 28.04.2012 21:57:
>> On 28 April 2012 19:50, Stefan Behnel wrote:
>>> mark florisson, 28.04.2012 20:33:
I think each module should have its own language level, so I think
that's a bug. I think the rules should be:
>
On Wed, May 2, 2012 at 12:33 AM, Stefan Behnel wrote:
> Robert Bradshaw, 02.05.2012 08:56:
>> On Tue, May 1, 2012 at 1:02 PM, Stefan Behnel wrote:
>>> Francesc Alted, 01.05.2012 21:49:
>>>> On 5/1/12 2:39 PM, mark florisson wrote:
>>>>> On 1 May 2
That's great, I'd like to get things moving forward on this.
> Since the decisions are rather arbitrary, perhaps we can try to quickly get
> to the "+1" stage (or, depending on how things turn out, a tournament
> starting with at most one proposal per person).
>
>
>
On Sat, May 5, 2012 at 10:42 PM, Stefan Behnel wrote:
> Stefan Behnel, 05.05.2012 21:50:
>>> https://github.com/cython/cython/pull/113
>>
>> This looks ok to me now. There have been objections back when we discussed
>> the initial patch for array.array support, so what do you think about
>> merg
On Mon, May 7, 2012 at 11:40 AM, Dag Sverre Seljebotn
wrote:
>
> mark florisson wrote:
>
>>On 7 May 2012 17:00, Dag Sverre Seljebotn
>>wrote:
>>> On 05/07/2012 04:16 PM, Stefan Behnel wrote:
Stefan Behnel, 07.05.2012 15:04:
>
> Dag Sverre Seljebotn, 07.05.2012 13:48:
>>
>>>
On Mon, May 7, 2012 at 10:08 AM, Stefan Behnel wrote:
> mark florisson, 07.05.2012 18:19:
>> On 7 May 2012 17:04, Vitja Makarov wrote:
>>> Hmm, it seems to me that master is currently broken:
>>>
>>> https://sage.math.washington.edu:8091/hudson/job/cython-devel-tests/BACKEND=c,PYVERSION=py27-ext/
On Mon, May 7, 2012 at 3:40 AM, Dag Sverre Seljebotn
wrote:
> [moving to dev list]
>
>
> On 05/07/2012 11:17 AM, Stefan Behnel wrote:
>>
>> Dag Sverre Seljebotn, 07.05.2012 10:44:
>>>
>>> On 05/07/2012 07:48 AM, Stefan Behnel wrote:
shaunc, 07.05.2012 07:13:
>
> The following cod
On Mon, May 7, 2012 at 8:48 AM, Dag Sverre Seljebotn
wrote:
> On 05/07/2012 03:04 PM, Stefan Behnel wrote:
>>
>> Dag Sverre Seljebotn, 07.05.2012 13:48:
>>
>>> Here you go:
>>>
>>> def foo(np.ndarray[double] a, np.ndarray[double] out=None):
>>> if out is None:
>>> out = np.empty_like(a
On Mon, May 7, 2012 at 5:05 PM, Greg Ewing wrote:
> Stefan Behnel wrote:
>
>> The main reason we didn't change this behaviour back then was that it
>> would
>> clearly break user code and we thought we could do without that. That's
>> different from considering it "right" and "good".
>
> I changed
On Mon, May 7, 2012 at 9:41 PM, Stefan Behnel wrote:
> Greg Ewing, 08.05.2012 02:05:
>> Stefan Behnel wrote:
>>
>>> The main reason we didn't change this behaviour back then was that it would
>>> clearly break user code and we thought we could do without that. That's
>>> different from considering
On Tue, May 8, 2012 at 6:47 AM, Vitja Makarov wrote:
> 2012/5/8 Stefan Behnel :
>> Hi,
>>
>> Vitja has rebased the type inference on the control flow, so I wonder if
>> this will enable us to properly infer this:
>>
>> def partial_validity():
>> """
>> >>> partial_validity()
>> ('Python
On Tue, May 8, 2012 at 12:04 PM, Vitja Makarov wrote:
> 2012/5/8 mark florisson :
>> On 8 May 2012 19:36, mark florisson wrote:
>>> Ok, so for the bugfix release 0.16.1 I propose that everyone cherry
>>> picks over its own fixes into the release branch (at least Stefan,
>>> since your fixes perta
On Wed, May 9, 2012 at 6:33 AM, Stefan Behnel wrote:
> mark florisson, 09.05.2012 15:18:
>> On 9 May 2012 14:16, Vitja Makarov wrote:
>>> from cython cimport typeof
>>>
>>> def foo(float[::1] a):
>>> b = a
>>> #del b
>>> print typeof(b)
>>> print typeof(a)
>>>
>>>
>>> In this example `
On Tue, May 8, 2012 at 2:48 AM, Stefan Behnel wrote:
> mark florisson, 08.05.2012 11:24:
> Dag Sverre Seljebotn, 08.05.2012 09:57:
>> 1) We NEVER deprecate "np.ndarray[double]", we commit to keeping that in
>> the language. It means exactly what you would like double[:] to mean,
>
On Tue, May 8, 2012 at 3:35 AM, mark florisson
wrote:
> On 8 May 2012 10:47, Dag Sverre Seljebotn wrote:
>>
>> After some thinking I believe I can see more clearly where Mark is coming
>> from. To sum up, it's either
>>
>> A) Keep both np.ndarray[double] and double[:] around, with clearly defined
On Wed, May 9, 2012 at 12:09 PM, mark florisson
wrote:
> On 9 May 2012 20:08, mark florisson wrote:
>> On 9 May 2012 19:56, Robert Bradshaw wrote:
>>> On Tue, May 8, 2012 at 3:35 AM, mark florisson
>>> wrote:
>>>> On 8 May 2012 10:47, Dag Sverre Seljebo
On Thu, May 10, 2012 at 2:25 AM, Stefan Behnel wrote:
> Hi,
>
> when declaring a C function in pure mode, you eventually end up with this:
>
> @cython.cfunc
> @cython.returns(cython.bint)
> @cython.locals(a=cython.int, b=cython.int, c=cython.int)
> def c_compare(a,b):
> c = 5
>
On Tue, May 8, 2012 at 11:22 PM, Stefan Behnel wrote:
> Robert Bradshaw, 09.05.2012 00:12:
>> On Tue, May 8, 2012 at 6:47 AM, Vitja Makarov wrote:
>>> 2012/5/8 Stefan Behnel:
>>>> Vitja has rebased the type inference on the control flow, so I wonder if
>>>
On Fri, May 11, 2012 at 8:56 AM, Stefan Behnel wrote:
> Robert Bradshaw, 11.05.2012 17:48:
>> On Tue, May 8, 2012 at 11:22 PM, Stefan Behnel wrote:
>>> Robert Bradshaw, 09.05.2012 00:12:
>>>> On Tue, May 8, 2012 at 6:47 AM, Vitja Makarov wrote:
>>>>
On Mon, May 14, 2012 at 10:05 AM, Nathaniel Smith wrote:
> On Mon, May 14, 2012 at 3:23 PM, Dag Sverre Seljebotn
> wrote:
>> On 05/14/2012 01:34 PM, Stefan Behnel wrote:
>>>
>>> Dag Sverre Seljebotn, 13.05.2012 21:37:
Anyway, thanks for the heads up, this seems to need a bit more work.
On Wed, May 16, 2012 at 12:15 PM, Stefan Behnel wrote:
> "Martin v. Löwis", 16.05.2012 20:33:
>>> Does this use case make sense to everyone?
>>>
>>> The reason why we are discussing this on python-dev is that we are looking
>>> for a general way to expose these C level signatures within the Python
On Wed, May 16, 2012 at 9:34 AM, Stefan Behnel wrote:
> Andreas van Cranenburgh, 16.05.2012 18:15:
>> Any news on this? Let me know if there's anything I can do to help inclusion
>> of this patch.
>
> Could someone please take over here?
>
> https://github.com/cython/cython/pull/113
>
> I haven't
On Mon, May 21, 2012 at 3:34 AM, Dag Sverre Seljebotn
wrote:
> On 05/20/2012 04:03 PM, mark florisson wrote:
>>
>> Hey,
>>
>> For my gsoc we already have some simple initial ideas, i.e.
>> elementwise vector expressions (a + b with a and b arrays with
>> arbitrary rank), I don't think these need a
On Mon, May 21, 2012 at 11:36 PM, Dag Sverre Seljebotn
wrote:
> On 05/22/2012 08:11 AM, Robert Bradshaw wrote:
>>
>> On Mon, May 21, 2012 at 3:34 AM, Dag Sverre Seljebotn
>> wrote:
>>>
>>> On 05/20/2012 04:03 PM, mark florisson wrote:
>>>>
&
On Mon, May 21, 2012 at 11:57 PM, Dag Sverre Seljebotn
wrote:
> On 05/22/2012 08:48 AM, Robert Bradshaw wrote:
>>
>> On Mon, May 21, 2012 at 11:36 PM, Dag Sverre Seljebotn
>> wrote:
>>>
>>> On 05/22/2012 08:11 AM, Robert Bradshaw wrote:
>>>>
&g
On Tue, May 22, 2012 at 6:08 AM, mark florisson
wrote:
> On 6 May 2012 15:28, mark florisson wrote:
>> Hey,
>>
>> I think we already have quite a bit of functionality (nearly) ready,
>> after merging some pending pull requests maybe it will be a good time
>> for a 0.17 release? I think it would b
Pushed my change.
On Wed, May 23, 2012 at 10:03 AM, mark florisson
wrote:
> On 23 May 2012 12:31, Robert Bradshaw wrote:
>> On Tue, May 22, 2012 at 6:08 AM, mark florisson
>> wrote:
>>> On 6 May 2012 15:28, mark florisson wrote:
>>>> Hey,
>>>
On Tue, May 22, 2012 at 6:16 AM, mark florisson
wrote:
> On 22 May 2012 07:48, Robert Bradshaw wrote:
>> On Mon, May 21, 2012 at 11:36 PM, Dag Sverre Seljebotn
>> wrote:
>>> On 05/22/2012 08:11 AM, Robert Bradshaw wrote:
>>>>
>>>> On Mo
On Mon, May 28, 2012 at 5:54 AM, mark florisson
wrote:
> On 28 May 2012 13:52, mark florisson wrote:
>> On 28 May 2012 13:49, mark florisson wrote:
>>> On 25 May 2012 21:53, Frédéric Bastien wrote:
Hi,
Sorry for the delay, I had some schedule change.
thanks for add
On Tue, May 29, 2012 at 3:22 PM, mark florisson
wrote:
> I started a new project, https://github.com/markflorisson88/minivect ,
> which currently features a simple C code generator. The specializer
> and astbuilder do most of the work of creating the right AST, so the
> code genera
On Tue, May 29, 2012 at 3:32 PM, mark florisson
wrote:
> On 29 May 2012 23:29, Robert Bradshaw wrote:
>> On Tue, May 29, 2012 at 3:22 PM, mark florisson
>> wrote:
>>>>>>> I started a new project, https://github.com/markflorisson88/minivect ,
>>>
On Tue, May 29, 2012 at 5:42 PM, Paul Leopardi
wrote:
>
> On Wednesday, 30 May 2012 02:40:47 UTC+10, Chris Barker wrote:
>>
>>
>> Well, the third option is to use your own home-made templatesto
>> auto-generate cython code for each type. That's actually not as
>> painful as it sounds -- there are
On Thu, May 31, 2012 at 3:09 AM, Dave Hirschfeld
wrote:
> Hi cython devs,
> I got the "unable to find vcvarsall.bat" error when using cython_inline when
> trying to compile with mingw. Using cython normally (creating a setup.py file)
> worked fine however.
>
> I was able to fix the problem for me
On Thu, May 31, 2012 at 7:20 AM, Dag Sverre Seljebotn
wrote:
>
> SEP updated (to what I hope is the final form):
>
> https://groups.google.com/forum/?fromgroups#!topic/numfocus/-XWwLMVgXBQ
> https://github.com/numfocus/sep/blob/master/sep200.rst
> https://github.com/dagss/pyextensibletype
Very ni
ting to call a nogil
> function? My take: For key-comparison you can compare under a mask, for
> interned-string we should have additional flags field.
>
> The situation is a bit awkward: The Cython list consensus (well, me and
> Robert Bradshaw) decided on what is "Approach 1&qu
On this note, a global string interning mechanism is likely to be of
interest beyond just native callable objects, so could be worth
separating out into a separate spec.
On Thu, May 31, 2012 at 11:50 AM, Robert Bradshaw wrote:
> On Thu, May 31, 2012 at 7:04 AM, Dag Sverre Seljebotn
>
On Thu, May 31, 2012 at 12:29 PM, Dag Sverre Seljebotn
wrote:
> On 05/31/2012 08:50 PM, Robert Bradshaw wrote:
>>
>> On Thu, May 31, 2012 at 7:04 AM, Dag Sverre Seljebotn
>> wrote:
>>>
>>> [Discussion on numfo...@googlegroups.com please]
>>>
>
On Mon, Jun 4, 2012 at 1:55 PM, Dag Sverre Seljebotn
wrote:
> On 06/04/2012 09:44 PM, Dag Sverre Seljebotn wrote:
>>
>> Me and Robert had a long discussion on the NumFOCUS list about this
>> already, but I figured it was better to continue it and provide more
>> in-depth benchmark results here.
>>
On Mon, Jun 4, 2012 at 3:07 PM, Dag Sverre Seljebotn
wrote:
>
>
> Robert Bradshaw wrote:
>
>>On Mon, Jun 4, 2012 at 1:55 PM, Dag Sverre Seljebotn
>> wrote:
>>> On 06/04/2012 09:44 PM, Dag Sverre Seljebotn wrote:
>>>>
>>>> Me and Rob
On Tue, Jun 5, 2012 at 1:07 AM, Stefan Behnel wrote:
> Dag Sverre Seljebotn, 05.06.2012 00:07:
>> The C FAQ says 'if you know the contents of your hash table up front you can
>> devise a perfect hash', but no details, probably just hand-waving.
>>
>> 128 bits gives more entropy for perfect hashin
On Tue, Jun 5, 2012 at 1:10 PM, Dag Sverre Seljebotn
wrote:
> On 06/04/2012 11:43 PM, Robert Bradshaw wrote:
>>
>> On Mon, Jun 4, 2012 at 1:55 PM, Dag Sverre Seljebotn
>> wrote:
>>>
>>> On 06/04/2012 09:44 PM, Dag Sverre Seljebotn wrote:
>>>>
&
On Tue, Jun 5, 2012 at 2:41 PM, Dag Sverre Seljebotn
wrote:
> On 06/05/2012 10:50 PM, Robert Bradshaw wrote:
>>
>> On Tue, Jun 5, 2012 at 1:10 PM, Dag Sverre Seljebotn
>> wrote:
>>>
>>> On 06/04/2012 11:43 PM, Robert Bradshaw wrote:
>>>>
&
On Wed, Jun 6, 2012 at 1:57 PM, Dag Sverre Seljebotn
wrote:
> On 06/06/2012 10:41 PM, Dag Sverre Seljebotn wrote:
>>
>> On 06/05/2012 12:30 AM, Robert Bradshaw wrote:
>>>
>>> I just found http://cmph.sourceforge.net/ which looks quite
>>> interestin
On Wed, Jun 6, 2012 at 2:36 PM, Dag Sverre Seljebotn
wrote:
> On 06/06/2012 11:16 PM, Robert Bradshaw wrote:
>>
>> On Wed, Jun 6, 2012 at 1:57 PM, Dag Sverre Seljebotn
>> wrote:
>>>
>>> On 06/06/2012 10:41 PM, Dag Sverre Seljebotn wrote:
>>>>
Both __init__ and __cinit__ are passed the same arguments, and the
former has Python calling conventions. (Also, we use Python's
framework to allocate and construct the new object, so there's not a
huge amount of flexibility here and working around this would be quite
non-trivial).
On Thu, Jun 7,
On Fri, Jun 8, 2012 at 2:12 PM, Dag Sverre Seljebotn
wrote:
> On 06/07/2012 12:35 PM, Dag Sverre Seljebotn wrote:
>>
>> On 06/07/2012 12:20 PM, Dag Sverre Seljebotn wrote:
>>>
>>> On 06/07/2012 12:26 AM, Robert Bradshaw wrote:
>>>>
>>>
On Fri, Jun 8, 2012 at 10:45 PM, Dag Sverre Seljebotn
wrote:
> On 06/09/2012 03:21 AM, Robert Bradshaw wrote:
>>
>> On Fri, Jun 8, 2012 at 2:12 PM, Dag Sverre Seljebotn
>>> There's still the indirection through SEP 200 (extensibletype slots). We
>>> can
&
On Sun, Jun 10, 2012 at 12:14 AM, Dag Sverre Seljebotn
wrote:
>
>
> Robert Bradshaw wrote:
>
>>On Fri, Jun 8, 2012 at 10:45 PM, Dag Sverre Seljebotn
>> wrote:
>>> On 06/09/2012 03:21 AM, Robert Bradshaw wrote:
>>>>
>>>> On Fri, Jun 8, 2012
On Sun, Jun 10, 2012 at 1:00 AM, Dag Sverre Seljebotn
wrote:
> On 06/10/2012 09:34 AM, Robert Bradshaw wrote:
>>
>> On Sun, Jun 10, 2012 at 12:14 AM, Dag Sverre Seljebotn
>> wrote:
>>>
>>>
>>>
>>> Robert Bradshaw wrote:
>&
On Sun, Jun 10, 2012 at 1:43 AM, Dag Sverre Seljebotn
wrote:
> On 06/10/2012 10:23 AM, Robert Bradshaw wrote:
>>
>> On Sun, Jun 10, 2012 at 1:00 AM, Dag Sverre Seljebotn
>> wrote:
>>>
>>> On 06/10/2012 09:34 AM, Robert Bradshaw wrote:
>>>>
>
On Tue, Jun 12, 2012 at 10:21 AM, Dag Sverre Seljebotn
wrote:
> On 06/12/2012 01:01 PM, Dag Sverre Seljebotn wrote:
>>
>> On 06/10/2012 11:53 AM, Robert Bradshaw wrote:
>>>
>>> On Sun, Jun 10, 2012 at 1:43 AM, Dag Sverre Seljebotn
>>>>
>>>&g
On Tue, Jun 19, 2012 at 4:58 AM, Sturla Molden wrote:
> 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
> st
I've been looking how painful it is to constantly convert between
Python objects and string in C++. Yes, it's easy to write a utility,
but this should be as natural (if not more so, as the length is
explicit) than bytes <-> char*. Several other of the libcpp classes
(vector, map) have natural Pytho
On Thu, Jun 28, 2012 at 2:54 AM, Stefan Behnel wrote:
> Robert Bradshaw, 28.06.2012 10:59:
>> I've been looking how painful it is to constantly convert between
>> Python objects and string in C++.
>
> You mean std::string (as I think it's called)? Can't we just
On Thu, Jun 28, 2012 at 10:45 PM, Stefan Behnel wrote:
> [moving this to cython-devel as it's getting technical]
>
> Robert Bradshaw, 28.06.2012 21:46:
>> On Thu, Jun 28, 2012 at 11:38 AM, Stefan Behnel wrote:
>>> currently, when I write "new CppClass()&q
On Thu, Jun 28, 2012 at 5:10 AM, Stefan Behnel wrote:
> Robert Bradshaw, 28.06.2012 12:07:
>> On Thu, Jun 28, 2012 at 2:54 AM, Stefan Behnel wrote:
>>> Robert Bradshaw, 28.06.2012 10:59:
>>>> I've been looking how painful it is to constantly convert between
On Fri, Jun 29, 2012 at 4:06 PM, Stefan Behnel wrote:
> Robert Bradshaw, 30.06.2012 00:38:
>> I implemented
>>
>> std::string <=> bytes
>> std::map <=> dict
>> iterable => std::vector => list
>> iterable => std::list => list
>&
On Mon, Jul 2, 2012 at 5:49 AM, Sturla Molden wrote:
> On 30.06.2012 01:06, Stefan Behnel wrote:
>
>>> std::string<=> bytes
>>> std::map<=> dict
>>> iterable => std::vector => list
>>> iterable => std::list => list
>>> iterable => std::set => set
>>> 2-iterable => std::pair => 2-tuple
>>
On Tue, Jul 3, 2012 at 9:38 AM, Stefan Behnel wrote:
> Dag Sverre Seljebotn, 03.07.2012 18:11:
>> On 07/03/2012 09:14 AM, Stefan Behnel wrote:
>>> I don't know what happens if a C++ exception is not being caught, but I
>>> guess it would simply crash the application. That's a bit more visible than
On Tue, Jul 3, 2012 at 11:11 AM, Stefan Behnel wrote:
> Robert Bradshaw, 03.07.2012 19:58:
>> On Tue, Jul 3, 2012 at 9:38 AM, Stefan Behnel wrote:
>>> Dag Sverre Seljebotn, 03.07.2012 18:11:
>>>> On 07/03/2012 09:14 AM, Stefan Behnel wrote:
>>>>> I
On Tue, Jul 3, 2012 at 11:43 AM, Dag Sverre Seljebotn
wrote:
> On 07/03/2012 08:23 PM, Robert Bradshaw wrote:
>>
>> On Tue, Jul 3, 2012 at 11:11 AM, Stefan Behnel
>> wrote:
>>>
>>> Robert Bradshaw, 03.07.2012 19:58:
>>>>
>>>> On Tu
On Fri, Jul 6, 2012 at 3:05 PM, Barry Warsaw wrote:
> On Jul 06, 2012, at 11:59 PM, Dag Sverre Seljebotn wrote:
>
>>>The generated code does a `catch(...)` so you lose that useful information.
>>>AFAICT, there's no way to find out within the catch clause (or anything
>>>called by that clause) what
On Fri, Jul 6, 2012 at 2:33 AM, mark florisson
wrote:
> On 6 July 2012 03:34, Dag Sverre Seljebotn wrote:
>>
>>
>> mark florisson wrote:
>>
>>>On 5 July 2012 21:46, Dag Sverre Seljebotn
>>>wrote:
>>>>
>>>>
>>>&
On Thu, Jul 19, 2012 at 12:19 PM, Stefan Behnel wrote:
> Stefan Behnel, 15.07.2012 19:41:
>> Stefan Behnel, 29.06.2012 07:45:
>>> [moving this to cython-devel as it's getting technical]
>>>
>>> Robert Bradshaw, 28.06.2012 21:46:
>>>>
On Thu, Jul 19, 2012 at 12:43 PM, Stefan Behnel wrote:
> Robert Bradshaw, 19.07.2012 21:29:
>> On Thu, Jul 19, 2012 at 12:19 PM, Stefan Behnel wrote:
>>> Stefan Behnel, 15.07.2012 19:41:
>>>> Stefan Behnel, 29.06.2012 07:45:
>>>>> Robert Bradshaw,
Thanks for the report!
On Wed, Jul 25, 2012 at 12:02 PM, Yaroslav Halchenko
wrote:
> So I wonder, wouldn't it be reasonable (i.e. more robust) in cython_inline to
> instantiate first build_extension and seek full name for the resultant
> extension from it? That should eliminate any possibility
On Wed, Jul 25, 2012 at 6:12 PM, Yaroslav Halchenko
wrote:
> actually I have not stated alternative variant since I thought it would
> not be wise to 'waste' memory : just store association between a
> particular build and target module_name but now I have mentioned that
> such code is pretty muc
On Wed, Jul 25, 2012 at 7:08 PM, Yaroslav Halchenko
wrote:
>
> On Wed, 25 Jul 2012, Robert Bradshaw wrote:
>
>> > module = imp.load_dynamic(module_name, module_path)
>> > arg_list = [kwds[arg] for arg in arg_names]
>
>> Compiled modules can persis
On Wed, Jul 25, 2012 at 4:24 AM, Greg Ewing wrote:
> mark florisson wrote:
>
>> I'm wondering, what was the original motivation to reuse temporaries?
>
> It goes back to Pyrex, where I didn't really give it much
> thought -- it just seemed like the tidiest thing to do.
> Once you have the logic to
On Tue, Jul 31, 2012 at 7:24 AM, Stefan Behnel wrote:
> mark florisson, 28.07.2012 14:04:
>> On 27 July 2012 23:30, Bradley Froehle wrote:
>>> Thanks to the work of Yaroslav Halchenko, there is an experimental Debian
>>> package for Cython 0.17.beta1 -- http://packages.qa.debian.org/c/cython.html
On Tue, Aug 7, 2012 at 2:53 AM, Stefan Behnel wrote:
> Hi,
>
> given how ubiquitous manual memory management is in C, I think it would be
> nice to let Cython generate the exception raising also for C, not only for
> C++. The difference is this:
>
> cdef extern from "...":
> char* make_new
301 - 400 of 790 matches
Mail list logo
