kicad-developers team mailing list archive

[Miguel Angel Ajo Pelayo <miguelangel@xxxxxxx>]

Hi Lorenzo,

    Let me answer what I know.

2012/8/20 Lorenzo Marcantonio <l.marcantonio@xxxxxxxxxxxx>

> I've done the scripted plotting patch and it substantially
> works-as-advertised; now I'll just have to port it to the main branch
> (not a lot of work usually). I'd expect to have a public patch tonight.
>
> During test I've noticed/tought about a couple of things, mostly due to
> my ignorance about python innards:
>
> - The plot controller objects keeps the plot file opened and close it
>   whenever a) the object is destroyed or b) another plotfile is opened
>   or c) you explicitly call the close method. At the moment I have to
>   use c) because the object isn't destroyed at the end of the script.
>
>   I assume it's because I store it in a global variable:
>
>   pctl = PLOT_CONTROLLER(GetBoard())
>
>   so since it remains reachable until pctl is in existance. I have no
>   idea about the python GC (reference counting? generational?
>   conservative? who knows...), so I have to assume that deletion is
>   'asynchronous and imprevedible' (as in most collected languages)
>
>
AFAIK Python uses reference counts to destroy unreferenced objects.



> - More seriously, it doesn't like when object are deleted by C++ when he
>   already have a reference. Example:
>
>   brd = GetBoard() or whatever creates a BOARD proxy
>
>   then load or do a new board -> the BOARD is deleted and a new one
>   takes it place
>

Yes, that won't work, because we keep the reference to the old deleted
board, not sure how to fix that, we cannot give a copy when using GetBoard,
because most probably we'd like to manipulate it.


>
>   Use brd from python -> hard crash since the memory was deleted
>
>   I know that in general this in not solvable (unless we hand over all
>   python-reachable object management to python; in lua for example this
>   is the way to do it...), but it is a serious problem to *at least*
>   think about.
>
> - I've got a warning from the compilation of the swig wrapper saying
>   that (in short) the IO_ERROR and the PARSE_ERROR are catched in the
>   wrong order so that the IO_ERROR catch is executed for PARSE_ERROR
>   too; maybe it's harmless (I think it is, since the behaviour is the
>   same) but I don't like warnings (they are there for a reason...)
>
>

I also had some problems when I needed for objects to change hands: for
example, I create a track, and then put it in the "GetBoard()" board, in
this case, BOARD object is supposed to take ownership of the object (that's
what Add method says, and makes sense), but in that case python (at close)
decided to delete our old object, and crash (for double free).

In that case, when a foreign object will explicitly delete another object
he takes ownership of you should always do object.thisown=0 before passing
it to his new owner. Look at the "Add" function here:
http://bazaar.launchpad.net/~kicad-testing-committers/kicad/testing/view/head:/pcbnew/scripting/board.i







> --
> Lorenzo Marcantonio
> Logos Srl
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>



-- 

Miguel Angel Ajo Pelayo
http://www.nbee.es
+34 636 52 25 69
skype: ajoajoajo