[Gnucap-devel] Contributing to Gnucap (fwd)

[Nenad Ocelic]

---------- Forwarded message ----------
Date: Fri, 12 Apr 2002 22:35:21 +0200 (MET DST)
From: Nenad Ocelic
To: Al Davis
Subject: Re: Contributing to Gnucap

> Any of the contributions you mention will be good.  They are all
> important.  It is hard to say which is most important.
Since you have no preference for one of the topics I mentioned, I have
decided to take care of the plotting business for the beginning. My
primary motivation was the expected simplicity of that task (compared
to the other three options).

Part 1: Graphic postprocessor
------------------------------
> Making Gwave work with Gnucap really means making it work
> automatically, with the appearance of being tightly coupled.  The
> file format already does work.  It is the same format as CaZM, which
> was one of the first formats for Gwave to support.

Before I actually start the operations, I'd like to see your idea about
the way the plotter should be used from within the gnucap (given that it
would be a separate executable).

Personally, I can imagine the situation where there is an option
like "PLOTTER" which would specify whether to:
1) draw an ASCII plot (as it does now),
2) launch an external viewer to inspect a temporary file,
3) launch an external viewer and supply it a continuous stream of plot
   points through an unnamed pipe,
4) Feed the plot points to a named pipe
The list of possible values for the PLOTTER option would then read
something like this:
1) Ascii (reamining default for compatibility reasons)
2) File
3) Pipe
4) FIFO

Since 1) is already functional, I guess the only thing that remains to be
done for 2)..4) is to make the PLOT use the existing PRINT mechanism (with
the appropriate destination set). Additionally, the plotting system would
launch whatever is given as the "target" option, before or after the
simulation. The TARGET may be an absolute path to the executable or the
name to be searched for on the $PATH. In the case of FIFO plotter, the
TARGET could contain the name of the FIFO file to be created.
Of course, the restriction of plotting to two signals only could be waived
for the graphical viewers.

(I haven't succeeded yet in finding the complete path of the print
machinery in order to reuse it for plotting, but I guess it resides mostly
in io_out.cc and s__out.cc. I'll have to look at it more carefully unless
you save me some time with a hint.)

Note 1: The plotter option could perhaps be extended beyond the
        forementioned options to include unix and/or internet domain
        sockets.
Note 2: The fact that pipes may block the simulator is not only a
        drawback; it can be be used to control the pace of simulation
        by the viewer.

Now, do my ideas for the plotting system look like yours, or do you have
something else in mind? Please let me know.


Part 2: Everything else
-----------------------
> Gnu (Richard Stallman) tends to prefer Guile as the scripting
> language, but I prefer an object oriented language (Python or Ruby.)
> How the language is licensed is an issue.  Of course GPL is good, and
> there is a track record saying the Python is ok.
Me too dislikes Guile. And if we are choosing between Python and Ruby,
there is no real doubt IMO: Ruby has a "softer" license (it is at worst
GPL) and does not suffer from that awkward code indentation. There are
some more subtle details which I think also tend to favor Ruby, but may
quite as well be subject to a discussion.
When I think of binding a script language to gnucap, I wonder if it
would be more natural to make gnucap an extension to (say) Ruby than to
embed an interpreter into gnucap.
Making gnucap an extension to a scripting language would require it to be
casted into the form of a library, which can then be (statically) linked
to a simple front end to make it stand-alone, or may be linked (either
statically or dynamically) to the more complex system like the scripting
language.
For that price one would then get more flexibility in the use of gnucap,
compared to the solution with the embedded interpreter, or at least I
am inclined to believe so. What about you?

> On interfacing to Oregano ...  It is pretty close.  There are two
> points of incompatibility.  The first is the ".control" statements.
> These could be added to Gnucap fairly easily.  The second is the
> output file format.  Oregano reads the Spice "rawfile" format, which
> is only used by Spice and its readers.  Gnucap uses plain column
> oriented files, readable directly by Gnuplot, Gwave, and all
> spreadsheets.
According to your description, the incompatibilities don't seem to be
insurmountable. However, there is one little but important piece of
information I was missing when I proposed to use Oregano as an interface.
>From the Oregano web page:
"2002-03-25: Oregano is no longer actively maintained.
Please check out GAEL instead."
But from what I have seen, GAEL is still far from the point of usability.
Any better news from your side?


        Nenad