Re: [GRASS-dev] Re: wxnviz problems compiling develbranch_6 on the Mac

[Michael Barton]

William,

Your fix worked. Unfortunately, another change broke v.surf.bspline.

Michael



On Jan 12, 2009, at 8:20 PM, William Kyngesburye wrote:

There were more references to the pixmap field that was removed.  I  
cleaned that up for dev6, trunk and release64.  (but didn't make it  
into 6.4 RC2)


On Jan 12, 2009, at 3:54 PM, Martin Landa wrote:


2009/1/12 Michael Barton :
William Kyngesburye did a fix so that wxnviz would compile on the  
Mac.
nviz_cmd wouldn't work on the Mac, but it didn't cause compile  
problems.
Something has happened to make this break. Now I once again have  
to manually

delete ../lib/nviz/render.c before it will compile.


can you send error log?

Martin


-
William Kyngesburye 
http://www.kyngchaos.com/

Theory of the Universe

There is a theory which states that if ever anyone discovers exactly  
what the universe is for and why it is here, it will instantly  
disappear and be replaced by something even more bizarrely  
inexplicable.  There is another theory which states that this has  
already happened.


-Hitchhiker's Guide to the Galaxy 2nd season intro




___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] latest change in v.surf.bspline breaks it on a Mac

[Michael Barton]

I just updated develbranch_6 svn and compiled. v.surf.bspline will no  
longer compile. Lots of errors (or the same error many times.


See below
Michael


cmb-MBP-2:v.surf.bspline cmbarton$ cd /Users/cmbarton/grass_dev/ 
grass6_src/vector/lidar/v.surf.bspline

cmb-MBP-2:v.surf.bspline cmbarton$ make
gcc -I/Users/cmbarton/grass_dev/grass6_src/dist.i386-apple-darwin9.6.0/ 
include  -arch i386 -Os-I/Library/Frameworks/GDAL.framework/ 
Versions/1.6/Headers-DPACKAGE=\""grassmods"\"  -I/Users/cmbarton/ 
grass_dev/grass6_src/dist.i386-apple-darwin9.6.0/include -o OBJ.i386- 
apple-darwin9.6.0/main.o -c main.c

main.c: In function ‘main’:
main.c:358: error: syntax error before ‘<<’ token
main.c: At top level:
main.c:370: error: syntax error before ‘==’ token
main.c:373: error: initializer element is not constant
main.c:373: warning: data definition has no type or storage class
main.c:375: error: syntax error before ‘if’
main.c:389: error: syntax error before numeric constant
main.c:389: error: conflicting types for ‘G_debug’
main.c:389: note: a parameter list with an ellipsis can’t match an  
empty parameter name list declaration
/Users/cmbarton/grass_dev/grass6_src/dist.i386-apple-darwin9.6.0/ 
include/grass/gisdefs.h:426: error: previous declaration of ‘G_debug’  
was here

main.c:389: warning: data definition has no type or storage class
main.c:390: error: syntax error before ‘&’ token
main.c:390: warning: data definition has no type or storage class
main.c:391: error: syntax error before ‘&’ token
main.c:391: warning: data definition has no type or storage class
main.c:392: error: syntax error before ‘&’ token
main.c:392: warning: data definition has no type or storage class
main.c:393: error: syntax error before ‘&’ token
main.c:393: warning: data definition has no type or storage class
main.c:402: error: syntax error before ‘&’ token
main.c:402: error: conflicting types for ‘P_zero_dim’
/Users/cmbarton/grass_dev/grass6_src/dist.i386-apple-darwin9.6.0/ 
include/grass/PolimiFunct.h:98: error: previous declaration of  
‘P_zero_dim’ was here

main.c:402: warning: data definition has no type or storage class
main.c:403: error: syntax error before ‘.’ token
main.c:406: error: syntax error before ‘&’ token
main.c:406: warning: data definition has no type or storage class
main.c:408: error: ‘original_reg’ undeclared here (not in a function)
main.c:408: warning: data definition has no type or storage class
main.c:409: warning: data definition has no type or storage class
main.c:410: error: ‘dims’ undeclared here (not in a function)
main.c:410: warning: data definition has no type or storage class
main.c:411: warning: data definition has no type or storage class
main.c:412: warning: data definition has no type or storage class
main.c:413: warning: data definition has no type or storage class
main.c:415: error: syntax error before ‘if’
main.c:421: warning: initialization makes integer from pointer without  
a cast

main.c:421: error: initializer element is not constant
main.c:421: warning: data definition has no type or storage class
main.c:422: warning: initialization makes integer from pointer without  
a cast

main.c:422: error: initializer element is not constant
main.c:422: warning: data definition has no type or storage class
main.c:423: error: ‘In’ undeclared here (not in a function)
main.c:423: error: initializer element is not constant
main.c:423: warning: data definition has no type or storage class
main.c:432: error: syntax error before ‘.’ token
main.c:434: error: syntax error before numeric constant
main.c:434: warning: data definition has no type or storage class
main.c:435: warning: data definition has no type or storage class
main.c:436: warning: data definition has no type or storage class
main.c:437: error: syntax error before ‘while’
main.c:439: error: syntax error before ‘&’ token
main.c:440: warning: data definition has no type or storage class
main.c:447: error: ‘elaboration_reg’ undeclared here (not in a function)
main.c:448: error: ‘passoN’ undeclared here (not in a function)
main.c:448: error: initializer element is not constant
main.c:448: warning: data definition has no type or storage class
main.c:449: error: syntax error before numeric constant
main.c:449: error: conflicting types for ‘G_debug’
main.c:449: note: a parameter list with an ellipsis can’t match an  
empty parameter name list declaration
/Users/cmbarton/grass_dev/grass6_src/dist.i386-apple-darwin9.6.0/ 
include/grass/gisdefs.h:426: error: previous declaration of ‘G_debug’  
was here

main.c:449: warning: data definition has no type or storage class
main.c:458: error: redefinition of ‘nsply’
main.c:446: error: previous definition of ‘nsply’ was here
main.c:460: error: initializer element is not constant
main.c:460: warning: data definition has no type or storage class
main.c:461: error: redefinition of ‘last_row’
main.c:436: error: previous definition of ‘last_row’ was here
main.c:461: warning: data definition has no type

Re: [GRASS-dev] Re: wxnviz problems compiling develbranch_6 on the Mac

[Michael Barton]

Thanks. I'll update and try it again.

Michael

C. 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-6262
Fax: 480-965-7671
www: 



On Jan 12, 2009, at 8:20 PM, William Kyngesburye wrote:

There were more references to the pixmap field that was removed.  I  
cleaned that up for dev6, trunk and release64.  (but didn't make it  
into 6.4 RC2)


On Jan 12, 2009, at 3:54 PM, Martin Landa wrote:


2009/1/12 Michael Barton :
William Kyngesburye did a fix so that wxnviz would compile on the  
Mac.
nviz_cmd wouldn't work on the Mac, but it didn't cause compile  
problems.
Something has happened to make this break. Now I once again have  
to manually

delete ../lib/nviz/render.c before it will compile.


can you send error log?

Martin


-
William Kyngesburye 
http://www.kyngchaos.com/

Theory of the Universe

There is a theory which states that if ever anyone discovers exactly  
what the universe is for and why it is here, it will instantly  
disappear and be replaced by something even more bizarrely  
inexplicable.  There is another theory which states that this has  
already happened.


-Hitchhiker's Guide to the Galaxy 2nd season intro




___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Re: wxnviz problems compiling develbranch_6 on the Mac

[William Kyngesburye]

There were more references to the pixmap field that was removed.  I  
cleaned that up for dev6, trunk and release64.  (but didn't make it  
into 6.4 RC2)


On Jan 12, 2009, at 3:54 PM, Martin Landa wrote:


2009/1/12 Michael Barton :
William Kyngesburye did a fix so that wxnviz would compile on the  
Mac.
nviz_cmd wouldn't work on the Mac, but it didn't cause compile  
problems.
Something has happened to make this break. Now I once again have to  
manually

delete ../lib/nviz/render.c before it will compile.


can you send error log?

Martin


-
William Kyngesburye 
http://www.kyngchaos.com/

Theory of the Universe

There is a theory which states that if ever anyone discovers exactly  
what the universe is for and why it is here, it will instantly  
disappear and be replaced by something even more bizarrely  
inexplicable.  There is another theory which states that this has  
already happened.


-Hitchhiker's Guide to the Galaxy 2nd season intro


___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: [GRASS-windows] Compiling grass7 on msys/mingw?

[Colin Nielsen]

Glynn,

> I have attached a complete, modified Html.make file to avoid
> confusion. This has at least been tested on Linux.

> Ugh. I suspect os.execvp() needs "g.parser.exe" rather than
> "g.parser". On Windows, only the higher-level interfaces (e.g.
> ShellExecute() or "cmd /c ...") allow the .exe (or .bat etc) extension
> to be omitted.

Thanks for the help. You were right on both counts. I added the new
Html.make and edited the grass.py line 208 to:
 os.execvp("g.parser.exe", [name] + argv)

That works too, the scripts compile perfectly now. Although I realize
that some work around will be needed to make it OS generic.

Any idea why I get the other error for r.mapcalc, r.univar,
raster3d/base and v.voronoi?

gcc -L/usr/local/src/grass_trunk/dist.i686-pc-mingw32/lib
-Wl,--export-dynamic,--enable-runtime-pseudo-reloc  -L/usr/local/lib
-L/usr/local/pgsql/lib  -o
/usr/local/src/grass_trunk/dist.i686-pc-mingw32/bin/r.mapcalc.exe
../../lib/gis/OBJ.i686-pc-mingw32/fmode.o -lgrass_gis -lgrass_datetime
-lxdr -liberty -lws2_32-lz -lgrass_btree-lxdr -liberty
-lws2_32-lz
/mingw/lib/libmingw32.a(main.o):main.c:(.text+0x104): undefined
reference to `winm...@16'
collect2: ld returned 1 exit status
make: *** [/usr/local/src/grass_trunk/dist.i686-pc-mingw32/bin/r.mapcalc.exe]
Error 1

> 7.0 is quite fluid, and it doesn't seem to be getting much testing on
> Windows (6.x doesn't get much testing either, but then 6.x isn't being
> substantially rewritten).
>

I am happy to test / keep posting errors for grass70 and grass64 as I
use grass in Windows Vista regularly. Let me know if there is anything
specific I should be testing/ looking for.

-Colin
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: [GRASS GIS] #429: Add option to disable warnings in modules

[GRASS GIS]

#429: Add option to disable warnings in modules
--+-
  Reporter:  kyngchaos|   Owner:  grass-dev@lists.osgeo.org
  Type:  enhancement  |  Status:  new  
  Priority:  minor|   Milestone:  6.4.0
 Component:  default  | Version:  svn-develbranch6 
Resolution:   |Keywords:   
  Platform:  Unspecified  | Cpu:  Unspecified  
--+-
Comment (by kyngchaos):

 > better: fix the noisy module.

 Well, it's in the GRASS proj library, do_proj.c: pj_do_proj() and
 pj_do_transform(), so it'll affect anything that projects coordinates.  I
 don't see a way to remove it for a single module other than a flag.

 {{{
 if (ok < 0) {
   G_warning(_("pj_transform() failed: %s"), pj_strerrno(ok));
 }
 return ok;
 }}}

-- 
Ticket URL: 
GRASS GIS 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: [GRASS GIS] #429: Add option to disable warnings in modules

[GRASS GIS]

#429: Add option to disable warnings in modules
--+-
  Reporter:  kyngchaos|   Owner:  grass-dev@lists.osgeo.org
  Type:  enhancement  |  Status:  new  
  Priority:  minor|   Milestone:  6.4.0
 Component:  default  | Version:  svn-develbranch6 
Resolution:   |Keywords:   
  Platform:  Unspecified  | Cpu:  Unspecified  
--+-
Comment (by hamish):

 Replying to [ticket:429 kyngchaos]:
 > I would like to be able to suppress warning messages in
 > commands, yet keep messages based on the GRASS_VERBOSE level,
 > especially in raster projection (r.proj) where is possible
 > to get thousands of "pj_transform() failed: tolerance condition
 > error" warnings, depending on the projection, that are expected
 > but clutter the progress output and slow down the process.

 better: fix the noisy module. e.g.

 {{{
  if(!pj_fail_flag)
 G_warning();
  else
 pj_fail_flag = TRUE;
 }}}


 > I see that G_warning() has a companion G_suppress_warnings(),
 > so this at least was an intended possibility at one time (but
 > maybe deprecated or discouraged now?).

 vaguely discouraged, as it will inadvertently hide important problems, and
 you /will/ be bitten by this after some time.


 Hamish

-- 
Ticket URL: 
GRASS GIS 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] [GRASS GIS] #429: Add option to disable warnings in modules

[GRASS GIS]

#429: Add option to disable warnings in modules
-+--
 Reporter:  kyngchaos|   Owner:  grass-dev@lists.osgeo.org
 Type:  enhancement  |  Status:  new  
 Priority:  minor|   Milestone:  6.4.0
Component:  default  | Version:  svn-develbranch6 
 Keywords:   |Platform:  Unspecified  
  Cpu:  Unspecified  |  
-+--
 I would like to be able to suppress warning messages in commands, yet keep
 messages based on the GRASS_VERBOSE level, especially in raster projection
 (r.proj) where is possible to get thousands of "pj_transform() failed:
 tolerance condition error" warnings, depending on the projection, that are
 expected but clutter the progress output and slow down the process.

 I see that G_warning() has a companion G_suppress_warnings(), so this at
 least was an intended possibility at one time (but maybe deprecated or
 discouraged now?).

-- 
Ticket URL: 
GRASS GIS 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] GRASS 6.4.0 RC2 released

[Markus Neteler]

A second release candidate of GRASS 6.4.0 is now available:

 http://grass.osgeo.org/grass64/source/
 http://grass.osgeo.org/grass64/source/grass-6.4.0RC2.tar.gz

To get the RC2 source code from SVN:
 svn checkout 
http://svn.osgeo.org/grass/grass/tags/release_20090112_grass_6_4_0RC2

An announcement has been drafted at
 http://trac.osgeo.org/grass/wiki/Release/6.4.0RC2-News

All news will be merged into the final announcement later.

Key improvements of the GRASS 6.4.0 release include enhanced
portability for MS-Windows (native support), hundreds of fixes,
the new wxPython based portable graphical interface and much
new functionality.

Release candidate management at
 http://grass.osgeo.org/wiki/GRASS_6.4_Feature_Plan

Please test, test, test...

Thanks to all contributors!

Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: [GRASS GIS] #428: g.proj -c defines wrong default values

[GRASS GIS]

#428: g.proj -c defines wrong default values
--+-
  Reporter:  martinl  |   Owner:  grass-dev@lists.osgeo.org  
  Type:  defect   |  Status:  new
  Priority:  major|   Milestone:  6.4.0  
 Component:  default  | Version:  6.4.0 RCs  
Resolution:   |Keywords:  projection, create location
  Platform:  All  | Cpu:  All
--+-
Comment (by pkelly):

 Without looking in depth, it seems to me it is a bug / "feature" of PROJ
 that the first syntax, i.e. with no parameters specified, actually works.
 For clarity it is best to specify the parameters.

 How g.proj works is it uses OGR functions to parse and validate the PROJ.4
 string before converting it into GRASS format. OGR interprets the string
 differently from PROJ.4 - internally it converts it to WKT format so I'm
 guessing that it requires the parameters to be specified, and because none
 are there it sets them to zero. Then when OGR exports the validated
 projection back to g.proj the parameters will be set to zero.

 Perhaps the best fix is for PROJ.4 to be modified so it does not accept
 the syntax with no parameters specified. But that is not good as it will
 break existing installations where people use the syntax with no
 parameters.

-- 
Ticket URL: 
GRASS GIS 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: [GRASS GIS] #428: g.proj -c defines wrong default values

[GRASS GIS]

#428: g.proj -c defines wrong default values
--+-
  Reporter:  martinl  |   Owner:  grass-dev@lists.osgeo.org  
  Type:  defect   |  Status:  new
  Priority:  major|   Milestone:  6.4.0  
 Component:  default  | Version:  6.4.0 RCs  
Resolution:   |Keywords:  projection, create location
  Platform:  All  | Cpu:  All
--+-
Comment (by martinl):

 Generally speaking, g.proj -c should not define any default values, if
 user decide not to define them. Or am I wrong?

-- 
Ticket URL: 
GRASS GIS 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: [GRASS GIS] #428: g.proj -c defines wrong default values

[GRASS GIS]

#428: g.proj -c defines wrong default values
--+-
  Reporter:  martinl  |   Owner:  grass-dev@lists.osgeo.org  
  Type:  defect   |  Status:  new
  Priority:  major|   Milestone:  6.4.0  
 Component:  default  | Version:  6.4.0 RCs  
Resolution:   |Keywords:  projection, create location
  Platform:  All  | Cpu:  All
--+-
Comment (by martinl):

 Compare:

 {{{
 echo "15 50" | proj +proj=krovak +ellps=bessel +no_defs
 +towgs84=570.8,85.7,462.8,4.998,1.587,5.261,3.56 +to_meter=1.0
 -703105.69  -1058219.60
 }}}

 {{{
 echo "15 50" | proj +proj=krovak +proj=krovak +lat_0=49.5
 +lon_0=24.83 +alpha=30.2881397222 +k=0. +x_0=0 +y_0=0
 +ellps=bessel +units=m +no_defs
 -703105.69  -1058219.60
 }}}

 and

 {{{
 echo "15 50" | proj +proj=krovak +lat_0=0 +lon_0=0 +k=1 +x_0=0 +y_0=0
 +no_defs +a=6377397.155 +rf=299.1528128
 +towgs84=570.8,85.7,462.8,4.998,1.587,5.261,3.56 +to_meter=1
 1067856.48  -996126.10
 }}}

-- 
Ticket URL: 
GRASS GIS 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: [GRASS GIS] #428: g.proj -c defines wrong default values

[GRASS GIS]

#428: g.proj -c defines wrong default values
--+-
  Reporter:  martinl  |   Owner:  grass-dev@lists.osgeo.org  
  Type:  defect   |  Status:  new
  Priority:  major|   Milestone:  6.4.0  
 Component:  default  | Version:  6.4.0 RCs  
Resolution:   |Keywords:  projection, create location
  Platform:  All  | Cpu:  All
--+-
Comment (by neteler):

 I assume that some *should* be defined... at least EPSG 2065 suggests so.

 Compare also http://trac.osgeo.org/gdal/ticket/2559

 Markus

-- 
Ticket URL: 
GRASS GIS 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: wxnviz problems compiling develbranch_6 on the Mac

[Martin Landa]

2009/1/12 Michael Barton :
> William Kyngesburye did a fix so that wxnviz would compile on the Mac.
> nviz_cmd wouldn't work on the Mac, but it didn't cause compile problems.
> Something has happened to make this break. Now I once again have to manually
> delete ../lib/nviz/render.c before it will compile.

can you send error log?

Martin

-- 
Martin Landa  * http://gama.fsv.cvut.cz/~landa *
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: r.walk, r.cost & r.drain patches posted

[Michael Barton]

Maybe what is needed is a built in vectorization algorithm that will  
transform the paths to vectors is a flag is set.


Michael

C. 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-6262
Fax: 480-965-7671
www: 



On Jan 7, 2009, at 9:32 AM, Colin Nielsen wrote:

Thanks for the updates. I'll give them a try. While I understand  
the reason
for the gaps in the paths now, I think that it is important to find  
some way
to get rid of them. That is, there needs to be some algorithm that  
will

'connect the dots' of knights move jumps.


I certainly agree but it should be done without adding cells in
between. The knight's moves should be retained in the output. We need
some kind of vectorization algorithm which connects cell center to
cell center, or which joins all the little line segments that would be
produced by a discontinuous path.


Even without vectorizing, the cell accumulation
values will be inaccurate if cells are skipped in a path from point  
A to

point B.


The algorithm accounts for the accumulation value in these larger
jumps using pythagoras. Just as diagonals are multiplied by ~1.4,
knight's move jumps are multiplied by ~2.2 (but depending on the
resolution, etc.).

-Colin


___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] wxnviz problems compiling develbranch_6 on the Mac

[Michael Barton]

William Kyngesburye did a fix so that wxnviz would compile on the Mac.  
nviz_cmd wouldn't work on the Mac, but it didn't cause compile  
problems. Something has happened to make this break. Now I once again  
have to manually delete ../lib/nviz/render.c before it will compile.



Michael
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] [GRASS GIS] #428: g.proj -c defines wrong default values

[GRASS GIS]

#428: g.proj -c defines wrong default values
-+--
 Reporter:  martinl  |   Owner:  
grass-dev@lists.osgeo.org
 Type:  defect   |  Status:  new
  
 Priority:  major|   Milestone:  6.4.0  
  
Component:  default  | Version:  6.4.0 RCs  
  
 Keywords:  projection, create location  |Platform:  All
  
  Cpu:  All  |  
-+--
 Creating location with g.proj, e.g.,

 {{{
 g.proj -c proj="+proj=krovak +a=6377397.155 +rf=299.1528128 +no_defs
 +towgs84=570.8,85.7,462.8,4.998,1.587,5.261,3.56" location=s-jtsk
 }}}

 some unwanted default values are defined, why?

 {{{
  g.proj -p
 -PROJ_INFO-
 name   : Krovak
 proj   : krovak
 ellps  : bessel
 lat_0  : 0 <- here
 lon_0  : 0 <- here
 alpha  : 0 <- here
 k  : 1 <- here
 x_0: 0 <- here
 y_0: 0 <- here
 towgs84: 570.8,85.7,462.8,4.998,1.587,5.261,3.56
 no_defs: defined
 -PROJ_UNITS
 unit   : meter
 units  : meters
 meters : 1
 }}}

 Martin

-- 
Ticket URL: 
GRASS GIS 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: [GRASS-windows] Compiling grass7 on msys/mingw?

[Glynn Clements]

Colin Nielsen wrote:

> > I suspect that Python wants PYTHONPATH to use Windows syntax, e.g.
> > (untested):
> >
> > -   PYTHONPATH="$(GISBASE)/etc/python:$$PYTHONPATH" \
> > +   PYTHONPATH="$(call mkpath,$(GISBASE)/etc/python,$$PYTHONPATH)" \
> > +
> > +ifneq ($(MINGW32),)
> > +mkpath = $(shell g.dirseps -h $(1))\;$(2)
> > +else
> > +mkpath = $(1):$(2)
> > +endif
> 
> I applied this to the Html.make file and tried again. I got:

[snip]

If you apply the above as-is, you will get this error. The htmldesc=
definition needs to be a contiguous block, and the ifneq...endif block
needs to follow it.

I have attached a complete, modified Html.make file to avoid
confusion. This has at least been tested on Linux.

> I then checked the variable PYTHONPATH and found that my Arc
> installation over-wrote the PYTHONPATH variable to its own folder. I
> changed this back to /usr/local/src/grass_trunk/lib/Python and ran it
> again (with the original Html.make) and got:

> os.execvp("g.parser", [name] + argv)
>   File "C:\MinGW\Python\lib\os.py", line 353, in execvp
> _execvpe(file, args)
>   File "C:\MinGW\Python\lib\os.py", line 389, in _execvpe
> func(fullname, *argrest)
> OSError: [Errno 2] No such file or directory

Ugh. I suspect os.execvp() needs "g.parser.exe" rather than
"g.parser". On Windows, only the higher-level interfaces (e.g. 
ShellExecute() or "cmd /c ...") allow the .exe (or .bat etc) extension
to be omitted.

On Windows, we might want to use subprocess.Popen(shell=True) followed
by sys.exit() instead of os.execvp().

> Before I continue with this, is this some peculiarity with my
> installation or a more general problem with grass7 on mingw/msys?

The latter.

7.0 is quite fluid, and it doesn't seem to be getting much testing on
Windows (6.x doesn't get much testing either, but then 6.x isn't being
substantially rewritten).

-- 
Glynn Clements 


# generic html rules for all commands

ifdef CROSS_COMPILING

html:

else

htmldesc = \
GISRC=$(RUN_GISRC) \
GISBASE=$(RUN_GISBASE) \
PATH="$(BIN):$$PATH" \
PYTHONPATH="$(call mkpath,$(GISBASE)/etc/python,$$PYTHONPATH)" \

$(LD_LIBRARY_PATH_VAR)="$(BIN):$(ARCH_LIBDIR):$($(LD_LIBRARY_PATH_VAR))" \
LC_ALL=C \
$(1) --html-description < /dev/null | grep -v '\|' > $(2)

ifneq ($(MINGW32),)
mkpath = $(shell g.dirseps -h $(1))\;$(2)
else
mkpath = $(1):$(2)
endif

$(HTMLDIR)/%.html: %.html %.tmp.html $(HTMLSRC)
-test -d $(HTMLDIR) || $(MKDIR) $(HTMLDIR)
$(MODULE_TOPDIR)/tools/mkhtml.sh $* > $@
-for file in  *.png *.jpg ; do \
head -n 1 $$file | grep '^\#!' > /dev/null ; \
if [ $$? -ne 0 ] ; then \
   $(INSTALL_DATA) $$file $(HTMLDIR) ; \
fi \
done 2> /dev/null ; true

$(MANDIR)/%.$(MANSECT): $(HTMLDIR)/%.html
$(HTML2MAN) $< $@

%.tmp.html: $(HTMLSRC)
if [ "$(HTMLSRC)" != "" ] ; then $(call htmldesc,$<,$@) ; fi

html: $(HTMLDIR)/$(PGM).html $(MANDIR)/$(PGM).$(MANSECT)

endif

.PHONY: html
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] gmath and gpde update

[Moritz Lennert]

On 12/01/09 16:25, Glynn Clements wrote:

Moritz Lennert wrote:


However, is

** Everyone is granted permission to copy, modify and redistribute this
** Meschach Library, provided:
[...]
**  3.  No charge is made for this software or works derived from it.
**  This clause shall not be construed as constraining other software
**  distributed on the same medium as this software, nor is a
**  distribution fee considered a charge.

GPL-compatible ?


Ah; I don't think so.

The GPL allows you to charge for derivative works (although being
unable to prohibit free redistribution tends to limit this).

Anyone distributing GRASS binaries is required to provide (or offer to
provide) the source code for "the work as a whole" (which would
include meschach) under the terms of the GPL.

This would then allow the recipient to extract any part (e.g. 
meschach) and (try to) sell it. While that seems like a rather

unlikely scenario, the GPL requires that you permit this, and if you
cannot permit it, you cannot satisfy the GPL.

And the meschach library appears not to permit it.


That's what I thought...

Interesting that Debian thought it DFSG-compatible...

Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: [GRASS GIS] #419: cairo compilation error

[GRASS GIS]

#419: cairo compilation error
--+-
  Reporter:  neteler  |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect   |  Status:  new  
  Priority:  major|   Milestone:  7.0.0
 Component:  default  | Version:  svn-trunk
Resolution:   |Keywords:   
  Platform:  Linux| Cpu:  x86-32   
--+-
Comment (by mlennert):

 Replying to [comment:6 glynn]:
 > Replying to [comment:5 mlennert]:
 >
 > > svn update and recompile now gives only one error:
 > >
 > >
 > {{{
 > /home/mlennert/SRC/GRASS/grass_trunk/general/g.cairocomp/main.c:118:
 undefined reference to `cairo_xlib_surface_get_xrender_format'
 >
 > make: *** [/home/mlennert/SRC/GRASS/grass_trunk/dist.i486-pc-linux-
 gnu/bin/g.cairocomp] Error 1
 > }}}
 > >
 > > Using cairo 1.4.14 on Debian stable.
 >
 > Right; I can only fix this in the sense of adding a configure check for
 cairo_xlib_surface_get_xrender_format() and not building g.cairocomp if
 it's missing. g.cairocomp can't work without that function, but the cairo
 driver can.


 And do I understand correctly that g.cairocomp is need to use the GUI, at
 least when using the default cairo driver ?

 I guess it's time to compile a more recent version of cairo, then...

 Moritz

-- 
Ticket URL: 
GRASS GIS 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] gmath and gpde update

[Glynn Clements]

Moritz Lennert wrote:

> However, is
> 
> ** Everyone is granted permission to copy, modify and redistribute this
> ** Meschach Library, provided:
> [...]
> **  3.  No charge is made for this software or works derived from it.
> **  This clause shall not be construed as constraining other software
> **  distributed on the same medium as this software, nor is a
> **  distribution fee considered a charge.
> 
> GPL-compatible ?

Ah; I don't think so.

The GPL allows you to charge for derivative works (although being
unable to prohibit free redistribution tends to limit this).

Anyone distributing GRASS binaries is required to provide (or offer to
provide) the source code for "the work as a whole" (which would
include meschach) under the terms of the GPL.

This would then allow the recipient to extract any part (e.g. 
meschach) and (try to) sell it. While that seems like a rather
unlikely scenario, the GPL requires that you permit this, and if you
cannot permit it, you cannot satisfy the GPL.

And the meschach library appears not to permit it.

-- 
Glynn Clements 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] gmath and gpde update

[Glynn Clements]

Soeren Gebbert wrote:

> > > * adding the prefix G_math_ to all extern library functions (with
> > > preprocessor directives)
> >
> > Why?
> 
> To mark the meschach code as part of the gmath library. Many functions in
> meschach are quite short
> and in this manner not self explaining. I think the grass code using
> meschach will
> be more readable if a prefix is used. A developer who is not familiar with
> meschach will identify the
> functions as part of the gmath library and will not search for local
> function definitions.
> But i wont touch any function name in the code of meschach. Instead i would
> like to include the meschach
> includes into gmath.h and redefine the meschach names with macros:

That's preferable, although it might be better to create wrapper
functions than macros, e.g.:

int G_math_somefunc(void) { return somefunc(); }

Excessive use of macros can be a nuisance; macros don't show up in
"nm" output, or in gdb backtraces, can't have breakpoints set on them,
can't be called from gdb, etc.

-- 
Glynn Clements 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: [GRASS GIS] #419: cairo compilation error

[GRASS GIS]

#419: cairo compilation error
--+-
  Reporter:  neteler  |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect   |  Status:  new  
  Priority:  major|   Milestone:  7.0.0
 Component:  default  | Version:  svn-trunk
Resolution:   |Keywords:   
  Platform:  Linux| Cpu:  x86-32   
--+-
Comment (by glynn):

 Replying to [comment:5 mlennert]:

 > svn update and recompile now gives only one error:
 >
 >
 {{{
 /home/mlennert/SRC/GRASS/grass_trunk/general/g.cairocomp/main.c:118:
 undefined reference to `cairo_xlib_surface_get_xrender_format'

 make: *** [/home/mlennert/SRC/GRASS/grass_trunk/dist.i486-pc-linux-
 gnu/bin/g.cairocomp] Error 1
 }}}
 >
 > Using cairo 1.4.14 on Debian stable.

 Right; I can only fix this in the sense of adding a configure check for
 cairo_xlib_surface_get_xrender_format() and not building g.cairocomp if
 it's missing. g.cairocomp can't work without that function, but the cairo
 driver can.

-- 
Ticket URL: 
GRASS GIS 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Error compiling grass6_devel

[Glynn Clements]

Markus Neteler wrote:

> >> Today I tried to compile grass6_devel fresh from svn and got this problem:
> >>
> >> gcc 
> >> -I/home/bobm/src/gis/grass6_devel/dist.x86_64-unknown-linux-gnu/include  
> >> -g -O2-fPIC   -DPACKAGE=\""grasslibs"\" -I/usr/local/include 
> >> -DPACKAGE=\""grasslibs"\"-I/usr/include/ffmpeg 
> >> -I/home/bobm/src/gis/grass6_devel/dist.x86_64-unknown-linux-gnu/include -o 
> >> OBJ.x86_64-unknown-linux-gnu/gsd_img_mpeg.o -c gsd_img_mpeg.c
> >> In file included from gsd_img_mpeg.c:29:
> >> /usr/include/ffmpeg/avformat.h:282: warning: �AVFrac� is deprecated
> >> gsd_img_mpeg.c: In function �gsd_close_mpeg�:
> >> gsd_img_mpeg.c:439: error: incompatible type for argument 1 of �url_fclose�
> >> make: *** [OBJ.x86_64-unknown-linux-gnu/gsd_img_mpeg.o] Error 1
> >
> > At the bottom of lib/ogsf/gsd_img_mpeg.c, change the line:
> >
> >url_fclose(&oc->pb);
> > to:
> >url_fclose(oc->pb);
> >
> > This has been fixed in 7.0 in r35270, but not backported.
> 
> Are you sure?
> http://trac.osgeo.org/grass/changeset/35273
> http://trac.osgeo.org/grass/changeset/35272

My mistake. I assumed that he was having the problem the fix was meant
to address, but it's the opposite problem.

-- 
Glynn Clements 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] tcl files in grass7

[Martin Landa]

Hi,

2009/1/12 Glynn Clements :
>
> Martin Landa wrote:
>
>> > # I guess to be retired with new py-nviz
>> > ./visualization/nviz/scripts/*.tcl
>>
>> wxNviz is not currently fully functional, some Nviz features are
>> missing (50%). So we can wait with removal.
>
> Except that lib/external/bwidget has been removed, and the Tcl/Tk NVIZ
> won't run without it.

right, lib/gtcltk and lib/external/bwidget again in trunk (r35358).
Now nviz should work.

Martin

-- 
Martin Landa  * http://gama.fsv.cvut.cz/~landa *
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: [GRASS GIS] #425: v.out.ogr: don't use random access to find attributes

[GRASS GIS]

#425: v.out.ogr: don't use random access to find attributes
--+-
  Reporter:  neteler  |   Owner:  grass-dev@lists.osgeo.org
  Type:  enhancement  |  Status:  new  
  Priority:  major|   Milestone:  6.5.0
 Component:  Vector   | Version:  unspecified  
Resolution:   |Keywords:   
  Platform:  All  | Cpu:  All  
--+-
Comment (by mlennert):

 Replying to [ticket:425 neteler]:
 > Moved here from
 http://trac.osgeo.org/grass/browser/grass/trunk/doc/vector/TODO#L250
 >
 > Radim suggested:
 >
 > v.out.ogr is very slow because it is using random access to the
 attributes. It should be rewritten so that all attributes are selected by
 one query, geometry for each attribute can be searched by category index
 (which is fast).

 I've implemented something like this in a long-ago rewrite (never
 committed) of d.vect.chart [1] - see plot.c. It uses db_open_select_cursor
 to access the table in one query and then for each row Vect_cidx_find_all
 to find the geometries associated to the cat value in that row.



 Moritz



 [1] http://lists.osgeo.org/pipermail/grass-dev/2006-October/026624.html

-- 
Ticket URL: 
GRASS GIS 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] gmath and gpde update

[Soeren Gebbert]

Thanks for you suggestions Glynn.

2009/1/12 Glynn Clements 

>
> Soeren Gebbert wrote:
>
> > In case we will use the meschach library within grass to replace the
> > existing LAPACK wrapper, my BLAS and solver implementation
> > and several numerical recipes algorithm (lu, eigenvalues solvers ...), i
> > will take the patched debian sources and integrate them into
> > grass.
> >
> > IMHO the following changes have to be made in the meschach library:
> >
> > * replacing malloc, calloc and realloc with the GRASS implementation
>
> Not necessarily. The G_* versions are merely a convenience to avoid
> having to explicitly check for failure. If meschach is already
> performing the checking, there probably isn't much reason to change
> it.
>

Agreed, AFAICT memory checks are performed in meschach.
But i was hoping to get rid of the machine dependent defines within the
include files of meschach,
grass already checks for malloc, calloc and realloc.


>
> > * replacing printf and fprintf with the GRASS implementation
>
> GRASS doesn't have implementations of those functions. It has
> G_message() etc, which should be used for communicating with the user.


Sorry for confusion, i ment G_message() etc.
Usage of G_message() will probably integrate meschach better in the grass
message handling (quite, verbose ...).
But i have to think more about this. You are making a good point.
In case a distribution version of meschach will be used, instead of the copy
in grass,
the message handling will process in the original way ..  so the benefit of
changing the
message handling in the grass copy is lost ... and because of that not
meaningful at all.


>
>
> > * changing the error handling to use G_fatal_error and similar GRASS
> > functions
>
> Probably, although this should be done in a minimal manner, e.g.
> making errors call a user-defined callback, and installing a callback
> which calls G_fatal_error().


Agreed.

>
>
> > * adding the prefix G_math_ to all extern library functions (with
> > preprocessor directives)
>
> Why?


To mark the meschach code as part of the gmath library. Many functions in
meschach are quite short
and in this manner not self explaining. I think the grass code using
meschach will
be more readable if a prefix is used. A developer who is not familiar with
meschach will identify the
functions as part of the gmath library and will not search for local
function definitions.
But i wont touch any function name in the code of meschach. Instead i would
like to include the meschach
includes into gmath.h and redefine the meschach names with macros:

gmath.h:

/*meschach includes*/
#ifndef SYSTEM_MESCHACH
#include "grass/matrix.h"
...
#else
#include 
...
#endif

#define G_math_iv_get iv_get
#define G_math_SPMAT SPMAT
#define G_math_sp_free sp_free
...


>
>
> Is there some reason why GRASS must "assimilate" meschach rather than
> simply using it (with any modifications which are strictly necessary).


No.


>
>
> In particular, if any distributions provide a meschach package, it's
> generally preferable to use that rather than a private copy.


Agreed.
But IMHO a copy of meschach should be provided in grass with minimal changes
so it can be
replaced with a distribution version. I guess this can be handled at
configuration time.

Soeren


>
>
> --
> Glynn Clements 
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: [GRASS GIS] #419: cairo compilation error

[GRASS GIS]

#419: cairo compilation error
--+-
  Reporter:  neteler  |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect   |  Status:  new  
  Priority:  major|   Milestone:  7.0.0
 Component:  default  | Version:  svn-trunk
Resolution:   |Keywords:   
  Platform:  Linux| Cpu:  x86-32   
--+-
Comment (by mlennert):

 Replying to [comment:4 glynn]:
 > Replying to [comment:3 mlennert]:
 >
 > > > > What's the minimum version of cairo needed here?
 >
 > > Looks like 1.5.8 would be enough:
 >
 > I'll update the test accordingly.
 >
 > > I have the same problem with
 > >
 > > cairo_xlib_surface_get_xrender_format
 >
 > That should be conditionalised upon CAIRO_HAS_XLIB_XRENDER_SURFACE. The
 function should be defined in cairo-xlib-xrender.h.
 >
 > Can you provide more details?

 svn update and recompile now gives only one error:


 {{{
 mlenn...@geog-pc40:~/SRC/GRASS/grass_trunk/general/g.cairocomp$ export
 LANG=C; make
 gcc -L/home/mlennert/SRC/GRASS/grass_trunk/dist.i486-pc-linux-gnu/lib -Wl,
 --export-dynamic -Wl,-rpath-
 link,/home/mlennert/SRC/GRASS/grass_trunk/dist.i486-pc-linux-gnu/lib   -o
 /home/mlennert/SRC/GRASS/grass_trunk/dist.i486-pc-linux-
 gnu/bin/g.cairocomp OBJ.i486-pc-linux-gnu/main.o  -lgrass_gis
 -lgrass_datetime -lz -lXrender -lcairo -lX11  -lm  -lz
 OBJ.i486-pc-linux-gnu/main.o: In function `init_xlib':
 /home/mlennert/SRC/GRASS/grass_trunk/general/g.cairocomp/main.c:118:
 undefined reference to `cairo_xlib_surface_get_xrender_format'
 collect2: ld returned 1 exit status
 make: *** [/home/mlennert/SRC/GRASS/grass_trunk/dist.i486-pc-linux-
 gnu/bin/g.cairocomp] Error 1
 }}}

 Using cairo 1.4.14 on Debian stable.

 Moritz

-- 
Ticket URL: 
GRASS GIS 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] gmath and gpde update

[Moritz Lennert]

On 11/01/09 22:32, Moritz Lennert wrote:

On 11/01/09 14:02, Glynn Clements wrote:

Moritz Lennert wrote:

Meschach is implemented in C and is able to replace the gmath 
library completely with much better implementations.
I have integrated meschach into grass for testing purposes and, 
after some very basic testing, it works nicely.
But im unsure if the licence of meschach is compatible with the GPL? 
Can somebody please verify this? Im not an expert in licensing.

This seems to be the relevant part:



"The source code is available to be perused, used and passed on without
cost, while ensuring that the quality of the software is not 
compromised."


There is no mention of modification, and the second half of the 
sentence ("while ensuring that the quality of the software is not 
compromised") sounds quite suspicious to me. So, without claiming any 
expert knowledge either, I would be sceptical.


Where did you find that? 


http://www.netlib.org/c/meschach/readme


It appears to contradict:

http://packages.debian.org/changelogs/pool/main/m/meschach/current/copyright 


The Debian version is what's in the copyright file in the source code 
available here:


http://www.math.uiowa.edu/~dstewart/meschach/mesch12b.tar.gz

So, sorry for the confusion, no contradiction (just an unclear readme file).

However, is

** Everyone is granted permission to copy, modify and redistribute this
** Meschach Library, provided:
[...]
**  3.  No charge is made for this software or works derived from it.
**  This clause shall not be construed as constraining other software
**  distributed on the same medium as this software, nor is a
**  distribution fee considered a charge.


GPL-compatible ?

Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev