[Maxima-bugs] [ maxima-Bugs-813659 ] xgraph broken (Windows)

[SourceForge.net <no...@so...>]

Bugs item #813659, was opened at 2003-09-27 12:01
Message generated for change (Settings changed) made by robert_dodier
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=104933&aid=813659&group_id=4933

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: Lisp Core - Plotting
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Stavros Macrakis (macrakis)
Assigned to: Nobody/Anonymous (nobody)
Summary: xgraph broken (Windows)

Initial Comment:
xgraph_curves (using the bar graph example in the doc) 
puts up a second window, and it immediately closes.

I suspect that xgraph is not supported on Windows, but 
if that is true, it should give a clean error, not just fail 
silently.

Maxima 5.9.0 gcl 2.5.0 mingw32 W2k Athlon


----------------------------------------------------------------------

Comment By: Robert Dodier (robert_dodier)
Date: 2003-12-10 12:01

Message:
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

----------------------------------------------------------------------

Comment By: Stavros Macrakis (macrakis)
Date: 2003-12-09 19:10

Message:
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?  

----------------------------------------------------------------------

Comment By: Robert Dodier (robert_dodier)
Date: 2003-12-09 17:58

Message:
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?



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=104933&aid=813659&group_id=4933