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=XjjHN75pesMUeASo6VY8gnLAf6L+3qmnmHO9rjkRkes=;
	b=cI3cmXZeOVvmRG0yrcrYT8ED6suqZhA1KY2asJ47ssdubjbFfAeoTg49QHulQ1lNya
	Eouf4QA6aJSATROtc4f0sPcDiZ1itk1RVKgjzltCR7lZ3AyQgMvpI5t2NmthmWSdcsqm
	bR293rz8c+FxVlu8UstACrHDPG1KSToT3OjOv/d2WUEFLWXeApx44i5K4U/41IENLqQb
	/ZVa/WVIli8LeFyNmhWXBunCSts45Jh2gK1eRvF4+L9CpPC0v8mhJLhmKLuF/IOLuoTc
	zATUOR91Z2xUF/5BnRIP4reWAcSvTVUq+TPoXBWrorSYt8ZVfIx2QBAqBUkQXXMsSwui
	Olng==
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=XjjHN75pesMUeASo6VY8gnLAf6L+3qmnmHO9rjkRkes=;
	b=URzxevUMoB2p1H2BnNkYlGo4vhBkUv6kdNpwGU4SPzr+dQJqzWZay3OItMGKZMlub0
	KddY1pUYxyMTmkxsRR/pdcfEMqokvxVTpOv4F6iNemmfQrv6KqNurlwcz7BM7FO6Dz38
	i/1HoELNU6lHuhDjvQTiI0sYDa0Cu2o7iKmxE0unpkkVlVFhJsxP4P0xaggvrEm1cQL2
	R1E83vfgmGquYNrzXX2gMZsr1FW9wSIQmK+aTIJMZLvm1jPShmqGCK0mFLuHws1D8Wob
	CbY/4V5dP9uPG8J7FWX63Rh2oV56AL2kiO4fKR5smHRf7+cZMNZiVRK7INLBHWmTAqkh
	AFUA==
X-Gm-Message-State:	ALoCoQmYcdBWAlmXUZEdxdJZn8gjjN3u5QYp9A4F5Jv2NV7DWa/bUFG5xn7OWi9wSpSEdS/w4Bjt4ETjOw1YPwyU4zVETChuCA==
MIME-Version:	1.0
X-Received:	by 10.194.243.6 with SMTP id wu6mr29404917wjc.14.1453212667807;
	Tue, 19 Jan 2016 06:11:07 -0800 (PST)
In-Reply-To:	<20160119123332.3A27581053DB@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>
	<CAMvDHVA+dW81TzJAkAvFnB_kaAgO9Rr4Er-QQ0rNzte1GOHgyA AT mail DOT gmail DOT com>
	<20160119123332 DOT 3A27581053DB AT turkos DOT aspodata DOT se>
Date:	Tue, 19 Jan 2016 17:11:07 +0300
Message-ID:	<CAMvDHVBo50FJFi9n-Tcvux4ZngRcvBZS2cyQENA7pODEptL9fg@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

On 1/19/16, karl AT aspodata DOT se <karl AT aspodata DOT se> wrote:
...
>> 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.
>
> Did you find out what was the strange thing about R8 = 10k:
>
>  http://www.delorie.com/archives/browse.cgi?p=geda-user/2015/12/31/14:11:23

As I already said, the processing function count-same-parts after
filtering out refdeses saw two records ("resistor"
"footprint_name" "10k") and chose the wrong one using the
'member' function after 'reverse' list. The 'member' function
returns not a record but the list tail starting from this
record. After you've changed value to 9k the records got different
and it all worked. The way of sorting/hacking the lists was
non-functional and opaque there, so I didn't dig down deeper after I
found this behaviour, though I believe it worked in some other
cases where records were in other places of the whole list (when I
saw the wrong behaviour two the same records were the first and
the last in the list).

>
>> 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.
>
> Give me a link, I can test it if you like.

The parts branch at
  https://github.com/vzh/geda-gaf

>> > 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.
>
> I think the best thing is to push that problem down to the user.

Agreed


>
>> > 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.
>
> 1, In 2010 I did one to remove numslots=0 attribute which gsymcheck
>    complains about:
>
> $ find . -type f -name \*.sym | xargs perl -i -ne 'if (m/^numslots\=0/) {
> undef($old); } else { print $old if $old; undef($old); if (m/^T /) {  $old =
> $_; } else { print; }}'

gsymcheck is broken. I have rewritten it in scheme (see the
gsymcheck branch in the above repository on github) and used as a
module for gschem to check symbols interactively. However, I won't
work on it further yet since I have some other thoughts :)

>
> 2, upcase 1st char of device attribute.

It's easy to do using Scheme, if you want, isn't it ;)

>
> Any more, do you have a list ?

No

...
> Great, I'd like to test that.

You haven't even recompile gnetlist for that. Just use something
like:

gnetlist -m ./gnetlist/scheme/*partslist*.scm -g partslist3 -o - test.sch

...
>> > 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.
>
> Hmm, maybe we could provide a postprocessor.

gnetlist is our postprocessor. You can load your custom/preferred
functions either before or after loading backends and thus change
its behaviour (e.g., using the -m option mentioned before).

Cheers,
  Vladimir

- Raw text -