On 5 May 2012 17:27, Dag Sverre Seljebotn wrote:
> On 05/05/2012 01:08 PM, mark florisson wrote:
>>
>> On 3 May 2012 13:24, Dag Sverre Seljebotn
>> wrote:
>>>
>>> I'm afraid I'm going to try to kick this thread alive again. I want us to
>>> have something that Travis can implement in numba and "h
On 05/05/2012 01:08 PM, mark florisson wrote:
On 3 May 2012 13:24, Dag Sverre Seljebotn wrote:
I'm afraid I'm going to try to kick this thread alive again. I want us to
have something that Travis can implement in numba and "his" portion of
SciPy, and also that could be used by NumPy devs.
Sinc
On 3 May 2012 13:24, Dag Sverre Seljebotn wrote:
> I'm afraid I'm going to try to kick this thread alive again. I want us to
> have something that Travis can implement in numba and "his" portion of
> SciPy, and also that could be used by NumPy devs.
>
> Since the decisions are rather arbitrary, pe
On Thu, May 3, 2012 at 5:24 AM, Dag Sverre Seljebotn
wrote:
> I'm afraid I'm going to try to kick this thread alive again. I want us to
> have something that Travis can implement in numba and "his" portion of
> SciPy, and also that could be used by NumPy devs.
That's great, I'd like to get things
I'm afraid I'm going to try to kick this thread alive again. I want us
to have something that Travis can implement in numba and "his" portion
of SciPy, and also that could be used by NumPy devs.
Since the decisions are rather arbitrary, perhaps we can try to quickly
get to the "+1" stage (or,
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
Nathaniel Smith wrote:
>On Thu, Apr 19, 2012 at 2:18 PM, Dag Sverre Seljebotn
> wrote:
>> On 04/19/2012 01:20 PM, Nathaniel Smith wrote:
>>> @cython.inline
>>> def square(x):
>>> return x * x
>>>
>>> # .specialize is an un-standardized Cython interface
>>> # square_double is an object imple
On Thu, Apr 19, 2012 at 2:18 PM, Dag Sverre Seljebotn
wrote:
> On 04/19/2012 01:20 PM, Nathaniel Smith wrote:
>> @cython.inline
>> def square(x):
>> return x * x
>>
>> # .specialize is an un-standardized Cython interface
>> # square_double is an object implementing the standardized C-callable
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 supported
signatures, which is needed (or at least convenient) if you want to use an
On 04/19/2012 01:11 PM, Stefan Behnel wrote:
Dag Sverre Seljebotn, 19.04.2012 13:05:
Pure speculation though
I think we should leave speculation to the CPUs. They are quite good at it
these days.
Yes, I agree, given these benchmarks, we should focus on
a) Usability in C
b) Simplicity
c)
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 supported
> signatures, which is needed (or at least convenient) if you want to use an
> FFI library or do some JIT-ing. So an iter
Dag Sverre Seljebotn, 19.04.2012 13:05:
> Pure speculation though
I think we should leave speculation to the CPUs. They are quite good at it
these days.
Stefan
___
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo
On 04/19/2012 12:56 PM, Dag Sverre Seljebotn wrote:
On 04/19/2012 11:07 AM, Nathaniel Smith wrote:
On Wed, Apr 18, 2012 at 10:58 PM, Dag Sverre Seljebotn
wrote:
On 04/18/2012 11:35 PM, Dag Sverre Seljebotn wrote:
On 04/17/2012 02:24 PM, Dag Sverre Seljebotn wrote:
On 04/13/2012 12:11 AM, D
On 04/19/2012 11:07 AM, Nathaniel Smith wrote:
On Wed, Apr 18, 2012 at 10:58 PM, Dag Sverre Seljebotn
wrote:
On 04/18/2012 11:35 PM, Dag Sverre Seljebotn wrote:
On 04/17/2012 02:24 PM, Dag Sverre Seljebotn wrote:
On 04/13/2012 12:11 AM, Dag Sverre Seljebotn wrote:
Travis Oliphant recentl
On Wed, Apr 18, 2012 at 10:58 PM, Dag Sverre Seljebotn
wrote:
> On 04/18/2012 11:35 PM, Dag Sverre Seljebotn wrote:
>>
>> On 04/17/2012 02:24 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
Dag Sverre Seljebotn, 18.04.2012 23:35:
> from numpy import sqrt, sin
>
> cdef double f(double x):
> return sqrt(x * x) # or sin(x * x)
>
> Of course, here one could get the pointer in the module at import time.
That optimisation would actually be very worthwhile all by itself. I mean,
we kn
On 04/18/2012 11:35 PM, Dag Sverre Seljebotn wrote:
On 04/17/2012 02:24 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
On 04/17/2012 02:24 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.g. (I'm making the nu
Dag Sverre Seljebotn wrote:
if you use
Python bytes in a dict in sys.modules['_nativecall'], the bytes objects
could be deallocated before callables containing the interned string --
unless you Py_INCREF once too many,
I don't understand that. Is there some reason that refcounting
of the inte
On Tue, Apr 17, 2012 at 8:07 PM, Dag Sverre Seljebotn
wrote:
>
>
> Nathaniel Smith wrote:
>
>>On Tue, Apr 17, 2012 at 3:34 PM, Dag Sverre Seljebotn
>> wrote:
>>> On 04/17/2012 04:20 PM, Nathaniel Smith wrote:
Since you've set this up... I have a suggestion for something that
>>may
be wo
Nathaniel Smith wrote:
>On Tue, Apr 17, 2012 at 3:34 PM, Dag Sverre Seljebotn
> wrote:
>> On 04/17/2012 04:20 PM, Nathaniel Smith wrote:
>>> Since you've set this up... I have a suggestion for something that
>may
>>> be worth trying, though I've hesitated to propose it seriously. And
>>> that i
Dag Sverre Seljebotn, 17.04.2012 15:20:
> On 04/17/2012 03:16 PM, Stefan Behnel wrote:
>> Dag Sverre Seljebotn, 17.04.2012 14:53:
>>> Is bytes a vararg object or does it wrap a char*?
>>
>> The data is stored internally in all CPython versions. Note that access to
>> it may not be efficient in othe
On Tue, Apr 17, 2012 at 3:34 PM, Dag Sverre Seljebotn
wrote:
> On 04/17/2012 04:20 PM, Nathaniel Smith wrote:
>> Since you've set this up... I have a suggestion for something that may
>> be worth trying, though I've hesitated to propose it seriously. And
>> that is, an API where instead of scannin
On 04/17/2012 04:20 PM, Nathaniel Smith wrote:
On Tue, Apr 17, 2012 at 1:24 PM, Dag Sverre Seljebotn
wrote:
OK, here's the benchmark code I've written:
https://github.com/dagss/cep1000
This is great!
Assumptions etc.:
- (Very) warm cache case is tested
- I compile and link libmycall
On Tue, Apr 17, 2012 at 1:24 PM, Dag Sverre Seljebotn
wrote:
> OK, here's the benchmark code I've written:
>
> https://github.com/dagss/cep1000
This is great!
> Assumptions etc.:
>
> - (Very) warm cache case is tested
>
> - I compile and link libmycallable.so, libmycaller.so and ./bench; with
On 04/17/2012 03:16 PM, Stefan Behnel wrote:
Dag Sverre Seljebotn, 17.04.2012 14:53:
Is bytes a vararg object or does it wrap a char*?
The data is stored internally in all CPython versions. Note that access to
it may not be efficient in other Python implementations, but at least PyPy
would als
Dag Sverre Seljebotn, 17.04.2012 14:53:
> Is bytes a vararg object or does it wrap a char*?
The data is stored internally in all CPython versions. Note that access to
it may not be efficient in other Python implementations, but at least PyPy
would also have a problem with providing a non-reference
On Tue, Apr 17, 2012 at 1:53 PM, Dag Sverre Seljebotn
wrote:
> On 04/17/2012 02:40 PM, Nathaniel Smith wrote:
>>
>> On Tue, Apr 17, 2012 at 12:54 PM, Dag Sverre Seljebotn
>> wrote:
>>>
>>> I don't believe doing interning right without a common dependency .so is
>>> all
>>> that easy. I'd love to
Dag Sverre Seljebotn, 17.04.2012 14:53:
> On 04/17/2012 02:40 PM, Nathaniel Smith wrote:
>> On Tue, Apr 17, 2012 at 12:54 PM, Dag Sverre Seljebotn wrote:
>>> I don't believe doing interning right without a common dependency .so is
>>> all
>>> that easy. I'd love to see a concrete spec for it (e.g.,
On 04/17/2012 02:40 PM, Nathaniel Smith wrote:
On Tue, Apr 17, 2012 at 12:54 PM, Dag Sverre Seljebotn
wrote:
I don't believe doing interning right without a common dependency .so is all
that easy. I'd love to see a concrete spec for it (e.g., if you use Python
bytes in a dict in sys.modules['_
On 04/17/2012 02:36 PM, Dag Sverre Seljebotn wrote:
On 04/17/2012 02:24 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
On Tue, Apr 17, 2012 at 12:54 PM, Dag Sverre Seljebotn
wrote:
> I don't believe doing interning right without a common dependency .so is all
> that easy. I'd love to see a concrete spec for it (e.g., if you use Python
> bytes in a dict in sys.modules['_nativecall'], the bytes objects could be
> de
On 04/17/2012 02:24 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.g. (I'm making the nu
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.g. (I'm making the numba part
up):
@numba # Compiles function using LLVM
On 04/15/2012 10:48 AM, Nathaniel Smith wrote:
On Sun, Apr 15, 2012 at 9:15 AM, Dag Sverre Seljebotn
wrote:
Do you really think it complicates the spec? SHA-1 is pretty standard, and
Python ships with hashlib (the hashing part isn't performance critical).
I prefer hashing to string-interning
Robert Bradshaw wrote:
Brevity, especially if the signature is inlined. (Encoding could take
care of this by, e.g. ignoring the redundant opening, or we could just
write di=d.)
Yes, I was thinking in terms of replacing the paren with
some other character, rather than inserting more parens.
--
Stefan Behnel wrote:
It wasn't really a proposed syntax, I guess, more of a way to write down an
example.
That's okay, although you might want to mention in the PEP
that the actual syntax is yet to be determined. Being a PEP,
anything it says tends to come across as being a specification
other
On 15 April 2012 12:40, Stefan Behnel wrote:
> mark florisson, 15.04.2012 13:30:
>> Finally, what are the semantics for Py_buffer? Will the callee own the
>> buffer, or will it borrow it? If they will borrow, then the compiler
>> will have to figure out whether it will need to own it (or be slower
mark florisson, 15.04.2012 13:30:
> Finally, what are the semantics for Py_buffer? Will the callee own the
> buffer, or will it borrow it? If they will borrow, then the compiler
> will have to figure out whether it will need to own it (or be slower
> and always own it), and acquire the buffer throu
On 15 April 2012 07:26, Stefan Behnel wrote:
> mark florisson, 14.04.2012 23:15:
>> On 14 April 2012 22:02, Stefan Behnel wrote:
>>> Dag Sverre Seljebotn, 14.04.2012 21:08:
* TBD: Support for Cython-specific constructs like memoryview slices
(so that arrays with strides and shape can
Nathaniel Smith wrote:
>On Sun, Apr 15, 2012 at 9:07 AM, Dag Sverre Seljebotn
> wrote:
>> On 04/15/2012 09:30 AM, Stefan Behnel wrote:
>>>
>>> Dag Sverre Seljebotn, 15.04.2012 08:58:
Ah, Cython objects. Didn't think of that. More below.
On 04/14/2012 11:02 PM, Stefan Behnel
Nathaniel Smith wrote:
>On Sun, Apr 15, 2012 at 9:15 AM, Dag Sverre Seljebotn
> wrote:
>> Do you really think it complicates the spec? SHA-1 is pretty
>standard, and
>> Python ships with hashlib (the hashing part isn't performance
>critical).
>>
>> I prefer hashing to string-interning as it can
On Sun, Apr 15, 2012 at 9:07 AM, Dag Sverre Seljebotn
wrote:
> On 04/15/2012 09:30 AM, Stefan Behnel wrote:
>>
>> Dag Sverre Seljebotn, 15.04.2012 08:58:
>>>
>>> Ah, Cython objects. Didn't think of that. More below.
>>>
>>> On 04/14/2012 11:02 PM, Stefan Behnel wrote:
thanks for writing
On Sun, Apr 15, 2012 at 9:15 AM, Dag Sverre Seljebotn
wrote:
> Do you really think it complicates the spec? SHA-1 is pretty standard, and
> Python ships with hashlib (the hashing part isn't performance critical).
>
> I prefer hashing to string-interning as it can still be done compile-time
> etc.
On 04/15/2012 10:07 AM, Dag Sverre Seljebotn wrote:
On 04/15/2012 09:30 AM, Stefan Behnel wrote:
Dag Sverre Seljebotn, 15.04.2012 08:58:
Ah, Cython objects. Didn't think of that. More below.
On 04/14/2012 11:02 PM, Stefan Behnel wrote:
thanks for writing this up. Comments inline as I read thr
On 04/15/2012 09:39 AM, Robert Bradshaw wrote:
On Sat, Apr 14, 2012 at 11:58 PM, Dag Sverre Seljebotn
wrote:
Ah, Cython objects. Didn't think of that. More below.
On 04/14/2012 11:02 PM, Stefan Behnel wrote:
Hi,
thanks for writing this up. Comments inline as I read through it.
Dag Sverre
On 04/15/2012 09:30 AM, Stefan Behnel wrote:
Dag Sverre Seljebotn, 15.04.2012 08:58:
Ah, Cython objects. Didn't think of that. More below.
On 04/14/2012 11:02 PM, Stefan Behnel wrote:
thanks for writing this up. Comments inline as I read through it.
Dag Sverre Seljebotn, 14.04.2012 21:08:
ea
On Sat, Apr 14, 2012 at 11:58 PM, Dag Sverre Seljebotn
wrote:
> Ah, Cython objects. Didn't think of that. More below.
>
>
> On 04/14/2012 11: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:
>
Dag Sverre Seljebotn, 15.04.2012 08:58:
> Ah, Cython objects. Didn't think of that. More below.
>
> On 04/14/2012 11:02 PM, Stefan Behnel wrote:
>> thanks for writing this up. Comments inline as I read through it.
>>
>> Dag Sverre Seljebotn, 14.04.2012 21:08:
>>> each described by a function point
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:
> There may be a lot of promotion/demotion (y
Ah, Cython objects. Didn't think of that. More below.
On 04/14/2012 11: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:
each described by a function pointer and a signature specification
string, such as "
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:
There may be a lot of promotion/demotion (you likely only want the
former) combinations, especially
Robert Bradshaw, 15.04.2012 08:27:
> On Sat, Apr 14, 2012 at 2:02 PM, Stefan Behnel wrote:
>> While overloaded signatures are great for the callee, they make things much
>> more complicated for the caller. It's no longer just one signature that
>> either matches or not. Especially when we allow mor
On 04/15/2012 08:16 AM, 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 multiple arguments, so perhaps it
makes sense to limit o
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 multiple arguments, so perhaps it
>>
Greg Ewing, 15.04.2012 03:07:
> Dag Sverre Seljebotn wrote:
>
>> if (obj has signature "id)i") {
>
> This is an aside, but is it really necessary to define the
> signature syntax in a way that involves unmatched parens?
> Some editors (such as the one I like to use) get confused
> by this, even w
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
mark florisson, 14.04.2012 23:15:
> On 14 April 2012 22:02, Stefan Behnel wrote:
>> Dag Sverre Seljebotn, 14.04.2012 21:08:
>>> * TBD: Support for Cython-specific constructs like memoryview slices
>>>(so that arrays with strides and shape can be passed faster than
>>>passing an {{{"O"}}}).
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 multiple arguments, so perhaps it
>> makes sense to limit ourselves a bit. For instance for numer
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 to the time taken by the call
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
Dag Sverre Seljebotn wrote:
if (obj has signature "id)i") {
This is an aside, but is it really necessary to define the
signature syntax in a way that involves unmatched parens?
Some editors (such as the one I like to use) get confused
by this, even when they're inside quotes.
The answer "get
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 to the time taken by the call itself
and whatever it does. But of course gut feelings are alway
Stefan Behnel wrote:
>mark florisson, 14.04.2012 23:00:
>> On 14 April 2012 20:08, Dag Sverre Seljebotn wrote:
>>> * TBD: Information about GIL requirements (nogil, with gil?), how
>>> exceptions are reported
>>
>> Maybe that could be a separate list, to be consulted mostly for
>> explicit
On 14 April 2012 22:02, 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 only be
mark florisson, 14.04.2012 23:00:
> On 14 April 2012 20:08, Dag Sverre Seljebotn wrote:
>> * TBD: Information about GIL requirements (nogil, with gil?), how
>> exceptions are reported
>
> Maybe that could be a separate list, to be consulted mostly for
> explicit casts (I think PyErr_Occurred()
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 only be used to call functions that state in their
> signature th
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 by his Numba so that
>> SciPy functions can call it, e.g. (I'm m
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.g. (I'm making the numba part up):
This thread is turning into one of t
On 04/14/2012 08:10 PM, Robert Bradshaw wrote:
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
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
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 Python
>>
>> Is it really? I got the impression that it's not consi
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 Python
>
>Is it really? I got the impression that it's not considered feasible,
>since it would require massi
Nathaniel Smith wrote:
>On Fri, Apr 13, 2012 at 11:22 PM, Dag Sverre Seljebotn
> wrote:
>>
>>
>> Robert Bradshaw wrote:
>>
>>>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 o
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 Python
Is it really? I got the impression that it's not considered feasible,
since it would require massive changes to the entire implem
On Fri, Apr 13, 2012 at 11:22 PM, Dag Sverre Seljebotn
wrote:
>
>
> Robert Bradshaw wrote:
>
>>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.
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't want to complicate the ABI too much, but I think
>>some
Dag Sverre Seljebotn wrote:
>
>
>Robert Bradshaw wrote:
>
>>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
Robert Bradshaw wrote:
>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)
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'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 o
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 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 over to the next specialization entry if
> it is too large; and prepe
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 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:
> That would only apply at
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 over to the next specialization entry if it
is too large; and prepend that key with a continuation code (two size-ts could
together say "
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:
That would only apply at a per-module level, though, so it would
require an indire
Robert Bradshaw, 13.04.2012 21:26:
> 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 d
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
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 been hinting at it
> on the PyPy mailing list for a while, wit
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
>>> indirection for the signature IDs. But
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:52 AM, Dag Sverre Seljebotn wrote:
>
> On 04/13/20
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/2012 01:38 AM, Robert Bradshaw wrote:
>
> Have you gi
On 13 April 2012 14:27, Dag Sverre Seljebotn wrote:
> On 04/13/2012 03:01 PM, mark florisson wrote:
>>
>> On 13 April 2012 13:48, Stefan Behnel wrote:
>>>
>>> Stefan Behnel, 13.04.2012 14:27:
Dag Sverre Seljebotn, 13.04.2012 13:59:
>
> Requiring interning is somewhat less elegan
On 04/13/2012 03:01 PM, mark florisson wrote:
On 13 April 2012 13:48, Stefan Behnel wrote:
Stefan Behnel, 13.04.2012 14:27:
Dag Sverre Seljebotn, 13.04.2012 13:59:
Requiring interning is somewhat less elegant in one way, but it makes a lot
of other stuff much simpler.
That gives us
struct {
On 13 April 2012 13:48, Stefan Behnel wrote:
> Stefan Behnel, 13.04.2012 14:27:
>> Dag Sverre Seljebotn, 13.04.2012 13:59:
>>> Requiring interning is somewhat less elegant in one way, but it makes a lot
>>> of other stuff much simpler.
>>>
>>> That gives us
>>>
>>> struct {
>>> void *pointer;
Stefan Behnel, 13.04.2012 14:27:
> Dag Sverre Seljebotn, 13.04.2012 13:59:
>> Requiring interning is somewhat less elegant in one way, but it makes a lot
>> of other stuff much simpler.
>>
>> That gives us
>>
>> struct {
>> void *pointer;
>> PyBytesObject *signature;
>> } record;
>>
>> and
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:52 AM, Dag Sverre Seljebotn wrote:
On 04/13/2012 01:38 AM, Robert Bradshaw wrote:
>
> Have you given any t
On 13 April 2012 12:38, 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/2012 01:38 AM, Robert Bradshaw wrote:
Have you given any thought as to what happens if __call__ is
re-assigned for an object (or
Dag Sverre Seljebotn, 13.04.2012 13:59:
> 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/2012 01:38 AM, Robert Bradshaw wrote:
> Minor nit: I don't think should_dereference is wort
On Fri, Apr 13, 2012 at 12:59 PM, Dag Sverre Seljebotn
wrote:
> I'll go one further: Intern Python bytes objects. It's just a PyObject*, but
> it's *required* (or just strongly encouraged) to have gone through
>
> sig = sys.modules['_nativecall']['interned_db'].setdefault(sig, sig)
>
> Obviously i
1 - 100 of 110 matches
Mail list logo
