[Gnucap-devel] gnucap and python

[Cyril Giraudon]

Hi Al,

Gnucap python wrapper is still not dead :-)

I thought I would be able to work on the Gnucap wrapper a few month ago. 
But, I was wrong...
But now, I have to decide.

I 've get a glance at Eispice. You certainly know this project. It's a 
circuit simulator with a python interpreter.
I've contacted the author (mailing list) and apparently Eispice is not 
enough stable to be used in production.
The question was the redundancy of the work.

This time, I know I can work on this project more than a few hours.

I base the following reasoning upon the version 0.35 of Gnucap.
I'm very impressed by Gnucap, its facilities, the clarity of your coding 
style, without it, I wouldn't be able to discover and study the source 
code so easily.

So, I come back with the CS class (see my last message of the 20 09 2006 
in gmane.comp.cad.geda.devel reproduced below if you need) , I 'd like 
to clarify my mind about that question.
I understand CS is very useful to bring informations from the command 
line to the core of Gnucap, this way of doing is very flexible, but I 
think, there must be a border between a framework 
(computation/simulation core) and its client (interpreter).

- With the CS class, the interpreter is very intrusive in the simulation 
core (s__init.cc / SIM::command_base for instance), and I don't know the 
way to use the simulation functions directly without rewrite the entire 
functions ( SIM::command_base ), do they exist ?
- I think, the interpreter has to prepare the parameters (Hard use of CS 
capabilities, string parsing ....) for the final launch of the compute 
with well identified parameters (a, b, c, d, ....)
- From a pure informatics point of view, the only parameter of methods 
and functions is a CS instance. The compilation stage can't bring a good 
help for debugging the code (parameters matching ...) and there are 
still some parsing operations in TRANSIENT::options which is very deep 
in the architecture compared to the command line.
- The unit tests of each functions are not facilitated
- I think the development would be easier with clear interface for each 
methods (see IDL for CORBA, COM, XPCOM for the philosophy of the idea).
- Now, if I think about the wrapping process. The way to use a python 
module would be :

import gnucap
gnucap.get("aCircuitFile")
gnucap.tran(start=0, end=1e-3)

(
circuit = gnucap.get("aCircuitFile")
circuit.tran(start=0, end=1e-3)
would be even better.
)

If the wrapper keeps the CS class :
import gnucap
gnucap.command("get aCircuitFile")
gnucap.command("tran 0 1e-3")

The introspection facilities of python can not used, no native help 
because there's only one function. A huge interest in using python, for 
instance, is its introspection capabilities. The interpreter can show 
all available functions, objects and methods of a module or another 
object and their input parameters. The built-in help method prints the 
inline help of an object (help string localized in the source code, no 
(less) need of html/paper help).
In order to implement these mechanisms with Gnucap, the wrapper will 
have to propose (and build) to the user, all the methods of the 
c__cmd.cc file with the proper number of parameters (some optional, why 
not). And then, the CS instance will be built and sent to the native 
method(CS &cmd). Then, parameters will be one more time extracted from 
the CS instance et finally the compute can run.

The wrapping process is not easy and redundant with the deeper use of 
the CS instance.
I don't ask to modify this part of Gnucap, it would a hard work (if you 
would agree :-) ),
I hope simply I present clearly my mind and expose different way of 
programming.
I repeat I like Gnucap, I don't want to upset you. It is really an 
amazing work.

Have you planned to complete the encapsulation of the CIRCUITS, SIM 
(hesitated classes) classes ?
circuit = gnucap.get("aCircuitFile")
circuit.tran(start=0, end=1e-3)
or
circuit = gnucap.Circuit("aCircuitFile")
transientSimulation = gnucap.Transient(circuit)
transientSimulation.run(0, 1e-3)


I hope this wrapper project finally really start...

Best regards,

Cyril.


###########################################################################
My python front-end project for a circuit simulator is not
> dead, but the time missed me during the past few months.
>
> It was not so urgent (until now :-)) and I continue looking
> at gnucap sources, ngspice sources to know the best candidate
> for the front-end.
>
> In a precedent thread (may 2006) , I precised that this stuff
> was for my job but it seems today it's not incompatible with
> a contribution to the gEDA project.
> The following reasonnings continue the thread of may 2006.
>
> Gnucap is more flexible than ngspice at source level and
> compilation level. Releases come out regularly. Compilation
> is easy on linux and windows. Good points.


> > However, its seems that the CS class is in the heart of
> > gnucap.  In general methods take a (CS &cmd) input parameter.
> > So the own gnucap script language is deep rooted in code.
>   

Think of that CS class as a smart "istream", with expression 
matching and other goodies.  You can also think of it as a 
smart string, assorted extras.  You can build a CS object very 
easily, just convert a string, or a C-string, or even a whole 
file.  It is really easy to use.

CS cmd("hello, this is a string!!");

or ...

char* foo = "here's another";
CS ff(foo);

It is only used for passing text arguments.


> > The consequence is that a front-end will simply build itself
> > the "cmd" instance corresponding to the context of a class
> > circuit instance, then call the CMD::cmdproc(cmd) the most of
> > the time.
>   

You could call the functions directly.  CMD::cmdproc insulates 
you from possible changes underneath.  You can use a pipe with 
text to communicate between processes.  There are lots of 
advantges.  It even handles partial matches.

The CS class is not dependent on gnucap.  I use it in lots of 
other stuff too.  I recommend it highly for command line 
interfaces and parsing input files.


> > (A python circuit class instance will be a Gnucap subckt.
> > The circuit class will implement the gnucap "build"
> > capability. One iteration of simulation at a time.
> > Each iteration will return the probed values.)
> > I will precise the functionnal features later.
> >
> > I thought I would call directly the gnucap methods under the
> > following form "transient(start=0, end=12e6, step=0.5e-6)"
> > for instance and not "transient(cmd)".
> > I don't know if it's better.
>   

try:
transient("start=0, end=12e6, step=0.5e-6");

or if you want to mess with one argument:
transient("trace=all");

Actually, you need to explicitly convert it:

CS x = "trace=all";
transient(x);

because of an object lifetime issue.


> > Is my understanding of Gnucap mechanisms good ?
>   
Getting there...



---------------------------------------------------------------------------------------
Orange vous informe que cet  e-mail a ete controle par l'anti-virus mail. 
Aucun virus connu a ce jour par nos services n'a ete detecte.