www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Objects on message queues of spawned processes

reply Russel Winder <russel winder.org.uk> writes:
I have some code (a simulation style solution to the Sleeping Barber
problem). It uses spawned processes to represent the actors of the
system. The code compiles and executes as expected using GDC as
currently on Debian Unstable, which I believe is effectively D 2.057.
Using DMD 2.058 I get the error message:


/home/users/russel/lib.Linux.x86_64/DMD2/bin64/../../src/phobos/std/concurr=
ency.d(529): Error: cannot have parameter of type void
/home/users/russel/lib.Linux.x86_64/DMD2/bin64/../../src/phobos/std/concurr=
ency.d(529): Error: cannot have parameter of type void
/home/users/russel/lib.Linux.x86_64/DMD2/bin64/../../src/phobos/std/concurr=
ency.d(529): Error: variable std.concurrency.receive!(void delegate(Custome=
r customer)  system,void,void).receive._param_1 voids have no value
/home/users/russel/lib.Linux.x86_64/DMD2/bin64/../../src/phobos/std/concurr=
ency.d(529): Error: variable std.concurrency.receive!(void delegate(Custome=
r customer)  system,void,void).receive._param_2 voids have no value
Failed: 'dmd' '-v' '-o-' 'singleBarber_d2_spawn.d' '-I.'


Using  DMD 2.059 I get the error message:

singleBarber_d2_spawn.d(35): Error: template std.concurrency.receive does n=
ot match any function template declaration
/home/users/russel/lib.Linux.x86_64/DMD2/bin64/../../src/phobos/std/concurr=
ency.d(530): Error: template std.concurrency.receive(T...) cannot deduce te=
mplate function from argument types !()(void delegate(Customer customer)  s=
ystem,void,void)
singleBarber_d2_spawn.d(59): Error: template std.concurrency.receive does n=
ot match any function template declaration
/home/users/russel/lib.Linux.x86_64/DMD2/bin64/../../src/phobos/std/concurr=
ency.d(530): Error: template std.concurrency.receive(T...) cannot deduce te=
mplate function from argument types !()(void delegate(Customer customer)  s=
ystem,void delegate(SuccessfulCustomer successfulCustomer)  system,void del=
egate(ShopClosing message)  system,void delegate(ClockedOut message)  syste=
m,void)
singleBarber_d2_spawn.d(99): Error: template std.concurrency.receive does n=
ot match any function template declaration
/home/users/russel/lib.Linux.x86_64/DMD2/bin64/../../src/phobos/std/concurr=
ency.d(530): Error: template std.concurrency.receive(T...) cannot deduce te=
mplate function from argument types !()(void delegate(Tid t) nothrow  safe,=
void delegate(Customer customer)  system,void delegate(SuccessfulCustomer s=
uccessfulCustomer)  system,void,void)
Failed: 'dmd' '-v' '-o-' 'singleBarber_d2_spawn.d' '-I.'

the "offending" bit of code is:

   receive (
             ( Customer customer ) {
               writeln ( "Barber : Starting Customer " , customer.id ) ;
               Thread.sleep ( hairTrimTime ( ) ) ;
               writeln ( "Barber : Finished Customer " , customer.id ) ;
               ++customersTrimmed ;
               shop.send ( SuccessfulCustomer ( customer ) ) ;
             } ,
             ( ShopClosing ) {
               writeln ( "Barber : Work over for the day, trimmed " , custo=
mersTrimmed , "." ) ;
               shop.send ( ClockedOut ( ) ) ;
               running =3D false ;
             } ,
             ( OwnerTerminated ) { }
             ) ;

Where Customer and SuccessfulCustomer are structs as the case types --
so that the shop can distinguish new arrivals from trimmed customers.

So somewhere between 2.057 and 2.058 it seems that something about
receive changed, as far as I am concerned from correct to fail --
however I may have missed a memo...=20

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Apr 18 2012
parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 04/18/2012 11:18 AM, Russel Winder wrote:

 Using  DMD 2.059 I get the error message:

 singleBarber_d2_spawn.d(35): Error: template std.concurrency.receive 
does not match any function template declaration
 
/home/users/russel/lib.Linux.x86_64/DMD2/bin64/../../src/phobos/std concurrency.d(530): Error: template std.concurrency.receive(T...) cannot deduce template function from argument types !()(void delegate(Customer customer) system,void,void) I have hit this problem earlier. Here is a reduced code: import std.concurrency; struct S {} void main() { receive((S) {}); // <-- compilation error with 2.059 } The workaround is to name the parameter: receive((S s) {}); Ali
Apr 18 2012
parent reply Russel Winder <russel winder.org.uk> writes:
On Wed, 2012-04-18 at 15:04 -0700, Ali =C3=87ehreli wrote:
[...]
 The workaround is to name the parameter:
=20
      receive((S s) {});
OK, this works for me as well, which is great. The question now is whether this is a feature or a bug? In terms of the parameter list of a function literal, the names should be there so requiring the name is fixing a bug that was there. In terms of usability in context, if the programmer doesn't use the variable just the fact that an instance of the type was received, then having to give the variable a name is total noise. In this case the old behaviour was right and the change created a new bug. I guess this is a situation where "Walter Decides" ? --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Apr 19 2012
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 04/19/2012 10:09 AM, Russel Winder wrote:
 On Wed, 2012-04-18 at 15:04 -0700, Ali Çehreli wrote:
 [...]
 The workaround is to name the parameter:

       receive((S s) {});
OK, this works for me as well, which is great. The question now is whether this is a feature or a bug? In terms of the parameter list of a function literal, the names should be there so requiring the name is fixing a bug that was there. In terms of usability in context, if the programmer doesn't use the variable just the fact that an instance of the type was received, then having to give the variable a name is total noise. In this case the old behaviour was right and the change created a new bug. I guess this is a situation where "Walter Decides" ?
The issue is that the meaning of (S) {} in non-template delegate signatures has changed: Previously it was a delegate with an unnamed parameter of type 'S', now it is a delegate with a parameter named 'S' of a deduced type. I think that the second meaning is more useful and more consistent, but YMMV. (You can name the parameter '_' or something along those lines to express that it is not used.)
Apr 19 2012
parent reply Russel Winder <russel winder.org.uk> writes:
On Thu, 2012-04-19 at 18:06 +0200, Timon Gehr wrote:
[...]
 The issue is that the meaning of (S) {} in non-template delegate=20
 signatures has changed: Previously it was a delegate with an unnamed=20
 parameter of type 'S', now it is a delegate with a parameter named 'S'=
=20
 of a deduced type. I think that the second meaning is more useful and=20
 more consistent, but YMMV. (You can name the parameter '_' or something=
=20
 along those lines to express that it is not used.)
OK, so I missed the memo, my fault. Is _ just a valid name that can be used in a conventional way, or is it an unallocated variable? --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Apr 19 2012
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 04/19/2012 06:23 PM, Russel Winder wrote:
 On Thu, 2012-04-19 at 18:06 +0200, Timon Gehr wrote:
 [...]
 The issue is that the meaning of (S) {} in non-template delegate
 signatures has changed: Previously it was a delegate with an unnamed
 parameter of type 'S', now it is a delegate with a parameter named 'S'
 of a deduced type. I think that the second meaning is more useful and
 more consistent, but YMMV. (You can name the parameter '_' or something
 along those lines to express that it is not used.)
OK, so I missed the memo, my fault. Is _ just a valid name that can be used in a conventional way, or is it an unallocated variable?
It is a valid identifier.
Apr 19 2012