headers
Robert Bradshaw | 2 Feb 2011 09:08
Favicon

Re: [Cython] Cython workshop

On Sun, Jan 23, 2011 at 2:50 AM, Stefan Behnel <stefan_ml@...> wrote:
> Dag Sverre Seljebotn, 23.01.2011 10:12:
>> On 01/23/2011 09:53 AM, Robert Bradshaw wrote:
>>> On Sat, Jan 22, 2011 at 12:06 AM, Stefan Behnel wrote:
>>>
>>>> Dag Sverre Seljebotn, 20.01.2011 12:26:
>>>>
>>>>> Starting new thread in case somebody did not see the hijacking.
>>>>>
>>>>> I've created this wiki page:
>>>>>
>>>>> http://wiki.cython.org/workshop1
>>>>>
>>>>> If you're interested in coming to a Cython workshop, please fill in your
>>>>> details in the table to help decide when and where a workshop should be
>>>>> held.
>>>>>
>>>> Current status so far: 4 core developers have signed in, 5 people in total,
>>>> all from Europe. Robert said he'd like to join in, too.
>>>>
>>>> Have there been any further off-list replies so far?
>>>>
>>> I've spoken to two people, both of whom won't be able to do much the
>>> first half of this year.
>
> Still, I think "close to now" is a very good time to do it, because 0.14.x
> is nearing stability and thus leaving the focus but needs a serious
> docsprint, 0.15 is in the pipeline and worth putting some work into and 1.0
> is getting in sight and worth discussing. Certainly enough to fill four days.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Robert Bradshaw | 4 Feb 2011 10:48
Favicon

Re: [Cython] Sage problem after fixing #654

On Sat, Jan 29, 2011 at 2:24 AM, Robert Bradshaw
<robertwb@...> wrote:
> On Fri, Jan 28, 2011 at 9:14 PM, Stefan Behnel <stefan_ml@...> wrote:
>> Robert Bradshaw, 28.01.2011 22:49:
>>> On Fri, Jan 28, 2011 at 1:01 PM, Stefan Behnel wrote:
>>>> And given that Cython cannot know that the pointer is actually not a
>>>> pointer, it generates the expected code here which only the C compiler can
>>>> detect as invalid.
>>>> This needs fixing in Sage in one way or another.
>>>
>>> Cython didn't used to support tyepdef'd arrays, so that's why it was
>>> declared as a pointer, but yes, that should be fixed. I'll do that in
>>> our copy, and it will go out with the 0.14.1 fixes (even though we
>>> don't need it yet). There's still the case of, say,
>>>
>>>      mpfr_init2(self._args[f(i)], self.domain.prec())
>>>
>>> where f is a cdef int ->  int function. Do we handle that?
>>
>> Sure. The problem isn't (any longer) that we *forget* to put things into a
>> temp, the problem is that we try to put things into a temp now that we
>> cannot store away.
>>
>> I've been dropping some cases in my latest commits where the temp copying
>> mechanism was triggered needlessly. It's basically a matter of properly
>> implementing is_simple() for an ExprNode in order to decide when a non-temp
>> result is side-effect free.
>>
>> I'm still not sure if a coerce_to_owned() method would be worthwhile. As
>> long as SimpleCallNode is the only place where this is actually needed,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stefan Behnel | 4 Feb 2011 16:00
Picon
Favicon

Re: [Cython] Cython 0.14.1 has been released

robertwb, 04.02.2011 11:51:
> Cython 0.14.1 has just been released. This release is primarily a bug
> fix release building on top of 0.14.
>
> Download: http://cython.org/release/Cython-0.14.1rc3.tar.gz

You may prefer getting it from PyPI or from this URL:

http://cython.org/release/Cython-0.14.1.tar.gz

Stefan
Permalink | Reply | 3 comments |
headers
Robert Bradshaw | 4 Feb 2011 18:23
Favicon

Re: [Cython] [cython-users] Re: Cython 0.14.1 has been released

On Fri, Feb 4, 2011 at 7:00 AM, Stefan Behnel <stefan_ml@...> wrote:
> robertwb, 04.02.2011 11:51:
>>
>> Cython 0.14.1 has just been released. This release is primarily a bug
>> fix release building on top of 0.14.
>>
>> Download: http://cython.org/release/Cython-0.14.1rc3.tar.gz
>
> You may prefer getting it from PyPI or from this URL:
>
> http://cython.org/release/Cython-0.14.1.tar.gz

Oops, I posted the rc3 link. I've done a 302 redirect to the correct
one for the time being.

- Robert
Permalink | Reply | 0 comments |
headers
Robert Bradshaw | 4 Feb 2011 19:50
Favicon

Re: [Cython] Switching from Py_UNICODE to Py_UCS4

On Sat, Jan 29, 2011 at 2:35 AM, Stefan Behnel <stefan_ml@...> wrote:
> Robert Bradshaw, 29.01.2011 10:01:
>> On Fri, Jan 28, 2011 at 11:37 PM, Stefan Behnel wrote:
>>> there is a recent discussion on python-dev about a new memory layout for
>>> the unicode type in CPython 3.3(?), proposed by Martin von Löwis (so it's
>>> serious ;)
>>>
>>> http://comments.gmane.org/gmane.comp.python.devel/120784
>>
>> That's an interesting PEP, I like it.
>
> Yep, after some discussion, I started liking it too. Even if it means I'll
> have to touch a lot of code in Cython again. ;)
>
>
>>> If nothing else, it gave me a new view on Py_UCS4 (basically a 32bit
>>> unsigned int), which I had completely lost from sight. It's public and
>>> undocumented and has been there basically forever, but it's a much nicer
>>> type to support than Py_UNICODE, which changes size based on build time
>>> options. Py_UCS4 is capable of representing any Unicode code point on any
>>> platform.
>>>
>>> So, I'm proposing to switch from the current Py_UNICODE support to Py_UCS4
>>> internally (without breaking user code which can continue to use either of
>>> the two explicitly). This means that loops over unicode objects will infer
>>> Py_UCS4 as loop variable, as would indexing. It would basically become the
>>> native C type that 1 character unicode strings would coerce to and from.
>>> Coercion from Py_UCS4 to Py_UNICODE would raise an exception if the value
>>> is too large in the given CPython runtime, as would write access to unicode
>>> objects (in case anyone really does that) outside of the platform specific
(Continue reading)

Permalink | Reply | 4 comments |
headers
Stefan Behnel | 5 Feb 2011 20:08
Picon
Favicon

[Cython] We missed a crash bug in 0.14.1

Hi,

sadly, we missed the opportunity to fix a crash bug in 0.14.1. It's been 
there for ages, so it's not a regression, but the recent runs of the Py2.6 
regression tests should have been red enough to tell us that it was there...

http://trac.cython.org/cython_trac/ticket/658

Basically, when you put "*args" or "**kwargs" into a closure, and anything 
bad happens during argument unpacking (such as an illegal argument type), 
the closure fields will get DECREF-ed but not set back to 0, so that the 
deallocation code crashes afterwards.

I don't think it's that uncommon to have args and kwargs in a closure, just 
think of a generic wrapper function. I opened a milestone 0.14.2 because I 
think this is worth fixing soon, maybe within a week or two, in case we 
want to wait for other problems to turn up.

Stefan
Permalink | Reply | 0 comments |
headers
Stefan Behnel | 6 Feb 2011 09:45
Picon
Favicon

Re: [Cython] Switching from Py_UNICODE to Py_UCS4

Robert Bradshaw, 04.02.2011 19:50:
> On Sat, Jan 29, 2011 at 2:35 AM, Stefan Behnel wrote:
>> Robert Bradshaw, 29.01.2011 10:01:
>>> On Fri, Jan 28, 2011 at 11:37 PM, Stefan Behnel wrote:
>>>> there is a recent discussion on python-dev about a new memory layout for
>>>> the unicode type in CPython 3.3(?), proposed by Martin von Löwis (so it's
>>>> serious ;)
>>>>
>>>> http://comments.gmane.org/gmane.comp.python.devel/120784
>>>
>>> That's an interesting PEP, I like it.
>>
>> Yep, after some discussion, I started liking it too. Even if it means I'll
>> have to touch a lot of code in Cython again. ;)
>>
>>
>>>> If nothing else, it gave me a new view on Py_UCS4 (basically a 32bit
>>>> unsigned int), which I had completely lost from sight. It's public and
>>>> undocumented and has been there basically forever, but it's a much nicer
>>>> type to support than Py_UNICODE, which changes size based on build time
>>>> options. Py_UCS4 is capable of representing any Unicode code point on any
>>>> platform.
>>>>
>>>> So, I'm proposing to switch from the current Py_UNICODE support to Py_UCS4
>>>> internally (without breaking user code which can continue to use either of
>>>> the two explicitly). This means that loops over unicode objects will infer
>>>> Py_UCS4 as loop variable, as would indexing. It would basically become the
>>>> native C type that 1 character unicode strings would coerce to and from.
>>>> Coercion from Py_UCS4 to Py_UNICODE would raise an exception if the value
>>>> is too large in the given CPython runtime, as would write access to unicode
(Continue reading)

Permalink | Reply | 3 comments |
headers
Stefan Behnel | 6 Feb 2011 10:08
Picon
Favicon

Re: [Cython] Switching from Py_UNICODE to Py_UCS4

Stefan Behnel, 06.02.2011 09:45:
> Robert Bradshaw, 04.02.2011 19:50:
>> On Sat, Jan 29, 2011 at 2:35 AM, Stefan Behnel wrote:
>>> Robert Bradshaw, 29.01.2011 10:01:
>>>> Also, this would be inconsistant with
>>>> python-level slicing, indexing, and range, right?
>>>
>>> Yes, it does not match well with slicing and indexing. That's the problem
>>> with narrow builds in both CPython and Cython. Only the PEP can fix that by
>>> basically dropping the restrictions of a narrow build.
>>
>> Lets let indexing do what indexing does.
>
> Ok. So you'd continue to get whatever CPython returns for indexing, i.e.
> Py_UNICODE in Py<=3.2 and Py_UCS4 in Python versions that implement the
> PEP. That includes separate code points for surrogate pairs on narrow builds.

... on narrow builds of pre-PEP Python versions, that is.

Stefan
Permalink | Reply | 0 comments |
headers
Robert Bradshaw | 6 Feb 2011 10:14
Favicon

Re: [Cython] Switching from Py_UNICODE to Py_UCS4

On Sun, Feb 6, 2011 at 12:45 AM, Stefan Behnel <stefan_ml@...> wrote:
> Robert Bradshaw, 04.02.2011 19:50:
>> On Sat, Jan 29, 2011 at 2:35 AM, Stefan Behnel wrote:
>>>> I am a bit concerned about the performance overhead of the Py_UCS4 to
>>>> Py_UNICODE coercion (e.g. if constructing a Py_UNICODE* by hand), but
>>>> maybe that's both uncommon and negligible.
>>>
>>> I think so. If users deal with Py_UNICODE explicitly, they'll likely type
>>> their respective variables anyway, so that there won't be an intermediate
>>> step through Py_UCS4. And on 32bit Unicode builds this isn't an issue at all.
>
> Coming back to this once more: if the PEP gets implemented, we will only
> know at C compile time (Py>=3.3 or not) if the result of indexing
> (including for-loop iteration) is Py_UCS4 or Py_UNICODE. For Cython's type
> inference, Py_UCS4 is therefore the more correct guess. So my proposal
> stands to always infer Py_UCS4 instead of Py_UNICODE for indexing, even if
> we ignore surrogate pairs in narrow Python builds.
>
> I will implement this for now, so that we can see what it gives.

Yes, that makes sense.

>>>> Also, this would be inconsistant with
>>>> python-level slicing, indexing, and range, right?
>>>
>>> Yes, it does not match well with slicing and indexing. That's the problem
>>> with narrow builds in both CPython and Cython. Only the PEP can fix that by
>>> basically dropping the restrictions of a narrow build.
>>
>> Lets let indexing do what indexing does.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Stefan Behnel | 6 Feb 2011 12:25
Picon
Favicon

Re: [Cython] Switching from Py_UNICODE to Py_UCS4

Robert Bradshaw, 06.02.2011 10:14:
> On Sun, Feb 6, 2011 at 12:45 AM, Stefan Behnel<stefan_ml@...>  wrote:
>> Robert Bradshaw, 04.02.2011 19:50:
>>> On Sat, Jan 29, 2011 at 2:35 AM, Stefan Behnel wrote:
>>>>> I am a bit concerned about the performance overhead of the Py_UCS4 to
>>>>> Py_UNICODE coercion (e.g. if constructing a Py_UNICODE* by hand), but
>>>>> maybe that's both uncommon and negligible.
>>>>
>>>> I think so. If users deal with Py_UNICODE explicitly, they'll likely type
>>>> their respective variables anyway, so that there won't be an intermediate
>>>> step through Py_UCS4. And on 32bit Unicode builds this isn't an issue at all.
>>
>> Coming back to this once more: if the PEP gets implemented, we will only
>> know at C compile time (Py>=3.3 or not) if the result of indexing
>> (including for-loop iteration) is Py_UCS4 or Py_UNICODE. For Cython's type
>> inference, Py_UCS4 is therefore the more correct guess. So my proposal
>> stands to always infer Py_UCS4 instead of Py_UNICODE for indexing, even if
>> we ignore surrogate pairs in narrow Python builds.
>>
>> I will implement this for now, so that we can see what it gives.
>
> Yes, that makes sense.

Done.

>>>>> Also, this would be inconsistant with
>>>>> python-level slicing, indexing, and range, right?
>>>>
>>>> Yes, it does not match well with slicing and indexing. That's the problem
>>>> with narrow builds in both CPython and Cython. Only the PEP can fix that by
(Continue reading)

Permalink | Reply | 0 comments |

Gmane