[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnucap-devel] gnucap and python

From: Cyril Giraudon
Subject: [Gnucap-devel] gnucap and python
Date: Fri, 23 Mar 2007 20:12:44 +0100
User-agent: Thunderbird (Windows/20061207)

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 ( / 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.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 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)
circuit = gnucap.Circuit("aCircuitFile")
transientSimulation = gnucap.Transient(circuit), 1e-3)

I hope this wrapper project finally really start...

Best regards,


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.

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

or if you want to mess with one argument:

Actually, you need to explicitly convert it:

CS x = "trace=all";

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]