[GRASS5] Driver Update

GRASS GRASS developer
41

Glynn Clements wrote:

> I have tested some modules:
>
> > d.display
> -> not o.k., needs the R_stabilize()

Any specific cases? d.display is quite a large program, which is why I
didn't try to fix it there and then.

> > i.class
> -> raster is o.k., but the vector lines are not drawn unless you
> accept them.
> Test usage: use i.group to generate a group and a subgroup of at least
> two raster images (could be anything for this). Then start i.class,
> enter some file names as queried, then "define region"/"draw region" to
> draw vector lines as sample areas. Then drawing, the lines *should*
> be seen (the aren't unless you hit the right mouse button to complete).

OK; this seems to be confined to draw_region().

Hmm. The problem which you report seems to be confined to
draw_region(), but I would suspect that extensive testing might reveal
others.

If d.display and/or i.class are going to be made to work, it would be
much simpler to redefine the graphics interface without R_stabilize or
R_flush. Of course, this would make certain types of driver (ones
which *require* some sort of flush operation) totally impractical.

The same applies to any other programs which make half-baked attempts
at implementing a GUI.

I'm not going to look into this any further; I'll add an auto-flush
feature to XDRIVER once we've had a reasonable chance to find any
other (realistically) fixable cases.

--
Glynn Clements <glynn.clements@virgin.net>

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

42

Glynn Clements wrote:

> A related problem I found:
> If you break a displaying module with CTRL-C, the monitor is blocked:
> GRASS:~ > d.display
> # displaying something, then CTRL-C to kill due to above problems
> GRASS:~ > Monitor <x0>: Premature EOF
>
> GRASS:~ > d.erase
> Monitor <x0>: Premature EOF
>
> Same story with d.rast: if you CTRL-C it, the monitor is blocked.
> In past this treatment was accepted and the monitor didn't die.
> Closing is (of course) still possible. Could you change the treatment of
> "Premature EOF" in the monitor to keep the monitor working?

This implies that some state is being retained between connections.
This shouldn't happen, and I can't immediately see how it is
happening. I'll look into it.

Looked into it; the "eof" flag wasn't being cleared at the start of a
new connection; once set, it stayed set.

Fixed and committed.

NB: this isn't related to Justin's problem, unfortunately; it only
causes process_command() to indicate EOF, not get_command().

--
Glynn Clements <glynn.clements@virgin.net>

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

43

On Fri, Apr 27, 2001 at 07:11:24PM +0100, Glynn Clements wrote:

Markus Neteler wrote:
> > > So we have to watch out now for any module with backing store problems
> > > (when using the latest Xdriver version). It can be simply fixed like
> > > d.rast.edit. Another candidate is v.digit, there may be more modules
> > > needing the R_stabilize() function.
> >
> > I've done a quick scan of anything that might need changes (i.e. by
> > looking for libraster.a in the build output).
> >
> > The following are the ones which couldn't be quickly confirmed to be
> > OK or fixed.
>
> I have tested some modules:
>
> > d.display
> -> not o.k., needs the R_stabilize()

Any specific cases? d.display is quite a large program, which is why I
didn't try to fix it there and then.

Sure, sorry. I loaded a raster map, it was only displayed when "wiping" the
monitor with another window. If you start it and load a raster map, it won't
appear.

> > i.points3
> -> o.k. for display
> Bug: If setting target reference point, nothing happens (not displayed,
> not accpeted). Note: i.points3 is *much* more convenient than
> i.points and it merges i.points and i.vpoints. We should get this
> working.

So this bug isn't related to R_stabilize()?

Yes, it will be something else (unfortunately). Volunteer wanted :slight_smile:

> > i.vpoints
> -> raster o.k., vector maps not displayed at all (bug)
> bug: full screen not restored (frames not removed). Anyway, i.points3
> is my recommendation.

So it doesn't need fixing?

It is not related to R_stabilize(). If we get i.points3 fixed, we can
remove i.points and i.vpoints from CVS and rename the much more convenient
i.points3 -> i.points. Would be another module structure simplification.

> > d.fix.ortho (src.contrib/SCS)
> -> the digitizing line is not shown yet (needs fix)

get_shift() has the drawing code commented out. Should this be
re-enabled?

Probably yes. I'll try that.

[...]

NB: The case where the client quits while waiting for a mouse click
shouldn't have changed at all; the Get_location_with_* functions all
have their own event loop, which doesn't return until a button is
pressed. This isn't straightforward to change (it can be done, but
it's potentially de-stabilising).

O.k. Once I was proposing a timeout for waiting for the right mouse button,
but the majority here disagreed. The only problem is that newbies (and non
english speakers) regularly ignore the mouse button description displayed
in xterm. Later they wonder why the monitor doesn't work any more...
However, I have no good solution for this. In other GUI-GIS you have
a button to be selected, therefore it's rather clear what's ongoing.

Markus

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

44

Markus Neteler wrote:

> > > d.fix.ortho (src.contrib/SCS)
> > -> the digitizing line is not shown yet (needs fix)
>
> get_shift() has the drawing code commented out. Should this be
> re-enabled?
Probably yes. I'll try that.

So, I have applied a quick-and-dirty fix to this module.
Now the vector line is draw.

Regards

Markus

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

45

Hi Glynn,

here a new report:

On Thu, Apr 26, 2001 at 06:59:38PM +0100, Glynn Clements wrote:

d.display

-> o.k. now (except the frame leftover bug not related to xdriver)

i.class

-> o.k. now

i.colors

-> o.k. now

i.ortho.photo

-> o.k. now

i.points
i.points3
i.vpoints

-> see my other mail (i.points3 preferred which is buggy)

v.area

-> o.k. now

v.digit

-> o.k. now

d.fix.ortho (src.contrib/SCS)

-> o.k. now

r.weight
r.water.fea (src.contrib/CERL)
paint/driver/preview
paint/driver/preview2

-> these are untested (volunteers?)

From your other mail:

GRASS:~ > d.erase
Monitor <x0>: Premature EOF
                                                                              
Same story with d.rast: if you CTRL-C it, the monitor is blocked.
In past this treatment was accepted and the monitor didn't die.
Closing is (of course) still possible. Could you change the treatment of
"Premature EOF" in the monitor to keep the monitor working?
                                                                               
This implies that some state is being retained between connections.
This shouldn't happen, and I can't immediately see how it is
happening. I'll look into it.

This is fixed, thanks. The monitor keeps working now.

Thanks for your work,

Markus

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

46

Markus Neteler wrote:

> NB: The case where the client quits while waiting for a mouse click
> shouldn't have changed at all; the Get_location_with_* functions all
> have their own event loop, which doesn't return until a button is
> pressed. This isn't straightforward to change (it can be done, but
> it's potentially de-stabilising).

O.k. Once I was proposing a timeout for waiting for the right mouse button,
but the majority here disagreed. The only problem is that newbies (and non
english speakers) regularly ignore the mouse button description displayed
in xterm. Later they wonder why the monitor doesn't work any more...
However, I have no good solution for this. In other GUI-GIS you have
a button to be selected, therefore it's rather clear what's ongoing.

The solution would be to re-write the mouse handling code in such a
way that it aborts if the connection is closed. However, I think that
this change might be too destabilizing this close to release.

--
Glynn Clements <glynn.clements@virgin.net>

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

47

Markus Neteler wrote:

> > I have tested some modules:
> >
> > > d.display
> > -> not o.k., needs the R_stabilize()
>
> Any specific cases? d.display is quite a large program, which is why I
> didn't try to fix it there and then.

Sure, sorry. I loaded a raster map, it was only displayed when "wiping" the
monitor with another window. If you start it and load a raster map, it won't
appear.

Odd; I don't get this behaviour. Furthermore, I don't see how it could
occur.

d.display repeatedly opens and closes the driver, doing very little in
between. R_close_driver() calls R_stabilize(), so all output should be
flushed whenever the driver is closed.

Running "fgrep R_ *.c" shows that, in all but three cases, there are
only between one and three statements between R_open_driver() and
R_close_driver(). The exceptions are the code to draw raster maps in
zoom.c and show_cell.c, and the setup code in setup.c (which, if it
weren't for the nine calls to Dnew() to create the frames, would only
have three statements).

The code for displaying a raster map (in show_cell.c; the code in
zoom.c is very similar) is:

  if (R_open_driver() != 0)
    G_fatal_error ("No graphics device selected");

/* Draw cell map */
  G_get_window(&wind) ;
  G_set_window(&wind) ;
  Dchoose(MAP.name) ;
  Derase("black") ;
  fprintf (stdout,"\n\n Displaying map %s from mapset %s\n", mapname, mapset);
  Dcell(mapname, mapset, 0) ;

/* Draw tiny map */
  G_get_default_window(&wind) ;
  G_set_window(&wind) ;
  Dchoose(REF.name) ;
  Dcell(mapname, mapset, 0) ;
  R_close_driver();

I don't see how this can produce the behaviour which you describe,
unless d.display terminates suddenly (you don't report this as
happening; was d.display still running?).

However, premature termination does appear to be a real possibility;
when I tried testing it, attempting to draw elevation.dem (from
spearfish) twice in succession caused d.display to segfault on the
second attempt. The segfault was in realloc(), which suggests heap
corruption.

--
Glynn Clements <glynn.clements@virgin.net>

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

48

On Sat, Apr 28, 2001 at 09:40:07PM +0100, Glynn Clements wrote:

Markus Neteler wrote:

> > > I have tested some modules:
> > >
> > > > d.display
> > > -> not o.k., needs the R_stabilize()
> >
> > Any specific cases? d.display is quite a large program, which is why I
> > didn't try to fix it there and then.
>
> Sure, sorry. I loaded a raster map, it was only displayed when "wiping" the
> monitor with another window. If you start it and load a raster map, it won't
> appear.

Odd; I don't get this behaviour. Furthermore, I don't see how it could
occur.

Glynn,

obviously we got our mails overlapped: The d.display is running well
since yesterday. Sorry for the confusion,

Markus

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

49

Hi Glynn

Glynn Clements wrote:

  We previously established that get_command() is returning non-zero.
  If you're not getting the "Premature EOF" message from
  get_command(), then the first read1(c) in get_command() must be
  returning non-zero.

  If you're not getting the "Error reading input" message from
  read1(), then the read() call in read1() must be returning zero,
  indicating EOF from the client. Can you add a "if (n_read == 0)
  printf(...)" to read1() just to confirm this beyond doubt?

Yes I believe this is correct, here is the output for your reference
after an update about 6 hours ago.

using default visual which is TrueColor
Visual is read-only or using a private colormap
ncolors: 32768
allocating memory...
About to call prepare_connection_sock
About to call get_connection_sock
Graphics driver [x0] started
About to call Do-work (0)
About to call get_connection_sock
About to call Do-work (1)
About to call Do-work (1)
Warning - no response from graphics monitor <x0>.
Check to see if the mouse is still active.
ERROR - no response from graphics monitor <x0>.
Monitor: read1: n_read = 0
get_command was != 0
About to call close(_wfd)
About to call get_connection_sock
Problem selecting x0. Will try once more
About to call Do-work (0)
About to call get_connection_sock
About to call Do-work (1)
About to call Do-work (1)
Warning - no response from graphics monitor <x0>.
Check to see if the mouse is still active.
ERROR - no response from graphics monitor <x0>.
Monitor: read1: n_read = 0
get_command was != 0
About to call close(_wfd)
About to call get_connection_sock
About to call Do-work (0)
About to call get_connection_sock
About to call Do-work (0)

Sorry to be such a pain and not much use to you. I just don't have time
to become familiar with the source code.

--
Sincerely,

Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand

People who think they know everything are very irritating to those
of us who do. ---Anonymous

Jazz and Trek Rule!!!

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

50

Justin Hickey wrote:

> We previously established that get_command() is returning non-zero.
> If you're not getting the "Premature EOF" message from
> get_command(), then the first read1(c) in get_command() must be
> returning non-zero.
>
> If you're not getting the "Error reading input" message from
> read1(), then the read() call in read1() must be returning zero,
> indicating EOF from the client. Can you add a "if (n_read == 0)
> printf(...)" to read1() just to confirm this beyond doubt?

Yes I believe this is correct, here is the output for your reference
after an update about 6 hours ago.

using default visual which is TrueColor
Visual is read-only or using a private colormap
ncolors: 32768
allocating memory...
About to call prepare_connection_sock
About to call get_connection_sock
Graphics driver [x0] started
About to call Do-work (0)
About to call get_connection_sock
About to call Do-work (1)
About to call Do-work (1)
Warning - no response from graphics monitor <x0>.
Check to see if the mouse is still active.
ERROR - no response from graphics monitor <x0>.

Can you tell me roughly what sort of time intervals are involved here?

The first call to Do_work(1) should immediately follow
get_connection_sock(). The next call will occur after the first
command is read and processed.

The client should print the warning after 5 seconds, and the error
after a further 10 seconds.

The fact that Do_work(1) gets called a second time suggests that all
of the data has been sent. Or, at least, the driver isn't blocking
trying to send it. I've commited an update to
src/display/devices/lib/command.c which checks the return value from
the write() call, in case that's failing for some reason.

Monitor: read1: n_read = 0
get_command was != 0

This is to be expected; at this point, the client has given up and
closed the connection.

--
Glynn Clements <glynn.clements@virgin.net>

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

51

Hi Glynn

Glynn Clements wrote:

Can you tell me roughly what sort of time intervals are involved
here?

The first call to Do_work(1) should immediately follow
get_connection_sock(). The next call will occur after the first
command is read and processed.

Both calls to Do_work(1) seem to occur immediately.

The client should print the warning after 5 seconds, and the error
after a further 10 seconds.

Yep, these times are the times I get.

The fact that Do_work(1) gets called a second time suggests that all
of the data has been sent. Or, at least, the driver isn't blocking
trying to send it. I've commited an update to
src/display/devices/lib/command.c which checks the return value from
the write() call, in case that's failing for some reason.

Are you sure you committed the change? I updated the file and CVS
reported it as an M update which means the differences are from my local
file. So I looked through the file but did not see any changes for the
write() command. Just curious.

> Monitor: read1: n_read = 0
> get_command was != 0

This is to be expected; at this point, the client has given up and
closed the connection.

--
Sincerely,

Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand

People who think they know everything are very irritating to those
of us who do. ---Anonymous

Jazz and Trek Rule!!!

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

52

Justin Hickey wrote:

> The fact that Do_work(1) gets called a second time suggests that all
> of the data has been sent. Or, at least, the driver isn't blocking
> trying to send it. I've commited an update to
> src/display/devices/lib/command.c which checks the return value from
> the write() call, in case that's failing for some reason.

Are you sure you committed the change? I updated the file and CVS
reported it as an M update which means the differences are from my local
file. So I looked through the file but did not see any changes for the
write() command. Just curious.

No; it appears that I didn't.

--
Glynn Clements <glynn.clements@virgin.net>

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

53

Hi Glynn

Glynn Clements wrote:

I've commited an update to
src/display/devices/lib/command.c which checks the return value from
the write() call, in case that's failing for some reason.

Now that I could compile again, I tried d.mon and it seems that there is
no change in the output. That is, the write() call doesn't seem to be
failing. Here's the output.

GRASS 5.0.0pre1 > d.mon start=x0
using default visual which is TrueColor
Visual is read-only or using a private colormap
ncolors: 32768
allocating memory...
About to call prepare_connection_sock
About to call get_connection_sock
Graphics driver [x0] started
About to call Do-work (0)
About to call get_connection_sock
About to call Do-work (1)
Monitor: _send: write was successful
Monitor: _send: write was successful
    <Above message printed a total of 43 times>
About to call Do-work (1)
Warning - no response from graphics monitor <x0>.
Check to see if the mouse is still active.
ERROR - no response from graphics monitor <x0>.
Monitor: read1: n_read = 0
get_command was != 0
About to call close(_wfd)
About to call get_connection_sock
Problem selecting x0. Will try once more
About to call Do-work (0)
About to call get_connection_sock
About to call Do-work (1)
Monitor: _send: write was successful
Monitor: _send: write was successful
    <Above message printed a total of 43 times>
About to call Do-work (1)
Warning - no response from graphics monitor <x0>.
Check to see if the mouse is still active.
ERROR - no response from graphics monitor <x0>.
Monitor: read1: n_read = 0
get_command was != 0
About to call close(_wfd)
About to call get_connection_sock
                                                                       
Mapset <PERMANENT> in Location <spearfish>
GRASS 5.0.0pre1 > About to call Do-work (0)
About to call get_connection_sock
About to call Do-work (0)

I'm not sure if knowing that write was called 43 times is significant or
not, but a little more knowledge now.

--
Sincerely,

Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand

People who think they know everything are very irritating to those
of us who do. ---Anonymous

Jazz and Trek Rule!!!

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

54

Justin Hickey wrote:

> I've commited an update to
> src/display/devices/lib/command.c which checks the return value from
> the write() call, in case that's failing for some reason.

Now that I could compile again, I tried d.mon and it seems that there is
no change in the output. That is, the write() call doesn't seem to be
failing. Here's the output.

OK, I'm an idiot; I can't believe it took me this long to notice this.
"c" changed from a "char" to an "int" when the "switch" was made into
a separate function (process_command()).

This doesn't affect anyone whose platform is little-endian (e.g.
Intel), but on a big-endian platform it's sending a zero instead of
the COMMAND_ESC (127) which terminates the sequence. The client waits
forever for a COMMAND_ESC which never arrives.

Are you really the only person testing this on a big-endian platform?
I suppose you must be.

I reckon that the attached patch (or the latest CVS version[1]) will
fix it.

[1] I've just checked a lot of other XDRIVER changes into CVS, so you
may wish to try just this first.

--
Glynn Clements <glynn.clements@virgin.net>

(attachments)

command.c.diff (530 Bytes)

55

Hi Glynn

Glynn Clements wrote:

"c" changed from a "char" to an "int" when the "switch" was made into
a separate function (process_command()).

Yes! Yes! I can render again!!! :slight_smile:

Thank you Glynn! I have now sucessfully rendered raster, vector and site
data to a monitor. Everything seems fine so far!

Thanks again!

--
Sincerely,

Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand

People who think they know everything are very irritating to those
of us who do. ---Anonymous

Jazz and Trek Rule!!!

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

56

On Wed, May 02, 2001 at 05:14:01PM +0700, Justin Hickey wrote:

Hi Glynn

Glynn Clements wrote:
> "c" changed from a "char" to an "int" when the "switch" was made into
> a separate function (process_command()).
>

Yes! Yes! I can render again!!! :slight_smile:

Thank you Glynn! I have now sucessfully rendered raster, vector and site
data to a monitor. Everything seems fine so far!

Thanks again!

Great! After these breaking news that the new Xdriver works on SGI
again and all the other fixes from last days, let's discuss what's
left for the GRASS 5.0.0.

I think it would be good to get out 5.0.0pre1 quickly to the public.
Now I will migrate all bugs from BUGS into RT for better management.

Bernhard, may I ask you to write a small (cronjob) script to feed
the RT contents into CVS? Then RT can be the only bug assembling point.

Regards

Markus

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

57

On Wed, May 02, 2001 at 01:04:37PM +0100, Markus Neteler wrote:

Bernhard, may I ask you to write a small (cronjob) script to feed
the RT contents into CVS? Then RT can be the only bug assembling point.

Do we really need to have the contents of the RT in the CVS, too?
  Bernhard

--
Professional Service around Free Software (intevation.net)
The FreeGIS Project (freegis.org)
Association for a Free Informational Infrastructure (ffii.org)
FSF Europe (fsfeurope.org)

58

Glynn Clements wrote:

> if you allow, an offlist query: Is it possible to implement an auto-redraw
> into the monitor if the user resizes it? Somehow like d.zoom does the
> redraw? The would be *really* great if it wouldn't destabilize the driver.

AFAICT, d.zoom uses the list constructed by D_add_to_list() to perform
the redraw. I haven't looked into how this mechanism works enough to
be able to determine how involved this would be.

OK; I've just committed some changes which will implement this.

Resize events are no longer processed while a client is connected;
instead, a flag is set, and the resize is handled once the driver is
idle.

This needs testing thoroughly; XDRIVER will now spawn whatever
commands are added to the list via D_add_to_list(). If any of these
commands don't like being run in this environment, problems may occur;
in which case, the commands will need to be fixed, or at least have
the D_add_to_list() call removed.

--
Glynn Clements <glynn.clements@virgin.net>

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

59

On Tue, May 08, 2001 at 11:58:46AM +0100, Glynn Clements wrote:

Glynn Clements wrote:

> > if you allow, an offlist query: Is it possible to implement an auto-redraw
> > into the monitor if the user resizes it? Somehow like d.zoom does the
> > redraw? The would be *really* great if it wouldn't destabilize the driver.
>
> AFAICT, d.zoom uses the list constructed by D_add_to_list() to perform
> the redraw. I haven't looked into how this mechanism works enough to
> be able to determine how involved this would be.

OK; I've just committed some changes which will implement this.

Resize events are no longer processed while a client is connected;
instead, a flag is set, and the resize is handled once the driver is
idle.

This needs testing thoroughly; XDRIVER will now spawn whatever
commands are added to the list via D_add_to_list(). If any of these
commands don't like being run in this environment, problems may occur;
in which case, the commands will need to be fixed, or at least have
the D_add_to_list() call removed.

Glynn,

that's great!! I have just tested, it seems to run well.
This has been a long awaited feature of XDRIVER...

Thanks a lot,

Markus

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'