headers
GRASS GIS | 1 Mar 2009 01:44
Favicon

Re: [GRASS GIS] #510: bad display in the Output window for r.report and r.stats with aspect maps.

#510: bad display in the Output window for r.report and r.stats with aspect maps.
----------------------+-----------------------------------------------------
  Reporter:  clerici  |       Owner:  grass-dev <at> lists.osgeo.org
      Type:  defect   |      Status:  new                      
  Priority:  major    |   Milestone:  6.4.0                    
 Component:  default  |     Version:  6.4.0 RCs                
Resolution:           |    Keywords:                           
  Platform:  Linux    |         Cpu:  Unspecified              
----------------------+-----------------------------------------------------
Comment (by hamish):

 I can't replicate the badly sorted r.report output, either from GIS.m or
 the command line.


 Note that your r.stats result is missing some lines too, it seems to skip
 from 1.4% to 33%. Here I get the continuous set:

 {{{
 spearfish:G65> g.region rast=aspect
 spearfish:G65> r.stats -a -p in=aspect | head -n 25
  100%
 0-1.411765 537300.000000   0.20%
 1.411765-2.823529 827100.000000   0.30%
 2.823529-4.235294 882900.000000   0.32%
 4.235294-5.647059 1002600.000000   0.37%
 5.647059-7.058824 965700.000000   0.35%
 7.058824-8.470588 1116000.000000   0.41%
 8.470588-9.882353 919800.000000   0.34%
 9.882353-11.294118 1382400.000000   0.51%
(Continue reading)

Permalink | Reply | 0 comments |
headers
GRASS GIS | 1 Mar 2009 03:16
Favicon

Re: [GRASS GIS] #111: r.los fails in WinGRASS with high values for max_dis parameter

#111: r.los fails in WinGRASS with high values for max_dis parameter
---------------------------+------------------------------------------------
  Reporter:  gsancho       |       Owner:  grass-dev <at> lists.osgeo.org
      Type:  defect        |      Status:  new                      
  Priority:  major         |   Milestone:  6.4.0                    
 Component:  Raster        |     Version:  svn-develbranch6         
Resolution:                |    Keywords:  wingrass r.los           
  Platform:  MSWindows XP  |         Cpu:  x86-32                   
---------------------------+------------------------------------------------
Comment (by hamish):

 another report of it:
 http://lists.osgeo.org/pipermail/grass-windows/2008-November/001587.html


 ----
 Benjamin Ducke wrote on the -dev list:
 {{{
 Michael,

 this is a problem with dirty memory allocation that never got fixed.
 On some systems, like Linux, the memory manager is a bit more "relaxed"
 and lets this pass. On Windows, it's more strict and kills
 the application. The crashes appear a bit random which is typical for
 memory allocation problems. The more allocations involved (read: the
 bigger
 you set max_dist), the more probable it becomes that a sensitive memory
 region gets corrupted and the program bails out.

 If anyone wants to have a go at it: use Valgrind on Linux. It will tell
 you exactly where the bad allocations happen. I actually had a go at this
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hamish | 1 Mar 2009 03:22
Picon
Favicon
Gravatar

Re: r.los on windows question


Benjamin wrote:
> this is a problem with dirty memory allocation that never
> got fixed.
....
> If anyone wants to have a go at it: use Valgrind on Linux.
> It will tell you exactly where the bad allocations happen.

Markus has done that already; posted to the bug tracker:
  http://trac.osgeo.org/grass/ticket/111

> From memory: the problem can be fixed by delaying the release of memory
> allocated at the start of each run through the main loop.

also if anyone is interested r.viewshed from wiki addons only needs some
cleanup and small bug fixes to have a LOS app which scales a lot better.

Hamish
Permalink | Reply | 1 comment |
headers
Hamish | 1 Mar 2009 03:30
Picon
Favicon
Gravatar

Re: question about raster cats and labels


Michael:
> That squashes an idea we had to record different kinds of
> information in the cat and label.

what did you have in mind?

Hamish
Permalink | Reply | 0 comments |
headers
Hamish | 1 Mar 2009 03:48
Picon
Favicon
Gravatar

Re: Fwd: question about gui switching menu item


Michael wrote:
> >> Why does the menu item to change the gui have to run a script instead
> >> of just run g.gui tcltk -un?

because for 6.4 there is a choice of text,d.m,gis.m, and wxPython.

I added a wrapper script instead of just opening a GUI for g.gui to 
enforce that the -u and -n flags are used and make it a bit more obvious.

see  http://trac.osgeo.org/grass/ticket/500

I initially added some text about "will take effect next time you start
grass" but removed it after I noticed that module popup guis use the new
gui immediately. so maybe say "will take *full* effect next time..." or so.
?

"""""
Running it from the wxPython GUI still needs to be tested by someone please. Config -> Working enviro ->
Change default GUI

Also, I was thinking it could be useful to add an entry after 'Help->About system' like 'Help->Show system
environment' which would run "set" and dump the results to the Output window. It would help in debugging. 
"""""
prob add a sep line in the help menu for that and 'About System'.

Hamish
Permalink | Reply | 2 comments |
headers
Michael Barton | 1 Mar 2009 04:36
Picon
Favicon

Re: Fwd: question about gui switching menu item

I've tested it in wxPython and it works on the Mac.

The script is more than I had in mind, but is indeed nice.

I was only able to follow the discussion in parts. I remember some  
talk about windows not having a command line. But in fact it does have  
a command line in both TclTk and wxPython, even if it does not have a  
full terminal. The lack of a terminal, however, means that text and  
old d.m are not available for Windows. It only can run the TclTk gis.m  
and wxPython GUI's. I'm not sure what will happen in Windows if  
someone selects text or d.m. Linux and the Mac, with terminal can run  
these other modes, but this makes a nice menu item less important too.

Michael

On Feb 28, 2009, at 7:48 PM, Hamish wrote:

>
> Michael wrote:
>>>> Why does the menu item to change the gui have to run a script  
>>>> instead
>>>> of just run g.gui tcltk -un?
>
> because for 6.4 there is a choice of text,d.m,gis.m, and wxPython.
>
> I added a wrapper script instead of just opening a GUI for g.gui to
> enforce that the -u and -n flags are used and make it a bit more  
> obvious.
>
> see  http://trac.osgeo.org/grass/ticket/500
(Continue reading)

Permalink | Reply | 1 comment |
headers
Michael Barton | 1 Mar 2009 04:43
Picon
Favicon

Re: [GRASS GIS] #431: vector operations crash in 64bit OSX


On Feb 28, 2009, at 8:36 PM, <grass-dev-request <at> lists.osgeo.org> wrote:

> Date: Sat, 28 Feb 2009 18:36:43 -0000
> From: "GRASS GIS" <trac <at> osgeo.org>
> Subject: [GRASS-dev] Re: [GRASS GIS] #431: vector operations crash in
> 	64bit	OSX
> To: undisclosed-recipients:;
> Message-ID: <052.d87121ae002aa41c3077d2e7d7113b18 <at> osgeo.org>
> Content-Type: text/plain; charset="utf-8"
>
> #431: vector operations crash in 64bit OSX
> ------------------------ 
> +---------------------------------------------------
>  Reporter:  kyngchaos  |       Owner:  grass-dev <at> lists.osgeo.org
>      Type:  defect     |      Status:  closed
>  Priority:  major      |   Milestone:  6.4.0
> Component:  Vector     |     Version:  svn-develbranch6
> Resolution:  fixed      |    Keywords:
>  Platform:  MacOSX     |         Cpu:  x86-64
> ------------------------ 
> +---------------------------------------------------
> Changes (by mmetz):
>
>  * status:  new => closed
>  * resolution:  => fixed
>
> Comment:
>
> fixed in trunk r36003 and devbr6 r36049
(Continue reading)

Permalink | Reply | 6 comments |
headers
William Kyngesburye | 1 Mar 2009 05:29
Favicon

Re: Re: [GRASS GIS] #431: vector operations crash in 64bit OSX

On Feb 28, 2009, at 9:43 PM, Michael Barton wrote:

>> #431: vector operations crash in 64bit OSX
>> ------------------------ 
>> +---------------------------------------------------
>> Reporter:  kyngchaos  |       Owner:  grass-dev <at> lists.osgeo.org
>>     Type:  defect     |      Status:  closed
>> Priority:  major      |   Milestone:  6.4.0
>> Component:  Vector     |     Version:  svn-develbranch6
>> Resolution:  fixed      |    Keywords:
>> Platform:  MacOSX     |         Cpu:  x86-64
>> ------------------------ 
>> +---------------------------------------------------
>> Changes (by mmetz):
>>
>> * status:  new => closed
>> * resolution:  => fixed
>>
>> Comment:
>>
>> fixed in trunk r36003 and devbr6 r36049
>>
>> -- 
>> Ticket URL: <http://trac.osgeo.org/grass/ticket/431#comment:1>
>> GRASS GIS <http://grass.osgeo.org>
>
> Does this mean that we can compile GRASS 7 in 64bit on the Mac now?
>
I hope so.  I'll be checking it out some time in the next couple  
days.  Though we'll have to think about the python stuff now - it
(Continue reading)

Permalink | Reply | 5 comments |
headers
Hamish | 1 Mar 2009 06:27
Picon
Favicon
Gravatar

Re: Fwd: question about gui switching menu item


Michael wrote:
> I've tested it in wxPython and it works on the Mac.

thanks.

> I remember some talk about windows not having a command line.

one is available. just not at the same time as the gui.

from the OSGeo4W DOS box shell run "grass64 -text" and you get one
in the same dos box. (but no xmons) Handy for batch jobs or experts.

> But in fact it does have a command line in both TclTk and
> wxPython, even if it does not have a full terminal.

[internal one, see "d.mon not implemented" error window from wxPy seen
in i.class thread when a user tries to follow old-way examples]

> The lack of a terminal, however, means that text and old d.m are not
> available for Windows.

ok, d.m is not available in windows because of no monitors and it uses
xmons. hmm. "d.m" from the command prompt actually does launch it.
(more below)

> It only can run the TclTk gis.m and wxPython GUI's.

(and stand-alone text)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Barton | 1 Mar 2009 07:06
Picon
Favicon

v.in.db should look for file

Now that Martin fixed the wxPython gui for v.in.db, I see a problem I  
had not previously noticed. That is, the module looks for vector  
tables. However, the objective of this module is to find a database  
table (recognized by a GRASS driver) anywhere on a user's computer and  
create vector points from its x and y coordinates.

So instead of looking for a vector table, it should be looking for a  
file. In main.c (lines 56-58), would this be ...

     table_opt = G_define_standard_option(G_OPT_F_INPUT);
     table_opt->required = YES;
     table_opt->description = _("Input table name");

instead of the current...

     table_opt = G_define_standard_option(G_OPT_TABLE);
     table_opt->required = YES;
     table_opt->description = _("Input table name");

??

I'd change this, but I'm not sure if anything else needs to change too.

Michael
Permalink | Reply | 1 comment |

Gmane