www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - sslot version 0.2

reply Lutger <lutger.blijdestijn gmail.com> writes:
I've uploaded a new version using the features of D since 0.173. Perhaps 
it is useful to those who want return values and other callable types 
than delegates from objects in their signals:

http://lutger.ifastnet.com

Some changes:
- No need for interface + mixin anymore to manage connections.
- No limit to the number of arguments.
- Slots can be temporarily blocked and unblocked.
- As suggested by Bill Baxter, a signal which doesn't have a return 
value can connect any slot with a return value.
- Better compiler time error messages. I've included Don Clugston's 
meta.nameof for this, I'm sure it has an open source license but I 
couldn't find exactly which one.
- Classes can be injected with the signal code by using a mixin.
A test module is included.

Note that connecting is slightly different from phobos, you'll have to 
provide the object reference:
signal.connect(&foo.bar, foo) instead of just signal.connect(&foo.bar)

[OT] I have to say it is a pleasure to program in D. The template 
varargs is a godsend.
Nov 17 2006
next sibling parent reply Bill Baxter <wbaxter gmail.com> writes:
Lutger wrote:
 I've uploaded a new version using the features of D since 0.173. Perhaps 
 it is useful to those who want return values and other callable types 
 than delegates from objects in their signals:
 
 http://lutger.ifastnet.com

Sounds like good stuff, Lutger. In the mean time, I've also updated FlexSignal to support connecting a function like: bool foo_slot(char[] s) { ... } to the signal: FlexSignal!(int, char[], float); I.e. the foo_slot can be connected to only get the char[] argument if that's all it's interested in. Unfortunately the syntax for this is a little cumbersome right now due to bug #540: thesignal.fconnect!(typeof(&foo_slot),1)(&foo_slot); When/if #540 is fixed this can become: thesignal.fconnect!(1)(&foo_slot); The '1' indicates foo_slot wants to skip the 1st argument emitted by the signal. Source here: http://www.dsource.org/projects/luigi/browser/trunk/luigi/signalobj.d Unlike Lutger's version, this is a wrapper around std.signals, and so signals can't have a return value. --bb
Nov 17 2006
parent reply Lutger <lutger.blijdestijn gmail.com> writes:
Bill Baxter wrote:
 In the mean time, I've also updated FlexSignal to support connecting a 
 function like:
    bool foo_slot(char[] s) { ... }
 
 to the signal:
    FlexSignal!(int, char[], float);
 
 I.e. the foo_slot can be connected to only get the char[] argument if 
 that's all it's interested in.  Unfortunately the syntax for this is a 
 little cumbersome right now due to bug #540:
 
     thesignal.fconnect!(typeof(&foo_slot),1)(&foo_slot);
 
 When/if #540 is fixed this can become:
 
     thesignal.fconnect!(1)(&foo_slot);
 
 The '1' indicates foo_slot wants to skip the 1st argument emitted by the 
 signal.

It's sort of a reverse bind? Would it be possible to write a seperate adapter so it could be used with std.signals and allow for garbage collection / deletion before disconnection? Boost::signals works nicely with boost bind like this but it's a little less flexible iirc. Something like this perhaps: thesignal.connect(adapt(thesignal, &foo_slot, 1)); and / or more concise: connect(thesignal, &foo_slot, 1); btw. there is a way to get the type of the .ptr property of a delegate but I was reluctant to use it as it seemed a little too hackish: http://www.digitalmars.com/d/archives/digitalmars/D/learn/delegate_type_info_5001.html
Nov 18 2006
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Lutger wrote:
 Bill Baxter wrote:
 In the mean time, I've also updated FlexSignal to support connecting a 
 function like:
    bool foo_slot(char[] s) { ... }

 to the signal:
    FlexSignal!(int, char[], float);

 I.e. the foo_slot can be connected to only get the char[] argument if 
 that's all it's interested in.  Unfortunately the syntax for this is a 
 little cumbersome right now due to bug #540:

     thesignal.fconnect!(typeof(&foo_slot),1)(&foo_slot);

 When/if #540 is fixed this can become:

     thesignal.fconnect!(1)(&foo_slot);

 The '1' indicates foo_slot wants to skip the 1st argument emitted by 
 the signal.

It's sort of a reverse bind?

Yeh, it is sort of bind-like.
 Would it be possible to write a seperate 
 adapter so it could be used with std.signals and allow for garbage 
 collection / deletion before disconnection?

It does actually use a separate adaptor. See the SlotAdaptor template in the code. But right now the SlotAdaptor template only returns the pointer to the delegate it makes, not the class itself. But I guess you could get that from the .ptr prop.
 Boost::signals works nicely with boost bind like this but it's a little 
 less flexible iirc.
 
 Something like this perhaps:
 thesignal.connect(adapt(thesignal, &foo_slot, 1));

The problem with that is that it creates some adapted thingy but unless you keep a pointer to it yourself you won't have a way to disconnect it.
 and / or more concise:
 connect(thesignal, &foo_slot, 1);

That doesn't work because the '1' has to be a compile time constant in order to muck with the signal's argument tuple. I don't think there's a way to convince D that it is constant without making it a template parameter. At least I couldn't figure one out.
 btw. there is a way to get the type of the .ptr property of a delegate 
 but I was reluctant to use it as it seemed a little too hackish:
 http://www.digitalmars.com/d/archives/digitalmars/D/learn/delegate_type_info_5001.html

Ah yes. I remember seeing that one go by. Hopefully some official support for that will be added, or else the distinction between Object and non-object delegates will be removed. --bb
Nov 18 2006
prev sibling next sibling parent reply "John Reimer" <terminal.node gmail.com> writes:
On Fri, 17 Nov 2006 09:06:45 -0800, Lutger <lutger.blijdestijn gmail.com>  
wrote:

 I've uploaded a new version using the features of D since 0.173. Perhaps  
 it is useful to those who want return values and other callable types  
 than delegates from objects in their signals:

 http://lutger.ifastnet.com

 Some changes:
 - No need for interface + mixin anymore to manage connections.
 - No limit to the number of arguments.
 - Slots can be temporarily blocked and unblocked.
 - As suggested by Bill Baxter, a signal which doesn't have a return  
 value can connect any slot with a return value.
 - Better compiler time error messages. I've included Don Clugston's  
 meta.nameof for this, I'm sure it has an open source license but I  
 couldn't find exactly which one.
 - Classes can be injected with the signal code by using a mixin.
 A test module is included.

 Note that connecting is slightly different from phobos, you'll have to  
 provide the object reference:
 signal.connect(&foo.bar, foo) instead of just signal.connect(&foo.bar)

 [OT] I have to say it is a pleasure to program in D. The template  
 varargs is a godsend.

Nice, but the document refers to a test.d or something that shows more details on how to use sslot. It's not in the package, and I don't see any other examples anywhere. -JJR
Nov 17 2006
parent reply Lutger <lutger.blijdestijn gmail.com> writes:
John Reimer wrote:
  > Nice, but the document refers to a test.d or something that shows more
 details on how to use sslot.  It's not in the package, and I don't see 
 any other examples anywhere.
 
 -JJR

That's weird. Did you download the archive sslot_v0.2.tar.gz? There should be a module tests.d inside. The documentation also has a couple of examples, it's in sslot\doc\signal.html, the same is viewable online.
Nov 18 2006
parent "John Reimer" <terminal.node gmail.com> writes:
On Sat, 18 Nov 2006 05:07:26 -0800, Lutger <lutger.blijdestijn gmail.com>  
wrote:

 John Reimer wrote:
   > Nice, but the document refers to a test.d or something that shows  
 more
 details on how to use sslot.  It's not in the package, and I don't see  
 any other examples anywhere.
  -JJR

That's weird. Did you download the archive sslot_v0.2.tar.gz? There should be a module tests.d inside. The documentation also has a couple of examples, it's in sslot\doc\signal.html, the same is viewable online.

Yes, I saw the doc examples. And Yes, tests.d was inside. Sorry, my mistake. I must have been looking in the wrong place. :P -JJR
Nov 18 2006
prev sibling next sibling parent reply Don Clugston <dac nospam.com.au> writes:
Lutger wrote:
 I've uploaded a new version using the features of D since 0.173. Perhaps 
 it is useful to those who want return values and other callable types 
 than delegates from objects in their signals:
 
 http://lutger.ifastnet.com
 
 Some changes:

 - Better compiler time error messages. I've included Don Clugston's 
 meta.nameof for this, I'm sure it has an open source license but I 
 couldn't find exactly which one.

BSD. I'm working on an update which will cope with all situations (the one in DDL/meta doesn't work with local variables (it wasn't possible prior to 0.172), and fails in some (relatively obscure) circumstances).
Nov 19 2006
next sibling parent Lutger <lutger.blijdestijn gmail.com> writes:
Don Clugston wrote:
 Lutger wrote:
 I've uploaded a new version using the features of D since 0.173. 
 Perhaps it is useful to those who want return values and other 
 callable types than delegates from objects in their signals:

 http://lutger.ifastnet.com

 Some changes:

 - Better compiler time error messages. I've included Don Clugston's 
 meta.nameof for this, I'm sure it has an open source license but I 
 couldn't find exactly which one.

BSD. I'm working on an update which will cope with all situations (the one in DDL/meta doesn't work with local variables (it wasn't possible prior to 0.172), and fails in some (relatively obscure) circumstances).

Good to hear. I'm sure there are much more impressive things that can be done with it, but being able to give such exact compiler messages is pretty darn useful I've found. It must be in the top 3 complaints from people learning STL that the compiler error messages are so cryptic. By using D templates with meta.nameof it might be possible to make templated code even easier to 'debug' than non-templated code. I think this can be a huge time-saver.
Nov 19 2006
prev sibling parent reply Kirk McDonald <kirklin.mcdonald gmail.com> writes:
Don Clugston wrote:
 Lutger wrote:
 - Better compiler time error messages. I've included Don Clugston's 
 meta.nameof for this, I'm sure it has an open source license but I 
 couldn't find exactly which one.

BSD. I'm working on an update which will cope with all situations (the one in DDL/meta doesn't work with local variables (it wasn't possible prior to 0.172), and fails in some (relatively obscure) circumstances).

Your Nameof module is turning out to be exceedingly useful. Pyd also uses it. I have some license questions/requests: I would appreciate it if (in the future) you included the text of the license at the top of the source files (in a plain comment, not a doc-comment). Second, Pyd itself is released under the MIT license. If Wikipedia's rundown of the differences between the two is correct, then to comply with the BSD license on Nameof I just need to include "meta.Nameof and meta.Demangle are copyright (C) 2005-2006 Don Clugston" in Pyd's docs. Is this correct? -- Kirk McDonald Pyd: Wrapping Python with D http://pyd.dsource.org
Nov 19 2006
parent reply Don Clugston <dac nospam.com.au> writes:
Kirk McDonald wrote:
 Don Clugston wrote:
 Lutger wrote:
 - Better compiler time error messages. I've included Don Clugston's 
 meta.nameof for this, I'm sure it has an open source license but I 
 couldn't find exactly which one.

BSD. I'm working on an update which will cope with all situations (the one in DDL/meta doesn't work with local variables (it wasn't possible prior to 0.172), and fails in some (relatively obscure) circumstances).

Your Nameof module is turning out to be exceedingly useful. Pyd also uses it.

Delighted to hear it.
 I have some license questions/requests:
 
 I would appreciate it if (in the future) you included the text of the 
 license at the top of the source files (in a plain comment, not a 
 doc-comment).

I really don't want to include the full text of the license. Would a link suffice?
 Second, Pyd itself is released under the MIT license. If Wikipedia's 
 rundown of the differences between the two is correct, then to comply 
 with the BSD license on Nameof I just need to include "meta.Nameof and 
 meta.Demangle are copyright (C) 2005-2006 Don Clugston" in Pyd's docs. 
 Is this correct?

Yes. Really, all I want to do with the license is to provide reassurance that there will never be legal issues associated with the code. From what I've heard, BSD/MIT licenses are better than public domain for this.
Nov 19 2006
next sibling parent reply Kirk McDonald <kirklin.mcdonald gmail.com> writes:
Don Clugston wrote:
 Kirk McDonald wrote:
 I would appreciate it if (in the future) you included the text of the 
 license at the top of the source files (in a plain comment, not a 
 doc-comment).

I really don't want to include the full text of the license. Would a link suffice?

Probably. If you look through the Pyd sources, you'll see that all of them include the text of the MIT license at the top. Putting the actual text of the license in there makes it that much more explicit. It's just a style thing, though, so I won't stress too much about it.
 Second, Pyd itself is released under the MIT license. If Wikipedia's 
 rundown of the differences between the two is correct, then to comply 
 with the BSD license on Nameof I just need to include "meta.Nameof and 
 meta.Demangle are copyright (C) 2005-2006 Don Clugston" in Pyd's docs. 
 Is this correct?

Yes. Really, all I want to do with the license is to provide reassurance that there will never be legal issues associated with the code. From what I've heard, BSD/MIT licenses are better than public domain for this.

I agree. It's why Pyd is MIT licensed. :-) -- Kirk McDonald Pyd: Wrapping Python with D http://pyd.dsource.org
Nov 20 2006
parent Don Clugston <dac nospam.com.au> writes:
Kirk McDonald wrote:
 Don Clugston wrote:
 Kirk McDonald wrote:
 I would appreciate it if (in the future) you included the text of the 
 license at the top of the source files (in a plain comment, not a 
 doc-comment).

I really don't want to include the full text of the license. Would a link suffice?

Probably. If you look through the Pyd sources, you'll see that all of them include the text of the MIT license at the top. Putting the actual text of the license in there makes it that much more explicit. It's just a style thing, though, so I won't stress too much about it.
 Second, Pyd itself is released under the MIT license. If Wikipedia's 
 rundown of the differences between the two is correct, then to comply 
 with the BSD license on Nameof I just need to include "meta.Nameof 
 and meta.Demangle are copyright (C) 2005-2006 Don Clugston" in Pyd's 
 docs. Is this correct?

Yes. Really, all I want to do with the license is to provide reassurance that there will never be legal issues associated with the code. From what I've heard, BSD/MIT licenses are better than public domain for this.

I agree. It's why Pyd is MIT licensed. :-)

"Cos I don't want to be a container/Or a bastard with a ten page disclaimer/But these monsters..." -- http://www.sigitas.com/artist_s/something_for_kate_lyrics/monsters_lyrics.html
Nov 20 2006
prev sibling parent reply Lutger <lutger.blijdestijn gmail.com> writes:
Don Clugston wrote:
 Really, all I want to do with the license is to provide reassurance that 
 there will never be legal issues associated with the code. From what 
 I've heard, BSD/MIT licenses are better than public domain for this.

What is the problem with public domain? Can GPL software use BSD licensed components? Some sites claim it can't because of the advertising clause, but then there are a couple of BSD licenses.
Nov 20 2006
next sibling parent Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Lutger wrote:
 Don Clugston wrote:
 Really, all I want to do with the license is to provide reassurance 
 that there will never be legal issues associated with the code. From 
 what I've heard, BSD/MIT licenses are better than public domain for this.

What is the problem with public domain? Can GPL software use BSD licensed components? Some sites claim it can't because of the advertising clause, but then there are a couple of BSD licenses.

Those sites are talking about the _old_ BSD license. The new BSD license is identical except that problematic clause is removed. IIRC, Linux contains quite a bit of (new) BSD-licensed code, and is GPL.
Nov 20 2006
prev sibling parent Bastiaan Veelo <Bastiaan Veelo.net> writes:
Lutger wrote:

 What is the problem with public domain?

To quote Lawrence Rosen: “... there is no mechanism for waiving a copyright that merely subsists, and there is no accepted way to dedicate an original work of authorship to the public domain before the copyright term for that work expires. A license is the only recognized way to authorize others to undertake the authors’ exclusive copyright rights.” _Open Source Licensing / Software Freedom and Intellectual Property Law_ Lawrence Rosen p.74 http://www.rosenlaw.com/Rosen_Ch05.pdf Best regards, Bastiaan.
Nov 22 2006
prev sibling parent Lutger <lutger.blijdestijn gmail.com> writes:
Lutger wrote:
 I've uploaded a new version using the features of D since 0.173. Perhaps 
 it is useful to those who want return values and other callable types 
 than delegates from objects in their signals:
 
 http://lutger.ifastnet.com

Not sure if anybody is using it, but there was a bug fixed (array bounds error of all things...)
Dec 06 2006