Re: [Gnucap-devel] asco and gnucap

[al davis]

On Tuesday 20 December 2011, Felix Salfelder wrote:
> ive hacked a few lines into asco for it to support gnucap.
> as it seems, there is no asco list and the asco deveoper is
> busy with other things. somebody might be interested anyway.
> 
> ive tried to implement a serious pipeline based interface
> between asco and gnucap. it was fun to implement, but i even
> expect some speedup, from not having expand netlists and
> find operating points over and over again -- depending on
> the use-case. the inverter example shows that it works.

There are plans to make the output pluggable, in the same sense 
as the other gnucap plugins.  It's one of the projects that got 
delayed last year when I other issues to contend with.  I held 
off to avoid delaying a stable release, then there were other 
factors that delayed it anyway.

I have also considered what it would take to do optimization as 
a gnucap script.  The critical missing piece is a loop.  This 
leads to the need for "for" and "while" loop plugin, that uses 
parameter values.  It has lots of uses.  Another need that could 
then be done easily as a script is periodic steady state 
analysis.


> get a clone of my asco repo typing
> git clone git://tool.em.cs.uni-frankfurt.de/git/asco --branch
> gnucap the current status of README.gnucap is attached to
> this mail.

I did, and am considering incorporating some of your changes.

Some comments ..

io_trace.h ... send to stderr instead of stdout.
At first I thought "good idea" .. then I remembered why I didn't 
do it that way.
First, that printing only happens with a "debug" build, compiled 
with debugging enabled, so non-developers should never see those 
messages.
For debugging, if the messages are sent to stderr, the OS 
buffers them separately so they come out out of sync with the 
regular output, making  them less useful for debugging.
Since you bring it up, it IS a good idea to be able to turn them 
off even in a version compiled with debugging on.
Compiling with debugging on has a significant speed penalty.

The new commands can be added in a plugin.  That's what plugins 
are for.

moving getlines .. I like the idea .. need to do some testing in 
all modes.




> 
> regards
> felix
> 
> PS: there are mails missing in the list archives. must be
> something wrong with
> http://lists.gnu.org/archive/html/gnucap-devel/

What's wrong is low activity.