Mail Archives: geda-user/2015/02/08/15:44:53
On 02/08/2015 07:12 AM, Christian Riggenbach wrote:
> have some kind of editor in gschem to "escape" scriptlets. You can define
> accessors for lua objects, so you can parametricate quite simply without
> disturbing the API.
+1 Put parametric changes in a mode of their own. Only gets executed when user asks, then
is there in the schematic file format as static definition, (output from parametric run), and
the parametric script which is just a comment or ignored as far as the netlister can tell.
Changes by using the GUI when outside of parametric mode would allow parametric rules to be broken.
On 02/08/2015 11:44 AM, Chris Smith wrote:> I had thought getting rid of Scheme was one of the design goals, and in my view that
is solving a problem.:)
>
> Joking aside, the issue is that the gschem format isn't native to any language, and anything that uses it must parse it for it
to be of any use. Any application parser (as shown by the netlister) is usually incomplete, because it's considered a waste of
effort to parse features that you don't think people will want and it's difficult to predict how people will use it. By using a
well defined format like Lua,/everything/ is parsed and made available because it/has/ to be.
>
> Am I biased towards Lua? Yes, I'll admit that, but only because I have researched this before and wholeheartedly believe it is
the right tool for the job.
Sounds like replacing the scheme with lua could be a bit more than one mythical-man-month of work
if not done by just one person, so something realistic to consider.
There's still the C language layer. The nitty gritty parts. That needs some architecture
description written before charging ahead with replacing scheme, since much of that deserves redoing to get hierarchic
schematics and netlists working well for anything including embedded verilog logic circuit definitions.
On 02/08/2015 11:55 AM, Christian Riggenbach wrote:> and point 4. In all whole suite,
> you would have the exact same API to access the data, either with C code or
> directly in lua.
But that does not translate all the functions existing as scheme into lua. What are all those functions?
There is not much implementation-neutral written about the architecture of the gschem application.
We need that document to have any chance of a successful rewriting project.
I don't see much descriptive writing happening, so that all may not work out, and we may be occsionally
digging into scheme learning for a good while. The scheme/guile code would not be that bad if there was such a document
existing now.
Creating an architecture specification for gschem is really the important thing to do.
- Raw text -