www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Message-Passing

reply "Nathan M. Swan" <nathanmswan gmail.com> writes:
I want to applaud Sean Kelly and everyone who worked on std.concurrency 
for a great API, and wish that I could easily write Cocoa applications 
with it.

I'm writing a screen recording program in Objective-C, and to make sure 
each frame has an equal length, I have two threads: one that takes the 
screenshot at certain intervals, the other that assembles it into a 
quicktime movie. After writing an implementation of a thread-safe queue, 
where the picture-taking thread adds and the assembling thread removes, 
I realized the huge similarity between what I'd done and std.concurrency.

The std.concurrency module would have made hours of effort in ObjC take 
five minutes in D. Well done!
Jan 19 2012
next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
Thanks :-)  If you have ideas on how it could be improved, please let me =
know.

On Jan 19, 2012, at 12:58 PM, Nathan M. Swan wrote:


 I want to applaud Sean Kelly and everyone who worked on =


std.concurrency for a great API, and wish that I could easily write =
Cocoa applications with it.

=20
 I'm writing a screen recording program in Objective-C, and to make =


sure each frame has an equal length, I have two threads: one that takes =
the screenshot at certain intervals, the other that assembles it into a =
quicktime movie. After writing an implementation of a thread-safe queue, =
where the picture-taking thread adds and the assembling thread removes, =
I realized the huge similarity between what I'd done and =
std.concurrency.

=20
 The std.concurrency module would have made hours of effort in ObjC =


take five minutes in D. Well done!
Jan 19 2012
parent "Mariusz Gliwiński" <alienballance gmail.com> writes:
On Thursday, 19 January 2012 at 22:36:17 UTC, Sean Kelly wrote:

 Thanks :-)  If you have ideas on how it could be improved, 
 please let me know.


I don't know whether it's good or not, but in my system based on 
std.concurrency:
* i had to add in-thread messaging in case when there will be 
more actors than threads
* needed to have possibility of sending multiple types of 
messages, but ignoring these, not listened to (rather than 
throwing messageMismatch). IMHO there should be no message 
buffering, and throwing messages not listened on.
* had to define some possibility of thread discharging, based on 
constraints fired after each in-thread message handling
    void poll(bool delegate(Variant msg) condition);
    void poll(bool delegate() condition);
* needed to implement some form of message filters (like windows 
file system minifilters), which might sequentially act with 
blocking or passing message for multiple-listeners handling

i still need to add:
* because every message might have multiple listeners, it should 
be read only and shared between them
* there should be some kind of standard scheduler, which could be 
replaced later

Anyways, i think it's a great model of multithreading, and 
enjoyed working with std.concurrency.
Jan 22 2012
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-01-19 21:58, Nathan M. Swan wrote:

 I want to applaud Sean Kelly and everyone who worked on std.concurrency
 for a great API, and wish that I could easily write Cocoa applications
 with it.

 I'm writing a screen recording program in Objective-C, and to make sure
 each frame has an equal length, I have two threads: one that takes the
 screenshot at certain intervals, the other that assembles it into a
 quicktime movie. After writing an implementation of a thread-safe queue,
 where the picture-taking thread adds and the assembling thread removes,
 I realized the huge similarity between what I'd done and std.concurrency.

 The std.concurrency module would have made hours of effort in ObjC take
 five minutes in D. Well done!


I don't know if it's the same but doesn't Objective-C makes that quite 
simple as well since Mac OS X 10.6 using grand central dispatch:

http://en.wikipedia.org/wiki/Grand_Central_Dispatch

-- 
/Jacob Carlborg
Jan 19 2012
prev sibling next sibling parent reply Manu <turkeyman gmail.com> writes:
On 20 January 2012 00:36, Sean Kelly <sean invisibleduck.org> wrote:


 Thanks :-)  If you have ideas on how it could be improved, please let me
 know.

 On Jan 19, 2012, at 12:58 PM, Nathan M. Swan wrote:


 I want to applaud Sean Kelly and everyone who worked on std.concurrency


 for a great API, and wish that I could easily write Cocoa applications with
 it.

 I'm writing a screen recording program in Objective-C, and to make sure


 each frame has an equal length, I have two threads: one that takes the
 screenshot at certain intervals, the other that assembles it into a
 quicktime movie. After writing an implementation of a thread-safe queue,
 where the picture-taking thread adds and the assembling thread removes, I
 realized the huge similarity between what I'd done and std.concurrency.

 The std.concurrency module would have made hours of effort in ObjC take


 five minutes in D. Well done!


I had some troubles with std.concurrency which I thought it might be nice
to address.

Perhaps the most major problem I had was related to the concept of thread
ownership. If a spawned threads parent thread dies, it also receives a
signal to kill its self, but it seems impossible to reassign ownership.
In my case I had threads A, B and C...
  Thread A is the main thread, which may spawn many temporary worker
threads B, which may last 1-2 seconds.
  During the life of B, it may spawn C, which may persist for hours.
  B promptly dies, and any C's that were spawned receive the kill signal,
which I ignore.
  Thread A, the main thread may exit, and I would really like all C's to
receive that notification, but they were are all orphaned when their B died.
The problem is, when I spawn a C, it should be created as a child of A
somehow, rather than a child of the transient B... Some mechanism to solve
this sort of problem would be useful.

Another usability problem I had was that, intuitively, the simpler function
with intuitive usage pattern receiveOnly() should be named receive().
And receive() with the complex var-arg list of delegates should be named
something more complex.
receiveTimeout() has no receiveTimeoutOnly(), which is the function I
almost always want to use... and receiveTimeout() didn't actually work for
me anyway (it wouldn't receive a duration as per the documentation, I had
to pass an int)

I wonder if there is a solution to the 'shared' problem. Basically every
single line of code that uses the std.concurrenty api is riddled with casts
to/from shared... really ugly.
I think the problem here is that I'm not SHARING values between threads,
I'm actually passing ownership of something to another thread. So I wonder
if some improvement can be made in this area.

I was going to complain about the documentation, but I just checked, and it
seems to have had work since I was reading it. Looks much better now! :)
Jan 20 2012
parent "jdrewsen" <jdrewsen nospam.com> writes:
On Friday, 20 January 2012 at 13:10:37 UTC, Manu wrote:

 On 20 January 2012 00:36, Sean Kelly <sean invisibleduck.org> 
 wrote:


 Thanks :-)  If you have ideas on how it could be improved, 
 please let me
 know.

 On Jan 19, 2012, at 12:58 PM, Nathan M. Swan wrote:


 I want to applaud Sean Kelly and everyone who worked on 
 std.concurrency


 for a great API, and wish that I could easily write Cocoa 
 applications with
 it.

 I'm writing a screen recording program in Objective-C, and 
 to make sure


 each frame has an equal length, I have two threads: one that 
 takes the
 screenshot at certain intervals, the other that assembles it 
 into a
 quicktime movie. After writing an implementation of a 
 thread-safe queue,
 where the picture-taking thread adds and the assembling thread 
 removes, I
 realized the huge similarity between what I'd done and 
 std.concurrency.

 The std.concurrency module would have made hours of effort 
 in ObjC take


 five minutes in D. Well done!


 I had some troubles with std.concurrency which I thought it 
 might be nice
 to address.

 Perhaps the most major problem I had was related to the concept 
 of thread
 ownership. If a spawned threads parent thread dies, it also 
 receives a
 signal to kill its self, but it seems impossible to reassign 
 ownership.
 In my case I had threads A, B and C...
 Thread A is the main thread, which may spawn many temporary 
 worker
 threads B, which may last 1-2 seconds.
 During the life of B, it may spawn C, which may persist for 
 hours.
 B promptly dies, and any C's that were spawned receive the kill 
 signal,
 which I ignore.
 Thread A, the main thread may exit, and I would really like all 
 C's to
 receive that notification, but they were are all orphaned when 
 their B died.
 The problem is, when I spawn a C, it should be created as a 
 child of A
 somehow, rather than a child of the transient B... Some 
 mechanism to solve
 this sort of problem would be useful.

 Another usability problem I had was that, intuitively, the 
 simpler function
 with intuitive usage pattern receiveOnly() should be named 
 receive().
 And receive() with the complex var-arg list of delegates should 
 be named
 something more complex.
 receiveTimeout() has no receiveTimeoutOnly(), which is the 
 function I
 almost always want to use... and receiveTimeout() didn't 
 actually work for
 me anyway (it wouldn't receive a duration as per the 
 documentation, I had
 to pass an int)

 I wonder if there is a solution to the 'shared' problem. 
 Basically every
 single line of code that uses the std.concurrenty api is 
 riddled with casts
 to/from shared... really ugly.
 I think the problem here is that I'm not SHARING values between 
 threads,
 I'm actually passing ownership of something to another thread. 
 So I wonder
 if some improvement can be made in this area.

 I was going to complain about the documentation, but I just 
 checked, and it
 seems to have had work since I was reading it. Looks much 
 better now! :)


It still needs to document that the ops in "void receive(T...)(T 
ops)" can return false if they did not handle the message. This 
is useful when you want to receive a message from a specific 
spawned subthread (tid).

/Jonas
Jan 20 2012
prev sibling next sibling parent Sean Kelly <sean invisibleduck.org> writes:
On Jan 20, 2012, at 5:10 AM, Manu wrote:

=20
 I had some troubles with std.concurrency which I thought it might be =


nice to address.

=20
 Perhaps the most major problem I had was related to the concept of =


thread ownership. If a spawned threads parent thread dies, it also =
receives a signal to kill its self, but it seems impossible to reassign =
ownership.

 In my case I had threads A, B and C...
   Thread A is the main thread, which may spawn many temporary worker =


threads B, which may last 1-2 seconds.

   During the life of B, it may spawn C, which may persist for hours.
   B promptly dies, and any C's that were spawned receive the kill =


signal, which I ignore.

   Thread A, the main thread may exit, and I would really like all C's =


to receive that notification, but they were are all orphaned when their =
B died.

 The problem is, when I spawn a C, it should be created as a child of A =


somehow, rather than a child of the transient B... Some mechanism to =
solve this sort of problem would be useful.

Erlang has functions to link and unlink threads from one another, and =
I've already implemented a bit of it in std.concurrency.  A fuller =
implementation would probably be sufficient for your needs.



 Another usability problem I had was that, intuitively, the simpler =


function with intuitive usage pattern receiveOnly() should be named =
receive().

 And receive() with the complex var-arg list of delegates should be =


named something more complex.

Matter of opinion.  I think receiveOnly indicates what the function =
does, and I think it's important to indicate that receiving anything =
else is unexpected and will trigger an error.



 receiveTimeout() has no receiveTimeoutOnly(), which is the function I =


almost always want to use... and receiveTimeout() didn't actually work =
for me anyway (it wouldn't receive a duration as per the documentation, =
I had to pass an int)

I think this is an artifact of the syntax.  There's no way to have a =
return value that indicates a timeout occurred.  If receiving a duration =
(ie. a non-reference type) doesn't work then I'd consider that a bug.



 I wonder if there is a solution to the 'shared' problem. Basically =


every single line of code that uses the std.concurrenty api is riddled =
with casts to/from shared... really ugly.

I think Unique!T should work for the sending side, and then the receive =
side wouldn't have to receive shared(T).  It's something that's been on =
the radar, but I haven't done anything about it yet.=
Jan 20 2012
prev sibling next sibling parent reply Manu <turkeyman gmail.com> writes:
On 20 January 2012 20:06, Sean Kelly <sean invisibleduck.org> wrote:


 On Jan 20, 2012, at 5:10 AM, Manu wrote:

 I had some troubles with std.concurrency which I thought it might be


 nice to address.

 Perhaps the most major problem I had was related to the concept of


 thread ownership. If a spawned threads parent thread dies, it also receives
 a signal to kill its self, but it seems impossible to reassign ownership.

 In my case I had threads A, B and C...
   Thread A is the main thread, which may spawn many temporary worker


 threads B, which may last 1-2 seconds.

   During the life of B, it may spawn C, which may persist for hours.
   B promptly dies, and any C's that were spawned receive the kill


 signal, which I ignore.

   Thread A, the main thread may exit, and I would really like all C's to


 receive that notification, but they were are all orphaned when their B died.

 The problem is, when I spawn a C, it should be created as a child of A


 somehow, rather than a child of the transient B... Some mechanism to solve
 this sort of problem would be useful.

 Erlang has functions to link and unlink threads from one another, and I've
 already implemented a bit of it in std.concurrency.  A fuller
 implementation would probably be sufficient for your needs.



 Another usability problem I had was that, intuitively, the simpler


 function with intuitive usage pattern receiveOnly() should be named
 receive().

 And receive() with the complex var-arg list of delegates should be named


 something more complex.

 Matter of opinion.  I think receiveOnly indicates what the function does,
 and I think it's important to indicate that receiving anything else is
 unexpected and will trigger an error.


Well I'm just saying as a new comer what I consider to be intuitive or not

java, php, ecma, etc)... I've never seen an api like receive() in any
language before. It definitely is a D-ish API, and wouldn't be expected by
most users.
I also think most instances of passing messages between 2 threads will have
a tight well-defined expectation of send/receive types. receiveOnly() seems
far more intuitive to me, and simpler to achieve 90(100?)% of my jobs.
Eg, I press '.' and the list of methods appears, and I skim through the
list and choose the one that looks appropriate, I'll choose receive, and
then I'll be puzzled by the argument list and why it doesn't work like I
expect, after a little wasted time, I may begrudgingly read the manual... I
personally feel this is an API failure, and the single most important thing

no prior knowledge of the language just using the '.' key with
code-complete in your IDE. The API's are really exceptionally intuitive.




 receiveTimeout() has no receiveTimeoutOnly(), which is the function I


 almost always want to use... and receiveTimeout() didn't actually work for
 me anyway (it wouldn't receive a duration as per the documentation, I had
 to pass an int)

 I think this is an artifact of the syntax.  There's no way to have a
 return value that indicates a timeout occurred.  If receiving a duration
 (ie. a non-reference type) doesn't work then I'd consider that a bug.


Syntax or otherwise, it's kinda broken. receiveOnlyTimeout() is a very
important function for my money. I think many usages will not want to block
indefinitely.

Actually, on that note, I really wanted a poll() function. I never want to
block for messages, just grab one if there is one waiting in the queue.
receiveTimeout(0) seems to be the only way to do it... Again, not
particularly nice or intuitive.
Consider the Win32 message loop: PeekMessage/GetMessage/WaitMessage.. I
think they're all good to have.



 I wonder if there is a solution to the 'shared' problem. Basically every
 single line of code that uses the std.concurrenty api is riddled with casts
 to/from shared... really ugly.

 I think Unique!T should work for the sending side, and then the receive
 side wouldn't have to receive shared(T).  It's something that's been on the
 radar, but I haven't done anything about it yet.



Cool, I'll be interested to see what nice solutions for this could exist.
Jan 21 2012
parent reply "F i L" <witte2008 gmail.com> writes:
Manu wrote:

 Eg, I press '.' and the list of methods appears, and I skim 
 through the
 list and choose the one that looks appropriate, I'll choose 
 receive, and
 then I'll be puzzled by the argument list and why it doesn't 
 work like I
 expect, after a little wasted time, I may begrudgingly read the 
 manual... I
 personally feel this is an API failure, and the single most 
 important thing

 absolutely
 no prior knowledge of the language just using the '.' key with
 code-complete in your IDE. The API's are really exceptionally 
 intuitive.


This is a big restraint to D's popularity. It's certainly a 
complaint I've heard from others. An IDE with intelligence might 
have been a luxury in the past, but it's quickly becoming 
essential to large project development. Things like hunting 
through poorly cross-referenced documentation just to find out 
how to convert a string to an int, then doing it all over again 
when you realize the same function doesn't go both ways is just a 
pain in the ass.
Jan 21 2012
next sibling parent Manu <turkeyman gmail.com> writes:
On 21 January 2012 17:23, F i L <witte2008 gmail.com> wrote:


 Manu wrote:


 Eg, I press '.' and the list of methods appears, and I skim through the
 list and choose the one that looks appropriate, I'll choose receive, and
 then I'll be puzzled by the argument list and why it doesn't work like I
 expect, after a little wasted time, I may begrudgingly read the manual...
 I
 personally feel this is an API failure, and the single most important
 thing

 no prior knowledge of the language just using the '.' key with
 code-complete in your IDE. The API's are really exceptionally intuitive.


 This is a big restraint to D's popularity. It's certainly a complaint I've
 heard from others. An IDE with intelligence might have been a luxury in the
 past, but it's quickly becoming essential to large project development.
 Things like hunting through poorly cross-referenced documentation just to
 find out how to convert a string to an int, then doing it all over again
 when you realize the same function doesn't go both ways is just a pain in
 the ass.


'quickly becoming' :) .. I think that happened 5 years ago. It's long been
a basic requirement, and does really need some attention.
Jan 21 2012
prev sibling next sibling parent Sean Kelly <sean invisibleduck.org> writes:
Seriously?  I usually turn that feature off if I use an IDE that has it. Lar=
ge projects aren't an issue. I've worked on some counted in millions of line=
s of code.=20

Sent from my iPhone

On Jan 21, 2012, at 7:23 AM, "F i L" <witte2008 gmail.com> wrote:


 Manu wrote:

 Eg, I press '.' and the list of methods appears, and I skim through the
 list and choose the one that looks appropriate, I'll choose receive, and
 then I'll be puzzled by the argument list and why it doesn't work like I
 expect, after a little wasted time, I may begrudgingly read the manual...=




 I

 personally feel this is an API failure, and the single most important thi=




ng







 no prior knowledge of the language just using the '.' key with
 code-complete in your IDE. The API's are really exceptionally intuitive.


=20
 This is a big restraint to D's popularity. It's certainly a complaint I've=


 heard from others. An IDE with intelligence might have been a luxury in the=
 past, but it's quickly becoming essential to large project development. Thi=
ngs like hunting through poorly cross-referenced documentation just to find o=
ut how to convert a string to an int, then doing it all over again when you r=
ealize the same function doesn't go both ways is just a pain in the ass.
Jan 21 2012
prev sibling next sibling parent reply Manu <turkeyman gmail.com> writes:
On 21 January 2012 18:09, Sean Kelly <sean invisibleduck.org> wrote:


 I suggest checking out Erlang messaging, as it's the basis for this
 design. Maybe then things will be a bit clearer.



Are you suggesting that erlang is a common language that all programmers
worth their paycheques are familiar with... and would also find intuitive?
I don't know if it's the most sensible API decision to model a design off
something so obscure, unless you suspect that D should appeal primary to
ex-erlang users?

Just to re-iterate, I'm not arguing against the API or it's merits, it's
really cool, just that it shouldn't be the trivial one named receive().
That name should be reserved for the most conventional API.

Seriously?  I usually turn that feature off if I use an IDE that has it.

 Large projects aren't an issue. I've worked on some counted in millions of
 lines of code.


Why even argue this? What's the point in intentionally making D unappealing
to anyone who works in a non-linux professional environment? Do you aim to
alienate those users from the community; keep the community nice and
small...
I honestly don't understand how so many people around here can blindly
consider windows users, and 'IDE users' in general, a niche or minority
user base, and also, what the value of presenting this argument might
actually be?

Who are the majority of professional devs here? What industry do they work
in? Do they, or do they intend to use D in their professional work? What
language are they coming from/using normally in their work? Do they
*really*use vi in the office?
Is there a poll, or some statistics of this sort? I'd be very curious...
because this argument comes up every other day.
Jan 21 2012
next sibling parent "Kiith-Sa" <42 theanswer.com> writes:
Erlang being uncommon doesn't mean it doesn't have awesome 
features.
Java (or COBOL :p) are common, that doesn't mean we should copy 
them
just to make it easier for Java users to move to D.


OT, but this always pisses me off:

I use Vim. On Linux. Vim not being an IDE doesn't mean it doesn't
have autocompletion, or pretty much any common IDE feature (or... 
many that no IDE in existence has, for that matter). You just have
to build your own environment with plugins. I understand most 
people
might not want to spend time to do that, but there are quite
a few that do - and I wouldn't use anything else now, hobby or 
job.

(BTW, I originally used NetBeans, Eclipse, Code::Blocks on 
Windows - I know VS is significantly better, but nothing can tear 
me off
the pure productivity of my buttonless screen displaying 10 files
at once)

Oh, and don't use Vi for development (I don't know anyone who 
does,
anyway - for basic text editing when there's nothing else, yes, 
but for development?).

That said, there's no intelligent autocompletion for D in Vim 
(there is for C/C++, Java, Python...).
I for one would like to have it. But this is not responsibility of
DMD devs - DMD will never turn into Clang.

I hope if anyone works on a project like this, they do it as a 
library
so not only VisualD or DDT or whatever will benefit.


On Saturday, 21 January 2012 at 18:35:40 UTC, Manu wrote:

 On 21 January 2012 18:09, Sean Kelly <sean invisibleduck.org> 
 wrote:


 I suggest checking out Erlang messaging, as it's the basis for 
 this
 design. Maybe then things will be a bit clearer.



 Are you suggesting that erlang is a common language that all 
 programmers
 worth their paycheques are familiar with... and would also find 
 intuitive?
 I don't know if it's the most sensible API decision to model a 
 design off
 something so obscure, unless you suspect that D should appeal 
 primary to
 ex-erlang users?

 Just to re-iterate, I'm not arguing against the API or it's 
 merits, it's
 really cool, just that it shouldn't be the trivial one named 
 receive().
 That name should be reserved for the most conventional API.

 Seriously?  I usually turn that feature off if I use an IDE 
 that has it.

 Large projects aren't an issue. I've worked on some counted in 
 millions of
 lines of code.


 Why even argue this? What's the point in intentionally making D 
 unappealing
 to anyone who works in a non-linux professional environment? Do 
 you aim to
 alienate those users from the community; keep the community 
 nice and
 small...
 I honestly don't understand how so many people around here can 
 blindly
 consider windows users, and 'IDE users' in general, a niche or 
 minority
 user base, and also, what the value of presenting this argument 
 might
 actually be?

 Who are the majority of professional devs here? What industry 
 do they work
 in? Do they, or do they intend to use D in their professional 
 work? What
 language are they coming from/using normally in their work? Do 
 they
 *really*use vi in the office?
 Is there a poll, or some statistics of this sort? I'd be very 
 curious...
 because this argument comes up every other day.
Jan 21 2012
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-01-21 19:35, Manu wrote:

 On 21 January 2012 18:09, Sean Kelly <sean invisibleduck.org
 <mailto:sean invisibleduck.org>> wrote:

     I suggest checking out Erlang messaging, as it's the basis for this
     design. Maybe then things will be a bit clearer.


 Are you suggesting that erlang is a common language that all programmers
 worth their paycheques are familiar with... and would also find intuitive?
 I don't know if it's the most sensible API decision to model a design
 off something so obscure, unless you suspect that D should appeal
 primary to ex-erlang users?

 Just to re-iterate, I'm not arguing against the API or it's merits, it's
 really cool, just that it shouldn't be the trivial one named receive().
 That name should be reserved for the most conventional API.


Scala also uses a similar API as Erlang.

-- 
/Jacob Carlborg
Jan 22 2012
next sibling parent Manu <turkeyman gmail.com> writes:
On 22 January 2012 15:18, Jacob Carlborg <doob me.com> wrote:


 On 2012-01-21 19:35, Manu wrote:


 On 21 January 2012 18:09, Sean Kelly <sean invisibleduck.org
 <mailto:sean invisibleduck.org**>> wrote:

    I suggest checking out Erlang messaging, as it's the basis for this
    design. Maybe then things will be a bit clearer.


 Are you suggesting that erlang is a common language that all programmers
 worth their paycheques are familiar with... and would also find intuitive?
 I don't know if it's the most sensible API decision to model a design
 off something so obscure, unless you suspect that D should appeal
 primary to ex-erlang users?

 Just to re-iterate, I'm not arguing against the API or it's merits, it's
 really cool, just that it shouldn't be the trivial one named receive().
 That name should be reserved for the most conventional API.


 Scala also uses a similar API as Erlang.



Another super-mainstream language that everyone's familiar with :)
Jan 22 2012
prev sibling next sibling parent Sean Kelly <sean invisibleduck.org> writes:
	charset=us-ascii

The popularity of a language has no bearing on the quality of one of its fea=
tures. Are there other message passing schemes you prefer?

Sent from my iPhone

On Jan 22, 2012, at 5:53 AM, Manu <turkeyman gmail.com> wrote:


 On 22 January 2012 15:18, Jacob Carlborg <doob me.com> wrote:
 On 2012-01-21 19:35, Manu wrote:
 On 21 January 2012 18:09, Sean Kelly <sean invisibleduck.org
 <mailto:sean invisibleduck.org>> wrote:
=20
    I suggest checking out Erlang messaging, as it's the basis for this
    design. Maybe then things will be a bit clearer.
=20
=20
 Are you suggesting that erlang is a common language that all programmers
 worth their paycheques are familiar with... and would also find intuitive?=



 I don't know if it's the most sensible API decision to model a design
 off something so obscure, unless you suspect that D should appeal
 primary to ex-erlang users?
=20
 Just to re-iterate, I'm not arguing against the API or it's merits, it's
 really cool, just that it shouldn't be the trivial one named receive().
 That name should be reserved for the most conventional API.
=20
 Scala also uses a similar API as Erlang.
=20
 Another super-mainstream language that everyone's familiar with :)
Jan 22 2012
prev sibling parent reply Manu <turkeyman gmail.com> writes:
On 22 January 2012 18:42, Sean Kelly <sean invisibleduck.org> wrote:


 The popularity of a language has no bearing on the quality of one of its
 features. Are there other message passing schemes you prefer?


As said in the original post, I think receiveOnly() is the most intuitive
API. I just think that one should be named receive(), and perhaps receive()
may be renamed receiveMulti(). Surely that would be more intuitive to more
people?
Also both Only and Multi varieties should have a Timeout version, and I
would love to see a poll()/pollMulti() function.
Jan 22 2012
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/22/12 3:18 PM, Manu wrote:

 On 22 January 2012 18:42, Sean Kelly <sean invisibleduck.org
 <mailto:sean invisibleduck.org>> wrote:

     The popularity of a language has no bearing on the quality of one of
     its features. Are there other message passing schemes you prefer?


 As said in the original post, I think receiveOnly() is the most
 intuitive API. I just think that one should be named receive(), and
 perhaps receive() may be renamed receiveMulti(). Surely that would be
 more intuitive to more people?


Names will not change.


 Also both Only and Multi varieties should have a Timeout version, and I
 would love to see a poll()/pollMulti() function.


This is sensible. You may want to add functions through pull requests, 
or make enhancement requests on bugzilla.


Thanks,

Andrei
Jan 22 2012
next sibling parent reply Manu <turkeyman gmail.com> writes:
On 22 January 2012 23:34, Andrei Alexandrescu <SeeWebsiteForEmail erdani.org

 wrote:



 On 1/22/12 3:18 PM, Manu wrote:


 On 22 January 2012 18:42, Sean Kelly <sean invisibleduck.org

 <mailto:sean invisibleduck.org**>> wrote:

    The popularity of a language has no bearing on the quality of one of
    its features. Are there other message passing schemes you prefer?


 As said in the original post, I think receiveOnly() is the most
 intuitive API. I just think that one should be named receive(), and
 perhaps receive() may be renamed receiveMulti(). Surely that would be
 more intuitive to more people?


 Names will not change.



Why? Surely API's being as intuitive as possible should be a key goal for a
standard library?
The thing isn't supposed to be stable yet is it? If you take the attitude
that no name should ever be changed, then I think there is a problem with
the phobos contribution process.
Phobos contributions have basically no incubation time/process. I've seen
others suggest new stuff should go in exp.xxx to incubate, and it should
only be promoted to std after some time, or some successful usage in
multiple large-ish projects?
It's a shame that basic usability things like that couldn't be caught
earlier.

Do you disagree that receive() and receiveMulti() (with the crazy
var-arg-of-delegates API that nobody would have ever seen in any popular
language before) is a far more intuitive approach?

greatest achievement, and can not be understated.

Also both Only and Multi varieties should have a Timeout version, and I

 would love to see a poll()/pollMulti() function.


 This is sensible. You may want to add functions through pull requests, or
 make enhancement requests on bugzilla.


Shall do one or the other.
Jan 22 2012
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 01/23/2012 12:05 AM, Manu wrote:

 On 22 January 2012 23:34, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org <mailto:SeeWebsiteForEmail erdani.org>>
 wrote:

     On 1/22/12 3:18 PM, Manu wrote:

         On 22 January 2012 18:42, Sean Kelly <sean invisibleduck.org
         <mailto:sean invisibleduck.org>

         <mailto:sean invisibleduck.org
         <mailto:sean invisibleduck.org>__>> wrote:

             The popularity of a language has no bearing on the quality
         of one of
             its features. Are there other message passing schemes you
         prefer?


         As said in the original post, I think receiveOnly() is the most
         intuitive API. I just think that one should be named receive(), and
         perhaps receive() may be renamed receiveMulti(). Surely that
         would be
         more intuitive to more people?


     Names will not change.


 Why? Surely API's being as intuitive as possible should be a key goal
 for a standard library?


Another key goal is that an API should be as concise and powerful as 
possible. Furthermore, the API is very intuitive once you glimpsed over 
the documentation.


 The thing isn't supposed to be stable yet is it? If you take the
 attitude that no name should ever be changed, then I think there is a
 problem with the phobos contribution process.


He said 'Names will not change' not 'All names never change'.


 Phobos contributions have basically no incubation time/process. I've
 seen others suggest new stuff should go in exp.xxx to incubate, and it
 should only be promoted to std after some time, or some successful usage
 in multiple large-ish projects?
 It's a shame that basic usability things like that couldn't be caught
 earlier.


Erlang *has* been used in multiple large projects and it is likely that 
you make use of some service that is powered by erlang on a daily basis. 
It is successful in its niche. Copying its message passing API is 
reasonable and safe: Its concurrency model is the main selling point of 
erlang.

http://programmers.stackexchange.com/questions/112417/real-world-applications-of-erlang


 Do you disagree that receive() and receiveMulti() (with the crazy
 var-arg-of-delegates API that nobody would have ever seen in any popular
 language before) is a far more intuitive approach?


Yes.



 greatest achievement, and can not be understated.



functionality. Can you help me out?
Jan 22 2012
next sibling parent reply Manu <turkeyman gmail.com> writes:
On 23 January 2012 02:00, Timon Gehr <timon.gehr gmx.ch> wrote:


 Erlang *has* been used in multiple large projects and it is likely that
 you make use of some service that is powered by erlang on a daily basis. It
 is successful in its niche. Copying its message passing API is reasonable
 and safe: Its concurrency model is the main selling point of erlang.

 http://programmers.**stackexchange.com/questions/**112417/real-world-**
 applications-of-erlang<http://programmers.stackexchange.com/questions/112417/real-world-applications-of-erlang>



Oh come on.. It's niche, unfamiliar to most people, and we're talking about
name and argument list clarity with respect to what would be instinctive to
the most users, not 'model' or API design, that's obviously fine.



 greatest achievement, and can not be understated.



 Can you help me out?


I'm not referring to this API in particular, I'm referring to the fairly

I've ever talked to agree that one of it's biggest selling points, and
possibly even the key reason they use it; because it was so accessible and
productive from the instant they tried it out.
You shouldn't need to read anything. Pressing '.' in the IDE shows lists of
classes/methods/etc, and common sense writes your code. This requires that
the function names make perfect sense, and the argument lists are as you
intuitively expect.

If I: send(tid, myThing);
I expect to: myThing = receive!SomeThing();

How can you argue that it's not intuitive to receive what you sent?
There's nothing in: send(tid, something); that suggests the expected
compliment API should take a var-arg list of undefined things. It's not
clear from receive()'s signature that it should receive delegates, it looks
like it could receive anything. The delegate signature is un-knowable from
the functions own signature, nor what the delegates are even supposed to do.
Also, the name 'receiveOnly' doesn't actually make sense unless you
*already know* that receive() is effectively receiveMulti. If I was
scrolling through the pop-up list of methods, I would not confidently
predict what that does.

You MUST read the docs to understand receive(), and that is an instant fail
for my money. You don't need to read the docs to understand receiveOnly(),
it's perfectly obvious what it does and how it works on sight, and matches
what you expect as the natural complement to send().

On 23 January 2012 02:55, Jonathan M Davis <jmdavisProg gmx.com> wrote:


 On Sunday, January 22, 2012 23:18:46 Manu wrote:

 On 22 January 2012 18:42, Sean Kelly <sean invisibleduck.org> wrote:

 The popularity of a language has no bearing on the quality of one of




 its

 features. Are there other message passing schemes you prefer?


 As said in the original post, I think receiveOnly() is the most intuitive
 API. I just think that one should be named receive(), and perhaps


 receive()

 may be renamed receiveMulti(). Surely that would be more intuitive to


 more

 people?


 I'm not sure that that's true. But since you have to read the docs before
 using _any_ of it, I don't see it as an issue.



My argument is that you shouldn't have to read the docs AT ALL to access
basic functionality. I say "how do I create a worker thread?", and someone
in the office answers "use std.concurrency", I type std.concurrency and
press '.', everything I care about appears, and if it's designed correctly,
a momentary glance will have me headed in the right path. It also reflects
on why I really hate seeing 'auto' used in sample code.


Anyway, it's irrelevant, Andrei has spoken :)

I'm really not just trying to be a picky bastard for the sake of it... it's
a genuine red flag for me. And I'm not just raising the point for this
single example, I think this should be a basic principle applied
universally. Every API, before being accepted, should be scrutinised; does
the name make perfect sense given conventional presumptions of the system?
do the args/template args appear obvious? At very least just for the
key/fundamental parts of the API. Advanced functionality is sure to exist,
can/should have more specific names, and will probably require looking up
the docs, sure.

I'm not a hobbyist looking to play with a new toy, I'm trying to be
genuinely realistic about what I expect with respect to what else is out
there. And it's not hard. For the most part, language-wise, D delivers the
goods. The library needs polish, but I think everyone knows that.

function, lost D a significant number of points at face value with me after
it wasted my time and forced me to read the fairly sub-standard docs.

I simply expect more these days. You can call me whatever you like :)
Jan 25 2012
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 01/25/2012 11:49 AM, Manu wrote:
...

 My argument is that you shouldn't have to read the docs AT ALL to access
 basic functionality. I say "how do I create a worker thread?", and
 someone in the office answers "use std.concurrency", I type
 std.concurrency and press '.', everything I care about appears, and if
 it's designed correctly, a momentary glance will have me headed in the
 right path. It also reflects on why I really hate seeing 'auto' used in
 sample code.


Except that for 'worker thread' the guy in the office will presumably 
answer "use std.parallelism". You were presumably not using the most 
appropriate tool for the job.
Jan 25 2012
prev sibling next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
On Jan 25, 2012, at 2:49 AM, Manu wrote:


 On 23 January 2012 02:00, Timon Gehr <timon.gehr gmx.ch> wrote:
 Erlang *has* been used in multiple large projects and it is likely =


that you make use of some service that is powered by erlang on a daily =
basis. It is successful in its niche. Copying its message passing API is =
reasonable and safe: Its concurrency model is the main selling point of =
erlang.

=20
 =


http://programmers.stackexchange.com/questions/112417/real-world-applicati=
ons-of-erlang

=20
 Oh come on.. It's niche, unfamiliar to most people, and we're talking =


about name and argument list clarity with respect to what would be =
instinctive to the most users, not 'model' or API design, that's =
obviously fine.

Personally, I expected receiveOnly to see infrequent use compared to =
receive.  At least in my own code, it's rare that I'd want a receive =
call to throw if there's any message in the queue other than the one I'm =
looking for.  So the naming scheme was a mistaken assumption of popular =
use.




 greatest achievement, and can not be understated.
=20
=20



functionality. Can you help me out?

=20
 I'm not referring to this API in particular, I'm referring to the =



Most people I've ever talked to agree that one of it's biggest selling =
points, and possibly even the key reason they use it; because it was so =
accessible and productive from the instant they tried it out.

 You shouldn't need to read anything. Pressing '.' in the IDE shows =


lists of classes/methods/etc, and common sense writes your code. This =
requires that the function names make perfect sense, and the argument =
lists are as you intuitively expect.

=20
 If I: send(tid, myThing);
 I expect to: myThing =3D receive!SomeThing();
=20
 How can you argue that it's not intuitive to receive what you sent?


We could overload receive even more so that if it has only one argument =
and that argument is not a callable type, it does receiveOnly.  That =
might be deceptive however.  What I like about "receiveOnly" is that the =
name itself suggests that anything other than the specified type is not =
expected, and so some measure will probably be taken.  receive!T says to =
me "look for a message of this type and block if it's not present."



 There's nothing in: send(tid, something); that suggests the expected =


compliment API should take a var-arg list of undefined things. It's not =
clear from receive()'s signature that it should receive delegates, it =
looks like it could receive anything. The delegate signature is =
un-knowable from the functions own signature, nor what the delegates are =
even supposed to do.


doesn't have templates.



 Also, the name 'receiveOnly' doesn't actually make sense unless you =


*already know* that receive() is effectively receiveMulti. If I was =
scrolling through the pop-up list of methods, I would not confidently =
predict what that does.

Matter of opinion I suppose.  See above.=
Jan 26 2012
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 01/26/2012 09:07 PM, Sean Kelly wrote:

 On Jan 25, 2012, at 2:49 AM, Manu wrote:


 On 23 January 2012 02:00, Timon Gehr<timon.gehr gmx.ch>  wrote:
 Erlang *has* been used in multiple large projects and it is likely that you
make use of some service that is powered by erlang on a daily basis. It is
successful in its niche. Copying its message passing API is reasonable and
safe: Its concurrency model is the main selling point of erlang.

 http://programmers.stackexchange.com/questions/112417/real-world-applications-of-erlang

 Oh come on.. It's niche, unfamiliar to most people, and we're talking about
name and argument list clarity with respect to what would be instinctive to the
most users, not 'model' or API design, that's obviously fine.


 Personally, I expected receiveOnly to see infrequent use compared to receive. 
At least in my own code, it's rare that I'd want a receive call to throw if
there's any message in the queue other than the one I'm looking for.  So the
naming scheme was a mistaken assumption of popular use.


It is not necessarily a mistaken assumption. I still assume it.
Jan 26 2012
prev sibling next sibling parent reply Manu <turkeyman gmail.com> writes:
On 26 January 2012 22:07, Sean Kelly <sean invisibleduck.org> wrote:


 On Jan 25, 2012, at 2:49 AM, Manu wrote:


 On 23 January 2012 02:00, Timon Gehr <timon.gehr gmx.ch> wrote:
 Erlang *has* been used in multiple large projects and it is likely that


 you make use of some service that is powered by erlang on a daily basis. It
 is successful in its niche. Copying its message passing API is reasonable
 and safe: Its concurrency model is the main selling point of erlang.


 http://programmers.stackexchange.com/questions/112417/real-world-applications-of-erlang

 Oh come on.. It's niche, unfamiliar to most people, and we're talking


 about name and argument list clarity with respect to what would be
 instinctive to the most users, not 'model' or API design, that's obviously
 fine.

 Personally, I expected receiveOnly to see infrequent use compared to
 receive.  At least in my own code, it's rare that I'd want a receive call
 to throw if there's any message in the queue other than the one I'm looking
 for.  So the naming scheme was a mistaken assumption of popular use.


Well perhaps my usage is biased, but I think many/most threads are spawned
with the intent of receiving one particular workload from one source. I
think a thread that receives a variable/dynamic workload is probably less
common, although certainly does exist, but regardless of that, from the
point of view of API design, I don't think the API clearly communicates
that intent. It certainly had me scratching my head until I _read the
docs_, which is the basis of my argument.
If I'm wrong on that point, then there's nothing to argue :)

(bear in mind, this isn't the only thing I mentioned in my OP. As with
prior posts where I've made the mistake of listing things, the the single
most trivial detail in my list is the one that spawns the longest
conversation ;)




 greatest achievement, and can not be understated.





 functionality. Can you help me out?

 I'm not referring to this API in particular, I'm referring to the fairly



 I've ever talked to agree that one of it's biggest selling points, and
 possibly even the key reason they use it; because it was so accessible and
 productive from the instant they tried it out.

 You shouldn't need to read anything. Pressing '.' in the IDE shows lists


 of classes/methods/etc, and common sense writes your code. This requires
 that the function names make perfect sense, and the argument lists are as
 you intuitively expect.

 If I: send(tid, myThing);
 I expect to: myThing = receive!SomeThing();

 How can you argue that it's not intuitive to receive what you sent?


 We could overload receive even more so that if it has only one argument
 and that argument is not a callable type, it does receiveOnly.  That might
 be deceptive however.



I agree that's a pretty ugly approach. I can see your point, but it only
makes sense to me with advanced knowledge of the API. If I approach it
without that insight, as I did, it's not so clear, or even misleading.
Consider the position you're likely to be when you reach for the API,
trying to use it for the first time, and you've just typed: send(tid,
myThing) not 10 seconds prior... what do you expect to type next?



 What I like about "receiveOnly" is that the name itself suggests that
 anything other than the specified type is not expected, and so some measure
 will probably be taken.



Again, this only makes sense to me if you already expect that the act of
receiving (as a compliment to the send API, which you've already invoked
and have a presumption about), was capable of receiving any/multiple
things, rather than receiving what you just sent a few lines back...

 receive!T says to me "look for a message of this type and block if it's

 not present."


Perfect. It says that to me too. I'm lost now though, this is the behaviour
of receiveOnly... are you agreeing now? :)


 There's nothing in: send(tid, something); that suggests the expected
 compliment API should take a var-arg list of undefined things. It's not
 clear from receive()'s signature that it should receive delegates, it looks
 like it could receive anything. The delegate signature is un-knowable from
 the functions own signature, nor what the delegates are even supposed to do.


 doesn't have templates.



But in a case like this, such an apparently arguably ambiguous API wouldn't
be permitted. It would be restructured, or the competing API's both renamed
to something more clear.


 Also, the name 'receiveOnly' doesn't actually make sense unless you
 *already know* that receive() is effectively receiveMulti. If I was
 scrolling through the pop-up list of methods, I would not confidently
 predict what that does.

 Matter of opinion I suppose.  See above.



Perhaps so. I suppose my mental flow was by drawing a direct contrast to
the send() API, which I called not 10 seconds prior, before trying to type
my receive code.


Anyway, I think it's a void topic in this instance, it's been stated that
it will not change, I'm good with that.
I was just trying to raise the point that I think more care should be taken
to the end that the standard library (across the board, not just in this
case) should be indisputably intuitive, and with particular consideration
to auto-complete listings, which should be self evident enough to do most
basic functionality a system offers.



 Jan 26 2012



  parent  Timon Gehr <timon.gehr gmx.ch>  writes:


On 01/26/2012 10:19 PM, Manu wrote:





make code type check (and duplicate static variables), templates 


Templates have the benefit that they are a lot more powerful, generics 
have the benefit that they can be type checked modularly and generic 
functions can be virtual.



 Jan 26 2012



prev sibling  parent  Sean Kelly <sean invisibleduck.org>  writes:


On Jan 26, 2012, at 1:19 PM, Manu wrote:


 On 26 January 2012 22:07, Sean Kelly <sean invisibleduck.org> wrote:
 =20
 What I like about "receiveOnly" is that the name itself suggests that =


anything other than the specified type is not expected, and so some =
measure will probably be taken.

=20
 Again, this only makes sense to me if you already expect that the act =


of receiving (as a compliment to the send API, which you've already =
invoked and have a presumption about), was capable of receiving =
any/multiple things, rather than receiving what you just sent a few =
lines back...

=20
  receive!T says to me "look for a message of this type and block if =


it's not present."

=20
 Perfect. It says that to me too. I'm lost now though, this is the =


behaviour of receiveOnly... are you agreeing now? :)

It's only the behavior of receiveOnly if the queue is completely empty.  =
If it contains any other message, receiveOnly will throw.  But from what =
you've said I think this is simply a difference in how we design apps.  =
For me, it's common to send multiple message types.  For you, it sounds =
like it is not.



 Jan 26 2012



prev sibling next sibling parent  Sean Kelly <sean invisibleduck.org>  writes:


	charset=us-ascii

The names as they exist match what's in TDPL, so they're somewhat set in sto=
ne.=20

Sent from my iPhone

On Jan 22, 2012, at 3:05 PM, Manu <turkeyman gmail.com> wrote:


 On 22 January 2012 23:34, Andrei Alexandrescu <SeeWebsiteForEmail erdani.o=


rg> wrote:

 On 1/22/12 3:18 PM, Manu wrote:
 On 22 January 2012 18:42, Sean Kelly <sean invisibleduck.org
=20
 <mailto:sean invisibleduck.org>> wrote:
=20
    The popularity of a language has no bearing on the quality of one of
    its features. Are there other message passing schemes you prefer?
=20
=20
 As said in the original post, I think receiveOnly() is the most
 intuitive API. I just think that one should be named receive(), and
 perhaps receive() may be renamed receiveMulti(). Surely that would be
 more intuitive to more people?
=20
 Names will not change.
=20
 Why? Surely API's being as intuitive as possible should be a key goal for a=


 standard library?

 The thing isn't supposed to be stable yet is it? If you take the attitude t=


hat no name should ever be changed, then I think there is a problem with the=
 phobos contribution process.

 Phobos contributions have basically no incubation time/process. I've seen o=


thers suggest new stuff should go in exp.xxx to incubate, and it should only=
 be promoted to std after some time, or some successful usage in multiple la=
rge-ish projects?

 It's a shame that basic usability things like that couldn't be caught earl=


ier.

=20
 Do you disagree that receive() and receiveMulti() (with the crazy var-arg-=


of-delegates API that nobody would have ever seen in any popular language be=
fore) is a far more intuitive approach?




st achievement, and can not be understated.

=20
 Also both Only and Multi varieties should have a Timeout version, and I
 would love to see a poll()/pollMulti() function.
=20
 This is sensible. You may want to add functions through pull requests, or m=


ake enhancement requests on bugzilla.

=20
 Shall do one or the other.





 Jan 22 2012



prev sibling  parent  Manu <turkeyman gmail.com>  writes:


On 23 January 2012 01:49, Sean Kelly <sean invisibleduck.org> wrote:


 The names as they exist match what's in TDPL, so they're somewhat set in
 stone.


Ah, I see. That makes it considerably harder to go back on then :)



 Jan 23 2012



prev sibling next sibling parent reply Sean Kelly <sean invisibleduck.org>  writes:


	charset=us-ascii

On Jan 21, 2012, at 10:35 AM, Manu <turkeyman gmail.com> wrote:


 On 21 January 2012 18:09, Sean Kelly <sean invisibleduck.org>=20
=20
 Seriously?  I usually turn that feature off if I use an IDE that has it. L=


arge projects aren't an issue. I've worked on some counted in millions of li=
nes of code.

=20
 Why even argue this? What's the point in intentionally making D unappealin=


g to anyone who works in a non-linux professional environment? Do you aim to=
 alienate those users from the community; keep the community nice and small.=
..

 I honestly don't understand how so many people around here can blindly con=


sider windows users, and 'IDE users' in general, a niche or minority user ba=
se, and also, what the value of presenting this argument might actually be?

I wasn't making any sort of argument, I was merely surprised at this stateme=
nt.  Even most of the Java devs I know aren't this reliant on an IDE.=20=



 Jan 21 2012



  parent  "Marco Leise" <Marco.Leise gmx.de>  writes:


Am 22.01.2012, 01:42 Uhr, schrieb Sean Kelly <sean invisibleduck.org>:


 On Jan 21, 2012, at 10:35 AM, Manu <turkeyman gmail.com> wrote:


 On 21 January 2012 18:09, Sean Kelly <sean invisibleduck.org>

 Seriously?  I usually turn that feature off if I use an IDE that has  
 it. Large projects aren't an issue. I've worked on some counted in  
 millions of lines of code.

 Why even argue this? What's the point in intentionally making D  
 unappealing to anyone who works in a non-linux professional  
 environment? Do you aim to alienate those users from the community;  
 keep the community nice and small...
 I honestly don't understand how so many people around here can blindly  
 consider windows users, and 'IDE users' in general, a niche or minority  
 user base, and also, what the value of presenting this argument might  
 actually be?


 I wasn't making any sort of argument, I was merely surprised at this  
 statement.  Even most of the Java devs I know aren't this reliant on an  
 IDE.


I was as a Java developer reliant on an IDE. It integrates such features  
as SVN, refactoring, Maven2, remote debugging, powerful code completion  
including turning the letters "MSO" into "MySpecialObject" using  
camel-case matching, an embedded compiler capable of quick recompiling  
when you save a file, warnings while you are editing, powerful search for  
things like "write access to field 'x'", ... the list goes on.



 Jan 22 2012



prev sibling  parent  Manu <turkeyman gmail.com>  writes:


On 22 January 2012 02:42, Sean Kelly <sean invisibleduck.org> wrote:


 On Jan 21, 2012, at 10:35 AM, Manu <turkeyman gmail.com> wrote:

 On 21 January 2012 18:09, Sean Kelly <sean invisibleduck.org>

 Seriously?  I usually turn that feature off if I use an IDE that has it.

 Large projects aren't an issue. I've worked on some counted in millions of
 lines of code.


 Why even argue this? What's the point in intentionally making D
 unappealing to anyone who works in a non-linux professional environment? Do
 you aim to alienate those users from the community; keep the community nice
 and small...
 I honestly don't understand how so many people around here can blindly
 consider windows users, and 'IDE users' in general, a niche or minority
 user base, and also, what the value of presenting this argument might
 actually be?


 I wasn't making any sort of argument, I was merely surprised at this
 statement.  Even most of the Java devs I know aren't this reliant on an
 IDE.


Most of the Java devs I know use Eclipse, and quite like the auto-compile
stuff, code completion, and the reasonable quality integrated debugger.
That said, most of the Java devs I know work for Google, who seem to
promote use of Eclipse internally.

Regardless, I'm fairly surprised that you're surprised that there are many
devs that wouldn't bother with a toolchain if it doesn't integrate with
their company's workflow. For most businesses, integration with their
company workflow is basic pre-requisite to consideration for adoption.



 Jan 21 2012



prev sibling next sibling parent  Sean Kelly <sean invisibleduck.org>  writes:


	charset=us-ascii

I suggest checking out Erlang messaging, as it's the basis for this design. M=
aybe then things will be a bit clearer.=20

Sent from my iPhone

On Jan 21, 2012, at 6:34 AM, Manu <turkeyman gmail.com> wrote:


 On 20 January 2012 20:06, Sean Kelly <sean invisibleduck.org> wrote:
 On Jan 20, 2012, at 5:10 AM, Manu wrote:

 I had some troubles with std.concurrency which I thought it might be nic=




e to address.

 Perhaps the most major problem I had was related to the concept of threa=




d ownership. If a spawned threads parent thread dies, it also receives a sig=
nal to kill its self, but it seems impossible to reassign ownership.

 In my case I had threads A, B and C...
   Thread A is the main thread, which may spawn many temporary worker thr=




eads B, which may last 1-2 seconds.

   During the life of B, it may spawn C, which may persist for hours.
   B promptly dies, and any C's that were spawned receive the kill signal=




, which I ignore.

   Thread A, the main thread may exit, and I would really like all C's to=




 receive that notification, but they were are all orphaned when their B died=
.

 The problem is, when I spawn a C, it should be created as a child of A s=




omehow, rather than a child of the transient B... Some mechanism to solve th=
is sort of problem would be useful.

=20
 Erlang has functions to link and unlink threads from one another, and I've=


 already implemented a bit of it in std.concurrency.  A fuller implementatio=
n would probably be sufficient for your needs.

=20
=20

 Another usability problem I had was that, intuitively, the simpler funct=




ion with intuitive usage pattern receiveOnly() should be named receive().

 And receive() with the complex var-arg list of delegates should be named=




 something more complex.

=20
 Matter of opinion.  I think receiveOnly indicates what the function does, a=


nd I think it's important to indicate that receiving anything else is unexpe=
cted and will trigger an error.

=20
 Well I'm just saying as a new comer what I consider to be intuitive or not=



ava, php, ecma, etc)... I've never seen an api like receive() in any languag=
e before. It definitely is a D-ish API, and wouldn't be expected by most use=
rs.

 I also think most instances of passing messages between 2 threads will hav=


e a tight well-defined expectation of send/receive types. receiveOnly() seem=
s far more intuitive to me, and simpler to achieve 90(100?)% of my jobs.

 Eg, I press '.' and the list of methods appears, and I skim through the li=


st and choose the one that looks appropriate, I'll choose receive, and then I=
'll be puzzled by the argument list and why it doesn't work like I expect, a=
fter a little wasted time, I may begrudgingly read the manual... I personall=


owledge of the language just using the '.' key with code-complete in your ID=
E. The API's are really exceptionally intuitive.

=20
 =20

 receiveTimeout() has no receiveTimeoutOnly(), which is the function I al=




most always want to use... and receiveTimeout() didn't actually work for me a=
nyway (it wouldn't receive a duration as per the documentation, I had to pas=
s an int)

=20
 I think this is an artifact of the syntax.  There's no way to have a retur=


n value that indicates a timeout occurred.  If receiving a duration (ie. a n=
on-reference type) doesn't work then I'd consider that a bug.

=20
 Syntax or otherwise, it's kinda broken. receiveOnlyTimeout() is a very imp=


ortant function for my money. I think many usages will not want to block ind=
efinitely.

=20
 Actually, on that note, I really wanted a poll() function. I never want to=


 block for messages, just grab one if there is one waiting in the queue. rec=
eiveTimeout(0) seems to be the only way to do it... Again, not particularly n=
ice or intuitive.

 Consider the Win32 message loop: PeekMessage/GetMessage/WaitMessage.. I th=


ink they're all good to have.

=20
=20

 I wonder if there is a solution to the 'shared' problem. Basically every=




 single line of code that uses the std.concurrenty api is riddled with casts=
 to/from shared... really ugly.

=20
 I think Unique!T should work for the sending side, and then the receive si=


de wouldn't have to receive shared(T).  It's something that's been on the ra=
dar, but I haven't done anything about it yet.

=20
 Cool, I'll be interested to see what nice solutions for this could exist.





 Jan 21 2012



prev sibling next sibling parent  "Martin Nowak" <dawg dawgfoto.de>  writes:


On Thu, 19 Jan 2012 23:36:12 +0100, Sean Kelly <sean invisibleduck.org>  
wrote:


 Thanks :-)  If you have ideas on how it could be improved, please let me  
 know.


Well you know the obvious extension, extending this to IPC, networking and  
user defined transport layers.
Of course we're lacking a marshalling solution for this.

ZeroMQ is probably a too heavy dependency, but it offers interesting  
connection schemes.



 Jan 21 2012



prev sibling  parent  Jonathan M Davis <jmdavisProg gmx.com>  writes:


On Sunday, January 22, 2012 23:18:46 Manu wrote:

 On 22 January 2012 18:42, Sean Kelly <sean invisibleduck.org> wrote:

 The popularity of a language has no bearing on the quality of one of its
 features. Are there other message passing schemes you prefer?


 
 As said in the original post, I think receiveOnly() is the most intuitive
 API. I just think that one should be named receive(), and perhaps receive()
 may be renamed receiveMulti(). Surely that would be more intuitive to more
 people?


I'm not sure that that's true. But since you have to read the docs before 
using _any_ of it, I don't see it as an issue. You have to understand it 
before you can use it, and if you understand it, what's it matter if it's 
receiveOnly and receive instead of receiveOneOf and receive?

The problems with std.concurrency have not been its design but its lack of 
documentation (which Sean has apparently improved - though I haven't looked at 
it yet, so I can't comment), and the fact that it doesn't work correctly with 
shared. It would be valuable to be able to say that you're _moving_ a value 
across such that the current thread doesn't own it anymore, but that's really 
a language issue, not an issue with std.concurrency.

The naming strikes me as bikeshedding. The names work as they are.

- Jonathan M Davis



 Jan 22 2012