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;
	bh=dnxLF+nwpc96wIU6hEAPQ/3Y1UYOccMYyKQWN2yqI6g=;
	b=tNXaiwiR7dE7T+h917/5BKvmfzQm63ox+rfPCkTcioq8fTqgAapXBOllejRGGe15Q2
	ulbmQ9s8F+WQJ22c6PqKwJaf+/1xIwz/3g35IsEW/0yP0nstIftqY1AtAAYMlRBkdGla
	dl2PyUj8WgV0K5IaittCFl9ksmdRO/uG278jjbJyBhCWO3S49JXaQamjS8NdvhmY3bnB
	P/6sSJMe9G23XW/sbjmrTyEx5Au7Bug+vfWjkemMtrDrcDubNGMwd3SrwNmV3qQWuWGW
	wYkc7EG0C8j2VZvvg6JaXXeaiu2EMTw5YpjSSvKI64tQhsTcWUB2IbT778JcOovwUF16
	zdZg==
MIME-Version:	1.0
X-Received:	by 10.25.137.194 with SMTP id l185mr8348444lfd.41.1451610421615;
	Thu, 31 Dec 2015 17:07:01 -0800 (PST)
In-Reply-To:	<CAMvDHVATJYfLUkL+5AkD31BVTbg5OdKTvZc2LVh=7Kf6Y-95EA@mail.gmail.com>
References:	<CAM2RGhS4L-ch6FEcLtdSt0vA0BdQZvq+AuFDP+9ea7Ftd=AALg AT mail DOT gmail DOT com>
	<CAMvDHVATJYfLUkL+5AkD31BVTbg5OdKTvZc2LVh=7Kf6Y-95EA AT mail DOT gmail DOT com>
Date:	Fri, 1 Jan 2016 01:07:01 +0000
Message-ID:	<CAM2RGhRximmN30eR_ttrtkrcyK-Ft5BtMOZnsZwFqgbTi7EYNw@mail.gmail.com>
Subject:	Re: gEDA and it's future with Scheme & Guile was Re: [geda-user]
	Project leadership
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>
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 9:03 AM, Vladimir Zhbanov (vzhbanov AT gmail DOT com)
[via geda-user AT delorie DOT com] <geda-user AT delorie DOT com> wrote:
> On 12/29/15, Evan Foss (evanfoss AT gmail DOT com) [via
> geda-user AT delorie DOT com] <geda-user AT delorie DOT com> wrote:
> ...
>>>> could be miss interpreting your plan here but it sounds like you are
>>>> going to replace more of the C with Scheme.
>>>
>>> Yeah, that's my plan :)
>>
>> Sorry but I oppose this plan and I think I can gather a lot of support.
>
> I was going to write an extended answer until I realized it would
> be overwhelmingly difficult for me due to I am not so fluent in
> English as you are. Hence I'll try to manifest what I consider to
> be done (and what I worked on so far). Please let me know which
> things you consider to be harmful for gEDA. Now then, I list my
> wishes here:

Don't worry about the language barrier.

> - each C-function in geda-gaf should be available for
>   Scheme-scripting;

I totally support that!

> - all geda-gaf programs should be modularized and all their
>   functions should be available for other programs

I think I support this if I understand it correctly.

> - all duplicated functionality should be unified and cleaned up.

It depends on how you plan on doing it.

> Now, what I did so far (some of my stuff can be found on
> https://github.com/vzh):
> - rewrote pretty useless gsymcheck having lots of erroneous C
>   functionality in Scheme, thus added
>   - new checks;
>   - representation of a symbol as a whole as a list having all
>     slotting and net info without conflicts in it;

I am not wild about it but I can see value in what you did.

> - added a simple interface for using it in gschem where the user
>   can:
>   - check common symbol errors (in primitives or attributes);
>   - select particular objects (or all them) and check what's wrong
>     with them (if any)

Makes sense.

> - wrote a simple DSL to quickly parse our new ini-style config
>   files in order to get all their structure in libgeda at once
>   (did not finish yet); if I ever will work on it further, it
>   could close one of the blueprints we have in the bug-tracker
>   for geda

Would you please point me to entry in the bug-tracker?

> - played with gschem's undo to represent it as a plain Scheme list
>   so user could just type something like "(get-undo)" in the REPL
>   and see all undo info (which is now buried in libgeda C structs)
>   as a plain list (it is in another branch, didn't check it in
>   because it has to be cleaned up, and my attempts to work on DSL
>   are on top of it)

I admit the implementation of undo is kind of ugly but I don't want
the code that drives it being moved from C to Scheme.

> - added REPL in background terminal for gschem and found a way to
>   add more REPLs which you would be able to use, say, in Emacs,
>   using its shiny geiser environment

I like this and I am sure I did before.

> - did lots of other work (e.g. symbol generator which could work
>   as a gschem function, that is could have a menu for calling it;
>   whitespace separated netlist to schematic converter; and other
>   things) which I'm not motivated to continue to work on until we
>   find the direction we'll go further.

I don't think symbol generation should be in gschem. I think it should
be a separate command that can be called from inside gschem like
schematic import in pcb. The scheme interaction mechanism should let
you call the command line to do this and other things I think. (I am
not married to this idea)

> I must emphasize one thing: all those Scheme functions/add-ons are
> available on the C side as well.

Availability is good.

> Finally, I consider the position of "get rid of Scheme" to be a
> Bad Thing which slows down geda development.

I never said get rid of scheme. We need to keep that and I have said
as much although not recently. I have in fact voiced my support for
some of your more recent additions. I am just worried about more
functionality being walled off behind the language barrier and long
term maintenance. I could expand on this but I am tired of debating
and negativity.

If you want to do something go for it. You are a more serious
contributor than me so far, I should trust you more. My apologies.

> Regards,
>   Vladimir



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