Maxima -- GPL CAS based on DOE-MACSYMA

xgraph has been cut out with revision 1.136. Closing this bug report.

I tried the example from the manual and it doesn't work: xgraph_curves
loops endlessly, writing NIL into xgraph-out.

After considering the state of xgraph_curves, I have concluded it would be
a waste of time to fix it. It has likely never worked as advertised (not
since it was maintained by Bill Schelter), doesn't work now on any
platform, and cannot run without further intervention on the user's part
(since xgraph must be installed separately from Maxima). There are many
plotting programs with similar features, I don't see a good reason to
support this one in particular. If someone wants to plot stuff with xgraph
or any similar program they can just write stuff into a file and plot that.
That's all xgraph_curves does anyway.

The Maxima plotting code is a mess of more or less maintained code for
more or less popular plotting programs. Xgraph falls in the "less" category
on both counts. We have enough trouble with plotting as it is; there's no
need to increase the burden on developers by taking on the task of
maintaining yet another random plotting program.

I'm going to cut out the xgraph stuff. I'll run a message on the mailing
list and go ahead if there isn't too much opposition.

When xgraph is not installed on Windows the following error message is
printed:

(%i3) xgraph_curves([]);
Der Befehl "xgraph" ist entweder falsch geschrieben oder
konnte nicht gefunden werden.
(%o3) 0

Following version of xgraph can be downloaded for Windows:
xgraph1_3.zip (152-KB) [5-18-2006] - For MS-Windows '98, 2000, NT, and XP.
Runs natively. Nothing else needed. (Does not depend on Cygwin or any other
libraries.)

With this version installed xgraph seems to work. A window opens when
typing xgraph_curves([]). But the example from the manual gives a Lisp
Error:

(%i30) l:[append (["BarGraph: true", "NoLines: true","BarWidth: 0.2"],
create_list ([i - 0.2, i^2], i, 1, 3)),append (["BarGraph: true", "NoLines:
true", "BarWidth: 0.2"],create_list ([i + 0.2, 0.7*i^2], i, 1, 3))]$

(%i31) xgraph_curves(l);
Maxima encountered a Lisp error:

Error in MACSYMA-TOP-LEVEL [or a callee]: NIL is not of type (OR
RATIONAL

LISP:FLOAT).
Automatically continuing.
To reenable the Lisp debugger set *debugger-hook* to nil.

I have not tested xgraph_curves on my linux system and I have not tried to
figure out a new example, but the Lisp Error might not to be a windows
problem.

Dieter Kaiser

Logged In: YES
user_id=501686

On further reflection, I am inclined to believe that the
xgraph code should be moved out of src/plot.lisp and into a
share file. There's no way to make it work cross platform,
so we shouldn't include it in Maxima core.

Logged In: YES
user_id=501686

I don't think there is a function like "which" in Windows.

One approach is to beef up the $system function (through
which the plotting helper apps are launched) to check the
exit code. If the exit code is zero, the command executed OK
-- I believe this is true for Windows, certainly so for
Unix. Otherwise there was some problem. I think this will be
useful in contexts other than plotting.

Now that I think about it, if there is an error I think the
plotting routines should just notice it and complain about
it, without trying to execute some alternative.

$system is implemented in a different way for each kind of
Lisp. I think the return value for $system should be the
exit code for the command it tried to execute.

Clisp: $system executes ext:run-shell-command; on my setup
(Clisp 2.31) the return value for that function is the exit
code, but I can't find that behavior documented -- the
on-line man page I found [1] doesn't have a pointer to a
Clisp manual, but only says that Clisp "mostly" implemented
the CL HyperSpec, which in turn has no entry for
run-shell-command. Oh well.

Cmucl: $system executes ext:run-program, and the return
value for that function is nil or a process structure, and
the function ext:process-exit-code gets the exit code from
that structure. This is according to [2].

GCL: $system executes system; I can't tell what the return
value is -- the one reference I located [3] says only "GCL
specific: Executes a Shell command as if STRING is an input
to the Shell. Not all versions of GCL support this function."

[1] http://clisp.cons.org/clisp.html
[2]
http://www.ljosa.com/~ljosa/doc/encycmuclopedia/devenv/cmu-user/extensions.html#@funs29
[3]
http://www.sunsite.ualberta.ca/Documentation/Gnu/gcl-2.3.6/html_mono/gcl-si.html

Logged In: YES
user_id=588346

I don't know how to handle cross-platform systems issues like
this, so my proposals may be naive. Can't Maxima check the
return code from the (system...) call? And what about
checking whether the xgraph executable exists in $PATH? Is
the Unix 'which' command supported cross-platform?

Logged In: YES
user_id=501686

I believe the problem is that the plotting functions execute
helper applications to display plots. In this case, the
helper is xgraph.

Xgraph was/is a simple minded plotting program for X
windows. It may have been ported to Windows, but if so I'm
sure it is installed on very few machines. So for the vast
majority of Windows boxes (and for many Unix boxes as well),
the xgraph helper cannot be launched.

It seems like the right thing is to look for the helper
(xgraph, gnuplot, ghostview, whatever) and complain if it's
not found, and then fall back on a default method. But what
is a portable way to determine if the helper app is present?