gmane.comp.python.cython.devel

Re: [Cython] CF based type inference

Vitja Makarov — 2013-05-21T13:49:45

2013/5/21 mark florisson <markflorisson88-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org>

x will be of object type here.


As well as here. Can it raise exception or not doesn't matter here since
typeof() returns type of entry and it's calculated at compile time.

Re: [Cython] CF based type inference

mark florisson — 2013-05-21T13:45:29

Sure, e.g.

    if cond:
        x = 2
    else:
        x = "hello"
    use(x)

A tricky one is this:

    try:
        x = f() # let's say 'double'
        x = g() # let's say 'string'
    finally:
        print typeof(x) # what does this print if 'f' can raise an exception?

Re: [Cython] CF based type inference

Vitja Makarov — 2013-05-21T13:41:46

2013/5/21 mark florisson <markflorisson88-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org>



Can you provide example please? And yes if type cannot be inferred it
fallback to object.

Re: [Cython] CF based type inference

mark florisson — 2013-05-21T13:32:16

Ok, so I assume it promotes the incoming types (all reaching
definitions)? If N == 0, then when using objects you get an int,
otherwise a double. What happens when the reaching types cannot be
promoted together? Do you fall back to object?

Re: [Cython] CF based type inference

Vitja Makarov — 2013-05-21T13:14:48

2013/5/21 mark florisson <markflorisson88-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org>



Hi Mark,

Nothing changed in your example old algorithm was able to handle this
"simple" kind of cycles as well as new one:

def foo(int N):
    x = 0
    for i in range(N):
        x += 0.2 * i
    print typeof(x)

So this function (not that N is an integer here) will print 'dobule'.

With new algorithm we can go further:

def foo(int N):
    x = 1
    y = 0
    for i in range(N):
        x = x * 0.1 + y * 0.2
        y = x * 0.3 + y * 0.4
    print typeof(x), typeof(y)

Here both x and y will be inferred as double

Re: [Cython] CF based type inference

mark florisson — 2013-05-21T11:39:06

Hey Vitja,

Cool! How do you want to handle variable merge at control flow joins?
Would you promote (backwards incompatible), use a union type, or
object? E.g. what does this result in:

    x = 0
    for i in range(N):
        x += 0.2 * i
    print typeof(x)

[Cython] CF based type inference

Vitja Makarov — 2013-05-21T10:26:35

Hi!

Recently I've started work on new type inference engine. Now it's almost
ready and I want to discuss it.

It works like this: first infer type for each assignment then for whole
entry. It has some advantages over previous algorithm:
 - it handles assignment cycles, see test_swap() for example
 - it can infer type using info about assignments on the whole entry:

a = 1
b = a
a = "str"

a is python object and b is integer.

Here are testcases that show some new cases it can solve:
https://github.com/vitek/cython
/blob/_type_inference_new/tests/run/type_inference_new.pyx

Here is branch for it https://github.com/vitek/cython
/tree/_type_inference_new

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 can bypass the GIL using `with
nogil`. But I figured it would be a good idea to report it anyway.

Ryan Pessa
AerisPOS Project Manager / Developer
Essential Elements <http://www.essential-elements.net/> |
AerisPOS<http://www.aerispos.com/>

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