[PD] deleting data structures

david golightly davigoli at hotmail.com
Tue Oct 4 21:57:55 CEST 2005


Hm, some good insights Frank.  I'm not too familiar with how PD handles its 
own [pointer] objs internally but perhaps it might be a good approach for 
devel to remodel after the C/C++ technique I described.  As you say, I don't 
see how deleting by messages would be fundametally different from deleting 
by mouse click, in terms of internal relations between pointers in a list.  
Again, in C++ terminology (and I don't have to tell this to any developer!), 
most instances in a linked list will contain a pointer to the next obj & a 
pointer to the previous obj.  Upon deletion, the object will call a 
"deconstructor" routine that looks at the prev. obj and makes its "next" 
pointer point to the current obj's "next", and vice versa, like a circle of 
people holding hands, and you step out of the circle but join the hands of 
the two people next to you to keep the circle from breaking.  Therefore, no 
pointer references become "invalid" because no pointers have moved!  If this 
is how things work in C/C++ (and most other mid-level languages), I don't 
see why this couldn't be applied to the internal pointer logic in PD as 
well...

I don't think my C chops are up to the task of taking on a re-engineering of 
the internal [pointer] logic the DS, though again I'll have to take a look 
at it and see.  I could be waaaay off base here, and there are doubtless 
other technicalities I'm not seeing.  Any one in Devel who has any thoughts?

Thanks,
David




>From: Frank Barknecht <fbar at footils.org>
>To: pd-list at iem.at
>Subject: Re: [PD] deleting data structures
>Date: Tue, 4 Oct 2005 21:26:21 +0200
>
>Hallo,
>david golightly hat gesagt: // david golightly wrote:
>
> > Well, I ended up abandoning attempts to delete the data structures and 
>have
> > just assigned one data structure to each voice in a polyphonic texture, 
>so
> > that the DS's get moved around in response to note-events within that 
>voice
> > rather than created & deleted.  Seems to work fine for now, but
> > nonetheless: it seems to me that creating an effective DS system would
> >  involve the use of doubly-linked lists, each atom having (in C++
> > terminology) a pointer to the next object and to the previous object, 
>which
> > are then updated each time anything gets added or deleted to the list,
> > making it less of a list and more a 2-way ring (like the <deque> 
>template
> > in C++'s STL), as following successive pointers in any direction gets 
>you
> > back where you started.  That way, deleting an atom from the list causes
> > the list to close up around the gap, and the memory address of the 
>defunct
> > atom is returned to the heap and rendered irrelevant while all remaining
> > pointer references remain valid.
>
>This sounds like a sensible approach.
>
>To add a third name, that is used in different contexts to mean
>different things: The problem with deleting a data structure is not
>only one of memory (de)allocation (that can be solved using C language
>features), but the fact, that there is a [pointer] Pd type, which can
>be passed around just like a float or a symbol can. A float can not
>become invalid, however a [pointer] can:
>
>If you work a bit with DS, you will encounter messages like
>
>   error: ptrobj_bang: empty pointer
>   error: ptrobj_next: stale pointer
>   error: set: empty pointer
>
>a lot, if you delete a DS, whose [pointer] is still in use in your
>patch. This doesn't crash Pd (most of the time) but it will do other
>strange things. For example in the Midi-Loop-Sequencer I posted (also
>in my PWD~ ("public working directory") at [1]) the sequencing will
>stop as soon as you delete a note in your pattern, probably because
>not only the deleted [pointer] became invalid, but also all other
>[pointer]s in the same list (i.e. subwindow).
>
>So to allow clean deletion of DS-objects, some care has to be taken
>with dangling [pointer]s in a Pd patch's logic, too.
>
>However as deletion of DS is possible by hand (and also by Pd's
>internal messages for mouse movement and editing) adding a
>"remove"-method to [pointer] would not create a fundamentaly new
>problem, as far as I can see.
>
>[1] http://royalrabbit.goto10.org/svn/goto10/pd-patches/fbar/pipeseq/
>
>Ciao
>--
>  Frank Barknecht                 _ ______footils.org_ __goto10.org__
>
>_______________________________________________
>PD-list at iem.at mailing list
>UNSUBSCRIBE and account-management -> 
>http://lists.puredata.info/listinfo/pd-list






More information about the Pd-list mailing list