1) The scheme front end and supports the initialization of the gaf programs. Where, symbols are found and in what order libraries are searched etc. This works ok and there obviously is a lot of work that just doesn't need to be redone. My take support it for now it isn't very hard to work through each one and make sure that the new g_netlist.c supports each of the existing scripts. To replace these scripts would require understanding each format that you are creating a new control for. I havn't the time or desire.
2) The scheme back end supports a lot of formats. these also work and rewritting them will take a lot of time. 3) The main code of gnetlist and libgeda is fairly convoluted. Data structures that support a wide number of objects have all the data structures for each object. There isn't a uniform set of functions for manipulating each of the basic data structures. To add new features it takes a long time to learn the flow of the code. 4) Re-organizing the data structures, making sure each data structure has a fairly similar set of common functions and a documented set of specific functions should make understanding the code much easier. 5) Making use of gtk libraries for the manipulation of expandable strings and double linked lists should improve the robustness of the code. For example, I completely eliminated the use of malloc and free and replaced these with g_new, g_free and the GString, Glist allocators and destructors. 6) Anyone who wants to replace scheme can do so and put on what ever wrapper they like. 7) Anyone who wants to attach what ever additional libraries they like can also do so. 8) I would appreciate constructive critisim about the current state of cleanup I would welcome additional cleanup especially of the library portions that are ment to support gschem. Enjoy, Steve Meier Peter TB Brett wrote: > On Thursday 01 March 2007 03:19:10 Dan McMahill wrote: > > >> I'd see this actually as an opportunity to build the internal database >> in a good way and then provide a more sane and complete scheme api for >> accessing the database. >> > > The way it's currently mapped out in my head: > > - libgeda provides a C API for doing stuff like netlisting. > > - the API is designed to be easy to write bindings for > > - bindings can then be written in <LANGUAGE>, but gnetlist & friends could > easily be kept for backwards-compatibility. > > I'm a big fan of removing Guile from libgeda's dependencies, and providing an > API to do the things that Scheme is currently used for. This means my Python > BOM/inventory management program won't have to pull in the whole of Guile > *and* Python every time it starts up. > > Peter > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > geda-dev mailing list > [email protected] > http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev > _______________________________________________ geda-dev mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
