Robert Bradshaw | 1 May 2009 07:12
Favicon

Re: [Cython] Path towards Python completeness

On Apr 30, 2009, at 9:36 AM, Stefan Behnel wrote:

> Stefan Behnel wrote:
>> Stefan Behnel wrote:
>>> Robert Bradshaw wrote:
>>>> http://hg.cython.org/cython-closures/file/c4ee199f08a2/tests/run/ 
>>>> closures_T82.pyx
>>>>
>>>> Before you get your hopes up too much, I want to add a big
>>>> disclaimer that though I tried to be careful, this is very first-
>>>> draft code and there are bound to be issues (e.g. I think I've run
>>>> into some with respect to Python arguments).
>>> I'll give it a try during the next days.
>>
>> I exercised it a bit and added more test cases. That revealed a  
>> couple of
>> problems, although I must say that it works pretty well in general.
>>
>> I added comments to the tests as far as I got with analysing them.  
>> One
>> segfaults pretty badly, which makes it harder to figure out.
>
> Ok, that was due to ref-counting problems.

I was hoping that's all it was (not that tracking down ref-counting  
issues is always easy...)

> All of these work for me now:
>
> http://hg.cython.org/cython-closures/file/626e754738b6/tests/run/ 
(Continue reading)

Robert Bradshaw | 1 May 2009 07:19
Favicon

Re: [Cython] hg repo doesn't seem to work?

On Apr 29, 2009, at 12:33 PM, Robert Bradshaw wrote:

> On Apr 29, 2009, at 11:46 AM, Ondrej Certik wrote:
>
>> Hi,
>>
>> I did:
>>
>> $ hg clone http://hg.cython.org/cython/
>> destination directory: cython
>> requesting all changes
>> adding changesets
>> adding manifests
>> adding file changes
>> transaction abort!
>> rollback completed
>> abort: 00changelog.i <at> 696e20737973: no node!
>>
>> am I doing something wrong?
>
> Hmm... I'm getting that too. I can't look into this now, but will try
> to do so later. You can clone from the others right now.

OK, it was missing a file in the repo (?). I think something got lost  
when we packaged it with distuitils. Resolved.

- Robert

Dag Sverre Seljebotn | 1 May 2009 14:28
Picon
Picon

[Cython] Please vote: wraparound directive

A new directive which allows Cython to assume that integers passed to [] 
are not negative.

Currently buffers have the negative_indices option:

   object[int, negative_indices=False] arr = ...

but this can be cumbersome and less flexible. The rationale for not 
doing this in the first place was that it changes semantics during 
normal running rather than under exceptional circumstances, but now 
 <at> cdivision has crossed that line anyway.

Also note that this could potentially apply to typed lists and tuples as 
well, if there's a benefit.

--

-- 
Dag Sverre
Dag Sverre Seljebotn | 1 May 2009 14:53
Picon
Picon

[Cython] 0.11.2 release schedule?

Like I've been saying on some occasions, I'm going show off Cython 18th 
of May, and have had a tendency to scratch some itches rather than 
planning how to explain them... so I'd really like a release to happen 
before then. (Though I also have some fixes/rewrites which are not done 
yet which will go in next week.)

If it helps I can play release manager this time and do the groundwork 
for making it build Sage etc. (especially if that gets us complex floats 
in time :-)).

Would it be possible to e.g. do a full stop feature freeze next Friday 
8th, and then a release the week after?

--

-- 
Dag Sverre
Kurt Smith | 1 May 2009 15:50
Picon

Re: [Cython] Please vote: wraparound directive

On Fri, May 1, 2009 at 7:28 AM, Dag Sverre Seljebotn
<dagss@...> wrote:
> A new directive which allows Cython to assume that integers passed to []
> are not negative.
>
> Currently buffers have the negative_indices option:
>
>   object[int, negative_indices=False] arr = ...
>
> but this can be cumbersome and less flexible. The rationale for not
> doing this in the first place was that it changes semantics during
> normal running rather than under exceptional circumstances, but now
>  <at> cdivision has crossed that line anyway.

+1 for me.

Since directives can be module, function or block scoped they're
pretty flexible, and it makes it clear & explicit that different
semantics are going on.

The current state allows the use of two different negative_indices
type buffers in the same expression:

arr_neg[a,b] = arr_neg[a,b] + arr_no_neg[abs(a), abs(b)]

While that would be impossible with the proposed directive.  I can't
easily think of cases when I'd like to mix negative & non_negative
indexing in the same expression, or when I couldn't just revert to
regular indexing for these cases when required -- presumably I'm
giving the arr_no_neg 'negative_indices=False' since I want to speed
(Continue reading)

Stefan Behnel | 1 May 2009 18:18
Picon
Favicon

Re: [Cython] 0.11.2 release schedule?


Dag Sverre Seljebotn wrote:
> Like I've been saying on some occasions, I'm going show off Cython 18th 
> of May, and have had a tendency to scratch some itches rather than 
> planning how to explain them... so I'd really like a release to happen 
> before then. (Though I also have some fixes/rewrites which are not done 
> yet which will go in next week.)
> 
> If it helps I can play release manager this time and do the groundwork 
> for making it build Sage etc. (especially if that gets us complex floats 
> in time :-)).
> 
> Would it be possible to e.g. do a full stop feature freeze next Friday 
> 8th, and then a release the week after?

I'm not currently working on cython-devel anyway, so I'm glad to hear that
you volunteer as QA manager. :)

There are tons of open issues assigned to 0.11.2, though. I don't expect
many more releases for 0.11.x (maybe a .3, but not necessarily a .4), so
they may have to get moved to 0.12. At least, there are no really critical
issues. Some even seem to be so low priority that we should remove their
milestone all together. Even some 'wishlist' bugs sound more important than
some of the 0.11.2 tickets. A minor bug in 0.11 doesn't mean it needs
fixing in a 0.11.x release, especially if the fix is not trivial.

Stefan
Simon King | 1 May 2009 19:15
Picon
Picon
Favicon

[Cython] Problems with creating a package of extension modules

Dear Cython-Dev,

currently I try to create a Cython package comprising couple of extension
modules for usage in Sage. It somehow works, but apparently the extension
classes in the modules don't know where they belong to.

In my setup.py, I have
setup(
  name = "pGroupCohomology",
  version = "1.0",
  author = "Simon A. King",
  author_email = "simon.king@...",
  url = "http://users.minet.uni-jena.de/~king/cohomology/",
  description = "Modular Cohomology Rings of Groups of Prime Power Order",
  packages=["pGroupCohomology"],
  package_dir={"pGroupCohomology":"CohoSrc"},
  ext_package="pGroupCohomology",
  ext_modules=[
    Extension("mtx",
              sources = ["CohoSrc/mtx.pyx",
                         ...],
              ...),
    Extension(...)]
  cmdclass = {'build_ext': build_ext}
)

I learned from some documentation that providing the optional argument
'ext_package' should make the Extensions modules in that package, so, it should
be Extension("mtx",...), not Extension("pGroupCohomology.mtx",...).

(Continue reading)

Robert Bradshaw | 1 May 2009 20:43
Favicon

Re: [Cython] Please vote: wraparound directive

On May 1, 2009, at 5:28 AM, Dag Sverre Seljebotn wrote:

> A new directive which allows Cython to assume that integers passed  
> to []
> are not negative.
>
> Currently buffers have the negative_indices option:
>
>    object[int, negative_indices=False] arr = ...
>
> but this can be cumbersome and less flexible. The rationale for not
> doing this in the first place was that it changes semantics during
> normal running rather than under exceptional circumstances, but now
>  <at> cdivision has crossed that line anyway.

Yes, I like this. I think directives are more explicit and easier to  
follow than extra data attached to types.

> Also note that this could potentially apply to typed lists and  
> tuples as
> well, if there's a benefit.

Yes, there is a potential benefit here.

- Robert

Robert Bradshaw | 1 May 2009 20:46
Favicon

Re: [Cython] Problems with creating a package of extension modules

On May 1, 2009, at 10:15 AM, Simon King wrote:

> Dear Cython-Dev,
>
> currently I try to create a Cython package comprising couple of  
> extension
> modules for usage in Sage. It somehow works, but apparently the  
> extension
> classes in the modules don't know where they belong to.
>
> In my setup.py, I have
> setup(
>   name = "pGroupCohomology",
>   version = "1.0",
>   author = "Simon A. King",
>   author_email = "simon.king@...",
>   url = "http://users.minet.uni-jena.de/~king/cohomology/",
>   description = "Modular Cohomology Rings of Groups of Prime Power  
> Order",
>   packages=["pGroupCohomology"],
>   package_dir={"pGroupCohomology":"CohoSrc"},
>   ext_package="pGroupCohomology",
>   ext_modules=[
>     Extension("mtx",
>               sources = ["CohoSrc/mtx.pyx",
>                          ...],
>               ...),
>     Extension(...)]
>   cmdclass = {'build_ext': build_ext}
> )
(Continue reading)

Robert Bradshaw | 1 May 2009 21:07
Favicon

Re: [Cython] 0.11.2 release schedule?

On May 1, 2009, at 9:18 AM, Stefan Behnel wrote:

> Dag Sverre Seljebotn wrote:
>> Like I've been saying on some occasions, I'm going show off Cython  
>> 18th
>> of May, and have had a tendency to scratch some itches rather than
>> planning how to explain them... so I'd really like a release to  
>> happen
>> before then. (Though I also have some fixes/rewrites which are not  
>> done
>> yet which will go in next week.)
>>
>> If it helps I can play release manager this time and do the  
>> groundwork
>> for making it build Sage etc. (especially if that gets us complex  
>> floats
>> in time :-)).
>>
>> Would it be possible to e.g. do a full stop feature freeze next  
>> Friday
>> 8th, and then a release the week after?
>
> I'm not currently working on cython-devel anyway, so I'm glad to  
> hear that
> you volunteer as QA manager. :)

Yes, that would be great if you would do the release managing-- 
definitely would make a mid-May release more feasible.

> There are tons of open issues assigned to 0.11.2, though. I don't  
(Continue reading)


Gmane