geda-developers team mailing list archive

[Peter Clifton <pcjc2@xxxxxxxxx>]

On Tue, 2012-12-18 at 19:58 +0000, Peter TB Brett wrote:

> We should also adopt as many good ideas as possible from other EDA
> tools, like e.g. Upverter (which appears to use operational
> transformations, i.e. a very good idea) [2].

That might be a nice way to do local multi-process editing of the same
document. The nasty complex theory stuff needs to get abstracted away
though, as it may need someone smarter them me to understand the compsci
details! (The wikipedia page is intimidating at first glance).


> Additionally, see this (also incomplete) diagram [3].  You can tell it
> is old because it doesn't include polygons. ;-)

I remember that ;)

The key controversial idea there which differs from gEDA is relating to
attributes.

PLEASE can we make attributes a fundamental property, and the text
representation thereof DISTINCT! ???


> Comments?  Anything I've missed?

One day I want to write a 3D kernel... one day. Thinking about the size
of the challenge, I figured that I (and a small team) could never beat
the professionals whilst playing catch-up on implementing lucratively
profitable technology which has been in highly funded development for 20
+ years.

So... lets not copy the commercial EDA packages, lets think
unconventionally about the problems we are trying to solve and do
something different.

With the size team we have, we will need to work smart - not hard. If
that means high-level languages, I'll grudgingly admit that is sensible.

FWIW, the 3D CAD stuff I've been thinking around at the moment mostly
centres on designing a data-centric, dependency aware micro-task
scheduler. (That might be blue sky management speak for me suggesting I
solve the meta-problem around the real issue... that I don't know how a
3D CAD kernel should be structured ;)).

Anyway though, once the system gets big and complex enough - the
structure of the system becomes an important design issue in its own
right.

I figured using LLVM as the magic glue to bind a scheduler, + various
algorithmic bits together would be useful. Perhaps not required for
gEDA / libeda / etc.. though.


Anyway.. I think concurrent programming is the way forward for any kind
of data-based tasks in the future.


Regards,

-- 
Peter Clifton <peter.clifton@xxxxxxxxxxxxxxxxxxxxxxxxx>

Clifton Electronics