So then, this is not a problem for the moment, as long as the script writer is aware of this.
I will see if there is a way to tell swig ".py" runtime that one of his objects have been deleted, it could make sense to kill them when destruction happens for extra safety… weren't we talking about regression testing? :-P :D (interesting talk anyway) :) Miguel Angel Ajo http://www.nbee.es (http://www.nbee.es/) +34911407752 skype: ajoajoajo On Wednesday, 1 de May de 2013 at 18:59, Lorenzo Marcantonio wrote: > On Wed, May 01, 2013 at 06:32:46PM +0200, Miguel Angel Ajo wrote: > > this is not a problem when calling pcbnew objects from outside pcbnew, > > > Unless from the outside you call something that deletes an object you > have 'on hold' no, it's not a problem. Imaginary use case: > > Let's say a script want to delete a track segment; it take hold of the > segment (searching around and stuff) and put it in a variable. > > Now I don't actually know how track segment are deleted in pcbnew, but, > since it's imaginary, let's say that there is a board function that does > this, given a segment pointer (which is a plausible way to do stuff, > since usually object don't self-destruct). In pseudo-code: > > board = GetBoard() > segment = board.FindSegment(stuff_im_interested_to) > ... maybe other processing ... > board.DeleteSegment(segment) > > At this point, since the segment object was deleted, the segment > reference becomes invalid (usually trying to use it gives a segfault but > anyway is undefined behaviour). It works, just be careful to not use it > after that (or put a null inside to be sure, if python has the concept). > The old SAFE_DELETE macro did something like that for C++ (delete x; > x=0;). > > The problem exist in LUA too, BTW... actually since LUA is targeted > toward C, object are implemented as userdata (to anchor in the LUA > memory manager) but you have the same problem! The usual solution is > giving all the objects away to LUA (you gain free garbage collection in > the deal :D) but the object themselves must be coded specially for this > to happen; for example you have to register finalizers *and* every time > you take hold of another object you have to tell LUA that you have it, > otherwise it will be collected. If you ever had the (dis)pleasure of > coding COM object, the drill is the same. I don't know how python works but > I don't think that would be a lot different... it would be great if > there was a way to tell python "this object is no longer alive" and it > would null all the references (just put the magic call in the > destructors...); weak pointers in many languages works that > way (only automatically :D) > > > from inside, it could be a problem if we multithreadWx does run as a single > > thread event loop, or is it multithread? > > Never seen an ounce of thread synchronization in the whole kicad :D > From what I have seen it all run in the main event thread (or whatever > thing in wx receives messages from the outside) > > -- > Lorenzo Marcantonio > Logos Srl > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > (mailto:kicad-developers@lists.launchpad.net) > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > >
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
