Re: Functional programming with GLib

[Joël Krähemann]

Hi

Why not doing a different approach? Provide serialization to your list
and pass it to AgsFunction?

I would love to see something alike in GSequencer. Thus I did a boxed
type AgsComplex.
The mention object above shall be able to solve mathematical equations.

Note I is not implemented for now. But feel free to provide solver strategies ;)
The goal is to let the user describe its synth by a formula.

nongnu.org/gsequencer

Bests,
Joël


On Sun, Apr 23, 2017 at 8:46 PM, Dirk-Jan C. Binnema
<djcb.b...@gmail.com> wrote:
>
> Hi All,
>
> A while back, I wrote some functions for functional-flavored programming
> with GLib. It's fully documented[1], has tests, etc.
>
> It would (for me at least) be useful to have some of these functions in
> GLib-proper, but I suspect the GLib-maintainers are not /too/ eager to
> accept contributions to GList... anyway, perhaps its useful for others.
>
> As a simple example, suppose we want to calculate the sum of primes up
> to 100 (a common task after all):
>
> ,
> | intsum;
> | GList *nums, *primes;
> |
> | nums   = gx_list_iota (100, 1, 1);
> | primes = gx_list_filter (nums, (GXPred)gx_is_prime, NULL);
> | sum= gx_list_sum (primes); /* => 1060 */
> |
> | g_list_free (nums);
> | g_list_free (primes);
> `
>
> There's also folding, mapping etc. See a short article about this:
>http://www.djcbsoftware.nl/2015/10/04/functional-glists/
> (2015?! time does fly). Am still developing it though.
>
> Repo: https://github.com/djcb/gxlib
> Docs: http://www.djcbsoftware.nl/code/gxlib/
>
> Best wishes,
> Dirk.
>
> --
> Dirk-Jan C. Binnema  Helsinki, Finland
> e:d...@djcbsoftware.nl   w:www.djcbsoftware.nl
> pgp: D09C E664 897D 7D39 5047 A178 E96A C7A1 017D DA3C
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Functional programming with GLib

[Stefan Sauer]

Am 09.05.2017 um 10:59 schrieb Tristan Van Berkom:
> On Mon, 2017-05-01 at 19:09 -0400, Matthias Clasen wrote:
>>
>>
>> On Thu, Apr 27, 2017 at 10:29 AM, Emmanuele Bassi 
>> wrote:
>>> For command line parsing I'd actually favour a slightly bolder
>>> approach of deprecating GOptionContext, and having something
>>> slightly
>>> more modern — in terms of being bindable in other languages, and
>>> well-integrated with API like GApplication.
>>>
>>
>> What is lacking in the current incarnation of commandline option
>> support in GApplication? 
> 
> Since this was raised here and I've currently been working with
> python's click library and trying to make some enhancements there, just
> thought I'd throw some things out there.
> 
> Some things that I'm finding important for CLI apps:
> 
> A.) Automatic generation of man pages and similar documentation,
> especially generating separate man pages for each separate sub
> command.
> 
> I'm not even sure, do we have this already ?

You can document your man page using gtkdoc (with a PROGRAM section). More
introspection would be nice though.

> 
> B.) Built-in support for bash completions, allowing optional overrides
> for the application to implement custom completion suggestions
> for selected options/arguments.
> 
> 
> This is all probably possible without completely replacing the API with
> a new one, though.
> 
> Cheers,
> -Tristan
> 
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
> 

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Functional programming with GLib

[Matthias Clasen]

On Tue, May 9, 2017 at 4:59 AM, Tristan Van Berkom <
tristan.vanber...@codethink.co.uk> wrote:

>
> Some things that I'm finding important for CLI apps:
>
> A.) Automatic generation of man pages and similar documentation,
> especially generating separate man pages for each separate sub
> command.
>
> I'm not even sure, do we have this already ?
>

I fail to see the value of a man page that just repeats what --help already
tells me.  Why is this useful ?


> B.) Built-in support for bash completions, allowing optional overrides
> for the application to implement custom completion suggestions
> for selected options/arguments.
>

This on the other hand, is very useful. But hard to do in a way that is
generic enough for all possible styles of
commandline interface that people have built with GOption. Do you have a
suggestion for this ?
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Functional programming with GLib

[Tristan Van Berkom]

On Mon, 2017-05-01 at 19:09 -0400, Matthias Clasen wrote:
> 
> 
> On Thu, Apr 27, 2017 at 10:29 AM, Emmanuele Bassi 
> wrote:
> > For command line parsing I'd actually favour a slightly bolder
> > approach of deprecating GOptionContext, and having something
> > slightly
> > more modern — in terms of being bindable in other languages, and
> > well-integrated with API like GApplication.
> > 
> 
> What is lacking in the current incarnation of commandline option
> support in GApplication? 

Since this was raised here and I've currently been working with
python's click library and trying to make some enhancements there, just
thought I'd throw some things out there.

Some things that I'm finding important for CLI apps:

A.) Automatic generation of man pages and similar documentation,
    especially generating separate man pages for each separate sub
    command.

    I'm not even sure, do we have this already ?

B.) Built-in support for bash completions, allowing optional overrides
    for the application to implement custom completion suggestions
    for selected options/arguments.


This is all probably possible without completely replacing the API with
a new one, though.

Cheers,
    -Tristan

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Functional programming with GLib

[Emmanuele Bassi]

On 2 May 2017 at 00:09, Matthias Clasen  wrote:

> On Thu, Apr 27, 2017 at 10:29 AM, Emmanuele Bassi  wrote:
>>
>> For command line parsing I'd actually favour a slightly bolder
>> approach of deprecating GOptionContext, and having something slightly
>> more modern — in terms of being bindable in other languages, and
>> well-integrated with API like GApplication.
>>
>
> What is lacking in the current incarnation of commandline option support in
> GApplication?

In general, a nicer API that does not rely on
GOptionEntry/GOptionGroup, which are barely introspectable, or that
does not rely on calling g_application_add_main_option() for every
single option in order to avoid the memory management weirdness of
GOptionEntry.

The other issue is that the command line options are accessible using
the GVariant API as a dictionary, which requires additional
translation into application data structures; you need to use
g_variant_dict_lookup(), which is not the nicest API in the world;
high level languages may be able to unpack the GVariantDict, but I'm
not entirely sure if that's actually the case.

Adding command line parsing in JavaScript based on the GLib API (since
JS does not have a "native" module to do that, like Python's
ArgParser) is usually pretty rough; I'd like to see something better
in that area.

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Functional programming with GLib

[Matthias Clasen]

On Thu, Apr 27, 2017 at 10:29 AM, Emmanuele Bassi  wrote:

> For command line parsing I'd actually favour a slightly bolder
> approach of deprecating GOptionContext, and having something slightly
> more modern — in terms of being bindable in other languages, and
> well-integrated with API like GApplication.
>
>
What is lacking in the current incarnation of commandline option support in
GApplication?
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Functional programming with GLib

[Philip Withnall]

I was thinking about that, but then fell into the trap of worrying
about suggesting it because someone might expect me to implement it.

I agree though; a reworking of GOptionContext which integrates better
with GApplication, supports sub-commands and supports custom argument
formats more easily would be lovely. Drawing inspiration from python-
argparse would also be good.

Philip

On Thu, 2017-04-27 at 15:29 +0100, Emmanuele Bassi wrote:
> For command line parsing I'd actually favour a slightly bolder
> approach of deprecating GOptionContext, and having something slightly
> more modern — in terms of being bindable in other languages, and
> well-integrated with API like GApplication.
> 
> For instance, something similar to [clap.rs][0].
> 
> Ciao,
>  Emmanuele.
> 
> [0]: https://clap.rs/
> 
> On 27 April 2017 at 15:15, Philip Withnall <phi...@tecnocode.co.uk>
> wrote:
> > Hey,
> > 
> > The general policy for GLib is that utility functions which are
> > useful
> > (and used in) several projects are considered for being added to
> > GLib.
> > 
> > To me, a functional programming approach using GLists is not
> > something
> > which every project is going to use. Is there any harm in keeping
> > it as
> > a separate library? There’s nothing stopping projects from linking
> > to
> > GLib *and* GXLib. :-)
> > 
> > The command line parsing stuff you have looks a bit more widely
> > applicable. Were you considering merging those into GLib?
> > 
> > http://www.djcbsoftware.nl/code/gxlib/gxlib-Command-line-parsing.ht
> > ml
> > 
> > Anyway, nice work on GXLib. It looks well documented.
> > 
> > Philip
> > 
> > On Sun, 2017-04-23 at 21:46 +0300, Dirk-Jan C. Binnema wrote:
> > > Hi All,
> > > 
> > > A while back, I wrote some functions for functional-flavored
> > > programming
> > > with GLib. It's fully documented[1], has tests, etc.
> > > 
> > > It would (for me at least) be useful to have some of these
> > > functions
> > > in
> > > GLib-proper, but I suspect the GLib-maintainers are not /too/
> > > eager
> > > to
> > > accept contributions to GList... anyway, perhaps its useful for
> > > others.
> > > 
> > > As a simple example, suppose we want to calculate the sum of
> > > primes
> > > up
> > > to 100 (a common task after all):
> > > 
> > > ,
> > > > intsum;
> > > > GList *nums, *primes;
> > > > 
> > > > nums   = gx_list_iota (100, 1, 1);
> > > > primes = gx_list_filter (nums, (GXPred)gx_is_prime, NULL);
> > > > sum= gx_list_sum (primes); /* => 1060 */
> > > > 
> > > > g_list_free (nums);
> > > > g_list_free (primes);
> > > 
> > > `
> > > 
> > > There's also folding, mapping etc. See a short article about
> > > this:
> > >    http://www.djcbsoftware.nl/2015/10/04/functional-glists/
> > > (2015?! time does fly). Am still developing it though.
> > > 
> > > Repo: https://github.com/djcb/gxlib
> > > Docs: http://www.djcbsoftware.nl/code/gxlib/
> > > 
> > > Best wishes,
> > > Dirk.
> > > 
> > 
> > ___
> > gtk-devel-list mailing list
> > gtk-devel-list@gnome.org
> > https://mail.gnome.org/mailman/listinfo/gtk-devel-list
> > 
> 
> 
> 

signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Functional programming with GLib

[Emmanuele Bassi]

For command line parsing I'd actually favour a slightly bolder
approach of deprecating GOptionContext, and having something slightly
more modern — in terms of being bindable in other languages, and
well-integrated with API like GApplication.

For instance, something similar to [clap.rs][0].

Ciao,
 Emmanuele.

[0]: https://clap.rs/

On 27 April 2017 at 15:15, Philip Withnall <phi...@tecnocode.co.uk> wrote:
> Hey,
>
> The general policy for GLib is that utility functions which are useful
> (and used in) several projects are considered for being added to GLib.
>
> To me, a functional programming approach using GLists is not something
> which every project is going to use. Is there any harm in keeping it as
> a separate library? There’s nothing stopping projects from linking to
> GLib *and* GXLib. :-)
>
> The command line parsing stuff you have looks a bit more widely
> applicable. Were you considering merging those into GLib?
>
> http://www.djcbsoftware.nl/code/gxlib/gxlib-Command-line-parsing.html
>
> Anyway, nice work on GXLib. It looks well documented.
>
> Philip
>
> On Sun, 2017-04-23 at 21:46 +0300, Dirk-Jan C. Binnema wrote:
>> Hi All,
>>
>> A while back, I wrote some functions for functional-flavored
>> programming
>> with GLib. It's fully documented[1], has tests, etc.
>>
>> It would (for me at least) be useful to have some of these functions
>> in
>> GLib-proper, but I suspect the GLib-maintainers are not /too/ eager
>> to
>> accept contributions to GList... anyway, perhaps its useful for
>> others.
>>
>> As a simple example, suppose we want to calculate the sum of primes
>> up
>> to 100 (a common task after all):
>>
>> ,
>> > intsum;
>> > GList *nums, *primes;
>> >
>> > nums   = gx_list_iota (100, 1, 1);
>> > primes = gx_list_filter (nums, (GXPred)gx_is_prime, NULL);
>> > sum= gx_list_sum (primes); /* => 1060 */
>> >
>> > g_list_free (nums);
>> > g_list_free (primes);
>>
>> `
>>
>> There's also folding, mapping etc. See a short article about this:
>>http://www.djcbsoftware.nl/2015/10/04/functional-glists/
>> (2015?! time does fly). Am still developing it though.
>>
>> Repo: https://github.com/djcb/gxlib
>> Docs: http://www.djcbsoftware.nl/code/gxlib/
>>
>> Best wishes,
>> Dirk.
>>
>
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
>



-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Functional programming with GLib

[Philip Withnall]

Hey,

The general policy for GLib is that utility functions which are useful
(and used in) several projects are considered for being added to GLib.

To me, a functional programming approach using GLists is not something
which every project is going to use. Is there any harm in keeping it as
a separate library? There’s nothing stopping projects from linking to
GLib *and* GXLib. :-)

The command line parsing stuff you have looks a bit more widely
applicable. Were you considering merging those into GLib?

http://www.djcbsoftware.nl/code/gxlib/gxlib-Command-line-parsing.html

Anyway, nice work on GXLib. It looks well documented.

Philip

On Sun, 2017-04-23 at 21:46 +0300, Dirk-Jan C. Binnema wrote:
> Hi All,
> 
> A while back, I wrote some functions for functional-flavored
> programming
> with GLib. It's fully documented[1], has tests, etc.
> 
> It would (for me at least) be useful to have some of these functions
> in
> GLib-proper, but I suspect the GLib-maintainers are not /too/ eager
> to
> accept contributions to GList... anyway, perhaps its useful for
> others.
> 
> As a simple example, suppose we want to calculate the sum of primes
> up
> to 100 (a common task after all):
> 
> ,
> > intsum;
> > GList *nums, *primes;
> > 
> > nums   = gx_list_iota (100, 1, 1);
> > primes = gx_list_filter (nums, (GXPred)gx_is_prime, NULL);
> > sum= gx_list_sum (primes); /* => 1060 */
> > 
> > g_list_free (nums);
> > g_list_free (primes);
> 
> `
> 
> There's also folding, mapping etc. See a short article about this:
>    http://www.djcbsoftware.nl/2015/10/04/functional-glists/
> (2015?! time does fly). Am still developing it though.
> 
> Repo: https://github.com/djcb/gxlib
> Docs: http://www.djcbsoftware.nl/code/gxlib/
> 
> Best wishes,
> Dirk.
> 

signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Functional programming with GLib

[Dirk-Jan C. Binnema]

Hi All,

A while back, I wrote some functions for functional-flavored programming
with GLib. It's fully documented[1], has tests, etc.

It would (for me at least) be useful to have some of these functions in
GLib-proper, but I suspect the GLib-maintainers are not /too/ eager to
accept contributions to GList... anyway, perhaps its useful for others.

As a simple example, suppose we want to calculate the sum of primes up
to 100 (a common task after all):

,
| intsum;
| GList *nums, *primes;
|
| nums   = gx_list_iota (100, 1, 1);
| primes = gx_list_filter (nums, (GXPred)gx_is_prime, NULL);
| sum= gx_list_sum (primes); /* => 1060 */
|
| g_list_free (nums);
| g_list_free (primes);
`

There's also folding, mapping etc. See a short article about this:
   http://www.djcbsoftware.nl/2015/10/04/functional-glists/
(2015?! time does fly). Am still developing it though.

Repo: https://github.com/djcb/gxlib
Docs: http://www.djcbsoftware.nl/code/gxlib/

Best wishes,
Dirk.

-- 
Dirk-Jan C. Binnema  Helsinki, Finland
e:d...@djcbsoftware.nl   w:www.djcbsoftware.nl
pgp: D09C E664 897D 7D39 5047 A178 E96A C7A1 017D DA3C
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list