gnucap-devel
[Top][All Lists]
Advanced

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

Re: [Gnucap-devel] gnucap and python


From: al davis
Subject: Re: [Gnucap-devel] gnucap and python
Date: Fri, 23 Mar 2007 23:24:37 -0400
User-agent: KMail/1.9.5

On Friday 23 March 2007 22:50, al davis wrote:
> > - 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.

Sorry .. let me correct that:

Use only the CMD::command(string) interface.  Since your plugin 
will be a class derived from CMD, you can just do 
command("string").

There is "cmdproc" which is intended for user interaction, 
and "command" which is intended for internal calls.  Use 
whichever is appropriate.

They both take a std::string, so you don't need to convert to 
CS.  There is an automatic conversion from char*.

A thought on the python wrapper plugin.  It looks to me that all 
it needs is to call cmdproc and command. How about doing this 
first?


I just thought about adding another: "help".  I decided not to.  
It will be required that help requests go through the string 
interface.

Let's see ....

With the usual command line ..  "help tran" --- finds the 
command "help" and passes on the string.

"tran help" finds the command "tran" and passes in the string.

So, there will be could be a plugin "help" that calls its 
argument with the argument "help". That is trivial.  What would 
be valuable is a command "help" that with no arguments lists 
the commands.  The dispatcher needs some enhancements to do 
this.  Maybe someday....




reply via email to

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