kicad-developers team mailing list archive

[Miguel Angel Ajo Pelayo <miguelangel@xxxxxxx>]

Well, I managed to wrap the DLIST<xxx> templates after fixing some strange
inheritance behaviour in swig (via %ignore directives).

And everything seems to start working with the lists from BOARD object.

I found that there is a lot of dependencies with wxPoint and wxString,
which are quite complicated  to handle (without using the .i files from
wxPython project or building equivalent ones).

Would it make sense for the project to remove dependencies with wx*** were
we are not at UI level?, I mean, internal objects and structures, passing
names to open or save files, etc. ?, main dendencies go to wxString,
wxPoint, wxSize and wxRect, another option could be adding extra LoadFile,
SaveFile methods receiving plain char *const string, which internally
converted the strings.

For swig wrappers, it's not the same a wxPoint from our wrappers that a
wxPoint from the wx standard wrappers
in python. (see the picture). That will make it complicated if we want to
pass wx objects to our calls, or wx objects from our calls to wx python
made dialogs. At least, until I'm not able to find a way to synchronize
that (which in the end it could be possible).


I will keep working on it, and keep you updated, my "roadmap" may look like
this:

1) End the wrapper for BOARD objects, and all the objects inside a board.
1.b) Add wrappers to basic objects like wxString, wxPoint, etc...
1.c) Clean up the GetBoard() implementation I did now (just for test)
2) Wrap the KICAD_PLUGIN + BOARD objects, to make "kicad/pcbnew" modules
importable from scripts.
3) Make some QA tests to check the our new scripting classes

Stepping up for this job it seems more and more feasible to me, as I solve
the little problems that I'm finding around it
should be something easy to do and maintain

Greetings,
Miguel Angel Ajo


2012/2/29 Miguel Angel Ajo Pelayo <miguelangel@xxxxxxx>

> Wow, doesn't look bad for a first test. I added a little GetBoard
> method to get the board created/loaded at start,
> and a simple dialog to run script, so  I can start poking around and
> trying the swig-ed classes.
>
> I've a meeting now, I will upload the code to the branch later.
>
> 2012/2/28 Miguel Angel Ajo Pelayo <miguelangel@xxxxxxx>:
> > As a proof of concept (with randomly swig-ed classes, etc...):
> >
> > http://bazaar.launchpad.net/~miguelangel-r/kicad/scripting/revision/3444
> >
> > With little work I managed to link to python and include a couple of
> > SWIG-ed modules
> > from our own code/classes.
> >
> > The integration in pcbnew.cpp and CMakeList.txt it's a little dirty
> > yet, but it works.
> >
> > I hope tomorrow could run something more useful than:
> >
> >  154    PyRun_SimpleString("import sys\n"
> >  155                       "sys.path.append(\".\")\n"
> >  156                       "import kicad,pcbnew\n"
> >  157                       "from time import time,ctime\n"
> >  158                       "print 'Today is',ctime(time())\n");
> >
> > Great! :)
> >
> > 2012/2/28 Miguel Angel Ajo Pelayo <miguelangel@xxxxxxx>
> >>
> >> Hi Dick,
> >>
> >> 2012/2/27 Dick Hollenbeck <dick@xxxxxxxxxxx>
> >>>
> >>> On 02/27/2012 01:48 AM, Miguel Angel Ajo Pelayo wrote:
> >>> > I've been doing some experiments about that during the weekend, with
> python as a first
> >>> > target, and using SWIG (which should be highly desired, as it's
> something easier to
> >>> > mantain).
> >>> >
> >>> > And by now, what I found is that swig is quite mature, but mainly
> ready for this:
> >>> >
> >>> >     Python--->[extension]/extension_wrap.o ---->library.so
> >>> >
> >>> > This is one of our intended usages, but,  for usage inside kicad:
> >>> >
> >>> >     Kicad<--->Python-->extension--->Kicad
> >>>
> >>>
> >>> I think to accomplish all our goals, we will have to split PCBNEW and
> EESCHEMA into at
> >>> least two parts each, perhaps three.  (Third part might be the
> graphics functions.)  This
> >>> means you keep a main() part, and have one or two DLL/DSO's beneath
> that main process
> >>> entry point.  This is my vision even *before* SWIG enters into it.
> >>
> >>
> >> It's finally not important for swig to have a DSO, but if it was in the
> plan anyway the final code must be much more clean.
> >>
> >>
> >>>
> >>> This lets you then have a replaceable main() part, that is a number of
> alternative
> >>> implementations of the top level process entry point.   EESCHEMA and
> PCNBEW core document
> >>> functions are held in what is essentially shared libraries.
> >>>
> >>>
> >>> I foresee at least 3 such alternative top main() parts:
> >>>
> >>> a) simple command line processing main() without a scripting language.
> >>
> >>
> >> Aha, like for simple task that could be scripted, like printing,
> plotting into gerbers, rendering thins, I suppose, right?
> >>
> >>>
> >>>
> >>> b) scripting language main(), for any SWIG favorite language(s).
> >>
> >>
> >> For this, and having all the functionalities as DLLs/DSOs,  we could go
> the swig-standard way, using any interpreter as...
> >>
> >>     python-->[eeschema-module]--->eeschema-lib
> >>     lua-->[eeschema-module]-->eeschema-lib
> >>     whatever-favorite-script-->[,,,]--->[...]
> >>
> >>
> >>>
> >>>
> >>> c) normal UI main() where the wxFrame and Dialogs reside.
> >>>
> >>>
> >>>
> >>> For the final use case, which is normal UI but also with scripting:
> >>>
> >>> Once you have this split (or these split_s_, if you consider a second
> DLL/DSO for drawing
> >>> functions), then like mortar in between two stacked bricks, there is a
> place to put a shim
> >>> in there, that is inject something below c) to handle the case where
> you want the normal
> >>> UI but also want scripting.
> >>
> >>
> >> Yes, that should be interesting, so people could load plugins into
> kicad in the form of scripts (like exporting/importing/special automated
> functions...) and assign them to hotkeys or system callbacks.
> >>
> >>> >
> >>> > It may require some hacking.
> >>>
> >>>
> >>> Your word, not mine.  I don't ever remember having hacked any code.  :)
> >>
> >>
> >> Well, the "hacking" won't be needed, it's not the standard case but it
> seems that the swig people already thought of this. So we could do it
> without breaking anything around (modifying swig, or patching swig's out...)
> >>
> >> And as python has already wx libraries, for the UI part it musn't be
> that bad :-) (as long as now wx is loaded dynamically...) it could work...
> >>
> >>
> >>>
> >>>
> >>> > They had an embed.i that can be a start point. The problem is that
> SWIG build wrapper
> >>> > modules that are ready to be loaded from python, but they include
> all the swig logic. So
> >>> > then, if we linked kicad + python lib + wrapper_kicad.cxx +
> wrapper_eeschema.cxx +
> >>> > wrapper_pcbnew.cxx then the swig code would be x3 times.
> >>>
> >>>
> >>> I mention all this so that you understand what we have been talking
> about, and don't
> >>> forget the BOARD_ACTION class, which is also still missing.   This is
> a way of pulling
> >>> non-UI verb type code down into the DLL/DSO layer without distancing
> it so far that it
> >>> cannot still be part of the c) wxFrames above.  I talked about using
> multiple inheritance
> >>> to bring BOARD_ACTION back into the frame.  Doing this across a
> DLL/DSO chasm will be a
> >>> trick, but it might be possible.  If it cannot be made to work, we can
> fall back to
> >>> separate link images, where you simply have identical code in a number
> places.
> >>>
> >>
> >> Yes of course, now I opened a kicad-scripting branch, to do some first
> (dirty) tests and confirm the feasibility of the project using SWIG, so we
> could later go and use the same build scripts / techniques for BOARD_ACTION
> (or any other parts) with very little effort and very little maintenance.
> >>
> >> Greetings :-)
> >>
> >>
> >>>
> >>>
> >>> Dick
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> 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
> >
> >
> >
> >
> > --
> >
> > Miguel Angel Ajo Pelayo
> > http://www.nbee.es
> > +34 636 52 25 69
> > skype: ajoajoajo
>
>
>
> --
>
> Miguel Angel Ajo Pelayo
> http://www.nbee.es
> +34 636 52 25 69
> skype: ajoajoajo
>



-- 

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

Attachment: wx_types_swig.png
Description: PNG image