www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Doesn't std.signal completely miss the point?

reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
From what I can tell std.signal is designed around the idea that an

multiple signals within one class and making arbitrary connections between signals and slots. If you actually read the full paper it links to: http://www.elpauer.org/stuff/a_deeper_look_at_signals_and_slots.pdf you'll see that the idea of signals and slots is to avoid writing specialized signal classes, and instead just use member functions as signal emitters. I don't see why we can't have something as good or even better than Qt's and Boost's signals and slots implementations. I admit I haven't had a look at the other implementations linked from the std.signals page yet, so maybe there's some better implementations out there. But from a current standpoint it looks to me like std.signal is a good candidate for a revamp.
Sep 04 2011
next sibling parent Johannes Pfau <spam example.com> writes:
Andrej Mitrovic wrote:
From what I can tell std.signal is designed around the idea that an

multiple signals within one class and making arbitrary connections between signals and slots. If you actually read the full paper it links to: http://www.elpauer.org/stuff/a_deeper_look_at_signals_and_slots.pdf you'll see that the idea of signals and slots is to avoid writing specialized signal classes, and instead just use member functions as signal emitters. I don't see why we can't have something as good or even better than Qt's and Boost's signals and slots implementations. I admit I haven't had a look at the other implementations linked from the std.signals page yet, so maybe there's some better implementations out there. But from a current standpoint it looks to me like std.signal is a good candidate for a revamp.

I started a std.signal rewrite ~1 year ago: This is what I came up with: http://dl.dropbox.com/u/24218791/d/src/signals.html https://gist.github.com/1194497 I think the API isn't too bad, but the internal implementation could be improved. I didn't know about boost.signals, so that could be used to improve my implementation. However, I think it's useless as long as it can't be used by multiple threads. But when I wanted to add 'shared' support to it, I always hit a dead end, a bug, something not working, so in the end I gave up. Another point which could be improved is that it currently only works for safe/ trusted delegates. Maybe a system signal is also useful. And I'm also not sure how (or whether) signals are meant to be integrated with message passing. -- Johannes Pfau
Sep 05 2011
prev sibling next sibling parent reply Nick Treleaven <nospam example.com> writes:
On 04/09/2011 22:27, Andrej Mitrovic wrote:
 From what I can tell std.signal is designed around the idea that an
 entire class acts as a signal emitter, without the ability to write
 multiple signals within one class and making arbitrary connections
 between signals and slots.

I for one was surprised when I looked at it a while ago and found it doesn't seem to support multiple signals per class. I'm no expert but I'm used to GTK+ named signals and expected something comparable.
Sep 05 2011
parent Cal <callumenator gmail.com> writes:
== Quote from Nick Treleaven (nospam example.com)'s article
 On 04/09/2011 22:27, Andrej Mitrovic wrote:
 From what I can tell std.signal is designed around the idea that an
 entire class acts as a signal emitter, without the ability to write
 multiple signals within one class and making arbitrary connections
 between signals and slots.

doesn't seem to support multiple signals per class. I'm no expert but I'm used to GTK+ named signals and expected something comparable.

You can have multiple signals per class by naming the mixins: class Send { void fire() { sigA.emit("A", 1); sigB.emit("B", 2); } mixin Signal!(string, int) sigA; mixin Signal!(string, int) sigB; } class Watch { void watchA(string, int) { /// Do stuff } void watchB(string, int) { /// Do stuff } } Send s = new Send; Watch w = new Watch; s.sigA.connect(&w.watchA); s.sigB.connect(&w.watchB); s.fire(); Unless I am misunderstanding this thread? Cheers, Cal
Sep 05 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 9/5/11, Cal <callumenator gmail.com> wrote:
 You can have multiple signals per class by naming the mixins:

Seems like you're right. I completely missed this in the docs. I think I could make a pull to add another example of multiple signals, I didn't know they were supported.
Sep 05 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
I sure hope that code is well tested though. Does anyone know why
calloc/realloc are used inside of connect() instead of letting the GC
do its thing?
Sep 05 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Well it seems I can't use this with freeform delegates that are not
class fields. This could definitely use some improvement.
Sep 05 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 9/5/11, Johannes Pfau <spam example.com> wrote:
 I started a std.signal rewrite ~1 year ago: This is what I came up
 with:
 http://dl.dropbox.com/u/24218791/d/src/signals.html
 https://gist.github.com/1194497

This actually works great for me since it supports lambdas, I've tried it and it works. I'll put my sample up on the cairoDSamples repo once it's done. Thanks for this!
Sep 05 2011
prev sibling next sibling parent Johannes Pfau <spam example.com> writes:
Andrej Mitrovic wrote:
Well it seems I can't use this with freeform delegates that are not
class fields. This could definitely use some improvement.

You're talking about phobos std.signals, not my implementation, right? Last time I asked on the mailing list I was told that std.signals was written in the D1 days and not updated since then. The reason why this only works with class delegates: std.signals looks up the class a delegate belongs to and registers a callback in druntime to get notified when the object gets destroyed. This seems only useful with explicit delete, which is now deprecated. -- Johannes Pfau
Sep 06 2011
prev sibling next sibling parent Johannes Pfau <spam example.com> writes:
Andrej Mitrovic wrote:
On 9/5/11, Johannes Pfau <spam example.com> wrote:
 I started a std.signal rewrite ~1 year ago: This is what I came up
 with:
 http://dl.dropbox.com/u/24218791/d/src/signals.html
 https://gist.github.com/1194497

This actually works great for me since it supports lambdas, I've tried it and it works. I'll put my sample up on the cairoDSamples repo once it's done. Thanks for this!

I'm glad it's useful for you. Please note that the disconnect method might not work correctly until http://d.puremagic.com/issues/show_bug.cgi?id=5011 is fixed. (At least one unittest also fails because of that) -- Johannes Pfau
Sep 06 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 9/5/11, Johannes Pfau <spam example.com> wrote:
 You're talking about phobos std.signals, not my implementation, right?

Yes. On 9/5/11, Johannes Pfau <spam example.com> wrote:
 However, I think it's useless as long as it can't be used by multiple
 threads. But when I wanted to add 'shared' support to it, I always hit
 a dead end, a bug, something not working, so in the end I gave up.

I'm not really sure how multithreading should work with signals (well I'm just too new to multithreading anyways). Some people have mentioned that DFL is thread-friendly, but I'm not seeing any synchronization in its Event type, whereas DGUI has a synchronized() block around the code that invokes signal handlers.
 Another point which could be improved is that it currently only works
 for  safe/ trusted delegates. Maybe a  system signal is also useful.

Why must they be safe?
Sep 06 2011
prev sibling parent Johannes Pfau <spam example.com> writes:
Andrej Mitrovic wrote:
On 9/5/11, Johannes Pfau <spam example.com> wrote:
 You're talking about phobos std.signals, not my implementation,
 right?

Yes. On 9/5/11, Johannes Pfau <spam example.com> wrote:
 However, I think it's useless as long as it can't be used by multiple
 threads. But when I wanted to add 'shared' support to it, I always
 hit a dead end, a bug, something not working, so in the end I gave
 up.

I'm not really sure how multithreading should work with signals (well I'm just too new to multithreading anyways). Some people have mentioned that DFL is thread-friendly, but I'm not seeing any synchronization in its Event type, whereas DGUI has a synchronized() block around the code that invokes signal handlers.
 Another point which could be improved is that it currently only works
 for  safe/ trusted delegates. Maybe a  system signal is also useful.

Why must they be safe?

There's no technical reason. But as soon as one system delegate is connected, emit() must also be system. But if emit() is system you can't emit events from safeD code. So currently emit() is trusted to support safeD and all connected delegates should be safe or trusted. In the end it should be possible to choose between a safe and a system signal though. -- Johannes Pfau
Sep 06 2011