[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: gEDA-user: How to deal with single/dual parts?
On Dec 5, 2009, at 10:09 AM, John Doty wrote:
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.
Agreed, I hate using the latter two in a procedural fashion.
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,
YAML might be a good go between, it has support for the most common
containers and support for custom containers.
but using the sch file would prevent unrepresentable things from
happening to the data.
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.
Agreed here, how a hierarchy works is not one single way!
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!
Sorry, i meant implementing the other languages atop scheme. basic is
done, what about x,y, and z :-P
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.
fair point, being unfamiliar with scheme, I can't comment on it's data
implementations. But doesn't this stipulate that scheme shouldn't be
used ;-P or are you saying that lots of guile is implemented to
minimize this barrier? Thus making other languages make scheme code
difficult as well.
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.
I can learn the syntax, but will I be proficient with it's
methodologies, and nuances?
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.
This opinion is expressed by many, but I proposed that if the
scripting languages were capable of a being a plugin, then you could
make the requester of xzy language write the plugin. There just need
to be a way to get to the data. Pass a C pointer for all I care, but
accessors would be better.
To implement any scripting language the data structures must be made
visible, make that interface an abstraction layer
get/set functions in C that the scheme would call.
This does a few things.
1: Allows any code to call those functions.
2: provides an out for changes in the core.
i.e. when you change something in the core, a workaround can be built
into the set/get functions so their external appearance doesn't
change.
3: provides deprecation paths.
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.
What might be a good compromise here is to pipe the sch file out to an
external app and it should pipe in the processed data.
This way the API is the text file formats, and there is a clear
boundary between the two.
Maybe pass some arguments (selected component list), some error
checking, menu insertion functions and some undo logic changes, and we
have an in application scripting interface.
I feel that this thread has lost focus, what are we really
discussing?
Just as you argue for not tying down one implementation for workflow,
I am proposing that scripting interfaces are not tied down as well.
As as far as i know
I am not saying that gnetlist should switch away from scheme, but that
future implementations of scripting languages be abstracted, this
might make things like 1.6 to 1.8 guile transitions a thing of the
past, as the abstraction layer would allow isolation at a single point
and allow both to operate during a transition.
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.
Which aspects are unfriendly? I find configuring gEDA not difficult,
even ata per project level.
John Doty Noqsi Aerospace, Ltd.
[1]http://www.noqsi.com/
jpd@xxxxxxxxx
_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
References
1. http://www.noqsi.com/
_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user