[GRASS-dev] g.list -a

GRASS GIS GRASS GIS developer
1

Hi,

I am trying to implement the wish [1]. I found a strange construction
in g.list module. The -f flag (full listing) calls the external
program $GISBASE/etc/lister/[cell|vector]. These little programs are
called only in g.list -f (I think).

I rewrote g.list without calling any external program -- i.e. I moved
functions from lister directory to lib/lister.c. If there are no
serious objections I will commit it to CVS.

GRASS 6.3.cvs (spearfish60):~/grass6 > g.list rast,region
----------------------------------------------
raster files available in mapset PERMANENT:
aspect bugsites density elevation.10m elevation.dem
elevation.dted erode.index erosion1 fields geology
landcover.30m landcover.orig landuse owner quads
railroads roads rstrct.areas rushmore slope
soil.br.depth soils soils.Kfactor soils.Tfactor soils.ph
soils.range spot.image streams strm.dist texture
tractids transport.misc trn.sites uparea vegcover

----------------------------------------------
region definition files available in mapset PERMANENT:
9961 county gism_temp_region previous_zoom
subregion.NW

----------------------------------------------

Best regards, Martin

[1] https://intevation.de/rt/webrt?serial_num=3178

--
Martin Landa <landa.martin@gmail.com> * http://gama.fsv.cvut.cz/~landa *

(attachments)

g_list_a.tar.gz (2.65 KB)

2

Martin Landa wrote:

I am trying to implement the wish [1]. I found a strange construction
in g.list module. The -f flag (full listing) calls the external
program $GISBASE/etc/lister/[cell|vector]. These little programs are
called only in g.list -f (I think).

I rewrote g.list without calling any external program -- i.e. I moved
functions from lister directory to lib/lister.c. If there are no
serious objections I will commit it to CVS.

Don't remove the existing functionality; add a new switch for using
your built-in lister.

--
Glynn Clements <glynn@gclements.plus.com>

3

Hi Glynn,

this patch does not remove any functionality (AFAIK). The only change
is: the functionality of lister (programs) is moved to lib/lister.c. I
don't see any reason why to have this functionality (the -f flag)
outside of the g.list (/etc/lister/[cell|vector]). Maybe there is a
particular reason for this construction, please let me know. Thanks!

Best, Martin

PS: The external lister do only one thing -- calls G_list_element ()
with a give pointer to lister function.

PS1: Fixed patch attached.

2006/12/24, Glynn Clements <glynn@gclements.plus.com>:

Martin Landa wrote:

> I am trying to implement the wish [1]. I found a strange construction
> in g.list module. The -f flag (full listing) calls the external
> program $GISBASE/etc/lister/[cell|vector]. These little programs are
> called only in g.list -f (I think).
>
> I rewrote g.list without calling any external program -- i.e. I moved
> functions from lister directory to lib/lister.c. If there are no
> serious objections I will commit it to CVS.

Don't remove the existing functionality; add a new switch for using
your built-in lister.

--
Glynn Clements <glynn@gclements.plus.com>

--
Martin Landa <landa.martin@gmail.com> * http://gama.fsv.cvut.cz/~landa *

(attachments)

g_list_a-1.tar.gz (2.65 KB)

4

Martin Landa wrote:

> > I am trying to implement the wish [1]. I found a strange construction
> > in g.list module. The -f flag (full listing) calls the external
> > program $GISBASE/etc/lister/[cell|vector]. These little programs are
> > called only in g.list -f (I think).
> >
> > I rewrote g.list without calling any external program -- i.e. I moved
> > functions from lister directory to lib/lister.c. If there are no
> > serious objections I will commit it to CVS.
>
> Don't remove the existing functionality; add a new switch for using
> your built-in lister.

this patch does not remove any functionality (AFAIK). The only change
is: the functionality of lister (programs) is moved to lib/lister.c. I
don't see any reason why to have this functionality (the -f flag)
outside of the g.list (/etc/lister/[cell|vector]). Maybe there is a
particular reason for this construction, please let me know. Thanks!

The user can install lister programs for other types and/or replace
existing ones.

The point of -f isn't so much to provide specific additional
functionality, but to allow the handling to be deferred to an external
program.

--
Glynn Clements <glynn@gclements.plus.com>

5

Hi,

2006/12/27, Glynn Clements <glynn@gclements.plus.com>:

Martin Landa wrote:

> > > I am trying to implement the wish [1]. I found a strange construction
> > > in g.list module. The -f flag (full listing) calls the external
> > > program $GISBASE/etc/lister/[cell|vector]. These little programs are
> > > called only in g.list -f (I think).
> > >
> > > I rewrote g.list without calling any external program -- i.e. I moved
> > > functions from lister directory to lib/lister.c. If there are no
> > > serious objections I will commit it to CVS.
> >
> > Don't remove the existing functionality; add a new switch for using
> > your built-in lister.
>
> this patch does not remove any functionality (AFAIK). The only change
> is: the functionality of lister (programs) is moved to lib/lister.c. I
> don't see any reason why to have this functionality (the -f flag)
> outside of the g.list (/etc/lister/[cell|vector]). Maybe there is a
> particular reason for this construction, please let me know. Thanks!

The user can install lister programs for other types and/or replace
existing ones.

OK, it makes sense to me (only it's hard to imagine an user how
installs other lister program instead of changing the code;-)

The point of -f isn't so much to provide specific additional
functionality, but to allow the handling to be deferred to an external
program.

You are right, I have tried to change the patch in this way, not sure
if I am working with child process as I should have. In any case
g.list works:-)

Martin

--
Glynn Clements <glynn@gclements.plus.com>

--
Martin Landa <landa.martin@gmail.com> * http://gama.fsv.cvut.cz/~landa *

(attachments)

g_list_a-2.diff.gz (2.48 KB)

6

Hi,

I have just one general (maybe a little bit silly;-) question. There
are number of modules which follow this pattern:

* there is one (determinative) parameter (e.g. type in g.list)
* and the flag for all types (e.g. -a -- List all data types)

I can see two distinct approaches:

1) the determinative parameter is requested

-> usage: g.list -a type=

This is more precise for parsing syntax of the module, I think. On the
other hand a little bit confusing for the user.

2) the determinative parameter is not requested

-> usage: g.list -a

This construction is more clear for the user I hope. But it cause more
problems for programmer -- there is a need to handle meaningless usage
of the module, e.g. g.list -f (verbose listing).

I am not sure which approach is better.

Best regards, Martin

2006/12/27, Martin Landa <landa.martin@gmail.com>:

Hi,

2006/12/27, Glynn Clements <glynn@gclements.plus.com>:
>
> Martin Landa wrote:
>
> > > > I am trying to implement the wish [1]. I found a strange construction
> > > > in g.list module. The -f flag (full listing) calls the external
> > > > program $GISBASE/etc/lister/[cell|vector]. These little programs are
> > > > called only in g.list -f (I think).
> > > >
> > > > I rewrote g.list without calling any external program -- i.e. I moved
> > > > functions from lister directory to lib/lister.c. If there are no
> > > > serious objections I will commit it to CVS.
> > >
> > > Don't remove the existing functionality; add a new switch for using
> > > your built-in lister.
> >
> > this patch does not remove any functionality (AFAIK). The only change
> > is: the functionality of lister (programs) is moved to lib/lister.c. I
> > don't see any reason why to have this functionality (the -f flag)
> > outside of the g.list (/etc/lister/[cell|vector]). Maybe there is a
> > particular reason for this construction, please let me know. Thanks!
>

> The user can install lister programs for other types and/or replace
> existing ones.

OK, it makes sense to me (only it's hard to imagine an user how
installs other lister program instead of changing the code;-)

> The point of -f isn't so much to provide specific additional
> functionality, but to allow the handling to be deferred to an external
> program.

You are right, I have tried to change the patch in this way, not sure
if I am working with child process as I should have. In any case
g.list works:-)

Martin

> --
> Glynn Clements <glynn@gclements.plus.com>
>

--
Martin Landa <landa.martin@gmail.com> * http://gama.fsv.cvut.cz/~landa *

--
Martin Landa <landa.martin@gmail.com> * http://gama.fsv.cvut.cz/~landa *

7

How about g.list type=any or g.list type=all?

2c.

On 12/28/06, Martin Landa <landa.martin@gmail.com> wrote:

Hi,

I have just one general (maybe a little bit silly;-) question. There
are number of modules which follow this pattern:

* there is one (determinative) parameter (e.g. type in g.list)
* and the flag for all types (e.g. -a -- List all data types)

I can see two distinct approaches:

1) the determinative parameter is requested

-> usage: g.list -a type=

This is more precise for parsing syntax of the module, I think. On the
other hand a little bit confusing for the user.

2) the determinative parameter is not requested

-> usage: g.list -a

This construction is more clear for the user I hope. But it cause more
problems for programmer -- there is a need to handle meaningless usage
of the module, e.g. g.list -f (verbose listing).

I am not sure which approach is better.

Best regards, Martin

2006/12/27, Martin Landa <landa.martin@gmail.com>:
> Hi,
>
> 2006/12/27, Glynn Clements <glynn@gclements.plus.com>:
> >
> > Martin Landa wrote:
> >
> > > > > I am trying to implement the wish [1]. I found a strange construction
> > > > > in g.list module. The -f flag (full listing) calls the external
> > > > > program $GISBASE/etc/lister/[cell|vector]. These little programs are
> > > > > called only in g.list -f (I think).
> > > > >
> > > > > I rewrote g.list without calling any external program -- i.e. I moved
> > > > > functions from lister directory to lib/lister.c. If there are no
> > > > > serious objections I will commit it to CVS.
> > > >
> > > > Don't remove the existing functionality; add a new switch for using
> > > > your built-in lister.
> > >
> > > this patch does not remove any functionality (AFAIK). The only change
> > > is: the functionality of lister (programs) is moved to lib/lister.c. I
> > > don't see any reason why to have this functionality (the -f flag)
> > > outside of the g.list (/etc/lister/[cell|vector]). Maybe there is a
> > > particular reason for this construction, please let me know. Thanks!
> >
>
> > The user can install lister programs for other types and/or replace
> > existing ones.
>
> OK, it makes sense to me (only it's hard to imagine an user how
> installs other lister program instead of changing the code;-)
>
> > The point of -f isn't so much to provide specific additional
> > functionality, but to allow the handling to be deferred to an external
> > program.
>
> You are right, I have tried to change the patch in this way, not sure
> if I am working with child process as I should have. In any case
> g.list works:-)
>
> Martin
>
> > --
> > Glynn Clements <glynn@gclements.plus.com>
> >
>
> --
> Martin Landa <landa.martin@gmail.com> * http://gama.fsv.cvut.cz/~landa *
>

--
Martin Landa <landa.martin@gmail.com> * http://gama.fsv.cvut.cz/~landa *

_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev

--
-- Daniel Calvelo Aros

8

Hi,

it is nice idea but there is one problem. The data type list is common
for related modules, e.g. g.remove, g.copy, etc. It would affect them
also...

Martin

2007/1/3, Daniel Calvelo <dca.gis@gmail.com>:

How about g.list type=any or g.list type=all?

2c.

On 12/28/06, Martin Landa <landa.martin@gmail.com> wrote:
> Hi,
>
> I have just one general (maybe a little bit silly;-) question. There
> are number of modules which follow this pattern:
>
> * there is one (determinative) parameter (e.g. type in g.list)
> * and the flag for all types (e.g. -a -- List all data types)
>
> I can see two distinct approaches:
>
> 1) the determinative parameter is requested
>
> -> usage: g.list -a type=
>
> This is more precise for parsing syntax of the module, I think. On the
> other hand a little bit confusing for the user.
>
> 2) the determinative parameter is not requested
>
> -> usage: g.list -a
>
> This construction is more clear for the user I hope. But it cause more
> problems for programmer -- there is a need to handle meaningless usage
> of the module, e.g. g.list -f (verbose listing).
>
> I am not sure which approach is better.
>
> Best regards, Martin
>
> 2006/12/27, Martin Landa <landa.martin@gmail.com>:
> > Hi,
> >
> > 2006/12/27, Glynn Clements <glynn@gclements.plus.com>:
> > >
> > > Martin Landa wrote:
> > >
> > > > > > I am trying to implement the wish [1]. I found a strange construction
> > > > > > in g.list module. The -f flag (full listing) calls the external
> > > > > > program $GISBASE/etc/lister/[cell|vector]. These little programs are
> > > > > > called only in g.list -f (I think).
> > > > > >
> > > > > > I rewrote g.list without calling any external program -- i.e. I moved
> > > > > > functions from lister directory to lib/lister.c. If there are no
> > > > > > serious objections I will commit it to CVS.
> > > > >
> > > > > Don't remove the existing functionality; add a new switch for using
> > > > > your built-in lister.
> > > >
> > > > this patch does not remove any functionality (AFAIK). The only change
> > > > is: the functionality of lister (programs) is moved to lib/lister.c. I
> > > > don't see any reason why to have this functionality (the -f flag)
> > > > outside of the g.list (/etc/lister/[cell|vector]). Maybe there is a
> > > > particular reason for this construction, please let me know. Thanks!
> > >
> >
> > > The user can install lister programs for other types and/or replace
> > > existing ones.
> >
> > OK, it makes sense to me (only it's hard to imagine an user how
> > installs other lister program instead of changing the code;-)
> >
> > > The point of -f isn't so much to provide specific additional
> > > functionality, but to allow the handling to be deferred to an external
> > > program.
> >
> > You are right, I have tried to change the patch in this way, not sure
> > if I am working with child process as I should have. In any case
> > g.list works:-)
> >
> > Martin
> >
> > > --
> > > Glynn Clements <glynn@gclements.plus.com>
> > >
> >
> > --
> > Martin Landa <landa.martin@gmail.com> * http://gama.fsv.cvut.cz/~landa *
> >
>
> --
> Martin Landa <landa.martin@gmail.com> * http://gama.fsv.cvut.cz/~landa *
>
> _______________________________________________
> grass-dev mailing list
> grass-dev@grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass-dev
>

--
-- Daniel Calvelo Aros

--
Martin Landa <landa.martin@gmail.com> * http://gama.fsv.cvut.cz/~landa *

9

[me]

How about g.list type=any or g.list type=all?

[Martin]

it is nice idea but there is one problem. The data type list is common
for related modules, e.g. g.remove, g.copy, etc. It would affect them
also...

Don't you think it might be helpful there as well?

I agree it is some more work to get the semantics and implementation
right in all the actual cases, but I've the feeling it might be of
some use...

Daniel.

10

Daniel Calvelo wrote:

[me]
> How about g.list type=any or g.list type=all?

[Martin]
> it is nice idea but there is one problem. The data type list is common
> for related modules, e.g. g.remove, g.copy, etc. It would affect them
> also...

Don't you think it might be helpful there as well?

It's used differently; g.list has a type= option where the valid
option values are the types, while g.remove, g.rename and g.copy have
a separate option for each type.

In terms of implementing "g.list type=all", the obvious first step
would be to add element->multiple=YES to the type= option so that you
can do e.g. "g.list type=rast,vect". Once that was done, it would be
relatively straightforward to allow "type=all".

--
Glynn Clements <glynn@gclements.plus.com>

11

Hi,

2007/1/6, Glynn Clements <glynn@gclements.plus.com>:

[snip]

It's used differently; g.list has a type= option where the valid
option values are the types, while g.remove, g.rename and g.copy have
a separate option for each type.

In terms of implementing "g.list type=all", the obvious first step
would be to add element->multiple=YES to the type= option so that you
can do e.g. "g.list type=rast,vect". Once that was done, it would be
relatively straightforward to allow "type=all".

well, the new data type 'all' would be useful. I can imagine, for
example `g.copy all=r,r1` or `g.remove all=r`, etc.

I have modified the last patch according to that (removing -a flag).
Do you think it could be committed to CVS. Other manage module will
support this feature soon.

Regards, Martin

--
Martin Landa <landa.martin@gmail.com> * http://gama.fsv.cvut.cz/~landa *

(attachments)

g_list_all-3.diff.gz (2.9 KB)

12

Martin Landa wrote:

> It's used differently; g.list has a type= option where the valid
> option values are the types, while g.remove, g.rename and g.copy have
> a separate option for each type.
>
> In terms of implementing "g.list type=all", the obvious first step
> would be to add element->multiple=YES to the type= option so that you
> can do e.g. "g.list type=rast,vect". Once that was done, it would be
> relatively straightforward to allow "type=all".

well, the new data type 'all' would be useful. I can imagine, for
example `g.copy all=r,r1` or `g.remove all=r`, etc.

I can't imagine that ever being useful. Or, rather, I can imagine the
danger far exceeding the usefulness, e.g. using "g.remove all=foo" as
a shorthand for "g.remove rast=foo ; g.remove vect=foo" and forgetting
that you had a region, icon, etc named "foo" which you didn't want to
delete.

--
Glynn Clements <glynn@gclements.plus.com>

13

Hi,

2007/1/7, Glynn Clements <glynn@gclements.plus.com>:

[snip]

> well, the new data type 'all' would be useful. I can imagine, for
> example `g.copy all=r,r1` or `g.remove all=r`, etc.

I can't imagine that ever being useful. Or, rather, I can imagine the
danger far exceeding the usefulness, e.g. using "g.remove all=foo" as
a shorthand for "g.remove rast=foo ; g.remove vect=foo" and forgetting
that you had a region, icon, etc named "foo" which you didn't want to
delete.

well, you are right, of course it could be too dangerous feature. On
the other hand the user should know what he/she is doing;-) I can see

1) the special flag in g.list (-a -> all types) Q: the 'type'
parameter should be requested or not requested?

2) the new data type 'all', Q: Should or shouldn't be avoided in other
manage modules (like g.remove, g.copy)?

3) ... ?

Not sure what is better or more useful. If we don't want to use 'all'
in other modules (e.g. g.copy) I think the flag (1) would be (maybe)
better.

Martin
--
Martin Landa <landa.martin@gmail.com> * http://gama.fsv.cvut.cz/~landa *

14

On 1/7/07, Martin Landa <landa.martin@gmail.com> wrote:

[...]

1) the special flag in g.list (-a -> all types) Q: the 'type'
parameter should be requested or not requested?

2) the new data type 'all', Q: Should or shouldn't be avoided in other
manage modules (like g.remove, g.copy)?

3) ... ?

Not sure what is better or more useful. If we don't want to use 'all'
in other modules (e.g. g.copy) I think the flag (1) would be (maybe)
better.

If it is only useful in g.list, are there any reasons against creating
a script g.list.all without options and well-structured output (i.e.
parseable)?

Daniel.

15

Daniel Calvelo wrote:

On 1/7/07, Martin Landa <landa.martin@gmail.com> wrote:

[...]

1) the special flag in g.list (-a -> all types) Q: the 'type'
parameter should be requested or not requested?

2) the new data type 'all', Q: Should or shouldn't be avoided in other
manage modules (like g.remove, g.copy)?

3) ... ?

Not sure what is better or more useful. If we don't want to use 'all'
in other modules (e.g. g.copy) I think the flag (1) would be (maybe)
better.

If it is only useful in g.list, are there any reasons against creating
a script g.list.all without options and well-structured output (i.e.
parseable)?

Or maybe add option type=all to g.mlist?

Maciek

16

Martin Landa wrote:

I can see

1) the special flag in g.list (-a -> all types) Q: the 'type'
parameter should be requested or not requested?

From an implementation perspective, there is negligible difference

between adding a -a flag or allowing a value of "all" for the type.

The main difference is that a "-a" flag means that you need to remove
the "required" attribute from the option and manually check that
either -a or type= was given.

2) the new data type 'all', Q: Should or shouldn't be avoided in other
manage modules (like g.remove, g.copy)?

It doesn't make sense for the other modules, and might be problematic
to implement; you would either have to perform a separate existence
check for each type or ensure that non-existence of a particular type
is handle correctly (e.g. "g.copy all=foo,foo2" *shouldn't* print a
bunch of warnings: "no region named 'foo'", "no icon named 'foo'",
...).

Not sure what is better or more useful. If we don't want to use 'all'
in other modules (e.g. g.copy) I think the flag (1) would be (maybe)
better.

Even if you used "all" in every module, you would still have to treat
it separately; adding an "all" entry to etc/element_list wouldn't
work. So, I don't really see much difference between:

  if (flag_a->answer)
    ...
and:
  if (strcmp(element->answer, "all") == 0)
    ...

in g.list.

Actually, I'd favour the latter, as that leaves the
"element->required = YES" intact, which makes the "g.list help" output
a bit more informative. The help output (and HTML/XML output, the
Tcl/Tk GUI etc) automatically indicates if a specific option is
required, while manual either/or checks have to be documented
manually and cannot be enforced by the GUI.

--
Glynn Clements <glynn@gclements.plus.com>

17

Hi,

2007/1/8, Glynn Clements <glynn@gclements.plus.com>:

> 1) the special flag in g.list (-a -> all types) Q: the 'type'
> parameter should be requested or not requested?

From an implementation perspective, there is negligible difference
between adding a -a flag or allowing a value of "all" for the type.

The main difference is that a "-a" flag means that you need to remove
the "required" attribute from the option and manually check that
either -a or type= was given.

> 2) the new data type 'all', Q: Should or shouldn't be avoided in other
> manage modules (like g.remove, g.copy)?

It doesn't make sense for the other modules, and might be problematic
to implement; you would either have to perform a separate existence
check for each type or ensure that non-existence of a particular type
is handle correctly (e.g. "g.copy all=foo,foo2" *shouldn't* print a
bunch of warnings: "no region named 'foo'", "no icon named 'foo'",
...).

> Not sure what is better or more useful. If we don't want to use 'all'
> in other modules (e.g. g.copy) I think the flag (1) would be (maybe)
> better.

Even if you used "all" in every module, you would still have to treat
it separately; adding an "all" entry to etc/element_list wouldn't
work. So, I don't really see much difference between:

        if (flag_a->answer)
                ...
and:
        if (strcmp(element->answer, "all") == 0)
                ...

in g.list.

Actually, I'd favour the latter, as that leaves the
"element->required = YES" intact, which makes the "g.list help" output
a bit more informative. The help output (and HTML/XML output, the
Tcl/Tk GUI etc) automatically indicates if a specific option is
required, while manual either/or checks have to be documented
manually and cannot be enforced by the GUI.

OK, your argumentation seems to be right.

1) Q: allowing multiple data type would be useful for the user - is it desired ?
e.g. type=rast,vect,region

2) It seems better to add the type 'all' to g.list manually
(especially because of the requested type parameter). I am not sure
how to do it in an elegant way (see the patch) - my approach seems to
be very ugly.

Any objections or suggestions?

Martin

--
Martin Landa <landa.martin@gmail.com> * http://gama.fsv.cvut.cz/~landa *

(attachments)

g_list_all-4.diff.gz (2.86 KB)

18

Hi,

2007/1/8, Maciej Sieczka <tutey@o2.pl>:

Or maybe add option type=all to g.mlist?

it is good idea (personally I am not sure if the type for all data
types should be implemented in g.list). In any case g.mlist should be
updated according to the changes in g.list (i.e. multiple type
parameter).

Martin

--
Martin Landa <landa.martin@gmail.com> * http://gama.fsv.cvut.cz/~landa *

19

Martin Landa wrote:

1) Q: allowing multiple data type would be useful for the user - is it desired ?
e.g. type=rast,vect,region

I think so.

Once g.list can list all types, making it list an arbitrary set of
types is simple enough.

2) It seems better to add the type 'all' to g.list manually
(especially because of the requested type parameter). I am not sure
how to do it in an elegant way (see the patch) - my approach seems to
be very ugly.

I would abandon the approach of having a separate "parse" function in
favour of iterating over element->answers and listing each type as
it's encountered.

lib/do_list.c doesn't need to change; just have cmd/list.c call
do_list() once for each type.

--
Glynn Clements <glynn@gclements.plus.com>

20

Hi Glynn,

2007/1/9, Glynn Clements <glynn@gclements.plus.com>:

[snip]

> 2) It seems better to add the type 'all' to g.list manually
> (especially because of the requested type parameter). I am not sure
> how to do it in an elegant way (see the patch) - my approach seems to
> be very ugly.

I would abandon the approach of having a separate "parse" function in
favour of iterating over element->answers and listing each type as
it's encountered.

well, I have tried to simplify the patch. Functions parse() &
do_list() are now called for each element->answers[i]. I hope it is
better now.

lib/do_list.c doesn't need to change; just have cmd/list.c call
do_list() once for each type.

I think that fn do_list() have to be rewritten because of the -f flags
(calling of execl() fn) ?

Martin

--
Glynn Clements <glynn@gclements.plus.com>

--
Martin Landa <landa.martin@gmail.com> * http://gama.fsv.cvut.cz/~landa *

(attachments)

g_list_all-5.diff.gz (2.42 KB)