[GRASS-dev] Re: [GRASS GIS] #705: Python error with winGRASS 6.4RC5

[GRASS GIS]

#705: Python error with winGRASS 6.4RC5
---+
  Reporter:  neteler   |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect|  Status:  new  
  Priority:  normal|   Milestone:  6.4.0
 Component:  wxGUI | Version:  6.4.0 RCs
Resolution:|Keywords:   
  Platform:  MSWindows XP  | Cpu:  Unspecified  
---+
Comment (by cmbarton):

 Can we close? Can you test Markus?

 Michael

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

[GRASS-dev] Re: [GRASS GIS] #689: wxgui - georectify: group does not exist

[GRASS GIS]

#689: wxgui - georectify: group does not exist
---+
  Reporter:  mlennert  |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect|  Status:  closed   
  Priority:  major |   Milestone:  6.5.0
 Component:  wxGUI | Version:  svn-develbranch6 
Resolution:  fixed |Keywords:  wxgui georectify 
  Platform:  All   | Cpu:  All  
---+
Comment (by cmbarton):

 You are right. I meant that this is reported in #709.

 Michael

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

[GRASS-dev] Re: [GRASS GIS] #532: Vector editing not possible with wx tools

[GRASS GIS]

#532: Vector editing not possible with wx tools
--+-
  Reporter:  geognu1  |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect   |  Status:  new  
  Priority:  major|   Milestone:  6.4.0
 Component:  wxGUI| Version:  6.4.0 RCs
Resolution:   |Keywords:  vector, digit
  Platform:  All  | Cpu:  x86-32   
--+-
Comment (by cmbarton):

 Then isn't this really something that needs to be fixed in compiling? I
 don't think this is really a wxGUI issue is it?

 Michael

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

[GRASS-dev] Re: [GRASS GIS] #660: v.delaunay producing incorrect results

[GRASS GIS]

#660: v.delaunay producing incorrect results
---+
  Reporter:  cmbarton  |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect|  Status:  new  
  Priority:  critical  |   Milestone:  6.4.0
 Component:  Vector| Version:  6.4.0 RCs
Resolution:|Keywords:  delaunay 
  Platform:  MacOSX| Cpu:  OSX/Intel
---+
Comment (by cmbarton):

 Still badly broken on my Mac in 6.4 compiled from svn 26 September. Has
 there been any fix since that date?

 Michael

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

[GRASS-dev] Re: [GRASS GIS] #588: wxGUI: About GRASS GIS window doesn't let you view full lic or devs

[GRASS GIS]

#588: wxGUI: About GRASS GIS window doesn't let you view full lic or devs
---+
  Reporter:  hamish|   Owner:  grass-dev@lists.osgeo.org
  Type:  defect|  Status:  reopened 
  Priority:  major |   Milestone:  6.4.0
 Component:  Compiling | Version:  6.4.0 RCs
Resolution:|Keywords:  wingrass, license
  Platform:  MSWindows XP  | Cpu:  Unspecified  
---+
Comment (by cmbarton):

 There are 2 things. The worst bug is that the needed files are/were not
 being copied into the binaries by the makefile. William says he has fixed
 this on the Mac (I haven't yet tested) but I saw comments on the same
 issue in Windows today.

 The 2nd thing is that the information in the files (AUTHOR, COPYING, etc)
 is too big to go into a standard AboutDialog. It is cut off and there is
 no way to add scroll bars to the AboutDialog. Even with the new menu
 buttons, it is still too big (the AUTHORS and GPL.TXT files are several
 screen pages long). So this just won't fit into a standard AboutDialog and
 we have to do something custom in any case. I thought the flatnotebook at
 least matches the rest of the interface, but if someone wants to try
 another kind of control that's OK. However, any control used for this
 information will need scrollbars at the least and it would be better to
 break the information up into its natural chunks (represented by the files
 in $GISBASE).

 I'd recommend either changing this to closed or at least to enhancement
 rather than defect once the Makefiles are fixed on Mac and Windows.

 Michael

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

[GRASS-dev] Re: [GRASS GIS] #588: wxGUI: About GRASS GIS window doesn't let you view full lic or devs

[GRASS GIS]

#588: wxGUI: About GRASS GIS window doesn't let you view full lic or devs
---+
  Reporter:  hamish|   Owner:  grass-dev@lists.osgeo.org
  Type:  defect|  Status:  reopened 
  Priority:  major |   Milestone:  6.4.0
 Component:  Compiling | Version:  6.4.0 RCs
Resolution:|Keywords:  wingrass, license
  Platform:  MSWindows XP  | Cpu:  Unspecified  
---+
Changes (by martinl):

 * cc: martinl (added)

Comment:

 Replying to [comment:9 cmbarton]:
 > Fixed in develbranch_6 r39300. The AboutBox dialog is too small for all
 the GRASS information and you can't add scrollbars. So I've made this a
 tabbed notebook that visually matches the rest of the interface. Please
 test. If it works on other platforms (Linux and Windows), I'll backport to
 releasebranch and trunk.

 I am no happy with this change. I would really incline to use *standard*
 dialogs as much as possible. I hope that the reported bug can be fixed
 without removing {{{wx.AboutDialog}}}.

 Martin

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

[GRASS-dev] Re: [GRASS GIS] #532: Vector editing not possible with wx tools

[GRASS GIS]

#532: Vector editing not possible with wx tools
--+-
  Reporter:  geognu1  |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect   |  Status:  new  
  Priority:  major|   Milestone:  6.4.0
 Component:  wxGUI| Version:  6.4.0 RCs
Resolution:   |Keywords:  vector, digit
  Platform:  All  | Cpu:  x86-32   
--+-
Changes (by martinl):

 * cc: martinl (added)

Comment:

 Replying to [comment:8 cmbarton]:
 > Can we close???

 I don't think so. The problem still remains in different forms, but
 usually it's cause by incompatible version of swig and wxPython.

 Martin

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

[GRASS-dev] Re: [GRASS GIS] #660: v.delaunay producing incorrect results

[GRASS GIS]

#660: v.delaunay producing incorrect results
---+
  Reporter:  cmbarton  |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect|  Status:  new  
  Priority:  critical  |   Milestone:  6.4.0
 Component:  Vector| Version:  6.4.0 RCs
Resolution:|Keywords:  delaunay 
  Platform:  MacOSX| Cpu:  OSX/Intel
---+
Comment (by adhollander):

 On Linux v.delaunay is looking fine to me, testing it on 64bit Ubuntu 9.4
 running 6.4.0RC5.

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

[GRASS-dev] Re: [GRASS GIS] #597: Digitize tool won't work

[GRASS GIS]

#597: Digitize tool won't work
-+--
  Reporter:  vince   |   Owner:  martinl  
  Type:  defect  |  Status:  assigned 
  Priority:  normal  |   Milestone:  6.4.0
 Component:  wxGUI   | Version:  6.4.0 RCs
Resolution:  |Keywords:  digitize 
  Platform:  MacOSX  | Cpu:  x86-64   
-+--
Comment (by cmbarton):

 Works for me in 6.4 and 6.5 on the Mac. Can anyone confirm that this is
 still broken after William changed the way this is compiled on a Mac?

 Michael

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

[GRASS-dev] Re: [GRASS GIS] #708: wxgui georectify: i.rectify runs with -c flag even if "clip to computational region..." box is not checked

[GRASS GIS]

#708: wxgui georectify: i.rectify runs with -c flag even if "clip to
computational region..." box is not checked
---+
  Reporter:  mlennert  |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect|  Status:  new  
  Priority:  major |   Milestone:  6.5.0
 Component:  wxGUI | Version:  svn-develbranch6 
Resolution:|Keywords:  georectify i.rectify -c  
  Platform:  Linux | Cpu:  Unspecified  
---+
Changes (by cmbarton):

  * version:  6.4.0 RCs => svn-develbranch6

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

[GRASS-dev] Re: [GRASS GIS] #708: wxgui georectify: i.rectify runs with -c flag even if "clip to computational region..." box is not checked

[GRASS GIS]

#708: wxgui georectify: i.rectify runs with -c flag even if "clip to
computational region..." box is not checked
---+
  Reporter:  mlennert  |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect|  Status:  new  
  Priority:  major |   Milestone:  6.5.0
 Component:  wxGUI | Version:  6.4.0 RCs
Resolution:|Keywords:  georectify i.rectify -c  
  Platform:  Linux | Cpu:  Unspecified  
---+
Changes (by cmbarton):

  * milestone:  6.4.0 => 6.5.0

Comment:

 Fixed for 6.4 in r39385. This probably still needs to be fixed in
 develbranch_6 and trunk, but can't backport because they are no longer in
 sync with 6.4 in this module. Changing version to 6.5.

 Michael

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

[GRASS-dev] Re: [GRASS GIS] #588: wxGUI: About GRASS GIS window doesn't let you view full lic or devs

[GRASS GIS]

#588: wxGUI: About GRASS GIS window doesn't let you view full lic or devs
---+
  Reporter:  hamish|   Owner:  grass-dev@lists.osgeo.org
  Type:  defect|  Status:  reopened 
  Priority:  major |   Milestone:  6.4.0
 Component:  Compiling | Version:  6.4.0 RCs
Resolution:|Keywords:  wingrass, license
  Platform:  MSWindows XP  | Cpu:  Unspecified  
---+
Comment (by hamish):

 Replying to [comment:10 cmbarton]:
 > Backported to releasebranch and trunk.

 I'm not too crazy about the aesthetics of the fix (tabs come out on a dark
 grey background for me), but it solves the main problem and I don't have
 any better ideas to offer.

 > Changing to compiling because the requisite files have not been
 > getting into the compiled binaries in Windows and Mac. Once the
 > files (AUTHORS, COPYING, GPL.TXT, etc.) get copied into the
 > binaries correctly, they will also display in full.

 does 'g.version -c' display the GPL message and project contact details on
 Mac ??? The Makefile should be copying that stuff into $(ETC), not the
 packager.


 Hamish

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

[GRASS-dev] Re: [GRASS GIS] #580: WinGRASS: $GISBASE/etc/gui/scripts/ require something like $(EXE) to run

[GRASS GIS]

#580: WinGRASS: $GISBASE/etc/gui/scripts/ require something like $(EXE) to run
---+
  Reporter:  hamish|   Owner:  grass-dev@lists.osgeo.org
  Type:  defect|  Status:  new  
  Priority:  blocker   |   Milestone:  6.4.0
 Component:  wxGUI | Version:  6.4.0 RCs
Resolution:|Keywords:  wingrass 
  Platform:  MSWindows XP  | Cpu:  Unspecified  
---+
Comment (by hamish):

 Replying to [comment:4 hamish]:
 > > Running a python script from the DOS prompt it fails though
 > > because it doesn't know what program to associate .PY with.
 > >
 > > what is apparently missing is:
  {{{
   set .py="%GISBASE%/extrabin\python.exe"
  }}}

 Replying to [comment:5 glynn]:
 > I've never seen this syntax.

 Nevermind, further down in the thread that suggested that is the small
 caveat that belongs to some NT4 3rd party replacement for cmd.exe (gee,
 thanks for the tip then).


 > The normal way to associate applications with extensions is via
 > assoc and ftype (but AFAICT, those change the system-wide
 > settings, which may have be overriden by per-user settings).
 ...
 > Note that this will change the registry keys, which will
 > permanently affect the handling of all .py files on the system,
 > not just those which are part of GRASS, and not just for the
 > lifetime of the command prompt.

 ... leading to more like bug #570


 So lacking a way to locally set the extension association, our only choice
 is to ditch PATHEXT and use wrapper scripts which ensure that the
 GRASS_PYTHON enviro var. is respected. Workable from the GUI, but running
 GRASS python modules from the command line will be at the mercy of
 whatever version of python the user has installed. (a python wrapper
 script which launched another (but this time known) version of python to
 run a script is probably asking for trouble)


 > Bundling a "local" copy of Python (with a matching copy of
 > wxPython) may be a reasonable approach for getting the wxGUI
 > working,

 (and even with doing that we still aren't close to mastering it)

 > but any standalone scripts will use the system Python
 > installation, and GRASS shouldn't be interfering with that

 is there anything left which won't use the python set by the GRASS_PYTHON
 enviro variable? (from #570 apparently the answer is yes)

 > (applications which automatically "steal" file associations are
 > generally considered to be malware).

 ... Windows would seem to have a lot of malware then ... at least the DLL
 version clobbering in favour of the last-to-run installer is less
 prevalent these days.


 Hamish

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

[GRASS-dev] Re: [GRASS GIS] #695: Can't create a location using Select Coordinate System option with WXGUI Location Wizard

[GRASS GIS]

#695: Can't create a location using Select Coordinate System option with WXGUI
Location Wizard
---+
  Reporter:  voncasec  |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect|  Status:  closed   
  Priority:  major |   Milestone:  6.4.0
 Component:  wxGUI | Version:  6.4.0 RCs
Resolution:  fixed |Keywords:  Location Wizard  
  Platform:  Linux | Cpu:  Unspecified  
---+
Changes (by cmbarton):

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

Comment:

 Fixed in r39309. Closing.

 Michael

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

[GRASS-dev] Re: [GRASS GIS] #588: wxGUI: About GRASS GIS window doesn't let you view full lic or devs

[GRASS GIS]

#588: wxGUI: About GRASS GIS window doesn't let you view full lic or devs
---+
  Reporter:  hamish|   Owner:  grass-dev@lists.osgeo.org
  Type:  defect|  Status:  reopened 
  Priority:  major |   Milestone:  6.4.0
 Component:  Compiling | Version:  6.4.0 RCs
Resolution:|Keywords:  wingrass, license
  Platform:  MSWindows XP  | Cpu:  Unspecified  
---+
Changes (by cmbarton):

  * component:  wxGUI => Compiling

Comment:

 Backported to releasebranch and trunk.

 Changing to compiling because the requisite files have not been getting
 into the compiled binaries in Windows and Mac. Once the files (AUTHORS,
 COPYING, GPL.TXT, etc.) get copied into the binaries correctly, they will
 also display in full.

 Michael

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

[GRASS-dev] Re: [GRASS GIS] #532: Vector editing not possible with wx tools

[GRASS GIS]

#532: Vector editing not possible with wx tools
--+-
  Reporter:  geognu1  |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect   |  Status:  new  
  Priority:  major|   Milestone:  6.4.0
 Component:  wxGUI| Version:  6.4.0 RCs
Resolution:   |Keywords:  vector, digit
  Platform:  All  | Cpu:  x86-32   
--+-
Comment (by cmbarton):

 Can we close???

 Michael

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

[GRASS-dev] Re: [GRASS GIS] #707: wxGUI: v.digit broken for new maps: "No vector map selected for editing." although selected

[GRASS GIS]

#707: wxGUI: v.digit broken for new maps: "No vector map selected for editing."
although selected
--+-
  Reporter:  neteler  |   Owner:  martinl 
  Type:  defect   |  Status:  closed  
  Priority:  blocker  |   Milestone:  6.4.0   
 Component:  wxGUI| Version:  6.4.0 RCs   
Resolution:  fixed|Keywords:  vector digitizer, vdigit
  Platform:  Linux| Cpu:  All 
--+-
Changes (by cmbarton):

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

Comment:

 Closing. No response for continued problems. Tests by Martin and me show
 no problems now. Can reopen if needed.

 Michael

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

[GRASS-dev] Re: [GRASS GIS] #464: wxGUI: georectify tool fails to create a group

[GRASS GIS]

#464: wxGUI: georectify tool fails to create a group
---+
  Reporter:  msieczka  |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect|  Status:  closed   
  Priority:  major |   Milestone:  6.4.0
 Component:  wxGUI | Version:  6.4.0 RCs
Resolution:  fixed |Keywords:   
  Platform:  All   | Cpu:  All  
---+
Changes (by cmbarton):

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

Comment:

 Fixed in r39382. Please test.

 Michael

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

[GRASS-dev] Re: [GRASS GIS] #689: wxgui - georectify: group does not exist

[GRASS GIS]

#689: wxgui - georectify: group does not exist
---+
  Reporter:  mlennert  |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect|  Status:  closed   
  Priority:  major |   Milestone:  6.5.0
 Component:  wxGUI | Version:  svn-develbranch6 
Resolution:  fixed |Keywords:  wxgui georectify 
  Platform:  All   | Cpu:  All  
---+
Comment (by cmbarton):

 Just noting that this fix was releasebranch r39376

 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] Some wxGUI tests on Windows

[Hamish]

Markus Neteler wrote:
> No idea since I have to use the versions from Colin for the
> time being.
> 
> >> - closing the message window which tells that the digitizer
> >> is unavailable kills the entire GUI
> 
> ... works for you?

Yes it does work for me (XP). Selecting the 3D view locks up the desktop
for about 20sec the first time I try it (0% cpu load, not sure what it's
doing, maybe doing a deep search on the disk for the module), but then
shows the pop up error message and goes on its way. Selecting the 
digitizer pops up a feature unavail. message without any problem.

I notice that you don't see the message warning you that that stuff is not
there in the msys xterm window until after you exit the GUI. And then it
suggests that you need a newer version of GRASS to fix it, which is perhaps
overly-optimistic.

 
> >> - r.shaded.relief doesn't show any error but the result is
> >> completely NULL.

works for me.


> >> - i.group does not permit to select a subgroup (apparently
> >> the list isn't fetched from the group file). Adding it
> >> manually works.
>
> ... will open a ticket for this.
>
> >> - i.maxlik seems to be unable to read the signature file:
> >> ill-conditioned signatures for all classes. It *seems* to
> >> be an issue to read the encoding of the ASCII signature file.
> >> Any G_getl() which should be G_getl2()?
...
> > so, yes.
> 
> attached a diff. Makes sense?

Yes, applied to all branches. (please test) 
I also did all the other G_getl()s in lib/imagery.

IIRC these had been low priority as we can assume that all those files
were written by the imagery library, which only uses fprintf(fp, "\n");.
The flaw in that assumption may come from if the GUIs are writing the
POINTS file etc. directly using some native writel tcl/python command,
or if the user had been going about it by hand in a text editor.
As such I'm not fully convinced this will be the cause + solution to the
problem, but at least will rule something obvious out.
Regardless, now the read is newline independent.


any update on bug #707?
  https://trac.osgeo.org/grass/ticket/707


Hamish




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

Re: [GRASS-dev] Some wxGUI tests on Windows

[Glynn Clements]

Jarek Jasiewicz wrote:

> > - r.shaded.relief doesn't show any error but the result is completely NULL.
> >   Perhaps due to the fact that it is a shell script? If so, I would suggest
> >   to add a Windows test and to bail out rather than continue unless it
> >is substituted with the Python version (6.4.1?).
> 
> Is there some objectives to replace r.shaded.relief with C code?.

What would be the point? The script is essentially a single r.mapcalc
expression.

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

[GRASS-dev] Re: [GRASS GIS] #580: WinGRASS: $GISBASE/etc/gui/scripts/ require something like $(EXE) to run

[GRASS GIS]

#580: WinGRASS: $GISBASE/etc/gui/scripts/ require something like $(EXE) to run
---+
  Reporter:  hamish|   Owner:  grass-dev@lists.osgeo.org
  Type:  defect|  Status:  new  
  Priority:  blocker   |   Milestone:  6.4.0
 Component:  wxGUI | Version:  6.4.0 RCs
Resolution:|Keywords:  wingrass 
  Platform:  MSWindows XP  | Cpu:  Unspecified  
---+
Comment (by glynn):

 Replying to [comment:4 hamish]:

 > %PATHEXT% is used to indicate that .py files are executable and usable
 without their extension. But this only seems to work from the DOS box
 version of WinGrass, not from the MSys xterm (no big surprise there).

 Right. MSys' bash emulates Unix execution semantics.

 Ultimately, WinGRASS is supposed to be "GRASS for Windows", not "GRASS for
 MSys".

 > Running a python script from the DOS prompt it fails though because it
 doesn't know what program to associate .PY with.
 >
 > what is apparently missing is:
 {{{
 set .py="%GISBASE%/extrabin\python.exe"
 }}}

 I've never seen this syntax. The normal way to associate applications with
 extensions is via assoc and ftype (but AFAICT, those change the system-
 wide settings, which may have be overriden by per-user settings).

 > some random google hit shows it might need assoc + ftype as well,

 It's more likely to be "instead of". "set" sets environment variables,
 which have nothing to do with file associations.

 > so I add this all together in C:\GRASS-6-SVN\grass64.bat just after the
 "set PYTHONHOME":
 >
 {{{
 set .py="%GRASSDIR%\extrabin\python.exe"
 assoc .py=Python.File
 ftype Python.File="%GRASSDIR%\extrabin\python.exe" "%1" "%*"
 assoc .pyw=Python.NoConFile
 ftype Python.NoConFile="%GRASSDIR%\extrabin\pythonw.exe" "%1" "%*"
 }}}

 Note that this will change the registry keys, which will permanently
 affect the handling of all .py files on the system, not just those which
 are part of GRASS, and not just for the lifetime of the command prompt.

 Bundling a "local" copy of Python (with a matching copy of wxPython) may
 be a reasonable approach for getting the wxGUI working, but any standalone
 scripts will use the system Python installation, and GRASS shouldn't be
 interfering with that (applications which automatically "steal" file
 associations are generally considered to be malware).

 > and then "cd C:\GRASS-6-SVN\etc\gui\scripts" and v.type_wrapper
 finally launches python, but gives a "unknown option -e" error and shows
 the python.exe usage text.
 >
 > should {{{ set PYTHONPATH="%GRASSDIR%\etc\python" }}} be set in
 C:\GRASS-6-SVN\grass64.bat as well?

 Probably not. This should only be set when invoking a Python script using
 the bundled copy of Python. Scripts run from the command prompt will use
 the system's Python, so you shouldn't be modifying PYTHONPATH in this
 case.

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

[GRASS-dev] Re: [GRASS GIS] #595: WinGRASS g.version -c fails

[GRASS GIS]

#595: WinGRASS g.version -c fails
---+
  Reporter:  hamish|   Owner:  grass-dev@lists.osgeo.org
  Type:  defect|  Status:  new  
  Priority:  blocker   |   Milestone:  6.4.0
 Component:  License   | Version:  6.4.0 RCs
Resolution:|Keywords:  wingrass gpl 
  Platform:  MSWindows XP  | Cpu:  x86-32   
---+
Comment (by glynn):

 Replying to [comment:5 hamish]:

 > so what is this Makefile line doing exactly?
 >  - It's copying the COPYING file into the $GISBASE/etc/VERSION file
 >  - it's terminating each line with a literal '\n'
 >  - it's removing all actual newline chars from the file.
 >
 > So this is getting the file ready to be a string embedded in the C code.

 Yep.

 > The g.version Makefile has it with comments:
 {{{
 > EXTRA_CFLAGS=...

 >   -DCOPYING="\"$(COPYING)\""
 }}}

 > On linux 'strings' shows the COPYING text within the binary, from the
 native WinGrass Msys prompt it doesn't.

 I suspect that the -DCOPYING=... may run into problems with the maximum
 length of a command line on Windows.

 It would be better to convert the COPYING file to a complete C source file
 (including the quotes) which can then be #include'd. E.g.:

 {{{
 EXTRA_CFLAGS=-DGRASS_VERSION_FILE="\"$(GRASS_VERSION_FILE)\"" ...

 $(GRASS_VERSION_FILE): ../../COPYING
 sed -e 's/^.*$/"&\\n"/' $< > $@
 }}}

 and:
 {{{
 static const char COPYING[] =
 #include GRASS_VERSION_FILE
 ;
 }}}

 > so the COPYING: ... > VERSION make rule could be simplified into a
 straight cp?

 No. The VERSION file has "\n" instead of newline.

 Maybe it's provided as a convenience for add-on modules (nothing in the
 GRASS source tree uses it)?

 > interestingly the build info string does make it into the WinGrass
 binary and the $GISBASE/etc/BUILD file also has the correct content in it.

 I note that -DGRASS_CONFIGURE_PARAMS=... comes first; maybe the command
 gets truncated at that point (does g.version have the '''complete''' build
 command?)

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

Re: [GRASS-dev] Using GRASS in long running and multithreaded applications Was: Re: The tomcat shut down ...

[Glynn Clements]

Soeren Gebbert wrote:

> >> Example which works for me in my test code:
> >>
> >> /*Thread local and setjmp() exception support*/
> >> #include 
> >> #ifdef WIN32
> >> #define Thread   __declspec( thread )
> >> #else
> >> #define Thread   __thread
> >> #endif
> >
> > The __thread qualifier is a gcc extension.
> 
> Yes, wikipedia says it works for:
> Sun Studio C/C++, IBM XL C/C++, GNU C and Intel C/C++ (Linux systems)
> 
> Using the pthreads implementation will be a better solution?

Any thread-local state needs to be conditionalised upon the actual
threading mechanism used, with a fall-back to a single instance (i.e. 
a simple variable).

> >> Is this approach ok or to simple or just naive? :)
> >
> > It's too invasive. The longjmp() should go into an application-defined
> > error handler, rather than the GRASS libraries.
> 
> Ok. The error handler looks like that for now:

[snip]

Yep; that's the general idea.

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

Re: [GRASS-dev] backgrounding wxGUI, defaults for 6.x

[Glynn Clements]

Hamish wrote:

> is r39284 "Implement SF_BINDING for Windows" for backport?

It doesn't matter one way or the other. I don't think it's used in
either 6.x or 7.0.

> does it relate to G_spawn_ex(), or just in general? (ie backport
> to 6.4 too when _ex is not yet used there?)

The SF_* constants are only meaningful to G_spawn_ex().

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

[GRASS-dev] Re: [GRASS-user] r.stats: negative cell counts and percentages

[Glynn Clements]

Hamish wrote:

> Hamish wrote:
> > > I notice r.info uses unsigned long long + printf %llu
> > > Shall we standardize on that?
> 
> Glynn wrote:
> > The main downside is that you can end up needing a lot of
> > conditional code.
> 
> I'm not seeing any alternative though.
> 
> For any module which does math with it (eg casting prior to
> variable multiplication/division), perhaps to save some noise in
> the code the LONGTYPE could be set up as a macro at the top
> of the file and then the casts should look like 
>  (LONGTYPE)chellhd.rows * cellhb*cols

I suggest adding the following (or something similar) to config.h:

#ifdef HAVE_LONG_LONG_INT
#define longest long long
#define PRILONGEST_PREFIX "ll"
#else
#define longest long
#define PRILONGEST_PREFIX "l"
#endif

#define PRIdLONGEST PRILONGEST_PREFIX "d"
#define PRIiLONGEST PRILONGEST_PREFIX "i"
#define PRIoLONGEST PRILONGEST_PREFIX "o"
#define PRIuLONGEST PRILONGEST_PREFIX "u"
#define PRIxLONGEST PRILONGEST_PREFIX "x"
#define PRIXLONGEST PRILONGEST_PREFIX "X"

I'm unsure whether it's better to use a macro or a typedef for the
type. Using a macro allows the use of "unsigned longest" rather than
requiring a separate typedef (e.g. "u_longest").

I have no particular preference as to the name of the macro/type, or
whether to use upper or lower case for a macro (a typedef should use
lower case).

The PRI* syntax is intended to mirror the C99 macros from
. The definition doesn't include the leading "%", so that
you can include flags, a field width and/or a precision.

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

[GRASS-dev] Re: [GRASS GIS] #689: wxgui - georectify: group does not exist

[GRASS GIS]

#689: wxgui - georectify: group does not exist
---+
  Reporter:  mlennert  |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect|  Status:  closed   
  Priority:  major |   Milestone:  6.5.0
 Component:  wxGUI | Version:  svn-develbranch6 
Resolution:  fixed |Keywords:  wxgui georectify 
  Platform:  All   | Cpu:  All  
---+
Comment (by hamish):

 Replying to [comment:3 cmbarton]:
 > I see that the problems with georectification in 6.5 are
 > reported in ticket #705. So I'm closing this one.

 #705 doesn't seem like the right ticket.


 Hamish

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

[GRASS-dev] Re: [GRASS GIS] #705: Python error with winGRASS 6.4RC5

[GRASS GIS]

#705: Python error with winGRASS 6.4RC5
---+
  Reporter:  neteler   |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect|  Status:  new  
  Priority:  normal|   Milestone:  6.4.0
 Component:  wxGUI | Version:  6.4.0 RCs
Resolution:|Keywords:   
  Platform:  MSWindows XP  | Cpu:  Unspecified  
---+
Comment (by hamish):

 Replying to [comment:1 cmbarton]:
 > Can you tell me what is wrong with your location so that I can
 > duplicate it and see what kind of error this is?

 I think that bug was fixed by #654.


 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] python in windows?

[Hamish]

Michael Barton wrote:
> We have a python script that uses
> g_parser and runs find in Linux and Mac.
> We can get it to open but not to actually read
> the input argument from the GUI in
> Windows. 
> Is there something special we need to do to make
> a GRASS Python script run in Windows?

this is a similar problem as NVIZ has from the wxGui File menu or wx
Cmd> prompt.



Is the script somewhere in the $PATH / %PATH% ?


maybe these hints from trac #580 can help ?
  https://trac.osgeo.org/grass/ticket/580

rem ...make .py extension optional
set PATHEXT=%PATHEXT%;.PY

rem ...not sure, the following maybe does nothing
set .py="%GRASSDIR%\extrabin\python.exe"

rem ...these are important
assoc .py=Python.File
ftype Python.File="%GRASSDIR%\extrabin\python.exe" "%1" "%*"
assoc .pyw=Python.NoConFile
ftype Python.NoConFile="%GRASSDIR%\extrabin\pythonw.exe" "%1" "%*"



Hamish




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

[GRASS-dev] python in windows?

[Michael Barton]

We have a python script that uses g_parser and runs find in Linux and  
Mac.


We can get it to open but not to actually read the input argument from  
the GUI in Windows.


Is there something special we need to do to make a GRASS Python script  
run in Windows?


Thanks
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; fax: 480-965-7671
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

[GRASS-dev] Re: [GRASS GIS] #464: wxGUI: georectify tool fails to create a group

[GRASS GIS]

#464: wxGUI: georectify tool fails to create a group
---+
  Reporter:  msieczka  |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect|  Status:  new  
  Priority:  major |   Milestone:  6.4.0
 Component:  wxGUI | Version:  6.4.0 RCs
Resolution:|Keywords:   
  Platform:  All   | Cpu:  All  
---+
Changes (by cmbarton):

  * version:  svn-develbranch6 => 6.4.0 RCs

Comment:

 The reason for this is that running i.group somehow switches out of the
 source (xy) location back to the original (target) location. There is
 something in menuform.py or possibly gselect.py that is overriding the
 environmental settings in force when it they are called. So far, I have
 not been able to find the reason for this.

 AFAIK, this is in all branches. But I'm putting it to 6.4 RC so that we
 try to get this solved soon.

 Michael

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

[GRASS-dev] Re: [GRASS GIS] #689: wxgui - georectify: group does not exist

[GRASS GIS]

#689: wxgui - georectify: group does not exist
---+
  Reporter:  mlennert  |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect|  Status:  closed   
  Priority:  major |   Milestone:  6.5.0
 Component:  wxGUI | Version:  svn-develbranch6 
Resolution:  fixed |Keywords:  wxgui georectify 
  Platform:  All   | Cpu:  All  
---+
Changes (by cmbarton):

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

Comment:

 I see that the problems with georectification in 6.5 are reported in
 ticket #705. So I'm closing this one.

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

[GRASS-dev] Re: [GRASS GIS] #689: wxgui - georectify: group does not exist

[GRASS GIS]

#689: wxgui - georectify: group does not exist
---+
  Reporter:  mlennert  |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect|  Status:  new  
  Priority:  major |   Milestone:  6.5.0
 Component:  wxGUI | Version:  svn-develbranch6 
Resolution:|Keywords:  wxgui georectify 
  Platform:  All   | Cpu:  All  
---+
Changes (by cmbarton):

  * priority:  normal => major
  * platform:  Unspecified => All
  * version:  6.4.0 RCs => svn-develbranch6
  * cpu:  Unspecified => All

Comment:

 It's not completely clear from the description, but I'm pretty sure that
 this is fixed. Basically, georectification was broken because it was not
 running i.rectify in the source (xy) location. Hence, it could not find
 the group in the source location. I've fixed this. But there is still a
 problem with creating a group from the georectifier because it is
 switching back out of the source location when i.group is run. If this is
 not reported elsewhere, I'll open a separate ticket on this.

 I'm also not sure whether this is reported for 6.4 or 6.5 (see
 properties). I've fixed this for 6.4. 6.5 is also broken but in a
 different way.

 I'm closing this for 6.4 but leaving it open for version 6.5 because I
 suspect that there are similar causes to 6.5 breaking.

 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] Some wxGUI tests on Windows

[Michael Barton]

On Oct 2, 2009, at 1:11 AM, grass-dev-requ...@lists.osgeo.org wrote:


Date: Fri, 2 Oct 2009 10:04:58 +0200
From: Markus Neteler 
Subject: Re: [GRASS-dev] Some wxGUI tests on Windows
To: Hamish 
Cc: GRASS developers list 
Message-ID:
   <86782b610910020104p1dbd57f5n637d8c1724cad...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

On Thu, Oct 1, 2009 at 8:16 PM, Hamish  wrote:

Markus wrote:

today I had occasion to test on a colleague's computer the
latest binary package.
Here a list of some issues I came across (tell me which
should become a ticket):


(we need more of this, thanks)


- i.group does not permit to select a subgroup (apparently
the list isn't�fetched from the group file). Adding it
manually works.


... will open a ticket for this.



I seem to remember discussion of a bug about subgroups being discussed  
over the past 6 months or so. There might already be a ticket.


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

[GRASS-dev] Re: i.rgb.his/i.his.rgb and 16bit images

[Georg Kaspar]

Hamish wrote:
> Very sorry if this is a dumb question, but did you set n_levels= to
> 65535? (it defaults to 8bit)

actually i set it to 2048 but i guess i should have used 2047. the data 
seems to be encoded using 11bits

> Does 'i.rgb2his --help' show the option? what does 'r.info -r' say about
> the 3 r,g,b bands?

yes, the option is shown.

r.info -r on initial datasets 
min=0
max=2047

> really that option name is misleading, it should be max_level=255 or
> n_levels=256 or bitdepth=8. I think to go with bitdepth= with 8,16 as
> the only options. Anyone know if 32bit or other bits satellite/imagery
> data exist?

yes, quickbird seems to use 11bit ;)
but i guess grass will use 16bit to store the data anyway...

> set colors with:
> 
> r.colors band.red color=rules
> 0 black
> 65535 white
> end
> 
> etc.
> 
> note that i.his2rgb has not been modified; experimenting with i.rgb2his
> first.
> 
> do you know of any free-for-download QB data for testing it with?

http://glcf.umiacs.umd.edu/data/quickbird/

bests,
Georg


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

[GRASS-dev] Re: [GRASS GIS] #537: g.proj.exe crashes on Windows Vista (osgeo4w)

[GRASS GIS]

#537: g.proj.exe crashes on Windows Vista (osgeo4w)
--+-
  Reporter:  giohappy |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect   |  Status:  closed   
  Priority:  major|   Milestone:  6.4.0
 Component:  default  | Version:  6.4.0 RCs
Resolution:  fixed|Keywords:  osgeo4w g.proj gdal  
  Platform:  MSWindows Vista  | Cpu:  x86-32   
--+-
Comment (by daudeoud):

 I find the same Vista g.proj crash problem on Grass 6.4.0, Qgis 1.0.2 and
 1.3 with the OSGeo4W package. Is there a solution without recompiling the
 package ?

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

Re: [GRASS-dev] Some wxGUI tests on Windows

[Jarek Jasiewicz]

Hi

Markus Neteler pisze:


- r.shaded.relief doesn't show any error but the result is completely NULL.
  Perhaps due to the fact that it is a shell script? If so, I would suggest
  to add a Windows test and to bail out rather than continue unless it
   is substituted with the Python version (6.4.1?).

  
Is there some objectives to replace r.shaded.relief with C code?. It 
looks like very easy task and I can do that when I have little more time.

Jarek


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

Re: [GRASS-dev] Some wxGUI tests on Windows

[Martin Landa]

Hi,

2009/10/2 Markus Neteler :
> On Thu, Oct 1, 2009 at 8:16 PM, Hamish  wrote:
>> Markus wrote:
>>> today I had occasion to test on a colleague's computer the
>>> latest binary package.
>>> Here a list of some issues I came across (tell me which
>>> should become a ticket):
>>
>> (we need more of this, thanks)
>
> We can do that but we aren't able to compile ourself currently...

I am planning to set up OSGeo BuildBot [1] slave on our new servers -
at least to build binaries for Debian GNU/Linux and MS Windows. Hope
to do it in December, currently no time for that.

Martin

[1] http://wiki.osgeo.org/wiki/How_to_create_new_OSGeo_BuildBot_instance

-- 
Martin Landa  * http://gama.fsv.cvut.cz/~landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Some wxGUI tests on Windows

[Markus Neteler]

On Thu, Oct 1, 2009 at 8:16 PM, Hamish  wrote:
> Markus wrote:
>> today I had occasion to test on a colleague's computer the
>> latest binary package.
>> Here a list of some issues I came across (tell me which
>> should become a ticket):
>
> (we need more of this, thanks)

We can do that but we aren't able to compile ourself currently...

>> - Map canvas: zoom to RGB layer finishes in the 0..1 space
>>   (solution might be to zoom to one channel of the RGB
>> set?)
>
> is this the one fixed by Marin yesterday?

No idea since I have to use the versions from Colin for the time
being.

>> - closing the message window which tells that the digitizer
>> is unavailable kills the entire GUI

... works for you?

>> - r.shaded.relief doesn't show any error but the result is
>> completely NULL.
>>   Perhaps due to the fact that it is a shell script?
>> If so, I would suggest
>>   to add a Windows test and to bail out rather than
>> continue unless it is substituted with the Python version
>> (6.4.1?).

Since all say that r.shaded.relief works it might be a problem
here. also using XP.

> I will try to hijack a PC in the office at lunch to confirm.
> AFAIK all shell scripts just worked. The only problematic
> ones were the wrapper scripts in $GISBASE/etc/gui/scripts/
> which had either (not sure which) PATH, PYTHONPATH, PATHEXT,
> or post-parser-can't-find-it-anymore problems.
>
>> - i.group does not permit to select a subgroup (apparently
>> the list isn't fetched from the group file). Adding it
>> manually works.

... will open a ticket for this.

>> - i.maxlik seems to be unable to read the signature file:
>> ill-conditioned signatures for all classes. It *seems* to
>> be an issue to read the encoding of the ASCII signature file.
>> Any G_getl() which should be G_getl2()?
>
> grass65:
>
> develbranch_6/lib/imagery$ grep G_getl *
> ls_groups.c:    while (G_getl(buf, sizeof(buf), ls)) {
> ls_groups.c:    while (G_getl(buf, sizeof(buf), ls)) {
> points.c:    while (G_getl(buf, sizeof buf, fd)) {
> title.c:        G_getl(title, n, fd);
>
> develbranch_6/lib/imagery$ grep fgets *
> group.c:    while (fgets(buf, sizeof buf, fd)) {
>
> so, yes.

attached a diff. Makes sense?

>>   If so, what's the purpose of still keeping G_getl()?
>
> beware if def'n of buffer size of n or n-1 may differ, and
> if return type is a little different (I think that's mainly
> between fgets() and G_getl2(), but not sure)

ok.

Markus
Index: lib/imagery/group.c
===
--- lib/imagery/group.c	(revision 39339)
+++ lib/imagery/group.c	(working copy)
@@ -154,7 +154,7 @@
 if (!fd)
 	return 0;
 
-while (fgets(buf, sizeof buf, fd)) {
+while (G_getl2(buf, sizeof buf, fd)) {
 	n = sscanf(buf, "%255s %255s %15s", name, mapset, color);	/* better use INAME_LEN */
 	if (n == 2 || n == 3) {
 	I_add_file_to_group_ref(name, mapset, ref);
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev