Steve Meier wrote:
Dan,
1) compatability with most of the current back ends is one of the goals.
2) gnetman looks interesting and if I understand it it drags in datadraw
with it. I would propose looking at integrating gnetman as schem
function calls and what ever gnetman does with datadraw is ok by me. At
least for the time being.
Thanks,
Steve M.
What datadraw does is it lets you describe your database in relatively
simple terms and then it compiles this description into c code that
implements all of the underlying database code including all the
{de,}constructors, and accessors. The bad part is if you want to do a
full recompile from the true source you need to have datadraw installed
to convert the datadraw input file into the c code. Also the generated
code can be pretty big. Note that the generated code should not be
interpreted as code which should then be parsed or edited by a person,
it is compiler output where the output happens to be in c. The good
news is that if you distribute the generated c code along with the
datadraw input files, then the end user doesn't actually need datadraw.
The penalty is just the size of the distfile.
It really seems that the right approach is to build on gnetman
(actually, by this I mean the database schema defined for gnetman) as
the internal database. It was designed by someone who has lots of
experience and it is powerful enough and scales well enough to support
very large (chip-scale not just board scale) designs. Then you could
have scheme backends which use scheme calls that are just wrappers
around the datadraw functions.
I guess what I'd hate to see is a lot of work put into improving
gnetlist (which needs improving) only to find that the underlying
database structure and methods for accessing it still aren't complete
enough, fast enough, or scalable enough.
All that said, I'm very happy to see someone working on gnetlist!
-Dan
.
Dan McMahill wrote:
Steve Meier wrote:
I have been keeping silent about this. But I am in the process of a
major rewrite of the netlist program. In this process, I folded libgeda
into my code base with the intent of eventually extracting it again in
some form or another.
My work has
1) rewritten the struct.h data structures.
2) rewritten large amounts of the code for supporting these data
structures. Including attempts to keep the api consistent from object
structure to object structure.
3) rewritten the netlist algorythms
4) made heavy use of GList and GString data structures from gtk
This new netlister, currently supports hierarchical buses. It is capable
of exporting net lists for pcb and almost for PADS-PCB from mentor
graphics. It also supports a BOM generator.
There are numerous bugs that still must be fixed (embeded symbols arn't
supported and must be). But I would request that those interested in a
clean up of the data structures and API to please take a look.
Thanks,
Steve Meier
I have several questions.
It sounds like this is incompatible with gnetlist and the 20 some odd
backends we have?
Any consideration to taking advantage of gnetman and datadraw now that
datadraw is much more accessable?
I think these first two are fairly important. The first because we
have a lot of functionality there and the second because Bill Cox has
had quite a bit of experience in dealing with code that processes
large hierarchical netlists and it seems like something well worth
taking advantage of.
Is there still an interpreted backend to make it easy for end users to
come up with their own netlisters?
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.
-Dan
_______________________________________________
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
_______________________________________________
geda-dev mailing list
[email protected]
http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
