On Thursday 21 August 2008 23:29:56 Peter TB Brett wrote: > 3. (The big one). Embedding TinyScheme into libgeda, and then ripping out > Guile. If all goes as planned, this should result in gschem, gnetlist etc > working identically from the users point of view. This stuff will be in a > branch, obviously! Check out my 'die-guile-die' branch if you want to see > the progress so far [http://repo.or.cz/w/geda-gaf/peter-b.git].
Note that my branch is HEAVILY BROKEN in its current state.
Why remove Guile
================
Guile presents a number of issues when used in a shared library:
1) Guile uses a global state. It isn't possible to have multiple totally
independent Scheme interpreters in the same program if you're using Guile.
There are some long standing issues in gschem (most notably, not being able
to have per-project component libraries coexisting in the same gschem
instance) which *cannot* be solved in a sane and maintainable way while using
Guile. [#1846542, #1846547]
2) Guile literally takes over your program -- the application must
be "wrapped" inside the Scheme interpreter. This sucks if you want to use
libgeda inside a non-gEDA app (e.g. KTechLab) to load gEDA schematics, for
example.
Guile also has quite large headers, which add significantly to gEDA's compile
time and compilation memory usage.
Why use TinyScheme
==================
It's small and BSD licensed. No other particular reason.[1]
How far I've got
================
1. Imported TinyScheme, integrated into build/install. gEDA Scheme types,
per-TOPLEVEL Scheme interpreter.
2. New per-TOPLEVEL C-based configuration API, replacing i_vars and friends.
Backwards-compatible Scheme bindings.
3. New resource-library API, based on existing clib. Used for per-TOPLEVEL
component and source libraries. Backwards-compatible Scheme bindings.
4. Tore out almost all of the Guile code in libgeda, apart from that still
used by the apps for their Guile bits.
5. (Almost) completely excised the existing Scheme API code for hooking on
events, and inspecting and modifying objects.[2]
6. Made a start on unbreaking gschem.
Diffstat (so far) is approx +9700 -4000. Yes, this is approaching fork-like
proportions.
What's left to do
=================
libgeda is just about done, apart from deleting more stuff.
1. gschem configuration. This will just be a "plug in and turn handle" job,
but will likely take a few hours to do.
2. Menus and keybindings. This will be somewhat (lots) trickier. One major
problem, as I see it, is the lack of a way of altering the menu configuration
at runtime.
3. Make sure rc file loading works properly.
4. Look at gnetlist (I'm feeling that after gschem, this will be a stroll in
the park).
5. Persuade TinyScheme to give friendly backtraces and error messages.
6. Anything else that crops up.
Possibilities this work opens up
================================
1. Extension of the config API to tracking where config settings came from.
2. Switching between different configs depending on which file you're looking
at.
3. Switching between different component libraries depending on which file
you're looking at.
4. Configuration write-back (a la Emacs customize).
I can't understate how much more sane to read and easier to write gEDA code is
when you can assume a 1:1 relationship between library state and Scheme
interpreter state.
I'm going to chill out and watch a movie now -- but even more of the same
tomorrow!
Peter
[1] I'm putting a lot of work into "compartmentalising" the code that actually
talks to the Scheme interpreter, with the aim of making it easy to tear out
and replace the interpreter again if required.
[2] I need to re-implement something similar based on TinyScheme, but I'm
going to wait until I have the time to design an API that's consistent and
intuitive. Since I *have* to ground-up rewrite it, I might as well do it
properly.
--
Peter Brett
Electronic Systems Engineer
Integral Informatics Ltd
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ geda-dev mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
