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: References: Date: Fri, 1 Jan 2016 01:07:01 +0000 Message-ID: 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]" To: gEDA users mailing list Content-Type: text/plain; charset=UTF-8 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 On Wed, Dec 30, 2015 at 9: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: 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-----