headers
Dag Sverre Seljebotn | 1 Dec 2008 02:09
Picon
Picon

Re: [Cython] Temp allocation flow

Greg Ewing wrote:
> Dag Sverre Seljebotn wrote:
>> It 
>> now takes two parameters, "decref" and "free_temp", which both defaults 
>> to True, and which can be toggled.
> 
> Rather than a free_temp parameter, I'd be more inclined
> to have an owns_temp flag on the node, set according to
> whether the node allocated the temp itself or it was
> supplied by the parent (currently done via an optional
> parameter to allocate_temps(), which would become a
> parameter to generate_evaluation_code()).

I didn't supply enough context. It was meant for situations like this:

self.arg.generate_evaluate_code(code)
...
code.putln("if (...) {")
...
self.arg.generate_disposal_code(code)
...
code.putln("} else {")
...
self.arg.generate_disposal_code(code)
...
code.putln("}")

Here, one can't free the temp in the first generate_disposal_code 
(because then the else-block could reuse and overwrite the temp etc.). 
As mentioned this is now solved by considering temp freeing as a
(Continue reading)

Permalink | Reply | 2 comments |
headers
Dag Sverre Seljebotn | 1 Dec 2008 02:12
Picon
Picon

Re: [Cython] Temp allocation flow

Dag Sverre Seljebotn wrote:
> Greg Ewing wrote:
>> Dag Sverre Seljebotn wrote:
>>> It 
>>> now takes two parameters, "decref" and "free_temp", which both defaults 
>>> to True, and which can be toggled.
>> Rather than a free_temp parameter, I'd be more inclined
>> to have an owns_temp flag on the node, set according to
>> whether the node allocated the temp itself or it was
>> supplied by the parent (currently done via an optional
>> parameter to allocate_temps(), which would become a
>> parameter to generate_evaluation_code()).
> 
> I didn't supply enough context. It was meant for situations like this:
> 
> self.arg.generate_evaluate_code(code)
> ...
> code.putln("if (...) {")
> ...
> self.arg.generate_disposal_code(code)
> ...
> code.putln("} else {")
> ...
> self.arg.generate_disposal_code(code)
> ...
> code.putln("}")
> 
> Here, one can't free the temp in the first generate_disposal_code 
> (because then the else-block could reuse and overwrite the temp etc.). 
> As mentioned this is now solved by considering temp freeing as a
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Cournapeau | 1 Dec 2008 07:27
Picon
Gravatar

[Cython] Recursive structure, typedef

Hi,

I am using cython to wrap some fairly large C API, with a big numbers
of enumerations. Those API are big enough so that I got tired of
manually declaring the definitions (in particular enum), and start
working on a code generator based on gccxml. It almost works for some
non trivial headers (CoreAudio framework, Alsa headers), but I have a
problem with the following kind of C declaration:

typedef struct foo foo_t;

struct foo {
    foo_t *foo;
}

AFAIK, cython does support typedefing a struct directly, and you
should use something like that instead:

cdef struct foo:
    foo_t *foo
ctypdef foo foo_t

Which does not work as the recursive reference uses the typedef'd type
name. The following works, though:

cdef struct foo:
    foo *foo
ctypdef foo foo_t

For now, I can get away by modifying on the fly the gccxml parsed tree
(Continue reading)

Permalink | Reply | 5 comments |
headers
Greg Ewing | 1 Dec 2008 11:19
Picon
Picon
Favicon

Re: [Cython] Temp allocation flow

Dag Sverre Seljebotn wrote:

> self.arg.generate_evaluate_code(code)
> ...
> code.putln("if (...) {")
> ...
> self.arg.generate_disposal_code(code)
> ...
> code.putln("} else {")
> ...
> self.arg.generate_disposal_code(code)
> ...
> code.putln("}")

Are there any examples of this in Pyrex, or is this
from Cython?

--

-- 
Greg
Permalink | Reply | 0 comments |
headers
Dag Sverre Seljebotn | 1 Dec 2008 12:49
Picon
Picon

Re: [Cython] Temp allocation flow

I don't know Pyrex that well, and weren't around at the time of the fork. I assume it is Cython-only then.

We could probably change these cases. Then again they were probably added in the first place as features/optimizations.

Anyway, now the necessary changes to support it is up in -devel.

Dag Sverre Seljebotn
-----Original Message-----
From: Greg Ewing <greg.ewing@...>
Date: Monday, Dec 1, 2008 11:16 am
Subject: Re: [Cython] Temp allocation flow
To: cython-dev@...: cython-dev@...

Dag Sverre Seljebotn wrote:
>
>> self.arg.generate_evaluate_code(code)
> ...
> code.putln("if (...) {")
> ...
> self.arg.generate_disposal_code(code)
> ...
> code.putln("} else {")
> ...
> self.arg.generate_disposal_code(code)
> ...
> code.putln("}")
>
>Are there any examples of this in Pyrex, or is this
>from Cython?
>
(Continue reading)

Permalink | Reply | 2 comments |
headers
Lisandro Dalcin | 1 Dec 2008 13:20
Picon
Gravatar

[Cython] Python aborts when running Cython on petsc4py sources

I've got this when running Cython to generate petsc4py sources.

cython --cleanup 9 -I. -Iinclude -w src petsc4py.PETSc.pyx -o petsc4py_PETSc.c
python: Modules/gcmodule.c:276: visit_decref: Assertion
`gc->gc.gc_refs != 0' failed.

I've tried to manually remove the Cython extension modules

$ rm `find ~/lib/python/Cython -name '*.so'`

but then (I reported this some time ago), things fails (because of
pure-python mode)

cython --cleanup 9 -I. -Iinclude -w src petsc4py.PETSc.pyx -o petsc4py_PETSc.c
Traceback (most recent call last):
  File "/u/dalcinl/bin/cython", line 7, in <module>
    from Cython.Compiler.Main import main
  File "/u/dalcinl/lib/python/Cython/Compiler/Main.py", line 17, in <module>
    import Code
  File "/u/dalcinl/lib/python/Cython/Compiler/Code.py", line 11, in <module>
    from Scanning import SourceDescriptor
  File "/u/dalcinl/lib/python/Cython/Compiler/Scanning.py", line 14, in <module>
    import cython
ImportError: No module named cython

I have no time to dive onto this. I'm in the process of releasing
petsc4py alongside with core PETSc. Could any of you tell me what
cython-devel revision would be more or less safe to use?

--

--
(Continue reading)

Permalink | Reply | 6 comments |
headers
Lisandro Dalcin | 1 Dec 2008 13:31
Picon
Gravatar

Re: [Cython] Recursive structure, typedef

Hi, David. Did you tried latest release,
http://cython.org/Cython-0.10.2.tar.gz ? It contains fixes for
recursive typedef struct. Please, give a try a let us know of any
problem.

On Mon, Dec 1, 2008 at 4:27 AM, David Cournapeau <cournape@...> wrote:
> Hi,
>
> I am using cython to wrap some fairly large C API, with a big numbers
> of enumerations. Those API are big enough so that I got tired of
> manually declaring the definitions (in particular enum), and start
> working on a code generator based on gccxml. It almost works for some
> non trivial headers (CoreAudio framework, Alsa headers), but I have a
> problem with the following kind of C declaration:
>
> typedef struct foo foo_t;
>
> struct foo {
>    foo_t *foo;
> }
>
> AFAIK, cython does support typedefing a struct directly, and you
> should use something like that instead:
>
> cdef struct foo:
>    foo_t *foo
> ctypdef foo foo_t
>
> Which does not work as the recursive reference uses the typedef'd type
> name. The following works, though:
(Continue reading)

Permalink | Reply | 4 comments |
headers
David Cournapeau | 1 Dec 2008 13:40
Picon
Gravatar

Re: [Cython] Recursive structure, typedef

On Mon, Dec 1, 2008 at 9:31 PM, Lisandro Dalcin <dalcinl@...> wrote:
> Hi, David. Did you tried latest release,
> http://cython.org/Cython-0.10.2.tar.gz ? It contains fixes for
> recursive typedef struct. Please, give a try a let us know of any
> problem.
>

Yes, I use 0.10.2. I upgraded because indeed, before, the following
did not work:

cdef struct foo:
    foo *foo
ctypdef foo foo_t

It works on 0.10.2. But my problem is slightly different:

cdef struct foo:
    foo_t *foo
ctypdef foo foo_t

Notice how the recursive is referenced through a typedef. In C, this
is solved by forward declaring the struct through a typedef before the
struct declaration. But AFAIK, you can't do that in cython.

My question may be stupid: I know nothing about parsing languages, and
maybe this is just a problem in my own code generator which is
"hand-built" from the AST given by gccxml.

cheers,
(Continue reading)

Permalink | Reply | 3 comments |
headers
Dag Sverre Seljebotn | 1 Dec 2008 14:03
Picon
Picon

Re: [Cython] Python aborts when running Cython on petsc4py sources

Lisandro Dalcin wrote:

> I have no time to dive onto this. I'm in the process of releasing
> petsc4py alongside with core PETSc. Could any of you tell me what
> cython-devel revision would be more or less safe to use?

If you're in the process of releasing software, use the latest stable. 
-devel has had bugs for at least a week because of temps stuff, but the 
latest release should be safe.

Or is this happening in the latest release?

--

-- 
Dag Sverre
Permalink | Reply | 4 comments |
headers
Lisandro Dalcin | 1 Dec 2008 14:04
Picon
Gravatar

Re: [Cython] Python aborts when running Cython on petsc4py sources

On Mon, Dec 1, 2008 at 11:03 AM, Dag Sverre Seljebotn
<dagss@...> wrote:
> Lisandro Dalcin wrote:
>
> If you're in the process of releasing software, use the latest stable.
> -devel has had bugs for at least a week because of temps stuff, but the
> latest release should be safe.

OK

> Or is this happening in the latest release?

No, no. This is happening with cython-devel.

BTW, I switched to the revision above (a few commits away for latest
release), and all seems to work.

Revision: 1393
Branch: default
Author: Stefan Behnel <scoder@...>  2008-11-26 18:00:35
Committer: Stefan Behnel <scoder@...>  2008-11-26 18:00:35
Parent: 1392:a53116f21261 (fixed typo)
Child:  1394:71d8a06957eb (make TupleNode and ListNode a NewTempExprNode)

    let types inherit from object to work around hashing problems

> --
> Dag Sverre
> _______________________________________________
> Cython-dev mailing list
(Continue reading)

Permalink | Reply | 3 comments |

Gmane