Re: [GRASS-dev] [GRASS GIS] #1941: wxGUI fails with Japanese locale

[GRASS GIS]

#1941: wxGUI fails with Japanese locale
--+-
 Reporter:  venkat|   Owner:  grass-dev@…  
 Type:  defect|  Status:  new  
 Priority:  blocker   |   Milestone:  7.0.0
Component:  wxGUI | Version:  svn-trunk
 Keywords:  wingrass  |Platform:  MSWindows 7  
  Cpu:  x86-32|  
--+-

Comment(by martinl):

 Replying to [comment:18 glynn]:
 > Replying to [comment:17 martinl]:
 >
 > > Usually it's caused by Python installed together with Esri ArcGIS. The
 newest version of ArcGIS 10.2 still comes with Python 2.7.3. It would be
 good to find solution on our side without overwriting system-installed
 Python.
 >
 > 2.7.3 should be fine for GRASS, right? So the solution should be to
 detect that the

 No, the problem still remains. Note that we have this problem only with
 standalone installer not with osgeo4w installer.

 > "system" Python is sufficient and not try to use the bundled Python
 (i.e. don't set PYTHONHOME, set GRASS_PYTHON to point to the system
 version, etc).

 But then we will have problem with other python packages (GRASS
 dependecies) which are installed through osgeo4w environment as `python-
 matplotlib` or `python-numpy`, right? Version of "system" python will be
 most probably different from the python version available in osgeo4w
 environment.

 > AFAICT, the issue is that the system python27.dll (from
 `Windows/System32` or `Windows/SysWOW64`) is being used, but PYTHONHOME
 points to the bundled version of the Python standard library.
 >
 > If you can start a Python shell using the GRASS Python, you can use
 [http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx Process
 Explorer] to view the list of DLLs which are actually being used by that
 process. AFAIK, System32/SysWOW64 take precedence over everything except
 the directory containing the exe, and %PATH% comes last.

 Strangely `C:\Program Files (x86)\GRASS GIS 7.0.svn\extrabin\python.exe`
 launches python 2.7.3 (same as system python from `C:\Python27\ArcGIS
 10.2`)! When launching `C:\osgeo4w\bin\python.exe` I got expected version
 of python, so 2.7.4 (current osgeo4w python version). This partly explains
 the fact that we have this problem only with standalone installer.

 > [http://msdn.microsoft.com/en-
 us/library/windows/desktop/ms682586%28v=vs.85%29.aspx DLL Search Order].

 Right, when I launch `python.exe` which comes with standalone installer it
 points to `C:Windows\SysWOW64\python27.dll`. When I launch `python.exe`
 from `C:\OSGeo4W\bin` it points to the right dll file, ie.
 `C:\OSGeo4W\bin\python27.dll`.

-- 
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] #1941: wxGUI fails with Japanese locale

[GRASS GIS]

#1941: wxGUI fails with Japanese locale
--+-
 Reporter:  venkat|   Owner:  grass-dev@…  
 Type:  defect|  Status:  new  
 Priority:  blocker   |   Milestone:  7.0.0
Component:  wxGUI | Version:  svn-trunk
 Keywords:  wingrass  |Platform:  MSWindows 7  
  Cpu:  x86-32|  
--+-

Comment(by mlennert):

 I think that the Python launcher might be the best solution for this. See
 the experiments with different combinations of Python versions at [1].


 [1] [http://lists.osgeo.org/pipermail/grass-dev/2013-July/065197.html]

-- 
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] #1941: wxGUI fails with Japanese locale

[GRASS GIS]

#1941: wxGUI fails with Japanese locale
--+-
 Reporter:  venkat|   Owner:  grass-dev@…  
 Type:  defect|  Status:  new  
 Priority:  blocker   |   Milestone:  7.0.0
Component:  wxGUI | Version:  svn-trunk
 Keywords:  wingrass  |Platform:  MSWindows 7  
  Cpu:  x86-32|  
--+-

Comment(by martinl):

 Replying to [comment:19 martinl]:
 > > [http://msdn.microsoft.com/en-
 us/library/windows/desktop/ms682586%28v=vs.85%29.aspx DLL Search Order].
 >
 > Right, when I launch `python.exe` which comes with standalone installer
 it points to `C:Windows\SysWOW64\python27.dll`. When I launch `python.exe`
 from `C:\OSGeo4W\bin` it points to the right dll file, ie.
 `C:\OSGeo4W\bin\python27.dll`.

 Ah, OK, it's probably caused by the fact that the standalone installer
 puts `python27.dll` to the different directory (ie. `extralib`) compared
 to `python.exe` (`extrabin`). Directory `extralib` is in the path
 source:grass/trunk/mswindows/env.bat#L17, but it's probably not enough.
 The problem could be solved by moving `python27.dll` to `extrabin`. Then
 we could probably move all DLL files to `extrabin` and get rid of this
 directory. It's comment practice to have DLL files together with EXE files
 in the same directory. I don't know why the standalone installer separates
 them to the two different directories, ie. `extrabin` and `extralib`.

-- 
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] Missing subgroup functionality in GRASS 7 wxGUI's i.group?

[Nikos Alexandris]

Hi list.

Working with version=7.0.svn, revision=57486M here.  It seems the option to 
create a subgroup is missing from:

Imagery > Develop images and groups > Create/edit group [i.group]

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

Re: [GRASS-dev] [GRASS GIS] #1941: wxGUI fails with Japanese locale

[GRASS GIS]

#1941: wxGUI fails with Japanese locale
--+-
 Reporter:  venkat|   Owner:  grass-dev@…  
 Type:  defect|  Status:  new  
 Priority:  blocker   |   Milestone:  7.0.0
Component:  wxGUI | Version:  svn-trunk
 Keywords:  wingrass  |Platform:  MSWindows 7  
  Cpu:  x86-32|  
--+-

Comment(by mlennert):

 Replying to [comment:21 martinl]:
 > Replying to [comment:19 martinl]:
 > > > [http://msdn.microsoft.com/en-
 us/library/windows/desktop/ms682586%28v=vs.85%29.aspx DLL Search Order].
 > >
 > > Right, when I launch `python.exe` which comes with standalone
 installer it points to `C:Windows\SysWOW64\python27.dll`. When I launch
 `python.exe` from `C:\OSGeo4W\bin` it points to the right dll file, ie.
 `C:\OSGeo4W\bin\python27.dll`.
 >
 > Ah, OK, it's probably caused by the fact that the standalone installer
 puts `python27.dll` to the different directory (ie. `extralib`) compared
 to `python.exe` (`extrabin`). Directory `extralib` is in the path
 source:grass/trunk/mswindows/env.bat#L17, but it's probably not enough.
 The problem could be solved by moving `python27.dll` to `extrabin`. Then
 we could probably move all DLL files to `extrabin` and get rid of this
 directory. It's comment practice to have DLL files together with EXE files
 in the same directory. I don't know why the standalone installer separates
 them to the two different directories, ie. `extrabin` and `extralib`.

 Try it, but ISTR that there is also an issue with the Windows registry,
 i.e. that the dlls called depend on registry entries (I think that this
 came up as a problem at least in the case of python scripts called from
 python scripts).

-- 
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] #1941: wxGUI fails with Japanese locale

[GRASS GIS]

#1941: wxGUI fails with Japanese locale
--+-
 Reporter:  venkat|   Owner:  grass-dev@…  
 Type:  defect|  Status:  new  
 Priority:  blocker   |   Milestone:  7.0.0
Component:  wxGUI | Version:  svn-trunk
 Keywords:  wingrass  |Platform:  MSWindows 7  
  Cpu:  x86-32|  
--+-

Comment(by hellik):

 Replying to [comment:21 martinl]:
 >
 > Ah, OK, it's probably caused by the fact that the standalone installer
 puts `python27.dll` to the different directory (ie. `extralib`) compared
 to `python.exe` (`extrabin`). Directory `extralib` is in the path
 source:grass/trunk/mswindows/env.bat#L17, but it's probably not enough.
 The problem could be solved by moving `python27.dll` to `extrabin`. Then
 we could probably move all DLL files to `extrabin` and get rid of this
 directory. It's comment practice to have DLL files together with EXE files
 in the same directory.

 that could be the clue. same directory could work.

 >I don't know why the standalone installer separates them to the two
 different directories, ie. `extrabin` and `extralib`.

 also no idea or memory here on my side. since I'm involved in the
 winGRASS, the separation in `extrabin` and `extralib` was always there.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] Missing subgroup functionality in GRASS 7 wxGUI's i.group?

[Newcomb, Doug]

Confirmed that the option does not work in the gui, but does work on the
command line.  Have you filed a ticket?

Doug


On Wed, Sep 11, 2013 at 5:35 AM, Nikos Alexandris
wrote:

> Hi list.
>
> Working with version=7.0.svn, revision=57486M here.  It seems the option to
> create a subgroup is missing from:
>
> Imagery > Develop images and groups > Create/edit group [i.group]
>
> Best regards, Nikos
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
>



-- 
Doug Newcomb
USFWS
Raleigh, NC
919-856-4520 ext. 14 doug_newc...@fws.gov
-
The opinions I express are my own and are not representative of the
official policy of the U.S.Fish and Wildlife Service or Dept. of the
Interior.   Life is too short for undocumented, proprietary data formats.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Missing subgroup functionality in GRASS 7 wxGUI's i.group?

[Nikos Alexandris]

On Wednesday 11 of September 2013 08:53:24 you wrote:

> Confirmed that the option does not work in the gui, but does work on the
> command line.  Have you filed a ticket?

Not yet.  Thaks for (re-)checking,

Nikos

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

[GRASS-dev] GUI wizards reducing functionality [was: Re: Missing subgroup functionality in GRASS 7 wxGUI's i.group?]

[Moritz Lennert]

On 11/09/13 14:53, Newcomb, Doug wrote:

Confirmed that the option does not work in the gui, but does work on the
command line.  Have you filed a ticket?


This seems like another example of a gui wizard providing less than the 
original module and the gui of the module becoming unaccessible via the 
menus (cf also https://trac.osgeo.org/grass/ticket/2042).


I do think that we should have a more general debate about how to handle 
these issues. Personally, I'm very strongly opposed to this tendency of 
"dumbing-down" the GUI menus. I have nothing against wizards, but I 
think they should be an additional feature, not a replacing features.


Moritz


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

Re: [GRASS-dev] [GRASS GIS] #1778: Typing in g.region without parameters does not open a g.region window

[GRASS GIS]

#1778: Typing in g.region without parameters does not open a g.region window
+---
 Reporter:  pvanbosgeo  |   Owner:  grass-dev@… 
 
 Type:  defect  |  Status:  new 
 
 Priority:  normal  |   Milestone:  7.0.0   
 
Component:  Default | Version:  svn-trunk   
 
 Keywords:  g.region, r.colors, r.mask  |Platform:  Linux   
 
  Cpu:  x86-64  |  
+---

Comment(by martinl):

 Replying to [comment:21 martinl]:

 > the attached patch attachment:force_gui.diff adds '--ui' to the help
 printed by the parser (see example below). I agree that this switch is not
 documented well, even it's not noted in the `g.parser`'s help page.

 any objection to committing 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] [GRASS GIS] #1941: wxGUI fails with Japanese locale

[GRASS GIS]

#1941: wxGUI fails with Japanese locale
--+-
 Reporter:  venkat|   Owner:  grass-dev@…  
 Type:  defect|  Status:  new  
 Priority:  blocker   |   Milestone:  7.0.0
Component:  wxGUI | Version:  svn-trunk
 Keywords:  wingrass  |Platform:  MSWindows 7  
  Cpu:  x86-32|  
--+-

Comment(by glynn):

 Replying to [comment:19 martinl]:
 > > "system" Python is sufficient and not try to use the bundled Python
 (i.e. don't set PYTHONHOME, set GRASS_PYTHON to point to the system
 version, etc).
 >
 > But then we will have problem with other python packages (GRASS
 dependecies) which are installed through osgeo4w environment as `python-
 matplotlib` or `python-numpy`, right? Version of "system" python will be
 most probably different from the python version available in osgeo4w
 environment.

 Add-on packages don't normally care about the minor version, so a package
 built for 2.7 should work with 2.7..

 This doesn't apply to sre_*.py; modules which are part of the base Python
 distribution don't expect to be used with anything other than the exact
 Python version of which they are part.

 > Right, when I launch `python.exe` which comes with standalone installer
 it points to `C:Windows\SysWOW64\python27.dll`. When I launch `python.exe`
 from `C:\OSGeo4W\bin` it points to the right dll file, ie.
 `C:\OSGeo4W\bin\python27.dll`.

 That will be because the OSGeo4W version has its python27.dll in the same
 directory as python.exe. The directory containing the EXE comes first,
 before the system directories; %PATH% comes last.

-- 
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] #1778: Typing in g.region without parameters does not open a g.region window

[GRASS GIS]

#1778: Typing in g.region without parameters does not open a g.region window
+---
 Reporter:  pvanbosgeo  |   Owner:  grass-dev@… 
 
 Type:  defect  |  Status:  new 
 
 Priority:  normal  |   Milestone:  7.0.0   
 
Component:  Default | Version:  svn-trunk   
 
 Keywords:  g.region, r.colors, r.mask  |Platform:  Linux   
 
  Cpu:  x86-64  |  
+---

Comment(by glynn):

 Replying to [comment:25 martinl]:

 > any objection to committing this patch?

 Not really, although I note that we don't list --help, --script or any of
 the --*-description options either.

 I suppose that --script and --*-description aren't of interest to end
 users, and if you're reading the help text, you probably don't need to be
 told about --help (although it would be nice if we could train users to
 use that so that we can remove the argv[1]=="help" check; although "help"
 isn't likely to be particularly common as an option value, I dislike
 having special cases on principle).

-- 
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] #1941: wxGUI fails with Japanese locale --> mixed Python installs on Windows (was: wxGUI fails with Japanese locale)

[GRASS GIS]

#1941: wxGUI fails with Japanese locale --> mixed Python installs on Windows
--+-
 Reporter:  venkat|   Owner:  grass-dev@…  
 Type:  defect|  Status:  new  
 Priority:  blocker   |   Milestone:  7.0.0
Component:  wxGUI | Version:  svn-trunk
 Keywords:  wingrass  |Platform:  MSWindows 7  
  Cpu:  x86-32|  
--+-
Description changed by hamish:

Old description:

> I get following error with the wxGUI while running
> GRASS7-svn when selecting modules form the menu.
> on Windows-7 in Japanese locale.
> I guess it is related to utf-8 encoding.
>
> 
> Traceback (most recent call last):
>   File "C:\Program Files\GRASS GIS
> 7.0.svn\etc\gui\wxpython\lmgr\frame.py", line 737, in
> OnMenuCmd
>
> cmd = self.GetMenuCmd(event)
>   File "C:\Program Files\GRASS GIS
> 7.0.svn\etc\gui\wxpython\lmgr\frame.py", line 722, in
> GetMenuCmd
>
> input = GUI().GetCommandInputMapParamKey(cmdlist[0])
>   File "C:\Program Files\GRASS GIS
> 7.0.svn\etc\gui\wxpython\gui_core\forms.py", line 2301, in
> GetCommandInputMapParamKey
>
> gtask.get_interface_description(cmd).decode(enc).encode('utf
> -8')))
> UnicodeDecodeError
> :
> 'cp932' codec can't decode bytes in position 7074-7075:
> illegal multibyte sequence

New description:

 I get following error with the wxGUI while running
 GRASS7-svn when selecting modules form the menu.
 on Windows-7 in Japanese locale.
 I guess it is related to utf-8 encoding.

 
 {{{
 Traceback (most recent call last):
   File "C:\Program Files\GRASS GIS
 7.0.svn\etc\gui\wxpython\lmgr\frame.py", line 737, in
 OnMenuCmd

 cmd = self.GetMenuCmd(event)
   File "C:\Program Files\GRASS GIS
 7.0.svn\etc\gui\wxpython\lmgr\frame.py", line 722, in
 GetMenuCmd

 input = GUI().GetCommandInputMapParamKey(cmdlist[0])
   File "C:\Program Files\GRASS GIS
 7.0.svn\etc\gui\wxpython\gui_core\forms.py", line 2301, in
 GetCommandInputMapParamKey

 gtask.get_interface_description(cmd).decode(enc).encode('utf
 -8')))
 UnicodeDecodeError
 :
 'cp932' codec can't decode bytes in position 7074-7075:
 illegal multibyte sequence
 }}}

--

-- 
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] #1941: wxGUI fails with Japanese locale --> mixed Python installs on Windows

[GRASS GIS]

#1941: wxGUI fails with Japanese locale --> mixed Python installs on Windows
--+-
 Reporter:  venkat|   Owner:  grass-dev@…  
 Type:  defect|  Status:  new  
 Priority:  blocker   |   Milestone:  7.0.0
Component:  wxGUI | Version:  svn-trunk
 Keywords:  wingrass  |Platform:  MSWindows 7  
  Cpu:  x86-32|  
--+-

Comment(by hamish):

 Replying to [comment:24 glynn]:
 > Add-on packages don't normally care about the minor version, so
 > a package built for 2.7 should work with 2.7..

 As seen in the pdf screenshot, the trouble comes with "import re", which I
 think(??) is a built-in.

 We recently saw the same trouble here with 'import re' -> no MAXREPEAT and
 6.4.3 on a Windows 7 laptop, where there was a slightly older python
 version of 2.7(.2?) installed to C:\Python, which I guessed came with a
 separate OSGeo4W install(?). For us it was a new laptop not doing anything
 else so we could uninstall the non-grass Python from the control panel and
 then all was good.

 Are we prepending to the PYTHONPATH instead of adding the grass paths to
 the end of it? (hopefully the GRASS versions get picked up first then)
 AFAIK env.bat & friends in the stand-alone installer now explicitly set
 GRASS_PYTHON with with the full path to grass's python.exe.


 Hamish

-- 
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] #1778: Typing in g.region without parameters does not open a g.region window

[GRASS GIS]

#1778: Typing in g.region without parameters does not open a g.region window
+---
 Reporter:  pvanbosgeo  |   Owner:  grass-dev@… 
 
 Type:  defect  |  Status:  new 
 
 Priority:  normal  |   Milestone:  7.0.0   
 
Component:  Default | Version:  svn-trunk   
 
 Keywords:  g.region, r.colors, r.mask  |Platform:  Linux   
 
  Cpu:  x86-64  |  
+---

Comment(by hamish):

 No, I don't think --ui should be added to the help page. It should only
 needed in special circumstances (like debugging or having the main GUI
 progmatically force open a dialog), much like --script and --interface-
 description aren't interesting in the main help pages even though
 possible.

 I'm still highly confused about the need for any change since everything
 seemed to be working very smoothly in GRASS 6. For example d.erase if
 called alone would do its job without a GUI, you could add "color=black"
 or whatever extra option on the command line if needed, or use --ui to get
 a GUI module in the rare cases that you wanted one or add '--ui' to the
 menus.xml file to force one if called from there.

 Other modules in G6 that are special cases where no command line arguments
 are needed (although possible) test argc or $# to decide how to act. Since
 it's only a few of them special parser handling/support isn't needed, the
 module programmer can make that decision on a one-off basis.


 ?,
 Hamish

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] GUI wizards reducing functionality [was: Re: Missing subgroup functionality in GRASS 7 wxGUI's i.group?]

[Hamish]

Moritz wrote:

> I do think that we should have a more general debate about how to handle 
> these issues. Personally, I'm very strongly opposed to this tendency of 
> "dumbing-down" the GUI menus. I have nothing against wizards, but I 
> think they should be an additional feature, not a replacing features.

Hi,

I don't think it needs a big debate, just a bit of finesse in the execution.
For example I think the Cartographic Composer tool does a nice job of hiding
the ps.map module GUI dialog behind a conceptual "Advanced" button using
its menu placement. New users would probably ignore the menu item not
knowing what it did; seasoned users would recognize what it was and use it
as needed, but for them too it wouldn't be cluttering up for normal use.

An example I keep coming back to is wrapper-subset scripts for d.vect (*see g6
addons d.stations, d.varea, and ~d.mark), since the main GUI controls begin
to resemble the complication of a Boeing 747 cockpit. Simplification in and
of itself is not always a bad thing.

wrt the steepness of the learning curve, I don't think you should have to know
the name of a module to launch its GUI (ie from the command line) instead of a
wizard, but the wizard should gently teach you the name of the module. For
me this was the self-assembling command lines at the bottom of the grass5
tcltkgrass module GUIs.

wrt r.import and r.export as fancy g.GUI wizards and r.{in|out}.gdal as
advanced full module dialog GUIs, the idea sounds nice to me.


regards,
Hamish

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

[GRASS-dev] problem with demolocation in compiling

[Michael Barton]

I just updated GRASS 7 and am trying to compile it on my Mac. No change in my 
setup from last time I compiled it a few weeks ago.

It is generating errors on all modules along the lines of…

access: No such file or directory
ERROR: LOCATION
   

   not available

Michael

__
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University
Tempe, AZ  85287-2402
USA

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

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

Re: [GRASS-dev] [GRASS GIS] #2034: GUI crashes on launch for newly compiled binary for Mac OS X

[GRASS GIS]

#2034: GUI crashes on launch for newly compiled binary for Mac OS X
---+
 Reporter:  cmbarton   |   Owner:  grass-dev@…  
 Type:  defect |  Status:  new  
 Priority:  critical   |   Milestone:  7.0.0
Component:  wxGUI  | Version:  svn-trunk
 Keywords: |Platform:  MacOSX   
  Cpu:  OSX/Intel  |  
---+

Comment(by cmbarton):

 Just tested. Still broken. Workaround still works.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] Resources about compiling on Mac OS X

[Michael Barton]

Nope. 

Just tested on GRASS 7 svn updated in the past hour.

Michael
__
C. Michael Barton 
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University
Tempe, AZ  85287-2402
USA

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

On Sep 5, 2013, at 12:18 AM, Moritz Lennert  
wrote:

> On 04/09/13 17:27, Michael Barton wrote:
>> Recent changes have caused problems that require an extra step for my
>> instructions to work. I've been hoping that this could be fixed but it
>> looks increasingly unlikely and may become moot with the new OSX --
>> which could make it impossible to keep producing binaries that can run
>> on 10.6+
>> 
>> Here is the workaround to add to the current WIKI instructions. I'm
>> heading to class and then out of town until next week. Feel free to post
>> them.
> 
> Does this "fix" https://trac.osgeo.org/grass/ticket/2034 ?
> 
> Moritz

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

[GRASS-dev] [GRASS GIS] #2075: Browse in v.in.ogr and r.in.gdal causes entire GUI to crash

[GRASS GIS]

#2075: Browse in v.in.ogr and r.in.gdal causes entire GUI to crash
-+--
 Reporter:  cmbarton |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  critical |   Milestone:  7.0.0
Component:  wxGUI| Version:  svn-trunk
 Keywords:   |Platform:  MacOSX   
  Cpu:  Unspecified  |  
-+--
 This problem is relatively new (past month or so). Clicking the browse
 button in the GUI wrappers for v.in.ogr and r.in.gdal causes the entire
 GUI to crash. Because the whole thing crashes, there are no GRASS error
 messages. Here is what I hope is the relevant portion of the system crash
 message:

 {{{

 Process: Python [26361]
 Path:
 
/System/Library/Frameworks/Python.framework/Versions/2.6/Resources/Python.app/Contents/MacOS/Python
 Identifier:  org.python.python
 Version: 2.6.7 (2.6.7)
 Build Info:  python-600040~1
 Code Type:   X86 (Native)
 Parent Process:  Python [26160]
 User ID: 501

 PlugIn Path:
 /Users/USER/*/GRASS-7.0.app/Contents/MacOS/lib/libwx_macud-2.8.0.dylib
 PlugIn Identifier: libwx_macud-2.8.0.dylib
 PlugIn Version:??? (9)

 Date/Time:   2013-09-11 15:49:55.092 -0700
 OS Version:  Mac OS X 10.8.4 (12E55)
 Report Version:  10

 Interval Since Last Report:  5028416 sec
 Crashes Since Last Report:   948
 Per-App Interval Since Last Report:  8688 sec
 Per-App Crashes Since Last Report:   1
 Anonymous UUID:  5872B1C9-EF11-8711-7280-A91E040454E2

 Crashed Thread:  0  Dispatch queue: com.apple.main-thread

 Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
 Exception Codes: KERN_INVALID_ADDRESS at 0xfff4

 }}}

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] standardized options

[Vaclav Petras]

Hi Madi,

that's interesting and there is even a G_OPT_R_ELEV, I was not aware of it.

You can have a look into these:

http://grass.osgeo.org/programming7/parser__standard__options_8c_source.html
http://grass.osgeo.org/programming7/parser__standard__options_8c.html
http://grass.osgeo.org/programming7/gislib.html#Command_Line_Parsing

Vaclav


On Tue, Jul 16, 2013 at 6:31 AM, Markus Metz
wrote:

> You could try G_OPT_M_DIR. The comment says "directory input" but it
> should also work for output, all it should return is the path to a
> folder.
>
> Markus M
>
>
> On Mon, Jul 15, 2013 at 5:42 PM, Margherita Di Leo
>  wrote:
> > Dear Devs,
> >
> > in r57084 Martin has added standardized options to r.ipso (thanks!). I
> would
> > like to learn more about their use, particularly, does it exist a
> standard
> > variable defined for taking a path as input? (Not a path+file name as
> > G_OPT_F_INPUT). For example this is useful in the case that a module
> > produces some pictures and/or csv files and the user wants to set a
> folder
> > for storing them. I digged into [1] but I seem not to find what I need.
> > Should I just take the path as a string? Giving to the user the
> possibility
> > to browse the folders instead of indicating a path would be IMHO more
> > convenient. Could anyone point me out where to read in order to learn
> more
> > about that?
> >
> > Thanks!
> > madi
> >
> > [1] http://grass.osgeo.org/programming7/gis_8h_source.html
> >
> > --
> > Best regards,
> >
> > Dr. Margherita DI LEO
> > Scientific / technical project officer
> >
> > European Commission - DG JRC
> > Institute for Environment and Sustainability (IES)
> > Via Fermi, 2749
> > I-21027 Ispra (VA) - Italy - TP 261
> >
> > Tel. +39 0332 78 3600
> > margherita.di-...@jrc.ec.europa.eu
> >
> > Disclaimer: The views expressed are purely those of the writer and may
> not
> > in any circumstance be regarded as stating an official position of the
> > European Commission.
> >
> > ___
> > 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
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #1736: wxNVIZ volume display crashes Mac

[GRASS GIS]

#1736: wxNVIZ volume display crashes Mac
---+
 Reporter:  cmbarton   |   Owner:  grass-dev@…  
 Type:  defect |  Status:  new  
 Priority:  critical   |   Milestone:  6.4.4
Component:  wxGUI  | Version:  svn-releasebranch64  
 Keywords: |Platform:  MacOSX   
  Cpu:  OSX/Intel  |  
---+

Comment(by cmbarton):

 I just tested this using Helena's test data for the NC_spm_08 demo data
 location. I've added several isosurces and a slice, and set resolution
 down to 1 and cannot seem to crash it. I thought this fixed or greatly
 improved the problem.

 BUT I cannot get my own data to display at all. Helena, can you check to
 see if your test data set is displaying correctly. Not sure why my data do
 not display (they did a year or two back).

 Michael

-- 
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] #2075: Browse in v.in.ogr and r.in.gdal causes entire GUI to crash

[GRASS GIS]

#2075: Browse in v.in.ogr and r.in.gdal causes entire GUI to crash
-+--
 Reporter:  cmbarton |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  critical |   Milestone:  7.0.0
Component:  wxGUI| Version:  svn-trunk
 Keywords:   |Platform:  MacOSX   
  Cpu:  Unspecified  |  
-+--

Comment(by annakrat):

 Please try r57642. There was a wrong wildcard format which was happily
 ignored on Linux. But definitely there is something wrong in wxPython on
 Mac because such a minor issue shouldn't crash the whole gui.

-- 
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] #2075: Browse in v.in.ogr and r.in.gdal causes entire GUI to crash

[GRASS GIS]

#2075: Browse in v.in.ogr and r.in.gdal causes entire GUI to crash
---+
  Reporter:  cmbarton  |   Owner:  grass-dev@…  
  Type:  defect|  Status:  closed   
  Priority:  critical  |   Milestone:  7.0.0
 Component:  wxGUI | Version:  svn-trunk
Resolution:  fixed |Keywords:   
  Platform:  MacOSX| Cpu:  Unspecified  
---+
Changes (by cmbarton):

  * status:  new => closed
  * resolution:  => fixed


Comment:

 Fixed! Thanks. I agree that there is something weird going on. I wonder if
 it goes away when I stop compiling for 10.6 compatibility?

 Michael

-- 
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] #1736: wxNVIZ volume display crashes Mac

[GRASS GIS]

#1736: wxNVIZ volume display crashes Mac
---+
 Reporter:  cmbarton   |   Owner:  grass-dev@…  
 Type:  defect |  Status:  new  
 Priority:  critical   |   Milestone:  6.4.4
Component:  wxGUI  | Version:  svn-releasebranch64  
 Keywords: |Platform:  MacOSX   
  Cpu:  OSX/Intel  |  
---+

Comment(by cmbarton):

 I was wrong about my data. They DO show up for the first time in months.
 This is GREAT. I'm still not certain that it is showing the z-axis
 correctly. So Helena it is still a good idea to check your test data for
 this. But this is a huge improvement it seems. Maybe it is "fixed" as well
 as it can be.

 Michael

-- 
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] #2075: Browse in v.in.ogr and r.in.gdal causes entire GUI to crash

[GRASS GIS]

#2075: Browse in v.in.ogr and r.in.gdal causes entire GUI to crash
---+
  Reporter:  cmbarton  |   Owner:  grass-dev@…  
  Type:  defect|  Status:  closed   
  Priority:  critical  |   Milestone:  7.0.0
 Component:  wxGUI | Version:  svn-trunk
Resolution:  fixed |Keywords:   
  Platform:  MacOSX| Cpu:  Unspecified  
---+

Comment(by annakrat):

 Replying to [comment:2 cmbarton]:
 > Fixed! Thanks. I agree that there is something weird going on. I wonder
 if it goes away when I stop compiling for 10.6 compatibility?

 Most probably not. Anyway, it's fixed now.

-- 
Ticket URL: 
GRASS GIS 

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