kicad-developers team mailing list archive

[Miguel Angel Ajo Pelayo <miguelangel@xxxxxxx>]

I need to spend some time understanding your idea of design, right now I'm
a little bit lost,
but I started by the "simple" part, which was building the swig-js branch,
and it seems
that I managed to do it (it was only ready for WIN32) but I have a patch
for swig-js that
seems to work in linux (partially)...

I was able to generate the example for:

https://github.com/oliver----/swig-js/blob/master/src/Examples/jsv8/class/example.h

and it seems to link to standard libv8 from ubuntu, and run. (It compiled
it's own v8, but it was standard one, no patches).

I think I will try to cleanup the build, and then publishing it.

The swig-js is built using CMake (I'm quite experienced on it) so I could
need some help ':-)




2012/2/22 Dick Hollenbeck <dick@xxxxxxxxxxx>

> On 02/22/2012 09:11 AM, Miguel Angel Ajo Pelayo wrote:
> > I think I could put some efforts on testing it, and see how well the
> "JS" branch of swig
> > does work.
> >
> > Do we have an idea of which interface we may want to give to the
> scripting layers?,
> > access to PCB objects, modules, tracks, etc?
>
> To keep it simple, let me talk about PCBNEW only *for now* (duplicate the
> discussion in
> your mind for EESCHEMA).
>
> class BOARD, and the needed significant objects contained within it.  I
> say needed,
> because I think there is some flexibility as to where you build this
> bridge, either in the
> class BOARD by accessor augmentation in C++ go give access to everything
> there, or by
> SWIGing out the contained classes.
>
> We also talked about moving the non-UI member functions that are now in
> PCB_BASE_FRAME,
> PCB_EDIT_FRAME, into a class which is purely for significant actions but
> with NO UI, like
> plotting, annotating, etc.  The UI portion (meaning the preceding dialog
> invocation) would
> stay out of this class.  conceptually lets call this class BOARD_ACTIONS.
>  All the
> functions in BOARD_ACTIONS take enough parameters to operation *without
> any UI*, by
> definition.
>
>
>
> BOARD_ACTIONS could then be transported into two realms:
>
> a) back into PCB_*_FRAME by multiple inheritance, so you are back to where
> you started
> from with respect to PCB_EDIT_FRAME.
>
> b) into the top of a scripting entry point DLL/DSO.
>
>
> Along with this, it might be useful to try and build a PCBNEW DLL/DSO that
> has the public
> BOARD_ACTIONS, and BOARD entry points exposed.
> The actual PCBNEW program (where main() is), could be a thin layer with
> linked with the UI
> (mostly dialogs and wxFrames).
>
> The plotting and drawing functions themselves might have to be yet a
> separate DLL/DSO.
> Since your BOARD_ACTIONS might actually have to plot or print.
>
> We are finally getting in a position to be able to do this, reduction of
> globals has been
> an enabler in this effort.  There is some more work to do.  We still have
> a number of
> globals, and getting the separation into BOARD_ACTIONS would be some work.
>
> This design I think deals with both the paradigms:
>
> a) scripting calls C++ actions, and
> b) C++ calls scripting, since these calls from C++ would be from the upper
> main() area,
> and you could still call BOARD_ACTIONS and BOARD from the script.
>
> It just does not however deal with the letting the script control the UI.
>  I think that is
> significantly more work, and is probably best done in C++ forever.
>
> I don't anticipate that this would take under two days to do.
>
> :) read carefully now.
>
> Dick
>
>
>
> >
> >
> >
> > 2012/2/22 Dick Hollenbeck <dick@xxxxxxxxxxx <mailto:dick@xxxxxxxxxxx>>
> >
> >     On 02/17/2012 08:56 AM, Miguel Angel Ajo Pelayo wrote:
> >     > Hi Dick,
> >     >
> >     >    Thanks for your feedback on the ideas, it's really appreciated,
> I fully understand
> >     > all of your points, as I'm on the same situation with some open
> projects and my little
> >     > company. I supposed that most of the ideas were already in your
> mind, but if I didn't
> >     > share them I wouldn't know now where do they converge with yours
> :-)
> >     >
> >     >     I really love the V8 engine, just played a little bit on
> embedded systems, and it
> >     > works incredibly fast (it does JIT of the code and you get all the
> flexibility of
> >     > javascript), and nodeJS gives all the functionality needed to
> access the underlaying OS
> >     > and network, although I'm not sure if it's internal design makes
> it suitable to get
> >     > integrated in other apps.
> >     >
> >     >      I'm also using SWIG to build interfaces to many languages,
> and it works incredibly
> >     > well. I must test the swig-js and see how mature is.
> >
> >     We will be interested in finding out what you learn.  JavaScript
> seems to have a lot of
> >     momentum now, and it needs to be looked at in detail.
> >
> >     With HTML5 giving it new life on the client, NodeJS giving it
> further life on the
> >     server,
> >     its C++ like syntax, its standardization by a standards body, it has
> a lot going for it.
> >
> >     And for any one not already knowing a language, one is comforted by
> the fact that
> >     learning
> >     it might serve a real purpose in other areas, (like when you go
> design your next
> >     webpage.)
> >
> >     Dick
> >
> >
> >     >
> >     >     Personally, I'd like to give "some blood" on the project as
> soon as I can and get
> >     > familiar with kicad's code/design :-)
> >     >
> >     >     Cheers,
> >     > Mike
> >
> >
> >     > Two weeks ago I looked into adding support for V8.  V8 is google's
> javascript
> >     engine and
> >     >
> >     >     they use it under the chrome browser.  (You may already have a
> copy on your disk
> >     >     now.)  V8
> >     >     is very fast.  There is another project that sits on top of V8
> called node.js.
> >     >      node.js is
> >     >     great at writing asynchronous webservers, and has been shown
> to actually be
> >     faster than
> >     >     apache in some circumstances.
> >     >
> >     >     My measurement of doing it manually said that it is a lot of
> work.  However
> >     since then I
> >     >     see some folks are trying to add the binding generation
> functionality to SWIG.
> >      SWIG can
> >     >     generate bindings for a number of languages, in theory.
> >     >
> >     >
> >     >
> http://comments.gmane.org/gmane.comp.programming.swig.devel/20373
> >     >     https://github.com/oliver----/swig-js
> >     >
> >     >     This is an ancillary project, and not integrated into core
> SWIG from what I can
> >     tell.
> >     >
> >     >     node.js has gathered so much momentum that it is actually
> changing the choice of
> >     >     languages
> >     >     used on the server side for many web applications.  There are
> two reasons for this
> >     >     that I
> >     >     can see:  a) node.js on top of V8 is fast.  b) being able to
> use javascript
> >     both on the
> >     >     client side and server side is attractive to many developers.
> >     >
> >
> >
> >
> >
> >
> > --
> >
> > 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