Re: D, Unit_Threaded, and GtkD

2020-05-18 Thread Russel Winder via Digitalmars-d-learn
On Sun, 2020-05-17 at 20:32 +, 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 Roadm: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk



signature.asc
Description: This is a digitally signed message part


Re: D, Unit_Threaded, and GtkD

2020-05-17 Thread Luis via Digitalmars-d-learn

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




Re: D, Unit_Threaded, and GtkD

2020-05-17 Thread Russel Winder via Digitalmars-d-learn
On Sat, 2020-05-16 at 11:37 +, 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 Roadm: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk



signature.asc
Description: This is a digitally signed message part


Re: D, Unit_Threaded, and GtkD

2020-05-16 Thread Cogitri via Digitalmars-d-learn

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.