kicad-developers team mailing list archive

[Maciej Sumiński <maciej.suminski@xxxxxxx>]

Hi Miles,

I suppose the silence in the thread indicates there are not many
developers knowing the Python scripting interface inside out. Since you
are both studying the scripting interface and developing own scripts, it
is quite possible you are the most competent person to give us an advice
on how to proceed. See some comments below, but I am neither a Python
script developer nor a scripting interface maintainer, so I might be
lacking some basic knowledge here.

On 02/28/2018 05:12 PM, miles mccoo wrote:
> So I'm plugin-ifying my python scripts (the mechanism is awesome). One of
> the plugins deletes some stuff and that is causing trouble.
> 
> 
> 
> I'm not sure how to fix the root cause. Hence this mail.
> 
> 
> 
> The plugin just deletes Edge.Cuts[1]:
> for d in board.GetDrawings():
>             if (d.GetLayerName() == 'Edge.Cuts'):
>                 board.Remove(d)
> 
> 
> 
> in board_item_container.i, I see this (with stuff deleted):
> %rename(RemoveNative)    BOARD_ITEM_CONTAINER::Remove;
>     def Remove(self,item):
>         self.RemoveNative(item)
>         item.thisown=1
> 
> 
> Setting thisown tells, python "you own it". Delete it when you're done.
> Which it does.
> 
> 
> The problem this causes is that the plugin mechanism saves a list of all
> objects before running the plugin and then checks if any of them has a null
> list after (ie is it still in the design).

Is this mechanism implemented to handle memory leaks? If so, would not
it be sufficient to stick to 'thisown' flag on Remove() calls or is
there another way objects might be destroyed using Python scripts?

> Since the object has been deleted by python, the plugin stuff gets confused.
> 
> 
> *So, the question is how to fix this?*
> 
> 
> It appears that the plugin infrastructure will delete for you (that's what
> I'm guessing), so the thisown setting shouldn't be done.
> 
> 
> On the other hand, if running code from within a standalone script (ie from
> regular python shell), now thisown'ing it would yield a memory leak.
> 
> 
> 
> Perhaps the plugin stuff should have some sort of flag indicating "you're
> in a plugin". Then the thisown setting could be conditional.

If the object listing mechanism is required for other reasons, then I
suppose it is second best idea. Generally speaking, I would like to make
the scripting interface convenient for the users, so they do not need to
worry about whether their scripts are run standalone or as a plugin.
Let's hide the dirty magic from them and make the coding process enjoyable.

Regards,
Orson

> But I'm just a spectator. *I'm happy to put in the time to fix this but
> need guidance on what approach to take.*
> 
> 
> Miles
> 
> 
> 
> [1] full plugin text
> import pcbnew
> 
> class RemoveBoundaryPlugin(pcbnew.ActionPlugin):
>     def defaults(self):
>         self.name = "Remove boundary"
>         self.category = "A descriptive category name"
>         self.description = "This plugin reads a dxf file and converts it to
> a zone"
> 
>     def Run(self):
>         board = pcbnew.GetBoard()
> 
>         for d in board.GetDrawings():
>             print("{}".format(str(d)))
>             #print("on layer {} {} {}".format(d.GetLayerName(),
>             #                                 str(d.GetStart()),
>             #                                 str(d.GetEnd())))
>             if (d.GetLayerName() == 'Edge.Cuts'):
>                 board.Remove(d)
> 
> RemoveBoundaryPlugin().register()
> 
> 
> 
> _______________________________________________
> 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
>

Attachment: signature.asc
Description: OpenPGP digital signature