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:
Travis Oliphant recently raised the issue on the NumPy list of what
mechanisms to use to box native functions produced by his Numba
On 04/13/2012 07:24 AM, Stefan Behnel wrote:
Dag Sverre Seljebotn, 13.04.2012 00:34:
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 ca
Stefan Behnel, 13.04.2012 07:24:
> Dag Sverre Seljebotn, 13.04.2012 00:34:
>> 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, without reaction so far. I'll trigger
> them again, with a
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:
Travis Oliphant recently raised the issue
Dag Sverre Seljebotn, 13.04.2012 11:13:
> On 04/13/2012 07:24 AM, Stefan Behnel wrote:
>> Dag Sverre Seljebotn, 13.04.2012 00:34:
>>> http://wiki.cython.org/enhancements/cep1000
>>
>> There's PEP 362 which proposes a Signature object. It seems to have
>> attracted some interest lately and Guido see
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 subclass of an object) supporting this
>>> interface
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 thought as to what happens if __call__ is
re-assigned for an object (or subclass of an
On Fri, Apr 13, 2012 at 9:52 AM, Dag Sverre Seljebotn
wrote:
> On 04/13/2012 01:38 AM, Robert Bradshaw wrote:
>> Also, I'm not sure the type registration will scale, especially if
>> every callable type wanted to get registered. (E.g. currently closures
>> and generators are new types...) Where to
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
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 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
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
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 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;
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 {
Stefan Behnel, 13.04.2012 07:11:
> Robert Bradshaw, 12.04.2012 22:21:
>> On Thu, Apr 12, 2012 at 11:21 AM, mark florisson wrote:
>>> 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 branc
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 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 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 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
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 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
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
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
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 "
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
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 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 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
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
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)
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
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
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.
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
35 matches
Mail list logo
