Mail Archives: geda-user/2018/07/11/02:40:26
On Wed, 11 Jul 2018, gedau AT igor2 DOT repo DOT hu wrote:
> There was a long discussion about this issue on the mailing list years ago,
> some time between 2011 and 2013.
Hah, I've found it! It was late 2012. Let's see some archeology.
The thread started here:
http://www.delorie.com/archives/browse.cgi?p=geda-user/2012/12/04/12:35:10
of course this simple bugreport got derailed and quickly escalated into a
haystack of random ideas on short circuit indication. I found it hard to
follow all the ideas with the same subject line, so I decided to organize
them. This was an early version of my summary on all proposals:
http://www.delorie.com/archives/browse.cgi?p=geda-user/2012/12/14/05:38:19
This was my proposal for mincut, backed up with prototype code:
http://www.delorie.com/archives/browse.cgi?p=geda-user/2012/12/13/09:27:49
And the rest of the story: for a while it got positive feedback from pcb
devs, but then we bumped into "ok, but we first need to rewrite [some API
and code in] find.c". None of the other proposals got any prototype or
production code from anyone, as far as I can tell. I leaned back waiting
for the said find.c rewrite.
So let's see what happened to mincut, the only proposal that had a
prototype:
Time went by and nothing happened. I eventually forked and added mincut in
pcb-rnd without any major find.c rewrite - so I stopped pushing it in
mainline. (Although before 2016 I invested a lot of time doing my pcb-rnd
development in a way mainline could apply the patches. Looking back,
seeing the result, I think this was a pure waste of time)
This adventure with mincut was very useful for pcb-rnd: it helped me
realize how important it is to modularize the code (happend to pcb-rnd in
from 2013, by now we have less code in core than in plugins) so that
features can be implemented in core plugins with minimal impact on core.
This lets contributors with such ideas do their code in pcb-rnd without
risking stability and without having to wait for
yet-another-big-refactoring. Core plugins don't bitrot as easily as
external plugins, so we could upgrade core APIs ever since, without having
to worry too much. In fact we could do the whole data model
redesign/rewrite, spanning about 1.5 years, while other parts of the code
could also develop.
About find.c: incidentally, at pcb-rnd we are getting to a point where we
are really preparing for a full rewrite of find.c, for other reasons,
mainly because the new data model will allow us to provide a much simpler
implementation. It may happen this year, or if not, then probably next
year.
About Levente, who started the original thread: after an annual flame war
on file formats he started a pcb-rewrite effort, based on sqlite. But
that didn't get far and later on he abandoned geda and switched to kicad.
That project was: https://github.com/leventelist/apollon
(Since that my efforts in pcb-rnd proved my point that our proplems came
from the data model, not from the file formats or how exactly we store our
data in memory).
Regards,
Igor2
- Raw text -