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:content-transfer-encoding;
	bh=7A3aYibRg+JRg54diY1ndZhLgaBxti79/fwpbk2cyaE=;
	b=YVwi/Z6wuvVEG8l5g9jibTlSr8d06TUQwe1Wak/6dDVBhC23A2ak3trVkX+YB6V8lq
	xjrUOOoKDOC22cygksv89G4jBMy6019ZHUyz+Ch5aZgt4NpMIxQgvbITb420N7F9sKtg
	KfprMV0t8PcRE46DHJqyYT9oMTLoRcWPAufpNWNBwre7DwoW49Q6MEmqWHvE6pM2LMmS
	yckK62OlGIVLZPOOy74FIpeIAJ/lBe9yoTE3D/AkGPfleK9ow65Y4S45WW5NfbiepFrK
	7f3RhjwhqdN3GERVM6B3P1tR37l/UPABEVn1EvySrfgZYNJP+BTeDZEm6zE4LHcPqqnq
	RQ5Q==
MIME-Version:	1.0
X-Received:	by 10.112.130.195 with SMTP id og3mr6970132lbb.69.1445475027237;
	Wed, 21 Oct 2015 17:50:27 -0700 (PDT)
In-Reply-To:	<73ED29DA-968B-4675-9B00-125E03683C9B@noqsi.com>
References:	<1042003D-82E2-40F0-AB60-8186580C46AD AT noqsi DOT com>
	<34B17816-9EA5-45FD-BFB4-9D623A8D3D87 AT noqsi DOT com>
	<CAM2RGhR+K+dvDdXsbk0Y6LN=-7RhhG5wvtG4i0k4+uMgzd=H0w AT mail DOT gmail DOT com>
	<201510210954 DOT 46552 DOT ad252 AT freeelectron DOT net>
	<CAM2RGhTg=nT4aXqdiRz+OmHJ3WiMJntiTZyOH3AdFBZ8dEyT4w AT mail DOT gmail DOT com>
	<DA7D969B-6516-4633-831C-FFADA38E1807 AT noqsi DOT com>
	<CAM2RGhRN5S1KZCNFQwoVTPg3=mC5xrK2z9XTOpWwPuF0iVS+Rg AT mail DOT gmail DOT com>
	<73ED29DA-968B-4675-9B00-125E03683C9B AT noqsi DOT com>
Date:	Thu, 22 Oct 2015 00:50:27 +0000
Message-ID:	<CAM2RGhSvpVvboJ-gdyrojAzggFEBnAr30CKNQBefjci-PA1n6g@mail.gmail.com>
Subject:	Re: [geda-user] A lesson from gnet-makefile
From:	"Evan Foss (evanfoss AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
To:	gEDA users mailing list <geda-user AT delorie DOT com>
X-MIME-Autoconverted:	from quoted-printable to 8bit by delorie.com id t9M0oboR031454
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 Wed, Oct 21, 2015 at 10:49 PM, John Doty <jpd AT noqsi DOT com> wrote:
>
> On Oct 21, 2015, at 12:41 PM, Evan Foss (evanfoss AT gmail DOT com) [via geda-user AT delorie DOT com] <geda-user AT delorie DOT com> wrote:
>
>> The only changes that can not be undone are too user expectations.
>> We need a regression testing suite for the gnetlist backends.
>
> There’s the beginning of such a thing at geda-gaf/gnetlist/tests/. Netlister regression checking is tricky, though, as there’s much ambiguity. There are generally many ways to write equivalent netlists. A back end designed specifically for regression testing of the gnetlist API could be a good thing.

Yes there are multiple ways to parse the same content but I find it
hard to believe that there are really ways to make the backends behave
non-deterministically.

>> What
>> also needs to happen is added documentation of all the workflows we
>> support so that a list of what a user/developer can expect is made.
>
> What about future workflows?

At least if we have documentation for what is there now we can avoid
this recurring theme of "but X proposal will break Y workflow" which
somehow seems to appear in almost every discussion. Besides there are
as you admitted in your message some limitations that already exist as
a part of how geda works.

>> * Every list of connected pins can have a netname but it is not required.
>> * A list of connections can only have one netname.
>
> This one is hard to check, because a checking script only sees one name for the net, regardless.

I see that hair you just split. There is no valid use case for a net
having more than one name.

>> * Using the same netname twice with out showing a visual connection
>> still creates a valid connection.
>> * Every pin has to have a pinnumber.
>
> Those are implicit in the design, hard to change, I think, so yes.
>
>> * Pins may not have duplicate numbers.
>
> More precisely, netlisting is troublesome unless there is at most one instance of a given (refdes pinnumber) pair in the design. However, if the back end asks the right question, it can see the duplicates and determine how they connect. This might be useful for interchangeable pins.
>
> We have tools for checking “rules”, but they work relative to their designers’ models of the flow. We have seen that these do not apply to every flow. And every once in while some crazy person wants something completely unanticipated by the developers (like a graphical Makefile generator ;-). It’s thus the gnetlist core’s job to present the data to the backend, not to enforce rules.

You call them crazy while saying we should cater to them? This is
particularly odd as you are the one constantly digging up workflows no
one has considered before.

>>
>> I assume there is little if any vagueness left in the backend documentation.
>
> You enjoy making jokes, don’t you? ツ

I have no idea what you are talking about.

> John Doty              Noqsi Aerospace, Ltd.
> http://www.noqsi.com/
> jpd AT noqsi DOT com
>
>



-- 
Home
http://evanfoss.googlepages.com/
Work
http://forge.abcd.harvard.edu/gf/project/epl_engineering/wiki/

- Raw text -