[GRASS-dev] Re: [GRASS GIS] #1136: wxGUI: inconsisent number of &s in buttons

[GRASS GIS]

#1136: wxGUI: inconsisent number of &s in buttons
-+--
 Reporter:  hamish   |   Owner:  grass-...@…  
 Type:  defect   |  Status:  new  
 Priority:  major|   Milestone:  6.4.0
Component:  wxGUI| Version:  svn-releasebranch64  
 Keywords:  mapcalc  |Platform:  MacOSX   
  Cpu:  Unspecified  |  
-+--

Comment(by hamish):

 hopefully now fixed in svn, please test on various platforms.
 now using two &&s for each literal &.

 also I notice in the grass6 man pages that r.mapcalc has &&& as &&&.
 some tweaking in the html->man conversion script needed I guess.


 Hamish

-- 
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] Voxel support in vtk-grass-bridge

[Soeren Gebbert]

Hello,
JFYI, i have added voxel support to the vtk-grass-bridge[1]. Now,
besides of raster and vector data, grass voxel data can be accessed
from C++, Python and Java using a simple object oriented approach.
It is possible to read grass voxel data directly as vtkImage data and
to write vtkImage data as grass voxel data. Hence all vtkImage
filtering classes can be used to process gis grass voxel data, here an
example module which reads and writes grass voxel data and uses the
vtkImageGaussianSmooth class from VTK to process the data:
http://code.google.com/p/vtk-grass-bridge/source/browse/trunk/Modules/Python/r3.gauss.smooth.py

Because of grass vector read and write support in vtk-grass-bridge,
any kind of grass vector data can be converted into grass voxel data
using VTK filtering classes.

The vtk-grass-bridge is still under developing and not stable, but
ready for experiments with grass and VTK.

Good night and good luck
Soeren


[1] http://code.google.com/p/vtk-grass-bridge
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: [GRASS GIS] #1125: wingrass - ctypes - compiling error

[GRASS GIS]

#1125: wingrass - ctypes - compiling error
--+-
 Reporter:  hellik|   Owner:  grass-...@…  
 Type:  defect|  Status:  new  
 Priority:  blocker   |   Milestone:  6.5.0
Component:  Compiling | Version:  svn-trunk
 Keywords:  wingrass, ctypes  |Platform:  MSWindows Vista  
  Cpu:  x86-32|  
--+-

Comment(by hamish):

 Replying to [comment:37 hellik]:
 >
 {{{
  3D view mode not available
  Reason: grass_datetime not found.
  Note that the 3D view mode is currently not working under MS
  Windows (hopefully this will be fixed soon). Please keep an
  eye out for updated versions of GRASS.
 }}}
 >

 fwiw I also see this "MS Windows" message in linux.


 Hamish

-- 
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] #1136: wxGUI: inconsisent number of &s in buttons

[GRASS GIS]

#1136: wxGUI: inconsisent number of &s in buttons
-+--
 Reporter:  hamish   |   Owner:  grass-...@…  
 Type:  defect   |  Status:  new  
 Priority:  major|   Milestone:  6.4.0
Component:  wxGUI| Version:  svn-releasebranch64  
 Keywords:  mapcalc  |Platform:  MacOSX   
  Cpu:  Unspecified  |  
-+--
 Hi,

 I recently added more &s to the raster map calculator buttons as from top
 to bottom I was seeing 1,0,2 of them in the wxgui tool. Now on two debian
 machines I (correctly) see 2, 1, 3. But Michael reports seeing 3, 2, 4 of
 them on Mac. no idea what the correct python quoting should look like, I
 just added &s until I could see them in the buttons.  help?

 also Michael wondered why there was ">>>" in r.mapcalc/mapcalc.y,
 but not a matching "<<<". ?


 argh,
 Hamish

-- 
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] r.mapcalc operator question

[Michael Barton]

In r.mapcalc docs there is an operator >>> for an unsigned right shift.

Is there a corresponding <<< that is not mentioned?

MIchael

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

[GRASS-dev] Re: [GRASS GIS] #1134: WinGrass - 3D view mode crashes

[GRASS GIS]

#1134: WinGrass - 3D view mode crashes
--+-
 Reporter:  hellik|   Owner:  grass-...@…  
 Type:  defect|  Status:  new  
 Priority:  normal|   Milestone:  7.0.0
Component:  wxGUI | Version:  svn-trunk
 Keywords:  wingrass, wxnviz  |Platform:  MSWindows Vista  
  Cpu:  x86-32|  
--+-

Comment(by hellik):

 Replying to [comment:1 hellik]:
 > Replying to [ticket:1134 hellik]:
 >
 > as a side note, I've tried tcltk-nviz in the selfcompiled wingrass7 and
 there are similar error messages, for example:
 >
 > {{{
 > [...]
 > > D3/5: GS_load_att_map(): elevatio...@g7 not loaded in correct form -
 loading now
 > [...]
 > }}}
 >
 > very interesting, because in a self compiled wingrass7 from yesterday
 (r43155) tcltk-nviz was working.
 >
 > Helmut
 >

 tested with WinGRASS-7.0.SVN-r43232-1-Setup.exe from
 http://josef.fsv.cvut.cz/wingrass/grass70/

 all errors and all crashes (3dviewmode and tcltk-nviz) are the same as in
 the initial report. see also attached error-popup from tcltk-nviz

 the same location (nc-sample-dataset), the wingrass64-tcltk-nviz and
 wingrass65-tcltk-nviz are working normally.

 Helmut

-- 
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] #1125: wingrass - ctypes - compiling error

[GRASS GIS]

#1125: wingrass - ctypes - compiling error
--+-
 Reporter:  hellik|   Owner:  grass-...@…  
 Type:  defect|  Status:  new  
 Priority:  blocker   |   Milestone:  6.5.0
Component:  Compiling | Version:  svn-trunk
 Keywords:  wingrass, ctypes  |Platform:  MSWindows Vista  
  Cpu:  x86-32|  
--+-

Comment(by hellik):

 Replying to [comment:35 martinl]:
 > Replying to [comment:34 hellik]:
 > > so I suggest following:
 > >
 > > - closing this ticket, because ctypes compiles now also on windows
 >
 > +1
 >
 > > - after some testing, backport ctypes to grass64/grass65
 >
 > done in r43219 for grass65, please test. Martin

 a quick compiling test of wingrass65 (r43248)

 {{{
 GRASS GIS compilation log
 -
 Started compilation: Tue Aug 24 17:18:42 GMT 2010
 --
 Errors in:
 No errors detected.
 --
 Finished compilation: Tue Aug 24 18:33:28 GMT 2010
 }}}

 and all files seems to be build in
 C:\OSGeo4W\usr\src\grass6_devel\dist.i686-pc-mingw32\etc\python\grass\lib

 but during wingrass65-startup I get:

 {{{
 3D view mode not available
 Reason: grass_datetime not found.
 Note that the 3D view mode is currently not working under MS
 Windows (hopefully this will be fixed soon). Please keep an
 eye out for updated versions of GRASS.
 }}}

 best regards
 Helmut

-- 
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] #1132: wxNviz and wxVdigit missing from 6.4svn

[GRASS GIS]

#1132: wxNviz and wxVdigit missing from 6.4svn
--+-
 Reporter:  hamish|   Owner:  grass-...@…  
 Type:  task  |  Status:  new  
 Priority:  critical  |   Milestone:  6.4.1
Component:  wxGUI | Version:  svn-releasebranch64  
 Keywords:  C++   |Platform:  Linux
  Cpu:  x86-64|  
--+-

Comment(by glynn):

 Replying to [comment:6 hamish]:

 > > wxNviz has been already rewritten in Python (grass65+). Within
 > > the next weeks I am planning to rewrite wxvdigit in Python and
 > > include it in 6.4.1+.
 >
 > just our of curiosity, I wonder the number of programmer-hours it took
 to do that for wxNviz?

 Converting nviz took me a couple of hours, but it's a much, much simpler
 module than vdigit. In particular, the nviz module didn't explicitly use
 wxWidgets at all; it just relied upon the OpenGL context having been set
 up by the Python code.

 Once the ctypes wrappers were generated for the OGSF and nviz libraries,
 the conversion was a direct translation from C++ to Python.

 One of the main issues for vdigit is that it's performing bulk data
 processing, reading individual lines via Vlib and rendering them to a
 PseudoDC. Doing that entirely in Python is likely to be slow, and I don't
 see any easy way around it.

 Using OpenGL would provide more choices.

 One option would be a C (not C++) component which read lines via Vlib and
 "rendered" them into a display list. A C component could be used from
 Python via ctypes, and rendering whole display lists rather than
 individual lines eliminates much of the Python overhead.

 Another option would be utility functions to read large amounts of data
 from Vlib into arrays, which could then be processed using NumPy and
 rendered using glDrawArrays or glDrawElements, so no per-line/per-vertex
 processing in Python.

 Bulk data processing with NumPy is much faster than iterating in Python
 (and NumPy would be an excellent candidate for acceleration via e.g.
 OpenCL or CUDA; I'm surprised it hasn't happened already).

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] 6.4.0 blocker bugs

[Michael Barton]

I'm OK with this plan too. I just don't want to see 6.4 delayed OR released 
broken.

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-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 Aug 24, 2010, at 2:28 AM, grass-dev-requ...@lists.osgeo.org wrote:

> Date: Tue, 24 Aug 2010 02:28:29 -0700 (PDT)
> From: Hamish 
> Subject: Re: [GRASS-dev] 6.4.0 blocker bugs
> To: Martin Landa 
> Cc: grass-dev@lists.osgeo.org
> Message-ID: <108761.7...@web110005.mail.gq1.yahoo.com>
> Content-Type: text/plain; charset=us-ascii
> 
> Martin wrote:
>> from my point of view is unacceptable to change the default
>> GUI (DEFAULT_GUI in init.sh) within 6.4.x. Change it now (i.e.
>> before releasing 6.4.0) or leave it for 6.5 (6.6) or 7.0.
> 
> I don't think it harms backwards compatibility too badly to
> adjust GUI things (scripts+code will still work), but y'all
> make a good point that tutorials and screenshot guides will
> suffer in this case. We can get around the "don't make big
> policy changes right before release" rule by shipping one last
> RC; I would hope the the final 6.4.0 could go out after that
> rather quickly (maybe a week?). So RC7 in the next 24 hrs and
> 6.4.0 some time before Helena's plenary session on Sept 8th?
> (as long as no problems are found within that time..)
> 
> (comments? objections? better ideas?)
> 
> 
> I think we all agree that by 6.4.1 wx should be the default,
> and that big changes are bad within a stable release. Since
> we have had so many RCs wx is now in good shape in the stable
> branch, ready for more eyeballs. so ok with me to be the default,
> so long as that change gets tested.
> 
> I would note that besides init.sh there is also line 83 of
> g.gui/main.c to change in relbr64 to alter the default GUI
> (which GUI to start if "GRASS_GUI=text"), and a grep of the
> docs/announcements.
> 
> We would have to check that it fail-overs back to tcltk if
> tcl is there but wx is not. (I have a Debian/etch machine sitting
> around I can test that on)
> 
> 
> fwiw, changing it manually is not /too/ hard to find:
>  Config -> GRASS working enivronment -> Change default GUI
> ... but you have to know about it before you'd ever think to look.
> 
> 
> As for ctypes backports, AFAICT that is not well tested in 6.5
> yet, so I'm a bit worried to put it into 6.4 yet. Is it just
> copying in lib/python/ctypes/, or are other structural changes
> that need to be coordinated with that? As AFAIK it is "only" a
> new feature, and not really a policy change or bugfix, so I see
> no problem to wait for 6.4.1, 4 weeks or so after the main
> release.
> 
> 
> cheers,
> Hamish
> 
> 
> ps- I wonder if we should really expose g.mapset in the GUI
> menu? Some "Advanced" features are best hidden from new users..
> (& I take it that works well from the now?) or at least only
> let them change mapset from there, to limit damage/confusion.
> (??)
> 
> 
> 
> 
> 

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

Re: [GRASS-dev] double check vector display on MSWindows

[Helena Mitasova]

I got it confirmed fixed from both,
one of them is actually running the class assignment with the  winGRASS exe 
that you have just posted
so it is getting tested right away

  Helena 


On Aug 24, 2010, at 11:19 AM, Martin Landa wrote:

> Hi,
> 
> 2010/8/24 Helena Mitasova :
>> I believe this has been fixed but I just got a complaint about GRASS 
>> crashing when vectors
>> are displayed (this is with the currently available RC6 on VISSTA and this 
>> guy is known to have troubles
>> with everything, so it may be just his particular set up). It may be good to 
>> check before the release
>> because I had another experienced GRASS user reporting this on windows - he 
>> has several versions
>> of python on his machine so I am wondering whether that may be related.
> 
> yes, it should be fixed [1].
> 
> Martin
> 
> [1] http://trac.osgeo.org/grass/ticket/1020
> 
> -- 
> 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] double check vector display on MSWindows

[Martin Landa]

Hi,

2010/8/24 Helena Mitasova :
> I believe this has been fixed but I just got a complaint about GRASS crashing 
> when vectors
> are displayed (this is with the currently available RC6 on VISSTA and this 
> guy is known to have troubles
> with everything, so it may be just his particular set up). It may be good to 
> check before the release
> because I had another experienced GRASS user reporting this on windows - he 
> has several versions
> of python on his machine so I am wondering whether that may be related.

yes, it should be fixed [1].

Martin

[1] http://trac.osgeo.org/grass/ticket/1020

-- 
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

[GRASS-dev] double check vector display on MSWindows

[Helena Mitasova]

I believe this has been fixed but I just got a complaint about GRASS crashing 
when vectors
are displayed (this is with the currently available RC6 on VISSTA and this guy 
is known to have troubles
with everything, so it may be just his particular set up). It may be good to 
check before the release 
because I had another experienced GRASS user reporting this on windows - he has 
several versions
of python on his machine so I am wondering whether that may be related.

Helena 

Begin forwarded message:

> 
> Message:
> I am working through the Getting Started with GRASS video.  When i get to the 
> part that adds the Vector Map streets GRASS crashes.  I get a message saying 
> "the Vector digitizer is currently not working under windows".

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

Re: [GRASS-dev] 6.4.0 blocker bugs

[William Kyngesburye]

On Aug 24, 2010, at 7:55 AM, Hamish wrote:

> Markus wrote:
>> Please change the default GUI and I'll prepare RC7 then
>> immediately.
> 
> release summary now prepared from svn log:
>  https://trac.osgeo.org/grass/wiki/Release/6.4.0RC7-News
> 
> (except for final details of course..)
> 
> 
> clean as needed, enjoy the new trac wiki edit-by-section, just
> click on the hidden [edit] to the right of each section heading.
> 
> e.g. I'm sure 
> "r.watershed: upgraded to improved version"
> and r.out.gdal improvements could be better explained.
> 
> 
> Hamish

I updated the Mac startup so it should let init.sh set the default.

-
William Kyngesburye 
http://www.kyngchaos.com/

"We are at war with them. Neither in hatred nor revenge and with no particular 
pleasure I shall kill every ___ I can until the war is over. That is my duty."

"Don't you even hate 'em?"

"What good would it do if I did? If all the many millions of people of the 
allied nations devoted an entire year exclusively to hating the  it 
wouldn't kill one ___ nor shorten the war one day."

 "And it might give 'em all stomach ulcers."

- Tarzan, on war

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

Re: [GRASS-dev] 6.4.0 blocker bugs

[Martin Landa]

Hi,

2010/8/24 Hamish :

>> Please change the default GUI and I'll prepare RC7 then
>> immediately.

winGRASS for quick testing is available at

http://josef.fsv.cvut.cz/wingrass/grass64/WinGRASS-6.4.SVN-r43230-1-Setup.exe

Martin

-- 
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] 6.4.0 blocker bugs

[Hamish]

Markus wrote:
> Please change the default GUI and I'll prepare RC7 then
> immediately.

release summary now prepared from svn log:
  https://trac.osgeo.org/grass/wiki/Release/6.4.0RC7-News

(except for final details of course..)


clean as needed, enjoy the new trac wiki edit-by-section, just
click on the hidden [edit] to the right of each section heading.

e.g. I'm sure 
 "r.watershed: upgraded to improved version"
and r.out.gdal improvements could be better explained.


Hamish



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

Re: [GRASS-dev] r 43228 "note 'wx' in init.sh and wxGUI in g.gui"

[Martin Landa]

Hi,

2010/8/24 Hamish :
> re. https://trac.osgeo.org/grass/changeset/43228,
>
> {{{
>             echo "Environment variables relevant for startup:"
> -            echo "  GRASS_GUI                      select GUI (text, gui, 
> tcltk, oldtcltk, wxpython)"
> +            echo "  GRASS_GUI                      select GUI (text, gui, 
> tcltk, oldtcltk, wxpython, wx)"
> }}}
>
>
> I would not advertise that
>  $ GRASS_GUI=wx grass64
> actually works. If it is to work, I would just rather it silently
> translated itself to the full name, as "grass64 -wx" expands itself to
> -wxpython interally. Advertising it risks that people will try to set
> the g.gisenv version to the short name as well, and the subsequent
> confusion and problems of not having a single internal name for it.
>
> read sloppy, write strict, and gently guide people to use the canonical
> names for things..

ok, reverted in r43229.

Martin

-- 
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

[GRASS-dev] r 43228 "note 'wx' in init.sh and wxGUI in g.gui"

[Hamish]

Hi,

re. https://trac.osgeo.org/grass/changeset/43228,

{{{
 echo "Environment variables relevant for startup:"
-echo "  GRASS_GUI  select GUI (text, gui, 
tcltk, oldtcltk, wxpython)"
+echo "  GRASS_GUI  select GUI (text, gui, 
tcltk, oldtcltk, wxpython, wx)"
}}}


I would not advertise that
  $ GRASS_GUI=wx grass64
actually works. If it is to work, I would just rather it silently
translated itself to the full name, as "grass64 -wx" expands itself to
-wxpython interally. Advertising it risks that people will try to set
the g.gisenv version to the short name as well, and the subsequent
confusion and problems of not having a single internal name for it.

read sloppy, write strict, and gently guide people to use the canonical
names for things..


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

[GRASS-dev] Re: [GRASS GIS] #1125: wingrass - ctypes - compiling error

[GRASS GIS]

#1125: wingrass - ctypes - compiling error
--+-
 Reporter:  hellik|   Owner:  grass-...@…  
 Type:  defect|  Status:  new  
 Priority:  blocker   |   Milestone:  6.5.0
Component:  Compiling | Version:  svn-trunk
 Keywords:  wingrass, ctypes  |Platform:  MSWindows Vista  
  Cpu:  x86-32|  
--+-

Comment(by hamish):

 Replying to [comment:35 martinl]:
 > Replying to [comment:34 hellik]:
 > > - after some testing, backport ctypes to grass64/grass65
 >
 > done in r43219 for grass65, please test.

 fyi raster_example_ctypes.py updated in doc/python/, vector and
 m.distance.py examples copied over from swig/python/examples/ in trunk but
 still to be ported to ctypes.

 (vector example should be straight forward enough; I don't know enough
 about ctypes to change the swig+NumPtr calls in m.distance)

 also it would be nice to copy in the numpy example from the wiki(?) and an
 example of using "from grass.script import *" non-ctypes variations. right
 now we just say "look in scripts/". Probably some good stuff on the
 mailing list archives to cut & paste into there.


 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] 6.4.0 blocker bugs

[Hamish]

Markus wrote:
> Please change the default GUI and I'll prepare RC7 then
> immediately.

the change is now done.


Hamish



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

Re: [GRASS-dev] 6.4.0 blocker bugs

[Markus Neteler]

On Tue, Aug 24, 2010 at 11:28 AM, Hamish  wrote:
> We can get around the "don't make big
> policy changes right before release" rule by shipping one last
> RC; I would hope the the final 6.4.0 could go out after that
> rather quickly (maybe a week?). So RC7 in the next 24 hrs and
> 6.4.0 some time before Helena's plenary session on Sept 8th?

Yes.

Please change the default GUI and I'll prepare RC7 then immediately.

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

Re: [GRASS-dev] 6.4.0 blocker bugs

[Martin Landa]

Hi,

2010/8/24 Hamish :
>> from my point of view is unacceptable to change the default
>> GUI (DEFAULT_GUI in init.sh) within 6.4.x. Change it now (i.e.
>> before releasing 6.4.0) or leave it for 6.5 (6.6) or 7.0.
>
> I don't think it harms backwards compatibility too badly to
> adjust GUI things (scripts+code will still work), but y'all
> make a good point that tutorials and screenshot guides will
> suffer in this case. We can get around the "don't make big
> policy changes right before release" rule by shipping one last
> RC; I would hope the the final 6.4.0 could go out after that
> rather quickly (maybe a week?). So RC7 in the next 24 hrs and
> 6.4.0 some time before Helena's plenary session on Sept 8th?
> (as long as no problems are found within that time..)
>
> (comments? objections? better ideas?)
>
> I think we all agree that by 6.4.1 wx should be the default,
> and that big changes are bad within a stable release. Since
> we have had so many RCs wx is now in good shape in the stable
> branch, ready for more eyeballs. so ok with me to be the default,
> so long as that change gets tested.
>
> I would note that besides init.sh there is also line 83 of
> g.gui/main.c to change in relbr64 to alter the default GUI
> (which GUI to start if "GRASS_GUI=text"), and a grep of the
> docs/announcements.
>
> We would have to check that it fail-overs back to tcltk if
> tcl is there but wx is not. (I have a Debian/etch machine sitting
> around I can test that on)
>
>
> fwiw, changing it manually is not /too/ hard to find:
>  Config -> GRASS working enivronment -> Change default GUI
> ... but you have to know about it before you'd ever think to look.

OK, if I understand well, you are suggesting to change the default GUI
to wxpython, release today/tomorrow RC7 and within one week to release
6.4.0, is it right? If so, I agree.

> As for ctypes backports, AFAICT that is not well tested in 6.5
> yet, so I'm a bit worried to put it into 6.4 yet. Is it just
> copying in lib/python/ctypes/, or are other structural changes
> that need to be coordinated with that? As AFAIK it is "only" a
> new feature, and not really a policy change or bugfix, so I see
> no problem to wait for 6.4.1, 4 weeks or so after the main
> release.

OK, ctypes is quite advance feature and will be used by wxNviz and
wxVdigit (not ready). So it can wait for 6.4.1. It's just not a
standard approach to add new features within x.y.z. On the other hand,
1.5 year for RCs is also not standard ;-)

Martin

-- 
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

[GRASS-dev] Re: [GRASS GIS] #1132: wxNviz and wxVdigit missing from 6.4svn

[GRASS GIS]

#1132: wxNviz and wxVdigit missing from 6.4svn
--+-
 Reporter:  hamish|   Owner:  grass-...@…  
 Type:  task  |  Status:  new  
 Priority:  critical  |   Milestone:  6.4.1
Component:  wxGUI | Version:  svn-releasebranch64  
 Keywords:  C++   |Platform:  Linux
  Cpu:  x86-64|  
--+-
Changes (by hamish):

  * keywords:  => C++


Comment:

 Replying to [comment:5 martinl]:
 > wxNviz has been already rewritten in Python (grass65+). Within
 > the next weeks I am planning to rewrite wxvdigit in Python and
 > include it in 6.4.1+.

 just our of curiosity, I wonder the number of programmer-hours it took to
 do that for wxNviz? (I guess we can apply our own mere-mortals, already
 blazed trail, and python ability adjustment factors to that number to get
 an idea..)


 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] r.watershed failing: seg fault and exit code 35584

[Markus Metz]

Martin Landa:
>
> Chris Carleton:
>> I haven't been able to find something in the mailing lists about this, but
>> if you know of somewhere that I can find a solution I'd appreciate the link.
>> I'm running GRASS 6.4 RC5 on Ubuntu LTS 10.04 with a Dell Precision T7500
>> Workstation. The region settings are as follows;
>
> RC5 is quite old - please try RC6 or better fresh SVN.
>
The Ubuntu version and grass version used are both true 64bit?
Processing over 130 million cells with r.watershed in memory and 12GB
is possible, but only if grass is compiled as a 64bit application.

SECTION 4: Watershed determination is pretty much unchanged since RC5,
the segfault might also happen in current 6.4.

The combination of threshold=10 and over 130 million cells is a bit
unusual, producing a very large number of stream segments, but AFAICT
not large enough to trigger a segfault.

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

Re: [GRASS-dev] 6.4.0 blocker bugs

[Hamish]

Martin wrote:
> from my point of view is unacceptable to change the default
> GUI (DEFAULT_GUI in init.sh) within 6.4.x. Change it now (i.e.
> before releasing 6.4.0) or leave it for 6.5 (6.6) or 7.0.

I don't think it harms backwards compatibility too badly to
adjust GUI things (scripts+code will still work), but y'all
make a good point that tutorials and screenshot guides will
suffer in this case. We can get around the "don't make big
policy changes right before release" rule by shipping one last
RC; I would hope the the final 6.4.0 could go out after that
rather quickly (maybe a week?). So RC7 in the next 24 hrs and
6.4.0 some time before Helena's plenary session on Sept 8th?
(as long as no problems are found within that time..)

(comments? objections? better ideas?)


I think we all agree that by 6.4.1 wx should be the default,
and that big changes are bad within a stable release. Since
we have had so many RCs wx is now in good shape in the stable
branch, ready for more eyeballs. so ok with me to be the default,
so long as that change gets tested.

I would note that besides init.sh there is also line 83 of
g.gui/main.c to change in relbr64 to alter the default GUI
(which GUI to start if "GRASS_GUI=text"), and a grep of the
docs/announcements.

We would have to check that it fail-overs back to tcltk if
tcl is there but wx is not. (I have a Debian/etch machine sitting
around I can test that on)


fwiw, changing it manually is not /too/ hard to find:
  Config -> GRASS working enivronment -> Change default GUI
... but you have to know about it before you'd ever think to look.


As for ctypes backports, AFAICT that is not well tested in 6.5
yet, so I'm a bit worried to put it into 6.4 yet. Is it just
copying in lib/python/ctypes/, or are other structural changes
that need to be coordinated with that? As AFAIK it is "only" a
new feature, and not really a policy change or bugfix, so I see
no problem to wait for 6.4.1, 4 weeks or so after the main
release.


cheers,
Hamish


ps- I wonder if we should really expose g.mapset in the GUI
menu? Some "Advanced" features are best hidden from new users..
(& I take it that works well from the now?) or at least only
let them change mapset from there, to limit damage/confusion.
(??)



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

[GRASS-dev] Re: [GRASS GIS] #1132: wxNviz and wxVdigit missing from 6.4svn

[GRASS GIS]

#1132: wxNviz and wxVdigit missing from 6.4svn
--+-
 Reporter:  hamish|   Owner:  grass-...@…  
 Type:  task  |  Status:  new  
 Priority:  critical  |   Milestone:  6.4.1
Component:  wxGUI | Version:  svn-releasebranch64  
 Keywords:|Platform:  Linux
  Cpu:  x86-64|  
--+-

Comment(by martinl):

 Replying to [comment:2 hamish]:
 > I can see wanting to save nviz for a backport of the improved version,
 but why was vdigit disabled? My experience with it so far on Linux has
 been very good/impressive.

 my motivation was to disable problematic components of wxGUI. The
 components require specific version of wxPython (copy of pseudodc.cpp/h)
 and swig. wxNviz has been already rewritten in Python (grass65+). Within
 the next weeks I am planning to rewrite wxvdigit in Python and include it
 in 6.4.1+.

 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] #1125: wingrass - ctypes - compiling error

[GRASS GIS]

#1125: wingrass - ctypes - compiling error
--+-
 Reporter:  hellik|   Owner:  grass-...@…  
 Type:  defect|  Status:  new  
 Priority:  blocker   |   Milestone:  6.5.0
Component:  Compiling | Version:  svn-trunk
 Keywords:  wingrass, ctypes  |Platform:  MSWindows Vista  
  Cpu:  x86-32|  
--+-

Comment(by martinl):

 Replying to [comment:34 hellik]:
 > so I suggest following:
 >
 > - closing this ticket, because ctypes compiles now also on windows

 +1

 > - after some testing, backport ctypes to grass64/grass65

 done in r43219 for grass65, please test. 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] #1135: v.patch should allow attribute copy if one of input maps lacks attribute data

[GRASS GIS]

#1135: v.patch should allow attribute copy if one of input maps lacks attribute
data
-+--
 Reporter:  marisn   |   Owner:  grass-...@…  
 Type:  enhancement  |  Status:  new  
 Priority:  normal   |   Milestone:  7.0.0
Component:  Vector   | Version:  svn-trunk
 Keywords:  v.patch  |Platform:  Unspecified  
  Cpu:  Unspecified  |  
-+--
Changes (by martinl):

  * keywords:  => v.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] r.watershed failing: seg fault and exit code 35584

[Martin Landa]

Hi,

2010/8/23 Chris Carleton :
> I haven't been able to find something in the mailing lists about this, but
> if you know of somewhere that I can find a solution I'd appreciate the link.
> I'm running GRASS 6.4 RC5 on Ubuntu LTS 10.04 with a Dell Precision T7500
> Workstation. The region settings are as follows;

RC5 is quite old - please try RC6 or better fresh SVN.

Martin

-- 
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] 6.4.0 blocker bugs

[Martin Landa]

Hi,

2010/8/23 Helmut Kudrnovsky :
>>> Finally, for the FOSS4G 2010 OSGeo Live GIS disc I have packaged it with
>>> ~/.grassrc6 containing GRASS_GUI=wxpython, so there Linux starts with
>>> the wxGUI.
>>
>>At this point we should do it for the rest of the users, too. I'd
>>really like to avoid to
>>be flooded with messages of "where is the new GUI??" content since the
>>standard Linux distros will package whatever is set in the software.
>>
>>Markus
>
> there was so much effort to create a new and working gui (wxgui) which will 
> be the next generation
> user interface.

from my point of view is unacceptable to change the default GUI
(DEFAULT_GUI in init.sh) within 6.4.x. Change it now (i.e. before
releasing 6.4.0) or leave it for 6.5 (6.6) or 7.0.

> IMHO this should be honored a lot and  the wxgui should be considered as the 
> default in the upcoming grass64-release,
> mainly to get feedback and being able to improve this interface.
>
> on windows - I've played a lot with grass64/65/70-versions - I've almost 
> never used the tcltk-gui.
>
> so I vote for wxgui as the default for all os-platforms.

As a wxGUI developer I cannot judge which GUI should be default.

Martin

-- 
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