Re: [GRASS-dev] GRASS 7 compile error

[William Kyngesburye]

ah, a new wx module that needs the arch stripping on OSX.

fixed in r40523.

On Jan 17, 2010, at 8:58 PM, Michael Barton wrote:

> I am hitting another compiler error in the visualization section of GRASS 7. 
> Previous errors were fixed. This is new in the past week or two.
> 
> cmb-MBP-2:grass70_dev cmbarton$ cd  
> /Users/cmbarton/grass_dev/grass70_dev/visualization/wximgview
> cmb-MBP-2:wximgview cmbarton$ make
> c++ -L/Users/cmbarton/grass_dev/grass70_dev/dist.i386-apple-darwin10.2.0/lib 
> -L/Users/cmbarton/grass_dev/grass70_dev/dist.i386-apple-darwin10.2.0/lib 
> -arch i386 -arch x86_64 -o 
> /Users/cmbarton/grass_dev/grass70_dev/dist.i386-apple-darwin10.2.0/bin/wximgview
>  OBJ.i386-apple-darwin10.2.0/main.o  -lgrass_raster -lgrass_gis 
> -L/usr/local/lib/wxPython-unicode-2.8.10.1/lib   -framework IOKit -framework 
> Carbon -framework Cocoa -framework System -framework QuickTime -framework 
> OpenGL -framework AGL  -lwx_macud-2.8
> ld: warning: in /System/Library/Frameworks//QuickTime.framework/QuickTime, 
> missing required architecture x86_64 in file
> ld: warning: in 
> /usr/local/lib/wxPython-unicode-2.8.10.1/lib/libwx_macud-2.8.dylib, missing 
> required architecture x86_64 in file
> Undefined symbols for architecture x86_64:
>  "wxWindowBase::DoSetVirtualSize(int, int)", referenced from:
>  vtable for MyFramein main.o
>  "wxTopLevelWindowMac::RequestUserAttention(int)", referenced from:
>  vtable for MyFramein main.o
>  "wxTopLevelWindowMac::Restore()", referenced from:
>  vtable for MyFramein main.o
>  "_wxDefaultPosition", referenced from:
>  MyFrame::MyFrame(wxSize const&)in main.o
>  "wxWindowBase::DoGetVirtualSize() const", referenced from:
>  vtable for MyFramein main.o
>  "wxFrameBase::UpdateWindowUI(long)", referenced from:
>  vtable for MyFramein main.o
>  "wxFrameBase::IsOneOfBars(wxWindow const*) const", referenced from:
>  vtable for MyFramein main.o
>  "wxWindowBase::InitDialog()", referenced from:
>  vtable for MyFramein main.o
>  "wxWindow::MacVisibilityChanged()", referenced from:
>  vtable for MyFramein main.o
>  "wxWindow::MacEnabledStateChanged()", referenced from:
>  vtable for MyFramein main.o
>  "wxWindow::GetScrollRange(int) const", referenced from:
>  vtable for MyFramein main.o
>  "wxFrame::PositionToolBar()", referenced from:
>  vtable for MyFramein main.o
>  "wxTopLevelWindowMac::IsIconized() const", referenced from:
>  vtable for MyFramein main.o
>  "wxEvtHandler::DoGetClientData() const", referenced from:
>  vtable for MyAppin main.o
>  vtable for MyFramein main.o
>  "wxFrame::Create(wxWindow*, int, wxString const&, wxPoint const&, wxSize 
> const&, long, wxString const&)", referenced from:
>  wxFrame::wxFrame(wxWindow*, int, wxString const&, wxPoint const&, wxSize 
> const&, long, wxString const&)in main.o
>  "wxImage::SetRGB(int, int, unsigned char, unsigned char, unsigned char)", 
> referenced from:
>  MyFrame::draw() in main.o
>  "wxWindow::DoSetSize(int, int, int, int, int)", referenced from:
>  vtable for MyFramein main.o
>  "wxApp::wxApp()", referenced from:
>  MyApp::MyApp() in main.o
>  "wxAppBase::OnInitCmdLine(wxCmdLineParser&)", referenced from:
>  vtable for MyAppin main.o
>  "wxObject::Ref(wxObject const&)", referenced from:
>  wxObject::operator=(wxObject const&)in main.o
>  "wxWindow::Reparent(wxWindowBase*)", referenced from:
>  vtable for MyFramein main.o
>  "wxTopLevelWindowMac::CanSetTransparent()", referenced from:
>  vtable for MyFramein main.o
>  "wxAppConsole::OnCmdLineError(wxCmdLineParser&)", referenced from:
>  vtable for MyAppin main.o
>  "wxAppBase::SendIdleEvents(wxWindow*, wxIdleEvent&)", referenced from:
>  vtable for MyAppin main.o
>  "wxTopLevelWindowMac::MacCreateRealWindow(wxString const&, wxPoint const&, 
> wxSize const&, long, wxString const&)", referenced from:
>  vtable for MyFramein main.o
>  "wxWindowBase::InheritAttributes()", referenced from:
>  vtable for MyFramein main.o
>  "wxTopLevelWindowMac::Destroy()", referenced from:
>  vtable for MyFramein main.o
>  "wxWindowBase::SetConstraintSizes(bool)", referenced from:
>  vtable for MyFramein main.o
>  "wxWindowBase::DoIsExposed(int, int, int, int) const", referenced from:
>  vtable for MyFramein main.o
>  "wxWindow::GetHandle() const", referenced from:
>  vtable for MyFramein main.o
>  "wxEventHashTable::wxEventHashTable(wxEventTable const&)", referenced from:
>  __static_initialization_and_destruction_0(int, int)in main.o
>  "wxBitmap::wxBitmap(wxImage const&, int)", referenced from:
>  MyFrame::draw() in main.o
>  "_wxEVT_TIMER", referenced from:
>  wxTimerEvent::wxTimerEvent(int, int)in main.o
>  __static_initialization_and_destruction_0(int, int)in main.o
>  "wxEvtHandler::DoGetClientObject() const", referenced from:
>  vtable for MyAppin main.o
>  vtable for MyFramein main.o
>  "wxAppConsole::ProcessPendin

[GRASS-dev] Re: [GRASS GIS] #877: wxGUI: Location wizard bug when creating LatLong location

[GRASS GIS]

#877: wxGUI: Location wizard bug when creating LatLong location
--+-
  Reporter:  neteler  |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect   |  Status:  new  
  Priority:  blocker  |   Milestone:  6.4.0
 Component:  wxGUI| Version:  svn-releasebranch64  
Resolution:   |Keywords:  location wizard, wingrass
  Platform:  MSWindows Vista  | Cpu:  Unspecified  
--+-
Comment (by cmbarton):

 OK. I'll take a look at the code with that in mind. I won't be able to
 test, but maybe I can see something

-- 
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] #877: wxGUI: Location wizard bug when creating LatLong location

[GRASS GIS]

#877: wxGUI: Location wizard bug when creating LatLong location
--+-
  Reporter:  neteler  |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect   |  Status:  new  
  Priority:  blocker  |   Milestone:  6.4.0
 Component:  wxGUI| Version:  svn-releasebranch64  
Resolution:   |Keywords:  location wizard, wingrass
  Platform:  MSWindows Vista  | Cpu:  Unspecified  
--+-
Changes (by hamish):

  * keywords:  location wizard => location wizard, wingrass

-- 
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] #877: wxGUI: Location wizard bug when creating LatLong location

[GRASS GIS]

#877: wxGUI: Location wizard bug when creating LatLong location
--+-
  Reporter:  neteler  |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect   |  Status:  new  
  Priority:  blocker  |   Milestone:  6.4.0
 Component:  wxGUI| Version:  svn-releasebranch64  
Resolution:   |Keywords:  location wizard  
  Platform:  MSWindows Vista  | Cpu:  Unspecified  
--+-
Comment (by neteler):

 It is a Windows-only bug.

 Markus

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

[GRASS-dev] GRASS 7 compile error

[Michael Barton]

I am hitting another compiler error in the visualization section of GRASS 7. 
Previous errors were fixed. This is new in the past week or two.

cmb-MBP-2:grass70_dev cmbarton$ cd  
/Users/cmbarton/grass_dev/grass70_dev/visualization/wximgview
cmb-MBP-2:wximgview cmbarton$ make
c++ -L/Users/cmbarton/grass_dev/grass70_dev/dist.i386-apple-darwin10.2.0/lib 
-L/Users/cmbarton/grass_dev/grass70_dev/dist.i386-apple-darwin10.2.0/lib -arch 
i386 -arch x86_64 -o 
/Users/cmbarton/grass_dev/grass70_dev/dist.i386-apple-darwin10.2.0/bin/wximgview
 OBJ.i386-apple-darwin10.2.0/main.o  -lgrass_raster -lgrass_gis 
-L/usr/local/lib/wxPython-unicode-2.8.10.1/lib   -framework IOKit -framework 
Carbon -framework Cocoa -framework System -framework QuickTime -framework 
OpenGL -framework AGL  -lwx_macud-2.8
ld: warning: in /System/Library/Frameworks//QuickTime.framework/QuickTime, 
missing required architecture x86_64 in file
ld: warning: in 
/usr/local/lib/wxPython-unicode-2.8.10.1/lib/libwx_macud-2.8.dylib, missing 
required architecture x86_64 in file
Undefined symbols for architecture x86_64:
  "wxWindowBase::DoSetVirtualSize(int, int)", referenced from:
  vtable for MyFramein main.o
  "wxTopLevelWindowMac::RequestUserAttention(int)", referenced from:
  vtable for MyFramein main.o
  "wxTopLevelWindowMac::Restore()", referenced from:
  vtable for MyFramein main.o
  "_wxDefaultPosition", referenced from:
  MyFrame::MyFrame(wxSize const&)in main.o
  "wxWindowBase::DoGetVirtualSize() const", referenced from:
  vtable for MyFramein main.o
  "wxFrameBase::UpdateWindowUI(long)", referenced from:
  vtable for MyFramein main.o
  "wxFrameBase::IsOneOfBars(wxWindow const*) const", referenced from:
  vtable for MyFramein main.o
  "wxWindowBase::InitDialog()", referenced from:
  vtable for MyFramein main.o
  "wxWindow::MacVisibilityChanged()", referenced from:
  vtable for MyFramein main.o
  "wxWindow::MacEnabledStateChanged()", referenced from:
  vtable for MyFramein main.o
  "wxWindow::GetScrollRange(int) const", referenced from:
  vtable for MyFramein main.o
  "wxFrame::PositionToolBar()", referenced from:
  vtable for MyFramein main.o
  "wxTopLevelWindowMac::IsIconized() const", referenced from:
  vtable for MyFramein main.o
  "wxEvtHandler::DoGetClientData() const", referenced from:
  vtable for MyAppin main.o
  vtable for MyFramein main.o
  "wxFrame::Create(wxWindow*, int, wxString const&, wxPoint const&, wxSize 
const&, long, wxString const&)", referenced from:
  wxFrame::wxFrame(wxWindow*, int, wxString const&, wxPoint const&, wxSize 
const&, long, wxString const&)in main.o
  "wxImage::SetRGB(int, int, unsigned char, unsigned char, unsigned char)", 
referenced from:
  MyFrame::draw() in main.o
  "wxWindow::DoSetSize(int, int, int, int, int)", referenced from:
  vtable for MyFramein main.o
  "wxApp::wxApp()", referenced from:
  MyApp::MyApp() in main.o
  "wxAppBase::OnInitCmdLine(wxCmdLineParser&)", referenced from:
  vtable for MyAppin main.o
  "wxObject::Ref(wxObject const&)", referenced from:
  wxObject::operator=(wxObject const&)in main.o
  "wxWindow::Reparent(wxWindowBase*)", referenced from:
  vtable for MyFramein main.o
  "wxTopLevelWindowMac::CanSetTransparent()", referenced from:
  vtable for MyFramein main.o
  "wxAppConsole::OnCmdLineError(wxCmdLineParser&)", referenced from:
  vtable for MyAppin main.o
  "wxAppBase::SendIdleEvents(wxWindow*, wxIdleEvent&)", referenced from:
  vtable for MyAppin main.o
  "wxTopLevelWindowMac::MacCreateRealWindow(wxString const&, wxPoint const&, 
wxSize const&, long, wxString const&)", referenced from:
  vtable for MyFramein main.o
  "wxWindowBase::InheritAttributes()", referenced from:
  vtable for MyFramein main.o
  "wxTopLevelWindowMac::Destroy()", referenced from:
  vtable for MyFramein main.o
  "wxWindowBase::SetConstraintSizes(bool)", referenced from:
  vtable for MyFramein main.o
  "wxWindowBase::DoIsExposed(int, int, int, int) const", referenced from:
  vtable for MyFramein main.o
  "wxWindow::GetHandle() const", referenced from:
  vtable for MyFramein main.o
  "wxEventHashTable::wxEventHashTable(wxEventTable const&)", referenced from:
  __static_initialization_and_destruction_0(int, int)in main.o
  "wxBitmap::wxBitmap(wxImage const&, int)", referenced from:
  MyFrame::draw() in main.o
  "_wxEVT_TIMER", referenced from:
  wxTimerEvent::wxTimerEvent(int, int)in main.o
  __static_initialization_and_destruction_0(int, int)in main.o
  "wxEvtHandler::DoGetClientObject() const", referenced from:
  vtable for MyAppin main.o
  vtable for MyFramein main.o
  "wxAppConsole::ProcessPendingEvents()", referenced from:
  vtable for MyAppin main.o
  "wxWindowBase::FindFocus()", referenced from:
  wxTopLevelWindowBase::IsActive()  in main.o
  "wxApp::MacHandleAEODoc(void*, void*)", referenced from:
  vtable for MyAppin ma

[GRASS-dev] Re: [GRASS GIS] #806: WinGRASS: Problem with special characters (wxpython GUI)

[GRASS GIS]

#806: WinGRASS: Problem with special characters (wxpython GUI)
---+
  Reporter:  marmai|   Owner:  grass-dev@lists.osgeo.org  
  Type:  defect|  Status:  reopened   
  Priority:  major |   Milestone:  6.4.0  
 Component:  wxGUI | Version:  6.4.0 RCs  
Resolution:|Keywords:  wingrass,umlaut charcter,german
  Platform:  MSWindows XP  | Cpu:  Unspecified
---+
Comment (by hamish):

 fwiw I see a "ü" in the $Date$ stamp of the AUTHORS file from the
 Help->About tab in the latest wingrass 6.4.0svn binary (r40456) on XP.
 (Presumably because this is due to the packager's locale.)


 Hamish

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

Re: [GRASS-dev] grass is a monad?

[Glynn Clements]

Radim Blazek wrote:

> > This too is Not A Bug. Not isolating distinct operations in distinct
> > processes *is* a bug.
> 
> I can imagine almost everything done via GRASS modules. Yes, it is
> annoying to run a GRASS module (probably I have to write a new one to
> be sure, that the output/options do not change in next minor GRASS
> release)

Even if you use an existing module, the module interface is less
likely to change than a library function. Certainly, the changes to
the modules between 6.x and 7.0 are quite minor compared to the
changes to many library functions (e.g. half of G_* being renamed to
Rast_*, R_* disappearing, ...).

> and to parse output instead of just calling a function. You
> did your work well, you made our life harder.
> 
> Everything except vector editing. I don't see any reasonable
> possibility to do interactive vector editing via a GRASS module. For
> vector editing, I need immediate response which is visualized on
> display (e.g. if a vertex was moved and area topology was broken it
> must be displayed). It is impossible to open/close a vector for every
> single operation, it would take too long time for larger vectors.

For this specific case, is it possible to isolate a subset of the
vector library such that it can be used reasonably by both GRASS and
QGIS (and the wxGUI's vdigit module, which is just as bad in this
regard)?

Also, what kind of fatal errors can occur while in the middle of
vector editing that could reasonably be recovered from?

I'm not particularly averse to libraries using status returns, so long
as this doesn't:

1. propagate up to the API used by modules,
2. "infest" a large portion of the GRASS libraries, or
3. mean that fatal errors end up being signalled at the highest levels
after most of the context has been lost.

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

Re: [GRASS-dev] Re: [GRASS-user] 6.4 vs 7.0

[Glynn Clements]

Paolo Craveri wrote:

> > If you use "
> > GRASS_OVERWRITE=1 \
> >  r.mapcalc "result = map * 4
> > it will work on both versions.
> 
> In grass 6.4:
> GRASS_OVERWRITE=1
> 
> r.mapcalc "result = rand(1,100)"
> 
> 100%
> 
> r.mapcalc "result = rand(1,200)"
>  ##ok, raster result has been overwritten
>  100%
> 
> 
> In grass7.0:
> GRASS_OVERWRITE=1
> 
> r.mapcalc "result = rand(1,100)"
> 
>  100%
> 
> r.mapcalc  "result = rand(1,200)"
> ###  raster 'result' hasn't been overwritten
> 
> I have to setting GRASS_OVERWRITE variable and r.mapcalc command in
> the same line as you suggest:
> GRASS_OVERWRITE=1 r.mapcalc "r = rand(12,24)"
> in this case it works in both version.  Strange behaviour IMHO.

This indicates a difference in the state of the shell between the two
cases, not a difference in GRASS.

Entering "GRASS_OVERWRITE=1" as a command sets the shell variable
GRASS_OVERWRITE. It doesn't necessarily cause it to be "exported" to
the environment used for child processes.

If the command "export GRASS_OVERWRITE" has been executed in the
current shell, the variable has been exported to the environment, and
any changes to the variable will affect the environment used for child
processes.

OTOH, the command "GRASS_OVERWRITE=1 r.mapcalc ..." executes r.mapcalc
with GRASS_OVERWRITE=1 in the environment for that specific process.

See the "bash" manual page for more information.

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

[GRASS-dev] Re: [GRASS GIS] #813: Location wizard - false path to the epsg-file

[GRASS GIS]

#813: Location wizard - false path to the epsg-file
--+-
  Reporter:  hellik   |   Owner:  grass-dev@lists.osgeo.org 
  
  Type:  defect   |  Status:  new   
  
  Priority:  normal   |   Milestone:  6.4.0 
  
 Component:  wxGUI| Version:  svn-releasebranch64   
  
Resolution:   |Keywords:  location wizard, path to 
EPSG-file, wingrass
  Platform:  MSWindows Vista  | Cpu:  Unspecified   
  
--+-
Changes (by hamish):

  * keywords:  location wizard, path to EPSG-file => location wizard, path
   to EPSG-file, wingrass

-- 
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] #877: wxGUI: Location wizard bug when creating LatLong location

[GRASS GIS]

#877: wxGUI: Location wizard bug when creating LatLong location
--+-
  Reporter:  neteler  |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect   |  Status:  new  
  Priority:  blocker  |   Milestone:  6.4.0
 Component:  wxGUI| Version:  svn-releasebranch64  
Resolution:   |Keywords:  location wizard  
  Platform:  MSWindows Vista  | Cpu:  Unspecified  
--+-
Comment (by cmbarton):

 Is it happening on Linux too, or only on Windows? It's not happening on
 the Mac.

 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] Re: [GRASS-user] 6.4 vs 7.0

[Glynn Clements]

Hamish wrote:

> > That's not good for the GUI, where the module won't have a
> > stdin (ideally, it will have been closed; if not, the module
> > will hang, waiting to read from whatever its stdin happens
> > to be).
> 
> does isatty(0) work on ms windows?

Yes. But only the Windows console is a TTY, MSys' rxvt isn't (which is
why e.g. tclsh and python don't work as expected there).

Windows doesn't appear to have anything similar to ptys.

> does it work from a pipe?

A pipe isn't considered a TTY on any platform.

isatty() is frequently misused. It can be a useful heuristic to
determine whether the program is being run interactively, but (as with
most heuristics), there should be a way for the user to override it.

The only situation where behaviour should depend solely upon the
result of isatty() is if you need to rely upon TTY-specific
functionality, e.g. tcsettattr().

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

[GRASS-dev] Re: [GRASS GIS] #877: wxGUI: Location wizard bug when creating LatLong location

[GRASS GIS]

#877: wxGUI: Location wizard bug when creating LatLong location
--+-
  Reporter:  neteler  |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect   |  Status:  new  
  Priority:  blocker  |   Milestone:  6.4.0
 Component:  wxGUI| Version:  svn-releasebranch64  
Resolution:   |Keywords:  location wizard  
  Platform:  MSWindows Vista  | Cpu:  Unspecified  
--+-
Comment (by neteler):

 Yes, I used the winGRASS package from the GRASS web site. The same was
 also confirmed by at least two other people (see mailing list). How can I
 debug this?

 Markus

-- 
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] #877: wxGUI: Location wizard bug when creating LatLong location

[GRASS GIS]

#877: wxGUI: Location wizard bug when creating LatLong location
--+-
  Reporter:  neteler  |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect   |  Status:  new  
  Priority:  blocker  |   Milestone:  6.4.0
 Component:  wxGUI| Version:  svn-releasebranch64  
Resolution:   |Keywords:  location wizard  
  Platform:  MSWindows Vista  | Cpu:  Unspecified  
--+-
Comment (by cmbarton):

 I just tried this and it works fine for me. No error if I duplicate your
 steps. You are doing this in 6.4 release branch right?

 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] WinGrass-Installer - definition of the destination folder?

[Glynn Clements]

Hamish wrote:

> > Grass64-Release => %ProgramFiles%\GRASS-64
> > Grass64-Dev => %ProgramFiles%\GRASS-64-SVN
> ...
> > We *need* this to work. If GRASS can't handle being
> > installed in %ProgramFiles%, that's a blocker, IMHO.
> 
> 
> It could be that this is a 6.4.0-final blocker, but //please// let's
> hold off on r40496 and release 6.4.0rc6 before beginning to validate
> that $GISBASE is space-safe.

If not now, then when? We need at least one RC which installs into
%ProgramFiles% by default. If that isn't RC6, then we will need an RC7
even if RC6 appears to work perfectly, and if it turns out that there
*are* problems with RC7, then we would need an RC8 to test the fixes.

> AFAIK there are no more major RC-blockers left & we are ready to go
> for rc6 -right now-.

Fine. Then release RC6 -right now-, with the default installation
directory as %ProgramFiles%\GRASS-64-RC6.

> If we start on the next thing it's going to be
> another 3 weeks+ before we can even think about shipping rc6. !...@$%!#
> It resets the release confidence cycle.

At the risk of stating the obvious, a "release candidate" (as opposed
to a "beta") is ... a candidate for release. If no bugs are found,
then the RC gets released as the "release", with the only change being
that it's called "6.4.0" rather than "6.4.0-RC".

If you know for a fact that the "RC" won't actually become the
release, even if no (significant) bugs are found, then it *isn't* a
"release candidate".

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

[GRASS-dev] Re: [GRASS GIS] #878: v.external not working on WinGrass

[GRASS GIS]

#878: v.external not working on WinGrass
--+-
  Reporter:  hellik   |   Owner:  grass-dev@lists.osgeo.org  
  Type:  defect   |  Status:  new
  Priority:  critical |   Milestone:  6.4.0  
 Component:  Vector   | Version:  svn-releasebranch64
Resolution:   |Keywords:  v.external, vector, windows
  Platform:  MSWindows Vista  | Cpu:  x86-32 
--+-
Comment (by neteler):

 You need to specify also the layer:

 {{{
 v.external dsn=C:\temp\ncdata\exporthospital.shp output=testvexternal
 layer=exporthospital
 }}}

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

Re: [GRASS-dev] win installer

[Michael Barton]

I agree 1 for me too.


Michael

On Jan 16, 2010, at 4:12 PM, grass-dev-requ...@lists.osgeo.org wrote:

> Date: Sat, 16 Jan 2010 19:19:59 +0100
> From: Helmut Kudrnovsky 
> Subject: [GRASS-dev] win installer
> To: grass-dev@lists.osgeo.org
> Message-ID:
><9968735.55862.1263665999837.javamail.fm...@fmcert02.dlan.cinetic.de>
> Content-Type: text/plain; charset="iso-8859-15"
> 
>> Hi,
>> 
>> I would suggest to move 'mswindows/README.html' from svn to trac wiki.
>> If no objections I will do it.
>> 
>> Martin
> 
> +1
> 
> Helmut

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

[GRASS-dev] Re: [GRASS GIS] #878: v.external not working on WinGrass

[GRASS GIS]

#878: v.external not working on WinGrass
--+-
  Reporter:  hellik   |   Owner:  grass-dev@lists.osgeo.org  
  Type:  defect   |  Status:  new
  Priority:  critical |   Milestone:  6.4.0  
 Component:  Vector   | Version:  svn-releasebranch64
Resolution:   |Keywords:  v.external, vector, windows
  Platform:  MSWindows Vista  | Cpu:  x86-32 
--+-
Comment (by hellik):

 Replying to [ticket:878 hellik]:
 > WinGrass r40456 on WinVista32
 >

 tested within the nc-sample-dataset

 {{{
 v.out.ogr input=hospit...@permanent type=point dsn=C:\temp\ncdata
 olayer=exporthospital
 Exportiere 160 Punkte/Linien...
 160 Feature geschrieben.
 }}}

 {{{
 ogrinfo:
 INFO: Open of `exporthospital.shp'
   using driver `ESRI Shapefile' successful.
 Layer name: exporthospital
 Geometry: Point
 Feature Count: 160
 Extent: (156998.171862, 20235.564401) - (914347.874861, 308097.937401)
 Layer SRS WKT:
 PROJCS["Lambert Conformal Conic",
 GEOGCS["grs80",
 DATUM["North_American_Datum_1983",
 SPHEROID["Geodetic_Reference_System_1980",6378137,298.257222101]],
 PRIMEM["Greenwich",0],
 UNIT["Degree",0.017453292519943295]],
 PROJECTION["Lambert_Conformal_Conic_2SP"],
 PARAMETER["standard_parallel_1",36.16],
 PARAMETER["standard_parallel_2",34.34],
 PARAMETER["latitude_of_origin",33.75],
 PARAMETER["central_meridian",-79],
 PARAMETER["false_easting",609601.22],
 PARAMETER["false_northing",0],
 UNIT["Meter",1]]
 }}}

 {{{
 v.external dsn=C:\temp\ncdata\exporthospital.shp output=testvexternal
 Data source contains 1 layers:
 exporthospital
 }}}


 no testvexternal in the vect-list either any error-message of v.external

-- 
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] #813: Location wizard - false path to the epsg-file

[GRASS GIS]

#813: Location wizard - false path to the epsg-file
--+-
  Reporter:  hellik   |   Owner:  grass-dev@lists.osgeo.org 
  Type:  defect   |  Status:  new   
  Priority:  normal   |   Milestone:  6.4.0 
 Component:  wxGUI| Version:  svn-releasebranch64   
Resolution:   |Keywords:  location wizard, path to EPSG-file
  Platform:  MSWindows Vista  | Cpu:  Unspecified   
--+-
Comment (by neteler):

 Is this still valid?

-- 
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] #861: localised wx-gui - german umlaut not correctly dislpayed

[GRASS GIS]

#861: localised wx-gui - german umlaut not correctly dislpayed
--+-
  Reporter:  hellik   |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect   |  Status:  closed   
  Priority:  normal   |   Milestone:  6.4.0
 Component:  wxGUI| Version:  svn-releasebranch64  
Resolution:  duplicate|Keywords:  wx-gui, locale, german umlaut
  Platform:  MSWindows Vista  | Cpu:  x86-32   
--+-
Changes (by neteler):

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

Comment:

 duplicate of #806

-- 
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] #806: WinGRASS: Problem with special characters (wxpython GUI)

[GRASS GIS]

#806: WinGRASS: Problem with special characters (wxpython GUI)
---+
  Reporter:  marmai|   Owner:  grass-dev@lists.osgeo.org  
  Type:  defect|  Status:  reopened   
  Priority:  major |   Milestone:  6.4.0  
 Component:  wxGUI | Version:  6.4.0 RCs  
Resolution:|Keywords:  wingrass,umlaut charcter,german
  Platform:  MSWindows XP  | Cpu:  Unspecified
---+
Changes (by neteler):

  * status:  closed => reopened
  * resolution:  duplicate =>

Comment:

 oops closed wrong report, sorry

-- 
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] #806: WinGRASS: Problem with special characters (wxpython GUI)

[GRASS GIS]

#806: WinGRASS: Problem with special characters (wxpython GUI)
---+
  Reporter:  marmai|   Owner:  grass-dev@lists.osgeo.org  
  Type:  defect|  Status:  closed 
  Priority:  major |   Milestone:  6.4.0  
 Component:  wxGUI | Version:  6.4.0 RCs  
Resolution:  duplicate |Keywords:  wingrass,umlaut charcter,german
  Platform:  MSWindows XP  | Cpu:  Unspecified
---+
Changes (by neteler):

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

Comment:

 duplicate of #806

-- 
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] #878: v.external not working on WinGrass

[GRASS GIS]

#878: v.external not working on WinGrass
-+--
 Reporter:  hellik   |   Owner:  
grass-dev@lists.osgeo.org
 Type:  defect   |  Status:  new
  
 Priority:  critical |   Milestone:  6.4.0  
  
Component:  Vector   | Version:  svn-releasebranch64
  
 Keywords:  v.external, vector, windows  |Platform:  MSWindows Vista
  
  Cpu:  x86-32   |  
-+--
 WinGrass r40456 on WinVista32
 __
 creation the location with a projected dataset (10mpopulatedplaces.shp)
 data
 
[http://www.naturalearthdata.com/http//www.naturalearthdata.com/download/10m/cultural/
 10m-populated-places.zip]
 __
 => creation of the location ok
 __

 {{{
 v.in.ogr dsn=C:\temp\10m_populated_places\10mpopulatedplaces.shp
 output=import
 Die Projektionsinformationen des Eingabedatensatzes und der aktuellen
 Location scheinen übereinzustimmen.
 Layer: 10mpopulatedplaces
 Importiere 6599 Objekte der Karte...
 -
 Building topology for vector map ...
 Registering primitives...
60006599 primitives registered
 6599 vertices registered
 Building areas...
 0 areas built
 0 isles built
 Attaching islands...
 Attaching centroids...
 Number of nodes: 6599
 Number of primitives: 6599
 Number of points: 6599
 Number of lines: 0
 Number of boundaries: 0
 Number of centroids: 0
 Number of areas: 0
 Number of isles: 0
 }}}

 __
 => import ok
 __

 {{{
 v.external dsn=C:\temp\10m_populated_places\10mpopulatedplaces.shp
 output=vlinkext
 Data source contains 1 layers:
 10mpopulatedplaces
 }}}

 __
 g.list type=vect

 {{{
 --
 vector files available in mapset :
 import
 --
 }}}

 __
 => link to external not working, because there is no link, but there is
 also no error-message with v.external
 __

 {{{
 g.gisenv --v
 GISDBASE='C:/gisdata/grassdata';
 LOCATION_NAME='populatedplaces';
 MAPSET='data';
 GRASS_GUI='wxpython';
 DEBUG='3';
 }}}

 __

 {{{
 (Mon Jan 18 00:21:23 2010)
 v.external dsn=C:\temp\10m_populated_places\10mpopulatedplaces.shp
 output=vlinkext2
 Data source contains 1 layers:
 10mpopulatedplaces
 (Mon Jan 18 00:21:24 2010) Command finished (0 sec)
 }}}

 __

 {{{
 g.list type=vect
 --
 vector files available in mapset :
 import
 }}}

-- 
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] #877: wxGUI: Location wizard bug when creating LatLong location

[GRASS GIS]

#877: wxGUI: Location wizard bug when creating LatLong location
-+--
 Reporter:  neteler  |   Owner:  grass-dev@lists.osgeo.org
 Type:  defect   |  Status:  new  
 Priority:  blocker  |   Milestone:  6.4.0
Component:  wxGUI| Version:  svn-releasebranch64  
 Keywords:  location wizard  |Platform:  MSWindows Vista  
  Cpu:  Unspecified  |  
-+--
 * Launch winGRASS
  * On the right-hand side select Location Wizard under Define new location
  * Leave the GIS Data Directory field as is but choose a descriptive name
 for the Project Location
  * Continue to the next page
  * Choose Select Coordinate System parameters from a list and continue
  * Type in ll for the Projection Code (or scroll down the page to find
 Lat/Lon)
  * Continue to the next page
  * Keep "Datum with associated ellipsoid"
  * Continue to the next page: bug appears "You must enter a value for
 Central Meridian" although values are inserted

 See attached screenshot.

-- 
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] #806: WinGRASS: Problem with special characters (wxpython GUI)

[GRASS GIS]

#806: WinGRASS: Problem with special characters (wxpython GUI)
---+
  Reporter:  marmai|   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:  wingrass,umlaut charcter,german
  Platform:  MSWindows XP  | Cpu:  Unspecified
---+
Comment (by neteler):

 We have done some modifications. Please check if the problem persists in
 the latest available winGRASS version.

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

Re: [GRASS-dev] win installer

[Martin Landa]

2010/1/16 Markus Neteler :
> No objections, but please downgrade then mswindows/README.html to
> mswindows/README.txt with the URL to leave a trace.

ok, done. 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] #875: WinGrass-Installer - definition of the destination folder

[GRASS GIS]

#875: WinGrass-Installer - definition of the destination folder
--+-
  Reporter:  hellik   |   Owner:  grass-dev@lists.osgeo.org
  Type:  task |  Status:  closed   
  Priority:  normal   |   Milestone:  6.4.0
 Component:  Packaging| Version:  unspecified  
Resolution:  fixed|Keywords:  WinGrass-Installer   
  Platform:  MSWindows Vista  | Cpu:  Unspecified  
--+-
Changes (by martinl):

  * status:  new => 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] #875: WinGrass-Installer - definition of the destination folder

[GRASS GIS]

#875: WinGrass-Installer - definition of the destination folder
--+-
  Reporter:  hellik   |   Owner:  grass-dev@lists.osgeo.org
  Type:  task |  Status:  new  
  Priority:  normal   |   Milestone:  6.4.0
 Component:  Packaging| Version:  unspecified  
Resolution:   |Keywords:  WinGrass-Installer   
  Platform:  MSWindows Vista  | Cpu:  Unspecified  
--+-
Comment (by hellik):

 Replying to [comment:2 martinl]:
 > I have committed your patch to relbr64 and devbr6. The files contain
 only relevant versions, e.g. in devbr6 only 'Dev65' is included.

 ok, thanks. so the ticket should be closed? or should we wait for the next
 testing phase?

 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] #875: WinGrass-Installer - definition of the destination folder

[GRASS GIS]

#875: WinGrass-Installer - definition of the destination folder
--+-
  Reporter:  hellik   |   Owner:  grass-dev@lists.osgeo.org
  Type:  task |  Status:  new  
  Priority:  normal   |   Milestone:  6.4.0
 Component:  Packaging| Version:  unspecified  
Resolution:   |Keywords:  WinGrass-Installer   
  Platform:  MSWindows Vista  | Cpu:  Unspecified  
--+-
Changes (by martinl):

 * cc: grass-dev@lists.osgeo.org (added)

Comment:

 I have committed your patch to relbr64 and devbr6. The files contain only
 relevant versions, e.g. in devbr6 only 'Dev65' is included.

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

Re: [GRASS-dev] grass is a monad?

[Radim Blazek]

On Thu, Jan 14, 2010 at 10:35 PM, Glynn Clements
 wrote:
> This too is Not A Bug. Not isolating distinct operations in distinct
> processes *is* a bug.

I can imagine almost everything done via GRASS modules. Yes, it is
annoying to run a GRASS module (probably I have to write a new one to
be sure, that the output/options do not change in next minor GRASS
release) and to parse output instead of just calling a function. You
did your work well, you made our life harder.

Everything except vector editing. I don't see any reasonable
possibility to do interactive vector editing via a GRASS module. For
vector editing, I need immediate response which is visualized on
display (e.g. if a vertex was moved and area topology was broken it
must be displayed). It is impossible to open/close a vector for every
single operation, it would take too long time for larger vectors.


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

[GRASS-dev] Re: [GRASS GIS] #811: MYSYS shortcut starts an infinite number of windows

[GRASS GIS]

#811: MYSYS shortcut starts an infinite number of windows
--+-
  Reporter:  JonBall  |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect   |  Status:  new  
  Priority:  major|   Milestone:  6.4.0
 Component:  default  | Version:  svn-releasebranch64  
Resolution:   |Keywords:  MSYS, wingrass   
  Platform:  MSWindows Vista  | Cpu:  x86-64   
--+-
Comment (by hellik):

 Replying to [comment:3 hamish]:
 > "MSYS UNIX Console" menu item worksforme with r40456 build on 32bit XP -
 it opens a rxvt term as it should.

 for the record:
 there are some hints for this issue for Win64 in

 
http://trac.osgeo.org/grass/wiki/CompileOnWindows#InstalltheenvironmentforcompilationMingW

 so the actual WinGrass-Installer is built with an updated msys in the
 osgeo4w-building environment.

 see also
 http://lists.osgeo.org/pipermail/osgeo4w-dev/2010-January/000760.html

 Helmut

-- 
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: [GRASS-user] 6.4 vs 7.0

[Paolo Craveri]

Hi,
2010/1/17 Hamish :
>
> If you use "
> GRASS_OVERWRITE=1 \
>  r.mapcalc "result = map * 4
> it will work on both versions.

In grass 6.4:
GRASS_OVERWRITE=1

r.mapcalc "result = rand(1,100)"

100%

r.mapcalc "result = rand(1,200)"
 ##ok, raster result has been overwritten
 100%


In grass7.0:
GRASS_OVERWRITE=1

r.mapcalc "result = rand(1,100)"

 100%

r.mapcalc  "result = rand(1,200)"
###  raster 'result' hasn't been overwritten

I have to setting GRASS_OVERWRITE variable and r.mapcalc command in
the same line as you suggest:
GRASS_OVERWRITE=1 r.mapcalc "r = rand(12,24)"
in this case it works in both version.  Strange behaviour IMHO.

> here "input=-" has been set to be a required input. AFAIU this is so the
> option appears on the first tab of the module GUI window ("Required").
> I've complained about that before, so won't repeat myself, but what is
> really needed IMO is a new item added somewhere to help order the GUI
> sections so these GUI-at-the-expense-of-the-CLI hacks can be avoided.
+1

 thanks to all

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

[GRASS-dev] Re: [GRASS-user] 6.4 vs 7.0

[Hamish]

[->dev]

Glynn wrote:
> Regardless of how it affects the GUI, I really can't accept
> that having to add " in=-" is a significant burden.

it's that little bit extra PITA when the computer can figure it out
for itself..

ok, I can accept the GUI window with empty input= being sent into
limbo argument.


> IMHO, we should just fix 6.4's db.execute to accept in=-.
> Allowing it provides forward-compatibility with 7.0 without breaking
> backward compatibility with 6.3/6.4-SVN. Ditto for v.in.ascii and
> anything else which is capable of reading from stdin.

I've got no problem fixing those. In fact I did that for v.in.ascii
in 6.5 two weeks ago. db.execute looks like it will take a similar
treatment fairly easily.

 
> If it helps, I could add G_open() and G_fopen() which accept "-" as a
> valid filename (meaning stdin for read, stdout for write;
> obviously read-write access won't work with "-").

I can't say it would hurt beyond messing with 6.x more than we have to,
but I don't think that's strictly necessary. We're not talking about that
many modules and it's usually just a one or two liner.



Hamish



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

[GRASS-dev] Re: [GRASS GIS] #876: new option for ps.map border

[GRASS GIS]

#876: new option for ps.map border
--+-
  Reporter:  vincent  |   Owner:  hamish   
  Type:  enhancement  |  Status:  assigned 
  Priority:  minor|   Milestone:  6.5.0
 Component:  ps.map   | Version:  svn-develbranch6 
Resolution:   |Keywords:  background,border
  Platform:  All  | Cpu:  All  
--+-
Comment (by hamish):

 Vincent suggests:
 {{{
 "0 0 width height box
 stroke "
 at the beginning of the ps file.
 }}}

-- 
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] #876: new option for ps.map border

[GRASS GIS]

#876: new option for ps.map border
--+-
  Reporter:  vincent  |   Owner:  hamish   
  Type:  enhancement  |  Status:  assigned 
  Priority:  minor|   Milestone:  6.5.0
 Component:  ps.map   | Version:  svn-develbranch6 
Resolution:   |Keywords:  background,border
  Platform:  All  | Cpu:  All  
--+-
Changes (by hamish):

 * cc: grass-dev@lists.osgeo.org (added)
  * owner:  grass-dev@lists.osgeo.org => hamish
  * priority:  normal => minor
  * status:  new => assigned
  * milestone:  6.4.0 => 6.5.0

Comment:

 work-around until this gets added: v.in.region + vareas as the last/
 bottom-most layer

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

Re: [GRASS-dev] WinGrass-Installer - definition of the destination folder?

[Hamish]

Glynn wrote:
> Grass64-Release => %ProgramFiles%\GRASS-64
> Grass64-Dev => %ProgramFiles%\GRASS-64-SVN
...
> We *need* this to work. If GRASS can't handle being
> installed in %ProgramFiles%, that's a blocker, IMHO.


It could be that this is a 6.4.0-final blocker, but //please// let's
hold off on r40496 and release 6.4.0rc6 before beginning to validate
that $GISBASE is space-safe.

AFAIK there are no more major RC-blockers left & we are ready to go
for rc6 -right now-. If we start on the next thing it's going to be
another 3 weeks+ before we can even think about shipping rc6. !...@$%!#
It resets the release confidence cycle.


> Similarly if it can't handle spaces in GISDBASE.

AFAIK all of those that are known have been fixed (I suppose mainly
thanks to a longer exposure to Mac users).


Hamish



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

[GRASS-dev] Re: [GRASS GIS] #811: MYSYS shortcut starts an infinite number of windows

[GRASS GIS]

#811: MYSYS shortcut starts an infinite number of windows
--+-
  Reporter:  JonBall  |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect   |  Status:  new  
  Priority:  major|   Milestone:  6.4.0
 Component:  default  | Version:  svn-releasebranch64  
Resolution:   |Keywords:  MSYS, wingrass   
  Platform:  MSWindows Vista  | Cpu:  x86-64   
--+-
Comment (by hamish):

 "MSYS UNIX Console" menu item worksforme with r40456 build on 32bit XP -
 it opens a rxvt term as it should.

-- 
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] #653: consider using console instead of cmd.exe

[GRASS GIS]

#653: consider using console instead of cmd.exe
---+
  Reporter:  timmie|   Owner:  grass-dev@lists.osgeo.org
  Type:  enhancement   |  Status:  new  
  Priority:  normal|   Milestone:  6.5.0
 Component:  Packaging | Version:  svn-develbranch6 
Resolution:|Keywords:  wingrass 
  Platform:  MSWindows XP  | Cpu:  x86-32   
---+
Changes (by hamish):

  * milestone:  6.4.0 => 6.5.0

-- 
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] #655: g.manual fails to open a browser

[GRASS GIS]

#655: g.manual fails to open a browser
---+
  Reporter:  landis|   Owner:  grass-dev@lists.osgeo.org  
  Type:  defect|  Status:  closed 
  Priority:  normal|   Milestone:  6.4.0  
 Component:  Docs  | Version:  6.4.0 RCs  
Resolution:  fixed |Keywords:  g.manual, osgeo4w, wingrass
  Platform:  MSWindows XP  | Cpu:  x86-32 
---+
Changes (by hamish):

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

Comment:

 calling this one fixed. reopen if needed.

-- 
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] #639: Wingrass native r.in.aster doesn't work

[GRASS GIS]

#639: Wingrass native r.in.aster doesn't work
--+-
  Reporter:  lroach   |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect   |  Status:  closed   
  Priority:  normal   |   Milestone:  6.4.0
 Component:  wxGUI| Version:  6.4.0 RCs
Resolution:  fixed|Keywords:  wingrass, r.in.aster,nviz
  Platform:  MSWindows Vista  | Cpu:  x86-64   
--+-
Changes (by hamish):

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

Comment:

 now it works.

-- 
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] #553: wx and tcltk GUI: changing default GUI returns error

[GRASS GIS]

#553: wx and tcltk GUI: changing default GUI returns error
---+
  Reporter:  hamish|   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:  wxgui gis.m  
  Platform:  MSWindows XP  | Cpu:  x86-32   
---+
Changes (by hamish):

  * priority:  major => normal

Comment:

 calling the main gist of this bug has been fixed.

 however,
 on wingrass the "start GRASS with wxPython gui" icon launches 'grass64
 -wxpython', which has the effect of resetting the default GUI away from
 what you set, but there's a "start GRASS with tcltk gui" button as well so
 I guess you can get the one you want pretty easily. not sure the best way
 to fix that.


 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] #860: wxGUI: About Copyright missing its middle

[GRASS GIS]

#860: wxGUI: About Copyright missing its middle
---+
  Reporter:  hamish|   Owner:  grass-dev@lists.osgeo.org
  Type:  defect|  Status:  new  
  Priority:  critical  |   Milestone:  6.4.0
 Component:  wxGUI | Version:  svn-releasebranch64  
Resolution:|Keywords:  license  
  Platform:  Linux | Cpu:  x86-64   
---+
Comment (by hamish):

 testing with the latest 6.4 wingrass installer (6.4.svn r40456)
 all Help->About content now displays.

 the weirdness of the tabs starting their scrolling on the 2nd paragraph or
 so remains.



 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] #843: v.digit broken on new WinGrass release

[GRASS GIS]

#843: v.digit broken on new WinGrass release
---+
  Reporter:  cnielsen  |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect|  Status:  new  
  Priority:  blocker   |   Milestone:  6.4.0
 Component:  Vector| Version:  unspecified  
Resolution:|Keywords:  wingrass,v.digit 
  Platform:  MSWindows XP  | Cpu:  x86-64   
---+
Comment (by hamish):

 as far as I can tell in the latest wingrass installer v.digit(tcl) works
 so this is no longer critical, but I get an unexplained error message when
 I close it:

 {{{
 Region restored to original extent.
 Building topology for vector map <(null)>...
 Registering promitives...
 Unable to read vector map
 }}}


 I also notice an error in the output:
 {{{
 DBMI-SQLite driver error:
 Error in sqlite3_prepare():
 near "where" syntax error
 Cannot update table
 }}}


 I'm guessing that is because I hit submit (or didn't) in the Form when the
 only column in the table was cat? (???)
 the output from v.db.select looks as it should.


 ?,
 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] #876: new option for ps.map border

[GRASS GIS]

#876: new option for ps.map border
---+
 Reporter:  vincent|   Owner:  grass-dev@lists.osgeo.org
 Type:  enhancement|  Status:  new  
 Priority:  normal |   Milestone:  6.4.0
Component:  ps.map | Version:  svn-develbranch6 
 Keywords:  background,border  |Platform:  All  
  Cpu:  All|  
---+
 It would be nice to add an fcolor (fill color) argument to the 'border'
 option, in order to switch from white to any color the background of a map
 composition.

 Thank you,
 Vincent

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

Re: [GRASS-dev] ps.map and map background

[Vincent Bain]

> if it was to be added to a ps.map instruction I'd guess it
> should belong to the "border" one as "fill_color" or so.

Hamish, it would be a nice option to add "fcolor" to "border", that
would only write a background box
"0 0 width height box
stroke "
at the beginning of the ps file. IMO it is the lightest solution...

Vincent



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

[GRASS-dev] Re: [GRASS GIS] #875: WinGrass-Installer - definition of the destination folder

[GRASS GIS]

#875: WinGrass-Installer - definition of the destination folder
--+-
  Reporter:  hellik   |   Owner:  grass-dev@lists.osgeo.org
  Type:  task |  Status:  new  
  Priority:  normal   |   Milestone:  6.4.0
 Component:  Packaging| Version:  unspecified  
Resolution:   |Keywords:  WinGrass-Installer   
  Platform:  MSWindows Vista  | Cpu:  Unspecified  
--+-
Changes (by hellik):

  * type:  defect => task

-- 
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] #875: WinGrass-Installer - definition of the destination folder

[GRASS GIS]

#875: WinGrass-Installer - definition of the destination folder
+---
 Reporter:  hellik  |   Owner:  grass-dev@lists.osgeo.org
 Type:  defect  |  Status:  new  
 Priority:  normal  |   Milestone:  6.4.0
Component:  Packaging   | Version:  unspecified  
 Keywords:  WinGrass-Installer  |Platform:  MSWindows Vista  
  Cpu:  Unspecified |  
+---
 from the dev-ml:

 >Glynn Clements glynn at gclements.plus.com
 >Sat Jan 16 18:48:00 EST 2010
 [...]
 >> maybe following options for the destination folder?
 >>
 >> Grass64-Release => c:\GRASS-64
 >> Grass64-Dev=> c:\GRASS-64-SVN
 >> Grass65-Dev=> c:\GRASS-65-SVN
 >> Grass7-Dev  => c:\GRASS-7-SVN
 >
 >Grass64-Release => %ProgramFiles%\GRASS-64
 >Grass64-Dev => %ProgramFiles%\GRASS-64-SVN
 >Grass65-Dev => %ProgramFiles%\GRASS-65-SVN
 >Grass7-Dev  => %ProgramFiles%\GRASS-7-SVN
 >
 >We *need* this to work. If GRASS can't handle being installed in
 >%ProgramFiles%, that's a blocker, IMHO.
 >
 >Similarly if it can't handle spaces in GISDBASE.

 I add patches for GRASS-Packager.bat and GRASS-Installer.nsi for this
 issue, please review

 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] #874: ps.map: submeter grid sizes

[GRASS GIS]

#874: ps.map: submeter grid sizes
--+-
  Reporter:  hamish   |   Owner:  grass-dev@lists.osgeo.org
  Type:  enhancement  |  Status:  new  
  Priority:  normal   |   Milestone:  6.5.0
 Component:  ps.map   | Version:  svn-develbranch6 
Resolution:   |Keywords:  grid 
  Platform:  All  | Cpu:  All  
--+-
Comment (by hamish):

 also, it would be nice to be able to run the grid instruction twice. (a
 darker coarser grid over the top of a lighter finer grid)

-- 
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] #874: ps.map: submeter grid sizes

[GRASS GIS]

#874: ps.map: submeter grid sizes
-+--
 Reporter:  hamish   |   Owner:  grass-dev@lists.osgeo.org
 Type:  enhancement  |  Status:  new  
 Priority:  normal   |   Milestone:  6.5.0
Component:  ps.map   | Version:  svn-develbranch6 
 Keywords:  grid |Platform:  All  
  Cpu:  All  |  
-+--
 Hi,

 currently ps.map's grid instruction only accepts integers. For sub-meter
 work or 2.5m grids etc it would be nice if that accepted floats.

 the attached patch adds that; please review.



 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-user] 6.4 vs 7.0

[Hamish]

[moving this to -dev]


Glynn  wrote:
> That's not good for the GUI, where the module won't have a
> stdin (ideally, it will have been closed; if not, the module
> will hang, waiting to read from whatever its stdin happens
> to be).


does isatty(0) work on ms windows?
does it work from a pipe?


Hamish



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

Re: [GRASS-dev] ps.map and map background

[Hamish]

Vincent Bain wrote:
> before emitting a ticket for this suggestion, I would like
> to know if ps.map allows to switch from white to any color the
> background of a map composition. Particularly I tried with
> the rectangle subcommand but it fails : the rectangle lays
> over all geographic features, whatever the precedence given
> to the command...
> Of course I can manually edit the ps file, then add a
> colored box as first ps instruction; but I would like
> to have this automated. 

are you displaying a raster map at all? if so what happens if
you set the null value (nv) to some color with r.colors?
maybe the "setcolor" instruction helps with that? (I keep
on meaning to check if that still works)

another idea along the lines of the rectangle decoration is to
use v.in.region to make a big box, then display that as the
last/bottom vareas layer.

if it was to be added to a ps.map instruction I'd guess it
should belong to the "border" one as "fill_color" or so.



Hamish


ps- in case anyone finds it useful, I just added a page to the
wiki showing how to make graph paper with ps.map:
  http://grass.osgeo.org/wiki/Ps.map_graph_paper



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

[GRASS-dev] ps.map and map background

[Vincent Bain]

Hello,
before emitting a ticket for this suggestion, I would like to know if
ps.map allows to switch from white to any color the background of a map
composition. Particularly I tried with the rectangle subcommand but it
fails : the rectangle lays over all geographic features, whatever the
precedence given to the command...
Of course I can manually edit the ps file, then add a colored box as
first ps instruction; but I would like to have this automated. And
perhaps other folks could profit of this new property.

What do you think of this point ?

Thanks,
Vincent.

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