Has anyone got any D code using the Glib event loop, usually GtkD code I'd guess, that is well tested using Unit_Threaded?

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

On Saturday, 16 May 2020 at 10:51:07 UTC, Russel Winder wrote:
>
> Has anyone got any D code using the Glib event loop, usually GtkD code I'd guess, that is well tested using Unit_Threaded?

I always had a hard time doing unittests for things with as many moving parts as glib based software, so I usually just do integration tests like so: https://gitlab.alpinelinux.org/Cogitri/apk-polkit/-/blob/1dfbe2b3d959e3c083fcb82419a0a0401c485937/tests/apkd_dbus_server/addAndDelete.d

Maybe I should look into Unit_Threaded for more fine grained tests, but I think the effort for all the mocking stuff that I'd have to implement even for a (relatively) simple GDBus application would be quite substantial.

On Sat, 2020-05-16 at 11:37 +0000, Cogitri via Digitalmars-d-learn wrote:
> On Saturday, 16 May 2020 at 10:51:07 UTC, Russel Winder wrote:
> > Has anyone got any D code using the Glib event loop, usually GtkD code I'd guess, that is well tested using Unit_Threaded?
> 
> I always had a hard time doing unittests for things with as many moving parts as glib based software, so I usually just do integration tests like so: https://gitlab.alpinelinux.org/Cogitri/apk-polkit/-/blob/1dfbe2b3d959e3c083fcb82419a0a0401c485937/tests/apkd_dbus_server/addAndDelete.d
> 
> Maybe I should look into Unit_Threaded for more fine grained tests, but I think the effort for all the mocking stuff that I'd have to implement even for a (relatively) simple GDBus application would be quite substantial.

I am experimenting with using manual control of the Glib event loop using the pending and iteration methods on the default MainContext within each unit- threaded test. The alternative of running a GTK application and then putting the tests in as an asynchronous sequence only works with Rust and Python since D has no coroutines of any sort.

Of course now there is jin.go which is a synchronous multi-tasking approach with channels rather than an asynchronous approach available in D.

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

On Sun, 2020-05-17 at 11:19 +0100, Russel Winder wrote: […]
> 
> Of course now there is jin.go which is a synchronous multi-tasking approach with channels rather than an asynchronous approach available in D.

Had I checked I would have seen this was a four years ago package that has been left fallow since. It seems like something that should be resurrected and made a core package for concurrency and parallelism for D.

I suspect there is significant overlap of some task, thread, fibre, and scheduling code with std.parallelism, but is it worth trying to share code ir just go with separate code?

It might be worth extracting the futures code out of vibe.d so that D has a
futures package in the Dub repository so that people can create asynchronous
coroutines on top of it.

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

On Sunday, 17 May 2020 at 10:19:38 UTC, Russel Winder wrote:
> I am experimenting with using manual control of the Glib event loop using the pending and iteration methods on the default MainContext within each unit- threaded test. The alternative of running a GTK application and then putting the tests in as an asynchronous sequence only works with Rust and Python since D has no coroutines of any sort.
>

A Fiber can't be used for this ? D Fibers don't have a scheduler. Yielding returns to the caller context.
https://dlang.org/phobos/core_thread_fiber.html

On Sun, 2020-05-17 at 20:32 +0000, Luis via Digitalmars-d-learn wrote:
> On Sunday, 17 May 2020 at 10:19:38 UTC, Russel Winder wrote:
> > I am experimenting with using manual control of the Glib event loop using the pending and iteration methods on the default MainContext within each unit- threaded test. The alternative of running a GTK application and then putting the tests in as an asynchronous sequence only works with Rust and Python since D has no coroutines of any sort.
> > 
> 
> A Fiber can't be used for this ? D Fibers don't have a scheduler. Yielding returns to the caller context. https://dlang.org/phobos/core_thread_fiber.html

Futures based co-routines with an executor could do it, but without some form of scheduling, manual control is needed. In fact I think spawning an OS thread is probably a better route, the Glib event loop can then run as it wants being controlled via events being placed on it's queue from another thread.

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk