X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
Date: Tue, 25 Aug 2015 19:49:19 +0200 (CEST)
X-X-Sender: igor2 AT igor2priv
To: "Evan Foss (evanfoss AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
X-Debug: to=geda-user AT delorie DOT com from="gedau AT igor2 DOT repo DOT hu"
From: gedau AT igor2 DOT repo DOT hu
Subject: Re: [geda-user] Re: off-topic: daydreaming about modularization
In-Reply-To: <CAM2RGhTD2MKKuXhK=tP7EwfrKuUBa7A0uCZF17LNx6+XQknwAg@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1508251945120.6924@igor2priv>
References: <CAM2RGhTJ-gywb3LrkKoNKUxkwJCTsJ7vRxiLtmrXa5Mnp0331w AT mail DOT gmail DOT com> <DUB125-W46D6798DBF674B80F24208C6620 AT phx DOT gbl> <6B8DDCCF-0E84-43DC-94A3-89CE0E56F0ED AT noqsi DOT com> <201508242052 DOT 28189 DOT ad252 AT freeelectron DOT net> <alpine DOT DEB DOT 2 DOT 00 DOT 1508250534570 DOT 6924 AT igor2priv>
 <3766120C-93DD-454D-B2FA-7C79B78DC86C AT noqsi DOT com> <alpine DOT DEB DOT 2 DOT 00 DOT 1508251403030 DOT 6924 AT igor2priv> <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>
 <CAM2RGhRYZ5Mxf8yUqsSmQ0Uzdb-4jc6-cSCKQ4kiMS6bOfEiHg AT mail DOT gmail DOT com> <55DC8B80 DOT 4020504 AT iae DOT nl> <CAM2RGhTD2MKKuXhK=tP7EwfrKuUBa7A0uCZF17LNx6+XQknwAg AT mail DOT gmail DOT com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
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, 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 <myken AT iae DOT nl> 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 <myken AT iae DOT nl> 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.

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.

Regards,

Igor2