[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnucap-devel] asco and gnucap
From: |
Felix Salfelder |
Subject: |
Re: [Gnucap-devel] asco and gnucap |
Date: |
Wed, 11 Jan 2012 20:38:22 +0100 |
User-agent: |
Mutt/1.5.20 (2009-06-14) |
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