Re: gEDA-user: How to deal with single/dual parts?

[John Doty <jpd@xxxxxxxxx>]

On Nov 20, 2009, at 7:09 AM, Peter Clifton wrote:

> On Thu, 2009-11-19 at 17:34 -0700, John Doty wrote:
>> On Nov 19, 2009, at 11:10 AM, Peter Clifton wrote:
>>
>>> The code which refreshes the pin-numbers when you change these
>>> unusually
>>> attached attributes is broken (missing) in git HEAD. Various special
>>> case checks for "slot=" exist, but none of the others. Nice things
>>> start
>>> to happen when you refactor the code though.. it starts to work
>>> better.
>>>
>>> The crux of it:
>>>
>>> http://repo.or.cz/w/geda-gaf/pcjc2.git/commitdiff/
>>> a8e4dd845a0dc49798fabc757a851f38567aa10a
>>
>> A bunch of changes to .c files. That's why you're frustrated, and why
>> I worry so much. The refactoring that's really needed is to take the
>> decisions away from the C core, move them to the Scheme layer, where
>> they can be overridden to support whatever the project flow needs.
>
> Refactoring is not usually about rewriting completely. Step one is to
> re-arrange what you have already got - which that commit does.
>
> Since we're pretty much stuck with the slot= mechanism we've always  
> had,
> there is no real point for me to re-write it in scheme anyway..  
> although
> it "could" be done as an exercise in the future.

Getting the agents to stop making policy decisions is part of getting  
the API right. This is especially important in an environment where  
volunteers are submitting patches, as the presence of policy code in  
the wrong layer will lure them into thinking that's where it belongs.  
The result is code that's convoluted and hard to change.

>
> The immediate obstacle is that we don't yet have support for doing any
> of the required stuff from scheme.

You've expressed frustration. *This* is the *source* of your  
frustration. Scheme is, in this design, the scripting language. But  
it can't access the functionality it needs to actually fulfill that  
role. Without the ability to script, we are stuck with a hard-wired  
policy for all flows. That can't work for anything more complex that  
we already have.

>
> We need to get the design of the internal, C API right before we can
> even hope to provide access to it from guile.

Giving Guile access is the essence of getting the API right in this  
architecture.

>
>
> If you read the code, you'll note that the new way is pretty  
> modular in
> nature, and employs hooks - such that it would be "really  
> easy" (TM) to
> turn into a plugin - given scheme access to those new hooks. In  
> effect,
> with the changes I pointed you at.. the slotting functionality is but
> one ".so" (and various loading code) away from being a loadable  
> module.


But loadable modules are not gEDA's customization mechanism: guile  
scripts are. We surely don't want two conflicting mechanisms here.

John Doty              Noqsi Aerospace, Ltd.
http://www.noqsi.com/
jpd@xxxxxxxxx




_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user