Mail Archives: geda-user/2015/08/25/14:14:15
On Tue, Aug 25, 2015 at 1:49 PM, <gedau AT igor2 DOT repo DOT hu> 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 <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.
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/
- Raw text -