Re: asco and gnucap

Hi.

On Wed, Jan 11, 2012 at 10:04:16AM -0500, al davis wrote:
> 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.

a loop would be a nice thing to have (in fact ive implemented a very
hackish one, long before i understood the LANGUAGE mechanism), also
would be an optimization script.
but then i think its great to have choices. like asco does allow the use
of ones favourite simulator.... and not even asco is used/maintained
very much (as it seems).

> I did, and am considering incorporating some of your changes.
thanks for taking the time.

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

i consequently use cerr for error reporting. so i do in gnucap. when
using stdout for data i dont even have much choice (and asco is hardly
the only scanario in which gnucap output is postprocessed).

if you care about synchronization, you can still tie() streams together.

> The new commands can be added in a plugin.  That's what plugins 
> are for.
the asco branch was a quick hack so anyone may try asco with it.
but also, i think the commands i added arent big enough to justify the
.so hassle.
(btw, gnucap should install headers and deliver a gnucap-conf script
to simplify out-of tree so-builds. this would fit well in a gnucap-dev
package. ask me about it, if you care.)

> moving getlines .. I like the idea .. need to do some testing in 
> all modes.
i'm not even sure why i implemented that. it might simplify fixing
the verilog parser (i recall that paramset bug...).

> What's wrong is low activity.
and yes -- i mixed something up, theres no further problem with the
list.

regards
felix