Guile, a Scheme implementation that's part of the GNU project, recently put out a new 2.0 release with many exciting new features and improvements.
gEDA relies on Guile for extensibility. In the past we have had a few problems moving to new versions of Guile, often due to differences between memory management APIs or library functions.
I first started looking at Guile 2.0 support in gEDA in December 2010. At the time, I had great difficulty getting libgeda to work due to differences in the debugging APIs between Guile 1.8 and 2.0. However, during January I did a considerable amount of work on how Scheme errors are reported in libgeda, and as part of that I managed to do things in a way compatible with both versions of Guile.
Last Friday I was therefore able to get gEDA fully working with Guile 2.0. Actually, the main remaining obstacle was that the new version of Guile is much stricter about correct Scheme syntax, and some of the gnetlist backends needed fixing up.
But that's done, and gEDA is now fully compatible with Guile 2.0 and can take advantage of the performance improvements it brings!
What's next for me in terms of gEDA development? Well, I still have several different development branches on the go, and I'm not sure which of them (if any) to focus on.
- I have a branch which extensively refactors, extends and improves the libgeda scheme API, with the intention of making it possible to write much more fully-featured plugins & extensions for gschem and gnetlist.
- I have done a lot of work on splitting the cairo rendering code out of gschem into a separate library called libgedacairo, in order to make it easier to write applications that display gEDA schematics or convert them to other graphics formats. (As part of of this work, I'm also modifying gschem to take advantage of the GTK+ printing APIs).
- I have a design for a new configuration system for gEDA, which is non-executable and can provide per-schematic-page configuration. This is intended to remove a security flaw in gEDA at the moment when opening designs received from others.
Or are there other, more urgent things that need work? let me know what you think.
4 comments:
1. Seems high importance relative the discussion of fixing up gschem to allow plugins control of back and forward annotation and lossless translations.
I am wanting to contribute some gschem refactoring after studying your new code and guile/scheme. Fixing some of the guile/scheme strictness problems would be a good start. Suggestions on that? I can only take on small chunks of work at this time.
Fortunately, the language strictness problems are now fixed in the default install AFAIK.
There are a lot of big challenges in gschem refactoring -- I'll try and have a look at the state of the code and give you a few suggestions at some point during the coming week.
A vote for #1. The API for dealing with gEDA data (sch/sym officially) is a, um, community-wide barrier, perceived and actual, to contribution.
Pretty non-visible work for sure, but IMO at the core for moving gEDA forward.
Thanks for your work so far!
Another vote for #1. It's the single most important thing for gEDA right now.
Without it, moving forward is
basically impossible. I myself have some work based on your guile-scheme-api branch and can't wait to see it merged to master.
Post a Comment