Re: [GRASS-dev] [GRASS GIS] #2369: Include map elements into GRASS workspaces

[GRASS GIS]

#2369: Include map elements into GRASS workspaces
--+--
  Reporter:  mastho   |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:  7.3.0
 Component:  wxGUI|Version:  unspecified
Resolution:   |   Keywords:  workspace, cartography, gsoc2016
   CPU:  Unspecified  |   Platform:  Unspecified
--+--

Comment (by annakrat):

 In [changeset:"68645" 68645]:
 {{{
 #!CommitTicketReference repository="" revision="68645"
 wxGUI: write overlays (legend, barscale, arrow) into workspace, see #2369,
 author Adam Laza
 }}}

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2369: Include map elements into GRASS workspaces

[GRASS GIS]

#2369: Include map elements into GRASS workspaces
--+--
  Reporter:  mastho   |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:  7.3.0
 Component:  wxGUI|Version:  unspecified
Resolution:   |   Keywords:  workspace, cartography, gsoc2016
   CPU:  Unspecified  |   Platform:  Unspecified
--+--
Changes (by lazaa):

 * Attachment "workspace3.diff" added.

 save all map element position include including legend

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] cProfile makes TypeError

[Glynn Clements]

Eva Stopková wrote:

> I would like to ask for advice. I am trying to make a visualization of the
> script process using cProfile according to [1], but it gives me an error:
> 
> File
> "~/grass7/dist.x86_64-pc-linux-gnu/etc/python/grass/lib/ctypes_loader.py",
> line 187, in _create_ld_so_cache
> for path in glob.glob("%s/*.s[ol]*" % dir):
> TypeError: __init__() takes exactly 4 arguments (2 given)

This seems to suggest that it's picking up some other "glob" module,
rather than the one in the standard library.

Does running the script without using cProfile work?

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

Re: [GRASS-dev] NULL file compression by default

[Glynn Clements]

Markus Neteler wrote:

> according to the current documentation, the NULL files are still
> uncompressed [1].
> Is there an important reason to not switch it on by default?

The fact that no "release" version supports reading compressed null
files. So anyone not explicitly disabling compression will be creating
maps which cannot be read by anyone using e.g. 7.0.4.

First, put out a release version which supports reading compressed
null files. Once it's been out long enough for adoption to be
widespread, you can consider compressing null files by default. Until
then, compression needs to be a conscious decision.

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

Re: [GRASS-dev] [GRASS GIS] #3056: ]PATCH] r.patch: disable creation of support files

[GRASS GIS]

#3056: ]PATCH] r.patch: disable creation of support files
--+---
  Reporter:  mlennert |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:  7.2.0
 Component:  Raster   |Version:  unspecified
Resolution:   |   Keywords:  r.patch categories colors
   CPU:  Unspecified  |   Platform:  Unspecified
--+---

Comment (by neteler):

 A wish - the current manual change proposal (maybe remove "very"):

  "This can be quite time consuming for certain maps, especially if there
 are ~~very~~ many different category values across the patched maps. The
 -s flag allows to disable support file creation."

 should also mention the side effects when using the proposed flag. Will
 other modules still accept such maps? Anything specific which will no
 longer work and how to work-around?

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] hacking configure for gettext

[Michael Barton]

Thanks Glynn. 

I'll try this out and see what happens. I've also tried to point the generic 
--with-includes= and
--with-libs= switches to my gettext location but it has made no difference. 

It looks like it is bundled dependencies that cause Mac OSX SIP to block GRASS 
launching. Trying to run the install_tool on every possible binary file that 
might link with one of these seems unrealistic. The simplest solution seems to 
be to build all dependencies outside of the Mac system folders. That is a pain 
but doable...if GRASS will recognize these dependencies in their non-system 
locations. 

Michael


C. Michael Barton
Director, Center for Social Dynamics & Complexity 
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC),  480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu



> On Jun 8, 2016, at 12:41 PM, Glynn Clements  wrote:
> 
> 
> Michael Barton wrote:
> 
>> I would like GRASS to use gettext that is installed in a location
>> NOT in the standard /usr/local... I have no problem building gettext
>> in such a location but I am having problems telling GRASS where to
>> find it.
>> 
>> The configure switch to enable gettext is --with-nls. I've tried
>> adding additional arguments
>> 
>> --with-nls-includes="/Users/cmbarton/grass_source/gettext/gettext_dist/include"
>> --with-nls-libs="/Users/cmbarton/grass_source/gettext/gettext_dist/lib"
>> 
>> to tell GRASS where to find gettext but these do not seem to do the
>> trick.
>> 
>> Can someone familiar with the build system suggest how to specify
>> where to find gettext or now to modify configure so that GRASS can
>> find gettext in this other location?
> 
> Currently, gettext is treated as a system function, i.e. there's no
> way to configure search paths beyond the generic --with-includes= and
> --with-libs= switches. It's checked initially without additional
> libraries (AC_CHECK_FUNC), and if that fails with -lintl
> (AC_CHECK_LIB).
> 
> To treat it as an external library function, try the attached patch.
> 
> Note that you'll need to add $(INTLINC) to ... something. probably
> Either INC (in Grass.make) or NLS_CFLAGS (in Compile.make). Adding it
> to individual Makefiles isn't feasible because  is included
> from , which is included by practically everything.
> 
> -- 
> Glynn Clements 
> 
> Index: configure.in
> ===
> --- configure.in  (revision 68639)
> +++ configure.in  (working copy)
> @@ -321,6 +321,9 @@
> LOC_ARG_WITH_INC(readline, Readline)
> LOC_ARG_WITH_LIB(readline, Readline)
> 
> +LOC_ARG_WITH_INC(nls, NLS)
> +LOC_ARG_WITH_LIB(nls, NLS)
> +
> LOC_ARG_WITH_INC(tiff, TIFF)
> LOC_ARG_WITH_LIB(tiff, TIFF)
> 
> @@ -1652,20 +1655,28 @@
> 
> LOC_CHECK_USE(nls,NLS,USE_NLS)
> 
> +if test -n "${USE_NLS}" ; then
> +AC_DEFINE(USE_NLS)
> +
> +INTLINC=
> +
> +LOC_CHECK_INC_PATH(nls,NLS,INTLINC)
> +
> +LOC_CHECK_INCLUDES(libintl.h,NSL,$INTLINC)
> +
> INTLLIB=
> HAVE_NLS=
> 
> -if test -n "${USE_NLS}" ; then
> -AC_DEFINE(USE_NLS)
> +LOC_CHECK_LIB_PATH(nsl,NLS,INTLLIB)
> 
> -AC_CHECK_FUNC(gettext, INTLLIB=, [
> -AC_CHECK_LIB(intl, gettext, INTLLIB=-lintl, [
> -AC_MSG_ERROR([*** Unable to locate gettext() function.])
> -])])
> +LOC_CHECK_FUNC(gettext,NLS,INTLLIB,[
> +LOC_CHECK_LIBS(intl,gettext,NLS,$INTLLIB,INTLLIB,,,)
> +])
> 
> HAVE_NLS=1
> fi
> 
> +AC_SUBST(INTLINC)
> AC_SUBST(INTLLIB)
> AC_SUBST(HAVE_NLS)
> 

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

Re: [GRASS-dev] hacking configure for gettext

[Glynn Clements]

Michael Barton wrote:

> I would like GRASS to use gettext that is installed in a location
> NOT in the standard /usr/local... I have no problem building gettext
> in such a location but I am having problems telling GRASS where to
> find it.
> 
> The configure switch to enable gettext is --with-nls. I've tried
> adding additional arguments
> 
> --with-nls-includes="/Users/cmbarton/grass_source/gettext/gettext_dist/include"
> --with-nls-libs="/Users/cmbarton/grass_source/gettext/gettext_dist/lib"
> 
> to tell GRASS where to find gettext but these do not seem to do the
> trick.
> 
> Can someone familiar with the build system suggest how to specify
> where to find gettext or now to modify configure so that GRASS can
> find gettext in this other location?

Currently, gettext is treated as a system function, i.e. there's no
way to configure search paths beyond the generic --with-includes= and
--with-libs= switches. It's checked initially without additional
libraries (AC_CHECK_FUNC), and if that fails with -lintl
(AC_CHECK_LIB).

To treat it as an external library function, try the attached patch.

Note that you'll need to add $(INTLINC) to ... something. probably
Either INC (in Grass.make) or NLS_CFLAGS (in Compile.make). Adding it
to individual Makefiles isn't feasible because  is included
from , which is included by practically everything.

-- 
Glynn Clements 

Index: configure.in
===
--- configure.in(revision 68639)
+++ configure.in(working copy)
@@ -321,6 +321,9 @@
 LOC_ARG_WITH_INC(readline, Readline)
 LOC_ARG_WITH_LIB(readline, Readline)
 
+LOC_ARG_WITH_INC(nls, NLS)
+LOC_ARG_WITH_LIB(nls, NLS)
+
 LOC_ARG_WITH_INC(tiff, TIFF)
 LOC_ARG_WITH_LIB(tiff, TIFF)
 
@@ -1652,20 +1655,28 @@
 
 LOC_CHECK_USE(nls,NLS,USE_NLS)
 
+if test -n "${USE_NLS}" ; then
+AC_DEFINE(USE_NLS)
+
+INTLINC=
+
+LOC_CHECK_INC_PATH(nls,NLS,INTLINC)
+
+LOC_CHECK_INCLUDES(libintl.h,NSL,$INTLINC)
+
 INTLLIB=
 HAVE_NLS=
 
-if test -n "${USE_NLS}" ; then
-AC_DEFINE(USE_NLS)
+LOC_CHECK_LIB_PATH(nsl,NLS,INTLLIB)
 
-AC_CHECK_FUNC(gettext, INTLLIB=, [
-AC_CHECK_LIB(intl, gettext, INTLLIB=-lintl, [
-AC_MSG_ERROR([*** Unable to locate gettext() function.])
-])])
+LOC_CHECK_FUNC(gettext,NLS,INTLLIB,[
+LOC_CHECK_LIBS(intl,gettext,NLS,$INTLLIB,INTLLIB,,,)
+])
 
 HAVE_NLS=1
 fi
 
+AC_SUBST(INTLINC)
 AC_SUBST(INTLLIB)
 AC_SUBST(HAVE_NLS)
 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2369: Include map elements into GRASS workspaces

[GRASS GIS]

#2369: Include map elements into GRASS workspaces
--+--
  Reporter:  mastho   |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:  7.3.0
 Component:  wxGUI|Version:  unspecified
Resolution:   |   Keywords:  workspace, cartography, gsoc2016
   CPU:  Unspecified  |   Platform:  Unspecified
--+--
Changes (by lazaa):

 * Attachment "workspace2.diff" added.

 updated patch with elements position

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] GSoC 2016 - PyQt GRASS - Report 2

[Anna Petrášová]

On Wed, Jun 8, 2016 at 3:30 AM, Blumentrath, Stefan
 wrote:
>> Side question: do the parser rules include flags ? I thought they were only 
>> available for options.
>
> Actually, I have no idea. I just checked the add-ons I wrote, and saw that I 
> only used them for options. I was not aware of this limitation...
> Thanks for pointing that out...

Check the manual:

https://grass.osgeo.org/grass72/manuals/g.parser.html

It's implemented and I used it couple of times successfully.

Anna

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

Re: [GRASS-dev] [GRASS GIS] #3056: ]PATCH] r.patch: disable creation of support files

[GRASS GIS]

#3056: ]PATCH] r.patch: disable creation of support files
--+---
  Reporter:  mlennert |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:  7.2.0
 Component:  Raster   |Version:  unspecified
Resolution:   |   Keywords:  r.patch categories colors
   CPU:  Unspecified  |   Platform:  Unspecified
--+---
Changes (by martinl):

 * milestone:  7.0.5 => 7.2.0


--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #3056: ]PATCH] r.patch: disable creation of support files

[GRASS GIS]

#3056: ]PATCH] r.patch: disable creation of support files
--+---
  Reporter:  mlennert |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:  7.0.5
 Component:  Raster   |Version:  unspecified
Resolution:   |   Keywords:  r.patch categories colors
   CPU:  Unspecified  |   Platform:  Unspecified
--+---
Changes (by mlennert):

 * Attachment "r.patch_nosupportfiles.diff" added.


--
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] #3056: ]PATCH] r.patch: disable creation of support files

[GRASS GIS]

#3056: ]PATCH] r.patch: disable creation of support files
---+-
 Reporter:  mlennert   |  Owner:  grass-dev@…
 Type:  enhancement| Status:  new
 Priority:  normal |  Milestone:  7.0.5
Component:  Raster |Version:  unspecified
 Keywords:  r.patch categories colors  |CPU:  Unspecified
 Platform:  Unspecified|
---+-
 r.patch can be very slow when patching a series of files with many
 different category values. The slow part is the creation of the support
 files. In some cases these support files are not necessary and so it would
 be preferable to disable the creation of the support files. The attached
 patch proposes to add a flag ('-s') to disable support files.

 Any objections to me applying this patch ?

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] GSoC 2016 - PyQt GRASS - Report 2

[Ondřej Pešek]

Hi,

it sounds good, thank you for opening new possibilities. To be honest, I
didn't know about the g.parser rules.

Now I'm just looking on that. It looks nice. In some latest version, I will
try to implement it. Especially the mutually exclusive ones, it should be
nice.

Thanks

2016-06-08 9:30 GMT+02:00 Blumentrath, Stefan :

> > Side question: do the parser rules include flags ? I thought they were
> only available for options.
>
> Actually, I have no idea. I just checked the add-ons I wrote, and saw that
> I only used them for options. I was not aware of this limitation...
> Thanks for pointing that out...
>
> Cheers
> Stefan
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSoC 2016 - PyQt GRASS - Report 2

[Blumentrath, Stefan]

> Side question: do the parser rules include flags ? I thought they were only 
> available for options.

Actually, I have no idea. I just checked the add-ons I wrote, and saw that I 
only used them for options. I was not aware of this limitation...
Thanks for pointing that out...

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

Re: [GRASS-dev] GSoC 2016 - PyQt GRASS - Report 2

[Moritz Lennert]

On 08/06/16 08:57, Blumentrath, Stefan wrote:

Hei,

And thanks for your work on the PyQT-GSoC project!

When it comes to possible GUI improvements, I am wondering if it would
be feasible to take e.g. parser rules into account by means of either

a)generating widgets depending on parser rules (if e.g. two flags are
mutually exclusive, use radio button instead of two tick-boxes)


Side question: do the parser rules include flags ? I thought they were 
only available for options.


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

Re: [GRASS-dev] GSoC 2016 - PyQt GRASS - Report 2

[Blumentrath, Stefan]

Hei,

And thanks for your work on the PyQT-GSoC project!

When it comes to possible GUI improvements, I am wondering if it would be 
feasible to take e.g. parser rules into account by means of either

a)  generating widgets depending on parser rules (if e.g. two flags are 
mutually exclusive, use radio button instead of two tick-boxes)

b)  making the GUI “interactive” (e.g. a flag and an option are mutually 
exclusive, grey out the option when the flag is set, and the other way around)

If it in principle would be possible to make the GUI more dynamic that would be 
nice. Here I am thinking of e.g. to be able to generate lists for selections or 
default values, from for example a python script that is run before the GUI 
opens... A use-case would be the i.ortho.* modules (which still have not been 
ported to G7), where for example the values stored in a camera file (which is a 
simple text file) would have to be read into the GUI, so users can edit camera 
definitions, camera exposure parameters ...

Nothing essential, but it might open some new possibilities...

Kind regards,
Stefan

From: grass-dev [mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of Ondrej 
Pešek
Sent: 5. juni 2016 10:22
To: Vaclav Petras 
Cc: GRASS developers list 
Subject: Re: [GRASS-dev] GSoC 2016 - PyQt GRASS - Report 2

Hi,

2016-06-04 20:47 GMT+02:00 Vaclav Petras 
>:

the screenshots looks good. For the code, it might little bit too soon to judge 
it, but just keep in mind the need for design we talked about earlier. For some 
simple help, you can use pylint tool which will demand some code style. Start 
with the file tools/pylintrc.txt in the GRASS source code.


yes, I want to write there also some comments etc. And I'll try the pylint.


When I ran it for v.buffer I see you are using text edit / line edit for float 
even when it is not [multiple]. I think Qt has double spin box which you can 
use. In general, you don't have to fully follow the current look or behavior. 
If you think that something can be done in a better way, do it.

For example, this would be one thing we can reconsider. The shorter description 
(label or description field) shows as the name/label for a field while the 
longer description (description field) shows as a tooltip of the label. One 
improvement could be showing it as a tooltip for the input field as well (or 
perhaps in a completely different way).

I will consider it all. While coding I was experimenting, but everytime I 
considered that the original widget = the best widget. Thanks for tips, I will 
try it your way. And the tooltip version sounds good. Should I put the name and 
type (input=string) upper (where now is description) or on the right side (as 
in current version).

Thanks for tips and have a nice time,
Ondrej


[Image removed by 
sender.]

Bez virů. 
www.avast.com


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

Re: [GRASS-dev] Travis-ci and tests of grass 7

[Rainer M Krug]

Just to make sure that this doesn't get lost again.

Rainer

Rainer M Krug  writes:

> Markus Neteler  writes:
>
>> On Thu, Jun 2, 2016 at 7:59 PM, Rainer M Krug  wrote:
>>> Markus Neteler  writes:
>> ...
 Anything to be done there? Was it integrated? Or stuck at

 https://trac.osgeo.org/grass/ticket/2733
>>>
>>> I think it was stuck - but I haven't looked at it since and I have no
>>> idea if it still works. I think there were some changes on travis
>>> concerning OS X?
>>>
>>> If you are interested, I could look at it again.
>>
>> Interested yes, but I cannot help with the Travis CI things.
>> Just don't like efforts potentially lost :)
>
> That's why I didn't continue looking into this - no response.
>
> OK. I checked the travis testing, updated the OS X config options to use the
> same as Linux, usage of gdal 1... as gdal 2.0 is not compiling at the
> moment in OS X, and the tests passed.
>
> Pull request is at:
>
> https://github.com/GRASS-GIS/grass-ci/pull/1
>
> travis tests at
>
> https://travis-ci.org/rkrug/grass-ci
>
> Who is actually maintaining the travis integration?
>
> One question: what is the relationship between the grass-ci on github
> and the svn repo? Are they kept in sync?
>
> Rainer
>
>
>
>>
>> Markus
>> ___
>> grass-dev mailing list
>> grass-dev@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-dev

-- 
Rainer M. Krug
email: Rainerkrugsde
PGP: 0x0F52F982


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