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=pd7RNmkleK9cN00zGOF5YpMfoNSm2jslB05Yi7RzT48=; b=0Rs48d9bFjwRnJSLCzqcnff98G6gP4PWwD/M5xD5wvhDpqb5E03ivzT8i4Wd4NpNAu ZsZyJjRfvhEeIhvZ0Tk6K2xvfbrbggNxPwYWpo4+lVww3Gzlgr9qRqoNKfzyvOs8JM80 y+4IfDEe0J7vgTRBTZ891KQ6mxuiQ2sJaGj9iUy+jSfPdDfAnzeV3vXnE6seXj1b6q/C sbcmaAsGXLXMTzyUaYxYu2SZQXUGoNDaMg3HM8qWCIAdKAV4HJjHUac0G8E4pIKQXSMd LUYxcw5Dl2V969CS3syD7NGVl+mflQeVo4+l2aN6B6aLxijhoVeCi+rgfG6KUFPc44+u Prgg== MIME-Version: 1.0 X-Received: by 10.152.5.69 with SMTP id q5mr10356688laq.92.1440526434691; Tue, 25 Aug 2015 11:13:54 -0700 (PDT) In-Reply-To: References: <6B8DDCCF-0E84-43DC-94A3-89CE0E56F0ED AT noqsi DOT com> <201508242052 DOT 28189 DOT ad252 AT freeelectron DOT net> <3766120C-93DD-454D-B2FA-7C79B78DC86C AT noqsi DOT com> <8DC5050C-49D2-49AD-94B0-A1FC857178E5 AT noqsi DOT com> <55DC6491 DOT 8030607 AT iae DOT nl> <3FA132D6-A8D9-47C8-8D37-E1962EF4098B AT noqsi DOT com> <55DC78F8 DOT 1010105 AT iae DOT nl> <55DC8B80 DOT 4020504 AT iae DOT nl> Date: Tue, 25 Aug 2015 14:13:54 -0400 Message-ID: Subject: Re: [geda-user] Re: off-topic: daydreaming about modularization From: "Evan Foss (evanfoss AT gmail DOT com) [via geda-user AT delorie DOT com]" To: geda-user AT delorie DOT com 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 Tue, Aug 25, 2015 at 1:49 PM, wrote: > > > On Tue, 25 Aug 2015, Evan Foss (evanfoss AT gmail DOT com) [via > geda-user AT delorie DOT com] wrote: > >> On Tue, Aug 25, 2015 at 11:36 AM, myken wrote: >>> >>> On 25/08/15 16:51, Evan Foss (evanfoss AT gmail DOT com) [via >>> geda-user AT delorie DOT com] wrote: >>> >>> On Tue, Aug 25, 2015 at 10:17 AM, myken wrote: >>> >>> On 25/08/15 15:18, John Doty wrote: >>> >>> Isn't the whole idea in this thread "let's make gschem/pcb more >>> accessible?? >>> >>> Yes, but the answer looks *completely* different depending on whether >>> you?re >>> >>> coming from a pcb (integrated tool) or geda-gaf (toolkit) perspective. >>> >>> >>> It must be my lack of understanding the English language but I don't >>> think >>> there is anyone on this list disputing the power, flexibility, simplicity >>> and usability of the geda-gaf (gschem) toolkit. Well I don't. >>> If I understand what I have read there is no one that wants to restrict >>> the >>> functionality of gschem. >>> If anything I guess there is a bigger change that pcb will move towards >>> gschem (geda) then the other way around. >>> >>> The PCB developers are the current majority. >>> >>> Maybe, but that doesn't automatically mean the gschem (geda) architecture >>> will change! >>> I use geda-gaf for schematic entry, simulation, VHDL design and PCB >>> design. >>> It is a great tool, just the way it is. I don't want it to change. >>> But I do see a great benefit in a more accessible toolkit (including >>> pcb). >>> If that means adding an additional button in the menu bar, so be it. >>> >>> All people try to do is find a way to make the combination more >>> accessible. >>> I don't mind adding the restriction "looking from the geda-gaf >>> perspective", >>> if that makes us move forward. >>> >>> gschem needs a more viable plugin interface so that people can >>> implement their desired gschem and pcb relationship with out >>> subjecting the rest of us too it. >>> >>> Sound great to me. Anyone opposes this? Can we move forward from here? >> >> >> >> I think in that objectives thread a while back we agreed that adding >> other plugin interfaces in parallel to scheme was a good thing. The >> best way to do it would be via (gpmi) the same library Igor2 used in >> pcb-rnd. That way we don't add any additional dependencies and debug >> will be easier. One thing that would have to be worked out is how to >> block gpmi from passing scheme along since it also supports that >> language. We don't want to unintentionally gain an extra scheme > > > That's not hard: gpmi is not doing anything by itself, you always explicitly > request things. Your C code requests gpmi to load a module that interprets a > language and your C code requests gpmi to run some code in it. If you just > don't load the guile module and you ask it to run scheme code for you, it > won't. Ok. I have barely found time to run the testing I wanted, reading the code keeps getting pushed forward. > Btw, from your C code, you don't see any difference between scripting > languages, you see an unified, simplified (and not very CPU efficient) > interface. So after all, it doesn't even matter if you don't block your user > from using scheme through gpmi, as it has no chance mixing with the scheme > context used by gschem. Ok. I just wanted to clearly define what I meant by in parallel. Thank you for clarifying. > Regards, > > Igor2 > -- Home http://evanfoss.googlepages.com/ Work http://forge.abcd.harvard.edu/gf/project/epl_engineering/wiki/