Peter -- I'm all in favor of getting rid of guile and replacing it with TinyScheme! Guile has been a major PITA for gEDA because it is a strange dependency not present on many virgin distro installs. It also sucks in a lot of strange dependencies, none of them having anything to do with electronics. But using guile forces our users to find and install these dependencies.
Also, the folks hacking guile have no interest in maintaining backwards compatability; their API changes have broken gEDA many times. You're doing the right thing to get rid of guile. It's just good practice to have as few dependencies as possible, and to control as much code as possible. Please count me as one vote in favor of ditching guile. Stuart On Mon, 25 Aug 2008, Peter TB Brett wrote: > 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 > _______________________________________________ geda-dev mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
