ftp.delorie.com/archives/browse.cgi | search |
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
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |