www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Last - but not least! - two DConf talks

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Spread the word!

https://www.youtube.com/watch?v=bxSPCmwqgYs
https://www.youtube.com/watch?v=jNQF3m5e2l0

Andrei
Jul 10 2015
next sibling parent "cym13" <cpicard openmailbox.org> writes:
On Friday, 10 July 2015 at 18:33:04 UTC, Andrei Alexandrescu 
wrote:
 Spread the word!

 https://www.youtube.com/watch?v=bxSPCmwqgYs
 https://www.youtube.com/watch?v=jNQF3m5e2l0

 Andrei
Erich's presentation is now my favourite one from this year's DConf. If you read this Erich, I really love your energy! Such nice display is, to me, as important as more technical presentations of D as they touch different people. Thank you!
Jul 10 2015
prev sibling next sibling parent reply "Atila Neves" <atila.neves gmail.com> writes:
On Friday, 10 July 2015 at 18:33:04 UTC, Andrei Alexandrescu 
wrote:
 Spread the word!

 https://www.youtube.com/watch?v=bxSPCmwqgYs
 https://www.youtube.com/watch?v=jNQF3m5e2l0

 Andrei
https://www.reddit.com/r/programming/comments/3d3ooa/behaviourdriven_development_with_d_and_cucumber/ Also on HN, but as usual can't post the link. Atila
Jul 13 2015
next sibling parent reply "Brad Anderson" <eco gnuk.net> writes:
On Monday, 13 July 2015 at 07:12:48 UTC, Atila Neves wrote:
 On Friday, 10 July 2015 at 18:33:04 UTC, Andrei Alexandrescu 
 wrote:
 Spread the word!

 https://www.youtube.com/watch?v=bxSPCmwqgYs
 https://www.youtube.com/watch?v=jNQF3m5e2l0

 Andrei
https://www.reddit.com/r/programming/comments/3d3ooa/behaviourdriven_development_with_d_and_cucumber/ Also on HN, but as usual can't post the link. Atila
Very cool techniques you've done there. I think you may have convinced me that Cucumber might be worth trying out. It does seem like you have to spend a lot of effort doing the plumbing to get it working (all the regexes) so I'm not completely sold but you've made it sound compelling enough to give it a whirl.
Jul 14 2015
parent "Atila Neves" <atila.neves gmail.com> writes:
On Tuesday, 14 July 2015 at 20:18:40 UTC, Brad Anderson wrote:
 On Monday, 13 July 2015 at 07:12:48 UTC, Atila Neves wrote:
 On Friday, 10 July 2015 at 18:33:04 UTC, Andrei Alexandrescu 
 wrote:
 Spread the word!

 https://www.youtube.com/watch?v=bxSPCmwqgYs
 https://www.youtube.com/watch?v=jNQF3m5e2l0

 Andrei
https://www.reddit.com/r/programming/comments/3d3ooa/behaviourdriven_development_with_d_and_cucumber/ Also on HN, but as usual can't post the link. Atila
Very cool techniques you've done there. I think you may have convinced me that Cucumber might be worth trying out. It does seem like you have to spend a lot of effort doing the plumbing to get it working (all the regexes) so I'm not completely sold but you've made it sound compelling enough to give it a whirl.
Cucumber even gives you the regexes after you write the feature. All you have to do is write the code that should be run, really. Atila
Jul 15 2015
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2015-07-13 09:12, Atila Neves wrote:

 https://www.reddit.com/r/programming/comments/3d3ooa/behaviourdriven_development_with_d_and_cucumber/


 Also on HN, but as usual can't post the link.

 Atila
Really great talk. We're using Cucumber (or rather a similar tool called Turnip) a lot at work and I was using the standard version at my previous work. A couple of things I don't like with the standard Cucumber are: 1. Regular expressions used for defining steps. Using actual regular expression is seldom needed, most of the time only a string is needed. Turnip uses strings with variable support, that is, any word prefix with a colon will be assumed to be a variable and passed to the block as an argument. What can easily happen with regular expression is the steps become too generic and try to do too much. This can of course happen with strings as well but it's less likely because a string is more limited on what it can match. 2. All steps are global. If nothing has changed recently all steps are available for all features/scenarios. This becomes a problem when you have similar steps but with different implementation, or rather the data is different. Which easily happens when you have a lot of features files. What happened to us was that to be able to share data between the steps a global associative array was used. This also caused a lot more data to be present in the feature file than we would have liked. Like identifiers to find the data in the associative array. Everything had dependencies on everything else can became a big mess. We have solved this with a heavily modified version of Turnip. Turnip uses the Gherkin feature files but is using RSpec as the test runner. We have modified Turnip so each feature is mapped to a module/namespace, each scenario is mapped a nested module, which is then included in the anonymous class that RSpec creates. Each step is mapped to a method in that anonymous class. Now we were able to do two things, have steps that are local to a scenario, without causing any conflicts and share data between the steps using instance variables. This resulted a completely different thinking in how to write feature files and how to implement them. We were also able to remove a lot of unnecessary data from the feature files. -- /Jacob Carlborg
Jul 15 2015
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2015-07-13 09:12, Atila Neves wrote:

 https://www.reddit.com/r/programming/comments/3d3ooa/behaviourdriven_development_with_d_and_cucumber/


 Also on HN, but as usual can't post the link.
The comment about not having to name the steps. One way to do that could be something like this: step("foo bar", { // step implementation }); There are two problems with that: 1. D doesn't support module level code like this. Which could be solved by either using a unit test block, a module constructor or some other function the framework knows about to call. 2. That syntax is not as nice as in Ruby. It would be really nice if the following could be supported: step("foo bar") { // step implementation } A trailing delegate syntax, where the delegate is passed after the regular argument list. -- /Jacob Carlborg
Jul 15 2015
next sibling parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Wednesday, 15 July 2015 at 19:28:13 UTC, Jacob Carlborg wrote:
 On 2015-07-13 09:12, Atila Neves wrote:

 https://www.reddit.com/r/programming/comments/3d3ooa/behaviourdriven_development_with_d_and_cucumber/


 Also on HN, but as usual can't post the link.
The comment about not having to name the steps. One way to do that could be something like this: step("foo bar", { // step implementation }); There are two problems with that: 1. D doesn't support module level code like this. Which could be solved by either using a unit test block, a module constructor or some other function the framework knows about to call.
Do mixin templates work on module level? They can even have an identifier.
 2. That syntax is not as nice as in Ruby. It would be really 
 nice if the following could be supported:

 step("foo bar") {
     // step implementation
 }

 A trailing delegate syntax, where the delegate is passed after 
 the regular argument list.
Unfortunately there are syntactical ambiguities: step("foo bar") { } .foo(); Is that a call chain, or two statements, with the second one calling a function in the root scope? And I think there are other similar cases...
Jul 16 2015
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2015-07-16 10:26, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net>" 
wrote:

 Do mixin templates work on module level? They can even have an identifier.
Yes. But a mixin template seems only be able to contain declarations. How did you plan to use it?
 Unfortunately there are syntactical ambiguities:

      step("foo bar") {
      }
      .foo();

 Is that a call chain, or two statements, with the second one calling a
 function in the root scope? And I think there are other similar cases...
Hmm, right. I have simple implementation of this. With you're example I get this error message: function main.foo () is not callable using argument types (void function() safe) -- /Jacob Carlborg
Jul 16 2015
parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Thursday, 16 July 2015 at 08:59:43 UTC, Jacob Carlborg wrote:
 On 2015-07-16 10:26, "Marc =?UTF-8?B?U2Now7x0eiI=?= 
 <schuetzm gmx.net>" wrote:

 Do mixin templates work on module level? They can even have an 
 identifier.
Yes. But a mixin template seems only be able to contain declarations. How did you plan to use it?
As Atila posted.
 Unfortunately there are syntactical ambiguities:

      step("foo bar") {
      }
      .foo();

 Is that a call chain, or two statements, with the second one 
 calling a
 function in the root scope? And I think there are other 
 similar cases...
Hmm, right. I have simple implementation of this. With you're example I get this error message: function main.foo () is not callable using argument types (void function() safe)
I guess we could even live with that. If someone wants the latter interpretation (which is kind of infrequent), they could insert a semicolon. Does your implementation support parameterized lambdas? I can already see the next ambiguity: someRange.each (element) { writeln(element); } Do the parentheses belong to the lambda on the right or the function on the left?
Jul 17 2015
parent reply Jacob Carlborg <doob me.com> writes:
On 2015-07-17 10:16, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net>" 
wrote:

 Does your implementation support parameterized lambdas? I can already
 see the next ambiguity:

      someRange.each (element) {
          writeln(element);
      }

 Do the parentheses belong to the lambda on the right or the function on
 the left?
Currently, in the above example, "element" is interpreted as an argument to "each". No, the current implementation does not support parameters. It's a really simple modification in the parser. If we really want to support this feature more work could be put in to this and make it work. I would say that it should first try to interpret "element" as an argument to "each", if that doesn't work, try as a parameter for the delegate. Just going with the longest match, if that doesn't work try the next thing. This feature has come up before, one of the suggestions back then was to do allow this syntax: someRange.each(start; element) { writeln(element); } Everything after the semicolon would be interperted as parameters for the delegate. -- /Jacob Carlborg
Jul 17 2015
parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Friday, 17 July 2015 at 11:28:45 UTC, Jacob Carlborg wrote:
 I would say that it should first try to interpret "element" as 
 an argument to "each", if that doesn't work, try as a parameter 
 for the delegate. Just going with the longest match, if that 
 doesn't work try the next thing.
That could only happen after semantic analysis, but the ambiguity needs to be resolved during parsing.
 This feature has come up before, one of the suggestions back 
 then was to do allow this syntax:

 someRange.each(start; element) {
     writeln(element);
 }

 Everything after the semicolon would be interperted as 
 parameters for the delegate.
That could work. But it would require an ugly `.each(; element)` if `each` should be called without arguments...
Jul 17 2015
parent reply Jacob Carlborg <doob me.com> writes:
On 2015-07-17 15:00, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net>" 
wrote:

 That could only happen after semantic analysis, but the ambiguity needs
 to be resolved during parsing.
Aren't there other things in D that already have this problem: auto a = foo; Is "foo" a variable or a method?
 That could work. But it would require an ugly `.each(; element)` if
 `each` should be called without arguments...
That would not be required with the suggestion above. But that might not be feasible. -- /Jacob Carlborg
Jul 17 2015
parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Friday, 17 July 2015 at 18:58:04 UTC, Jacob Carlborg wrote:
 On 2015-07-17 15:00, "Marc =?UTF-8?B?U2Now7x0eiI=?= 
 <schuetzm gmx.net>" wrote:

 That could only happen after semantic analysis, but the 
 ambiguity needs
 to be resolved during parsing.
Aren't there other things in D that already have this problem: auto a = foo; Is "foo" a variable or a method?
The AST for this statement would look something like: (DeclStatement type=(Keyword "auto") name=(Identifier "a") value=(AssignExpression exp=(VariableOrParenlessCall var=(Identifier "foo")))) This would probably be considerably harder for trailing delegates...
Jul 18 2015
parent Jacob Carlborg <doob me.com> writes:
On 2015-07-18 11:43, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net>" 
wrote:

 The AST for this statement would look something like:

 (DeclStatement type=(Keyword "auto") name=(Identifier "a")
 value=(AssignExpression exp=(VariableOrParenlessCall var=(Identifier
 "foo"))))

 This would probably be considerably harder for trailing delegates...
I think there are nine different ways a user could want write the code to call a method with a trailing delegate. Only two of them are ambiguous. foo { } foo (a){ // ambiguous } foo (int a){ } foo(a) { // ambiguous } foo(a) (b){ } foo(a) (int b){ } foo() (){ } foo (){ } foo() { } When it is ambiguous the compiler can always parse it as trailing delegate and store that in a variable in the call expression. The semantic analyze will then disambiguate the call. That would be similar to how my current implementation works like: 1. If the current expression is a call expression or an identifier 2. If the current token is an opening curly brace, parse an expression 3.1 If the current expression is a call expression, push the expression from step 2 to its argument list 3.2 If the current expression is an identifier, replace that with a call expression, go to 3.1 This could be extended to store the delegate expression in a new variable in the call expression instead. -- /Jacob Carlborg
Jul 18 2015
prev sibling parent "Atila Neves" <atila.neves gmail.com> writes:
On Thursday, 16 July 2015 at 08:26:58 UTC, Marc Sch├╝tz wrote:
 On Wednesday, 15 July 2015 at 19:28:13 UTC, Jacob Carlborg 
 wrote:
 On 2015-07-13 09:12, Atila Neves wrote:

 https://www.reddit.com/r/programming/comments/3d3ooa/behaviourdriven_development_with_d_and_cucumber/


 Also on HN, but as usual can't post the link.
The comment about not having to name the steps. One way to do that could be something like this: step("foo bar", { // step implementation }); There are two problems with that: 1. D doesn't support module level code like this. Which could be solved by either using a unit test block, a module constructor or some other function the framework knows about to call.
Do mixin templates work on module level? They can even have an identifier.
Yes. But it doesn't make it pretty to use: mixin When!(`...`, { }); Atila
Jul 16 2015
prev sibling parent reply "Atila Neves" <atila.neves gmail.com> writes:
On Wednesday, 15 July 2015 at 19:28:13 UTC, Jacob Carlborg wrote:
 On 2015-07-13 09:12, Atila Neves wrote:

 https://www.reddit.com/r/programming/comments/3d3ooa/behaviourdriven_development_with_d_and_cucumber/


 Also on HN, but as usual can't post the link.
The comment about not having to name the steps. One way to do that could be something like this: step("foo bar", { // step implementation }); There are two problems with that: 1. D doesn't support module level code like this. Which could be solved by either using a unit test block, a module constructor or some other function the framework knows about to call. 2. That syntax is not as nice as in Ruby. It would be really nice if the following could be supported: step("foo bar") { // step implementation } A trailing delegate syntax, where the delegate is passed after the regular argument list.
I tried out something like this to see how I'd like it before the talk, and I didn't. I mentioned it but I should've drawn more attention to it, it'd look like this: When!(`...`, { ... }) {} The empty block needed at the end was just too ugly. Atila
Jul 16 2015
parent Jacob Carlborg <doob me.com> writes:
On 2015-07-16 13:55, Atila Neves wrote:

 I tried out something like this to see how I'd like it before the talk,
 and I didn't. I mentioned it but I should've drawn more attention to it,
 it'd look like this:

  When!(`...`, { ... }) {}

 The empty block needed at the end was just too ugly.
Yeah, that looks quite weird. -- /Jacob Carlborg
Jul 17 2015
prev sibling parent "Jack Stouffer" <jack jackstouffer.com> writes:
On Friday, 10 July 2015 at 18:33:04 UTC, Andrei Alexandrescu 
wrote:
 Spread the word!
https://www.reddit.com/r/programming/comments/3d66zk/why_i_love_d_an_undergrad_shares_his_experience/
Jul 13 2015