delorie.com/archives/browse.cgi   search  
Mail Archives: geda-user/2015/12/29/11:39:50

X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
X-Original-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:content-type;
bh=SVI1rwl2fC9ITrZH77B6CEjiuCGxFeU5d66FFldeZTA=;
b=SNjsyt/qdC316PWDBeuA8klT/ibTqIBUkNWP5jnsyDEybLbzaMaVqi1wg0s6doSzb3
ToTX5x6KmLd4cpwAYOuD9oIZsLSQOLbFJ8OKmM+CrnJMKoR5RYk3wpzzGMt/PL6b6tnH
I+4cDl0X5zLDFxHGTYTSZBZS60PBPO9mbr6Yv8aZRHLctLFzDvyQHTWHYehhPx4dw1VL
ADbFHElX2uXLy6F1DdFYbl8cxMO1jiBQj83LvkMF64FRbdNraAMMw3HKaIVueGf5PKyP
OrmJqFYApfu4oD1nHiAaYXyf6dHDX1h0yp8IcjMd2G1BsiVuAAZp5MJSoWNYu4b1g9jg
u0XQ==
MIME-Version: 1.0
X-Received: by 10.25.83.209 with SMTP id h200mr2736667lfb.129.1451407172012;
Tue, 29 Dec 2015 08:39:32 -0800 (PST)
In-Reply-To: <20151229094603.782092b57563336883546bfd@gmail.com>
References: <CAJXU7q_3XwthnN_8mp7B+-ShHeK+=7J=54ZavKBUG3S3bSKp2A AT mail DOT gmail DOT com>
<CANEvwqiM7CKG+WpDRpG4L=HsmSEZ32=CBDyUhuk3ks-SNedL2Q AT mail DOT gmail DOT com>
<43CC8F96-6452-40FA-9DFB-E0983721C19C AT noqsi DOT com>
<alpine DOT DEB DOT 2 DOT 00 DOT 1512290406210 DOT 9035 AT igor2priv>
<20151229094603 DOT 782092b57563336883546bfd AT gmail DOT com>
Date: Tue, 29 Dec 2015 11:39:31 -0500
Message-ID: <CAM2RGhQ363RydhBJKMnNX5sLOkD1K4qVwb-PPwov3MT3D6MfdQ@mail.gmail.com>
Subject: Re: [geda-user] Project leadership (design error in the core of gschem)
From: "Evan Foss (evanfoss AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
To: gEDA users mailing list <geda-user AT delorie DOT com>
Reply-To: geda-user AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: geda-user AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com

On Tue, Dec 29, 2015 at 3:46 AM, Nicklas Karlsson
(nicklas DOT karlsson17 AT gmail DOT com) [via geda-user AT delorie DOT com]
<geda-user AT delorie DOT com> wrote:
>> My personal opinion, especially after actually hacking the code for back
>> annotation, is that there are design errors in the very core of gschem.
>> A few smallish things that makes life harder in probably most flows,
>> makes essential UI features impossible to implement. ...
>
> It would be good if you could bring the design erros forward.

I think Igor2 already said of this in the last thread that he wanted
to avoid saying because of the flamewar that would follow. I am a bit
more rested so I will kick the bees nest in his place.

gnetlist's one way functionality :
gnetlist lets you take a schematic (which in libgeda world is a list
of connections) and make a netlist but it won't let you take a netlist
and map those nets back to connections on the schematic. PCB can be
made to export a netlist. Ideally gnetlist would take a list of
changes to a netlist or two netlists (old and back annotated) and spit
out a list of changes to connections that you could carry over to
gschem.

nets vs connections:
libgeda and gschem are only allowed to understand connections and even
then in a limited way. To make back annotation work you ether have to
fix the problem above or let libgeda/gschem understand that a list of
connections is associated to a given net in the netlist. Right now
gschem almost has this because there is a highlight functionality that
lets you select a whole net and unintentionally maps the connections
in the process. I debated this one with John a while back. It was
particularly hard to deal with because John fundamentally does not
want back annotation/notation unless it is via some his script(s).

Basically I see value in not forcing every thing to make nets and
connections equivalent *but* more of the the mechanism that grants
them equivalence should be available in libgeda so the whole suite can
use it more easily and not just gnetlist.

connections vs buses:
Because we don't want to acknowledge connections are in any way
equivalent to nets we also can't group nets and call them a bus. The
inability to group them in this way leads to the inability to do cool
things like set properties for a whole bus when you go to rout a board
or do a simulation.

scripts:
I see scripts as having a few flavors. Throw away, project specific,
and prototype. The first two are mostly self explanatory but the last
one (prototype) I thought was how we were to see how the user
experience would be if we did X to the core. We are generating a low
of the first two and almost never any of the third. Even when it does
happen massive opposition hits when X new idea is suggested as an
addition to the core of geda (libgeda)

I want C plugins in libgeda it would make moving code that is a cool
plugin into the core easier.

(Side note: Vladimir I saw your feature request for a scheme
interaction window. I actually think that is very cool.)

scheme is good and bad:
The effect of having scheme drive things in geda instead of just as a
language was good in that it bent the programming style of C code
contributions into a cleaner form than we might otherwise have had. It
is bad though because having scheme drive C makes a lot of C
programmers nuts. It is also bad for long term maintenance because the
number of available scheme programmers is small and getting smaller.

clunky use of glib:
I don't like the way glists are used in libgeda. I accept glib as a
dependency because glib is also used by gtk and geda is gtk heavy but
still. If we ever put a hid on geda like we have on pcb it would be
nice to remove that dependency.

slots:
The slotting mechanism is fundamentally worthless for a the majority
of cases were I would want to use it. Look at the 7400 symbols were
they have a whole extra symbol for the power pins. That is
conceptually IMHO something that should be a slot but you can't do
that because all symbols have to have the same number of pins and
geometry.

In places were slotting could be cool we don't use it right in the
standard symbol library. Take the symbols for the larger xilinx chips.
I would rather each section of the chips I/O be it's own slot so I can
show the FPGA connections near what they are connected too instead of
putting the FPGA on it's own page (most of the time). Likewise
breaking it up into more symbols would mean not wasting most of a page
on the empty area inside the FPGA symbol.


-- 
Home
http://evanfoss.googlepages.com/
Work
http://forge.abcd.harvard.edu/gf/project/epl_engineering/wiki/

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v2

mQENBFYy4RYBCAC183JomLtbdAlcKiaPDoVHq52LDmVmH75aiEc69m7YxDt54/ai
VtYCAobbGVIyn3Hlz3uhF6LnPl/6Lm1VdnCfpwu3KQhCO6ds10ow2C30X4ohCqOd
hCVg5C+ILmQkEffFrFODy3ji+PYTF4pADvHCWsTMv0hf0llwFOJsBCK6cl02IffE
JPqy4PjM1nZ9HpzT84JBaG/4OGvTZ8SQ2yFUl265jagvygPTf88H1xpZHH1r8dB1
stjUHLmPH8AOyDgKxFchgGeDc3p/vJtgDDIXAFfDXG0NSRovLmtaQdGxe47Zf/go
bXiEM7YL2WqQe5zfEA919JxkEwlDKYniOSVzABEBAAG0N0V2YW4gRm9zcyAoVGhp
cyBpcyBteSBwdWJsaWMga2V5LikgPGV2YW5mb3NzQGdtYWlsLmNvbT6JATkEEwEC
ACMFAlYy4RYCGwMHCwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCIpQTcE8nN
bbBaCACAm8pU5lG1ev2Fsw68Axtcl57SJrYieqX96c3YuYH9JpqMqJRnd9nDKw9X
tQuvuH7tUk0VbOaDqReOYJVI/4c5wb9AaOFp6K2DUcupq6XhgXpvz3HzoPwjAdIj
XuQzdRUx5+innTJrSkGuBYW/CZ2zqEx4xfLlq4rO0hoTUMR8QVp2cCrkw6BT0m86
APIw/ZnjoxM8IEzr7MxfRIg3qpzrZk28rmhx+k78Jyk61UhwcCPGIm/pjUopTwYJ
3YBdRB2cYD2aN7A1JVf5cRmSQYooHBGpH0kYvomGk97PKqypVuJ7OpG9xM58wUcC
qUVt9hKlePLzP8csYjt8onqI7qIIuQENBFYy4RYBCADlH8spG3WkCx62vB5mr5Z0
SCDd/RcyA4A5y5EOj5KurQkrSWpgi9Ho1yKruMJ6blQR2qkc66KqH9pnXDm/ZI1M
K/wdW3ngETxBmXoozzFMT89aEWIVR5/PFodWK1elekE9iJxACuR98Zg2QttTD3x8
A9w8VEyMLOXcDTrPFpHegMKswFBg5iuMulAdXAoGejWTI3n+qKFpabHm2Lfs6wjk
5rjucpTdeFK6UeWF1xAvNxXibuu5BlGwv53930qIXRwO/Gn2Rh5DXWxKU2fEIme/
xgQQmIsDeUoWbfybdjw/x7Q0LW4mINiLDQcGHHRQKFIxbAJCT3USPLGh5xwE9/Er
ABEBAAGJAR8EGAECAAkFAlYy4RYCGwwACgkQiKUE3BPJzW0uYAf9Hf30n8tM3mR2
Zo6ESE0ivgdgjaJtAWrBUx7JzAzPjBnBOlNnu5Y9lVEqetvUPH6e3PvaHYUuaUU8
0HwxuKBW9nUprgV6uIu1DZmlcp+SxpbuCy7RDpNocRLNWWFMaYYzznmTgfnTgD4D
gCq8Mf1mcfrluTkOAo+QNqbMfl1GISClopRqxVuAo59ewgMnFujwgd8w12BwWl24
CzqOs5HqcUslePj+LzcjSNgVCklYwKl+0dsb/fctMOCtHodwqm2CBJ+zydvNmYkD
fxda/J91Z1xrah5ec++FL0L4vs+jCiIWJeupJFKlr1hCMZiiGH7W554loK5l4jv3
EY347EidAw==
=Ta4p
-----END PGP PUBLIC KEY BLOCK-----

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019