Re: gEDA-user: Functional blocks and PCB format changes

[Andrew Poelstra <asp11@xxxxxx>]

On Fri, Sep 03, 2010 at 11:00:43PM -0400, DJ Delorie wrote:
> 
> Re: functional blocks
> 
> If we contemplate changing the PCB file format, it would be nice if we
> went with something that was intrinsically extensible.  Knowing that
> the 5th element in a list with '[' means "clearance" is a bad format,
> but seeing "clearance=5mil" in a list of attributes is much better.
> We use something suitable as our menu resource, but folks have argued
> for XML too.  I don't want to bring in something as heavy and complex
> as XML, but maybe a small parser like our resource parser that "just
> happened" to use XML format would buy us some usefulness at low cost.
>

XML is far too heavy, agreed, and it's signal-to-noise ratio is abysmal.
I think that using a Lisp (or Lispy-looking) format would be extensible,
easy to parse, and make the most people happy.

Plus, it would make it very easy to manipulate PCBs in Lisp, which is
a far nicer language to work with than Perl, which AFAICT is the most
common language for gEDA hacking.
 
> For performance reasons, it might be useful to have both an ASCII and
> a compiled binary format for these, with a converter.  I've done stuff
> like this before; parsing a huge ascii file is a CPU hog compared to
> something designed to be digested by a program.
> 
> Note we already have the ability to store attributes at the layout,
> layer, and element level.  Perhaps that would be one place to hold new
> DRC rules?  If we tagged the rulesets, we could then assign those tags
> to objects on the board, although storing such tags means a file
> format change.  Maybe the new format can specify mandatory stuff as
> the first few non-tagged values (like line start/end coordinates) and
> have everything else be tagged after that (like clearance=1mm) so it's
> more free-form?  We'd need some meta-rules for specifying defaults.
>

I made another post to this list wherein I suggested structuring DRC rules
as objects in their own right: consisting of a filter (what it affects) and
a rule (what it requires).

If we tagged individual objects with rules it would be difficult to edit
rules in a systemetic way. So I don't think that's a good way to go.

 
> Re: DRC
> 
> Our DRC engine could use a complete rewrite.  It doesn't get arcs
> right, for example.  It would be nice if it told us the *actual*
> design rules used (what's the closest cross-net spacing?  Smallest
> drill?  Etc) too.
> 

Speed might be a problem, but again, Lisp would be a huge boon to this,
if only because of the immense amount of AI-related stuff out there.


> ...
> 
> Some of that work can be made easier to code if we switch to C++
> officially so we can use a real OO language instead of the OO hack we
> currently have.  There's a patch in the tracker to make the code
> C++-compatible, someone (i.e. me) needs to review it so we can get it
> committed and start seeing who'll have problems if we switch to C++.
>

C++ would be a definite improvement. However, it's a scary-huge language
and I'm not sure the pros would outweigh the cons. (Of course, it's a far
easier port than any other language would be.)

There aren't a lot of other compiled languages to consider, though, that
would do what we want with the speed that we need. What is the opinion of
D in this group?
 
> Then you could have each object know how to draw itself (or part of
> itself, usually by layers) just by foo->draw().  I don't think this is
> *needed* though.  We just need a new object type that is itself a PCB
> (or at least the PCB->Data structure, like a Buffer), a way to nest
> all the draw/find/select etc stuff, and a way to tell the GUI which
> object(s) you're editing.  That automatically gives you a footprint
> editor too :-)
> 

Agreed, but given the pain it would take to create a workable PCB object,
I think we'd be better off just going to a real OO language.

> If you'd rather work on the GUI, though, that's also a needed project.
> It would be nice if the GTK gui supported all the modern Gnome stuff,
> like dockable toolbars and menus-with-icons.  The SOW has an entry for
> that also.
> 

I really don't want to do GUI work, but I'm finding it's necessary to
developing functional blocks. Mainly because without GUI support, having
functional blocks is nearly useless.

And in the process, I'm learning Gtk and GUI development in general. And
learning is always a good thing :). For now, modernizing the entire GUI
is well beyond my abilities.


Andrew



_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user