Re: Unencumbered V0.1.2: Write Cucumber step definitions in D
On Thursday, 24 April 2014 at 14:10:07 UTC, Jacob Carlborg wrote: On 24/04/14 09:19, Atila Neves wrote: I did, yeah, that's why I asked that question recently about calling D from Ruby. Right, that was you. I also thought of using Thrift and played about with it but in the end decided that the simplest option is to just use the wire protocol. It even reports back D exception information back, so the only real thing I can see that's missing is the snippet suggestions when the steps aren't defined yet. If Ruby is embedded Cucumber could be embedded as well, perhaps. Then you could get an executable without dependencies. Or I could carry on implementing all the Cucumber features and end up with an executable that does everything the Ruby version does. I'm happy with what I've got now though, but the embedding thing is interesting. I just decided that embedding was too much work. Atila
Re: Unencumbered V0.1.2: Write Cucumber step definitions in D
On Thursday, 24 April 2014 at 18:55:20 UTC, Jacob Carlborg wrote: On 2014-04-23 15:24, Atila Neves wrote: Like testing with Cucumber? Wish you could call native D code with it? Now you can! http://code.dlang.org/packages/unencumbered https://github.com/atilaneves/unencumbered I especially like registering functions that take the parameters with the types they need from the regexp captures, as well as the compile-time failures that come from that if done incorrectly. Now I just need to use in real life. It would be very nice to have something like Aruba in D together with this. If you haven't heard of it it's basically a library making it easier to test CLI applications, often used together with Cucumber. I think it's used by Cucumber itself. Yeah, I know Aruba. Well, for all of about two weeks :) Why would you want Aruba in D, though? You can just use the Ruby version. Atila
Re: Unencumbered V0.1.2: Write Cucumber step definitions in D
On Thursday, 24 April 2014 at 18:53:22 UTC, Jacob Carlborg wrote: On 2014-04-23 15:24, Atila Neves wrote: Like testing with Cucumber? Wish you could call native D code with it? Now you can! http://code.dlang.org/packages/unencumbered https://github.com/atilaneves/unencumbered I especially like registering functions that take the parameters with the types they need from the regexp captures, as well as the compile-time failures that come from that if done incorrectly. Now I just need to use in real life. BTW, why is the description passed as a template argument to the Cucumber keywords. @Given!(foo) instead of @Given(foo)? Ehm... because until now I didn't know that @Given(foo) was possible. In my head I was doing compile-time stuff so everything had to be compile-time, if that makes any sense. After I read the above I wasn't even sure how @Given(foo) would work so I wrote some code and now know that all I need is a struct with a regular string field. I think the documenation on http://dlang.org/attribute.html is severely lacking. I think I have some refactoring to do now. Thanks for pointing this out! Atila
Re: Unencumbered V0.1.2: Write Cucumber step definitions in D
On Friday, 25 April 2014 at 08:45:20 UTC, Atila Neves wrote:
On Thursday, 24 April 2014 at 18:53:22 UTC, Jacob Carlborg
wrote:
On 2014-04-23 15:24, Atila Neves wrote:
Like testing with Cucumber? Wish you could call native D code
with it?
Now you can!
http://code.dlang.org/packages/unencumbered
https://github.com/atilaneves/unencumbered
I especially like registering functions that take the
parameters with
the types they need from the regexp captures, as well as the
compile-time failures that come from that if done incorrectly.
Now I just need to use in real life.
BTW, why is the description passed as a template argument to
the Cucumber keywords. @Given!(foo) instead of @Given(foo)?
Ehm... because until now I didn't know that @Given(foo) was
possible. In my head I was doing compile-time stuff so
everything had to be compile-time, if that makes any sense.
After I read the above I wasn't even sure how @Given(foo)
would work so I wrote some code and now know that all I need is
a struct with a regular string field. I think the documenation
on http://dlang.org/attribute.html is severely lacking.
I think I have some refactoring to do now. Thanks for pointing
this out!
Atila
Hmm. So for the string argument is fine, unfortunately I also
need to know the line number of the step definition, and that
doesn't work:
struct Given {
this(string s, ulong l = __LINE__) {
this.s = s;
this.l = l;
}
string s;
ulong l;
}
@Given(foobar)
auto func() pure nothrow @safe {
}
void main() {
foreach(attr; __traits(getAttributes, func)) {
pragma(msg, s is , __traits(getMember, attr, l));
}
}
I get:
s is attr_str.d(21): Error: variable attr cannot be read at
compile time
attr_str.d(21):while evaluating pragma(msg,
__traits(getMember, attr, l))
Re: Unencumbered V0.1.2: Write Cucumber step definitions in D
On Friday, 25 April 2014 at 08:52:18 UTC, Atila Neves wrote:
On Friday, 25 April 2014 at 08:45:20 UTC, Atila Neves wrote:
On Thursday, 24 April 2014 at 18:53:22 UTC, Jacob Carlborg
wrote:
On 2014-04-23 15:24, Atila Neves wrote:
Like testing with Cucumber? Wish you could call native D
code with it?
Now you can!
http://code.dlang.org/packages/unencumbered
https://github.com/atilaneves/unencumbered
I especially like registering functions that take the
parameters with
the types they need from the regexp captures, as well as the
compile-time failures that come from that if done
incorrectly.
Now I just need to use in real life.
BTW, why is the description passed as a template argument to
the Cucumber keywords. @Given!(foo) instead of
@Given(foo)?
Ehm... because until now I didn't know that @Given(foo) was
possible. In my head I was doing compile-time stuff so
everything had to be compile-time, if that makes any sense.
After I read the above I wasn't even sure how @Given(foo)
would work so I wrote some code and now know that all I need
is a struct with a regular string field. I think the
documenation on http://dlang.org/attribute.html is severely
lacking.
I think I have some refactoring to do now. Thanks for pointing
this out!
Atila
Hmm. So for the string argument is fine, unfortunately I also
need to know the line number of the step definition, and that
doesn't work:
struct Given {
this(string s, ulong l = __LINE__) {
this.s = s;
this.l = l;
}
string s;
ulong l;
}
@Given(foobar)
auto func() pure nothrow @safe {
}
void main() {
foreach(attr; __traits(getAttributes, func)) {
pragma(msg, s is , __traits(getMember, attr, l));
}
}
I get:
s is attr_str.d(21): Error: variable attr cannot be read at
compile time
attr_str.d(21):while evaluating pragma(msg,
__traits(getMember, attr, l))
struct Given {
this(ulong l = __LINE__)(string s) {
this.s = s;
this.l = l;
}
string s;
ulong l;
}
@Given(foobar)
auto func() pure nothrow @safe {
}
void main() {
pragma(msg, s is , getGivenL!func);
}
pure ulong getGivenL(alias symbol)() {
foreach(attr; __traits(getAttributes, func)) {
static if (is(typeof(attr) == Given)) {
return attr.l;
}
}
assert(0);
}
Basically move the checking of UDA's to specialist functions
that are reusable.
Also when using things like __LINE__ keep them to template args,
as they are inferred to the initiation if possible.
Re: Unencumbered V0.1.2: Write Cucumber step definitions in D
On Friday, 25 April 2014 at 09:45:06 UTC, Rikki Cattermole wrote: Also when using things like __LINE__ keep them to template args, as they are inferred to the initiation if possible. This is antipattern. Default function arguments for __LINE__ and __FILE__ are also evaluated at call site. Moving this to template parameter creates huge amount of template bloat and must be used only if there is no other way around (that usually implies variadic arguments)
Re: Unencumbered V0.1.2: Write Cucumber step definitions in D
On Friday, 25 April 2014 at 10:02:45 UTC, Dicebot wrote: On Friday, 25 April 2014 at 09:45:06 UTC, Rikki Cattermole wrote: Also when using things like __LINE__ keep them to template args, as they are inferred to the initiation if possible. This is antipattern. Default function arguments for __LINE__ and __FILE__ are also evaluated at call site. Moving this to template parameter creates huge amount of template bloat and must be used only if there is no other way around (that usually implies variadic arguments) True in this specific case it might be over the top.
[OT] Excelsior Jet standard edition virtually for free
For those who are interested in the Excelsior Jet AOT Java to native compiler http://www.excelsiorjet.com/charity Note: non-upgradable, no support
Re: Unencumbered V0.1.2: Write Cucumber step definitions in D
On Friday, 25 April 2014 at 10:20:47 UTC, Rikki Cattermole wrote: On Friday, 25 April 2014 at 10:02:45 UTC, Dicebot wrote: On Friday, 25 April 2014 at 09:45:06 UTC, Rikki Cattermole wrote: Also when using things like __LINE__ keep them to template args, as they are inferred to the initiation if possible. This is antipattern. Default function arguments for __LINE__ and __FILE__ are also evaluated at call site. Moving this to template parameter creates huge amount of template bloat and must be used only if there is no other way around (that usually implies variadic arguments) True in this specific case it might be over the top. It was a template parameter before anyway. Also, this is for acceptance/feature/integration testing, so I doubt anyone would care how much bloat it generates as long as it gets the job done. Is there any other way to achieve @Given(regexp) that also gets passed in the line number automatically without the template param? If so I'll glady use it, if not I think Rikki's solution seems to be the simplest so far. Atila
Re: Unencumbered V0.1.2: Write Cucumber step definitions in D
On Friday, 25 April 2014 at 11:11:18 UTC, Atila Neves wrote:
Is there any other way to achieve @Given(regexp) that also
gets passed in the line number automatically without the
template param? If so I'll glady use it, if not I think Rikki's
solution seems to be the simplest so far.
Atila
Just change struct constructor back to
this(string s, ulong l = __LINE__) {
in Riki's snippet
Re: Unencumbered V0.1.2: Write Cucumber step definitions in D
On Friday, 25 April 2014 at 11:11:18 UTC, Atila Neves wrote: On Friday, 25 April 2014 at 10:20:47 UTC, Rikki Cattermole wrote: On Friday, 25 April 2014 at 10:02:45 UTC, Dicebot wrote: On Friday, 25 April 2014 at 09:45:06 UTC, Rikki Cattermole wrote: Also when using things like __LINE__ keep them to template args, as they are inferred to the initiation if possible. This is antipattern. Default function arguments for __LINE__ and __FILE__ are also evaluated at call site. Moving this to template parameter creates huge amount of template bloat and must be used only if there is no other way around (that usually implies variadic arguments) True in this specific case it might be over the top. It was a template parameter before anyway. Also, this is for acceptance/feature/integration testing, so I doubt anyone would care how much bloat it generates as long as it gets the job done. It will hurt build-times, so it's worth avoiding.
Re: Unencumbered V0.1.2: Write Cucumber step definitions in D
On Friday, 25 April 2014 at 12:18:41 UTC, John Colvin wrote: On Friday, 25 April 2014 at 11:11:18 UTC, Atila Neves wrote: On Friday, 25 April 2014 at 10:20:47 UTC, Rikki Cattermole wrote: On Friday, 25 April 2014 at 10:02:45 UTC, Dicebot wrote: On Friday, 25 April 2014 at 09:45:06 UTC, Rikki Cattermole wrote: Also when using things like __LINE__ keep them to template args, as they are inferred to the initiation if possible. This is antipattern. Default function arguments for __LINE__ and __FILE__ are also evaluated at call site. Moving this to template parameter creates huge amount of template bloat and must be used only if there is no other way around (that usually implies variadic arguments) True in this specific case it might be over the top. It was a template parameter before anyway. Also, this is for acceptance/feature/integration testing, so I doubt anyone would care how much bloat it generates as long as it gets the job done. It will hurt build-times, so it's worth avoiding. Normally I'd agree. But it'll take longer to run the server and the tests themselves than it'll take to build anyway, so it really doesn't matter that much. Now, if it were for _unit_ tests... hmm, speaking of which I should probably try and optimise that for unit-threaded. But that means profiling the compiler I guess. Atila
Re: Unencumbered V0.1.2: Write Cucumber step definitions in D
whilst bootstrapping the process and also for some tests I wrote for my MQTT broker. I think this should work but I can't try it right You have a MQTT broker? Free? Open-source? Can I haz teh code plx!
Re: Unencumbered V0.1.2: Write Cucumber step definitions in D
Am 25.04.2014 15:00, schrieb Dejan Lekic: whilst bootstrapping the process and also for some tests I wrote for my MQTT broker. I think this should work but I can't try it right You have a MQTT broker? Free? Open-source? Can I haz teh code plx! https://github.com/atilaneves/mqtt BTW, shouldn't it be registered on code.dlang.org?
Re: Unencumbered V0.1.2: Write Cucumber step definitions in D
On Friday, 25 April 2014 at 13:07:43 UTC, Sönke Ludwig wrote: Am 25.04.2014 15:00, schrieb Dejan Lekic: whilst bootstrapping the process and also for some tests I wrote for my MQTT broker. I think this should work but I can't try it right You have a MQTT broker? Free? Open-source? Can I haz teh code plx! https://github.com/atilaneves/mqtt BTW, shouldn't it be registered on code.dlang.org? I guess! Doing it now. Atila
Re: Unencumbered V0.1.2: Write Cucumber step definitions in D
On Friday, 25 April 2014 at 13:00:20 UTC, Dejan Lekic wrote: whilst bootstrapping the process and also for some tests I wrote for my MQTT broker. I think this should work but I can't try it right You have a MQTT broker? Free? Open-source? Can I haz teh code plx! https://github.com/atilaneves/mqtt Only does QOS 0, doesn't do authentication, but it works. I wrote two blog posts about it and performance on http://atilanevesoncode.wordpress.com/. Atila
Re: [OT] Excelsior Jet standard edition virtually for free
On 4/25/14, Jos van Uden via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: For those who are interested in the Excelsior Jet AOT Java to native compiler http://www.excelsiorjet.com/charity Note: non-upgradable, no support If it's OT it does not belong to D.announce. Please stop spamming this Java stuff in the D newsgroups.
D Breaks on to the TIOBE Top 20 List.
I know we don't place much value in TIOBE and it's brethren. However, I thought that this was a milestone worthy of a note anyways. http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html -- Adam Wilson GitHub/IRC: LightBender Aurora Project Coordinator
Re: D Breaks on to the TIOBE Top 20 List.
On Friday, 25 April 2014 at 19:51:22 UTC, Adam Wilson wrote: I know we don't place much value in TIOBE and it's brethren. However, I thought that this was a milestone worthy of a note anyways. http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html Well, in fact last month D was 17th on Tiobe, and was in since November or December I think ... and now D is 20th but for a weird reason it is still ranked as gaining popularity. And let's talk about numbers : March 0.744% April 0.708% Change : +0.39 I just don't understand how they make their calculations.
Re: D Breaks on to the TIOBE Top 20 List.
On Friday, 25 April 2014 at 19:51:22 UTC, Adam Wilson wrote: I know we don't place much value in TIOBE What do you mean, we're in the top 20! Now's the time to put value in TIOBE :)
Re: D Breaks on to the TIOBE Top 20 List.
On Friday, 25 April 2014 at 20:22:32 UTC, Théo Bueno wrote: I just don't understand how they make their calculations. http://www.tiobe.com/index.php/content/paperinfo/tpci/tpci_definition.htm Apparently they use: +D programming -3-D programming -DTrace ? They claim 90% confidence, but I think that is misleading.
