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=date:from:to:subject:message-id:mail-followup-to:references
	:mime-version:content-type:content-disposition:in-reply-to
	:user-agent;
	bh=Y4JXafe530hjFw8CrSOG8t79fzGH1ICCz/abQRqESl0=;
	b=JySpMLlRnZAnWRBdvzzSRFi01KFSbazI7w9N9jn/mRucBcIyxr8srsNX/kW+437rNH
	KE1lAjrR1Hsa6HfJpw2ExjU5Tb+sNWqe3BWPvXROhSsTlC3e838eTVuSLtNFRxhOJHNn
	IfAYYG18iYONpoeGRt8JsGV63jrzHeGVJVRdLhJ822s1Kb9OWD42Qtzb2pd0KoNW8z2I
	PsHqFTYYpUhxiZPkoDO6zglgiV2RuTxmvZb3OzqpKhx02R15pr0i44E2k1KuVq6yIooF
	yi31voDz5pTOO0vZPUQViHe5CHrdIWuOZt0eAM3uXXfT3XLUiHHEuL99IwE3lu8IKP3X
	Zh6w==
X-Received:	by 10.25.141.206 with SMTP id p197mr9501904lfd.104.1451518652587;
	Wed, 30 Dec 2015 15:37:32 -0800 (PST)
Date:	Thu, 31 Dec 2015 02:37:30 +0300
From:	"Vladimir Zhbanov (vzhbanov AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
To:	"Evan Foss (evanfoss AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
Subject:	Re: [geda-user] Project leadership (design error in the core of
	gschem)
Message-ID:	<20151230233730.GI4099@localhost.localdomain>
Mail-Followup-To:	"Evan Foss (evanfoss AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
References:	<CAJXU7q_3XwthnN_8mp7B+-ShHeK+=7J=54ZavKBUG3S3bSKp2A AT mail DOT gmail DOT com>
	<CANEvwqiM7CKG+WpDRpG4L=HsmSEZ32=CBDyUhuk3ks-SNedL2Q AT mail DOT gmail DOT com>
	<43CC8F96-6452-40FA-9DFB-E0983721C19C AT noqsi DOT com>
	<alpine DOT DEB DOT 2 DOT 00 DOT 1512290406210 DOT 9035 AT igor2priv>
	<20151229094603 DOT 782092b57563336883546bfd AT gmail DOT com>
	<CAM2RGhQ363RydhBJKMnNX5sLOkD1K4qVwb-PPwov3MT3D6MfdQ AT mail DOT gmail DOT com>
	<449C2A4A-814E-4858-ACB3-82807A80BE8A AT noqsi DOT com>
	<CAM2RGhQD1b0NKLWNYyB-m1whgYJZeEH9syzSs4OZt+22D5hooA AT mail DOT gmail DOT com>
	<alpine DOT DEB DOT 2 DOT 00 DOT 1512300441390 DOT 9035 AT igor2priv>
MIME-Version:	1.0
In-Reply-To:	<alpine.DEB.2.00.1512300441390.9035@igor2priv>
User-Agent:	Mutt/1.5.23 (2014-03-12)
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, Dec 30, 2015 at 05:17:25AM +0100, gedau AT igor2 DOT repo DOT hu wrote:
...
> A better comparison: I run a binary program that hits an assert() or aborts
> and dumps core. Looking at the core and fixing the source is back
> annotation. For this, I want the binary side tools (a debugger), and the
> source code side tools (a text editor). The text editor needs a functions
> like "jump to line N". For this, it needs to understand what a "line" is.
> This makes it less general as if it didn't have to assume things like
> special meaning of newlines, but such is life.
> 
> Gschem can not "jump to a network". For me, it is exactly the same as if a
> text editor couldn't jump to a line. I do undrestand the background, I do
> understand that all network related smartness is exported into the netlist
> infrastructure, and it's all fine. But then why gschem doesn't ask the
> netlist infra? Or why the netlist engine doesn't generate an ".lst" (staying
> with the object example) gschem can read? And why gschem tries to understand
> slotting in the first place, and doesn't leave it for the netlister?
>
Because we understand it differently. Because someone who wrote
initial functions had thoughts all people would be able to use
scheme, and closed his eyes when a young developer added his C
stuff on top of it, making things more hard, and after realising
things got worse and he doesn't want fighting them (let's the
young developer fights his buildings) went away. Because lisp is a
thing made of and for lists, and our schematics, symbols, and
netlists are lists, too. Because you are fighting tools specially
made up for working with lists and prefer to work with malloc
stuff and such. Because nobody wants and can stop you or people
like you from doing things your way and thinking they're
presenting the best programming style in the world. Because, at
least, there are too few developers in our list to read and answer
all the posts like this one. Because you don't understand the John's
point "don't make things harder before you want to make them
simpler" when you're fighting the concepts he is trying to defend,
and while I know he could not be right in each thing he states, I
think he is right in this very thing.

> I am an user of gschem. Whatever flows you use, whatever flows I use, please
> do not try to convince me that I don't need to locate a network by name in
> my design. It just won't work. Not being able to get the GUI identify some
> of the most basic building blocks is just plain wrong, no matter what the
> architectural reason is. Not even if John will surely hurry to mislabel this
> as an "integrated vs. toolkit" issue.

I understand your needs, and agreed with some of your statements.
I disagree the way you're pressing on the current devs. You
consider gschem to be not perfect. Fine. Do it more perfect. I
don't mind at all. But please understand. There are currently two
developers working on gschem in the central repo these days. And
we (those two developers) have different views and different needs
(I don't even compare your needs here).

With hope my rant is constuctive,
  Vladimir

- Raw text -