delorie.com/archives/browse.cgi   search  
Mail Archives: geda-user/2016/07/16/22:58:57

X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
Date: Sun, 17 Jul 2016 05:05:19 +0200 (CEST)
X-X-Sender: igor2 AT igor2priv
To: geda-user AT delorie DOT com
X-Debug: to=geda-user AT delorie DOT com from="gedau AT igor2 DOT repo DOT hu"
From: gedau AT igor2 DOT repo DOT hu
Subject: Re: [geda-user] [pcb-rnd] code & test sprint - the future of pcb-rnd
(cschem)
In-Reply-To: <alpine.DEB.2.11.1607162106090.6844@nimbus>
Message-ID: <alpine.DEB.2.00.1607170421200.7286@igor2priv>
References: <alpine DOT DEB DOT 2 DOT 00 DOT 1607141138570 DOT 7286 AT igor2priv> <alpine DOT DEB DOT 2 DOT 00 DOT 1607161907560 DOT 7286 AT igor2priv> <alpine DOT DEB DOT 2 DOT 11 DOT 1607162106090 DOT 6844 AT nimbus>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
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 Sat, 16 Jul 2016, Roland Lutz wrote:

> On Sat, 16 Jul 2016, gedau AT igor2 DOT repo DOT hu wrote:
>> [Pcb-rnd is] close to being "finished". Which means I should probably stop 
>> investing as much time in it as I did in the past months and move my focus 
>> on something that is more broken (gschem).
>
>> cschem (a replacement for gschem and gnetlist - I'd say contribution is 
>> welcome right from the design phase, but I know how it works).
>
> Since I'm up to my guts in libgeda right now, I'm very interested in your 
> thoughts.  What are the problems you see with gschem?  How do you intend to 
> solve these problems?

High level:

There are some design decisions which are unusual but great. I want to 
keep them. They are the reason I am still using geda and gschem despite of 
all the below.

There are other design decisions from early on which I think didn't work 
out well or are just plain wrong. There are social/political reasons that 
makes it totally impossible to even discuss these constructively, so we 
are unable to change them or at least provide alternatives for them within 
the existing frame. Geda has locked itslef in, and I believe this 
determines its (sad) future.

The loud minority of the community and the very few active developers are 
not going in a direction that'd solve any of these problems, thus there's 
no chance the project can change direction. (No offense ment, I totally 
see those guys believe that direction is the right direction the same way 
I believe mine is the right one -> this why we need two separate 
projects.)

Low level:

Finally, the code itelf, which is tightly coupled with guile and gtk. When 
I wrote the back annotation patch about a year ago I figured I didn't like 
most of the code for various reasons. No offense meant, so I rather omit 
technical details. Unlike with pcb, I don't see it is worth forking it, 
it's cheaper to just rewrite it the way I think is proper, YMMV. (I won't 
name any specific issue, because it's really like everywhere I touched the 
code there were more issues than solutions; all in the design, in the 
API and in the actual implemenetation.)

Finally, how to solve them, my plans (public since 1st january):

http://repo.hu/projects/pcb-rnd/devlog/20160101_cschem.html

(FAQ: Nope, I can't use libgeda or any part of it, and no, I won't be 
API-compatible with libgeda. Cschem and the netlister will be able to load 
and save geda formats for compatibility, but the native format will be 
different, more human-readable, not less script-readable. There won't be 
more integration with pcb-rnd or anything else, but there will absolutely 
be more cooperation among the tools, options beyond "just generate a 
diff to pcb/sim/build netlists and apply the changes by hand".)

I do not want to discuss technical details of the plan now, because a 
mailing list thread won't ever yield any useful result but waste 
everyone's time. If there are a few users who are willing to help 
implementing and testing the design (ideas, no code) on hypotetical test 
cases, I am more than happy to channel their efforts in. As I don't use 
hierarchical netlists and I have only two or three workflows, such 
contribution would help keeping the new design 100% generic. But the 
design process can only happen in a coordinated way, using svn to work out 
ideas and examples. (I have no high hopes on this, tho, poeple tend to 
stick to gschem the are used to, so I expect 0 contributors.)

Regards,

Igor2

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019