[GRASS-user] Grass 6.3 Mac - r.patch parse error

GRASS GRASS user
1

Hi,

There seems to be a parse error of some kind in Grass-6.3.cvs, William Kyngsbury build, running under OSX. The most recent install I downloaded is in the file GRASS-6.3-070913.zip.

When working with a Web Mapping Server, Grass downloads a set of tiles and then patches them. The error happens in the patch process:
ERROR: the minimum number of input maps is two.

I can patch the files manually, but cannot patch them using patterns. The following command:

r.patch input=`g.mlist pat="*blue" sep=,` out=Perthblue

Produces the same failure.

I think the parsing problem is associated with g.mlist, because trying to use it for a bulk delete shows it appending the letter "n" into filenames:

>Removing raster <Test_2_tile_30_tmp.rednwa_output.red_State_Facilitiesn>

- the file should be *tmp.red followed by wa_output.red.

All operations work under 6.2.1.

Richard

2

Richard Chirgwin wrote:

There seems to be a parse error of some kind in Grass-6.3.cvs, William
Kyngsbury build, running under OSX. The most recent install I
downloaded is in the file GRASS-6.3-070913.zip.

This was fixed in CVS on Sept 18, five days after your build. g.mlist is a
shell script text file, you can edit in the fix by hand if you don't want to
update everything.

here is the thread from the nabble archive:
  http://www.nabble.com/g.mlist-problem-tf4472121.html

When working with a Web Mapping Server, Grass downloads a set of tiles
and then patches them. The error happens in the patch process:
ERROR: the minimum number of input maps is two.

I can patch the files manually, but cannot patch them using patterns.
The following command:

r.patch input=`g.mlist pat="*blue" sep=,` out=Perthblue

Produces the same failure.

I think the parsing problem is associated with g.mlist, because trying
to use it for a bulk delete shows it appending the letter "n" into
filenames:

>Removing raster <Test_2_tile_30_tmp.rednwa_output.red_State_Facilitiesn>

- the file should be *tmp.red followed by wa_output.red.

All operations work under 6.2.1.

the "n" is from the second part of the shell code for a newline "\n".

fixed here:
http://freegis.org/cgi-bin/viewcvs.cgi/grass6/scripts/g.mlist/g.mlist.diff?r1=1.18&r2=1.19

I would have guessed that a hardcoded newline in the regex (even \quoted)
wasn't entierly kosher. But apparently it's ok....

mailing list woes:

I first searched for the thread, and found one on grass-dev from 2007-09-18
titled
"[GRASS-dev] g.mlist problem - followup"
but the Gmane archive is producing an error "weft didn't produce an output."
and the ht://Dig -dev mailing list search can't even find any matches on a
search for "grass". (in the past Markus explained this might happen when it was
doing a rescan)

The other day a ht://Dig seach gave results, but the links were misaligned and
you ended up with another random post or not-found error when you clicked on a
promising summary.

I also notice that old commits wait to be copied to the new osgeo server: (?)
  http://lists.osgeo.org/pipermail/grass-commit/

I also notice someone posted with a bad clock, any chance to fix that with an
low-level edit with info taken from elsewhere in the email's header info?
  http://lists.osgeo.org/pipermail/grass-dev/1971-June/021316.html

?

Hamish

      ____________________________________________________________________________________
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs

3

On Nov 25, 2007, at 12:29 AM, Hamish wrote:

Richard Chirgwin wrote:

There seems to be a parse error of some kind in Grass-6.3.cvs, William
Kyngsbury build, running under OSX. The most recent install I
downloaded is in the file GRASS-6.3-070913.zip.

This was fixed in CVS on Sept 18, five days after your build. g.mlist is a
shell script text file, you can edit in the fix by hand if you don't want to
update everything.

here is the thread from the nabble archive:
http://www.nabble.com/g.mlist-problem-tf4472121.html

Yeah, that build is getting a bit old. I think I'm finally caught up on Leopard stuff and can package up the latest RC release soon.

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

"I ache, therefore I am. Or in my case - I am, therefore I ache."

- Marvin

4

On Nov 25, 2007, at 11:00 AM, Aurora Geomatics wrote:

On a related note, how is everything running on Leopard for you William?

GRASS, QGIS, PostgreSQL, R, etc....

I have Leopard but have not made the dive yet. Waiting for feedback on any problems concerns related to GRASS etc..

Thanks William, you save us Mac GIS users hours of set-up work!

Mars

Friday I just put new frameworks and Postgres online, built for Leopard.

I've mentioned a few things on the dev list over the past few weeks about GRASS on Leopard. Summary:

- The current GRASS build does work on Leopard, even with the old frameworks.

- X11 starts automatically now when needed. I know my GRASS startup already did this, but it's now done by the system.

- Do NOT set $DISPLAY. Monitor displays and the GUI will not work. DISPLAY is set by the system (and it's not the usual :0.0).

- TclTk 8.4 doesn't build 64bits, so the GUI and NVIZ will not run in 64bit mode. Not a big deal for the GUI, but it would be nice to have the extra boost in performance in NVIZ. TclTk 8.5 can build 64bits, but I had problems with that in GRASS.

- There is a Leopard linking problem with the X11 libGL (for NVIZ). There is a workaround. (only affects compiling GRASS)

- not specificaly GRASS related, but Carbon in Leopard is not 64bit-enabled. Carbon is deprecated. Carbon is dead. Anything that depends on Carbon must be updated to use Cocoa APIs to work in 64bits. This includes Qt (Qgis, OSSIM, ...), some Python GUI type stuff, some random libraries (Xerces, used in GDAL).

For GUI stuff, it's not a big problem, as long as the commands (ie GRASS modules) run from a GUI do so as a separate process, they will run in 64bits if they can.

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

"We are at war with them. Neither in hatred nor revenge and with no particular pleasure I shall kill every ___ I can until the war is over. That is my duty."

"Don't you even hate 'em?"

"What good would it do if I did? If all the many millions of people of the allied nations devoted an entire year exclusively to hating the ____ it wouldn't kill one ___ nor shorten the war one day."

<Ha, ha> "And it might give 'em all stomach ulcers."

- Tarzan, on war

5

Hamish wrote:

mailing list woes:

I first searched for the thread, and found one on grass-dev from 2007-09-18
titled
"[GRASS-dev] g.mlist problem - followup"
but the Gmane archive is producing an error "weft didn't produce an output."

Hamish,

I can't comment on gmane issues.

and the ht://Dig -dev mailing list search can't even find any matches on a
search for "grass". (in the past Markus explained this might happen when it was
doing a rescan)

>

The other day a ht://Dig seach gave results, but the links were misaligned and
you ended up with another random post or not-found error when you clicked on a
promising summary.

I can't comment on ht://Dig. Hopefully fairly soon the new mailing list
archives on lists.osgeo.org will be picked up by the various search engines
and searchable that way. I wouldn't be adverse to implementing some sort of
"on server" search for lists archived by lists.osgeo.org if that is really
helpful (instead of waiting for them to be indexed by the search engines), but
I would need some guidance on good approaches.

I also notice that old commits wait to be copied to the new osgeo server: (?)
  http://lists.osgeo.org/pipermail/grass-commit/

As Markus noted, I was hesitant to ingest the 250MB or so of old commit
messages. It seems like a very low value archive considering that the history
is all available in subversion anyways. I did of course preserve all the
original content lists (like grass-dev, etc).

If folks felt really really strongly about carrying over the commits archive
I could do so but it seems like a poor use of administrator and system
resources.

I also notice someone posted with a bad clock, any chance to fix that with an
low-level edit with info taken from elsewhere in the email's header info?
  http://lists.osgeo.org/pipermail/grass-dev/1971-June/021316.html

Speaking of a poor use of administrator resources...

I'm keen to make lists.osgeo.org (and other osgeo system services) useful to
the GRASS and other project communities, but I'm also keen to use admin time
efficiently (ie. lightly) and to aim for maximum leverage. So, implementing
lists.osgeo.org search services might be a hassle, but I can see it would give
more immediate search results than search engines, and would be leveragable
over all the lists on the system.

Manually editing .mbox files to fix up corrupt dates ... not so keen.

I'd add that I have to do all my osgeo.org administration over an ssh link
with an approximately 1.5s latency due to my sat link. The pain of this
makes me grumpy quickly. :slight_smile: There is definitely room on the OSGeo system
administration committee for additional volunteers with smome experience
and a willingness to make a significant commitment. Wolf has already
accepted substantial Drupal related responsibilities but has sensibly
avoided getting lots of other stuff dumped on him. But of course, part
of the objective is to provide useful services to the projects in a
more efficient manner than would be the case if we were each doing our
own thing.

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | President OSGeo, http://osgeo.org