On Dec 29, 2015, at 5:56 PM, Britton = Kerin (britton DOT kerin AT gmail DOT com) = [via geda-user AT delorie DOT com] = <geda-user AT delorie DOT com>= wrote:

Pcb is = fine.

Balone= y. For example, for years I=92ve been hearing that users want buried = vias. A sanely designed tool wouldn=92t prevent a user from simply = drawing a buried via, even if it didn=92t have such a concept built in. = Pcb doesn=92t properly model the job it=92s supposed to = do.

It has = all the users.

Almost = all of them do their drawing with gschem, but if you read this list, = almost all of the trouble they have is with pcb. Gschem works well, but = pcb doesn=92t. We really need a decent free/open layout = program.

There=92s nothing to keep my = collaborators and layout contractors from using pcb. They know of it but = it doesn=92t look useful to them. I=92ve exported gschem designs to a = variety of PCB layout programs. The best one in terms of results has = been Osmond PCB.

> and scheme turns off a
> lot of wood be contributors. We need people who....
> 1. Don't fight so much.
> 2. Know about EDA software.
> 3. Have time to work on the project.
> 4. Know all the languages involved in the project.
>
> That is a lot to ask.
>
> Kai-Martin and I were not the only two.
>
>> I never said scheme is over-emphasised in geda-gaf. AFAIR, I = always
>> stated the opposite: Scheme is 'under-emphasized' as a = scripting
>> language in geda.
>
> I think something got missed in translation. I was saying you = and
> peter were the only two who wanted to keep advancing scheme's use = in
> geda.
>
>>> 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 :)

Good plan.

Terrible = plan. Tons more people know C, so you're replacing code that = people can easily read with code they = can=92t.

Vladimir=92s = replacing code in a low-level language that is very clumsy in this = application with a language that is much better suited. C is good for = writing things like device drivers. There are far better ways to process = data away from the iron than C.

That's bad. You've = conceded in that past that Lisp probably isn't the best way = forward,

Lisp may not = be the best way forward for *new* tools,. If you want to get rid of = Lisp, you should write a new tool that isn=92t dependent on it. For = those of us who want to keep the old tool, it increases flexibility to = move more of it to Lisp.

you're just being argumentative = here.

Python might be = a way, and Xorn supports it. I would be more enthusiastic about this = path if I could concretely understand what Xorn is. At least we know = it's a powerful tool in Roland=92s hands, but does anybody else = understand it?

My position is consistent: = protect (and possibly extend in a way compatible with its design) our = existing infrastructure. If you want to do anything else, write a new = tool. When you have a toolkit, you shouldn't make drastic changes to = existing tools. Write new ones. If you want to make a schematic capture = program with plugins in C, why would you *start* with something tangled = with Scheme in a very complicated way? Easier to untangle by starting = with a C architecture designed for what you want. In the latter case, = you could have a 21st century GUI, too. Why kludge the gschem = architecture to fit your agenda, when you can more easily have a = parallel tool? I expect C plugins would still be far clumsier than = Scheme, but maybe some would have the fortitude to write = them.

The big disconnect here is the idea that = we can=92t keep our old tools while developing new ones. It seems to me = that developers who actually understand the internals of geda-gaf are = the ones who are also comfortable with doing more in = Scheme.