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

[John Doty <jpd@xxxxxxxxx>]

On Dec 4, 2009, at 12:38 PM, Steven Michalske wrote:

>
> On Nov 22, 2009, at 8:41 AM, John Doty wrote:
>
>>
>> On Nov 20, 2009, at 2:51 PM, Steven Michalske wrote:
>>
>>>
>>> On Nov 20, 2009, at 7:15 AM, Stuart Brorson wrote:
>>>
>>>> As an alternative to scheme, some would prefer to see TCL.  I have
>>>> no
>>>> problem with that, as long as the interpreter is built-in.   
>>>> However,
>>>> there is a large installed base of scheme, so it's likely we're
>>>> stuck
>>>> with it.
>>>
>>>
>>> I propose that the scripting languages be plugins.
>>
>> Difficult. The scripting language has a strong influence on the
>> scripting API.
>
> This always is an interesting argument,  the strong influence I see is
> functional programming languages vs imperative languages,

That's actually the most trivial. Data-driven versus pattern-driven  
versus process-driven, strong versus weak versus dynamic versus  
static versus no typing, various forms of OO, ...

> but scheme
> is multi-paradigm so it supports both.

If you want to create incomprehensible code, write procedurally in  
Scheme. Or Forth. Or Mathematica. It isn't technically hard to  
support procedural programming in a functional language, but it's a  
capability that should usually be avoided.

>
> The plugins would have their own external API interfaces that access
> the data structures and methods in the program you are scripting.

But every language has a different natural way to *view* those data  
structures. And then consider an "expand hierarchy" plugin. It's  
going to be creating new data structures *outside* the API. How are  
you going to present those to other plugins in other languages? It's  
not theoretically impossible, but it's a massive, massive can of worms,

And don't tell me hierarchy should be handled in the core. There  
isn't a single "correct" way to do it. I myself use different  
approaches for circuit boards versus VLSI in gEDA.

>   The
> internal plugin API would be very similar, the language's external API
> would be slightly similar, being based on the same data structure
> manipulation and method calling requirements.
>
>>
>>>
>>> that way we can use the language that we know best.
>>>
>>> Yes, I could learn scheme or TCL,  but I already know bash, perl,
>>> python, fourth, and basic
>>
>> We could pretty easily layer a BASIC or Logo atop Scheme. Way back in
>> 1977, Bob Frankston implemented ECD BASIC atop a stripped-down Lisp
>> engine. I maintained it from 1979-1981 after Bob moved on to his next
>> project (VisiCalc). It was pretty simple (it fit in something like
>> 16k bytes). ECD BASIC complied with the Dartmouth spec, but data
>> objects were actually lists, so you could easily represent complex
>> data structures as needed.
>>
>
> This seems more work than to make a way to present the data structures
> and methods cleanly through a scripting engine API.

Oh, no, it's *much* easier. Just because you've never studied the  
techniques, that doesn't make it hard. Bob fit the whole thing in  
16kB: there wasn't room for much complexity!

>
> Hell the plugins could just generate or call scheme routines, and
> still have scheme as the only interface to the guts of gEDA.

But Scheme data structures aren't a natural way to present the data  
to other languages, not even C, despite the fact that Guile is  
written in C, and there's a very elaborate API.

>
>> But what is it about engineers that I hear constantly "I don't want
>> to learn..." from them? So unprofessional. For something complex and
>> obfuscated, the time factor comes in, but Scheme is one of the
>> simplest programming languages there is.
>
> Unprofessional, I'm not getting paid to work with gEDA/PCB.  Were i
> getting paid, i'd learn scheme and use it.  My request comes from the
> fact that don't want to remember yet another syntax,

What syntax? Let's see, you have lists, dotted pairs, quoting, and a  
few kinds of constants. Maybe 10 minutes studying to understand it.  
Then there's some vocabulary, but the majority of what you need there  
is in the libgeda/gschem/gnetlist APIs, not built into Guile.

> and that if a
> plug-able *embedded* scripting language is used that the barrier to
> entry is minimized.

So you request that the small development team take on an enormous  
job so you don't have to do a tiny amount of studying.

>   Thus preventing the need/desire for others to
> implement yet another netlister in their favorite language.

Well, of course one advantage of clean, well documented formats is  
that one may use them as one pleases. And while I'm a huge fan of  
gnetlist (it's the magic jewel at the core of gEDA's superiority to  
other packages), it has its limits. I fear those limits will never be  
removed.

>
>>
>>>
>>> And before anyone starts complaining about dependency hell,  my
>>> answer
>>> to you will be get a Mac. Oh, and these are plugins.
>>
>> Huh? Now you seem to be talking about scripting at the command line
>> level. Nothing special about the Mac there. But we use Scheme for
>> *embedded* scripting within the gEDA tools. Different.
>
> No, more that macports or fink make the dependency hell much more
> tolerable.  Just as every other package manager should take care of
> dependencies.  Think of a Mac as unix for the masses.

I'm typing this on a Mac. Fink is OK, and it's very handy to be able  
to mix Jobsian totalitarian applications with Stallmannian free  
tools. But Fink doesn't work as well as Debian/Ubuntu or Red Hat. And  
dependencies at that level aren't the main issue here anyway.

> If dependencies are preventing you from using software or making you
> recreate the wheel, that you shouldn't be using linux, you would be
> happier on a Mac.
>
> As for embedded scripting, I know that we use scheme.
>
> The comment that these are plugins is referring to that a plugins are
> not a compile time requirement, and could be left out, except for the
> manditory scripting plugins, such as scheme would be with our long
> history.

I wouldn't call processing with non-embedded scripts a "plugin"  
process. And we already support that fairly well: the API is the  
gschem file format, which is pretty well documented and easily  
processed by perl, python, awk, whatever. The main barrier here is  
that the rc files aren't so friendly. But the where-geda-sh "backend"  
I posted a couple of months ago could probably be expanded to grind  
the rc files into a friendlier format. The problem is a lack of  
documentation of the internal representation of the parameters.

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