Mail Archives: geda-user/2016/07/17/14:57:02
On Sun, Jul 17, 2016 at 3:05 AM, <gedau AT igor2 DOT repo DOT hu> wrote:
>
>
> 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.
Indeed.
> 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 was initially hoping libgeda would be reusable but the more I look
at it the more unusable it feels. Linking against it means linking
against it's dependencies.
> 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.)
Ah well...
> Regards,
>
> Igor2
Evan
--
Home
http://evanfoss.googlepages.com/
Work
http://forge.abcd.harvard.edu/gf/project/epl_engineering/wiki/
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v2
mQENBFYy4RYBCAC183JomLtbdAlcKiaPDoVHq52LDmVmH75aiEc69m7YxDt54/ai
VtYCAobbGVIyn3Hlz3uhF6LnPl/6Lm1VdnCfpwu3KQhCO6ds10ow2C30X4ohCqOd
hCVg5C+ILmQkEffFrFODy3ji+PYTF4pADvHCWsTMv0hf0llwFOJsBCK6cl02IffE
JPqy4PjM1nZ9HpzT84JBaG/4OGvTZ8SQ2yFUl265jagvygPTf88H1xpZHH1r8dB1
stjUHLmPH8AOyDgKxFchgGeDc3p/vJtgDDIXAFfDXG0NSRovLmtaQdGxe47Zf/go
bXiEM7YL2WqQe5zfEA919JxkEwlDKYniOSVzABEBAAG0N0V2YW4gRm9zcyAoVGhp
cyBpcyBteSBwdWJsaWMga2V5LikgPGV2YW5mb3NzQGdtYWlsLmNvbT6JATkEEwEC
ACMFAlYy4RYCGwMHCwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCIpQTcE8nN
bbBaCACAm8pU5lG1ev2Fsw68Axtcl57SJrYieqX96c3YuYH9JpqMqJRnd9nDKw9X
tQuvuH7tUk0VbOaDqReOYJVI/4c5wb9AaOFp6K2DUcupq6XhgXpvz3HzoPwjAdIj
XuQzdRUx5+innTJrSkGuBYW/CZ2zqEx4xfLlq4rO0hoTUMR8QVp2cCrkw6BT0m86
APIw/ZnjoxM8IEzr7MxfRIg3qpzrZk28rmhx+k78Jyk61UhwcCPGIm/pjUopTwYJ
3YBdRB2cYD2aN7A1JVf5cRmSQYooHBGpH0kYvomGk97PKqypVuJ7OpG9xM58wUcC
qUVt9hKlePLzP8csYjt8onqI7qIIuQENBFYy4RYBCADlH8spG3WkCx62vB5mr5Z0
SCDd/RcyA4A5y5EOj5KurQkrSWpgi9Ho1yKruMJ6blQR2qkc66KqH9pnXDm/ZI1M
K/wdW3ngETxBmXoozzFMT89aEWIVR5/PFodWK1elekE9iJxACuR98Zg2QttTD3x8
A9w8VEyMLOXcDTrPFpHegMKswFBg5iuMulAdXAoGejWTI3n+qKFpabHm2Lfs6wjk
5rjucpTdeFK6UeWF1xAvNxXibuu5BlGwv53930qIXRwO/Gn2Rh5DXWxKU2fEIme/
xgQQmIsDeUoWbfybdjw/x7Q0LW4mINiLDQcGHHRQKFIxbAJCT3USPLGh5xwE9/Er
ABEBAAGJAR8EGAECAAkFAlYy4RYCGwwACgkQiKUE3BPJzW0uYAf9Hf30n8tM3mR2
Zo6ESE0ivgdgjaJtAWrBUx7JzAzPjBnBOlNnu5Y9lVEqetvUPH6e3PvaHYUuaUU8
0HwxuKBW9nUprgV6uIu1DZmlcp+SxpbuCy7RDpNocRLNWWFMaYYzznmTgfnTgD4D
gCq8Mf1mcfrluTkOAo+QNqbMfl1GISClopRqxVuAo59ewgMnFujwgd8w12BwWl24
CzqOs5HqcUslePj+LzcjSNgVCklYwKl+0dsb/fctMOCtHodwqm2CBJ+zydvNmYkD
fxda/J91Z1xrah5ec++FL0L4vs+jCiIWJeupJFKlr1hCMZiiGH7W554loK5l4jv3
EY347EidAw==
=Ta4p
-----END PGP PUBLIC KEY BLOCK-----
- Raw text -