Re: std.signal : voting has begun
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
Re: std.signal : voting has begun
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.
Re: std.signal : voting has begun
Le 21/01/2014 00:51, Adam Wilson a écrit : On Mon, 20 Jan 2014 15:16:42 -0800, Robert jfanati...@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/ujlhznaphepibgtpc...@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.
Re: std.signal : voting has begun
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
Re: std.signal : voting has begun
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/ujlhznaphepibgtpc...@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.
Re: std.signal : voting has begun
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/ujlhznaphepibgtpc...@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.
Re: std.signal : voting has begun
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
Re: std.signal : voting has begun
On Wed, Jan 15, 2014 at 9:35 PM, Russel Winder rus...@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.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@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?
Re: std.signal : voting has begun
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).
Re: std.signal : voting has begun
Thanks for helping to keep voting threads clean from off-topic discussions.
Re: std.signal : voting has begun
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
Re: std.signal : voting has begun
06.01.2014 13:11, Dicebot пишет:
Some time ago there have been a review for `std.signal` Phobos proposal
(http://forum.dlang.org/thread/ujlhznaphepibgtpc...@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
Re: std.signal : voting has begun
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 ?
Re: std.signal : voting has begun
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
Re: std.signal : voting has begun
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.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: std.signal : voting has begun
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/ujlhznaphepibgtpc...@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
Re: std.signal : voting has begun
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.
Re: std.signal : voting has begun
On Monday, 13 January 2014 at 17:36:22 UTC, Robert M. Münch wrote: On 2014-01-13 13:50:09 +, 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.
Re: std.signal : voting has begun
On 2014-01-13 13:50:09 +, 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. Münch Saphirion AG http://www.saphirion.com smarter | better | faster
Re: std.signal : voting has begun
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/ujlhznaphepibgtpc...@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.
Re: std.signal : voting has begun
On 2014-01-06 09:11:07 +, Dicebot said: Some time ago there have been a review for `std.signal` Phobos proposal (http://forum.dlang.org/thread/ujlhznaphepibgtpc...@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. Münch Saphirion AG http://www.saphirion.com smarter | better | faster
Re: std.signal : voting has begun
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
std.signal : voting has begun
Some time ago there have been a review for `std.signal` Phobos proposal (http://forum.dlang.org/thread/ujlhznaphepibgtpc...@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 ;)
Re: std.signal : voting has begun
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/ujlhznaphepibgtpc...@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/ykwgtaysaaejyvjsq...@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.
Re: std.signal : voting has begun
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/ujlhznaphepibgtpc...@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.
