Re: [GRASS-dev] New splash screen for GRASS GIS 7?
On Wed, Feb 4, 2015 at 10:48 AM, Moritz Lennert mlenn...@club.worldonline.be wrote: This just makes the rectangle smaller, but I still see it without the image for a while. I don't see the rectangle on Ubuntu but the splash screen is there just for a very short time comparing to how long nothing is visible. When starting GRASS for the first time after restart of computer I wait something like 7 seconds for the splash screen and splash screen is there just for 3 seconds. I guess this is not something we can change because when started for second time, the splash screen shows immediately, so the 7 seconds are for loading the wx libraries. I saw the same ratio of nothing and splash screen time on some MS Windows machines too. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] G7: endless loop with NFS mounted grassdata: libgis.G_mapset_permissions() problem
Hi,
we are currently stuck with a problem which prevents t.create from
concluding its job.
We run GRASS 7.1 in the office and mount /grassdata via NFS3 from our
cluster frontend machine.
With strace we got an idea where the problem is. Note that the user is
not operating in the mapset lexem_matteo cited below nor is it in
the mapset search path but it simply exists in the same location which
we share among our group:
GRASS 7.1.svn (eu_laea):
strace t.create output=Tdaily_modis_hants type=strds semantictype=mean
temporaltype=absolute title=daily temperature from Mod lst hants
description=daily T from hants on modis lst
...
getuid()= 10014
stat(/grassdata/eu_laea/lexem_matteo, {st_mode=S_IFDIR|0755,
st_size=4096, ...}) = 0
getuid()= 10014
stat(/grassdata/eu_laea/lexem_matteo, {st_mode=S_IFDIR|0755,
st_size=4096, ...}) = 0
getuid()= 10014
stat(/grassdata/eu_laea/lexem_matteo, {st_mode=S_IFDIR|0755,
st_size=4096, ...}) = 0
getuid()= 10014
stat(/grassdata/eu_laea/lexem_matteo, {st_mode=S_IFDIR|0755,
st_size=4096, ...}) = 0
[...]
stat(/grassdata/eu_laea/lexem_matteo, {st_mode=S_IFDIR|0755,
st_size=4096, ...}) = 0
getuid()= 10014
stat(/grassdata/eu_laea/lexem_matteo, {st_mode=S_IFDIR|0755,
st_size=4096, ...}) = 0
getuid()= 10014
stat(/grassdata/eu_laea/lexem_matteo, {st_mode=S_IFDIR|0755,
st_size=4096, ...}) = 0
[...]
^CTraceback (most recent call last):
File /usr/local/grass-7.1.svn/scripts/t.create, line 84, in module
main()
File /usr/local/grass-7.1.svn/scripts/t.create, line 77, in main
tgis.init()
File /usr/local/grass-7.1.svn/etc/python/grass/temporal/core.py,
line 593, in init
Process Process-1:
Process Process-2:
Traceback (most recent call last):
Traceback (most recent call last):
File /usr/lib64/python2.6/multiprocessing/process.py, line 232, in
_bootstrap
File /usr/lib64/python2.6/multiprocessing/process.py, line 232, in
_bootstrap
self.run()
File /usr/lib64/python2.6/multiprocessing/process.py, line 88, in run
self._target(*self._args, **self._kwargs)
File /usr/local/grass-7.1.svn/etc/python/grass/pygrass/messages/__init__.py,
line 65, in message_server
self.run()
File /usr/lib64/python2.6/multiprocessing/process.py, line 88, in run
self._target(*self._args, **self._kwargs)
File
/usr/local/grass-7.1.svn/etc/python/grass/temporal/c_libraries_interface.py,
line 769, in c_library_server
conn.poll(None)
KeyboardInterrupt
dbif = SQLDatabaseInterfaceConnection()
File /usr/local/grass-7.1.svn/etc/python/grass/temporal/core.py,
line 839, in __init__
self.tgis_mapsets = get_available_temporal_mapsets()
File /usr/local/grass-7.1.svn/etc/python/grass/temporal/core.py,
line 439, in get_available_temporal_mapsets
mapsets = c_library_interface.available_mapsets()
File
/usr/local/grass-7.1.svn/etc/python/grass/temporal/c_libraries_interface.py,
line 1220, in available_mapsets
return self.client_conn.recv()
KeyboardInterrupt
functions[data[0]](lock, conn, data)
File
/usr/local/grass-7.1.svn/etc/python/grass/temporal/c_libraries_interface.py,
line 159, in _available_mapsets
if libgis.G_mapset_permissions(mapset) 0:
KeyboardInterrupt
The ID of the actual user is 10014.
PROBLEM:
The issue happens in line 142
lib/python/temporal/c_libraries_interface.py
function def _available_mapsets(lock, conn, data):
where a while loop is used. The issue is apparently caused by the fact
that in our current cluster setup, after reinstallation, the NFS
daemon doesn't properly map the user ID's to the local workstation in
the office where not all users are existing. While we have to fix
this, it should not lead to an endless loop:
Apparently libgis.G_mapset_permissions() does not behave properly for
this NFS case. It should be able to leave the while loop rather than
getting stuck there.
# example for one of our NFS mounted directories as seen on the office
workstation:
ls -la /grassdata/eu_laea/lexem_matteo
total 312
drwxr-xr-x 13 10012 gis 4096 Jan 17 16:09 .
drwxrwxr-x 125 1338 gis 16384 Feb 3 18:35 ..
-rw--- 1 10012 gis 122050 Jan 1 18:26 .bash_history
-rw-r--r-- 1 10012 gis 1949 Jan 17 16:09 .bashrc
drwxr-xr-x 2 10012 gis 20480 Dec 27 14:22 cats
drwxr-xr-x 2 10012 gis 20480 Dec 27 14:22 cell
drwxr-xr-x 2 10012 gis 20480 Dec 27 14:22 cellhd
drwxr-xr-x 19 10012 gis 20480 Dec 27 14:22 cell_misc
...
-- user IDs not transmitted, our problem, but
libgis.G_mapset_permissions() doesn't deal with it properly (or def
_available_mapsets()).
Help welcome,
thanks,
Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] New splash screen for GRASS GIS 7?
Hi, 2015-02-03 23:48 GMT+01:00 Markus Neteler nete...@osgeo.org: I have taken liberty to upload #4 [1] in r64447 in order to get something changed for RC2 which is overdue (the image part of the screen should probably be filled with a white background). I took liberty to update also splash accordingly [1] in r64455. Martin [1] http://grasswiki.osgeo.org/w/images/GRASSGIS_splash5.jpg -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.eu/mentors/landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC2
On Wed, Feb 4, 2015 at 10:10 AM, Luca Delucchi lucadel...@gmail.com wrote: On 4 February 2015 at 10:03, Martin Landa landa.mar...@gmail.com wrote: Hi all, Hi all, thanks, the last issue for RC2 which I can see is the new startup banner and splash screen. Any objections to backport r64455 and r64447. Than we could hopefully move towards RC2 (it's ~20 days since RC1 has been released). sorry but should we vote or not? Maybe I lost some emails, but I understood that we should vote to choose banner and splash screen... I don't think that we should start a poll now (voting is happening on PSC, for other cases we have no voting infrastructure in place). Setting up a proper poll system is not that easy and requires time (who can participate, keep poll open for some week(s) etc). At time it is for RC2 only anyway which we need to get out asap. Is that acceptable? Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC2
Hi all, 2015-02-02 9:12 GMT+01:00 Markus Metz markus.metz.gisw...@gmail.com: To be backported: - r64280, r64279, r64278, r64277 (mmetz) Done in r64389-91. thanks, the last issue for RC2 which I can see is the new startup banner and splash screen. Any objections to backport r64455 and r64447. Than we could hopefully move towards RC2 (it's ~20 days since RC1 has been released). Martin -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.eu/mentors/landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC2
On 4 February 2015 at 10:03, Martin Landa landa.mar...@gmail.com wrote: Hi all, Hi all, thanks, the last issue for RC2 which I can see is the new startup banner and splash screen. Any objections to backport r64455 and r64447. Than we could hopefully move towards RC2 (it's ~20 days since RC1 has been released). sorry but should we vote or not? Maybe I lost some emails, but I understood that we should vote to choose banner and splash screen... Martin -- ciao Luca http://gis.cri.fmach.it/delucchi/ www.lucadelu.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2575: i.segment threshold error message should be updated
#2575: i.segment threshold error message should be updated --+- Reporter: madi | Owner: grass-dev@… Type: defect | Status: closed Priority: normal | Milestone: 7.1.0 Component: Imagery | Version: svn-trunk Resolution: fixed|Keywords: i.segment Platform: All | Cpu: Unspecified --+- Changes (by Madi): * status: reopened = closed * resolution: = fixed Comment: backported in r64456. Thanks. madi -- Ticket URL: https://trac.osgeo.org/grass/ticket/2575#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
Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC2
Hi Luca, 2015-02-04 10:10 GMT+01:00 Luca Delucchi lucadel...@gmail.com: sorry but should we vote or not? Maybe I lost some emails, but I understood that we should vote to choose banner and splash screen... we don't have any clear procedure for voting. So I would leave decision on Markus as the project leader. Otherwise GRASS 7 will be out probably in the next year ;-) Martin -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.eu/mentors/landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC2
+1 to go ahead, devs will see the difference on their next built. They can react if needed we decide to change before final. I am happy about the new splash and the new stylish banner. PS: I just updated ISIS-GRASS banner too. On 4 February 2015 at 15:11, Markus Neteler nete...@osgeo.org wrote: On Wed, Feb 4, 2015 at 10:10 AM, Luca Delucchi lucadel...@gmail.com wrote: On 4 February 2015 at 10:03, Martin Landa landa.mar...@gmail.com wrote: Hi all, Hi all, thanks, the last issue for RC2 which I can see is the new startup banner and splash screen. Any objections to backport r64455 and r64447. Than we could hopefully move towards RC2 (it's ~20 days since RC1 has been released). sorry but should we vote or not? Maybe I lost some emails, but I understood that we should vote to choose banner and splash screen... I don't think that we should start a poll now (voting is happening on PSC, for other cases we have no voting infrastructure in place). Setting up a proper poll system is not that easy and requires time (who can participate, keep poll open for some week(s) etc). At time it is for RC2 only anyway which we need to get out asap. Is that acceptable? Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev -- ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-user] temporary files of grass.script.array
Hi, I just tested in trunk, and it works: The temporary file that is create when assigning a raster to an python array is deleted once e.g. the python session is closed again. So this would be a nice thing also to have implemented in the next RC of GRASS7. /johannes On Tue, Feb 3, 2015 at 11:35 PM, Markus Neteler nete...@osgeo.org wrote: On Tue, Feb 3, 2015 at 4:23 PM, Glynn Clements gl...@gclements.plus.com wrote: The temporary files were supposed to be deleted when the array object was destroyed. However, this relied upon the ._close() method, which is no longer used. r64426 (trunk) should fix this. Please let me know if that should be backported then. Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Add link to manual page on the addon wiki
On Wed, Feb 4, 2015 at 10:56 PM, Martin Landa landa.mar...@gmail.com wrote: 2015-02-04 22:51 GMT+01:00 Markus Neteler nete...@osgeo.org: I could instead generate them on Linux. But not too soon due to being too busy these days. btw, then manual pages [1] are not generated on Windows but on Linux [2]. Martin [1] http://grass.osgeo.org/grass70/manuals/addons/ [2] http://grass.osgeo.org/addons/grass7/logs/summary.html ah, ok. So now I checked all failing modules: - PCL libs to be installed: impossible on Debian 6 - f77: gfortran does not seem to contain it - i.spec.* require LAPACK/BLAS which would enlarge the weekly snapshot - one module is a shell script and needs to be rewritten to Python - something else which I cannot immediately solve Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Add link to manual page on the addon wiki
On Tue, Jan 27, 2015 at 10:17 AM, Moritz Lennert mlenn...@club.worldonline.be wrote: On 25/01/15 13:09, Markus Neteler wrote: I have updated that script now. Voilà: http://grass.osgeo.org/grass70/manuals/addons/ Great ! Just one issue: some of the add-ons fail to compile on the server, sometimes because some additional libraries are missing (ex: v.class.mlpy, v.nnstat and v.kriging) Yes, because they are compiled on the Windows server which generates the nightly snapshots which does not have all packages. and because of that they are not listed on this page. Do you have an example? They are all autogenerated if they are in the parent Makefile registered. I don't know what the policy is: should all modules compile on the server and so should all dependencies be installed, Ideally yes but that's quite some work for the Windows server admin... or do we have to find a different solution for these ? Is it possible to only make the man pages and so avoid the issue of dependencies in the main source code ? I could instead generate them on Linux. But not too soon due to being too busy these days. Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2577: d.info: entire screen version frame
#2577: d.info: entire screen version frame -+-- Reporter: martinl | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 7.0.0 Component: Display | Version: svn-trunk Keywords: d.info |Platform: Unspecified Cpu: Unspecified | -+-- Comment(by martinl): Replying to [comment:3 glynn]: This should be fixed by r64459. This adds the -e flag to query the dimensions of the frame (-d queries the dimensions of the screen). This also fixes the behaviour of `d.info -g`, which was wrong before r62026. Thanks a lot for the fixes. They are hot candidates for backport to `relbr70` (before closing this ticket). Also, I don't think that the MONITOR stuff belongs in d.info. It should probably go into d.mon. Right, removed from `d.info` in r64466. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2577#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
Re: [GRASS-dev] Add link to manual page on the addon wiki
2015-02-04 22:51 GMT+01:00 Markus Neteler nete...@osgeo.org: I could instead generate them on Linux. But not too soon due to being too busy these days. btw, then manual pages [1] are not generated on Windows but on Linux [2]. Martin [1] http://grass.osgeo.org/grass70/manuals/addons/ [2] http://grass.osgeo.org/addons/grass7/logs/summary.html -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.eu/mentors/landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2509: d.mon output overwrite
#2509: d.mon output overwrite -+-- Reporter: martinl | Owner: martinl Type: defect | Status: assigned Priority: normal | Milestone: 7.0.0 Component: Display | Version: unspecified Keywords: d.mon|Platform: Unspecified Cpu: Unspecified | -+-- Comment(by mlennert): Replying to [comment:30 glynn]: Replying to [comment:28 martinl]: So if you want to retain the existing semantics for MONITOR, all references to it should be removed from the display library. Instead, wxGUI would set GRASS_RENDER_COMMAND to refer to a program or script which implements the MONITOR behaviour. Any future changes to the wxGUI monitor mechanism would only affect wxGUI and its utility programs, not the display systems. it's not only about wxGUI. The reason for having (GRASS) variable MONITOR is the module `d.mon` which allows to manage file-based monitors (like cairo output) and also standalone wxGUI monitors. This feature is requested by many of GRASS users, there is strong interest to have `d.mon` in GRASS 7. Now that you mentioned that, I decided to take a look at d.mon. I must have missed the discussion about the implementation of this. Can you tell me where to find it? display/d.mon ? -- Ticket URL: http://trac.osgeo.org/grass/ticket/2509#comment:31 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] New splash screen for GRASS GIS 7?
On 04/02/15 16:32, Martin Landa wrote: Hi, 2015-02-04 16:10 GMT+01:00 Moritz Lennert mlenn...@club.worldonline.be: Thanks ! However, I now see a white rectangle for a while, then the image I cannot reproduce that, I don't know. Here's little movie to give you an idea: http://tomahawk.ulb.ac.be/moritz/GRASS_slow_splash.ogv fills it briefly before it closes. Maybe the image is too heavy to be displayed quickly ? Right, even with `optipng -o5 file.png` [1], the splash screen has 408K. I agree that it would be good to decrease size of the file. I tried making it smaller with convert splash_screen_orig.png -resize 30% splash_screen.png This just makes the rectangle smaller, but I still see it without the image for a while. I just noticed that I see the same with GRASS6. I guess something in a recent update of my Debian machine might be causing this ? Moritz My system info: Version de GRASS: 7.1.svn GRASS SVN revision: 64455 Build date: 2015-01-04 Build platform: x86_64-unknown-linux-gnu GDAL: 1.10.1 PROJ.4: 4.8.0 GEOS: 3.4.2 SQLite: 3.8.7.1 Python: 2.7.8 wxPython: 3.0.1.1 Plateforme: Linux-3.16.0-4-amd64-x86_64-with-debian-8.0 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] New splash screen for GRASS GIS 7?
On 04/02/15 18:04, Vaclav Petras wrote: On Wed, Feb 4, 2015 at 10:48 AM, Moritz Lennert mlenn...@club.worldonline.be mailto:mlenn...@club.worldonline.be wrote: This just makes the rectangle smaller, but I still see it without the image for a while. I don't see the rectangle on Ubuntu but the splash screen is there just for a very short time comparing to how long nothing is visible. When starting GRASS for the first time after restart of computer I wait something like 7 seconds for the splash screen and splash screen is there just for 3 seconds. I guess this is not something we can change because when started for second time, the splash screen shows immediately, so the 7 seconds are for loading the wx libraries. I saw the same ratio of nothing and splash screen time on some MS Windows machines too. Would it be possible to launch some hidden process earlier (i.e. while the user looks at the startup screen) that already loads the libraries ? Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Add link to manual page on the addon wiki
On 04/02/15 23:21, Vaclav Petras wrote: See also how to formulate Makefiles for addons so that additional files get installed correctly by g.extension discussion [1]. Vaclav [1] http://lists.osgeo.org/pipermail/grass-dev/2015-February/073713.html Well, this thread is not so much about external dependencies, but more about the fact that a series of addon modules that split their code into several python files do not get these installed correctly when installing via g.extension, whereas they do when you compile directly from the source tree via 'make MODULE_TOPDIR='. Examples are #2480 (v.class.ml) and #2534 (i.segment.hierarchical). Pietro do you have any ideas for these ? Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2577: d.info: entire screen version frame
#2577: d.info: entire screen version frame -+-- Reporter: martinl | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 7.0.0 Component: Display | Version: svn-trunk Keywords: d.info |Platform: Unspecified Cpu: Unspecified | -+-- Comment(by martinl): Replying to [comment:1 glynn]: This stems from r62026. At present, there is no way to retrieve the screen bounds, only the frame bounds. Previously, it was the other way around. It's pity. Would be possible to change that? If not I would suggest to clean up at least d.info flags. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2577#comment:2 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2577: d.info: entire screen version frame
#2577: d.info: entire screen version frame -+-- Reporter: martinl | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 7.0.0 Component: Display | Version: svn-trunk Keywords: d.info |Platform: Unspecified Cpu: Unspecified | -+-- Comment(by glynn): Replying to [comment:1 glynn]: This should be fixed by r64459. This adds the -e flag to query the dimensions of the frame (-d queries the dimensions of the screen). This also fixes the behaviour of `d.info -g`, which was wrong before r62026. Also, I don't think that the MONITOR stuff belongs in d.info. It should probably go into d.mon. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2577#comment:3 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2577: d.info: entire screen version frame
#2577: d.info: entire screen version frame -+-- Reporter: martinl | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 7.0.0 Component: Display | Version: svn-trunk Keywords: d.info |Platform: Unspecified Cpu: Unspecified | -+-- Comment(by glynn): This stems from r62026. At present, there is no way to retrieve the screen bounds, only the frame bounds. Previously, it was the other way around. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2577#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
Re: [GRASS-dev] [GRASS GIS] #2509: d.mon output overwrite
#2509: d.mon output overwrite -+-- Reporter: martinl | Owner: martinl Type: defect | Status: assigned Priority: normal | Milestone: 7.0.0 Component: Display | Version: unspecified Keywords: d.mon|Platform: Unspecified Cpu: Unspecified | -+-- Comment(by glynn): Replying to [comment:26 wenzeslaus]: Passing commands as one string is probably necessary in some cases (e.g. when they are stored into a file or when a module would take more different commands as input) but if it can be avoided, it should be avoided I think. When a d.* command is redirected to another program, its argument list needs to be passed as-is. If you need to store a command in a file, then you need to separate the arguments. There are two options here: 1. Use a NUL byte as the argument separator. On both Unix and Windows, any byte except NUL can occur within an argument. NUL cannot occur within an argument, but can occur within a file. However, if the command is only one item within the file, then you also need some mechanism to indicate the end of the command, which leaves the second option: 2. Use some other byte as the separator and escape or quote argument values so that occurrences of the separator within an argument can be distinguished from argument separators. Ignoring the situation where the separator (or a character used for escaping or quoting) occurs within an argument is not a solution. Which is why G_recreate_command() can't be used here. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2509#comment:29 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2509: d.mon output overwrite
#2509: d.mon output overwrite -+-- Reporter: martinl | Owner: martinl Type: defect | Status: assigned Priority: normal | Milestone: 7.0.0 Component: Display | Version: unspecified Keywords: d.mon|Platform: Unspecified Cpu: Unspecified | -+-- Comment(by glynn): Replying to [comment:25 martinl]: 1. It adds yet more cruft rather than simplifying. Hopefully this is just a transitional phase until existing modules are updated. Can you be more detailed? Rather than redefining MONITOR (as suggested in comment:20), it keeps that and adds yet another variable, GRASS_RENDER_COMMAND. The only thing that's actually required is a mechanism to allow all d.* commands to be redirected to another program. And that's all that should be provided by the display library. Everything else should be handled by that other program. So if you want to retain the existing semantics for MONITOR, all references to it should be removed from the display library. Instead, wxGUI would set GRASS_RENDER_COMMAND to refer to a program or script which implements the MONITOR behaviour. Any future changes to the wxGUI monitor mechanism would only affect wxGUI and its utility programs, not the display systems. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2509#comment:27 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2509: d.mon output overwrite
#2509: d.mon output overwrite -+-- Reporter: martinl | Owner: martinl Type: defect | Status: assigned Priority: normal | Milestone: 7.0.0 Component: Display | Version: unspecified Keywords: d.mon|Platform: Unspecified Cpu: Unspecified | -+-- Comment(by glynn): Replying to [comment:28 martinl]: So if you want to retain the existing semantics for MONITOR, all references to it should be removed from the display library. Instead, wxGUI would set GRASS_RENDER_COMMAND to refer to a program or script which implements the MONITOR behaviour. Any future changes to the wxGUI monitor mechanism would only affect wxGUI and its utility programs, not the display systems. it's not only about wxGUI. The reason for having (GRASS) variable MONITOR is the module `d.mon` which allows to manage file-based monitors (like cairo output) and also standalone wxGUI monitors. This feature is requested by many of GRASS users, there is strong interest to have `d.mon` in GRASS 7. Now that you mentioned that, I decided to take a look at d.mon. I must have missed the discussion about the implementation of this. Can you tell me where to find it? -- Ticket URL: http://trac.osgeo.org/grass/ticket/2509#comment:30 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2509: d.mon output overwrite
#2509: d.mon output overwrite -+-- Reporter: martinl | Owner: martinl Type: defect | Status: assigned Priority: normal | Milestone: 7.0.0 Component: Display | Version: unspecified Keywords: d.mon|Platform: Unspecified Cpu: Unspecified | -+-- Comment(by martinl): Replying to [comment:27 glynn]: So if you want to retain the existing semantics for MONITOR, all references to it should be removed from the display library. Instead, wxGUI would set GRASS_RENDER_COMMAND to refer to a program or script which implements the MONITOR behaviour. Any future changes to the wxGUI monitor mechanism would only affect wxGUI and its utility programs, not the display systems. it's not only about wxGUI. The reason for having (GRASS) variable MONITOR is the module `d.mon` which allows to manage file-based monitors (like cairo output) and also standalone wxGUI monitors. This feature is requested by many of GRASS users, there is strong interest to have `d.mon` in GRASS 7. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2509#comment:28 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] New splash screen for GRASS GIS 7?
On 04/02/15 09:29, Martin Landa wrote: Hi, 2015-02-03 23:48 GMT+01:00 Markus Neteler nete...@osgeo.org: I have taken liberty to upload #4 [1] in r64447 in order to get something changed for RC2 which is overdue (the image part of the screen should probably be filled with a white background). I took liberty to update also splash accordingly [1] in r64455. Thanks ! However, I now see a white rectangle for a while, then the image fills it briefly before it closes. Maybe the image is too heavy to be displayed quickly ? Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Planning GRASS GIS 7.0.0RC2
On Wed, Feb 4, 2015 at 4:41 AM, Markus Neteler nete...@osgeo.org wrote: On Wed, Feb 4, 2015 at 10:10 AM, Luca Delucchi lucadel...@gmail.com wrote: On 4 February 2015 at 10:03, Martin Landa landa.mar...@gmail.com wrote: Hi all, Hi all, thanks, the last issue for RC2 which I can see is the new startup banner and splash screen. Any objections to backport r64455 and r64447. Than we could hopefully move towards RC2 (it's ~20 days since RC1 has been released). sorry but should we vote or not? Maybe I lost some emails, but I understood that we should vote to choose banner and splash screen... I don't think that we should start a poll now (voting is happening on PSC, for other cases we have no voting infrastructure in place). Setting up a proper poll system is not that easy and requires time (who can participate, keep poll open for some week(s) etc). I don't think we have to keep it open for weeks, 3 days is enough. At time it is for RC2 only anyway which we need to get out asap. I am just afraid the banner and the splash screen will stay that way... Did you try to get any feedback on the new splash screen on FOSSDEM? The feedback on the grassy world splash screen I get here is negative... Is that acceptable? Yes, it's just a splash screen, but we have to get back to it. Anna Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] New splash screen for GRASS GIS 7?
On Tue, Feb 3, 2015 at 5:48 PM, Markus Neteler nete...@osgeo.org wrote: Hi, I have taken liberty to upload #4 [1] in r64447 in order to get something changed for RC2 which is overdue (the image part of the screen should probably be filled with a white background). Why this one? I thought most agreed on upper case? I don't know where you got the banner (I couldn't find the original image on the wiki), but the background white is not white (254,255,252) which was probably not intention. I found that out when I was trying to see how it would look like with transparent background, which in my opinion looks better on the welcome screen. Anna Markus [1] http://grasswiki.osgeo.org/wiki/File:GRASSGIS_welcome_banner4.jpg It looks now a bit different due to the wording changes, though. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] New splash screen for GRASS GIS 7?
Hello Anna, sorry for this mistake, can't really figure out where the error comes from, probably when I turned the native svg to indexed colors png, but the background should have kept pure white. I'll fix it as soon as possible. Of course removing the white bg and set it to transparent is straight too. Vincent. Le mercredi 04 février 2015 à 09:40 -0500, Anna Petrášová a écrit : On Tue, Feb 3, 2015 at 5:48 PM, Markus Neteler nete...@osgeo.org wrote: Hi, I have taken liberty to upload #4 [1] in r64447 in order to get something changed for RC2 which is overdue (the image part of the screen should probably be filled with a white background). Why this one? I thought most agreed on upper case? I don't know where you got the banner (I couldn't find the original image on the wiki), but the background white is not white (254,255,252) which was probably not intention. I found that out when I was trying to see how it would look like with transparent background, which in my opinion looks better on the welcome screen. Anna Markus [1] http://grasswiki.osgeo.org/wiki/File:GRASSGIS_welcome_banner4.jpg It looks now a bit different due to the wording changes, though. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] New splash screen for GRASS GIS 7?
Hi, 2015-02-04 16:10 GMT+01:00 Moritz Lennert mlenn...@club.worldonline.be: Thanks ! However, I now see a white rectangle for a while, then the image I cannot reproduce that, I don't know. fills it briefly before it closes. Maybe the image is too heavy to be displayed quickly ? Right, even with `optipng -o5 file.png` [1], the splash screen has 408K. I agree that it would be good to decrease size of the file. Martin [1] http://trac.osgeo.org/grass/wiki/Submitting/Docs -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.eu/mentors/landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
