[GRASS-dev] [GRASS GIS] #759: r.patch non-functional in WinGRASS 6.4 svn on Vista

#759: r.patch non-functional in WinGRASS 6.4 svn on Vista
------------------------------+---------------------------------------------
  Reporter: cmbarton | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: critical | Milestone: 6.4.0
Component: Raster | Version: 6.4.0 RCs
Resolution: | Keywords: r.patch, wingrass
  Platform: MSWindows Vista | Cpu: Unspecified
------------------------------+---------------------------------------------
Comment (by hellik):

for the record:
the manifest taken from

http://msdn.microsoft.com/en-us/library/bb756929.aspx

Helmut

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/759#comment:20&gt;
GRASS GIS <http://grass.osgeo.org>

#759: r.patch non-functional in WinGRASS 6.4 svn on Vista
------------------------------+---------------------------------------------
  Reporter: cmbarton | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: critical | Milestone: 6.4.0
Component: Raster | Version: 6.4.0 RCs
Resolution: | Keywords: r.patch, wingrass
  Platform: MSWindows Vista | Cpu: Unspecified
------------------------------+---------------------------------------------
Comment (by hellik):

Replying to [comment:19 hellik]:

>
> so the question will be how this could be implemented in the grass-
compile- and build process?
>

maybe something for the NSIS-installer-script because it's windows-
related?

Helmut

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/759#comment:21&gt;
GRASS GIS <http://grass.osgeo.org>

#759: r.patch non-functional in WinGRASS 6.4 svn on Vista
------------------------------+---------------------------------------------
  Reporter: cmbarton | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: critical | Milestone: 6.4.0
Component: Raster | Version: 6.4.0 RCs
Resolution: | Keywords: r.patch, wingrass
  Platform: MSWindows Vista | Cpu: Unspecified
------------------------------+---------------------------------------------
Comment (by glynn):

Replying to [comment:19 hellik]:

> so the question will be how this could be implemented in the grass-
compile- and build process?

How about adding something like the following to the "default" target in
the top-level Makefile:

{{{
ifneq ($(strip $(MINGW)),)
         find $(ARCH_DISTDIR) -type f -name '*.exe' | \
         while read file ; do \
             cmd=`basename "$$file" .exe` \
             sed "s/@CMD@/$$cmd/" generic.manifest > "$$file".manifest ; \
         done
endif
}}}

For 7.0, I'd use a pattern rule for "%.exe.manifest" to build a manifest
alongside any exe.

It wouldn't be hard to allow the <description> field to be customised, but
I'm not sure that really matters. The main thing is to shut UAC up.

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/759#comment:22&gt;
GRASS GIS <http://grass.osgeo.org>

#759: r.patch non-functional in WinGRASS 6.4 svn on Vista
------------------------------+---------------------------------------------
  Reporter: cmbarton | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: critical | Milestone: 6.4.0
Component: Raster | Version: 6.4.0 RCs
Resolution: | Keywords: r.patch, wingrass
  Platform: MSWindows Vista | Cpu: Unspecified
------------------------------+---------------------------------------------
Comment (by hellik):

Replying to [comment:11 hellik]:
>
> i see also in the windows-file-explorer that both r.patch.exe and
v.patch.exe are >marked by WinVista with a win-symbol, so Vista really
recognize only by the file-name
> that there could something important/dangerous for the system and
activates the UAC.

also r.le.patch and r.le.setup are marked

Helmut

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/759#comment:23&gt;
GRASS GIS <http://grass.osgeo.org>

#759: r.patch non-functional in WinGRASS 6.4 svn on Vista
------------------------------+---------------------------------------------
  Reporter: cmbarton | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: critical | Milestone: 6.4.0
Component: Raster | Version: 6.4.0 RCs
Resolution: | Keywords: r.patch, wingrass
  Platform: MSWindows Vista | Cpu: Unspecified
------------------------------+---------------------------------------------
Comment (by neteler):

Replying to [comment:23 hellik]:
> Replying to [comment:11 hellik]:
> >
> > i see also in the windows-file-explorer that both r.patch.exe and
v.patch.exe are
> > marked by WinVista with a win-symbol, so Vista really recognize only
by the file-name
> > that there could something important/dangerous for the system and
activates the UAC.
>
> also r.le.patch and r.le.setup are marked

From http://technet.microsoft.com/en-us/magazine/2007.06.uac.aspx

citation: "Conveniently Accessing Administrative Rights

... Some of the heuristics it uses are as simple as detecting if the image
has the words setup, install, or update in its file name or internal
version information; more sophisticated ones involve scanning for byte
sequences in the executable that are common to third-party installation
wrapper utilities...."

...so no surprise...

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/759#comment:24&gt;
GRASS GIS <http://grass.osgeo.org>

#759: r.patch non-functional in WinGRASS 6.4 svn on Vista
------------------------------+---------------------------------------------
  Reporter: cmbarton | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: critical | Milestone: 6.4.0
Component: Raster | Version: 6.4.0 RCs
Resolution: | Keywords: r.patch, wingrass
  Platform: MSWindows Vista | Cpu: Unspecified
------------------------------+---------------------------------------------
Comment (by hellik):

Replying to [comment:20 hellik]:
> for the record:
> the manifest taken from
>
> http://msdn.microsoft.com/en-us/library/bb756929.aspx
>
> Helmut

see also http://trac.osgeo.org/grass/ticket/827#comment:24

http://msdn.microsoft.com/de-de/library/aa375365(en-us,VS.85).aspx

Helmut

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/759#comment:25&gt;
GRASS GIS <http://grass.osgeo.org>

#759: r.patch non-functional in WinGRASS 6.4 svn on Vista
------------------------------+---------------------------------------------
  Reporter: cmbarton | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: critical | Milestone: 6.4.0
Component: Raster | Version: 6.4.0 RCs
Resolution: | Keywords: r.patch, wingrass
  Platform: MSWindows Vista | Cpu: Unspecified
------------------------------+---------------------------------------------
Comment (by neteler):

Replying to [comment:22 glynn]:
> Replying to [comment:19 hellik]:
>
> > so the question will be how this could be implemented in the grass-
compile- and build process?
>
> How about adding something like the following to the "default" target in
the top-level Makefile:
>
> {{{
> ifneq ($(strip $(MINGW)),)
> find $(ARCH_DISTDIR) -type f -name '*.exe' | \
> while read file ; do \
> cmd=`basename "$$file" .exe` \
> sed "s/@CMD@/$$cmd/" generic.manifest > "$$file".manifest ; \
> done
> endif
> }}}
>
> For 7.0, I'd use a pattern rule for "%.exe.manifest" to build a manifest
alongside any exe.
>
> It wouldn't be hard to allow the <description> field to be customised,
but I'm not sure that really matters. The main thing is to shut UAC up.

I have tried to patch it but get a syntax error. Could you please submit
the patch?
If it fails, we can still revert.

Markus

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/759#comment:26&gt;
GRASS GIS <http://grass.osgeo.org>

#759: r.patch non-functional in WinGRASS 6.4 svn on Vista
------------------------------+---------------------------------------------
  Reporter: cmbarton | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: critical | Milestone: 6.4.0
Component: Raster | Version: 6.4.0 RCs
Resolution: | Keywords: r.patch, wingrass
  Platform: MSWindows Vista | Cpu: Unspecified
------------------------------+---------------------------------------------
Comment (by glynn):

Replying to [comment:26 neteler]:

> I have tried to patch it but get a syntax error. Could you please submit
the patch?
> If it fails, we can still revert.

Try r40977.

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/759#comment:27&gt;
GRASS GIS <http://grass.osgeo.org>

#759: r.patch non-functional in WinGRASS 6.4 svn on Vista
------------------------------+---------------------------------------------
  Reporter: cmbarton | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: critical | Milestone: 6.4.0
Component: Raster | Version: 6.4.0 RCs
Resolution: | Keywords: r.patch, wingrass
  Platform: MSWindows Vista | Cpu: Unspecified
------------------------------+---------------------------------------------
Comment (by glynn):

Replying to [comment:27 glynn]:

> Try r40977.

Not quite; needs r40978 as well.

That builds what appear to be valid manifests, but it needs someone with
Vista or Windows 7 to test it.

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/759#comment:28&gt;
GRASS GIS <http://grass.osgeo.org>

#759: r.patch non-functional in WinGRASS 6.4 svn on Vista
------------------------------+---------------------------------------------
  Reporter: cmbarton | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: critical | Milestone: 6.4.0
Component: Raster | Version: 6.4.0 RCs
Resolution: | Keywords: r.patch, wingrass
  Platform: MSWindows Vista | Cpu: Unspecified
------------------------------+---------------------------------------------
Comment (by hellik):

Replying to [comment:28 glynn]:
> Replying to [comment:27 glynn]:
>
> > Try r40977.
>
> Not quite; needs r40978 as well.
>
> That builds what appear to be valid manifests, but it needs someone with
Vista or Windows 7 to test it.

i've tried this in Grass64 (with attached patch for the make-file), but no
manifest is written in C:\OSGeo4W\apps\grass\grass-6.4.0svn\bin

Helmut

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/759#comment:29&gt;
GRASS GIS <http://grass.osgeo.org>

#759: r.patch non-functional in WinGRASS 6.4 svn on Vista
------------------------------+---------------------------------------------
  Reporter: cmbarton | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: critical | Milestone: 6.4.0
Component: Raster | Version: 6.4.0 RCs
Resolution: | Keywords: r.patch, wingrass
  Platform: MSWindows Vista | Cpu: Unspecified
------------------------------+---------------------------------------------
Comment (by hellik):

Replying to [comment:29 hellik]:
> Replying to [comment:28 glynn]:
> > Replying to [comment:27 glynn]:
> >
> > > Try r40977.
> >
> > Not quite; needs r40978 as well.
> >
> > That builds what appear to be valid manifests, but it needs someone
with Vista or Windows 7 to test it.
>
> i've tried this in Grass64 (with attached patch for the make-file), but
no manifest is written in C:\OSGeo4W\apps\grass\grass-6.4.0svn\bin
>
> Helmut

now also tested with a fresh-svn-checkout in Grass7, all the manifest-
files are built.

Helmut

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/759#comment:30&gt;
GRASS GIS <http://grass.osgeo.org>

#759: r.patch non-functional in WinGRASS 6.4 svn on Vista
------------------------------+---------------------------------------------
  Reporter: cmbarton | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: critical | Milestone: 6.4.0
Component: Raster | Version: 6.4.0 RCs
Resolution: | Keywords: r.patch, wingrass
  Platform: MSWindows Vista | Cpu: Unspecified
------------------------------+---------------------------------------------
Comment (by glynn):

Replying to [comment:29 hellik]:

> i've tried this in Grass64 (with attached patch for the make-file), but
no manifest is written in C:\OSGeo4W\apps\grass\grass-6.4.0svn\bin

You need to add the "$(MAKE) manifests" to the "default" target (see
r40977).

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/759#comment:31&gt;
GRASS GIS <http://grass.osgeo.org>

#759: r.patch non-functional in WinGRASS 6.4 svn on Vista
------------------------------+---------------------------------------------
  Reporter: cmbarton | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: critical | Milestone: 6.4.0
Component: Raster | Version: 6.4.0 RCs
Resolution: | Keywords: r.patch, wingrass
  Platform: MSWindows Vista | Cpu: Unspecified
------------------------------+---------------------------------------------
Comment (by hellik):

Replying to [comment:31 glynn]:
> Replying to [comment:29 hellik]:
>
> > i've tried this in Grass64 (with attached patch for the make-file),
but no manifest is written in C:\OSGeo4W\apps\grass\grass-6.4.0svn\bin
>
> You need to add the "$(MAKE) manifests" to the "default" target (see
r40977).

attempts to fix this issue are checked in for Grass64 (r41034) and Grass65
(r41035).

please test by the nightly builds of Grass64 and Grass65.

Helmut

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/759#comment:32&gt;
GRASS GIS <http://grass.osgeo.org>

it was my impression that the previously reported bugs in v.voronoi were fixed - I checked the tracker and I don't see any related opened bug report. However, in 64 and 65 (compiled few days ago) I am still getting lines across the region in polygon result and holes in the raster generated from those polygons:

http://skagit.meas.ncsu.edu/~helena/grasswork/voronoibug_rast.png
http://skagit.meas.ncsu.edu/~helena/grasswork/voronoibug_poly.png

this has been generated using the nc_spm like this
http://courses.ncsu.edu/mea582/lec/001/GIS_anal_grass/GIS_Anal_grinterp1.html

the results from the contour points have the same problem with lines, but no holes
in the raster, so it looks like the holes are due to points that are close to each other and
the polygons are then not built and converted properly.

I don't think this is critical for the release, but should I file bug report to keep tract of it or is
this me making a mistake somewhere?

v.delaunay results look OK but I am not sure what they would be used for without the z-values.
http://skagit.meas.ncsu.edu/~helena/grasswork/delaunay_poly.png
I remember that there was some effort to get the z-values added to create a 3D vector
but I could not find anything in add ons - maybe I am missing something?

Helena

On Mon, 15 Feb 2010, Helena Mitasova wrote:

v.delaunay results look OK but I am not sure what they would be used for without the z-values.
http://skagit.meas.ncsu.edu/~helena/grasswork/delaunay_poly.png
I remember that there was some effort to get the z-values added to create a 3D vector
but I could not find anything in add ons - maybe I am missing something?

Hi Helena, I'm not sure if I'm aware of what the issue with v.delaunay z-values is, but wondered could it be related to this current bug: <http://trac.osgeo.org/grass/ticket/933&gt; ?
(Although that is about corrupted z-values, not absence of them.)

Paul

On Feb 16, 2010, at 4:13 AM, Paul Kelly wrote:

On Mon, 15 Feb 2010, Helena Mitasova wrote:

v.delaunay results look OK but I am not sure what they would be used for without the z-values.
http://skagit.meas.ncsu.edu/~helena/grasswork/delaunay_poly.png
I remember that there was some effort to get the z-values added to create a 3D vector
but I could not find anything in add ons - maybe I am missing something?

Hi Helena, I'm not sure if I'm aware of what the issue with v.delaunay z-values is, but wondered could it be related to this current bug: <http://trac.osgeo.org/grass/ticket/933&gt; ?
(Although that is about corrupted z-values, not absence of them.)

For the record - it was my mistake - I did not realize that I had my z-values were stored as attribute.
When I changed it to z-coordinate it came out quite nice
(the first is from contour points, the second from random points in nc_spm_08)
http://skagit.meas.ncsu.edu/~helena/grasswork/TINgrassnviz2.jpg
http://skagit.meas.ncsu.edu/~helena/grasswork/TINgrassnvizrand2.jpg
- maybe a hint in the man page would help.

The only problem that I had in GRASS65 was that nviz kept crashing when I tried to run it
with the vector data only so I had to add raster map as a reference plane.

Helena

Paul

Helena wrote:

The only problem that I had in GRASS65 was that nviz kept
crashing when I tried to run it
with the vector data only so I had to add raster map as a
reference plane.

not to defend the bug or anything, but the light grey base plane actually
makes quite a nice shadow effect. also it shouldn't be necessary to make
a "r.mapcalc one=1" dummy surface if you start nviz up empty and then add
a new constant raster surface of 1 before the vector surface.

Hamish

On Feb 20, 2010, at 2:13 AM, Hamish wrote:

Helena wrote:

The only problem that I had in GRASS65 was that nviz kept
crashing when I tried to run it
with the vector data only so I had to add raster map as a
reference plane.

not to defend the bug or anything, but the light grey base plane actually
makes quite a nice shadow effect. also it shouldn't be necessary to make
a "r.mapcalc one=1" dummy surface if you start nviz up empty and then add
a new constant raster surface of 1 before the vector surface.

it is not a problem if you know upfront that you have to do it - but when you type
nviz vector=mytin
it just crashes. At least an error message "raster is needed to display this data"
would help.

But I don't think anybody is actually trying to compute and visualize
TIN surfaces like this because the raster DEM from the same points
is just so much better. I did it only to generate images for the lecture to show
the difference between terrain models.

Going back to nviz - Google SoC has been announced, I lost track where it stands now
but I am wondering whether we should set up 2010 topics wiki and
give wxnviz some priority, if Martin would be willing to mentor it.
We (me and a group of students here) can certainly help to test, develop manual/help pages
and maybe even do some programming to help get it moving to replace nviz
which has many things broken or working only partially (points with attributes, file sequencing tool,
isosurfaces, etc ).

Another tool that needs replacement in wxGUI is xganim,
it is easy enough to generate animations using scripts but to quickly preview what you actually have
in the series, browse through it, identify problems or just quickly show it,
xganim has been unbeatable so far. So it may be a good topic for Google SoC
but I am not sure we have a mentor for it (I don't know enough about wxpython to be helpful here)

Helena

Hamish

#759: r.patch non-functional in WinGRASS 6.4 svn on Vista
------------------------------+---------------------------------------------
  Reporter: cmbarton | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: closed
  Priority: critical | Milestone: 6.4.0
Component: Raster | Version: 6.4.0 RCs
Resolution: fixed | Keywords: r.patch, wingrass
  Platform: MSWindows Vista | Cpu: Unspecified
------------------------------+---------------------------------------------
Changes (by hamish):

  * status: new => closed
  * resolution: => fixed

Comment:

Helmut wrote: (on the -dev ML)
> tested with the nightly wingrass-build from today
> (WinGRASS-6.4.SVN-r41114-1-Setup.exe) on a WinVista32-box,
> both are working now.

ok, thanks. closing bug.

> maybe further testing on Win7 is needed?

probably, but that goes for everything. reopen as needed.

Hamish

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/759#comment:33&gt;
GRASS GIS <http://grass.osgeo.org>

Helena wrote:

But I don't think anybody is actually trying to compute and visualize
TIN surfaces like this because the raster DEM from the same points
is just so much better.

they'll still try if it's what they've grown up with :slight_smile:

Going back to nviz - Google SoC has been announced, I lost
track where it stands now

your timing is very good, Wolf should announce something very soon.

I'll note that applications for mentoring organizations have not yet
opened and no one is guaranteed a spot or a specific number of students.
Still it helps to start thinking about this stuff early anyway.

but I am wondering whether we should set up 2010 topics wiki

done. http://grass.osgeo.org/wiki/GRASS_SoC_Ideas_2010

as you add ideas, keep in mind that we need both a great application
AND a matching mentor to accept anything- so in particular I worry about
who could mentor the much needed imagery & orthophoto port to wxPython.
Handing the student the "too hard" pile and walking away is rather risky.

also, for ideas with strategic and complex integration issues (C++ etc),
we need to specify how we want it to happen up front, rather than have
the student do all this hard work and then say sorry, it needs to be
rewritten to be merged into the main tree. I guess that's really a
project-wide communication issue, but it really helps in evaluating the
applications if we have an idea of what is viable and actually wanted
before hand. In practice focusing on "we want feature X" is secondary
to the quality of the applications we get; sometimes great students can
be convinced to put in multiple applications if we are impressed by
them but are not sure of their chosen task.

We (me and a group of students here) can certainly help to
test, develop manual/help pages
and maybe even do some programming to help get it moving to
replace nviz
which has many things broken or working only partially
(points with attributes, file sequencing tool,
isosurfaces, etc ).

what's the file sequencing tool do? is it like xganim in 3D but
simpler than the keyframe animator(s)?

(I wonder how hard it would be to quick-fix those things in the tcl?
It seems like a series of small bugfixes to me, just requires time and
tcl smarts to be thrown at it. and the discipline not to extend it :slight_smile:

Hamish