[GRASS-dev] Re: [GRASS-user] GRASS6.3 on Windows

[Glynn Clements]

Paul Kelly wrote:

> >> Works for me starting it both those ways, and also from command-line. I
> >> even tried make distclean and compiling from scratch in case there was
> >> something I'd manually fixed that kept it working on my system. So I don't
> >> know what could be up with yours. Maybe you have an old nviz.exe lying
> >> around in your PATH somewhere that is getting picked up when the GUI runs
> >> "nviz", instead of Glynn's new nviz.bat?
> >>
> >> A couple of side-notes though:
> >> 1) In general the GUI is terrible at catching and reporting errors from
> >> modules it calls in the background and this leads to cryptic error
> >> messages or nothing happening all over the place. IMHO it is a really
> >> pervasive problem that definitely needs fixed in the next GUI. Hopefully
> >> it already is there (ISTR discussions about every call to a GRASS module
> >> going through some other function where the error trapping could
> >> presumably be added, to avoid code repetition).
> >
> > Actually, error trapping is pretty good in the GUI now, except for NVIZ (but
> > which doesn't run much in the way of GRASS commands anyway). There are traps
> 
> Well maybe I was being a bit overly dramatic, but running
>   grep "exec " *.tcl | grep -v catch | wc -l
> in the gis.m directory still reveals 72 lines where exec is used without a
> corresponding catch. Not very scientific and perhaps not important in most
> cases - but if a single command (be it a GRASS module or system command)
> is not available or not working for some reason it could really make the
> difference between somebody tearing their hair out for a day or finding 
> the source of a problem quickly.
> 
> > around all (or perhaps nearly all) GRASS commands that run through the GUI
> > that will kick out any GRASS errors to the terminal or a message box.
> 
> Note that I'm not talking here about "expected" errors that come from bad 
> user data or some kind of error that's handled by G_fatal_error() or 
> whatever inside a GRASS command - I'm thinking more of unexpected errors 
> caused perhaps by a library not being installed properly or files being 
> corrupted on the user's system. Perhaps it's not a big deal right now and 
> perhaps Python will make it much easier to do than Tcl or even do it 
> automatically.

A catch only helps if you do something useful once you've caught the
exception.

If the caller is relying upon the procedure to return information, and
the inability to execute the program means that the information cannot
be obtained, then there isn't any practical alternative to allow the
exception to propagate up to the caller.

Sometimes it may be worthwhile catching an exception just so that you
can re-throw the exception with additional data. But in the case of
exec failing, the specific error (e.g. "unable to load shared library
libfoo.so") needs to be retained.

> > In fact it is possible to write NVIZ script code that can do pretty much
> > what you want. I don't know how to do it, but you should be able type script
> > commands to control the visualization and open NVIZ with this script (Maybe
> > you can even cat these into NVIZ in a *nix system--though I don't know if
> > this is possible or not).
> 
> What I was getting at is that you don't have to use NVIZ and/or Tcl/Tk to 
> create 3-D views in GRASS. NVIZ is just a Tcl/Tk interface to the gsurf 
> library (lib/ogsf) which is written in C. So my idea was to write some new 
> C modules that link against libgrass_ogsf and duplicate the functionality 
> of NVIZ but in a much more easily scriptable way. I'll keep quiet about it 
> again though unless I actually get time to see how easy it is to do, as I 
> really am not too sure how much work it would be.

One thing to bear in mind is that you still need OpenGL. In practice,
this means that any such scripts need access to a GLX-capable X
server.

Also, you need to create the drawing "canvas" (a pBuffer or GLXPixmap
will suffice *if* the server supports them, otherwise you need to
create a window).

Alternatively, you can use an OSMesa context if you have OSMesa and
your libGL supports it (i.e. you have the standard X.org libGL, not
nVidia's version).

-- 
Glynn Clements <glynn at gclements.plus.com>