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 <[email protected]> Clifton Electronics -- Mailing list: https://launchpad.net/~geda-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~geda-developers More help : https://help.launchpad.net/ListHelp
