digitalmars.D.announce - Last - but not least! - two DConf talks
- Andrei Alexandrescu (4/4) Jul 10 2015 Spread the word!
- cym13 (6/10) Jul 10 2015 Erich's presentation is now my favourite one from this year's
- Atila Neves (5/9) Jul 13 2015 https://www.reddit.com/r/programming/comments/3d3ooa/behaviourdriven_dev...
- Brad Anderson (6/17) Jul 14 2015 Very cool techniques you've done there. I think you may have
- Atila Neves (4/24) Jul 15 2015 Cucumber even gives you the regexes after you write the feature.
- Jacob Carlborg (36/39) Jul 15 2015 Really great talk.
- Jacob Carlborg (19/21) Jul 15 2015 The comment about not having to name the steps. One way to do that could...
- "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> (10/32) Jul 16 2015 Do mixin templates work on module level? They can even have an
- Jacob Carlborg (10/17) Jul 16 2015 Yes. But a mixin template seems only be able to contain declarations.
- "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> (12/32) Jul 17 2015 I guess we could even live with that. If someone wants the latter
- Jacob Carlborg (20/27) Jul 17 2015 Currently, in the above example, "element" is interpreted as an argument...
- "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> (5/16) Jul 17 2015 That could only happen after semantic analysis, but the ambiguity
- Jacob Carlborg (9/13) Jul 17 2015 Aren't there other things in D that already have this problem:
- "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> (7/15) Jul 18 2015 The AST for this statement would look something like:
- Jacob Carlborg (36/41) Jul 18 2015 I think there are nine different ways a user could want write the code
- Atila Neves (4/28) Jul 16 2015 Yes. But it doesn't make it pretty to use:
- Atila Neves (7/29) Jul 16 2015 I tried out something like this to see how I'd like it before the
- Jacob Carlborg (4/9) Jul 17 2015 Yeah, that looks quite weird.
- Jack Stouffer (3/4) Jul 13 2015 https://www.reddit.com/r/programming/comments/3d66zk/why_i_love_d_an_und...
Spread the word! https://www.youtube.com/watch?v=bxSPCmwqgYs https://www.youtube.com/watch?v=jNQF3m5e2l0 Andrei
Jul 10 2015
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 AndreiErich'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
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 Andreihttps://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
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: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.Spread the word! https://www.youtube.com/watch?v=bxSPCmwqgYs https://www.youtube.com/watch?v=jNQF3m5e2l0 Andreihttps://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 14 2015
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: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. AtilaOn Friday, 10 July 2015 at 18:33:04 UTC, Andrei Alexandrescu wrote: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.Spread the word! https://www.youtube.com/watch?v=bxSPCmwqgYs https://www.youtube.com/watch?v=jNQF3m5e2l0 Andreihttps://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 15 2015
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. AtilaReally 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
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
On Wednesday, 15 July 2015 at 19:28:13 UTC, Jacob Carlborg wrote:On 2015-07-13 09:12, Atila Neves wrote:Do mixin templates work on module level? They can even have an identifier.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.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
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
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:As Atila posted.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?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?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)
Jul 17 2015
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
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
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
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: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...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?
Jul 18 2015
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
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:Yes. But it doesn't make it pretty to use: mixin When!(`...`, { }); AtilaOn 2015-07-13 09:12, Atila Neves wrote:Do mixin templates work on module level? They can even have an identifier.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.
Jul 16 2015
On Wednesday, 15 July 2015 at 19:28:13 UTC, Jacob Carlborg wrote:On 2015-07-13 09:12, 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. Atilahttps://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.
Jul 16 2015
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
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