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 _______________________________________________ Gnucap-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnucap-devel
