On Thu, Jun 19, 2014 at 1:47 PM, Huidae Cho gras...@gmail.com wrote:
Hmm... one flag -s (switch default) should be enough, I think.
I'm not sure what is the current proposal (I think I've seen something
else in some other thread) but flag -s (switch default) seems like a very
bad idea as well
Huidae Cho wrote:
Hmm... one flag -s (switch default) should be enough, I think.
I think not. We need a way to specify a particular output format. A
switch flag is only useful if you already know which format will be
used without that flag, which isn't necessarily straightforward.
A similar
I agree that it can be confusing. I think we have the following options:
1. Just don't replace g.list as it is more user friendly and g.mlist is
more machine friendly.
2. Replace g.list with the current version of g.mlist and use -p in
terminal as needed.
3. Redirect g.mlist output
Huidae Cho wrote:
IMO, if we replace g.list with g.mlist, it would be better to remove the -p
flag and switch between the pretty output and machine-friendly output based
on isatty(STDOUT_FILENO). In most cases, if the user types a command from
the terminal without redirecting, they want to
FYI, multiple mapsets implemented in r60872.
On Sun, Jun 8, 2014 at 8:30 AM, Vaclav Petras wenzesl...@gmail.com wrote:
On Sun, Jun 8, 2014 at 7:10 AM, Huidae Cho gras...@gmail.com wrote:
Non-existent mapset fixed in r60749.
Thanks. I can confirm that it works. Now we need the test for
Looks like we need pretty printing by default in terminal and parsable
printing by default in non-terminal with -p to force pretty printing. When
defaulting to pretty printing in terminal, we may need to ignore some flags
only meant for parsable output. Also, a flag to force parsable printing in
Hmm... one flag -s (switch default) should be enough, I think.
On Thu, Jun 19, 2014 at 1:38 PM, Huidae Cho gras...@gmail.com wrote:
Looks like we need pretty printing by default in terminal and parsable
printing by default in non-terminal with -p to force pretty printing. When
defaulting to
IMO, if we replace g.list with g.mlist, it would be better to remove the -p
flag and switch between the pretty output and machine-friendly output based
on isatty(STDOUT_FILENO). In most cases, if the user types a command from
the terminal without redirecting, they want to *see* output, not *parse*
Non-existent mapset fixed in r60749.
Multiple mapsets is not too much, but do we need it? Also, if we implement
multiple mapsets, it would be better semantically to change mapset=.. to
mapset=* for all mapsets in the current location. Martin, do you mind if
I change mapset=.. to mapset=*?
On
On Sun, Jun 8, 2014 at 7:10 AM, Huidae Cho gras...@gmail.com wrote:
Non-existent mapset fixed in r60749.
Thanks. I can confirm that it works. Now we need the test for it.
On Fri, Jun 6, 2014 at 12:18 PM, Vaclav Petras wenzesl...@gmail.com wrote:
By the way, is multiple for mapset a planned
For our records, I'm attaching a new g.mlist main.c, which supports
multiple mapsets. I removed -p/-f and mapset=* mutual exclusiveness, but it
seems to have a problem with M_do_list when there are a small number of
maps in a previous mapset, but there are many in the current one.
For example,
Well, we have a similar problem with the original g.list when one type has
way less maps than others. g.list vect,rast wouldn't show vector maps when
there are a couple of them while there are many raster maps. No body
complained about it so far, so it should be fine, I guess.
On Jun 8, 2014 9:05
G.mlist seems to be tested enough (?), but is someone testing the new
g.mremove (g.mlist interface)? It worked for me at least...
I think it's safe to replace g.list with g.mlist at this point, but I have
a good history of getting reverted ;-). No more votes and 0 vetoes. Good or
bad sign?
On
On Tue, Jun 3, 2014 at 3:43 AM, Huidae Cho gras...@gmail.com wrote:
I tested g.mlist with the attached script. I started from test_g_list.py
and replaced g.list with g.mlist -p and g.list -f with g.mlist -f. g.mlist
passed the test, which means g.list == g.mlist -p g.list -f == g.mlist
-f.
I tested g.mlist with the attached script. I started from test_g_list.py
and replaced g.list with g.mlist -p and g.list -f with g.mlist -f. g.mlist
passed the test, which means g.list == g.mlist -p g.list -f == g.mlist -f.
g.mlist does everything g.list does and provides more functionalities, so
Hi,
2014-06-03 9:43 GMT+02:00 Huidae Cho gras...@gmail.com:
[...]
g.mlist does everything g.list does and provides more functionalities, so do
we want to retire the old g.list and replace it with g.mlist?
+1 (same should be done for g.mremove). Martin
you mean the new g.mremove with the g.mlist interface (
http://trac.osgeo.org/grass/attachment/ticket/2228/g-mremove-main.diff)?
On Tue, Jun 3, 2014 at 4:01 AM, Martin Landa landa.mar...@gmail.com wrote:
Hi,
2014-06-03 9:43 GMT+02:00 Huidae Cho gras...@gmail.com:
[...]
g.mlist does
2014-06-03 10:04 GMT+02:00 Huidae Cho gras...@gmail.com:
you mean the new g.mremove with the g.mlist interface
(http://trac.osgeo.org/grass/attachment/ticket/2228/g-mremove-main.diff)?
I had in mind replacing g.remove with g.mremove, but right,
consolidating interfaces would be also nice...
On Tue, Jun 3, 2014 at 4:08 AM, Martin Landa landa.mar...@gmail.com wrote:
2014-06-03 10:04 GMT+02:00 Huidae Cho gras...@gmail.com:
you mean the new g.mremove with the g.mlist interface
(http://trac.osgeo.org/grass/attachment/ticket/2228/g-mremove-main.diff
)?
I had in mind replacing
Vaclav,
Your test script is working great. I think it's ok to overwrite the first
method because the second one actually tests the new g.mremove anyway. I
deleted the first method and it worked fine.
Huidae
On Tue, Jun 3, 2014 at 9:15 AM, Vaclav Petras wenzesl...@gmail.com wrote:
On Tue,
Hi,
I don't think that there will be any issue but to introduce the idea how
testing can be used, I added a test of the most essential functionality of
g.list. Once g.list is replaced by g.mlist, the test can be used to ensure
that old g.list functionality works as expected. (In fact I used
On 28 May 2014 15:21, Martin Landa landa.mar...@gmail.com wrote:
Hi,
Hi
2014-05-28 15:07 GMT+02:00 Huidae Cho gras...@gmail.com:
Looks great! Personally I don't see a reason to have two versions of
list/remove. Time to replace the old g.list,remove with the g.m* version?
personally I
Hi,
2014-05-25 16:01 GMT+02:00 Huidae Cho gras...@gmail.com:
I thought about the all mapset special character. .. would be more
logical than - because it means go up to the current location and list all
mapsets under it.
done in r60528 (mapset=..). Related question do we need both g.list
and
Looks great! Personally I don't see a reason to have two versions of
list/remove. Time to replace the old g.list,remove with the g.m* version?
On May 28, 2014 4:23 AM, Martin Landa landa.mar...@gmail.com wrote:
Hi,
2014-05-25 16:01 GMT+02:00 Huidae Cho gras...@gmail.com:
I thought about the
Hi,
2014-05-28 15:07 GMT+02:00 Huidae Cho gras...@gmail.com:
Looks great! Personally I don't see a reason to have two versions of
list/remove. Time to replace the old g.list,remove with the g.m* version?
personally I agree, if we decide to do that, it should be done ASAP
(testing in trunk,
Please see http://trac.osgeo.org/grass/ticket/2228 also.
On Wed, May 28, 2014 at 9:21 AM, Martin Landa landa.mar...@gmail.comwrote:
Hi,
2014-05-28 15:07 GMT+02:00 Huidae Cho gras...@gmail.com:
Looks great! Personally I don't see a reason to have two versions of
list/remove. Time to
Hi all,
I would like to modify `g.mlist` to enable listing multiple types from
all mapsets in the given location. Now you can list multiple types
from search path, ie.
$ g.mlist rast,vect -m
raster map(s) available in mapset g6:
x@g6
vector map(s) available in mapset g6:
b@g6
obce6@g6
vector
Martin,
g.mlist already has -t flag for printing element types.
rast/x@g6
vect/b@g6
vect/obce6@g6
vect/kltm50@PERMANENT
Regarding all mapsets search, it should be (1) because a new flag for all
mapsets mapset=. (default for the current mapset) have a conflict meaning
and can be confusing.
Hi,
another option (you might have considered it already) is to allow option
mapset to have multiple inputs. So 2 steps would be needed, first get all
mapsets with g.mapsets -l and then g.mlist with these mapsets. I suppose
you need it for the wxDataCatalog?
Anna
On Sun, May 25, 2014 at 7:45
On Sun, May 25, 2014 at 3:43 AM, Martin Landa landa.mar...@gmail.comwrote:
I would like to modify `g.mlist` to enable listing multiple types from
all mapsets in the given location. Now you can list multiple types
from search path, ie.
This is just a reminder of recent discussions about
More recent discussion about g.mremove at
http://lists.osgeo.org/pipermail/grass-dev/2014-May/068774.html
As I mentioned in the above thread, I prefer the g.mlist interface because
it's easier to add more types and the exclude parameter.
I thought about the all mapset special character. .. would
Hi,
2014-05-25 13:45 GMT+02:00 Huidae Cho gras...@gmail.com:
g.mlist already has -t flag for printing element types.
ooops, I completely overlooked this flag...
Regarding all mapsets search, it should be (1) because a new flag for all
mapsets mapset=. (default for the current mapset) have
Hi,
2014-05-25 15:05 GMT+02:00 Anna Petrášová kratocha...@gmail.com:
another option (you might have considered it already) is to allow option
mapset to have multiple inputs. So 2 steps would be needed, first get all
mapsets with g.mapsets -l and then g.mlist with these mapsets. I suppose you
Hi,
2014-05-25 16:01 GMT+02:00 Huidae Cho gras...@gmail.com:
I thought about the all mapset special character. .. would be more
logical than - because it means go up to the current location and list all
mapsets under it.
good idea, Martin
___
On Sun, May 25, 2014 at 7:45 AM, Huidae Cho gras...@gmail.com wrote:
Regarding all mapsets search, it should be (1) because a new flag for all
mapsets mapset=. (default for the current mapset) have a conflict meaning
and can be confusing. Maybe, mapset=- (minus)?
On the other hand, a flag
35 matches
Mail list logo
