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>
	<CAMvDHVAqu0Hute-JPRrxRSvy19H1cU4f0ZZ=Lu_6QZeA-q=PUA AT mail DOT gmail DOT com>
	<20160119091756 DOT B960981053DB AT turkos DOT aspodata DOT se>
Date:	Tue, 19 Jan 2016 13:53:09 +0300
Message-ID:	<CAMvDHVA+dW81TzJAkAvFnB_kaAgO9Rr4Er-QQ0rNzte1GOHgyA@mail.gmail.com>
Subject:	Re: [geda-user] gnetlist -g partlist3 in error
From:	"Vladimir Zhbanov (vzhbanov AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
To:	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

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

- Raw text -