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=_823A7EF1-9AD1-4DEE-960F-DAB269E765D1"; 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 21:58:01 -0700 Message-Id: References: <43CC8F96-6452-40FA-9DFB-E0983721C19C AT noqsi DOT com> <20151229094603 DOT 782092b57563336883546bfd AT gmail DOT com> <449C2A4A-814E-4858-ACB3-82807A80BE8A AT noqsi 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=_823A7EF1-9AD1-4DEE-960F-DAB269E765D1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Dec 29, 2015, at 9:17 PM, gedau AT igor2 DOT repo DOT hu wrote: >=20 >=20 > On Tue, 29 Dec 2015, Evan Foss (evanfoss AT gmail DOT com) [via = geda-user AT delorie DOT com] wrote: >=20 >> On Tue, Dec 29, 2015 at 2:35 PM, John Doty wrote: >>>=20 >>> On Dec 29, 2015, at 9:39 AM, Evan Foss (evanfoss AT gmail DOT com) [via = geda-user AT delorie DOT com] wrote: >>>=20 >>>> 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. >>>=20 >>> I did this ad-hoc a few months ago with Osmond, and it wasn?t hard. = The required tool is one that puts the netlist in a ?canonical? form, = with connections sorted and assigned names of anonymous nets removed. = Then, you just do an old-fashioned diff. >>>=20 >>> 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?t change. This would be useful in a variety of flows, I = think. >>=20 >> Sorry, nothing will get me to adopt a flow that breaks manually named = nets. >>=20 >>>>=20 >>>> nets vs connections: >>>> libgeda and gschem are only allowed to understand connections and = even >>>> then in a limited way. >>>=20 >>> Limits to the smarts of the tool are good. Make the tool understand = too much and it gets in the way. >>=20 >> We already talked about this. I am going to skip over it to avoid >> re-re-re-hash. (i did go back and check how many re's to use here) >>=20 >>>> 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. >>>=20 >>> You can?t imagine doing this with a specialized tool? >>=20 >> The order of events to back notate. >>=20 >> 1. PCB exports a netlist (which I will call the backward netlist) >> 2. diff of forward and backward netlists >> 3. gnetlist generates a list of changes to connections >> 4. gschem takes the changes and lets the user implement or disregard = them. >>=20 >> If that seems amilliar it is because this is mostly what Igor2 did. >> Igor2 had PCB run more of it but still. >=20 > Nope, my approach is totally different. >=20 > 1. PCB exports a set of commands (I call it a patch) An interface. Good. Is it documented? >=20 > 2. gschem loads the patch and provides a "search" function that assist = the user to manually change the schematics so that it doesn't contradict = the patch >=20 > I quickly abandoned trying to go with netlists, because I wanted to = back annotate attribute changes as well (such as footprint changes). The = patch says things like: >=20 > - "pin 1 of U4 should not be connected to net Vcc" >=20 > - "pin 1 of U4 should be connected to net Gnd" >=20 > - "the value of footprint attribute of U4 should be dip(8)" >=20 > So the "search" functionality in gschem is really searching for items = on the patch that do not match the features of schematics currently = open. >=20 > Disclaimers for John (because I know he will repeat his agenda = anyway): >=20 > - I fully undrerstand your way of manual diffing, but I do not like = it; if I already use a GUI for editing the schematics, I do want the GUI = to assist me with the changes. OK. Perhaps a tool could generate your patch from the diff. I note that when I did this recently for a fairly drastically revised = layout I expected it to be harder than it turned out to be. The layout = guy had condensed a microcontroller and an FPGA into one thing, with the = associated changes in support fungus, and a couple of other changes he = hadn=92t mentioned (but his netlist revealed). The lack of GUI support = was a concern. But doing it from the diff was was easier than I = expected. >=20 > - the method is generic, not limit to the PCB flow or any specific = flow; in any flow the user can produce such patches; like tuning = resistor values after simulation Layout tools can often generate an output netlist and BOM, but few will = be able to directly generate your patch file. So, some way to get from = those to your patch file are required to make this truly generic. A = common netlist/bom format with a canonical form (so equivalent netlists = would be identical) would be a useful intermediate. >=20 > - I know that some parts could have been done by piping everything = through gnetlist backwards, but I simply don't see any benefit. No, the = "toolit vs. integrated" slogan does not work here (my current approach = does not integrate anything either). >=20 > - all parts are done in forks, so your Holy Workflow and Holy Version = are not affected by lame features noone would force you to use anyway. = (Although I strongly believe it's you who should make a fork and freeze = your Holy Version and leave others alone to go on fixing bugs and adding = missing features.) >=20 >>=20 >> Why run so much through gnetlist? Because you won't let use endow >> libgeda with an understanding of netlists and to map the changes back >> the other way we need that. >=20 > With the format I use, we don't. My approahc has its limitations too, = but as I'll discuss later, these are rather the limitations of how = gschem doesn't want to know about nets, not even via the netlist infra. >=20 >=20 >>>> 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. >>>=20 >>> Functionality that gets in the way more often than it helps. >>=20 >> You are right but the code is there and it works. (Igor2 proved it) >=20 > Also, John, you are confusing two things. One thing is a generic C = function that can list all direct connections of an object. This can not = "get in your way more often than it helps" because you never get to see = it as an user. Why are you not using the Scheme scripting that Peter Brett worked so = hard to make useful? >=20 > The other thing is what exactly happens when you click on a net. The overloading of that is a problem in the current GUI. > It's a GUI question, a decision, has nothing to do with libgeda. Or = with the topic we are discussing. >=20 >=20 >>>> 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). >>>=20 >>> 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 >> You just compared Apples to Asparagus. >=20 > A better comparison: I run a binary program that hits an assert() or = aborts and dumps core. Looking at the core and fixing the source is back = annotation. For this, I want the binary side tools (a debugger), and the = source code side tools (a text editor). The text editor needs a = functions like "jump to line N". For this, it needs to understand what a = "line" is. This makes it less general as if it didn't have to assume = things like special meaning of newlines, but such is life. >=20 > Gschem can not "jump to a network". For me, it is exactly the same as = if a text editor couldn't jump to a line. I do undrestand the = background, I do understand that all network related smartness is = exported into the netlist infrastructure, and it's all fine. But then = why gschem doesn't ask the netlist infra? Or why the netlist engine = doesn't generate an ".lst" (staying with the object example) gschem can = read? And why gschem tries to understand slotting in the first place, = and doesn't leave it for the netlister? >=20 > I am an user of gschem. Whatever flows you use, whatever flows I use, = please do not try to convince me that I don't need to locate a network = by name in my design. All the work that Peter did was intended to help users like you and me = make our own customizations to gschem and publish them without stepping = on each other. So, why are you not exploiting this? > It just won't work. Not being able to get the GUI identify some of the = most basic building blocks is just plain wrong, no matter what the = architectural reason is. Not even if John will surely hurry to mislabel = this as an "integrated vs. toolkit" issue. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ jpd AT noqsi DOT com --Apple-Mail=_823A7EF1-9AD1-4DEE-960F-DAB269E765D1 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 iQIcBAEBCgAGBQJWg2RZAAoJEF1Aj/0UKykRRh8P/293jirqqv60FtISgkKlzMW9 jPYRuNRkKuhi6A3XVhExcwRyOLXsWmgBeEEszhqqA5Wn/3+prCL9lrwv9m2SxVYB G/quWJqUMwdX3qw4ROF3JrCQ2eFjEpXUrHlHqPHw32CBFPQtb6EexBuiMhltPWTT Ygd6ETZlAhxbfcHyfi7PjHgZ7lU92x+z5n+ASkTm4JHUv//zDPRJr40Zc4W5tufv ptZZVTDLS6YXFjRZE6YPAcNwCU8STy5u2xIqyWKUhqLHaR6ZVgaNgqsFHHm354YX TJ3qRlb0YP7cvhWxVUiZzJr6st4ObCSX0gK/Jp2iXUkh6AKX8lKZbCox3WbEPb9Q EVmk5rYQmwsxAjfSiQJ5lsRtAtboJECFwr407NQWpjA4oly60je//aR80SvXAmm7 zLRSy0PWWG25QVeKgDyVIXhkwdqT7AN3kATcglMQSuEcQy2D2667or4JAvpLd00I 51UbE5Hcex7EJQwafEM+0MDnWZmgilh4Yn7EqdR7fQy0h8NXpL9Bbtgf6zOhKNdl N/pVAn4uG8N+VK0motQ735kQtzErOPHxX6RG4DhGQrpTvq5a/GS97NX7aNboMt4K HC+a/oBcV8JP9uPS5kN/xTTxI7LVc8Dtfto5AaExHF8qsk5YSZGbGVTpHS0mHgI3 UTwBSlAT69a84Ug5csSb =j5D7 -----END PGP SIGNATURE----- --Apple-Mail=_823A7EF1-9AD1-4DEE-960F-DAB269E765D1--