date:20100515

[GRASS-dev] Re: [GRASS GIS] #1037: v.random inconsequence between interface and source

2010-05-15 Thread GRASS GIS

#1037: v.random inconsequence between interface and source
--+-
  Reporter:  jarekj71 |   Owner:  martinl 
  Type:  defect   |  Status:  closed  
  Priority:  normal   |   Milestone:  6.5.0   
 Component:  Vector   | Version:  svn-develbranch6
Resolution:  fixed|Keywords:  v.random
  Platform:  Unspecified  | Cpu:  Unspecified 
--+-
Changes (by martinl):

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

-- 
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] #946: Opening Properties Dialog in Layer Manager gives error

2010-05-15 Thread GRASS GIS

#946: Opening Properties Dialog in Layer Manager gives error
-+--
  Reporter:  epatton |   Owner:  martinl 
  Type:  defect  |  Status:  closed  
  Priority:  normal  |   Milestone:  6.5.0   
 Component:  wxGUI   | Version:  svn-develbranch6
Resolution:  worksforme  |Keywords:  
  Platform:  Linux   | Cpu:  x86-64  
-+--
Changes (by martinl):

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

-- 
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] #582: import of multiple rasters does not do anything

2010-05-15 Thread GRASS GIS

#582: import of multiple rasters does not do anything
---+
  Reporter:  timmie|   Owner:  martinl  
  Type:  defect|  Status:  closed   
  Priority:  normal|   Milestone:  6.4.0
 Component:  wxGUI | Version:  6.4.0 RCs
Resolution:  worksforme|Keywords:   
  Platform:  MSWindows XP  | Cpu:  x86-32   
---+
Changes (by martinl):

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

-- 
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] #1032: ErrorCommandExecution g.proj

2010-05-15 Thread GRASS GIS

#1032: ErrorCommandExecution g.proj
--+-
  Reporter:  sallar   |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect   |  Status:  new  
  Priority:  blocker  |   Milestone:  6.4.0
 Component:  default  | Version:  6.4.0 RCs
Resolution:   |Keywords:  g.proj   
  Platform:  Linux| Cpu:  x86-32   
--+-
Comment (by martinl):

 Replying to [comment:14 glynn]:
 > I'm not sure why the backtrace stopped (maybe the caller was built with
 -fomit-frame-pointer?), but it looks like heap corruption. In which case,
 the stack trace doesn't really help, as the error is in whatever caused
 the heap corruption, not whatever happens to get bitten by it.
 > valgrind might be able to help here.

 Can you post here valgrind output ?

 http://grass.osgeo.org/wiki/GRASS_Debugging#Using_Valgrind

-- 
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] #1051: wxgui: SEARCH_PATH corruption

2010-05-15 Thread GRASS GIS

#1051: wxgui: SEARCH_PATH corruption
---+
  Reporter:  msieczka  |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect|  Status:  new  
  Priority:  critical  |   Milestone:  6.4.0
 Component:  wxGUI | Version:  svn-releasebranch64  
Resolution:|Keywords:   
  Platform:  All   | Cpu:  All  
---+
Comment (by glynn):

 Replying to [ticket:1051 msieczka]:
 > The mapset search path in mapset2 is wrong:
 >
 {{{
 $ g.gisenv get=MAPSET
 mapset2

 g.mapsets -p
 mapset1 PERMANENT mapset2
 }}}
 >
 > If maps of the same names exist in mapset1 and mapset2, GRASS will pick
 the one from mapset1 although the current mapset is mapset2. This might
 lead to various troubles.

 This isn't necessarily a problem. GRASS itself doesn't care whether the
 current mapset is first in the search path, or even if it's in the search
 path at all.

 OTOH, it's probably a good idea for the GUI interface to place additional
 mapsets after the current mapset, at least by default.

 However: I'd like to take this opportunity to remind programmers that an
 unqualified input map name does '''NOT''' necessarily refer to the map of
 that name in the '''current''' mapset, but to the first map with that name
 found in the mapset search path (which may '''or may not''' have the
 current mapset first).

 If you intend to refer specifically to a map in the current mapset, you
 '''need''' to specify the mapset.

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

Re: [GRASS-dev] Re: python scripts and standard input

2010-05-15 Thread Glynn Clements

Massimo Di Stefano wrote:

> the work-around :
> 
> > while 1:
> >   try:
> >   function() 
> >   break
> >   except IOError: 
> >   sleep(0.1)
> 
> works, 
> but i have to add it for each grass command i'm running in the code.

First, I'd suggest checking to see whether this has been fixed in a
later version of Python. Or that the Python developers are at least
aware of it. Are you using the version from python.org?

If you can't get a correctly-functioning version of Python, I'd
suggest using a wrapper rather than writing the loop out repeatedly,
e.g.:

def fixed(func, *args, **kwargs):
while True:
try:
return func(*args, **kwargs)
except IOError:
pass

def fix(func):
def f(*args, **kwargs):
return fixed(func, *args, **kwargs)
return f

Then you can use e.g.:

read = fix(read)

to create a fixed version of the function. Similarly for methods:

MyType.my_method = fix(MyType.my_method)

Or you can wrap individual calls, replacing "func(...)" with
"fixed(func, ...)".

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

Re: [GRASS-dev] diglib test.c fails on 64bit win

2010-05-15 Thread Glynn Clements


Markus Metz wrote:

> >> To avoid confusion, on MINGW32 it would be better to not use
> >> _FILE_OFFSET_BITS=64 and don't set USE_LARGEFILES and HAVE_LARGEFILES
> >> even if LFS is requested? Unset/undefine somewhere in configure.in or
> >> a bit later in config.h.in USE_LARGEFILES and HAVE_LARGEFILES for
> >> MINGW32?
> >
> > How about:
> >
> >  if test $ac_cv_largefiles = yes; then
> >        USE_LARGEFILES=1
> > +       if test "$MINGW32" = yes ; then
> > +               AC_MSG_ERROR([*** --enable-largefile doesn't work on 
> > Windows])
> > +       fi
> >  fi
> 
> I dunnknonothin about AC_MSG_ERROR,

It prints the specified message then aborts the configure script.

> so I would do
> 
> >  if test $ac_cv_largefiles = yes; then
> >USE_LARGEFILES=1
> > +   if test "$MINGW32" = yes ; then
> > +USE_LARGEFILES=0
> > +   fi
> >  fi

This *silently* disables LFS. I would prefer to tell the user that LFS
isn't available.

> but that is your turf, you can judge what is portable. I guess, in the
> near future, MINGW64 will become more popular which is IMHO good and
> grass should consider this build environment.

I wouldn't assume that Win64 will be any different with regard to LFS. 
Apart from anything else, "long" is still only 32 bits on Win64.

-- 
Glynn Clements 
___
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

2010-05-15 Thread Markus Neteler

On Sat, May 15, 2010 at 2:53 PM, Maciej Sieczka  wrote:
> W dniu 15.05.2010 12:40, Maciej Sieczka pisze:
>
>> @Markus, Paul:
>>
>> How do you actually do such updates like [3]?
>>
>>
>> [3]http://trac.osgeo.org/grass/changeset?old_path=grass%2Ftrunk%2Flib%2Fproj&old=41451&new_path=grass%2Ftrunk%2Flib%2Fproj&new=41452
>
> OK now, so this was actually a revert of a massive update which broke
> things.

Right - personally, I find it to be a major problem that we are out of
synch with GDAL now.

> Anyway, my point is that gcs.csv as it is now in all GRASS SVN branches
> lacks towgs84 definition for Pulkovo 1942(58) datum, which results in
> locations created from EPSG codes [4] lacking it too. The towgs84 should
> be as in [5].
>
> @Markus, Paul
>
> Do I simply modify gcs.csv alone or should this be a somewhat bigger change?

I have no idea, sorry. If you manage to generate a working patch it
will be hopefully
possible to include it in GRASS.

Markus

> Maciek
>
> [4]3120 2172 2173 2174 2175  3334 3335 3329 3330 3331 3332 3328 4179
> [5]33.4,-146.6,-76.3,-0.359,-0.053,0.844,-0.84
>
> --
> Maciej Sieczka
> http://www.sieczka.org
>
___
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

2010-05-15 Thread Maciej Sieczka


W dniu 15.05.2010 12:40, Maciej Sieczka pisze:


@Markus, Paul:

How do you actually do such updates like [3]?

[3]http://trac.osgeo.org/grass/changeset?old_path=grass%2Ftrunk%2Flib%2Fproj&old=41451&new_path=grass%2Ftrunk%2Flib%2Fproj&new=41452


OK now, so this was actually a revert of a massive update which broke
things.

Anyway, my point is that gcs.csv as it is now in all GRASS SVN branches
lacks towgs84 definition for Pulkovo 1942(58) datum, which results in
locations created from EPSG codes [4] lacking it too. The towgs84 should
be as in [5].

@Markus, Paul

Do I simply modify gcs.csv alone or should this be a somewhat bigger change?

Maciek

[4]3120 2172 2173 2174 2175  3334 3335 3329 3330 3331 3332 3328 4179
[5]33.4,-146.6,-76.3,-0.359,-0.053,0.844,-0.84

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

[GRASS-dev] Re: [GRASS GIS] #1051: wxgui: SEARCH_PATH corruption

2010-05-15 Thread GRASS GIS

#1051: wxgui: SEARCH_PATH corruption
---+
  Reporter:  msieczka  |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect|  Status:  new  
  Priority:  critical  |   Milestone:  6.4.0
 Component:  wxGUI | Version:  svn-releasebranch64  
Resolution:|Keywords:   
  Platform:  All   | Cpu:  All  
---+
Changes (by msieczka):

  * priority:  major => critical

-- 
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] #1068: unnecessary error information at GRASS startup

2010-05-15 Thread GRASS GIS

#1068: unnecessary error information at GRASS startup
---+
  Reporter:  msieczka  |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect|  Status:  new  
  Priority:  minor |   Milestone:  6.4.0
 Component:  default   | Version:  svn-releasebranch64  
Resolution:|Keywords:   
  Platform:  All   | Cpu:  All  
---+
Changes (by msieczka):

  * component:  wxGUI => default

Comment:

 > Why? It's kind of error...

 I don't think so.

 1. Remove or rename a location using the button at wxGUI startup.

 2. Quit.

 3. Start GRASS back - and it goes:

 {{{
 Starting GRASS ...
 BŁĄD:MAPSET ula nie został znaleziony
 ERROR: Location  not found
 ERROR: Mapset  not found
 }}}

 or e.g.:

 {{{
 access: No such file or directory
 ERROR: LOCATION << /home/grassdata/newLocation2 >> not available
 }}}

 It is not an error for the location or mapset to be no longer available
 under the last path GRASS remembered. IMO startup procedure should handle
 this normally. If it can't - OK, too bad. Though I still would say this is
 weird.

 >> This is scarry.

 > Really? ;-)

 No, actually it's "scary" :).

 Seriously, I really mean the user might be at least surprised with GRASS
 telling him it is an error that the location/mapset does not longer exist,
 while he removed/changed it's name using a regular GRASS tool.

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

2010-05-15 Thread Maciej Sieczka


Hi,

Before a release, GRASS CRS support files need an update, per bugs 
"ETRS89-based CRSs missing datum definition?" [1] and "lacking towgs84 
for Pulkovo 1942(58), Poland".


@Markus, Paul:

How do you actually do such updates like [3]?

[1]http://trac.osgeo.org/proj/ticket/11
[2]http://trac.osgeo.org/gdal/ticket/3579
[3]http://trac.osgeo.org/grass/changeset?old_path=grass%2Ftrunk%2Flib%2Fproj&old=41451&new_path=grass%2Ftrunk%2Flib%2Fproj&new=41452
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: [GRASS GIS] #1069: wxGUI: don't let rename, remove PERMANENT mapset

2010-05-15 Thread GRASS GIS

#1069: wxGUI: don't let rename, remove PERMANENT mapset
---+
  Reporter:  msieczka  |   Owner:  martinl
  Type:  defect|  Status:  assigned   
  Priority:  critical  |   Milestone:  6.4.0  
 Component:  wxGUI | Version:  svn-releasebranch64
Resolution:|Keywords: 
  Platform:  All   | Cpu:  All
---+
Changes (by martinl):

 * cc: grass-dev@lists.osgeo.org (added)
  * owner:  grass-dev@lists.osgeo.org => martinl
  * status:  new => assigned

Comment:

 Hopefully fixed in r42254

-- 
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] #1068: unnecessary error information at GRASS startup

2010-05-15 Thread GRASS GIS

#1068: unnecessary error information at GRASS startup
---+
  Reporter:  msieczka  |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect|  Status:  new  
  Priority:  minor |   Milestone:  6.4.0
 Component:  wxGUI | Version:  svn-releasebranch64  
Resolution:|Keywords:   
  Platform:  All   | Cpu:  All  
---+
Changes (by martinl):

  * priority:  normal => minor

Comment:

 Replying to [ticket:1068 msieczka]:
 > Don't issue an error when a location or mapset is no longer available at
 startup, like:

 Why? It's kind of error...

 {{{
 > Starting GRASS ...
 > BŁĄD:MAPSET ula nie został znaleziony
 > ERROR: Location  not found
 > ERROR: Mapset  not found
 }}}
 >
 > This is scarry.

 Really? ;-)

 Well, this "message" doesn't seems to me to be a "defect"...

-- 
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] #1069: wxGUI: don't let rename, remove PERMANENT mapset

2010-05-15 Thread GRASS GIS

#1069: wxGUI: don't let rename, remove PERMANENT mapset
---+
  Reporter:  msieczka  |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect|  Status:  new  
  Priority:  critical  |   Milestone:  6.4.0
 Component:  wxGUI | Version:  svn-releasebranch64  
Resolution:|Keywords:   
  Platform:  All   | Cpu:  All  
---+
Comment (by msieczka):

 I mean the mapset rename, remove, etc. tool at wxGUI startup.

-- 
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] #1069: wxGUI: don't let rename, remove PERMANENT mapset

2010-05-15 Thread GRASS GIS

#1069: wxGUI: don't let rename, remove PERMANENT mapset
--+-
 Reporter:  msieczka  |   Owner:  grass-dev@lists.osgeo.org
 Type:  defect|  Status:  new  
 Priority:  critical  |   Milestone:  6.4.0
Component:  wxGUI | Version:  svn-releasebranch64  
 Keywords:|Platform:  All  
  Cpu:  All   |  
--+-
 Don't let rename, remove PERMANENT mapset. Issue an error to the user
 instead.

-- 
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] #1068: unnecessary error information at GRASS startup

2010-05-15 Thread GRASS GIS

#1068: unnecessary error information at GRASS startup
--+-
 Reporter:  msieczka  |   Owner:  grass-dev@lists.osgeo.org
 Type:  defect|  Status:  new  
 Priority:  normal|   Milestone:  6.4.0
Component:  wxGUI | Version:  svn-releasebranch64  
 Keywords:|Platform:  All  
  Cpu:  All   |  
--+-
 Don't issue an error when a location or mapset is no longer available at
 startup, like:

 {{{
 Starting GRASS ...
 BŁĄD:MAPSET ula nie został znaleziony
 ERROR: Location  not found
 ERROR: Mapset  not found
 }}}

 This is scarry.

-- 
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] #1050: wxgui: `Rename mapset' does not work in Polish locale

2010-05-15 Thread GRASS GIS

#1050: wxgui: `Rename mapset' does not work in Polish locale
---+
  Reporter:  msieczka  |   Owner:  martinl
  Type:  defect|  Status:  closed 
  Priority:  normal|   Milestone:  6.4.0  
 Component:  wxGUI | Version:  svn-releasebranch64
Resolution:  fixed |Keywords:  welcome screen 
  Platform:  All   | Cpu:  All
---+
Changes (by msieczka):

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

Comment:

 Replying to [comment:1 martinl]:
 > Hopefully fixed in r42133

 Indeed. Thanks.

-- 
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] #1037: v.random inconsequence between interface and source

[GRASS-dev] Re: [GRASS GIS] #946: Opening Properties Dialog in Layer Manager gives error

[GRASS-dev] Re: [GRASS GIS] #582: import of multiple rasters does not do anything

[GRASS-dev] Re: [GRASS GIS] #1032: ErrorCommandExecution g.proj

[GRASS-dev] Re: [GRASS GIS] #1051: wxgui: SEARCH_PATH corruption

Re: [GRASS-dev] Re: python scripts and standard input

Re: [GRASS-dev] diglib test.c fails on 64bit win

Re: [GRASS-dev] 6.4.0 blocker bugs

Re: [GRASS-dev] 6.4.0 blocker bugs

[GRASS-dev] Re: [GRASS GIS] #1051: wxgui: SEARCH_PATH corruption

[GRASS-dev] Re: [GRASS GIS] #1068: unnecessary error information at GRASS startup

Re: [GRASS-dev] 6.4.0 blocker bugs

[GRASS-dev] Re: [GRASS GIS] #1069: wxGUI: don't let rename, remove PERMANENT mapset

[GRASS-dev] Re: [GRASS GIS] #1068: unnecessary error information at GRASS startup

[GRASS-dev] Re: [GRASS GIS] #1069: wxGUI: don't let rename, remove PERMANENT mapset

[GRASS-dev] [GRASS GIS] #1069: wxGUI: don't let rename, remove PERMANENT mapset

[GRASS-dev] [GRASS GIS] #1068: unnecessary error information at GRASS startup

[GRASS-dev] Re: [GRASS GIS] #1050: wxgui: `Rename mapset' does not work in Polish locale

18 matches

Site Navigation

Mail list logo

Footer information