[GRASS-dev] Re: grass-dev Digest, Vol 23, Issue 112

GRASS GRASS developer
1

On Mar 28, 2008, at 10:55 AM, grass-dev-request@lists.osgeo.org wrote:

Date: Fri, 28 Mar 2008 23:24:36 +0600
From: Ivan Shmakov <ivan@theory.asu.ru>
Subject: [GRASS-dev] gui/tcltk/gis.m/*.tcl: wrong `variable' syntax
To: grass-dev@lists.osgeo.org
Cc: Ivan Shmakov <oneingray@gmail.com>
Message-ID: <m263v67odn.fsf@cherry.siamics.int>
Content-Type: text/plain; charset=us-ascii

  The lines marked ``>'' below seem nonsensical to me. For what
  reason, e. g., would one need to assign to an `array' variable
  thrice, let alone introducing the `#' variable?

barscale.tcl 12 namespace eval GmBarscale {
barscale.tcl 13 > variable array opt # barscale current options
barscale.tcl 14 variable count 1
barscale.tcl 15 > variable array lfile # scale
barscale.tcl 16 > variable array lfilemask # scale
barscale.tcl 17 variable optlist
barscale.tcl 18 variable first
barscale.tcl 19 > variable array dup # layer
barscale.tcl 20 > variable placement #LabelEntry widget for scale bar placment coordinates
barscale.tcl 21 };

Ivan,

Everything following the # is a comment to document the variable

The "variable xxx"

is to assign this to a local namespace.

I had to learn TclTk from deconstructing others' (sometimes not so elegant or uptodate) code and trying to work through the (often obtuse) online manual.

If there is a better way to do it, that also makes the code more reliable or faster, that's great--as long as it is also readable. Because this is done by self-taught, amateur, volunteer programmers, however, whatever changes that are made need to be very well documented. There are chunks of code (e.g., for gronsole) that are not well documented and quite difficult for someone like me to untangle.

There is one place that is a serious problem where we could really use a much more experienced TclTk programmer like you to sort out: the progress bar. It seems like it ought to be straightforward, but there is something wrong with the progress bar code so that if a module executes too quickly, it crashes the entire TclTk interface. I didn't write it but I've tried to sort it out and made some improvement to it. But my 'fixes' involved more guesswork than they should have and there are still problems on some modules.

Thanks for your help.
Michael

2

Michael Barton wrote:

> Date: Fri, 28 Mar 2008 23:24:36 +0600
> From: Ivan Shmakov <ivan@theory.asu.ru>
> Subject: [GRASS-dev] gui/tcltk/gis.m/*.tcl: wrong `variable' syntax
> To: grass-dev@lists.osgeo.org
> Cc: Ivan Shmakov <oneingray@gmail.com>
> Message-ID: <m263v67odn.fsf@cherry.siamics.int>
> Content-Type: text/plain; charset=us-ascii
>
> The lines marked ``>'' below seem nonsensical to me. For what
> reason, e. g., would one need to assign to an `array' variable
> thrice, let alone introducing the `#' variable?
>
> barscale.tcl 12 namespace eval GmBarscale {
> barscale.tcl 13 > variable array opt # barscale current options
> barscale.tcl 14 variable count 1
> barscale.tcl 15 > variable array lfile # scale
> barscale.tcl 16 > variable array lfilemask # scale
> barscale.tcl 17 variable optlist
> barscale.tcl 18 variable first
> barscale.tcl 19 > variable array dup # layer
> barscale.tcl 20 > variable placement #LabelEntry widget for
> scale bar placment coordinates
> barscale.tcl 21 };

Ivan,

Everything following the # is a comment to document the variable

No it isn't. It may have been *intended* as a comment, but the #
character is only treated as starting a comment when it occurs at the
beginning of a command, e.g. at the beginning of a line, or following
a semicolon.

From the Tcl(n) manpage:

       [9] Comments.
              If a hash character (``#'') appears at a point where Tcl is
              expecting the first character of the first word of a command,
              then the hash character and the characters that follow it, up
              through the next newline, are treated as a comment and ignored.
              The comment character only has significance when it appears at
              the beginning of a command.

It's quite common for people to get bitten by this. Most of the time,
you just get a syntax error, but in this case the code is legal (it
just doesn't do what you expect).

There is one place that is a serious problem where we could really
use a much more experienced TclTk programmer like you to sort out:
the progress bar. It seems like it ought to be straightforward, but
there is something wrong with the progress bar code so that if a
module executes too quickly, it crashes the entire TclTk interface.

AFAICT, the issue is due to an event handler being re-entered through
the "update" command.

I note that ProgressBar::_modify calls update. One option is to remove
that call. Any other options (i.e. allowing event handlers to be
re-entered) are quite complex.

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

3

Michael Barton <michael.barton@asu.edu> writes:

>> The lines marked ``>'' below seem nonsensical to me. For what
>> reason, e. g., would one need to assign to an `array' variable
>> thrice, let alone introducing the `#' variable?

[...]

>> barscale.tcl 15 > variable array lfile # scale

[...]

> Ivan,

> Everything following the # is a comment to document the variable

  As Glynn had already pointed out, it isn't.

> The "variable xxx"

> is to assign this to a local namespace.

  But note that there's no `variable array VARN' form. I guess,
  the intended effect could be achieved by something like:

   variable VARN
   array set VARN { }

  Or, introducing a new procedure:

proc var-array { varn } {
    uplevel 1 [ list variable $varn ]
    uplevel 1 [ list array set $varn { } ]
}

...

   var-array VARN

[...]

4

On Mar 30, 2008, at 2:17 AM, Glynn Clements wrote:

Michael Barton wrote:

Date: Fri, 28 Mar 2008 23:24:36 +0600
From: Ivan Shmakov <ivan@theory.asu.ru>
Subject: [GRASS-dev] gui/tcltk/gis.m/*.tcl: wrong `variable' syntax
To: grass-dev@lists.osgeo.org
Cc: Ivan Shmakov <oneingray@gmail.com>
Message-ID: <m263v67odn.fsf@cherry.siamics.int>
Content-Type: text/plain; charset=us-ascii

  The lines marked ``>'' below seem nonsensical to me. For what
  reason, e. g., would one need to assign to an `array' variable
  thrice, let alone introducing the `#' variable?

barscale.tcl 12 namespace eval GmBarscale {
barscale.tcl 13 > variable array opt # barscale current options
barscale.tcl 14 variable count 1
barscale.tcl 15 > variable array lfile # scale
barscale.tcl 16 > variable array lfilemask # scale
barscale.tcl 17 variable optlist
barscale.tcl 18 variable first
barscale.tcl 19 > variable array dup # layer
barscale.tcl 20 > variable placement #LabelEntry widget for
scale bar placment coordinates
barscale.tcl 21 };

Ivan,

Everything following the # is a comment to document the variable

No it isn't. It may have been *intended* as a comment, but the #
character is only treated as starting a comment when it occurs at the
beginning of a command, e.g. at the beginning of a line, or following
a semicolon.

I got this syntax from prior TclTk code. This is what happens when you learn a language in that way. So we just need to move all these to their own line

From the Tcl(n) manpage:

       [9] Comments.
              If a hash character (``#'') appears at a point where Tcl is
              expecting the first character of the first word of a command,
              then the hash character and the characters that follow it, up
              through the next newline, are treated as a comment and ignored.
              The comment character only has significance when it appears at
              the beginning of a command.

It's quite common for people to get bitten by this. Most of the time,
you just get a syntax error, but in this case the code is legal (it
just doesn't do what you expect).

There is one place that is a serious problem where we could really
use a much more experienced TclTk programmer like you to sort out:
the progress bar. It seems like it ought to be straightforward, but
there is something wrong with the progress bar code so that if a
module executes too quickly, it crashes the entire TclTk interface.

AFAICT, the issue is due to an event handler being re-entered through
the "update" command.

I note that ProgressBar::_modify calls update. One option is to remove
that call. Any other options (i.e. allowing event handlers to be
re-entered) are quite complex.

I'll try this as soon as I can get back to doing this. Thanks.

Michael

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

5

Michael Barton wrote:

>> Everything following the # is a comment to document the variable
>
> No it isn't. It may have been *intended* as a comment, but the #
> character is only treated as starting a comment when it occurs at the
> beginning of a command, e.g. at the beginning of a line, or following
> a semicolon.

I got this syntax from prior TclTk code. This is what happens when
you learn a language in that way. So we just need to move all these
to their own line

Or put a semicolon before the #.

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

6

On 3/30/08 2:17 AM, "Glynn Clements" <glynn@gclements.plus.com> wrote:

There is one place that is a serious problem where we could really
use a much more experienced TclTk programmer like you to sort out:
the progress bar. It seems like it ought to be straightforward, but
there is something wrong with the progress bar code so that if a
module executes too quickly, it crashes the entire TclTk interface.

AFAICT, the issue is due to an event handler being re-entered through
the "update" command.

I note that ProgressBar::_modify calls update. One option is to remove
that call. Any other options (i.e. allowing event handlers to be
re-entered) are quite complex.

Now that I can compile again, I went to look for this to see if your
suggested remedy works. I can't find where you are talking about. Is this in
the GRASS code or in the TclTk code?

Michael
__________________________________________
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

7

Michael Barton wrote:

>> There is one place that is a serious problem where we could really
>> use a much more experienced TclTk programmer like you to sort out:
>> the progress bar. It seems like it ought to be straightforward, but
>> there is something wrong with the progress bar code so that if a
>> module executes too quickly, it crashes the entire TclTk interface.
>
> AFAICT, the issue is due to an event handler being re-entered through
> the "update" command.
>
> I note that ProgressBar::_modify calls update. One option is to remove
> that call. Any other options (i.e. allowing event handlers to be
> re-entered) are quite complex.

Now that I can compile again, I went to look for this to see if your
suggested remedy works. I can't find where you are talking about. Is this in
the GRASS code or in the TclTk code?

It's at the bottom of lib/external/bwidget/progressbar.tcl.

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