Fredrik Lundh wrote:
> if you check my original post, you'll find code for a new list helper
> function, which would solve this in a convenient way.
Yep - I thought I'd seen something like this, but couldn't find it
(eventually found it by searching for Lundh ;). That's exactly what I
was thinkin
On 12/7/05, Delaney, Timothy (Tim) <[EMAIL PROTECTED]> wrote:
> "Martin v. Löwis" wrote:
>
> > Nick Coghlan wrote:
> >> As Fredrik pointed out a while back, the PyObject approach doesn't
> >> *have* to involve manual decref operations - PyObject's come with a
> >> ready made arena structure, in the
"Delaney, Timothy (Tim)" wrote:
> > Nick Coghlan wrote:
> >> As Fredrik pointed out a while back, the PyObject approach doesn't
> >> *have* to involve manual decref operations - PyObject's come with a
> >> ready made arena structure, in the form of PyList.
> >
> > That doesn't really work: PyList_
"Martin v. Löwis" wrote:
> Nick Coghlan wrote:
>> As Fredrik pointed out a while back, the PyObject approach doesn't
>> *have* to involve manual decref operations - PyObject's come with a
>> ready made arena structure, in the form of PyList.
>
> That doesn't really work: PyList_Append (which you
Nick Coghlan wrote:
> As Fredrik pointed out a while back, the PyObject approach doesn't *have* to
> involve manual decref operations - PyObject's come with a ready made arena
> structure, in the form of PyList.
That doesn't really work: PyList_Append (which you would have to use)
duplicates th
Neal Norwitz wrote:
> This is my understanding of the two approaches from what I've seen so
> far (Jeremy or Martin should correct me if I'm wrong).
>
> With current arena impl:
> * need to call PyArena_AddPyObject() for any allocated PyObject
> * need to call PyArena_AddMallocPointer() for any
On 12/5/05, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> On 12/5/05, Jeremy Hylton <[EMAIL PROTECTED]> wrote:
[SNIP]
> I didn't look at the changes much, but from what I saw I think it may
> be better to move the arenas off the branch and onto the head now. It
> appears to be much easier to get right
On 12/5/05, Jeremy Hylton <[EMAIL PROTECTED]> wrote:
> On 12/5/05, James Y Knight <[EMAIL PROTECTED]> wrote:
> >
> > ISTM that having to remember which pointers are arena-allocated and
> > which are normally-refcounted-allocated removes the major gain that
> > an arena method is supposed to bring:
On 12/5/05, James Y Knight <[EMAIL PROTECTED]> wrote:
>
> On Dec 5, 2005, at 8:46 AM, Jeremy Hylton wrote:
> > I can see that problem occurring with an all-or-nothing solution, but
> > not if you have the freedom to allocate from an arena or from some
> > other mechanism. If there are multiple way
On Dec 5, 2005, at 8:46 AM, Jeremy Hylton wrote:
> On 12/5/05, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>
>> Jeremy Hylton wrote:
>> I would expect that you allocate in the process memory that needs to
>> outlive the arena, e.g. python strings. The fundamental problem is
>> that
>> the aren
On 12/5/05, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Jeremy Hylton wrote:
> I would expect that you allocate in the process memory that needs to
> outlive the arena, e.g. python strings. The fundamental problem is that
> the arena deallocation cannot know whether such memory exists, and what
Jeremy Hylton wrote:
> Can you expand on why you think this approach is fundamentally flawed?
I would expect that you allocate in the process memory that needs to
outlive the arena, e.g. python strings. The fundamental problem is that
the arena deallocation cannot know whether such memory exists,
On 12/1/05, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Jeremy Hylton wrote:
> > I'm not sure what your intent for this work is, but I'd like to create
> > a parallel arena branch and compare the results. I'll start work on
> > that tomorrow.
>
> I certainly want the PyObject* branch to become
Jeremy Hylton wrote:
> I'm not sure what your intent for this work is, but I'd like to create
> a parallel arena branch and compare the results. I'll start work on
> that tomorrow.
I certainly want the PyObject* branch to become "life" at some time;
I think this is the way to go, and that an aren
On 12/1/05, Jeremy Hylton <[EMAIL PROTECTED]> wrote:
> Martin,
>
> I'm not sure what your intent for this work is, but I'd like to create
> a parallel arena branch and compare the results. I'll start work on
> that tomorrow.
I think this is a good thing. It will be much easier to compare
impleme
Martin,
I'm not sure what your intent for this work is, but I'd like to create
a parallel arena branch and compare the results. I'll start work on
that tomorrow.
Jeremy
On 11/30/05, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> I created
>
> http://svn.python.org/projects/python/branches/ast-o
On 11/30/05, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> I created
>
> http://svn.python.org/projects/python/branches/ast-objects/
>
> You can convert your repository to that branch with
>
> svn switch svn+ssh://[EMAIL PROTECTED]/python/branches/ast-objects
>
If you would rather do a separate c
On 11/30/05, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>
> The bigger chunk of necessary changes is in using these, starting
> with ast.c.
I got a few more files to compile. The following files (all under
Python/) need some loving care and are looking for a kind soul to
adopt them:
ast.c, c
I created
http://svn.python.org/projects/python/branches/ast-objects/
You can convert your repository to that branch with
svn switch svn+ssh://[EMAIL PROTECTED]/python/branches/ast-objects
in the toplevel directory. In particular, this features
http://svn.python.org/projects/python/branches/as
19 matches
Mail list logo
