gmane.comp.python.cython.devel

Re: [Cython] [cython-users] Re: Cython Typed Memoryviews versus Cython+Numpy Speed ups

Robert Bradshaw — 2013-05-17T05:03:54

I think so, but I'm not sure. If so, +1 to making this a transformation.

Re: [Cython] nogil doesn't seem to work when defined on extern cpp functions

Greg Ewing — 2013-05-08T22:56:08

The nogil declaration doesn't work that way. Declaring a
function as nogil just says that it's safe to call it
without the GIL -- it doesn't actually cause the GIL to
be released. You need a 'with nogil' block to do that.

Re: [Cython] Cython 0.19.1 release candidate

Stefan Behnel — 2013-05-08T19:12:28

Robert Bradshaw, 08.05.2013 21:00:

Done.

Stefan

Re: [Cython] Cython 0.19.1 release candidate

Robert Bradshaw — 2013-05-08T19:00:29

It'd be nice to pull in
https://github.com/cython/cython/commit/5574592e569e0cce5f1277b6f0c441d6d19122b5
as well.

On Wed, May 8, 2013 at 7:25 AM, Stefan Behnel <stefan_ml-KjMAwuNBv5izQB+pC5nmwQ< at >public.gmane.org> wrote:

Re: [Cython] nogil doesn't seem to work when defined on extern cpp functions

Stefan Behnel — 2013-05-08T18:48:29

Hi,

this question is better suited for the cython-users mailing list.

Ryan Pessa, 08.05.2013 20:09:

Declarations won't implicitly free the GIL for you. They just state that
the function doesn't need the GIL and can thus be called safely from within
a "nogil" block. Freeing the GIL is an explicit operation that is left to
the user.

Otherwise, you'd end up with ambiguous code semantics. Imaging you'd call
two functions in a row that are both declared nogil - should Cython lock
the GIL in between or not?

Stefan

[Cython] nogil doesn't seem to work when defined on extern cppfunctions

Ryan Pessa — 2013-05-08T18:09:14

Hello,

I ran into an interesting problem today. It doesn't seem like Cython
respects the `nogil` statement on extern cpp functions. I am trying to use
a blocking I/O function, and am running it in secondary thread so I can use
another library function to cancel it.

I have tried it both on the `extern` line:
    cdef extern from "digitalpersona/dpfp_api.h" nogil:
        uint32_t DPFPGetEvent(dp_uid_t* pDevUID, dp_device_event_t**
ppEvent, uint32_t uTimeoutMsec)
and on the function itself:
    cdef extern from "digitalpersona/dpfp_api.h" nogil:
        uint32_t DPFPGetEvent(dp_uid_t* pDevUID, dp_device_event_t**
ppEvent, uint32_t uTimeoutMsec) nogil

Either way, this statement still blocks other threads:
    res = dpfp_api.DPFPGetEvent(pIdDev, &pEvent,
dpfp_api.DP_TIMEOUT_INFINITE)
While this statement does not:
    with nogil:
        res = dpfp_api.DPFPGetEvent(pIdDev, &pEvent,
dpfp_api.DP_TIMEOUT_INFINITE)
All variables used (res, pIdDev, pEvent) are C variables.

Obviously this is not a huge issue, as I

Re: [Cython] Generated C++ code incompatible with Clang

Robert Bradshaw — 2013-05-07T20:55:28

It's not a big problem, but it'll be an ugly and invasive amount of
bookkeeping to manage these top-level typedefs per type deletion.

On Tue, May 7, 2013 at 1:38 PM, Hannes Röst
<hroest_nospam2333< at >quantentunnel.de> wrote:
_______________________________________________
cython-devel mailing list
cython-devel< at >python.org
http://mail.python.org/mailman/listinfo/cython-devel

Re: [Cython] Generated C++ code incompatible with Clang

Hannes Röst — 2013-05-07T20:38:38

Hi Robert

After some internal discussion, we have not found an obvious way to not
have the extra typedef. Is this a big problem?

Maybe there are other people on the list that are more fluent in C++ and
could think of a way to do it?

Greetings

Hannes

On 30 April 2013 07:48, Robert Bradshaw <robertwb-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:

Re: [Cython] [cython] Order cdef classes by inheritance before generating the code. (#223)

Stefan Behnel — 2013-05-06T19:26:08

Nikita Nemkin, 05.05.2013 16:13:

Luckily, this broke the Sage build, by running into an infinite loop while
sorting.

https://sage.math.washington.edu:8091/hudson/job/sage-build/1778/

We clearly need more tests for extension type hierarchies spread across
multiple modules.

Stefan

Re: [Cython] [cython] Hide Cython utility classes (like memoryview) from Python level module scope. (#222)

Stefan Behnel — 2013-05-05T12:40:40

Nikita Nemkin, 05.05.2013 14:26:

Ah, yes. It's way more complex for classes than for, say, lambda functions
(and even those have a fake name).

Anyway, given how easy it is to declare utility code < at >internal to get this
fixed, I think it's not worth looking for a different solution.

I merged your pull request.

Stefan

Re: [Cython] [cython] Hide Cython utility classes (like memoryview) from Python level module scope. (#222)

Nikita Nemkin — 2013-05-05T12:26:28

On Sun, 05 May 2013 17:03:54 +0600, Stefan Behnel <stefan_ml-KjMAwuNBv5izQB+pC5nmwQ< at >public.gmane.org>  
wrote:


entry.name serves for general identification and bookkeeping, not just
to provide a python level name. Non-null entry name is a very useful
invariant, I'd rather not break it for something trivial like name hiding.

All codegen algorithms will have to worry about (class) entries with null
names afterwards. Even if it works currently, it may break in the future.

Anyway, just setting entry.name to None does not work, because it is not
the only place to get a python name (and of course it's never checked for  
None).
For example, module init code uses ClassScope.class_name. Some other code
may use entry.type.name etc...


Best regards,
Nikita Nemkin

Re: [Cython] [cython] Hide Cython utility classes (like memoryview) from Python level module scope. (#222)

Stefan Behnel — 2013-05-05T11:03:54

Nikita Nemkin, 04.05.2013 19:52:

I wonder why utility classes actually need a Python name. Can't they just
live with None as "name"? All they should really need is their cname and a
properly analysed entry stored in the right places, so deleting their
Python visible name when merging them into the main module should fix this.

Stefan

Re: [Cython] any more fixes for 0.19.1 ?

Stefan Behnel — 2013-05-04T17:21:26

Nikita Nemkin, 04.05.2013 16:28:

I'm not sure what the exact problem is here, but in general, I'd say that
they should be declared in the CythonScope only, and not leak into the
module scope at all. Mark would know more details on this one.

Stefan

Re: [Cython] any more fixes for 0.19.1 ?

Nikita Nemkin — 2013-05-04T14:28:13

On Fri, 03 May 2013 19:49:19 +0600, Stefan Behnel <stefan_ml-KjMAwuNBv5izQB+pC5nmwQ< at >public.gmane.org>  
wrote:


I'm working on this one and I need an opinion: should utility
classes be made internal by default or should they use
< at >cython.internal explicitly?


Best regards,
Nikita Nemkin

Re: [Cython] any more fixes for 0.19.1 ?

Stefan Behnel — 2013-05-03T13:49:19

Stefan Behnel, 03.05.2013 09:29:

There's also the C++ default arguments bug:

http://thread.gmane.org/gmane.comp.python.cython.user/1379

I think we should at least emit a warning for now.

Stefan

[Cython] any more fixes for 0.19.1 ?

Stefan Behnel — 2013-05-03T07:29:18

Hi,

since there's an unpleasant regression in 0.19, I'd like to release 0.19.1
soon. If you have any more fixes that should go in, you may want to apply
them now or at least speak up to delay the release.

I'm aware of ticket 810, but it doesn't seem like a regression and I don't
currently see an obvious simple way to reproduce it. It looks like a
classical "last reference dies while still in use" kind of problem to me.
Maybe even a bug in Sage rather than Cython that just accidentally worked
in older releases, although I'm not saying that there is nothing Cython
could do about it.

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

Ticket 814 (compiler crash during C++ code analysis) would also be worth
closing before a release as it might be an easy fix, even though it's not a
regression (crashes for me also in 0.18).

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

I also think that Ticket 775 ("memoryview" name leaks into module
namespace) should eventually be fixed as it's annoying and unexpected,
although

Re: [Cython] Autodoc improvements (#216)

Stefan Behnel — 2013-05-01T09:53:37

Stefan Behnel, 01.05.2013 11:50:

... and I just noticed that you already did that, and also removed the
warning about stray docstrings. Sorry for that. I'll merge it in.

Stefan

Re: [Cython] Autodoc improvements (#216)

Stefan Behnel — 2013-05-01T09:50:15

Nikita Nemkin, 26.04.2013 13:33:

Just because there's a ticket doesn't mean that it should be fixed, but
I'll give in on this one. Nikita, if you add the test that proves that
newlines prevent a subsequent string from becoming a docstring, i.e. that

    cdef attr

    "this is not a docstring"

behaves as expected and is different from

    cdef attr
    "this is a docstring"

I'll merge your pull request.

Stefan

Re: [Cython] Regresion in 0.19

Stefan Behnel — 2013-05-01T08:28:09

Stefan Behnel, 01.05.2013 09:45:

Yep, an oversight of my analyse_types() refactoring and cleanup.

https://github.com/scoder/cython/commit/db1f0ad5a5ac45d2a1da45211f9d344b4d83cab8

I'll give it a run through Jenkins before pushing it upstream.

Stefan

Re: [Cython] Regresion in 0.19

Stefan Behnel — 2013-05-01T07:45:23

Lisandro Dalcin, 01.05.2013 09:14:

With the above setup, I get Cython compile errors in 0.19:

Error compiling Cython file:
------------------------------------------------------------
...
cimport defs
cdef char buf[defs.SIZE]
                 ^
------------------------------------------------------------
code2.pyx:2:18: Not allowed in a constant expression

Interesting enough, this happens during declaration analysis, not during
type analysis. Looks like that's needed because the array size is part of
the declaration.

ISTM that the implementation of analyse_const_expression() is wrong. It
doesn't care about the result of analyse_types().

Stefan

Re: [Cython] Regresion in 0.19

Stefan Behnel — 2013-05-01T07:39:42

屈鹏, 01.05.2013 09:37:

This looks like thread-hijacking to me. Maybe you want to elaborate on this
in a new post to the cython-users mailing list.

Stefan

_______________________________________________
cython-devel mailing list
cython-devel< at >python.org
http://mail.python.org/mailman/listinfo/cython-devel