Re: [GRASS-dev] [GRASS GIS] #3392: t.register: encoding error

[GRASS GIS]

#3392: t.register: encoding error
--+-
  Reporter:  mlennert |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.2.2
 Component:  Temporal |Version:  svn-trunk
Resolution:   |   Keywords:  t.register encoding
   CPU:  Unspecified  |   Platform:  Unspecified
--+-
Changes (by zarch):

 * Attachment "temporal_encode.patch" added.

 Transform every variable to bytes

--
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] #3392: t.register: encoding error

[GRASS GIS]

#3392: t.register: encoding error
--+-
  Reporter:  mlennert |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.2.2
 Component:  Temporal |Version:  svn-trunk
Resolution:   |   Keywords:  t.register encoding
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by zarch):

 Hi Anna,

 Replying to [comment:12 annakrat]:
 > The problem mostly comes from calling gisenv function from script.utils
 which returns unicode. This was done some time ago to make the library
 Python3 compatible. So we eventually need to move towards unicode, but to
 have a quick fix for the release, we can keep the temporal library using
 bytestrings.


 I didn't have time to test your solution yet.

 Actually for me it is still not clear where should we use `unicode` and
 where `bytes`.
 Do you have some general guidelines?

 In the changes that I did, I transformed everything in bytes, and now the
 tests that I added to reproduce the ticket's error are passing, so the
 ticket is "theoretically" fixed. However this solution can only work with
 python2, because in the temporal library now I'm summing bytes with
 unicode, that can work only with python2 that does not distinguish between
 them.
 In python3 this operation raise an error. In general due to bytes
 limitation in python3 (mainly there is not format) perhaps we should use
 just unicode within the python code...

 Therefore I was thinking to replace all the `grass.script.utils` `encode`
 function that I added in `grass/lib/temporal` with `decode` to ensure that
 everything is unicode. And then replace the `print` function with
 `pygrass.messages.Messager` to eventually translate all the python unicode
 back to bytes just before printing them to system terminal.

 So I'm not sure when is the right moment to transform unicode to bytes.

--
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] #3400: set up mirror server for Windows Addons

[GRASS GIS]

#3400: set up mirror server for Windows Addons
--+-
  Reporter:  martinl  |  Owner:  grass-dev@…
  Type:  task | Status:  new
  Priority:  normal   |  Milestone:
 Component:  Packaging|Version:  unspecified
Resolution:   |   Keywords:
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by neteler):

 Replying to [ticket:3400 martinl]:
 > Currently building and publishing servers for Windows (daily + addons)
 binaries are located within one network which can cause problems (see
 #3399). Would be nice to set up mirrors.

 To copy the binaries, grass.osgeo.org comes to mind. Or did you think of a
 second building server?

--
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] #3392: t.register: encoding error

[GRASS GIS]

#3392: t.register: encoding error
--+-
  Reporter:  mlennert |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.2.2
 Component:  Temporal |Version:  svn-trunk
Resolution:   |   Keywords:  t.register encoding
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by annakrat):

 The problem mostly comes from calling gisenv function from script.utils
 which returns unicode. This was done some time ago to make the library
 Python3 compatible. So we eventually need to move towards unicode, but to
 have a quick fix for the release, we can keep the temporal library using
 bytestrings. This is a possible solution:


 {{{
 Index: lib/python/temporal/core.py
 ===
 --- lib/python/temporal/core.py (revision 71395)
 +++ lib/python/temporal/core.py (working copy)
 @@ -542,9 +542,9 @@
  grassenv = gscript.gisenv()

  # Set the global variable for faster access
 -current_mapset = grassenv["MAPSET"]
 -current_location = grassenv["LOCATION_NAME"]
 -current_gisdbase = grassenv["GISDBASE"]
 +current_mapset = gscript.encode(grassenv["MAPSET"])
 +current_location = gscript.encode(grassenv["LOCATION_NAME"])
 +current_gisdbase = gscript.encode(grassenv["GISDBASE"])

  # Check environment variable GRASS_TGIS_RAISE_ON_ERROR
  if os.getenv("GRASS_TGIS_RAISE_ON_ERROR") == "True" or \
 @@ -1107,6 +1107,7 @@
  detect_types=self.dbmi.PARSE_DECLTYPES |
 self.dbmi.PARSE_COLNAMES)
  self.connection.row_factory = self.dbmi.Row
  self.connection.isolation_level = None
 +self.connection.text_factory = str
  self.cursor = self.connection.cursor()
  self.cursor.execute("PRAGMA synchronous = OFF")
  self.cursor.execute("PRAGMA journal_mode = MEMORY")

 }}}

 plus all gisenv calls in temporal modules need to be encoded to not let
 any unicode into the library. I would appreciate if somebody could test it
 more thoroughly. This would be a temporary solution, we need to move to
 unicode eventually, but I think that would require more time to fix and
 more significant changes.

 Also, this works only for sqlite3 backend, I haven't looked at postgres...

--
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] [SoC] GSoC 2017 Weekly Report 11 - SOS tools in GRASS GIS

[Ondřej Pešek]

Hi everyone!

Here is the eleventh report of my GSoC project - SOS tools in GRASS GIS.
You can see my project at wiki at [1]

What did you get done this week?

v.in.sos
* finally working the desired way even with more layers
   main commits: [2] [3]
 * uses yet existing columns for timestamps instead of creating new ones
   main commits: [4]
t.vect.in.sos
* finally working with layers-based vectors
   main commits: [5] [6]
t.rast.in.sos
   main commits: [7]

What do you plan on doing next week?

 * Work on documentation
 * t.vect.to.rast
 * still have some ideas how to improve yet existing modules (for example
option for granularity)

Are you blocked on anything?

No

Regards,
Ondrej

[1] https://trac.osgeo.org/grass/wiki/GSoC/2017/SOSInGRASS
[2]
https://github.com/pesekon2/GRASS-GIS-SOS-tools/commit/6ac65b2ba2b42d63973652f6d4cdd155313f3b11
[3]
https://github.com/pesekon2/GRASS-GIS-SOS-tools/commit/bc98deb0663e9d15f993ca0837014f197c718c0d
[4]
https://github.com/pesekon2/GRASS-GIS-SOS-tools/commit/12a415ad12098ca876c431e8c2457148c477f601
[5]
https://github.com/pesekon2/GRASS-GIS-SOS-tools/commit/4a435453b6281736719653e0c12a1576c9a906e1
[6]
https://github.com/pesekon2/GRASS-GIS-SOS-tools/commit/dc8d7e0724ff07d040755ee10ae9fc153391cd57
[7]
https://github.com/pesekon2/GRASS-GIS-SOS-tools/commit/c985f8e8115a6fa9ded608d4697a1dbba44110f2
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev