http://www.digitalmars.com/d/std_signals.html

And that, hopefully, is that.

Walter Bright wrote:

> http://www.digitalmars.com/d/std_signals.html
> 
> And that, hopefully, is that.

Almost that...

http://www.digitalmars.com/d/phobos/std_signals.html

--anders

Walter Bright wrote:
> http://www.digitalmars.com/d/std_signals.html
> 
> And that, hopefully, is that.

Does the following mean you intend to make signals compatible with other callable types?

"BUGS:
Slots can only be delegates formed from class objects or interfaces to class objects."

Lutger wrote:
> Does the following mean you intend to make signals compatible with other callable types?
> 
> "BUGS:
> Slots can only be delegates formed from class objects or interfaces to class objects."

Not for the time being. The problem is the type system cannot distinguish them.

Using the example straight from http://www.digitalmars.com/d/phobos/std_signals.html (and yes using DMD 0.173) I get the following compiler errors:


c:\dmd\bin\..\src\phobos\std\signals.d(166): undefined identifier _d_OutOfMemory

c:\dmd\bin\..\src\phobos\std\signals.d(166): function expected before (), not _d
_OutOfMemory of type int
c:\dmd\bin\..\src\phobos\std\signals.d(174): undefined identifier _d_OutOfMemory

c:\dmd\bin\..\src\phobos\std\signals.d(174): function expected before (), not _d
_OutOfMemory of type int
c:\dmd\bin\..\src\phobos\std\signals.d(235): undefined identifier free
c:\dmd\bin\..\src\phobos\std\signals.d(235): function expected before (), not fr
ee of type int


I think this is finally a real mixin limitation being exposed. You probably only tested std.signals inside the signals.d source file, where the mixin had access to std.signals' imports. But use std.signals from another file and the mixin cannot access std.signal's imports because it's accessing the mixed-in scope. In other words, I think to remove these errors, std.signals' imports would need to be imported inside the mixin template (hack?), or change how mixins work.

Chris Miller wrote:

> Using the example straight from http://www.digitalmars.com/d/phobos/std_signals.html (and yes using DMD 0.173) I get the following compiler errors:
> 
> 
> c:\dmd\bin\..\src\phobos\std\signals.d(166): undefined identifier
> _d_OutOfMemory
> 
> c:\dmd\bin\..\src\phobos\std\signals.d(166): function expected before (),
> not _d
> _OutOfMemory of type int
> c:\dmd\bin\..\src\phobos\std\signals.d(174): undefined identifier
> _d_OutOfMemory
> 
> c:\dmd\bin\..\src\phobos\std\signals.d(174): function expected before (),
> not _d
> _OutOfMemory of type int
> c:\dmd\bin\..\src\phobos\std\signals.d(235): undefined identifier free
> c:\dmd\bin\..\src\phobos\std\signals.d(235): function expected before (),
> not fr
> ee of type int
> 
> 
> I think this is finally a real mixin limitation being exposed. You probably only tested std.signals inside the signals.d source file, where the mixin had access to std.signals' imports. But use std.signals from another file and the mixin cannot access std.signal's imports because it's accessing the mixed-in scope. In other words, I think to remove these errors, std.signals' imports would need to be imported inside the mixin template (hack?), or change how mixins work.

Maybe this is the que for Walter to finally accept that mixins are far from perfect as they are? Buggy and not optimally designed.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource & #D: larsivi

Chris Miller wrote:
> Using the example straight from http://www.digitalmars.com/d/phobos/std_signals.html (and yes using DMD 0.173) I get the following compiler errors:
> 
> 
> c:\dmd\bin\..\src\phobos\std\signals.d(166): undefined identifier _d_OutOfMemory
> 
> c:\dmd\bin\..\src\phobos\std\signals.d(166): function expected before (), not _d
> _OutOfMemory of type int
> c:\dmd\bin\..\src\phobos\std\signals.d(174): undefined identifier _d_OutOfMemory
> 
> c:\dmd\bin\..\src\phobos\std\signals.d(174): function expected before (), not _d
> _OutOfMemory of type int
> c:\dmd\bin\..\src\phobos\std\signals.d(235): undefined identifier free
> c:\dmd\bin\..\src\phobos\std\signals.d(235): function expected before (), not fr
> ee of type int
> 
> 
> I think this is finally a real mixin limitation being exposed. You probably only tested std.signals inside the signals.d source file, where the mixin had access to std.signals' imports. But use std.signals from another file and the mixin cannot access std.signal's imports because it's accessing the mixed-in scope. In other words, I think to remove these errors, std.signals' imports would need to be imported inside the mixin template (hack?), or change how mixins work.

++mixinVictims;

Thanks for bringing up that problem, Chris. I've begged for a change in mixins' visibility rules some time ago. Maybe we could restart the discussion now ?

Mixins are unlike any other construct in D, thus they are a trap for programmers expecting uniform behavior in the whole language.
The biggest problem with mixins is what has just been demonstrated by Chris - they exist in instantiation scope and that's where they look for symbols. But when we write a module with some template meant to be used as a mixin, the module will probably contain other stuff and we'll want our mixin to use it. So we use that symbol in the mixin and it works in the module... But then we import the module somewhere else, try to use the mixin and BANG! Lots of 'undefined identifier' errors.

To be consistent, mixins should by default see their declaration scope and only access the instantiation scope thru a special keyword or construct. If it were up to me, I'd use 'outer'. E.g.

template Foo() {
	alias foo a;	// uses 'foo' from the declaration scope
	alias outer.foo b;	// uses 'foo' from the instantiation scope
}

That's all is needed to avoid unpleasant surprises with mixin visibility rules.

On a last note, this is not the only problem with mixins. I hope that we can finally get around to fixing them all...

--
Tomasz Stachowiak

Walter Bright wrote:
> http://www.digitalmars.com/d/std_signals.html
> 
> And that, hopefully, is that.

Nice work!  In skimming the code, one thing jumped out at me:

signals.d:171: len += len + 4;

I think this should be: len += 4;

Or actually: len += (void*).sizeof;

To be 64-bit safe.  Finally, is there any reason to use _d_toObject in this code instead of cast(Object)?  I'd think they would do the same thing?


Sean

Sean Kelly wrote:
> Walter Bright wrote:
>> http://www.digitalmars.com/d/std_signals.html
>>
>> And that, hopefully, is that.
> 
> Nice work!  In skimming the code, one thing jumped out at me:
> 
> signals.d:171: len += len + 4;
> 
> I think this should be: len += 4;
> 
> Or actually: len += (void*).sizeof;

No, that is as intended. It's using a power of 2 allocation method. Also, the sizeof thing is taken care of by the call to calloc/realloc.

> To be 64-bit safe.  Finally, is there any reason to use _d_toObject in this code instead of cast(Object)?  I'd think they would do the same thing?

Not exactly. cast(Object)p won't do the pointer adjustment if the type of p is a void*. To convert an interface to its underlying Object, the cast implementation needs to know what the interface type is.

Chris Miller wrote:
> I think this is finally a real mixin limitation being exposed. You probably only tested std.signals inside the signals.d source file, where the mixin had access to std.signals' imports.

I plead guilty. My test suite is now corrected.

> But use std.signals from another file and the mixin cannot access std.signal's imports because it's accessing the mixed-in scope. In other words, I think to remove these errors, std.signals' imports would need to be imported inside the mixin template (hack?), or change how mixins work.

The fix is straightforward, in std\signals.d just make the imports public:

> public import std.stdio;
> public import std.c.stdlib;
> public import std.outofmemory;