Re: [Gnucap-devel] gnucap and python

[al davis]

On Friday 23 March 2007 15:12, Cyril Giraudon wrote:
> 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.

I have seen it, had to look back for a reminder.

It's a lightweight, in the sense that it is a simple simulator.  
I contacted him a while back, asked him if he wanted to help 
with gnucap.  He said he was having too much fun on his own.

So, I don't think it will be a true duplicate for a long time, 
but it may fill a real need for a simple simulator you can 
study to get started.

> 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.

If you are doing development, get the development snapshot.  It 
has support for plug-ins.  All commands and devices will be 
moving out to plugins.  The plug-in mechanism, with a wrapper, 
even allows the use of Spice C models, with no modifications.  
There are separate tarballs with all of the BSIM models, and 
the NGspice models.

> 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). 

It also provides a portable interface, that is visible across 
plug-ins.  Please use it.

> - 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 ?

Don't use them directly.  Please use the CS interface.  With 
plug-ins, you don't have direct access to the internal 
functions anyway.  That string is the only interface you have.

That is a deliberate design decision to isolate the inside, so 
other parts of the simulator are not dependent on specifics of 
the implementation.

> - 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 compiler cannot because that is a run time error.  A CS 
instance will adequately take care of that at run time.  That's 
part of what the CS class is all about, as opposed to just a 
string.

> - 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.
> )

What if "get" is not installed?  What if "tran" is not 
installed?  What about the "harmonic" command?  the "noise" 
command?  What if the user replaces the "tran" command with his 
own modified one?

All commands have an identical interface: a string.

You don't know what commands will be available, because users 
will each install whatever commands and aliases they want.

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

I think you will see that this approach is much more powerful 
than specific function calls, and you can take advantage of it.

If you look a the gnucap code, you will see that I always do it 
that way.

> The introspection facilities of python can not used, no
> native help because there's only one function.

Hmmm......   need to add "help" function, one for each command.  
Thanks for the idea.

Look at the development snapshot, with plugins. 

Here's an idea, for something really important:  A plug-in 
python wrapper, that will enable you to write plugins in 
python.  The wrapper itself needs to be a plugin.

When you see how plugins work, you will see why the interface is 
so strict.