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=wiQikHkethTWhSK4Cpi+mkIaaMGsWj1MaylOlRhAeic=; b=GbABxGrBfKhlOkNzqM8jVKs6Od0peXrdSCywPdNhYPj6zZDOexjdBV+1nSNX2JBr8Y MewGn+AYeJ9qGRgL1QjJv7SqjyFI38iw8W6Kyy8Ku2JX4nToRfip10oUGL2NSewt2VcJ bM57IfUBeKKPiLWe8Zh2Cb8WsVk9LzhvP/yyAIbUqLQ/kOqGIsvEJsxRuww2CLrnwO1M a/T1wq9roYPSKCstSMDudDnLgnrRD2DWLQgMMgvTYNvo9rxzaMl3zFBUFhhm12TRbXrp FSqj6sBf6S+RdqgFvHTzNZjVvxt0BwLd7gKMaqAQN/4saiyVjqe7+CWyXXxSOoQJZ6lH zeKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=wiQikHkethTWhSK4Cpi+mkIaaMGsWj1MaylOlRhAeic=; b=G+KeZ4j45hf1/zNAIGKScnMVp7xFGVHHWfkFx9CQqlEjE688tz/x1h1XEV1n3tsKgy lw1JKpfAkXu/vw7Kmh4nRmQ+p0S5jOaFXsd1EIsEWfaovbvZav4CU0/iuchjfzYsZDAY YqYeaETjEPG/yS5lHIGBiwlxlVonmFZzcV7OEg8hXq35q+F21UON0BAlzwYKpJ9waubP 52jmsU2RLRrdKCc7jUPV/X45u4hhYs6Qq1C97GdVm+rOGhroxfDoieZeIlhIqjKury1U PfOkFJkbvXhJ6fD7Io8Ps/BqmsL7gARSlbVBaPK4xZVdEU3jKQwgxglX6c9yT9UwyO4R o4yw== X-Gm-Message-State: AG10YORspS2B4xopTuntT5vA9Gg9bStFS0yh9vflRjQPNNkQQl7Is15wQWf9DrHB9b4ZA8WfNhpl5DmJ8eV0aA== MIME-Version: 1.0 X-Received: by 10.28.98.198 with SMTP id w189mr17471934wmb.39.1453200790194; Tue, 19 Jan 2016 02:53:10 -0800 (PST) In-Reply-To: <20160119091756.B960981053DB@turkos.aspodata.se> References: <20151218205019 DOT 1C1FF809D78C AT turkos DOT aspodata DOT se> <20151223141117 DOT D51F6809D795 AT turkos DOT aspodata DOT se> <20151230211705 DOT GE4099 AT localhost DOT localdomain> <20151231021429 DOT EE320809D79B AT turkos DOT aspodata DOT se> <20151231185752 DOT 78437809D79A AT turkos DOT aspodata DOT se> <20151231191107 DOT BCADE809D79A AT turkos DOT aspodata DOT se> <20160119091756 DOT B960981053DB AT turkos DOT aspodata DOT se> Date: Tue, 19 Jan 2016 13:53:09 +0300 Message-ID: Subject: Re: [geda-user] gnetlist -g partlist3 in error From: "Vladimir Zhbanov (vzhbanov AT gmail DOT com) [via geda-user AT delorie DOT com]" To: geda-user AT delorie DOT com Content-Type: text/plain; charset=UTF-8 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 Karl, ... >> I'm working on the fix for this bug. > > Do you know where the problem is ? The issue was in incorrect post-processing function you've mentioned. It used the 'member' function that gave incorrect result if the list contained a searched record twice. I've written other functions for sorting and am planning to replace the current ones with them. Didn't yet decided how to do this better. As of now, the code in my 'parts' branch on github seem to be working, though since it is a draft, it needs much rewriting and commenting before pushing upstream. > >> Meanwhile, seeing your gnetlist output, I have a question to >> all using the gnetlist partslist* backends: >> >> - Would it be better to upcase or downcase the device= attributes? >> Otherwise, depending on sorted values, we have, e.g. "Resistor" >> or "resistor" in various rows, which is probably not "the Right >> Thing". I believe devices should be sorted case-insensitively >> and output uppercase. > > "Ideally we should change all sym's". > > In the printouts I made, I gravitated towards camelcase with initial > capital for the device attribute to keep columns short. Like in: > > DiodeSchottky sod323_nxp_a.fp RB751V40 16 D3 D4 D5 D6 D7 > D8 D9 D10 D11 D12 D13 D15 D17 D19 D21 D23 > DiodeZener SOD80 3.3V 6 D14 D16 D18 > D20 D22 D24 > Driver DIP16 ST232ECN 1 sU1 > Inductor bi_hm78d_128.fp 2720uH 2 5L1 acL1 > Mechanical fibox_tempo_TA191209T_4p.fp OBO_T60 1 M1 > Memory so_08_a.fp MB85RC16V 1 U5 > OpAmp so_14_a.fp TS514AID 2 U2 U4 > PwrLinReg sot23_5.fp NCP700BSN3.3V 1 3U1 > PwrLinReg to220.fp 7812 1 U3 > PwrLinReg to220.fp LM317 1 pU1 > PwrLinReg to220.fp LM337 1 nU1 > PwrSwReg so_08_a.fp MC33063 2 5U1 acU1 > Resistor m1608_a.fp 2.2 1 acRsc1 > OK, I see, though some of our "canonical" device names are upper case while other are lower case, and I have found that some backends (e.g. spice-sdb) sometimes use case-sensitive comparison functions for them. Therefore, things get worse, in order to make my netlists compatible with most of the backends I have to use different letter case in different cases (sorry for the pun :)) So probably the case sensitive sorting would be better for the device= attributes. > if you upcase it, it would look a little thick: > > DIODESCHOTTKY sod323_nxp_a.fp RB751V40 16 D3 D4 D5 D6 D7 > D8 D9 D10 D11 D12 D13 D15 D17 D19 D21 D23 > DIODEZENER SOD80 3.3V 6 D14 D16 D18 > D20 D22 D24 > DRIVER DIP16 ST232ECN 1 sU1 > INDUCTOR bi_hm78d_128.fp 2720uH 2 5L1 acL1 > MECHANICAL fibox_tempo_TA191209T_4p.fp OBO_T60 1 M1 > MEMORY so_08_a.fp MB85RC16V 1 U5 > OPAMP so_14_a.fp TS514AID 2 U2 U4 > PWRLINREG sot23_5.fp NCP700BSN3.3V 1 3U1 > PWRLINREG to220.fp 7812 1 U3 > PWRLINREG to220.fp LM317 1 pU1 > PWRLINREG to220.fp LM337 1 nU1 > PWRSWREG so_08_a.fp MC33063 2 5U1 acU1 > RESISTOR m1608_a.fp 2.2 1 acRsc1 > > maybe its best to let the user handle that. He/she can change device > attributs to suit his/her taste. We would have to revisit all the current geda code then (see above). And internally we would still be forced to use case sensitive comparisons. At least until the backend API will be stable and documented somewhere. > > But I do think the output should not have its case changed. Then we could not join "Resistor 10k" and "resistor 10k" and count them together in some cases. > > If you want to change anything, wouldn't it be better to have a separate > sch/sym beautifier script ? Why not? However, at least basic things have to be done well. > > /// > > Have you considered the way I sorted the values, like in: > > Capacitor m1608_a.fp 18p 2 C4 C5 > Capacitor m2012_a.fp 330p 2 5C2 acC2 > Capacitor m2012_a.fp 10n 2 3C2 C14 > Capacitor m2012_a.fp 100n 13 C6 C7 C8 C9 > C10 C12 C13 C15 C17 sC1 sC2 sC3 sC4 > Capacitor m2012_a.fp 1u 7 3C1 3C3 C16 > nC1 nC2 pC1 pC2 > Capacitor m3216_a.fp 10u 1 C11 > ... > Resistor m1608_a.fp 2.2 1 acRsc1 > Resistor m1608_a.fp 3.3 1 5Rsc1 > Resistor m1608_a.fp 100 1 nRb3 > Resistor m1608_a.fp 330 3 R9 nRb2 pRt1 > Resistor m1608_a.fp 470 2 R3 pRt2 > Resistor m1608_a.fp 680 3 R1 R5 R7 > Resistor m1608_a.fp 1k 13 R2 R4 R6 R8 > R11 R17 R18 R19 R20 R21 R22 acRt3 nRt1 > Resistor m1608_a.fp 3.3k 3 R10 R14 R16 > Resistor m1608_a.fp 6.8k 2 R13 R15 > Resistor m1608_a.fp 10k 8 5Rb1 R12 R23 > R24 acRb1 nRb1 pRb1 pRb3 > Resistor m1608_a.fp 15k 2 5Rt1 5Rt2 > Resistor m1608_a.fp 33k 1 acRt2 > Resistor m1608_a.fp 47k 1 pRb2 > Resistor m1608_a.fp 100k 1 acRt1 > > instead of purely alfabetical ? > You could also possible merge say 1000 and 1k, and align the col. at > the decimal point, as in > > 2.2 > 100 > 3.3k > 47k > I've written different functions for different attributes. Refdeses, for instance are transformed to lists of strings and numbers, which are compared in order. Values are converted into numbers like you've proposed. However, I consider aligning by point to be superfluous (at least a feature request ;)) because some programs (LaTeX) would do this much better. > And it would be nice if columns lined up as in first example above. > The same. I believe this is a business for some post-processing program, since we just output a TSV lists. Thanks, Vladimir