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=AnSHZYYJLLQPah+A4A7fQG43R+O4+vColXBJHSfVIOI=; b=aIg7U8cC/vo60PVWerHNvHlQlQcI9ZF1weKoctRXdA+y+qqVf1aqNXUKiJyYdPwDam qk4gKWJNCKA3gH3vneZz5zAksH0yNB5N1BxLTc1OIgcQ02b4yWw6wHBYMVmghoHqFOaD wKiWCKZPAwTcEwT/8p7JgvCK5lgnTkyv61/ihYVbvGDKMpEL8CiZwJrWn/TkaRkBzezk F0Z7l+yR4yMFPoHoMPEBRAoqG44rc6r44cfk+JlE1FOzaUxOdtgXEQGUfJS+qXKEdaKa bkIydQM4lh0s9n/EFj86v8sDoLTZwSYDhKy3HWeK6Y95ztP9U5pqa8sbLduJGxjF4po3 bLeA== MIME-Version: 1.0 X-Received: by 10.28.48.131 with SMTP id w125mr63971958wmw.18.1451614472441; Thu, 31 Dec 2015 18:14:32 -0800 (PST) In-Reply-To: References: Date: Thu, 31 Dec 2015 17:14:32 -0900 Message-ID: Subject: Re: gEDA and it's future with Scheme & Guile was Re: [geda-user] Project leadership From: "Britton Kerin (britton DOT kerin AT gmail DOT com) [via geda-user AT delorie DOT com]" To: geda-user AT delorie DOT com Content-Type: multipart/alternative; boundary=001a114242a4fb1b1705283c54f1 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 Precedence: bulk --001a114242a4fb1b1705283c54f1 Content-Type: text/plain; charset=UTF-8 On Wed, Dec 30, 2015 at 12:03 AM, Vladimir Zhbanov (vzhbanov AT gmail DOT com) [via 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] 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: > > - each C-function in geda-gaf should be available for > Scheme-scripting; > - all geda-gaf programs should be modularized and all their > functions should be available for other programs > - all duplicated functionality should be unified and cleaned up. > > 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; > - 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) > - 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 > - 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) > - 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 > - 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 must emphasize one thing: all those Scheme functions/add-ons are > available on the C side as well. > Well it all sounds good and non-destructive given the details. > Finally, I consider the position of "get rid of Scheme" to be a > Bad Thing which slows down geda development. > Agreed. It probably wouldn't deserve to be a priority even if we didn't have some hard-core lisp types. I would say it would be best to avoid as much as possible adding additional dependence on any script language, and if there's no choice it would be nice to pick one of the most widely used ones. Britton --001a114242a4fb1b1705283c54f1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Dec 30, 2015 at 12: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 (<= a href=3D"mailto:evanfoss AT gmail DOT com">evanfoss AT gmail DOT com) [via
geda-user AT delorie DOT com] <geda-user AT delorie DOT com> wrote:<= br> ...
>>> 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:

- each C-function in geda-gaf should be available for
=C2=A0 Scheme-scripting;
- all geda-gaf programs should be modularized and all their
=C2=A0 functions should be available for other programs
- all duplicated functionality should be unified and cleaned up.

Now, what I did so far (some of my stuff can be found on
htt= ps://github.com/vzh):
- rewrote pretty useless gsymcheck having lots of erroneous C
=C2=A0 functionality in Scheme, thus added
=C2=A0 - new checks;
=C2=A0 - representation of a symbol as a whole as a list having all
=C2=A0 =C2=A0 slotting and net info without conflicts in it;
- added a simple interface for using it in gschem where the user
=C2=A0 can:
=C2=A0 - check common symbol errors (in primitives or attributes);
=C2=A0 - select particular objects (or all them) and check what's wrong=
=C2=A0 =C2=A0 with them (if any)
- wrote a simple DSL to quickly parse our new ini-style config
=C2=A0 files in order to get all their structure in libgeda at once
=C2=A0 (did not finish yet); if I ever will work on it further, it
=C2=A0 could close one of the blueprints we have in the bug-tracker
=C2=A0 for geda
- played with gschem's undo to represent it as a plain Scheme list
=C2=A0 so user could just type something like "(get-undo)" in the= REPL
=C2=A0 and see all undo info (which is now buried in libgeda C structs)
=C2=A0 as a plain list (it is in another branch, didn't check it in
=C2=A0 because it has to be cleaned up, and my attempts to work on DSL
=C2=A0 are on top of it)
- added REPL in background terminal for gschem and found a way to
=C2=A0 add more REPLs which you would be able to use, say, in Emacs,
=C2=A0 using its shiny geiser environment
- did lots of other work (e.g. symbol generator which could work
=C2=A0 as a gschem function, that is could have a menu for calling it;
=C2=A0 whitespace separated netlist to schematic converter; and other
=C2=A0 things) which I'm not motivated to continue to work on until we<= br> =C2=A0 find the direction we'll go further.

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

Well it all sounds good and non-destructive given the details.
<= div>=C2=A0
Finally, I consider the position of "get rid of Scheme" to be a Bad Thing which slows down geda development.

Agreed.=C2=A0 It probably wouldn't deserve to be a pri= ority even if we didn't have some hard-core lisp types.=C2=A0 I would s= ay it would be best to avoid as much as possible adding additional dependen= ce on any script language, and if there's no choice it would be nice to= pick one of the most widely used ones.
=C2=A0
Britton

--001a114242a4fb1b1705283c54f1--