www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - std.signal : voting has begun

reply "Dicebot" <public dicebot.lv> writes:
Some time ago there have been a review for `std.signal` Phobos 
proposal 
(http://forum.dlang.org/thread/ujlhznaphepibgtpcoqz forum.dlang.org#post-ujlhznaphepibgtpcoqz
40forum.dlang.org). 
It have not received much feedback and I was a it too busy to 
proceed with final voting at that moment but with no outstanding 
issues to address nothing prevents that final step.

Let's put 2 week deadline to refresh memories about the proposal 
and make some decision. Voting closes at January 20th 23:59 GMT 0

Please take some time and help make Phobos better ;)
Jan 06 2014
next sibling parent "ilya-stromberg" <ilya-stromberg-2009 yandex.ru> writes:
On Monday, 6 January 2014 at 09:11:09 UTC, Dicebot wrote:

 Some time ago there have been a review for `std.signal` Phobos 
 proposal 
 (http://forum.dlang.org/thread/ujlhznaphepibgtpcoqz forum.dlang.org#post-ujlhznaphepibgtpcoqz
40forum.dlang.org). 
 It have not received much feedback and I was a it too busy to 
 proceed with final voting at that moment but with no 
 outstanding issues to address nothing prevents that final step.

 Let's put 2 week deadline to refresh memories about the 
 proposal and make some decision. Voting closes at January 20th 
 23:59 GMT 0

 Please take some time and help make Phobos better ;)


Yes.

It's not a condition, but wish list:

1) Robert, please add thread-safe example for multi-thread 
application. I know that you think it's unnecessary 
(http://forum.dlang.org/post/ykwgtaysaaejyvjsqjfe forum.dlang.org), 
but I disagree.

2) It looks like D module system is not good enough. Robert 
creates additional struct `Signal` and string mixin `signal` to 
immitate C++ `friend` keyword. Maybe we should add this 
functionality to the D language.
Jan 06 2014
prev sibling next sibling parent "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Monday, 6 January 2014 at 09:11:09 UTC, Dicebot wrote:

 Some time ago there have been a review for `std.signal` Phobos 
 proposal 
 (http://forum.dlang.org/thread/ujlhznaphepibgtpcoqz forum.dlang.org#post-ujlhznaphepibgtpcoqz
40forum.dlang.org). 
 It have not received much feedback and I was a it too busy to 
 proceed with final voting at that moment but with no 
 outstanding issues to address nothing prevents that final step.

 Let's put 2 week deadline to refresh memories about the 
 proposal and make some decision. Voting closes at January 20th 
 23:59 GMT 0

 Please take some time and help make Phobos better ;)


No.

I think the use of a string mixin here is bad for usability, 
readability and documentation. I think we should either search 
for a different solution to this problem (maybe even think about 
a language enhancement) or just abandon the idea altogether.

I also think it would be better if the "weak" connect that 
currently takes a delegate would just take a function pointer; as 
it is, I think this part of the interface is error prone.

On a semi-related note, the implementation has a number of 
problems. As they don't affect the interface, they don't count 
towards my vote, but I'll mention them anyway: the code uses 
widely inconsistent formatting which really harms readability, 
and there's at least one seriously questionable allocation 
strategy in there. Additionally, I think the presented 
documentation is really poorly written.
Jan 06 2014
prev sibling next sibling parent "Robert" <jfanatiker gmx.at> writes:
Just a little update: More recent and prettier documentation can 
be found at:

https://vhios.dyndns.org/dlang.org/web/phobos-prerelease/std_signal.html

The pull request for phobos can be found here:

https://github.com/D-Programming-Language/phobos/pull/1833/files

Best regards,

Robert
Jan 07 2014
prev sibling next sibling parent reply =?iso-8859-1?Q?Robert_M._M=FCnch?= <robert.muench saphirion.com> writes:
On 2014-01-06 09:11:07 +0000, Dicebot said:


 Some time ago there have been a review for `std.signal` Phobos proposal 
 (http://forum.dlang.org/thread/ujlhznaphepibgtpcoqz forum.dlang.org#post-ujlhznaphepibgtpcoqz
40forum.dlang.org). 
 It have not received much feedback and I was a it too busy to proceed 
 with final voting at that moment but with no outstanding issues to 
 address nothing prevents that final step.
 
 Let's put 2 week deadline to refresh memories about the proposal and 
 make some decision. Voting closes at January 20th 23:59 GMT 0
 
 Please take some time and help make Phobos better ;)


Hi, not really a comment regarding the actual implementation but I 
think that good debug support for signales & slots helps a lot in using 
it. What do I mean with this:

- a way to dump in a human readable form the run-time connections. 
Which function / class / etc. is currently attached to which signal?
- automatic logging like a call-stack in a debugger to get an idea when 
which signal is acted on
- a way to get the order of activation for debugging to identify 
unwanted side-effects
- etc.

Big signal & slot implementaitons can be hard to debug, this should be 
as simple as possible.

-- 
Robert M. Mnch
Saphirion AG

http://www.saphirion.com
smarter | better | faster
Jan 10 2014
parent "Dicebot" <public dicebot.lv> writes:
On Friday, 10 January 2014 at 12:24:18 UTC, Robert M. Münch wrote:

 Hi, not really a comment regarding the actual implementation 
 but I think that good debug support for signales & slots helps 
 a lot in using it. What do I mean with this:

 - a way to dump in a human readable form the run-time 
 connections. Which function / class / etc. is currently 
 attached to which signal?
 - automatic logging like a call-stack in a debugger to get an 
 idea when which signal is acted on
 - a way to get the order of activation for debugging to 
 identify unwanted side-effects
 - etc.

 Big signal & slot implementaitons can be hard to debug, this 
 should be as simple as possible.


Please move discussion to matching thread linked in first post. 
This one is for voting.
Jan 10 2014
prev sibling next sibling parent "Damian Day" <damianroyday gmail.com> writes:
On Monday, 6 January 2014 at 09:11:09 UTC, Dicebot wrote:

 Some time ago there have been a review for `std.signal` Phobos 
 proposal 
 (http://forum.dlang.org/thread/ujlhznaphepibgtpcoqz forum.dlang.org#post-ujlhznaphepibgtpcoqz
40forum.dlang.org). 
 It have not received much feedback and I was a it too busy to 
 proceed with final voting at that moment but with no 
 outstanding issues to address nothing prevents that final step.

 Let's put 2 week deadline to refresh memories about the 
 proposal and make some decision. Voting closes at January 20th 
 23:59 GMT 0

 Please take some time and help make Phobos better ;)


Yes.
I use it, it's been rock solid so far.
Jan 11 2014
prev sibling next sibling parent =?iso-8859-1?Q?Robert_M._M=FCnch?= <robert.muench saphirion.com> writes:
On 2014-01-06 09:11:07 +0000, Dicebot said:


 Some time ago there have been a review for `std.signal` Phobos proposal 
 (http://forum.dlang.org/thread/ujlhznaphepibgtpcoqz forum.dlang.org#post-ujlhznaphepibgtpcoqz
40forum.dlang.org). 
 It have not received much feedback and I was a it too busy to proceed 
 with final voting at that moment but with no outstanding issues to 
 address nothing prevents that final step.
 
 Let's put 2 week deadline to refresh memories about the proposal and 
 make some decision. Voting closes at January 20th 23:59 GMT 0
 
 Please take some time and help make Phobos better ;)


Yes. It's a fundamental pattern that should be in Phobos.

-- 
Robert M. Mnch
Saphirion AG

http://www.saphirion.com
smarter | better | faster
Jan 13 2014
prev sibling next sibling parent reply "Dicebot" <public dicebot.lv> writes:
To everyone: please consider replying in linked discussion thread 
if you don't feel like you are going to vote for any reason. So 
far activity is rather low and I think I will need some feedback 
to determine if it is because of low demand or for some other 
reasons.
Jan 13 2014
parent reply =?iso-8859-1?Q?Robert_M._M=FCnch?= <robert.muench saphirion.com> writes:
On 2014-01-13 13:50:09 +0000, Dicebot said:


 To everyone: please consider replying in linked discussion thread if 
 you don't feel like you are going to vote for any reason.


Don't understand what you mean... How about explaining how to vote if 
it's not here, or there, ... keep things simple please.


 So far activity is rather low and I think I will need some feedback to 
 determine if it is because of low demand or for some other reasons.


Maybe because people don't understand the process.

-- 
Robert M. Mnch
Saphirion AG

http://www.saphirion.com
smarter | better | faster
Jan 13 2014
parent "Dicebot" <public dicebot.lv> writes:
On Monday, 13 January 2014 at 17:36:22 UTC, Robert M. Münch wrote:

 On 2014-01-13 13:50:09 +0000, Dicebot said:


 To everyone: please consider replying in linked discussion 
 thread if you don't feel like you are going to vote for any 
 reason.


 Don't understand what you mean... How about explaining how to 
 vote if it's not here, or there, ... keep things simple please.


I am asking for input from those who decided not to vote for some 
reason.


 So far activity is rather low and I think I will need some 
 feedback to determine if it is because of low demand or for 
 some other reasons.


 Maybe because people don't understand the process.


It is no different from process used to proceed with std.d.lexer 
which got 21 vote in smaller time frame. I am especially 
concerned about lack of votes from Phobos core team.
Jan 13 2014
prev sibling next sibling parent reply "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> writes:
On Monday, 6 January 2014 at 09:11:09 UTC, Dicebot wrote:

 Some time ago there have been a review for `std.signal` Phobos 
 proposal 
 (http://forum.dlang.org/thread/ujlhznaphepibgtpcoqz forum.dlang.org#post-ujlhznaphepibgtpcoqz
40forum.dlang.org). 
 It have not received much feedback and I was a it too busy to 
 proceed with final voting at that moment but with no 
 outstanding issues to address nothing prevents that final step.

 Let's put 2 week deadline to refresh memories about the 
 proposal and make some decision. Voting closes at January 20th 
 23:59 GMT 0

 Please take some time and help make Phobos better ;)


I am opposed to merging std.signal in its current form. It is not
at the level of documentation and implementation quality needed
for new Phobos modules.

* Documentation has numerous mistakes, omissions, disfluencies,
and colloquialisms that seriously decrease credibility of the
library. Examples:

- The first sentence (sic!) is not terminated with any
punctuation sign.

- The third sentence "They were first introduced in the Qt GUI
toolkit, alternate implementations are libsig++ or Boost.Signals2
similar concepts are implemented in other languages than C++
too." does not parse.

- Numerous symbolic identifiers (std.signal, emit, ref, etc) are
not in code font. Some should be cross-referenced, too.

- Colloqualisms should be eliminated ("very loose way", "Do some
fancy stuff", "you"/"your")

- All but one uses of "which" should be replaced with "that"

- Many, many others

* There's no synopsis at the very beginning motivating the module
with a simple example.

* There's no motivation or explanation given for RestrictedSignal
and no example of where one should use it.

* The notion of "strong" connection is not motivated and poorly
defined ("If in your application the connections made by a signal
are not that loose...")

After reading the very brief documentation I was unfortunately
left with an unclear picture of what the code offers and what are
its limitations. What is clear to me is that documentation needs
serious work that cannot probably be addressed in time for this
review cycle.

The code:

* Portions look foreign compared to the rest of Phobos, e.g.
spacing present around some operators but not others following no
apparent rule. This is quite jarring.

* Quadratic growth strategy in addSlot

* Several statements on the same line (e.g. debug (signal) { ...
}), some long enough that even github doesn't get to display
without scrolling.

* Some signed integers should be unsigned

* (Minor) redundant control flow and duplicated code in
wasConstructedFrom

* Odd whitespace in line 819

* Line 917: should that be an enforce?

* At least one more colloquialism ("Such dirty tricks...")

* Variables called "o", sigh.

Overall: I think the code is relatively easy to fix with one
careful pass, but the documentation needs a lot of work.


Andrei
Jan 14 2014
next sibling parent reply "qznc" <qznc web.de> writes:
On Wednesday, 15 January 2014 at 07:46:29 UTC, Andrei 
Alexandrescu wrote:
yada yada yada

I just created a wiki page to document requirements. Hopefully, 
this helps people to decide on their vote and not to forget 
aspects.

http://wiki.dlang.org/Phobos_Quality

Should this be linked from http://wiki.dlang.org/Review/Process ?
Jan 15 2014
next sibling parent "Dicebot" <public dicebot.lv> writes:
On Wednesday, 15 January 2014 at 15:59:20 UTC, qznc wrote:

 On Wednesday, 15 January 2014 at 07:46:29 UTC, Andrei 
 Alexandrescu wrote:
 yada yada yada

 I just created a wiki page to document requirements. Hopefully, 
 this helps people to decide on their vote and not to forget 
 aspects.

 http://wiki.dlang.org/Phobos_Quality

 Should this be linked from http://wiki.dlang.org/Review/Process 
 ?


Do it.
Jan 15 2014
prev sibling next sibling parent reply John J <john.joyus gmail.com> writes:
On 01/15/2014 10:59 AM, qznc wrote:

 On Wednesday, 15 January 2014 at 07:46:29 UTC, Andrei Alexandrescu wrote:
 yada yada yada

 I just created a wiki page to document requirements. Hopefully, this
 helps people to decide on their vote and not to forget aspects.

 http://wiki.dlang.org/Phobos_Quality

 Should this be linked from http://wiki.dlang.org/Review/Process ?



"Uses complete english sentences with correct syntax, grammar, and 
punctuation."

Please capitalize the e in english.
Jan 15 2014
next sibling parent reply Russel Winder <russel winder.org.uk> writes:
On Wed, 2014-01-15 at 13:42 -0500, John J wrote:
[…]

 "Uses complete english sentences with correct syntax, grammar, and 
 punctuation."
 
 Please capitalize the e in english.


We can, of course, now open the debate as to whether the Oxford Comma
should be used. ;-)

And does English mean American English, Canadian English, Australian
English, South African English, New Zealand English, or proper English,
i.e. that spoken in England. :-)

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.net
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
Jan 15 2014
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/15/14 11:35 AM, Russel Winder wrote:

 On Wed, 2014-01-15 at 13:42 -0500, John J wrote:
 […]

 "Uses complete english sentences with correct syntax, grammar, and
 punctuation."

 Please capitalize the e in english.


 We can, of course, now open the debate as to whether the Oxford Comma
 should be used. ;-)


At ACCU I attended talks by you, an awful speaker, and an incompetent 
chowderhead.

Now you tell me whether we should use the Oxford comma or not :o).


 And does English mean American English, Canadian English, Australian
 English, South African English, New Zealand English, or proper English,
 i.e. that spoken in England. :-)


We can always aspire...


Andrei
Jan 16 2014
prev sibling next sibling parent reply Rory McGuire <rjmcguire gmail.com> writes:
On Wed, Jan 15, 2014 at 9:35 PM, Russel Winder <russel winder.org.uk> wrote:

 We can, of course, now open the debate as to whether the Oxford Comma
 should be used. ;-)

 And does English mean American English, Canadian English, Australian
 English, South African English, New Zealand English, or proper English,
 i.e. that spoken in England. :-)

 --
 Russel.

 =============================================================================
 Dr Russel Winder      t: +44 20 7585 2200   voip:
 sip:russel.winder ekiga.net
 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


I vote: British English sentence construction with either American English
or British English spelling.
People are welcome to "fix" the documentation if the original writer's
English is not 100% :) or if they just prefer the spelling to be from one
of the other versions of English.

Disclaimer: I speak South African English.

P.S. I think Programming English is pretty much American English. For
example is there any API that contains the English word Colour?
Jan 16 2014
parent =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig+dforum outerproduct.org> writes:
Am 16.01.2014 09:42, schrieb Rory McGuire:

 P.S. I think Programming English is pretty much American English. For
 example is there any API that contains the English word Colour?


wxWidgets has one, but I think there was/is an additional alias with the 
American spelling.

http://docs.wxwidgets.org/trunk/classwx_colour.html

;)
Jan 21 2014
prev sibling parent reply Russel Winder <russel winder.org.uk> writes:
On Thu, 2014-01-16 at 10:42 +0200, Rory McGuire wrote:
[…]

 I vote: British English sentence construction with either American English
 or British English spelling.


Could always get the best of both worlds and avoid spelling bikeshedding
by using OED preferred.

[…]

 P.S. I think Programming English is pretty much American English. For
 example is there any API that contains the English word Colour?


Interestingly, or not, USA English spelling is predominently 17th
century English English. UK English was "re-Frenchified" in the early
18th century when all the us were added. So one could say that Color is
old-fashioned spelling and Colour is more modern spelling. With the
corollary that Americans haven't updated their dictionaries properly
since 1800 :-)

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.net
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
Jan 16 2014
parent "Dicebot" <public dicebot.lv> writes:
Thanks for helping to keep voting threads clean from off-topic 
discussions.
Jan 16 2014
prev sibling parent reply "ilya-stromberg" <ilya-stromberg-2009 yandex.ru> writes:
On Wednesday, 15 January 2014 at 15:59:20 UTC, qznc wrote:

 On Wednesday, 15 January 2014 at 07:46:29 UTC, Andrei 
 Alexandrescu wrote:
 yada yada yada

 I just created a wiki page to document requirements. Hopefully, 
 this helps people to decide on their vote and not to forget 
 aspects.

 http://wiki.dlang.org/Phobos_Quality

 Should this be linked from http://wiki.dlang.org/Review/Process 
 ?


It will be great if we will have a list of English-speaking 
people that can help with documentation. For example, English is 
not my native language, so it will be great if somebody else read 
and correct my documentation.

So, we need a list of people who interested to help with 
documentation for new modules with their contact information 
(e-mail should be enough).
Jan 16 2014
parent "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Thursday, 16 January 2014 at 09:26:04 UTC, ilya-stromberg 
wrote:

 On Wednesday, 15 January 2014 at 15:59:20 UTC, qznc wrote:

 On Wednesday, 15 January 2014 at 07:46:29 UTC, Andrei 
 Alexandrescu wrote:
 yada yada yada

 I just created a wiki page to document requirements. 
 Hopefully, this helps people to decide on their vote and not 
 to forget aspects.

 http://wiki.dlang.org/Phobos_Quality

 Should this be linked from 
 http://wiki.dlang.org/Review/Process ?


 It will be great if we will have a list of English-speaking 
 people that can help with documentation. For example, English 
 is not my native language, so it will be great if somebody else 
 read and correct my documentation.

 So, we need a list of people who interested to help with 
 documentation for new modules with their contact information 
 (e-mail should be enough).


They can just post in dm.D with a link to the code. People are 
available at different times, and might be more or less 
interested depending on the nature of the library/module.
Jan 16 2014
prev sibling parent "robert" <jfanatiker gmx.at> writes:
 I am opposed to merging std.signal in its current form. It is 
 not
 at the level of documentation and implementation quality needed
 for new Phobos modules.

 * Documentation has numerous mistakes, omissions, disfluencies,
 and colloquialisms that seriously decrease credibility of the
 library. Examples:


Thanks a lot, for this thorough feedback, I really appreciate it!

Best regards,

Robert
Jan 15 2014
prev sibling next sibling parent Denis Shelomovskij <verylonglogin.reg gmail.com> writes:
06.01.2014 13:11, Dicebot пишет:

 Some time ago there have been a review for `std.signal` Phobos proposal
 (http://forum.dlang.org/thread/ujlhznaphepibgtpcoqz forum.dlang.org#post-ujlhznaphepibgtpcoqz:40forum.dlang.org).
 It have not received much feedback and I was a it too busy to proceed
 with final voting at that moment but with no outstanding issues to
 address nothing prevents that final step.

 Let's put 2 week deadline to refresh memories about the proposal and
 make some decision. Voting closes at January 20th 23:59 GMT 0

 Please take some time and help make Phobos better ;)


No.

Any signals implementation is at least blocked by the fact closure 
delegates lifetime can't be determined (see issues [2] and [3]). 
Requirement to explicitly pass owning object is redundant and 
unacceptable, such code must work:
---
/// Usage: don't pass struct member function delegates as `del`.
void f(void delegate() del)
{
     obj.event.connect(del);
}
---
Yes, I still don't see an elegant way to fix the language for struct 
member function delegates, but for closures there is issue [1].

Another way to make things work is a runtime support for weak 
references, see druntime pull 639 discussion [4].

Also see this thread for more discussion about signals problems: [5].

[1] https://d.puremagic.com/issues/show_bug.cgi?id=9601
[2] https://d.puremagic.com/issues/show_bug.cgi?id=9602
[3] https://d.puremagic.com/issues/show_bug.cgi?id=9603
[4] https://github.com/D-Programming-Language/druntime/pull/639
[5] http://forum.dlang.org/thread/kkdkh3$sft$1 digitalmars.com

-- 
Денис В. Шеломовский
Denis V. Shelomovskij
Jan 15 2014
prev sibling next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Monday, 6 January 2014 at 09:11:09 UTC, Dicebot wrote:

 Some time ago there have been a review for `std.signal` Phobos 
 proposal 
 (http://forum.dlang.org/thread/ujlhznaphepibgtpcoqz forum.dlang.org#post-ujlhznaphepibgtpcoqz
40forum.dlang.org). 
 It have not received much feedback and I was a it too busy to 
 proceed with final voting at that moment but with no 
 outstanding issues to address nothing prevents that final step.

 Let's put 2 week deadline to refresh memories about the 
 proposal and make some decision. Voting closes at January 20th 
 23:59 GMT 0

 Please take some time and help make Phobos better ;)


Less than 10 hours are left.
Jan 20 2014
next sibling parent reply "Robert" <jfanatiker gmx.at> writes:
Thank you Dicebot for stepping up. Unfortunately the demand seems 
to be very, very low, so I believe we are going to stick with the 
old std.signals.

Thanks again!

Best regards,

Robert

On Monday, 20 January 2014 at 13:51:44 UTC, Dicebot wrote:

 On Monday, 6 January 2014 at 09:11:09 UTC, Dicebot wrote:

 Some time ago there have been a review for `std.signal` Phobos 
 proposal 
 (http://forum.dlang.org/thread/ujlhznaphepibgtpcoqz forum.dlang.org#post-ujlhznaphepibgtpcoqz
40forum.dlang.org). 
 It have not received much feedback and I was a it too busy to 
 proceed with final voting at that moment but with no 
 outstanding issues to address nothing prevents that final step.

 Let's put 2 week deadline to refresh memories about the 
 proposal and make some decision. Voting closes at January 20th 
 23:59 GMT 0

 Please take some time and help make Phobos better ;)


 Less than 10 hours are left.
Jan 20 2014
parent reply "Adam Wilson" <flyboynw gmail.com> writes:
On Mon, 20 Jan 2014 15:16:42 -0800, Robert <jfanatiker gmx.at> wrote:


 Thank you Dicebot for stepping up. Unfortunately the demand seems to be  
 very, very low, so I believe we are going to stick with the old  
 std.signals.

 Thanks again!

 Best regards,

 Robert


Which is a shame too. We could have definitely used this in Aurora... But  
I think Andrei's comments kind of nixed the discussion. :-S


 On Monday, 20 January 2014 at 13:51:44 UTC, Dicebot wrote:

 On Monday, 6 January 2014 at 09:11:09 UTC, Dicebot wrote:

 Some time ago there have been a review for `std.signal` Phobos  
 proposal  
 (http://forum.dlang.org/thread/ujlhznaphepibgtpcoqz forum.dlang.org#post-ujlhznaphepibgtpcoqz
40forum.dlang.org).  
 It have not received much feedback and I was a it too busy to proceed  
 with final voting at that moment but with no outstanding issues to  
 address nothing prevents that final step.

 Let's put 2 week deadline to refresh memories about the proposal and  
 make some decision. Voting closes at January 20th 23:59 GMT 0

 Please take some time and help make Phobos better ;)


 Less than 10 hours are left.





-- 
Adam Wilson
GitHub/IRC: LightBender
Aurora Project Coordinator
Jan 20 2014
parent reply Xavier Bigand <flamaros.xavier gmail.com> writes:
Le 21/01/2014 00:51, Adam Wilson a crit :

 On Mon, 20 Jan 2014 15:16:42 -0800, Robert <jfanatiker gmx.at> wrote:


 Thank you Dicebot for stepping up. Unfortunately the demand seems to
 be very, very low, so I believe we are going to stick with the old
 std.signals.

 Thanks again!

 Best regards,

 Robert


 Which is a shame too. We could have definitely used this in Aurora...
 But I think Andrei's comments kind of nixed the discussion. :-S


 On Monday, 20 January 2014 at 13:51:44 UTC, Dicebot wrote:

 On Monday, 6 January 2014 at 09:11:09 UTC, Dicebot wrote:

 Some time ago there have been a review for `std.signal` Phobos
 proposal
 (http://forum.dlang.org/thread/ujlhznaphepibgtpcoqz forum.dlang.org#post-ujlhznaphepibgtpcoqz:40forum.dlang.org).
 It have not received much feedback and I was a it too busy to
 proceed with final voting at that moment but with no outstanding
 issues to address nothing prevents that final step.

 Let's put 2 week deadline to refresh memories about the proposal and
 make some decision. Voting closes at January 20th 23:59 GMT 0

 Please take some time and help make Phobos better ;)


 Less than 10 hours are left.






We use std.signals on DQuick, signals are critical for a GUI system, but 
there is no advanced GUI library written completely in D for the moment. 
For the moment DQuick still have a long way to do before really needing 
something better.

Maybe a day having thread safe ones will be essential but not for the 
moment, we have so mush things to fix and so few time to do it...

Sadly I doubt about the benefit of testing new signals on DQuick at his 
current stage.

Please don't loose hope cause we read this forum, and seeing people 
working on such subjects help us to save motivation.
Jan 21 2014
parent reply Jacob Carlborg <doob me.com> writes:
On 2014-01-21 21:10, Xavier Bigand wrote:


 We use std.signals on DQuick, signals are critical for a GUI system, but
 there is no advanced GUI library written completely in D for the moment.
 For the moment DQuick still have a long way to do before really needing
 something better.


What does the current std.signals offer that plain delegates don't?

-- 
/Jacob Carlborg
Jan 21 2014
parent Xavier Bigand <flamaros.xavier gmail.com> writes:
Le 22/01/2014 08:43, Jacob Carlborg a crit :

 On 2014-01-21 21:10, Xavier Bigand wrote:


 We use std.signals on DQuick, signals are critical for a GUI system, but
 there is no advanced GUI library written completely in D for the moment.
 For the moment DQuick still have a long way to do before really needing
 something better.


 What does the current std.signals offer that plain delegates don't?


It's easier to manipulate when you have many connections.
Jan 22 2014
prev sibling parent reply "David Nadlinger" <code klickverbot.at> writes:
On Monday, 20 January 2014 at 13:51:44 UTC, Dicebot wrote:

 Less than 10 hours are left.


I completely missed the review/voting, sorry, though mine would 
have been a "no" too, for the in my opinion inappropriate use of 
string mixins in the API. If you find yourself to be needing to 
stringify a passed in type for use in a string mixin, you are 
doing something wrong, as it is near impossible to make this work 
reliable. There are many other pitfalls than the one mentioned in 
the docs, e.g. with renamed imports, protection specifiers, …

I hope that this module will continue to be improved as a DUB 
package, though, because there certainly is interest in a solid 
implementation, even if signals are currently not really part of 
the "go-to D toolbox" for most people right now. Who knows what a 
later round of review might bring once the library has seen some 
more adoption in the wild.

David
Jan 20 2014
parent Martin Nowak <code dawg.eu> writes:
On 01/21/2014 02:48 AM, David Nadlinger wrote:

 I completely missed the review/voting, sorry, though mine would have
 been a "no" too, for the in my opinion inappropriate use of string
 mixins in the API. If you find yourself to be needing to stringify a
 passed in type for use in a string mixin, you are doing something wrong,
 as it is near impossible to make this work reliable. There are many
 other pitfalls than the one mentioned in the docs, e.g. with renamed
 imports, protection specifiers, …

 I hope that this module will continue to be improved as a DUB package,
 though, because there certainly is interest in a solid implementation,
 even if signals are currently not really part of the "go-to D toolbox"
 for most people right now. Who knows what a later round of review might
 bring once the library has seen some more adoption in the wild.

 David


I strongly agree with this opinion.
Please note that it's not the lack of interest but the lack of time 
which prevented me from participating in this review.

-Martin
Jan 23 2014
prev sibling parent reply "Dicebot" <public dicebot.lv> writes:
Quoting http://wiki.dlang.org/Review/std.signal :

==============================

=== Stats ===

==== Yes ====
* ilya-stromberg
* Damian Day
* Robert M. Münch

==== No ====
* Jakob Ovrum
* Andrei Alexandrescu *
* Denis Shelomovskij

People marked with asterisk belong to this list : 
https://github.com/D-Programming-Language?tab=members

=== Summary ===

     Total    : 6
     Yes      : 3
     Yes, If  : 0
     No       : 3

     Among D developers : 0/0/1

=== Verdict ===

Rejected in its current implementation

=== Review manager comment ===

Apart from some implementation / documentation issues mentioned 
by reviewers important concern is general lack of interest in 
such module. It looks too niche to get amount of attention needed 
for detailed reviewing and this will remain concern even if all 
issues will be addressed. One possible recommendation is to keep 
module as separate dub package in Phobos candidate category so 
that it can't be easily discovered by those seeking sinal 
implementation and go for another review once it gets some user 
base to back it.

==============================

As an additional comment I wonder if existing signal module 
should be deprecated and removed completely from Phobos even 
desite lack of replacement. It sits in the very same niche as 
this proposal and has even worse implementation with plenty of 
reported bugs. It becomes hard to justify it at this point.
Jan 21 2014
next sibling parent "Dicebot" <public dicebot.lv> writes:
P.S. I really recommend to stop naming relevant dub package 
`phobosx` and give it own name. You only harm its discoverability 
that way and spread confusion about its official state.
Jan 21 2014
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2014-01-21 10:26, Dicebot wrote:


 It sits in the very same niche as this proposal and has
 even worse implementation with plenty of reported bugs.


If it has plenty of reported bugs someone is/was using it ;)

-- 
/Jacob Carlborg
Jan 21 2014
parent reply "Dicebot" <public dicebot.lv> writes:
On Tuesday, 21 January 2014 at 16:51:08 UTC, Jacob Carlborg wrote:

 On 2014-01-21 10:26, Dicebot wrote:


 It sits in the very same niche as this proposal and has
 even worse implementation with plenty of reported bugs.


 If it has plenty of reported bugs someone is/was using it ;)


Or tried to use it and ran away thinking that Phobos quality just 
laughable. Or wrote a replacement for it which did not pass the 
review ;)
Jan 21 2014
parent Jacob Carlborg <doob me.com> writes:
On 2014-01-21 18:48, Dicebot wrote:


 Or tried to use it and ran away thinking that Phobos quality just
 laughable. Or wrote a replacement for it which did not pass the review ;)


At least they filed a bug report.

-- 
/Jacob Carlborg
Jan 21 2014
prev sibling next sibling parent reply "Dejan Lekic" <dejan.lekic gmail.com> writes:
The new std.signal is IMHO far better than the old one. Why not
simply replace it, and then look forward to future improvements?
Jan 22 2014
next sibling parent reply "ilya-stromberg" <ilya-stromberg-2009 yandex.ru> writes:
On Wednesday, 22 January 2014 at 14:18:15 UTC, Dejan Lekic wrote:

 The new std.signal is IMHO far better than the old one. Why not
 simply replace it, and then look forward to future improvements?


Guys, were are you was a few days ago when voting still was open?!

Dicebot, can we continue voting at least 1-2 weeks? It looks like 
we finally have interest to the `std.signal` module.
Jan 22 2014
next sibling parent Daniel =?ISO-8859-1?Q?Koz=E1k?= <kozzi11 gmail.com> writes:
ilya-stromberg píše v St 22. 01. 2014 v 14:38 +0000:

 On Wednesday, 22 January 2014 at 14:18:15 UTC, Dejan Lekic wrote:

 The new std.signal is IMHO far better than the old one. Why not
 simply replace it, and then look forward to future improvements?


 
 Guys, were are you was a few days ago when voting still was open?!
 
 Dicebot, can we continue voting at least 1-2 weeks? It looks like 
 we finally have interest to the `std.signal` module.


+1
Jan 22 2014
prev sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Wednesday, 22 January 2014 at 14:38:48 UTC, ilya-stromberg 
wrote:

 On Wednesday, 22 January 2014 at 14:18:15 UTC, Dejan Lekic 
 wrote:

 The new std.signal is IMHO far better than the old one. Why not
 simply replace it, and then look forward to future 
 improvements?


 Guys, were are you was a few days ago when voting still was 
 open?!

 Dicebot, can we continue voting at least 1-2 weeks? It looks 
 like we finally have interest to the `std.signal` module.


No. I am not adjusting procedure post-factum and when evaluating 
actual results single "No" vote from Phobos core team (Andrei) 
outweights few extra "Yes" votes anyway.

We can schedule another review / voting relatively soon though, 
assuming Robert is still willing to push for it.
Jan 22 2014
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/22/14 6:57 AM, Dicebot wrote:

 We can schedule another review / voting relatively soon though, assuming
 Robert is still willing to push for it.


That would be great, and thanks Robert for being so gracious about it all.

Going forward the best way to improve Phobos is to ratchet quality by 
keeping a high standard. I do understand that can be frustrating since 
there's stuff _in there_ that is worse off than what's proposed.


Andrei
Jan 22 2014
prev sibling parent "robert" <jfanatiker gmx.at> writes:
 We can schedule another review / voting relatively soon though, 
 assuming Robert is still willing to push for it.


Well, I am definitely motivated now that there is some reaction. 
Although my wife is currently giving birth, so can't really 
estimate how soon I will get to it, but then I will definitely 
incorporate the review comments I agree with. There are some I 
don't agree with or which are not totally clear, I am going to 
summarize them in a new thread. I hope the people raising them 
will still be around then.

Best regards,

Robert
Jan 22 2014
prev sibling parent reply Johannes Pfau <nospam example.com> writes:
Am Wed, 22 Jan 2014 14:18:14 +0000
schrieb "Dejan Lekic" <dejan.lekic gmail.com>:


 The new std.signal is IMHO far better than the old one. Why not
 simply replace it, and then look forward to future improvements?


Phobos has a very strict "don't break backwards compatibility rule".
IMHO too strict, but that's the way it is.

This also means we can't add code if we already know it will have to be
modified in not backwards compatible ways in the future.

Also the Phobos quality standards must apply to new modules, otherwise
those standards are useless. Modules older than these rules and the
review process (signals, xml) are (unfortunately) special and I'd just
remove those completely, but there can't be any exceptions for new
modules.

(Thinking of documentation here for example. It's not a problem if a
module doesn't pass the review on the first time btw. Just fix the
problems and add it to the review queue again)
Jan 22 2014
parent reply "David Nadlinger" <code klickverbot.at> writes:
On Wednesday, 22 January 2014 at 15:44:07 UTC, Johannes Pfau 
wrote:

 Phobos has a very strict "don't break backwards compatibility 
 rule".
 IMHO too strict, but that's the way it is.


This is also the reason why I would have voted "no" if I made it 
in time. Documentation and implementation can be fixed later, but 
we would have had to support a borderline-broken API (with 
regards to type stringification) for the foreseeable future.

David
Jan 22 2014
parent "ilya-stromberg" <ilya-stromberg-2009 yandex.ru> writes:
On Wednesday, 22 January 2014 at 23:19:08 UTC, David Nadlinger 
wrote:

 This is also the reason why I would have voted "no" if I made 
 it in time. Documentation and implementation can be fixed 
 later, but we would have had to support a borderline-broken API 
 (with regards to type stringification) for the foreseeable 
 future.


The main problem with `std.signal` API is private signals. I 
think it's important feature, but Robert created additional 
struct `Signal`, enum `Protection` and string mixin `signal` to 
implement it.

It's only 2 possible solutions: remove private signals or 
implement new D feature like `friend` keyword.

What can we do? Will we create DIP or bugzilla issue? Andrei, 
what do you think about it?
Jan 23 2014
prev sibling parent "Kagamin" <spam here.lot> writes:
On Tuesday, 21 January 2014 at 09:26:14 UTC, Dicebot wrote:

 As an additional comment I wonder if existing signal module 
 should be deprecated and removed completely from Phobos even 
 desite lack of replacement. It sits in the very same niche as 
 this proposal and has even worse implementation with plenty of 
 reported bugs. It becomes hard to justify it at this point.


One possibility is a warning about issues and link to the dub 
package in the docs for std.signal with a hint, that it may be a 
better choise. Probably same for std.xml. Do we have a package 
with better xml?
Jan 23 2014