[GRASS-dev] Re: grass-dev Digest, Vol 21, Issue 1

Glynn Clements glynn at gclements.plus.com
Fri Jan 4 07:37:19 EST 2008


Michael Barton wrote:

> > Gm::errmsg belongs in a "library", i.e. a Tcl source file which can be
> > "source"d from other Tcl source files.
> >
> > Also: gm.tcl calls Gm::errmsg from top-level code at the beginning of
> > the file (the code which copies various g.gisenv settings into $env),
> > although the procedure isn't actually defined until much later in the
> > file. If any of those "catch" statements actually catch an error, the
> > handler will throw an error due to Gm::errmsg being undefined.
> 
> Making a library and moving Gm::errmsg to it is pretty easy to fix  
> (just a LOT of find/replace throughout the GUI code). Anything else  
> that you know of should come out of gm.tcl and into such a library?

One option is to make gm.tcl the library and put the gis.m "main" in a
different file. The function would still be called Gm::errmsg.

Everything up to the "proc Gm::create" line should probably be in a
library, while the stuff following is specific to the gis.m
application.

> However, making the 'get system info' function work is more trouble.  
> As I said in the rest of the post, it's very old code. Is it worth  
> bothering with to have the GUI launch a window with a bit of minimal  
> system info?

It might be useful for dealing with gis.m bug reports.

AFAICT, the only reason it stopped working was the botched conversion
to using Gm:errmsg.

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


More information about the grass-dev mailing list