pyNgSpice

Brian Taylor 4530cde8e2 Use Xspice cm_message_send to report errors rathen than printing to stderr and calling exit. When a d_process model has errors found in start(), sendheader(), and dprocess_exchangedata() these are reported, but if the model is run a SIGINT is raised. There must be a better way of stopping the simulator.		2 years ago
..
Monte_Carlo	Another attempt at clean up of error handling and reporting. It's OK on limux and cygwin, but Windows VisualC is being stubborn. I would prefer not to have to call exit(1) just for Windows, since then nothing is reported and the gui disappears in a puff of smoke. Even without the exit calls nothing gets reported with the Windows gui which will hang when there are errors detected by d_process.	2 years ago
TransImpedanceAmp	Another attempt at clean up of error handling and reporting. It's OK on limux and cygwin, but Windows VisualC is being stubborn. I would prefer not to have to call exit(1) just for Windows, since then nothing is reported and the gui disappears in a puff of smoke. Even without the exit calls nothing gets reported with the Windows gui which will hang when there are errors detected by d_process.	2 years ago
TransmissionLines	Another attempt at clean up of error handling and reporting. It's OK on limux and cygwin, but Windows VisualC is being stubborn. I would prefer not to have to call exit(1) just for Windows, since then nothing is reported and the gui disappears in a puff of smoke. Even without the exit calls nothing gets reported with the Windows gui which will hang when there are errors detected by d_process.	2 years ago
adms	Another attempt at clean up of error handling and reporting. It's OK on limux and cygwin, but Windows VisualC is being stubborn. I would prefer not to have to call exit(1) just for Windows, since then nothing is reported and the gui disappears in a puff of smoke. Even without the exit calls nothing gets reported with the Windows gui which will hang when there are errors detected by d_process.	2 years ago
cider	Another attempt at clean up of error handling and reporting. It's OK on limux and cygwin, but Windows VisualC is being stubborn. I would prefer not to have to call exit(1) just for Windows, since then nothing is reported and the gui disappears in a puff of smoke. Even without the exit calls nothing gets reported with the Windows gui which will hang when there are errors detected by d_process.	2 years ago
control_structs	S-parameters: Replace S11 by S_1_1 etc. to avoid ambiguity	4 years ago
ddt	Another attempt at clean up of error handling and reporting. It's OK on limux and cygwin, but Windows VisualC is being stubborn. I would prefer not to have to call exit(1) just for Windows, since then nothing is reported and the gui disappears in a puff of smoke. Even without the exit calls nothing gets reported with the Windows gui which will hang when there are errors detected by d_process.	2 years ago
digital	Another attempt at clean up of error handling and reporting. It's OK on limux and cygwin, but Windows VisualC is being stubborn. I would prefer not to have to call exit(1) just for Windows, since then nothing is reported and the gui disappears in a puff of smoke. Even without the exit calls nothing gets reported with the Windows gui which will hang when there are errors detected by d_process.	2 years ago
hicum2	Another attempt at clean up of error handling and reporting. It's OK on limux and cygwin, but Windows VisualC is being stubborn. I would prefer not to have to call exit(1) just for Windows, since then nothing is reported and the gui disappears in a puff of smoke. Even without the exit calls nothing gets reported with the Windows gui which will hang when there are errors detected by d_process.	2 years ago
inductive-systems	Another attempt at clean up of error handling and reporting. It's OK on limux and cygwin, but Windows VisualC is being stubborn. I would prefer not to have to call exit(1) just for Windows, since then nothing is reported and the gui disappears in a puff of smoke. Even without the exit calls nothing gets reported with the Windows gui which will hang when there are errors detected by d_process.	2 years ago
klu/Circuits	Added missing ISCAS85 libraries	3 years ago
loops	Another attempt at clean up of error handling and reporting. It's OK on limux and cygwin, but Windows VisualC is being stubborn. I would prefer not to have to call exit(1) just for Windows, since then nothing is reported and the gui disappears in a puff of smoke. Even without the exit calls nothing gets reported with the Windows gui which will hang when there are errors detected by d_process.	2 years ago
measure	Another attempt at clean up of error handling and reporting. It's OK on limux and cygwin, but Windows VisualC is being stubborn. I would prefer not to have to call exit(1) just for Windows, since then nothing is reported and the gui disappears in a puff of smoke. Even without the exit calls nothing gets reported with the Windows gui which will hang when there are errors detected by d_process.	2 years ago
memristor	Another attempt at clean up of error handling and reporting. It's OK on limux and cygwin, but Windows VisualC is being stubborn. I would prefer not to have to call exit(1) just for Windows, since then nothing is reported and the gui disappears in a puff of smoke. Even without the exit calls nothing gets reported with the Windows gui which will hang when there are errors detected by d_process.	2 years ago
mos	Another attempt at clean up of error handling and reporting. It's OK on limux and cygwin, but Windows VisualC is being stubborn. I would prefer not to have to call exit(1) just for Windows, since then nothing is reported and the gui disappears in a puff of smoke. Even without the exit calls nothing gets reported with the Windows gui which will hang when there are errors detected by d_process.	2 years ago
noise	Another attempt at clean up of error handling and reporting. It's OK on limux and cygwin, but Windows VisualC is being stubborn. I would prefer not to have to call exit(1) just for Windows, since then nothing is reported and the gui disappears in a puff of smoke. Even without the exit calls nothing gets reported with the Windows gui which will hang when there are errors detected by d_process.	2 years ago
numparam	Another attempt at clean up of error handling and reporting. It's OK on limux and cygwin, but Windows VisualC is being stubborn. I would prefer not to have to call exit(1) just for Windows, since then nothing is reported and the gui disappears in a puff of smoke. Even without the exit calls nothing gets reported with the Windows gui which will hang when there are errors detected by d_process.	2 years ago
optran	Another attempt at clean up of error handling and reporting. It's OK on limux and cygwin, but Windows VisualC is being stubborn. I would prefer not to have to call exit(1) just for Windows, since then nothing is reported and the gui disappears in a puff of smoke. Even without the exit calls nothing gets reported with the Windows gui which will hang when there are errors detected by d_process.	2 years ago
osdi	Use the PSP103 model pspnqs103va (including nqs option)	2 years ago
p-to-n-examples	Another attempt at clean up of error handling and reporting. It's OK on limux and cygwin, but Windows VisualC is being stubborn. I would prefer not to have to call exit(1) just for Windows, since then nothing is reported and the gui disappears in a puff of smoke. Even without the exit calls nothing gets reported with the Windows gui which will hang when there are errors detected by d_process.	2 years ago
plot	plotting/grid.c, bug fix, avoid string buffer overflow	8 years ago
probe	Another attempt at clean up of error handling and reporting. It's OK on limux and cygwin, but Windows VisualC is being stubborn. I would prefer not to have to call exit(1) just for Windows, since then nothing is reported and the gui disappears in a puff of smoke. Even without the exit calls nothing gets reported with the Windows gui which will hang when there are errors detected by d_process.	2 years ago
proc2mod	Another attempt at clean up of error handling and reporting. It's OK on limux and cygwin, but Windows VisualC is being stubborn. I would prefer not to have to call exit(1) just for Windows, since then nothing is reported and the gui disappears in a puff of smoke. Even without the exit calls nothing gets reported with the Windows gui which will hang when there are errors detected by d_process.	2 years ago
pss	Another attempt at clean up of error handling and reporting. It's OK on limux and cygwin, but Windows VisualC is being stubborn. I would prefer not to have to call exit(1) just for Windows, since then nothing is reported and the gui disappears in a puff of smoke. Even without the exit calls nothing gets reported with the Windows gui which will hang when there are errors detected by d_process.	2 years ago
snapshot	Another attempt at clean up of error handling and reporting. It's OK on limux and cygwin, but Windows VisualC is being stubborn. I would prefer not to have to call exit(1) just for Windows, since then nothing is reported and the gui disappears in a puff of smoke. Even without the exit calls nothing gets reported with the Windows gui which will hang when there are errors detected by d_process.	2 years ago
soa	Another attempt at clean up of error handling and reporting. It's OK on limux and cygwin, but Windows VisualC is being stubborn. I would prefer not to have to call exit(1) just for Windows, since then nothing is reported and the gui disappears in a puff of smoke. Even without the exit calls nothing gets reported with the Windows gui which will hang when there are errors detected by d_process.	2 years ago
soi	Another attempt at clean up of error handling and reporting. It's OK on limux and cygwin, but Windows VisualC is being stubborn. I would prefer not to have to call exit(1) just for Windows, since then nothing is reported and the gui disappears in a puff of smoke. Even without the exit calls nothing gets reported with the Windows gui which will hang when there are errors detected by d_process.	2 years ago
sp	Another attempt at clean up of error handling and reporting. It's OK on limux and cygwin, but Windows VisualC is being stubborn. I would prefer not to have to call exit(1) just for Windows, since then nothing is reported and the gui disappears in a puff of smoke. Even without the exit calls nothing gets reported with the Windows gui which will hang when there are errors detected by d_process.	2 years ago
svg	hcopywidth and hcopyheight failed with SVG plot	4 years ago
tclspice	Another attempt at clean up of error handling and reporting. It's OK on limux and cygwin, but Windows VisualC is being stubborn. I would prefer not to have to call exit(1) just for Windows, since then nothing is reported and the gui disappears in a puff of smoke. Even without the exit calls nothing gets reported with the Windows gui which will hang when there are errors detected by d_process.	2 years ago
transient-noise	Another attempt at clean up of error handling and reporting. It's OK on limux and cygwin, but Windows VisualC is being stubborn. I would prefer not to have to call exit(1) just for Windows, since then nothing is reported and the gui disappears in a puff of smoke. Even without the exit calls nothing gets reported with the Windows gui which will hang when there are errors detected by d_process.	2 years ago
utf-8/стекло	Upgrade due to recent ngspice enhancements	5 years ago
various	Another attempt at clean up of error handling and reporting. It's OK on limux and cygwin, but Windows VisualC is being stubborn. I would prefer not to have to call exit(1) just for Windows, since then nothing is reported and the gui disappears in a puff of smoke. Even without the exit calls nothing gets reported with the Windows gui which will hang when there are errors detected by d_process.	2 years ago
vbic	Added initial KLU support for node collapsing	3 years ago
vdmos	Add vto model parameter (the default has changed!), add .ic	3 years ago
xspice	Use Xspice cm_message_send to report errors rathen than printing to stderr and calling exit. When a d_process model has errors found in start(), sendheader(), and dprocess_exchangedata() these are reported, but if the model is run a SIGINT is raised. There must be a better way of stopping the simulator.	2 years ago