Re: [Kicad-developers] Kicad + V8/NodeJS/Swig [split from kicad ideas mail]

[Dick Hollenbeck]

> 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


I like number 3).  If the SWIG definitions are not regularly built and tested, 
we can well
imagine how they could become out of sync.  Thanks for thinking of this.


>
> 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
>


___
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

Re: [Kicad-developers] Kicad + V8/NodeJS/Swig [split from kicad ideas mail]

[Miguel Angel Ajo Pelayo]

Dick, Thanks a lot for the feedback.

1) I suspected that the wxString was used to take care of filename
encondigs. It makes sense. Thanks for your confirmation.
I'll try to look at the wxPython project to see how do they handle the
wxString objects :)

2) Sorry for my poor explanations, I will try to explain the problem I
found more clearly:

Right now, when we swig-out our code we get 2 wrappers (it could be just
one), one is kicad with general classes and definitions
and the other is pcbnew. Those wrappers, play well together. And it's swig
implementation takes care of converting objects from
C++ to script, and back, everything seems fine there.

The problem comes here:  If I import wxPython from my python script. At
this moment, the wxPython wrappers are loaded, and it
seems that a "wxPoint*" object wrapped from our software is different that
a "wxPoint*" wrapped from the wxPython. Both
swig wrappers (ours, and wx) don't seem to play well together. They can
run, but we cannot get a wxPoint or wxString from one
wrapper and pass it (directly) to the other.

For now, it's perfect to build just some wrappers for wxString, wxPoint,
wxRect, our basic dependencies, and we will be able
to use our api without any problem.

3) About the missing roadmap points, please ask me to add anything I
forgotten, I'm very sorry about that. Of course, this is
only for pcbnew,  this must be replicated for eeschema, etc. But it's
better to do it one step at a time :)


4) About the QA tests, yes, they are not very hard to do, and it's a good
way to test the full set of wrappers. About swig imports coming out of sync,
it shouldn't be a problem, they generate the class imports from our .h
headers. They could become out of sync if we don't use the .h headers
(to hide unwanted parts) or if we add some extra python(script) written
helpers.




2012/3/5 Dick Hollenbeck 

>
> > 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
>
>
> I like number 3).  If the SWIG definitions are not regularly built and
> tested, we can well
> imagine how they could become out of sync.  Thanks for thinking of this.
>
>
> >
> > 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
> >
>
>


-- 

Miguel Angel Ajo Pelayo
http://www.nbee.es
+34 636 52 25 69
skype: ajoajoajo
___
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

Re: [Kicad-developers] Kicad + V8/NodeJS/Swig [split from kicad ideas mail]

[Dick Hollenbeck]

On 03/05/2012 07:23 AM, Miguel Angel Ajo Pelayo wrote:
> Well, I managed to wrap the DLIST templates after fixing some strange 
> inheritance
> behaviour in swig (via %ignore directives).
>
> And everything seems to start working with the lists from BOARD object.

Congratulations!  Thanks for your work.

>
> 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?,

That question is too general.  If asked that way, then no.

> 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.

A discussion of "char*" is insufficient in itself, without being supplemented 
with a
description of the encoding scheme used to represent the full international 
character set.
Sometimes that encoding scheme is one thing and in another place it is another. 
 For
example, we have tried to achieve UTF8 encoding for all KiCad file content. 

Yet filenames on on disk in a disk directory, are encoded using the local 
encoding scheme
for that operating system and country.

wxFopen( wxStrring... ) takes care of this for us.


> For swig wrappers, it's not the same a wxPoint from our wrappers that a 
> wxPoint from the
> wx standard wrappers
> in python.

That was an unclear sentence, please rephrase the question.

(wxPoint is about as simple of a class that you can write for holding two 
datapoints, but
I don't know what question I am being asked here.)


> (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).

Not following you, maybe an example would help, more specific.

>
>
> 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

Are you saying BOARD_ACTIONs is something you need help with?  Splitting into 
DLL/DSO's?
It is not a problem to ask for help, but please let's be clear.  Your roadmap 
is missing a
couple of items that I mentioned.


>
> 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

We appreciate your help.  If the implementation is clear, the files are well 
organized and
described, then I would not over estimate YOUR burden in maintaining them.  
They would
become part of the KiCad source base and there would be help from other 
developers in
maintenance.  Ease of maintenance IS a concern, but this is influenced largely 
by choices
made during implementation.


Sorry I have not had time to look at your work yet.  I am finding little free 
time at the
moment.

Again, thanks very much.

Dick



___
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

Re: [Kicad-developers] Kicad + V8/NodeJS/Swig [split from kicad ideas mail]

[Miguel Angel Ajo Pelayo]

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:

 154PyRun_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 
>
> Hi Dick,
>
> 2012/2/27 Dick Hollenbeck 
>>
>> 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) test

Re: [Kicad-developers] Kicad + V8/NodeJS/Swig [split from kicad ideas mail]

[Miguel Angel Ajo Pelayo]

Hi Dick,

2012/2/27 Dick Hollenbeck 

> 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@lists.launchpad.net
> 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
___
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

Re: [Kicad-developers] Kicad + V8/NodeJS/Swig [split from kicad ideas mail]

[Dick Hollenbeck]

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.

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.

b) scripting language main(), for any SWIG favorite language(s).

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.



>
> It may require some hacking.

Your word, not mine.  I don't ever remember having hacked any code.  :)

> 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.


Dick



___
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

Re: [Kicad-developers] Kicad + V8/NodeJS/Swig [split from kicad ideas mail]

[Fabio Varesano]

Awesome, this is good news. In case you wanna dig more into this, I'll 
be happy to test any patch or early code development.


It's also worth noting that SWIG isn't the only way to access C/C++ 
libraries from within Python.. these are some of the other ways:

Cython http://cython.org/
Pyrex http://www.cosc.canterbury.ac.nz/greg.ewing/python/Pyrex/

Fabio

On 02/27/2012 09:14 AM, Miguel Angel Ajo Pelayo wrote:

Sorry, I ignore the "_wrapper.cxx + yyy_wrapper.cxx + etc cannot
be linked together"... swig define them as static functions, so they
can be linked together and will work. The path is not that dark ;-)



2012/2/27 Miguel Angel Ajo Pelayo mailto:miguelan...@nbee.es>>

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

It may require some hacking. 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.

So I'll keep playing until I find a good way, and then we could
really estimate the man/hours needed :-)


2012/2/25 Fabio Varesano mailto:fabio.vares...@gmail.com>>

+1 on choosing Python over LUA or JS. Blender is using Python
as scripting language and also internally.. and I guess
Blender's requirements are pretty similar to those of KiCad.



On 02/24/2012 09:22 PM, Miguel Angel Ajo Pelayo wrote:

About python, yes, I think it fits the same way lua does,
and I'm my
opinion, it has more libraries
that can be useful for the scripts (like image
manipulation, etc...).
There wasn't a branch already
trying this, how good or bad did it go?


_
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





--

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


___
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

Re: [Kicad-developers] Kicad + V8/NodeJS/Swig [split from kicad ideas mail]

[Miguel Angel Ajo Pelayo]

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

It may require some hacking. 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.

So I'll keep playing until I find a good way, and then we could really
estimate the man/hours needed :-)

2012/2/25 Fabio Varesano 

> +1 on choosing Python over LUA or JS. Blender is using Python as scripting
> language and also internally.. and I guess Blender's requirements are
> pretty similar to those of KiCad.
>
>
>
> On 02/24/2012 09:22 PM, Miguel Angel Ajo Pelayo wrote:
>
>> About python, yes, I think it fits the same way lua does, and I'm my
>> opinion, it has more libraries
>> that can be useful for the scripts (like image manipulation, etc...).
>> There wasn't a branch already
>> trying this, how good or bad did it go?
>>
>
> __**_
> 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
>



-- 

Miguel Angel Ajo Pelayo
http://www.nbee.es
+34 636 52 25 69
skype: ajoajoajo
___
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

Re: [Kicad-developers] Kicad + V8/NodeJS/Swig [split from kicad ideas mail]

[Miguel Angel Ajo Pelayo]

Sorry, I ignore the "_wrapper.cxx + yyy_wrapper.cxx + etc cannot be
linked together"... swig define them as static functions, so they can be
linked together and will work. The path is not that dark ;-)



2012/2/27 Miguel Angel Ajo Pelayo 

> 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
>
> It may require some hacking. 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.
>
> So I'll keep playing until I find a good way, and then we could really
> estimate the man/hours needed :-)
>
>
> 2012/2/25 Fabio Varesano 
>
>> +1 on choosing Python over LUA or JS. Blender is using Python as
>> scripting language and also internally.. and I guess Blender's requirements
>> are pretty similar to those of KiCad.
>>
>>
>>
>> On 02/24/2012 09:22 PM, Miguel Angel Ajo Pelayo wrote:
>>
>>> About python, yes, I think it fits the same way lua does, and I'm my
>>> opinion, it has more libraries
>>> that can be useful for the scripts (like image manipulation, etc...).
>>> There wasn't a branch already
>>> trying this, how good or bad did it go?
>>>
>>
>> __**_
>> 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
>>
>
>
>
> --
>
> 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
___
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

Re: [Kicad-developers] Kicad + V8/NodeJS/Swig [split from kicad ideas mail]

[Fabio Varesano]

+1 on choosing Python over LUA or JS. Blender is using Python as 
scripting language and also internally.. and I guess Blender's 
requirements are pretty similar to those of KiCad.



On 02/24/2012 09:22 PM, Miguel Angel Ajo Pelayo wrote:

About python, yes, I think it fits the same way lua does, and I'm my
opinion, it has more libraries
that can be useful for the scripts (like image manipulation, etc...).
There wasn't a branch already
trying this, how good or bad did it go?


___
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

Re: [Kicad-developers] Kicad + V8/NodeJS/Swig [split from kicad ideas mail]

[Miguel Angel Ajo Pelayo]

About python, yes, I think it fits the same way lua does, and I'm my
opinion, it has more libraries
that can be useful for the scripts (like image manipulation, etc...). There
wasn't a branch already
trying this, how good or bad did it go?

and about "a", honestly, I'd really like to say yes, but I still don't feel
ready, I've been looking at the
"BOARD" class and I almost had an heart attack ;-), it has a lot of
dependencies... which is normal
since it's the main object for pcbnew.

I want to keep analyzing and understanding the code, so I could estimate
how many man hours we
may need, and then I may step up, but I wouldn't want to start anything
that I cannot finish or maintain
properly.

Greetings,
Mike :-)

2012/2/24 Dick Hollenbeck 

> On 02/24/2012 12:42 PM, Miguel Angel Ajo Pelayo wrote:
> > Hehe, that can be another option, yeah!,
> >
> >I've worked with lua before, tuned the garbage collector to work in
> deeply embedded
> > devices (under 32kB of RAM) and
> > wrapped some libs by
> > hand:
> http://code.google.com/p/espardino/source/browse/#svn%2Ftrunk%2Fopenlibs%2Flua
> >
> >I think Javascript is incredibly more versatile, widely adopted, and
> easy to program
> > (also has already a couple of debuggers that can connect to the V8 lib
> and debug set by
> > step very easily).
> >
> >But, in the other hand the wx wrappers, I/O libraries, and default
> support in swig,
> > could finally make it a better candidate. It seems like a cleaner path,
> may be less
> > versatile, but cleaner at least. May be we should walk our first path
> this way.
> >
> >What do you think Dick?
>
>
> If I look at how I might weigh the various factors, in order of importance:
>
> a) Do we have qualified man hours to do any such work?
> If Miguel you step up and say yes, we have a yes here.
>
> b) licensing, seems fine.
>
> c) platform scope, seems fine.
>
> d) industry awareness and acceptance, seems fine.
>
> e) wx support, seems very fine.
>
> f) compactness, seems fine.
>
> g) impact on existing KiCad build process, probably OK.
>
>
> I don't see any drawbacks, one however could have answered many or most of
> these questions
> about python the same way?
>
> I am not opposed to LUA in any way, and at the end of the day, (a) above
> may be the most
> important.
>
> Mine is only a single opinion however.
>
> Dick
>
>


-- 

Miguel Angel Ajo Pelayo
http://www.nbee.es
+34 636 52 25 69
skype: ajoajoajo
___
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

Re: [Kicad-developers] Kicad + V8/NodeJS/Swig [split from kicad ideas mail]

[Dick Hollenbeck]

On 02/24/2012 12:42 PM, Miguel Angel Ajo Pelayo wrote:
> Hehe, that can be another option, yeah!, 
>
>I've worked with lua before, tuned the garbage collector to work in deeply 
> embedded
> devices (under 32kB of RAM) and 
> wrapped some libs by
> hand: 
> http://code.google.com/p/espardino/source/browse/#svn%2Ftrunk%2Fopenlibs%2Flua
>
>I think Javascript is incredibly more versatile, widely adopted, and easy 
> to program
> (also has already a couple of debuggers that can connect to the V8 lib and 
> debug set by
> step very easily).
>
>But, in the other hand the wx wrappers, I/O libraries, and default support 
> in swig,
> could finally make it a better candidate. It seems like a cleaner path, may 
> be less
> versatile, but cleaner at least. May be we should walk our first path this 
> way.
>
>What do you think Dick?


If I look at how I might weigh the various factors, in order of importance:

a) Do we have qualified man hours to do any such work? 
If Miguel you step up and say yes, we have a yes here.

b) licensing, seems fine.

c) platform scope, seems fine.

d) industry awareness and acceptance, seems fine.

e) wx support, seems very fine.

f) compactness, seems fine.

g) impact on existing KiCad build process, probably OK.


I don't see any drawbacks, one however could have answered many or most of 
these questions
about python the same way?

I am not opposed to LUA in any way, and at the end of the day, (a) above may be 
the most
important.

Mine is only a single opinion however.

Dick


___
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

Re: [Kicad-developers] Kicad + V8/NodeJS/Swig [split from kicad ideas mail]

[Miguel Angel Ajo Pelayo]

Hehe, that can be another option, yeah!,

   I've worked with lua before, tuned the garbage collector to work in
deeply embedded devices (under 32kB of RAM) and
wrapped some libs by hand:
http://code.google.com/p/espardino/source/browse/#svn%2Ftrunk%2Fopenlibs%2Flua

   I think Javascript is incredibly more versatile, widely adopted, and
easy to program (also has already a couple of debuggers that can connect to
the V8 lib and debug set by step very easily).

   But, in the other hand the wx wrappers, I/O libraries, and default
support in swig, could finally make it a better candidate. It seems like a
cleaner path, may be less versatile, but cleaner at least. May be we should
walk our first path this way.

   What do you think Dick?





2012/2/24 Tomasz Wlostowski 

> On 02/24/2012 08:54 AM, Miguel Angel Ajo Pelayo wrote:
>
>> Ok, I changed the topic of this thread, to match the discussion, which is
>> about making Kicad fully scriptable in Javascript.
>>
>> For speed reasons, and wide adoption, it seems that V8 must be our
>> preferred engine.
>>
> Hi Miguel,
>
> Did you consider using Lua as an alternative to JS? I've seen lots of
> applications scripted in Lua, but not too many using JS, Am Designer
> being a notable example. There are a few reasons to adopt it:
> - It's extremely small: JIT VM is ~400 kB DLL/DSO with zero external
> dependencies,
> - provides integrated I/O libraries - there's no need for additional
> frameworks in the middle, like NodeJS,
> - beats every other VMed/interpreted language at execution speed. At
> certain benchmarks, it outperforms V8 by an order of magnitude,
> - works out-of-the box with SWIG and other wrapper generators,
> - integrates nicely with wxWidgets (http://wxlua.sourceforge.net/**),
> facilitating easy GUI development for scripts.
>
> I'm not claiming that Lua should be the only scripting language available
> in Kicad, but it's certainly got some advantages over the rest :)
>
> Regards,
> Tom
>
>
>


-- 

Miguel Angel Ajo Pelayo
http://www.nbee.es
+34 636 52 25 69
skype: ajoajoajo
___
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

Re: [Kicad-developers] Kicad + V8/NodeJS/Swig [split from kicad ideas mail]

[Tomasz Wlostowski]

On 02/24/2012 08:54 AM, Miguel Angel Ajo Pelayo wrote:
Ok, I changed the topic of this thread, to match the discussion, which 
is about making Kicad fully scriptable in Javascript.


For speed reasons, and wide adoption, it seems that V8 must be 
our preferred engine.

Hi Miguel,

Did you consider using Lua as an alternative to JS? I've seen lots of 
applications scripted in Lua, but not too many using JS, Am Designer 
being a notable example. There are a few reasons to adopt it:
- It's extremely small: JIT VM is ~400 kB DLL/DSO with zero external 
dependencies,
- provides integrated I/O libraries - there's no need for additional 
frameworks in the middle, like NodeJS,
- beats every other VMed/interpreted language at execution speed. At 
certain benchmarks, it outperforms V8 by an order of magnitude,

- works out-of-the box with SWIG and other wrapper generators,
- integrates nicely with wxWidgets (http://wxlua.sourceforge.net/), 
facilitating easy GUI development for scripts.


I'm not claiming that Lua should be the only scripting language 
available in Kicad, but it's certainly got some advantages over the rest :)


Regards,
Tom



___
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

Re: [Kicad-developers] Kicad + V8/NodeJS/Swig [split from kicad ideas mail]

[Miguel Angel Ajo Pelayo]

2012/2/24 Dick Hollenbeck 

> Thanks Miguel.  Can you clearly state the the SWIG support for V8, which
> is still external
> to the SWIG project, is ready for production use?  Or do you still have
> doubts?
>

As I said in some previous email, it needs heavy testing, that I will do
:-)


> That was the original question.
>

I know but wanted to think first what could really do with an scripting
language.


>
> I also appreciate the use cases being identified up front.  I noticed you
> also did not say
> we should try and drive the UI from a scripting language.
>

I didn't think about it. But it could be interesting to have (at least)
some kind of user interface libraries accessible from javascript, so the
user could enter information or details to the script.
May be opening an HTML navigator and serving in the background could be an
easy approach (even if we din't offer any UI functionalities for the
scripting at first)


>
> This is interesting work, and I would eventually like to be able to offer
> more of my time
> on this particular topic.  However at this moment, my time is limited.  I
> do feel that I
> am very qualified to offer help.  I have written an entire Java Virtual
> Machine myself,
> including a JNI layer.  Sold it on the open market for a couple of years,
> back in the
> 90's, pre-JIT period.  This was the 2nd Java Virtual Machine ever written,
> and it has a
> real time incremental garbage collector in it.   I have embedded it into
> C++, call it from
> C++, it calls C++, and all this.  I know what it takes to package
> something like this,
> support it, and debug it.   It still runs in factories all over the world.
>  All this to
> say that I could offer qualified help with this if I had time or financial
> incentive.
>

Wow, it seems like a lot of work and expertise :-) JNI layer is the one
used to talk with native code, right? .

 I'm also short of time, but it's a really interesting "subproject" for
which I'd like to find some time.


> If I were to be able to spend more time on this.  I certainly would not be
> in a hurry to
> rush to a solution, since any quality implementation requires enough up
> front research to
> first establish the best path, and in today's world with so many open
> source projects to
> look at, that is a non-trivial effort.
>

Yes, we may think, design, and think in advance before taking any path,
because if we finally do, it's a lot of effort to put on it.


> Quite a few questions need to be answered and here are only a couple:
>
> a) should we be concerned about supporting more than one scripting
> language, or will it be
> sufficient to support only one?  This decision has a big impact on how you
> build
> infrastructure.
>

I suppose, that, if the SWIG approach works properly, we could do it for
many languages. Anyway, as resources/time are scarce, probably we may
target only one language, keeping in mind that we may like to try with
other languages later.

I like the JS approach, as it's quite widespread adopted.


> b) Is the scripting language sufficiently easier to use than C++?  Because
> another path
> would be to put a C++ compiler and build environment out in the cloud,
> where a guy could
> write his script in C++, HTTP POST it to a website, and get a DLL/DSO
> back, ready to run.
> This is your "script" in binary.  (This one is a setup for the next
> question.)
>


For sure, at least in my experience, anything is much faster to develop in
javascript than C++,
no class definitions, no headers, just code. Of course, it's a little bit
slower than C/C++.

I don't like the remote compilation support, it requires: a) to mantain a
server for it b) or the user to have a compiler (with all libs an headers)
installed. c) to run the resulting dll/dso which may have dependence
problems (if it's not static, of course). d) to keep an internet connection
to run new scripts.


>
> c) What kind of security holes to you open up when you down load
> (scripting) code from
> third parties, and is it our job to be concerned about those?
>

I think that it's the same case of using software compiled by others or any
script you download from the internet. The user can always check the code
before executing.

And anyway, as the user don't runs the code as root, nothing "too bad" may
happen.



>
> d) ..
>
>
> Scripting is not at the top of my priority list at this time.  Therefore I
> will not be
> able to offer any assistance at this time, but probably will be able to
> later, and might
> have time to offer some advice from time to time now, but even that will
> be limited

.
>
> Thanks for your enthusiasm.
>
>
It's a pleasure,

Greetings!! :-)

I will keep you updated about my tests with swig-js.

>
>
>
>
>
> > Ok, I changed the topic of this thread, to match the discussion, which
> is about making
> > Kicad fully scriptable in Javascript.
> >
> > For speed reasons, and wide adoption, it seems that V8 must be our
> preferred engine.
> >
> > V8 comes just with the java

Re: [Kicad-developers] Kicad + V8/NodeJS/Swig [split from kicad ideas mail]

[Dick Hollenbeck]

Thanks Miguel.  Can you clearly state the the SWIG support for V8, which is 
still external
to the SWIG project, is ready for production use?  Or do you still have doubts?

That was the original question. 

I also appreciate the use cases being identified up front.  I noticed you also 
did not say
we should try and drive the UI from a scripting language.

This is interesting work, and I would eventually like to be able to offer more 
of my time
on this particular topic.  However at this moment, my time is limited.  I do 
feel that I
am very qualified to offer help.  I have written an entire Java Virtual Machine 
myself,
including a JNI layer.  Sold it on the open market for a couple of years, back 
in the
90's, pre-JIT period.  This was the 2nd Java Virtual Machine ever written, and 
it has a
real time incremental garbage collector in it.   I have embedded it into C++, 
call it from
C++, it calls C++, and all this.  I know what it takes to package something 
like this,
support it, and debug it.   It still runs in factories all over the world.  All 
this to
say that I could offer qualified help with this if I had time or financial 
incentive.

If I were to be able to spend more time on this.  I certainly would not be in a 
hurry to
rush to a solution, since any quality implementation requires enough up front 
research to
first establish the best path, and in today's world with so many open source 
projects to
look at, that is a non-trivial effort.

Quite a few questions need to be answered and here are only a couple:

a) should we be concerned about supporting more than one scripting language, or 
will it be
sufficient to support only one?  This decision has a big impact on how you build
infrastructure.

b) Is the scripting language sufficiently easier to use than C++?  Because 
another path
would be to put a C++ compiler and build environment out in the cloud, where a 
guy could
write his script in C++, HTTP POST it to a website, and get a DLL/DSO back, 
ready to run. 
This is your "script" in binary.  (This one is a setup for the next question.)

c) What kind of security holes to you open up when you down load (scripting) 
code from
third parties, and is it our job to be concerned about those?

d) ..


Scripting is not at the top of my priority list at this time.  Therefore I will 
not be
able to offer any assistance at this time, but probably will be able to later, 
and might
have time to offer some advice from time to time now, but even that will be 
limited.

Thanks for your enthusiasm.

Dick





> Ok, I changed the topic of this thread, to match the discussion, which is 
> about making
> Kicad fully scriptable in Javascript.
>
> For speed reasons, and wide adoption, it seems that V8 must be our preferred 
> engine.
>
> V8 comes just with the javascript JIT interpreter, and no more. It's ready to 
> link
> agains your library or applications, it can be debugged with a remote 
> connection, but it
> doesn't include *any* system access library, networking, just nothing.
>
> In V8, you register functions which can be accessed from javascript to C++, 
> and you can
> also call Javascript code from C++
>
> Here is where NodeJS seems attractive: it adds many system and network access 
> layers.
> It's not ready out of the box to be embedded in other applications, but it 
> could be
> easily patched for that (already checked the code). 
>
> Anyway nodejs's implementation (I think) wouldn't match just any 
> architecture, it's
> something we should study carefully:
>
>1) It's ready for asynchronous operations (like most javascript code). 
>  [
> see http://nodejs.org/docs/latest/api/fs.html#fs.writeFile ]
>2) It's internal flow (in one thread) is done like this (simplified):
>a) Init V8
>b) Add all nodejs C++ functions.
>c) Load "node.js" part (some % of the code is just in 
> javascript, which
> makes sense).
>d) Enter the event loop   "while(notexit) { process_events(); 
> }" <--- not
> exactly like this, but you can get the underlaying idea.
>
>
> With this architecture, if we wanted to work with nodeJS , we may need to 
> launch a
> separate thread for the node.js interpreter (note, this is now V8 handles 
> threaded host
> apps: http://markmail.org/message/uxqpvsbc7sw7qntl) 
>
> Then we may need to define clearly how to work in this situation:
>
> 0) The ideas of Dick, about making a big library, would be nice, becaouse we 
> could use
> nodejs to work directly with kicad schematics, pcbs, etc, even without the 
> interface
> itself, in this case I don't find any problem.
>
> 1) now, when the interface is around: when we needed to call some JS 
> programmed function
> from kicad, we could simply pass the code to V8, and setup a callback that 
> would unlock
> us back, and lock ourselves waiting for the callback  [danger: we could 
> lock forever
> if the js code never unlock us back, solution: timeout?]
>
> 2) more danger