X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com X-TCPREMOTEIP: 207.224.51.38 X-Authenticated-UID: jpd AT noqsi DOT com Content-Type: multipart/signed; boundary="Apple-Mail=_A04BC94D-DCDF-4A2C-841C-27A5F4760B08"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: [geda-user] Project leadership (design error in the core of gschem) X-Pgp-Agent: GPGMail 2.5.2 From: John Doty In-Reply-To: Date: Tue, 29 Dec 2015 12:35:19 -0700 Message-Id: <449C2A4A-814E-4858-ACB3-82807A80BE8A@noqsi.com> References: <43CC8F96-6452-40FA-9DFB-E0983721C19C AT noqsi DOT com> <20151229094603 DOT 782092b57563336883546bfd AT gmail DOT com> To: geda-user AT delorie DOT com X-Mailer: Apple Mail (2.1878.6) 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 Precedence: bulk --Apple-Mail=_A04BC94D-DCDF-4A2C-841C-27A5F4760B08 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Dec 29, 2015, at 9:39 AM, Evan Foss (evanfoss AT gmail DOT com) [via = geda-user AT delorie DOT com] wrote: > 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] > 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. ... >>=20 >> It would be good if you could bring the design erros forward. >=20 > 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. >=20 > 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. I did this ad-hoc a few months ago with Osmond, and it wasn=92t hard. = The required tool is one that puts the netlist in a =93canonical=94 = form, with connections sorted and assigned names of anonymous nets = removed. Then, you just do an old-fashioned diff. One thing on my todo list is to make a gnetlist plugin that renames = anonymous nets based on the first pin it sees in a sorted list of = connections. This would give such nets stable names as long as their = connections don=92t change. This would be useful in a variety of flows, = I think. >=20 > nets vs connections: > libgeda and gschem are only allowed to understand connections and even > then in a limited way. Limits to the smarts of the tool are good. Make the tool understand too = much and it gets in the 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. You can=92t imagine doing this with a specialized tool? > 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. Functionality that gets in the way more often than it helps. > 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). Annotation is good and useful. Back annotation is problematic. Back in = the early days of programming, assemblers used to back-annotate source = code with the object code. That caused more problems than it solved. >=20 > 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. >=20 > 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. You want an integrated tool, not a toolkit. KiCAD, not gEDA. >=20 > 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) While I see scripts as production tools. The basis of automation, = allowing me to avoid the GUI altogether when appropriate. Type =93make=94,= and three minutes later have all netlists and BOMs built. data = integrated into PDF documentation via LaTeX, for a 3500 component = project. Geda-gaf scales up to real automation very well, without = forcing you to do it in any rigid way. >=20 > I want C plugins in libgeda it would make moving code that is a cool > plugin into the core easier. Fighting the paradigm. We have Scheme. That=92s what it=92s for. Now, = Roland aspires to make Xorn the universal foundation for such things, so = maybe you should work with him. >=20 > (Side note: Vladimir I saw your feature request for a scheme > interaction window. I actually think that is very cool.) >=20 > 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. I=92m a gey-haired refugee from the punch card era with three active = braincells left. If can use it, why can=92t an actual programmer use it? > It is also bad for long term maintenance because the > number of available scheme programmers is small and getting smaller. Lisp is having a resurgence with Clojure. Scheme isn=92t really that = different from other Lisp dialects. We really only use a small subset of = it. >=20 > 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. Deep down in stable code that shouldn=92t need much change. >=20 > 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. I think most of us agree that the slotting mechanism is flawed. This is = the kind of thing we should be doing with Scheme plug-ins. A related = problem is the model that gnet-drc2 imposes on designs. I have been = working on improving DRC (gnet-check-duplicates and = gnet-check-pincount). I think there=92s way too much ambition among developers to change our = solid, proven geda-gaf foundations. There=92s too little appreciation of = what they=92re capable of if you use them instead of fighting them. = Thus, there=92s too little ambition to add tools and scripts atop them. >=20 > 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. I just do that with pins2gsch. Draw a small box for the FPGA, with a bus = running to it. For my most recent project, the connections are extracted = from the Vivado export, so when the FPGA designer scrambles pins on me, = it automagically propagates to the netlist. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ jpd AT noqsi DOT com --Apple-Mail=_A04BC94D-DCDF-4A2C-841C-27A5F4760B08 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJWguB3AAoJEF1Aj/0UKykRenQP/3nsWCfWYNiI0CrALAR0x3l9 198AzGwuBON8y8kif6/5BfLoj2v7WjpJ3SBzQ2H1j1X7NJrGc66w7stUTQceIN9R ALuWluJXTwA6xJMmV9r2we5Liw2FYiK8ua5pPeB8k/CsrmZmH0Wu5+ISbylkXhrU +Nt2Sty2cc4qUCaxgq8068hmrYHfk+e32kauKCQpenKyPoD+BL7ysO8/aLI+dp0A Jop4msdOF3xAeZGdFqZ6C6oTAv6Qf6uCkjlq4RlLO0fsY3vQDvc7MOCbEH4t7ME/ da2V4680NzPJMZtRThArWGqjRxxGnQ1wJSXkatvN8DNsdUzp4dpoD8pVBHKVvTxF 2YBxz5XxiHpU5d7BL0ppId7uSormVkYVNFyJQrZUaktQHU8fOIq2bsJvSv+WVAZC o1LPw2daWg6F8DZ0BiVtpSjb7oTrPzlo2a61BeXgv6S22UZwuGMh/3nVar943IYE rFrxo6/rVxvHuwajALQSKexPq4w0c6rM6UpQ04b8UHg/bZMCQSawk/VTmnsWDo2N YQxoFVtOK6XXLon4VTcwcKZDgwCRbqLlGqMVHXYz2Lo4y/5lDoAEFe2hdqzqzQ6s yidtyeAw6j0q7beMQSkXUwmwMXcvMPY3WwUwuajxrypaH79yekwXMHeC/q2RsdIb RbjN+HK7UrgVh2OvIfjb =WUdv -----END PGP SIGNATURE----- --Apple-Mail=_A04BC94D-DCDF-4A2C-841C-27A5F4760B08--