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


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.

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 reply Johannes Pfau <spam example.com> writes:
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.

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
next sibling parent reply 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
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 parent reply 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
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
prev 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 reply 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.


 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.


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
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 parent reply 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
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