Re: [GRASS-dev] Unclean exit in 6.5: pgrep issue
Hamish wrote: (it is not dumb simply trying to `killall wish`, afaiu Maris's tcl magic registers the PID of the gis.m session upon launch and attempts to cleanly shut that down on Init.sh exit) Specifically, it uses wish to send a Gm::remoteExit command to each wish it can find (via winfo interps). Gm::remoteExit takes the session PID ($GIS_LOCK) as an argument, and only terminates if the process belongs to that session. There are many ways that this can fail to terminate a gis.m process which should be terminated, but it's highly unlikely[1] to cause problems for unrelated processes. [1] Although theoretically possible. Because it only checks the PID, and not the hostname, you could have two GRASS sessions on different hosts but with the same PID, both running gis.m on the same X display. In this case, both gis.m processes would be terminated. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #76: Calculation of bearing between 2 points, using d.measure
#76: Calculation of bearing between 2 points, using d.measure --+- Reporter: dylan| Owner: grass-dev@lists.osgeo.org Type: enhancement | Status: new Priority: minor| Milestone: 6.5.0 Component: default | Version: unspecified Resolution: |Keywords: d.measure Platform: Unspecified | Cpu: Unspecified --+- Comment (by dylan): I understand that the GUI has this functionality, but there are many of us who do not use the GUI. I have updated the patch to conform to the current (r39462) version of GRASS65. If it seems like a useless patch, then I will maintain my own local version. -- Ticket URL: https://trac.osgeo.org/grass/ticket/76#comment:4 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] [GRASS GIS] #806: WinGRASS: Problem with special characters (wxpython GUI)
#806: WinGRASS: Problem with special characters (wxpython GUI)
+---
Reporter: marmai | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: normal | Milestone: 6.4.0
Component: default | Version: 6.4.0 RCs
Keywords: umlaut charcter german |Platform: MSWindows XP
Cpu: Unspecified |
+---
In the latest winGRASS binary (standalone version: WinGRASS-6.4.0SVN-
r39626-1-Setup.exe) there is a problem with the special characters in the
German language ('Umlaute', e.g. ö,ä,ü):
In the GUI windows that open at startup ('GRASS GIS Ebenen-Manager')
everything is correct, but all GUIs for modules (started from within the
wxpython GUI) have broken characters (all umlauts are broken; see attached
file). This occured on W2k and XP, and can be reproduced.
--
Ticket URL: http://trac.osgeo.org/grass/ticket/806
GRASS GIS http://grass.osgeo.org
___
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)
#806: WinGRASS: Problem with special characters (wxpython GUI) ---+ Reporter: marmai| 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: umlaut charcter german Platform: MSWindows XP | Cpu: Unspecified ---+ Changes (by marmai): * component: default = wxGUI -- Ticket URL: http://trac.osgeo.org/grass/ticket/806#comment:1 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS-user] Python scripts for the Pareto Boundary, tested using spearfish60 data [How to merge multiple python scripts in one?]
Νίκος Αλεξανδρής wrote: If you want to enable these flags throughout the script, you can use: os.environ['GRASS_OVERWRITE'] = '1' # --o os.environ['GRASS_VERBOSE'] = '0' # --q os.environ['GRASS_VERBOSE'] = '3' # --v In general, it's best to leave these settings to the user. Sometimes it is required to use them and prevent the user from _not_ using e.g. the --o flag (I think... ?). The presence or absence of --o should definitely be honoured. Ideally, a script should try to use unique names for any temporary maps it creates, so that it doesn't inadvertently overwrite the user's maps (using tmp and the PID in the mapname is sufficient, e.g. mapname.tmp.pid; if the user gives their own maps such names, tough). Using overwrite=True to overwrite temporary maps created within the script is okay, but the final output maps should honour the --o and $GRASS_OVERWRITE settings, i.e. don't complain about overwriting maps if --o is used, and don't overwrite maps if it wasn't. The script shouldn't need to handle this explicitly. If the --o flag was given, GRASS_OVERWRITE will have been set to 1 by grass.parser(), and this will automatically be inherited by any child processes. The only thing that the script needs to do is to *not* explicitly use overwrite=True on any commands which create the final output maps, but allow their overwrite behaviour be controlled by $GRASS_OVERWRITE. If the user runs the script with --o, --q, and/or --v, the corresponding environment variables will be set by grass.parser(). If the user has those variables set in their environment, the values will be inherited by the script. If you want to examine the settings use the overwrite() and/or verbosity() functions in grass.script. # note-to-self: # check functions overwrite(), verbosity() in grass.script It's seldom necessary to check these explicitly. The settings will be inherited by child processes, and if you use grass.message(), grass.verbose(), etc for messages, whether or not the messages are displayed depends upon the $GRASS_VERSBOSE setting. If you do a lot of this, consider a utility function, e.g.: def log(msg, **kwargs): grass.message(string.Template(msg).substitute(**kwargs)) This is supposed to reduce typing effort, right? Yes, although it may also make the code easier to read and modify. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Re: grass-dev Digest, Vol 43, Issue 8
Hi Markus, How much memory was available on the machine? 8 GB If the machine had more than 512MB RAM, it is not fair to run terracost running with mem=400MB, and compare it with an algorithm that can use more memory. I don't understand, both modules can use more than 400MB of memory. I set r.terracost to use 400MB max and r.cost to use 135MB max. If anything, this is not fair for r.cost and gives an advantage to r.terracost. I did not mention that I gave r.terracost another advantage by assigning the temporary directories to a folder on a separate, very fast hard drive that had nothing else to do but manage the temp files of r.terracost. The temp files of r.cost are in the standard grass .tmp/$HOST directory, in my case that (slower) hard drive also had other things to do than just manage r.cost's temp files. I really tried to give r.terracost a head start ;-) my experience is that , if you want to see how an application would behave with 500 MB of RAM, you have to physically reboot the machine with 500 MB of RAM (it's very easy to do this on a Mac, and relatively easy on Linux. on windows, i don't know). if the machine has more than 500MB RAM, even if you restrict the application to use less, the system gives it all it can.in your setup, it is almost as if r.cost would run fully in memory, because even it it places the segments on disk, the system file cache fits all segments in memory. the same is true for terracost, its streams fit in memory. but using tiles has a big CPU overhead, which is why it is slower. when i did some preliminary testing, i rebooted the machine with 512MB RAM, and ran r.cost on grids of 50M-100M cells. it was slow, completely IO bound, and took several hours or more. or if you use 1GB of RAM, you may need to go to larger grids. However, I am surprised that withnumtiles=1, it was slower than r.cost. it looks like i misread your numbers. BTW, I took the liberty to fix r.terracost, it works now with numtiles1. See changelog for r39684 https://trac.osgeo.org/grass/changeset/39684 great, thanks! let's see if terracost is worthwhile :) -Laura ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
