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=FS9uTzc3Z+e8/Dub1gqB2UvE61KZfo7E+A7GqK7o8Wk=;
        b=XhF+FK982pu66+zsufJmvB+X8uh81YLZF1eMP2dq7ZdAGW4okxUZdjyG/uHOGUvs5G
         2I/5vlp9XPUUI4KVFMa21NC5GAuvRfnKkmPD2CybDOZasEqdi6D04+FMrM8eYR+DdQF0
         E7SjVrLd90/qFvDCdtV3gAS2A0tqt6Bflv+OI+TpRSAqaggF+vpaKY7Nm5mVObsq4Xcj
         GVi/U9l1qpJvgZKrPgdRbG2ODYg5wep1fLqifcPqS1ltfKJPJAK66nawz/hQQdwZXPM7
         E/ipcB8xpQAZ4Yr/gN+tj9wgH/ZNWd79oPD94oR5PWN6HMVx5cgTBF6u5ZvLU+oAazzG
         ssZA==
MIME-Version: 1.0
X-Received: by 10.25.19.155 with SMTP id 27mr114118lft.120.1444788085472; Tue,
 13 Oct 2015 19:01:25 -0700 (PDT)
In-Reply-To: <39FF6208-7D45-4DE8-9AEE-1ED1B512705B@noqsi.com>
References: <1042003D-82E2-40F0-AB60-8186580C46AD AT noqsi DOT com>
	<201510121905 DOT t9CJ5T9W026297 AT envy DOT delorie DOT com>
	<CAM2RGhTMnybSnYgnNhVZGA6PTvyJu+=Kzd5LX2HMqxT1F4LoRg AT mail DOT gmail DOT com>
	<88EA58F5-2B23-498A-9E5B-84054976DBED AT noqsi DOT com>
	<CAM2RGhTPPtqmWVa3=Kf-PeN+WS5Tn4J+D0Ri6R_4OrQOk+LFKQ AT mail DOT gmail DOT com>
	<4D3CD563-D8EE-4B2A-975A-AC2B573960FF AT noqsi DOT com>
	<CAM2RGhT8WzhwvzFx3Rfv8vN-f=i1=uWuLF+48VygSRtfdzdo-A AT mail DOT gmail DOT com>
	<34B17816-9EA5-45FD-BFB4-9D623A8D3D87 AT noqsi DOT com>
	<CAM2RGhR+K+dvDdXsbk0Y6LN=-7RhhG5wvtG4i0k4+uMgzd=H0w AT mail DOT gmail DOT com>
	<39FF6208-7D45-4DE8-9AEE-1ED1B512705B AT noqsi DOT com>
Date: Wed, 14 Oct 2015 02:01:25 +0000
Message-ID: <CAM2RGhROpz_3y2JB=xEkEQ3CMHqHJ_WZxqVrbQhP4q2mg40h8g@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>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id t9E21UCD019056
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

On Wed, Oct 14, 2015 at 12:16 AM, John Doty <jpd AT noqsi DOT com> wrote:
>
> On Oct 13, 2015, at 5:27 PM, Evan Foss (evanfoss AT gmail DOT com) [via geda-user AT delorie DOT com] <geda-user AT delorie DOT com> wrote:
>
>> We could prototype it via a plugin but in the long term it should
>> really be in the core.
>
> What advantage does that have? I see none.

Every advantage it is something that will be common among a lot of
gnetlist and other plugins. To have back notation work in the only way
done so far to not offend anyone (Igor2s fork) you need something to
map the connections. I want that to work for both the old flat nets
and the new ones. The two should be handled in as similar a way as
possible to avoid user and programmer confusion.

>> To be honest I find your "don't touch the core
>> you will break something" attitude kind of insulting.
>
> You shouldn’t be insulted. It’s like TeX: you don’t touch the core, you put everything in style files. Geda-gaf isn’t *that* well engineered, but it’s pretty good: the burden of necessity of change should be high. “If it ain’t broke, don’t fix it” is just good engineering.

I think you should consider the number of times I have been in that
minority of people agreeing with you. I don't start by assuming other
people are wrong.

You assume I am going to be like a bull in a china cabinet. I
deliberately declined to have direct commit privileges. If my code is
going to the mainline it will I expect have to get a review. Given how
open we are to other peoples ideas here getting past that will ensure
a level of quality no lower than any previous work.

For my contributions I will be glad to write tests of them. We should
have a larger regression testing framework though.

> Despite Peter Brett’s great work, we simply don’t have the tests necessary to insure that changes to the core don’t affect somebody’s flow.

It depends on how people choose to use what I want to add. It simply
being there is not going to break flows. Obviously some thought has to
be put into how these attributes but that is all decided after this.

> Geda-gaf can do all sorts of things (even generate makefiles ;-). Can you guarantee that you won’t disturb this? I absolutely don’t want a tool paralyzed by the interactions of added features.

(yes thanks again for the makefile thing i hope it has the effect i
was expecting)

Everywhere the original flat model exists people should have the
option of the new one. The key word being *option*. I am not about to
try to remove the old s_conn stuff just build something else next to
it.

*If* something is going to create a paralysing set of interactions
then it would be because this new code was being improperly used in
gnetlist or where ever else. The real issues around this are about how
it should be used not where in the codebase it resides.

> I recall an attempt by a core developer to make SPICE netlisting better that broke slotting for layout. He shouldn’t have put a SPICE-specific feature in the core: there were better ways to solve the problem. I would hope that our more mature project wouldn’t release a blunder that bad, but more subtle problems cannot be excluded.

This is silly. It is a parallel mechanism for mapping connections.
Functions that are there for other people to call from gnetlist via
scheme and in a gschem plugin (once it gets plugins) to handle things
like backwards notation. Now if people choose to not call the function
it will just sit there. I am not out to go re-write what is already
there just add on to it.

>> I am not out to
>> change how we have kept the concept of connections in libgeda and nets
>> in gnetlist. I just want to mirror the flat net model that already
>> exists in the core with a more nuanced and yet to be decided
>> structure.
>
> But the burden I’d lay on you is to show that this *needs* to be in the core. If not, it doesn’t belong there.

Really? I think the burden is on you to explain why it should not be.
In fact I think if we put this one to the people on geda-developers
right now you would get voted down. I already got a go ahead on
launchpad although that does not guarantee my stuff will get merged.

In one word it feels convoluted to me that you would have two
mechanisms for mapping connections in two different places in two
different languages. Right now you are basically the only one
contributing gnetlist back ends. In my book this gives you a great
deal of say over how gnetlist is shaped but I really think you are
wrong here.

If I have a hidden agenda in this it is that what you are proposing
would mean yet more infrastructure in scheme when we really need to
de-emphasize it. To me this already feels like a compromise since I
would just assume work on replacing scheme. I would rather work with
you and everyone else than fight over that.

> 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/