Johannes Radinger | 1 Sep 2011 09:43
Picon
Picon

Re: [GRASS-windows] WinGRASS Python 2.7

Hi,

-------- Original-Nachricht --------
> Datum: Wed, 31 Aug 2011 20:49:30 +0100
> Von: Glynn Clements <glynn <at> gclements.plus.com>
> An: "Johannes Radinger" <JRadinger <at> gmx.at>
> CC: grass-user <at> lists.osgeo.org, grass-windows <at> lists.osgeo.org
> Betreff: Re: [GRASS-windows] WinGRASS Python 2.7

> 
> Johannes Radinger wrote:
> 
> > So I checked the python.exe*32 (the only python that is running) in
> > the taskmanager (after booting and starting the wxGUI). And although
> > GRASS_PYTHON is set in the environmental variables to
> > C:\Python27\python.exe, the python which is used is still the
> > GRASS-Python in the path C:\Programm Files(x64)\GRASS
> > 6.4.1\extrabin\python.exe
> > 
> > So what causes this? How can I proceed? What should I check?
> 
> How did you set GRASS_PYTHON?
> 
> AFAIK, it's set in %GISBASE%\etc\env.bat; this will override any
> global setting.

I set the environmental variables in the environment settings in the system properties as I was told some
months ago here in the mailing list.
Anyway I found the env.bat file. It contains besides others following lines:

(Continue reading)

Sandip Maity | 1 Sep 2011 09:47
Picon

QT with Grass64

Dear All,
 
please help me, how to start GUI devolopment in QT with GRASS64 -TEXT.
 
Any link or documents regarding this topic?
 
thnks.
 
sandip
 
_______________________________________________
grass-user mailing list
grass-user <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Martin Landa | 1 Sep 2011 12:32
Picon

Re: QT with Grass64

Hi,

2011/9/1 Sandip Maity <sandip.stesalit <at> gmail.com>:
> please help me, how to start GUI devolopment in QT with GRASS64 -TEXT.

what do you mean by 'text', it's a UI mode.

> Any link or documents regarding this topic?

Older GUI has been written in TCL/TK [1,2], current GUI is written
wxPython [3]. There were some attempts to use Qt in the past, but they
were not successful, eg. [4].

Martin

[1] http://grass.osgeo.org/grass64/manuals/html64_user/gis.m.html
[2] http://grass.osgeo.org/grass64/manuals/html64_user/d.m.html
[3] http://grass.osgeo.org/wiki/WxGUI
[4] http://freshmeat.net/projects/qtgrass/

--

-- 
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa
_______________________________________________
grass-user mailing list
grass-user <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Arno Gerretsen | 1 Sep 2011 16:07
Picon

Re: r.watershed and big files


Quoting Arno Gerretsen <arno <at> agerrius.nl>:

>> I guess so too. The first message indicates that the on-disk option
>> (-m flag) is used. One reason could be not enough free disk space to
>> create temporary files. BTW, there seems to be a cut'n paste error,
>> the first message should read "SECTION 1 beginning: ..." and not
>> "SECTION 3 beginning: ..."
>>
>
> I probably forgot to copy the first part then. Let me try again with  
> the new knowledge about the maximum size. Hopefully that will  
> prevent these errors.

I did another attempt to use r.watershed on my big file. This time I  
compiled GRASS 6.4.1 from source code and made sure it was configured  
for largefiles (--enable-largefile). However I still get errors from  
r.watershed and it seems related to the segment file:

GRASS 6.4.1 (ML):~/grass/bin > r.watershed elevation=ML_elev  
stream=stream_total accumulation=accumulation_total threshold=10000  
--o -m memory=2000
SECTION 1 beginning: Initiating Variables. 5 sections total.
WARNING: No such file or directory
WARNING: dseg_open(): could not write segment file
WARNING: Subprocess failed with exit code 136

Can anybody tell me what is causing this (and how I could solve it)?  
In this case I was using a region of 19800x16200 pixels.

Thanks,

Arno
_______________________________________________
grass-user mailing list
grass-user <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Markus Metz | 1 Sep 2011 18:01

Re: r.watershed and big files

On Thu, Sep 1, 2011 at 4:07 PM, Arno Gerretsen <arno <at> agerrius.nl> wrote:
>
> Quoting Arno Gerretsen <arno <at> agerrius.nl>:
>
>>> I guess so too. The first message indicates that the on-disk option
>>> (-m flag) is used. One reason could be not enough free disk space to
>>> create temporary files. BTW, there seems to be a cut'n paste error,
>>> the first message should read "SECTION 1 beginning: ..." and not
>>> "SECTION 3 beginning: ..."
>>>
>>
>> I probably forgot to copy the first part then. Let me try again with the
>> new knowledge about the maximum size. Hopefully that will prevent these
>> errors.
>
> I did another attempt to use r.watershed on my big file. This time I
> compiled GRASS 6.4.1 from source code and made sure it was configured for
> largefiles (--enable-largefile). However I still get errors from r.watershed
> and it seems related to the segment file:
>
> GRASS 6.4.1 (ML):~/grass/bin > r.watershed elevation=ML_elev
> stream=stream_total accumulation=accumulation_total threshold=10000 --o -m
> memory=2000
> SECTION 1 beginning: Initiating Variables. 5 sections total.
> WARNING: No such file or directory
> WARNING: dseg_open(): could not write segment file
> WARNING: Subprocess failed with exit code 136
>
> Can anybody tell me what is causing this (and how I could solve it)? In this
> case I was using a region of 19800x16200 pixels.
>
I think the reason is that GRASS could not initialize a temporary
segment file, maybe because of insufficient free disk space?
dseg_open() s called relative late in the initialization process when
a number of other segment files have already been successfully
created. You could try to create a new GRASS database on a different
partition with more free disk space and try r.watershed again.

If possible, you could also try GRASS7 and run r.watershed --verbose,
this will print out estimated disk and memory requirements (and is
much faster than r.watershed -m in GRASS 6).

Markus M
_______________________________________________
grass-user mailing list
grass-user <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Michael Barton | 1 Sep 2011 19:36
Picon
Favicon

Re: QT with Grass64

We decided not to use QT because it is more difficult to develop a GUI in. We also reviewed current versions of
TclTk and GTK as potential interface development environments and settled on wxPython that combines the
cross-platform compatibility, ease of programming, open source environment, and versatility in
creating interface elements. There may be people in the larger GRASS community with experience in QT, but
no one on the dev team is using it for GUI development in GRASS. 

Have you looked at wx?

Michael
____________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity 
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University

voice: 	480-965-6262 (SHESC), 480-727-9746 (CSDC)
fax:          480-965-7671 (SHESC),  480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu

On Sep 1, 2011, at 9:00 AM, <grass-user-request <at> lists.osgeo.org> wrote:

> Date: Thu, 1 Sep 2011 13:17:34 +0530
> From: Sandip Maity <sandip.stesalit <at> gmail.com>
> Subject: [GRASS-user] QT with Grass64
> To: grass-user <at> lists.osgeo.org, grass <at> ces.iisc.ernet.in
> Message-ID:
> 	<CALSffknhrYHMvJ3PRV7fUJGpJ4hm5nKQ5ua-6Q+RJ2EC-C5KNQ <at> mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> Dear All,
> 
> please help me, how to start GUI devolopment in QT with GRASS64 -TEXT.
> 
> Any link or documents regarding this topic?
> 
> thnks.
> 
> sandip
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: http://lists.osgeo.org/pipermail/grass-user/attachments/20110901/02c7aaeb/attachment-0001.html

_______________________________________________
grass-user mailing list
grass-user <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Martin Landa | 1 Sep 2011 19:47
Picon

Re: QT with Grass64

Hi,

2011/9/1 Michael Barton <michael.barton <at> asu.edu>:
> We decided not to use QT because it is more difficult to develop a GUI in. We also reviewed current versions
of TclTk and GTK as potential interface

well, it's very subjective to say "more difficult". Qt compared to
wxWidgets is professional framework, it's the most developed graphical
library written in C++. In QT framework you will find very good
applications like Qt Designer or Creator. There are several bindings
like PyQt. Compared to wxWidgets and it's tools Qt playes another
game. But that's not reason why to leave wxPython for us, we are quite
happy with wxPython framework, even it's more difficult to use and
limited in design ;-)

Martin

--

-- 
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa
_______________________________________________
grass-user mailing list
grass-user <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Michael Barton | 1 Sep 2011 19:59
Picon
Favicon

Re: QT with Grass64

Also, until recently, QT also was not available as open source software on all platforms that GRASS
supports. And many more people in the scientific community (from where GRASS draws most of its
developers) are more familiar with Python than C++. So it's a pragmatic decision, but one that works well.

Michael
____________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity 
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University

voice: 	480-965-6262 (SHESC), 480-727-9746 (CSDC)
fax:          480-965-7671 (SHESC),  480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu

On Sep 1, 2011, at 10:47 AM, Martin Landa wrote:

> Hi,
> 
> 2011/9/1 Michael Barton <michael.barton <at> asu.edu>:
>> We decided not to use QT because it is more difficult to develop a GUI in. We also reviewed current versions
of TclTk and GTK as potential interface
> 
> well, it's very subjective to say "more difficult". Qt compared to
> wxWidgets is professional framework, it's the most developed graphical
> library written in C++. In QT framework you will find very good
> applications like Qt Designer or Creator. There are several bindings
> like PyQt. Compared to wxWidgets and it's tools Qt playes another
> game. But that's not reason why to leave wxPython for us, we are quite
> happy with wxPython framework, even it's more difficult to use and
> limited in design ;-)
> 
> Martin
> 
> -- 
> Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

_______________________________________________
grass-user mailing list
grass-user <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Martin Landa | 1 Sep 2011 20:06
Picon

Re: QT with Grass64

2011/9/1 Michael Barton <Michael.Barton <at> asu.edu>:
> Also, until recently, QT also was not available as open source software on all platforms that GRASS
supports. And many more people in the scientific community (from where GRASS draws most of its
developers) are more familiar with Python than C++. So it's a pragmatic decision, but one that works well.

just note: "recently" means 2006...

Martin

--

-- 
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa
_______________________________________________
grass-user mailing list
grass-user <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Glynn Clements | 1 Sep 2011 21:49

Re: Re: [GRASS-windows] WinGRASS Python 2.7


Johannes Radinger wrote:

> > How did you set GRASS_PYTHON?
> > 
> > AFAIK, it's set in %GISBASE%\etc\env.bat; this will override any
> > global setting.
> 
> 
> I set the environmental variables in the environment settings in the
> system properties as I was told some months ago here in the mailing
> list.

Ah; GRASS_PYTHON is only set in env.bat if it isn't already set. 
PYTHONHOME and PATH are set unconditionally.

> Anyway I found the env.bat file. It contains besides others following
> lines:
> 
> rem Path to the python directory
> set PYTHONHOME=%GISBASE%\Python25
> if "x%GRASS_PYTHON%" == "x" set GRASS_PYTHON=python
> 
> 
> What exactly should be changed there and how should i look like? As I
> said before, the Python I want to be used is C:\Python27\python.exe. 
> As it is set in the environemntal variables do I just need to delete
> it from the env.bat or what shoul I do exactly?

The above should only set GRASS_PYTHON if it isn't already set. 
However, the env.bat file also sets PATH, which may cause the bundled
version to be used in some cases.

If you want to use a system version of Python, I'd suggest disabling
the PYTHONHOME and GRASS_PYTHON settings in env.bat, and removing or
renaming any python.exe/pythonw.exe from the extrabin directory.

The original reason for bundling Python was that the GUI included a
couple of binary components (vdigit and nviz), which would only work
with the specific version of Python against which they were built. 
Those components have since been removed, but currently we don't have
anyone who is able and willing to fix the Window installer.

--

-- 
Glynn Clements <glynn <at> gclements.plus.com>
_______________________________________________
grass-user mailing list
grass-user <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


Gmane