Mail Archives: geda-user/2012/10/26/11:40:13
On Oct 26, 2012, at 1:00 AM, Gareth Edwards wrote:
>>
>> To a large extent, the gEDA action has moved to gedasymbols.org, which has grown to 32 MB of stuff (symbols, footprints, scripts, simulation models, ...). That's a tremendous community contribution, and I think that's where the biggest opportunities to contribute are.
>
> Sure, there's great work going on over there. But you yourself feel
> that gaf is not enough for you that you've forked it to lambda-geda,
> so you clearly think there is work to be done. So do I.
lambda-geda is Matt's work, not mine. I'm merely a user. It's not in any sense a fork. It's an independent tool for scripting schematic transformations that the regular tools cannot perform. At the moment, it can only transform hierarchical schematics into flattened schematics, but no other gEDA tool can do this. That's the toolkit approach: when you need a new capability, write a new tool. Don't "fix" things that aren't broken.
I absolutely agree that there's more work to be done. Take a look at github.com/noqsi/gnet-spice-noqsi. Not a fork of gnet-spice or gnet-spice-sdb, but a complete rewrite. Unlike previous efforts, this back end allows the user to create simulation netlists from the same schematics that the layout netlist comes from. It works: I'm using it. The code could use a couple of tweaks, but what I mostly need to do now is put together a simple demonstration project, and real documentation (for gEDA/SPICE experts, the README may suffice).
It would be nice to combine the two projects above: lambda-geda understands how to track down the sources of a hierarchical schematic, so it could drive gnet-spice-noqsi in the automatic creation of a proper hierarchical SPICE netlist. Right now, that must be manually scripted, most conveniently with a makefile.
But these things are external developments, requiring no new work on the core tools at all. It seems to me that gschem and gnetlist have reached a state of near perfection within their architectural limitations. The schematic file format itself is isomorphic to S-expressions (but friendlier to classic line-oriented text utilities), with unlimited flexibility, so no changes are needed or desirable.
I can see somebody writing a new schematic editor using 21st century GUI conventions, but it wouldn't be gschem, it would be a new development. I can see somebody writing a more flexible netlister than gnetlist, but it would need a new architecture and would not be gnetlist any more (somebody could in principle develop lambda-geda in that direction, but Haskell isn't the most user-friendly language).
John Doty Noqsi Aerospace, Ltd.
http://www.noqsi.com/
jpd AT noqsi DOT com
- Raw text -