date:20170615

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

2017-06-15 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:  svn-releasebranch72
Resolution:   |   Keywords:  ctypes, python
   CPU:  Unspecified  |   Platform:  Unspecified
--+-
Changes (by neteler):

 * Attachment "gcc7_flags_with_c99.txt" added.

 Output of 'gcc -std=c99 -E -dM -x c /dev/null | sort'

--
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] #3331: ctypes: ValueError: invalid literal for int() with base 8: '08420217248550443400745280086994171'

2017-06-15 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:  svn-releasebranch72
Resolution:   |   Keywords:  ctypes, python
   CPU:  Unspecified  |   Platform:  Unspecified
--+-
Changes (by neteler):

 * Attachment "gcc7_flags_with_c89.txt" added.

 Output of 'gcc -std=c89 -E -dM -x c /dev/null | sort'

--
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] #3331: ctypes: ValueError: invalid literal for int() with base 8: '08420217248550443400745280086994171'

2017-06-15 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:  svn-releasebranch72
Resolution:   |   Keywords:  ctypes, python
   CPU:  Unspecified  |   Platform:  Unspecified
--+-
Changes (by neteler):

 * Attachment "gcc7_flags_standard.txt" added.

 Output of 'gcc -E -dM -x c /dev/null | sort'

--
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] #3331: ctypes: ValueError: invalid literal for int() with base 8: '08420217248550443400745280086994171'

2017-06-15 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:  svn-releasebranch72
Resolution:   |   Keywords:  ctypes, python
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by neteler):

 Replying to [comment:17 glynn]:
 > Looking through pplexer.py shows that it specifically tries to handle
 literals with an "L" or "l" suffix, but there's nothing there for an
 "F64x" suffix.

 We were wondering here about the L suffix(es) but didn't realize that a
 "F64x" suffix could be an issue.

 ...

 > You can dump out gcc's built-in macro definitions with
 > {{{
 > gcc -E -dM -x c /dev/null | sort
 > }}}
 >
 > Does adding e.g. -std=c89 or -std=c99 eliminate the F64x literals?

 Apparently not, here the diffences (full outputs attached to the ticket):

 {{{
 # see attachments:
 [root@f1e5cbaaed18 /]# gcc -E -dM -x c /dev/null | sort >
 gcc7_flags_standard.txt
 [root@f1e5cbaaed18 /]# gcc -std=c89 -E -dM -x c /dev/null | sort >
 gcc7_flags_with_c89.txt
 [root@f1e5cbaaed18 /]# gcc -std=c99 -E -dM -x c /dev/null | sort >
 gcc7_flags_with_c99.txt

 # differences:
 [root@f1e5cbaaed18 /]# diff -u gcc7_flags_standard.txt
 gcc7_flags_with_c89.txt
 --- gcc7_flags_standard.txt 2017-06-16 05:35:10.481505202 +
 +++ gcc7_flags_with_c89.txt 2017-06-16 05:35:37.813790118 +
 @@ -161,10 +161,10 @@
  #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8 1
  #define __GCC_IEC_559 2
  #define __GCC_IEC_559_COMPLEX 2
 +#define __GNUC_GNU_INLINE__ 1
  #define __GNUC_MINOR__ 1
  #define __GNUC_PATCHLEVEL__ 1
  #define __GNUC_RH_RELEASE__ 2
 -#define __GNUC_STDC_INLINE__ 1
  #define __GNUC__ 7
  #define __GXX_ABI_VERSION 1011
  #define __INT16_C(c) c
 @@ -278,10 +278,8 @@
  #define __STDC_IEC_559__ 1
  #define __STDC_ISO_10646__ 201605L
  #define __STDC_NO_THREADS__ 1
 -#define __STDC_UTF_16__ 1
 -#define __STDC_UTF_32__ 1
 -#define __STDC_VERSION__ 201112L
  #define __STDC__ 1
 +#define __STRICT_ANSI__ 1
  #define __UINT16_C(c) c
  #define __UINT16_MAX__ 0x
  #define __UINT16_TYPE__ short unsigned int
 @@ -339,5 +337,3 @@
  #define __unix__ 1
  #define __x86_64 1
  #define __x86_64__ 1
 -#define linux 1
 -#define unix 1

 [root@f1e5cbaaed18 /]# diff -u gcc7_flags_standard.txt
 gcc7_flags_with_c99.txt
 --- gcc7_flags_standard.txt 2017-06-16 05:35:10.481505202 +
 +++ gcc7_flags_with_c99.txt 2017-06-16 05:35:49.742914468 +
 @@ -278,10 +278,9 @@
  #define __STDC_IEC_559__ 1
  #define __STDC_ISO_10646__ 201605L
  #define __STDC_NO_THREADS__ 1
 -#define __STDC_UTF_16__ 1
 -#define __STDC_UTF_32__ 1
 -#define __STDC_VERSION__ 201112L
 +#define __STDC_VERSION__ 199901L
  #define __STDC__ 1
 +#define __STRICT_ANSI__ 1
  #define __UINT16_C(c) c
  #define __UINT16_MAX__ 0x
  #define __UINT16_TYPE__ short unsigned int
 @@ -339,5 +338,3 @@
  #define __unix__ 1
  #define __x86_64 1
  #define __x86_64__ 1
 -#define linux 1
 -#define unix 1

 [root@f1e5cbaaed18 /]# grep F64x gcc7_flags_*
 gcc7_flags_standard.txt:#define __FLT64X_DENORM_MIN__ 3
 .64519953188247460252840593361941982e-4951F64x
 gcc7_flags_standard.txt:#define __FLT64X_EPSILON__ 1
 .08420217248550443400745280086994171e-19F64x
 gcc7_flags_standard.txt:#define __FLT64X_MAX__
 1.18973149535723176502126385303097021e+4932F64x
 gcc7_flags_standard.txt:#define __FLT64X_MIN__ 3
 .36210314311209350626267781732175260e-4932F64x
 gcc7_flags_with_c89.txt:#define __FLT64X_DENORM_MIN__ 3
 .64519953188247460252840593361941982e-4951F64x
 gcc7_flags_with_c89.txt:#define __FLT64X_EPSILON__ 1
 .08420217248550443400745280086994171e-19F64x
 gcc7_flags_with_c89.txt:#define __FLT64X_MAX__
 1.18973149535723176502126385303097021e+4932F64x
 gcc7_flags_with_c89.txt:#define __FLT64X_MIN__ 3
 .36210314311209350626267781732175260e-4932F64x
 gcc7_flags_with_c99.txt:#define __FLT64X_DENORM_MIN__ 3
 .64519953188247460252840593361941982e-4951F64x
 gcc7_flags_with_c99.txt:#define __FLT64X_EPSILON__ 1
 .08420217248550443400745280086994171e-19F64x
 gcc7_flags_with_c99.txt:#define __FLT64X_MAX__
 1.18973149535723176502126385303097021e+4932F64x
 gcc7_flags_with_c99.txt:#define __FLT64X_MIN__ 3
 .36210314311209350626267781732175260e-4932F64x
 }}}


 > FWIW, F64x appears to derive from ISO/IEC TS 18661-3:2015.

--
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] #3331: ctypes: ValueError: invalid literal for int() with base 8: '08420217248550443400745280086994171'

2017-06-15 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:  svn-releasebranch72
Resolution:   |   Keywords:  ctypes, python
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by neteler):

 Replying to [comment:12 neteler]:
 > In r71180 I have now removed the -dD flag in ctypesgencore/preprocessor
 because it is failing with gcc7 and apparently not causing any harm with
 gcc6.

 Reverted along with r71182 in r71187 since not solving the problem (but
 breaking v.digit)

--
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] #3331: ctypes: ValueError: invalid literal for int() with base 8: '08420217248550443400745280086994171'

2017-06-15 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:  svn-releasebranch72
Resolution:   |   Keywords:  ctypes, python
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by glynn):

 Replying to [comment:7 neteler]:

 > Adding some debug output shows where in the lexer the problem occurs:
 >
 {{{
 [root@f1e5cbaaed18 ctypes]# make | grep 084202
 #define __LDBL_EPSILON__ 1.08420217248550443400745280086994171e-19L
 #define __FLT64X_EPSILON__ 1.08420217248550443400745280086994171e-19F64x

 g1 = str(long(g1, 8))
 ValueError: invalid literal for int() with base 8:
 '08420217248550443400745280086994171'
 }}}

 > As seen above the `__LDBL_EPSILON__` definition is not parsed properly

 It's more likely to be an issue with `__FLT64X_EPSILON__`, as that's a
 recent addition. `__LDBL_EPSILON__` has been defined since forever, and
 hasn't caused problems before.

 Looking through pplexer.py shows that it specifically tries to handle
 literals with an "L" or "l" suffix, but there's nothing there for an
 "F64x" suffix. So the value won't match the regex for a float literal,
 which probably results in it matching "1." as a float literal then trying
 to match the remainder. The part up to the exponent will match an int
 literal, but the leading zero causes it to be parsed as octal, which then
 fails due to the presence of digits 8 and 9.

 You can dump out gcc's built-in macro definitions with
 {{{
 gcc -E -dM -x c /dev/null | sort
 }}}

 Does adding e.g. -std=c89 or -std=c99 eliminate the F64x literals?

 FWIW, F64x appears to derive from ISO/IEC TS 18661-3:2015.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] scientific notation in r.mapcalc ?

2017-06-15 Thread Glynn Clements


Markus Neteler wrote:

> > I just stumbled upon this while running a large model, and noticed that I
> > couldn't easily find an answer:
> >
> > IIUC r.mapcalc does not support scientific notation of floating point
> > numbers (i.e. 2.54e-05 instead of 0.254). Is that correct ?
> >
> > How difficult would it be to implement the support of such notation ?
> 
> We just stumbled over the same issue... would be nice to have.

It works here:

$ r.mapcalc "foo = 2.54e-05"
$ r.info -r foo
min=2.54e-05
max=2.54e-05

$ g.version -gr
version=7.3.svn
date=2016
revision=r70088
build_date=2017-06-16
build_platform=x86_64-pc-linux-gnu
build_off_t_size=8
libgis_revision=70829 
libgis_date="2017-04-04 08:43:02 +0100 (Tue, 04 Apr 2017) "

mapcalc.l specifically recognises exponential notation:

I   [0-9]+

E   [eE][-+]?[0-9]+

%%

{I}"."{I}?{E}?  |
"."{I}{E}?  {
yylval.fval = atof(yytext);
return DOUBLE;
}

atof() is specified as:

   7.20.1.1  The atof function

...

   [#2]  The  atof function converts the initial portion of the
   string pointed to by nptr to double representation.   Except
   for the behavior on error, it is equivalent to

   strtod(nptr, (char **)NULL)

and strtod() as

   7.20.1.3  The strtod, strtof, and strtold functions

...

   [#3] The  expected  form  of  the  subject  sequence  is  an
   optional plus or minus sign, then one of the following:

 -- a   nonempty  sequence  of  decimal  digits  optionally
containing a decimal-point character, then an  optional
exponent part as defined in 6.4.4.2;

I note that any locale-specific varations are supposed to be in
addition to the format used by the "C" locale, so even if LC_NUMERIC
gets set (and it shouldn't), that shouldn't affect it.

Is this issue a wxGUI thing?

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

Re: [GRASS-dev] [GRASS GIS] #3129: implementing GDAL WMTS driver in r.in.wms

2017-06-15 Thread GRASS GIS

#3129: implementing GDAL WMTS driver in r.in.wms
--+
  Reporter:  hellik   |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:  7.4.0
 Component:  Raster   |Version:  svn-trunk
Resolution:   |   Keywords:  WMTS, r.in.wms
   CPU:  All  |   Platform:  All
--+

Comment (by hellik):

 Replying to [ticket:3129 hellik]:
 > as mentioned in ticket #3127, GDAL WMTS driver is not yet implemented in
 r.in.wms.
 >
 > WMTS -- OGC Web Map Tile Service is available since GDAL 2.1
 (http://www.gdal.org/frmt_wmts.html).
 >
 > as more and more web map services uses WMTS, this wuld be a nice
 enhancement for r.in.wms.

 anyone working on this? would be a very nice feature. :-)

--
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] #3331: ctypes: ValueError: invalid literal for int() with base 8: '08420217248550443400745280086994171'

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

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

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

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

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

Re: [GRASS-dev] scientific notation in r.mapcalc ?

Re: [GRASS-dev] [GRASS GIS] #3129: implementing GDAL WMTS driver in r.in.wms

8 matches

Site Navigation

Mail list logo

Footer information