python bindings
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 
 
 
 
 
 
Felix Salfelder fd9560ef9c release 0.0.6 1 year ago
contrib port custom_ac.py 4 years ago
examples README to md 2 years ago
gnucap fix monolithic build and python3.9 1 year ago
include remove obsolete numpy_interface.{cc,h} 4 years ago
m4 workaround name mangling in AC_CHECK_LIB and fix ax_soname.m4 2 years ago
misc missing Makefile 4 years ago
pending gnucap extension example 4 years ago
tests fix monolithic build and python3.9 1 year ago
.gitattributes gitattributes 4 years ago
.gitignore gitignore release tarball 2 years ago
.gitlab-ci.yml wildcard cat test logs 2 years ago
AUTHORS more author notes. 4 years ago
CONTRIBUTE update CONTRIBUTE 3 years ago
COPYING First import 13 years ago
Makefile.am release 0.0.5 2 years ago
NEWS release 0.0.6 1 year ago
README.md unpropagate, 20200806 2 years ago
THANKS add THANKS 4 years ago
TODO io_trace.trace draft 3 years ago
bootstrap revisit 4 years ago
c_python.cc s/putenv/setenv/ 2 years ago
configure.ac release 0.0.6 1 year ago
gc_log_compiler move tests into tests/ 3 years ago
py_log_compiler move tests into tests/ 3 years ago

README.md

gnucap-python

This package contains a python plugin for the circuit simulator Gnucap which allows the user to implement commands or components (or anything) in Python, and run the simulator in a python environment, e.g. for postprocessing or plotting purposes.

The package also provides a command for Gnucap that loads Python modules, such as Python modules implementing custom commands or components (or anything). See examples.

Your support is gratefully received.

donate

Requirements

requirements are:

  • gnucap >= 20200806
  • Python >= 3.6
  • Swig >= 3.0.0 (tested with 3.0.12, 4.0.1)
  • Numpy (with development headers/libraries)
  • c++11 compiler (known issue with gcc 9, param.py)

Installation

Build python plugin for gnucap

::

$ ./bootstrap $ ./configure # pass PYTHON=some_other_python, to select # pass SWIG=/path/to/some/swig3.0, if needed $ make $ make check # runs tests $ make install # optional. may require root privileges

will install the python module "gnucap" and a gnucap plugin "python".

no Installation

after

::

$ make
$ export PYTHONPATH=.

it should be possible to "import gnucap" from a python interpreter, e.g.

::

$ python3 -c "import gnucap"
$ python3 some/test_or_example.py

Examples

From gnucap

This seems outdated. See examples/README

::

$ gnucap -a python.so gnucap> python example/loadplot.py <= this file is missing, but still. gnucap> get example/eq2-145.ckt gnucap> store ac vm(2) gnucap> ac oct 10 1k 100k gnucap> myplot vm(2)

First, the Python plugin is loaded. The second line loads a new command called "myplot" that plots a stored waveform using matplotlib. Line 3-5 loads a circuit and runs an ac analysis. Finally the ac magnitude of node 2 is plotted using the new plotting command.

From Python

Do the same directly from Python

::

$ python

import gnucap [..] welcome to gnucap-python gnucap.stuff

stuff is not documented much, but closely resembles the libgnucap interface. Exceptions are additional Pythonicity, and some usability hacks. see examples for some applications

Caveats

  • Sometimes tests fail because of stream buffer races. don't know how to synchronize Python output with library output. Check manually...

  • For debugging Python extensions with valgrind, you should set PYTHONMALLOC=malloc. The built-in default allocator, pymalloc, confuses valgrind.

  • Python interface functions ending with _ are "under construction". These may be replaced or superseded by a more Pythonic approach later on.

  • Generally you are advised to use gnucap packages from your distribution. If Gnucap is installed manually and with a custom prefix, you might have to pass

    LDFLAGS=-L$prefix/lib to configure. also export LD_LIBRARY_PATH=$prefix/lib before you run gnucap-python.

    *** on some systems /usr/local is considered "custom", on others a dirty cache interferes with the linker. YMMV, tell me your workarounds ***

  • the clone hack. currently, the clone override needs to keep a local reference to the returned python object. it boils down to an incompleteness in swig. generated code looks like

    c_result = reinterpret_cast< CARD * >(swig_argp); swig_acquire_ownership_obj(SWIG_as_voidptr(c_result), own /* & TODO: SWIG_POINTER_OWN */); return (CARD *) c_result;

    maybe a future swig will allow a better approach. NB: the clone override is now optional, and a default is taking care of this.

  • python sometimes generates .pyc files containing cached bytecode in random places. these may lead to weird error messages, if they are outdated. delete them.