Re: [GRASS-dev] [GRASS GIS] #3331: ctypes: ValueError: invalid literal for int() with base 8: '08420217248550443400745280086994171'

2017-06-05 Thread GRASS GIS 
#3331: ctypes: ValueError: invalid literal for int() with base 8:
'08420217248550443400745280086994171'
--+
  Reporter:  neteler  |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.2.2
 Component:  Python   |Version:  unspecified
Resolution:   |   Keywords:  ctypes, python
   CPU:  Unspecified  |   Platform:  Unspecified
--+

Comment (by brunofriedmann):

 We (openSUSE) also see the same error.


 {{{
 [  115s] make[6]: Entering directory
 '/home/abuild/rpmbuild/BUILD/grass-7.2.1/lib/python/ctypes'
 [  115s] test -d OBJ.x86_64-pc-linux-gnu || mkdir -p OBJ.x86_64-pc-linux-
 gnu
 [  115s] GISRC=/home/abuild/rpmbuild/BUILD/grass-7.2.1/dist.x86_64-pc-
 linux-gnu/demolocation/.grassrc72
 GISBASE=/home/abuild/rpmbuild/BUILD/grass-7.2.1/dist.x86_64-pc-linux-gnu
 PATH="/home/abuild/rpmbuild/BUILD/grass-7.2.1/dist.x86_64-pc-linux-
 gnu/bin:/home/abuild/rpmbuild/BUILD/grass-7.2.1/dist.x86_64-pc-linux-
 gnu/bin:/home/abuild/rpmbuild/BUILD/grass-7.2.1/dist.x86_64-pc-linux-
 gnu/scripts:$PATH"
 PYTHONPATH="/home/abuild/rpmbuild/BUILD/grass-7.2.1/dist.x86_64-pc-linux-
 gnu/etc/python:/home/abuild/rpmbuild/BUILD/grass-7.2.1/dist.x86_64-pc-
 linux-gnu/gui/wxpython:$PYTHONPATH"
 LD_LIBRARY_PATH="/home/abuild/rpmbuild/BUILD/grass-7.2.1/dist.x86_64-pc-
 linux-gnu/bin:/home/abuild/rpmbuild/BUILD/grass-7.2.1/dist.x86_64-pc-
 linux-gnu/bin:/home/abuild/rpmbuild/BUILD/grass-7.2.1/dist.x86_64-pc-
 linux-gnu/scripts:/home/abuild/rpmbuild/BUILD/grass-7.2.1/dist.x86_64-pc-
 linux-gnu/lib:/home/abuild/rpmbuild/BUILD/grass-7.2.1/dist.x86_64-pc-
 linux-gnu/lib:" LC_ALL=C ./ctypesgen.py --cpp "gcc -E
 -I/home/abuild/rpmbuild/BUILD/grass-7.2.1/dist.x86_64-pc-linux-gnu/include
 -I/home/abuild/rpmbuild/BUILD/grass-7.2.1/dist.x86_64-pc-linux-gnu/include
 -D__GLIBC_HAVE_LONG_LONG" -lgrass_datetime.7.2.1
 /home/abuild/rpmbuild/BUILD/grass-7.2.1/dist.x86_64-pc-linux-
 gnu/include/grass/datetime.h
 /home/abuild/rpmbuild/BUILD/grass-7.2.1/dist.x86_64-pc-linux-
 gnu/include/grass/defs/datetime.h -o OBJ.x86_64-pc-linux-gnu/date.py
 [  115s] Status: Preprocessing /tmp/tmpSIivMQ.h
 [  115s] Status: gcc -E
 -I/home/abuild/rpmbuild/BUILD/grass-7.2.1/dist.x86_64-pc-linux-gnu/include
 -I/home/abuild/rpmbuild/BUILD/grass-7.2.1/dist.x86_64-pc-linux-gnu/include
 -D__GLIBC_HAVE_LONG_LONG -U __GNUC__ -dD "-Dinline=" "-D__inline__="
 "-D__extension__=" "-D_Bool=uint8_t" "-D__const=const" "-D__asm__(x)="
 "-D__asm(x)=" "-DCTYPESGEN=1" /tmp/tmpSIivMQ.h
 [  115s] Traceback (most recent call last):
 [  115s]   File "./ctypesgen.py", line 139, in 
 [  115s] descriptions = ctypesgencore.parser.parse(options.headers,
 options)
 [  115s]   File
 
"/home/abuild/rpmbuild/BUILD/grass-7.2.1/lib/python/ctypes/ctypesgencore/parser/__init__.py",
 line 22, in parse
 [  115s] parser.parse()
 [  115s]   File
 
"/home/abuild/rpmbuild/BUILD/grass-7.2.1/lib/python/ctypes/ctypesgencore/parser/datacollectingparser.py",
 line 74, in parse
 [  115s] ctypesparser.CtypesParser.parse(self, fname, None)
 [  115s]   File
 
"/home/abuild/rpmbuild/BUILD/grass-7.2.1/lib/python/ctypes/ctypesgencore/parser/cparser.py",
 line 120, in parse
 [  115s] self.preprocessor_parser.parse(filename)
 [  115s]   File
 
"/home/abuild/rpmbuild/BUILD/grass-7.2.1/lib/python/ctypes/ctypesgencore/parser/preprocessor.py",
 line 218, in parse
 [  115s] token = self.lexer.token()
 [  115s]   File
 
"/home/abuild/rpmbuild/BUILD/grass-7.2.1/lib/python/ctypes/ctypesgencore/parser/preprocessor.py",
 line 63, in token
 [  115s] result = lex.Lexer.token(self)
 [  115s]   File
 
"/home/abuild/rpmbuild/BUILD/grass-7.2.1/lib/python/ctypes/ctypesgencore/parser/lex.py",
 line 355, in token
 [  115s] newtok = func(tok)
 [  115s]   File
 
"/home/abuild/rpmbuild/BUILD/grass-7.2.1/lib/python/ctypes/ctypesgencore/parser/pplexer.py",
 line 262, in t_ANY_int
 [  115s] g1 = str(long(g1, 8))
 [  115s] ValueError: invalid literal for int() with base 8:
 '08420217248550443400745280086994171'
 [  115s] make[6]: *** [Makefile:102: OBJ.x86_64-pc-linux-gnu/date.py]
 Error 1
 [  115s] make[6]: Leaving directory
 '/home/abuild/rpmbuild/BUILD/grass-7.2.1/lib/python/ctypes'
 [  115s] make[5]: *** [Makefile:81: default] Error 2
 }}}

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS-SVN] r70821 - grass/trunk/include/Make

2017-06-05 Thread Markus Neteler 
Hi Māris,

On Wed, May 31, 2017 at 5:25 PM, Maris Nartiss  wrote:
> Hello Markus,
> no idea, as it runs just fine on my system and I do not see any easy
> to spot problem with test.c code. You should run it under valgrind /
> gdb or just send me the core file.
> Ah, yes, while at it, include also
> /home/mundialis/software/grass72_svn/dist.x86_64-pc-linux-gnu/demolocation/.grassrc72
>
> Setting all locale stuff to C should prevent failures when translated
> strings are used or comma is the decimal separator thus it *should* be
> harmless.

indeed it is.
I got into a trap with a gcc compiler flag which collided in an
"interesting" way after having virtualised my workhorse machine at the
same time when I backported the change.

Sorry for the noise, all good.

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

Re: [GRASS-dev] [GRASS GIS] #3243: v.in.pdal build error: some PDAL 1.4.0 includes are not where the module expects them

2017-06-05 Thread GRASS GIS 
#3243: v.in.pdal build error: some PDAL 1.4.0 includes are not where the module
expects them
---+--
  Reporter:  msieczka  |  Owner:  ptschrum
  Type:  defect| Status:  assigned
  Priority:  normal|  Milestone:  7.2.2
 Component:  Vector|Version:  7.2.0
Resolution:|   Keywords:
   CPU:  All   |   Platform:  All
---+--
Changes (by ptschrum):

 * status:  new => assigned
 * owner:  grass-dev@… => ptschrum


Comment:

 I (ptschrum) assigned this ticket to myself.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2732: Read lidar data as vector points using PDAL

2017-06-05 Thread GRASS GIS 
#2732: Read lidar data as vector points using PDAL
-+-
  Reporter:  wenzeslaus  |  Owner:  ptschrum
  Type:  | Status:  assigned
  enhancement|
  Priority:  major   |  Milestone:  7.4.0
 Component:  Vector  |Version:  svn-trunk
Resolution:  |   Keywords:  lidar, las, laz, v.in.lidar,
   CPU:  |  v.in.pointcloud, v.in.pdal
  Unspecified|   Platform:  Unspecified
-+-
Changes (by ptschrum):

 * owner:  wenzeslaus => ptschrum
 * status:  new => assigned


Comment:

 I (ptschrum) am working on this as a GSoC project, 2017.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #3356: v.to.db: incorrect area calculations in lat-long location

2017-06-05 Thread GRASS GIS 
#3356: v.to.db: incorrect area calculations in lat-long location
--+---
  Reporter:  mlennert |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.4.0
 Component:  Vector   |Version:  svn-trunk
Resolution:   |   Keywords:  v.to.db area lat-long
   CPU:  Unspecified  |   Platform:  Unspecified
--+---

Comment (by mlennert):

 Replying to [comment:5 annakrat]:
 > I fixed the rendering issue in r71163 and r71164.

 Yes, works great now, thanks !

 > But the area computation problem must be somewhere in
 [https://grass.osgeo.org/programming7
 >/area__poly1_8c.html#af6f1f53bacc34249be98006c95369695
 G_ellipsoid_polygon_area], probably related
 > to very small numbers, but I couldn't pinpoint the problem. There is
 something specific about this
 > polygon, when I draw a similar one, it gives more reasonable results.

 Yes:


 {{{
 v.in.ogr training_single.shp out=poly
 v.to.db -p poly op=area
 Reading areas...
  100%
 cat|area
 1|38.2256243922775
 g.region vect=poly
 v.in.region out=test
 v.to.db -p test op=area
 Reading areas...
  100%
 cat|area
 1|0.155378405506674
 }}}

 Another interesting test:


 {{{
 v.generalize poly method=douglas out=poly_gen thresh=0.1 --o
 v.to.db -p poly_gen op=area --q
 1|38.2255972503724
 v.generalize poly method=douglas out=poly_gen thresh=0.0001 --o
 v.to.db -p poly_gen op=area --q
 1|2.27719829466825
 v.generalize poly method=douglas out=poly_gen thresh=0.0002
 v.to.db -p poly_gen op=area --q
 1|0.0634717598906464
 v.generalize poly method=douglas out=poly_gen thresh=0.0003 --o
 v.to.db -p poly_gen op=area --q
 1|0.134256325986436
 v.generalize poly method=douglas out=poly_gen thresh=0.001 --o
 v.to.db -p poly_gen op=area --q
 1|0.000968180796418213
 }}}

 IOW: just very slight generalization gives much better area calculations,
 but very small differences in generalization can lead to quite erratic
 area calculation results.

 So, yes, this definitely seems to be a precision issue, but at this stage
 I can't really see where in the source code, and don't have much time to
 delve into it in greater detail. Maybe MarkusM has an idea ?

--
Ticket URL: 
GRASS GIS 

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