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?

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

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

On Friday, 25 April 2014 at 08:45:20 UTC, Atila Neves wrote:

> 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.

What do you mean, it's right there, at the bottom of the first example [1]:

@Bar(3) int d;

[1] http://dlang.org/attribute.html#UserDefinedAttribute

--
/Jacob Carlborg

On Friday, 25 April 2014 at 08:45:20 UTC, Atila Neves wrote:

> 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.

BTW, I think it's possible to use a plain function as well, which returns a struct. In this case, "Given" would be the function.

--
/Jacob Carlborg

On 2014-04-25 10:31, Atila Neves wrote:

> 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.

I see.

A pure D implementation would be even better.

-- 
/Jacob Carlborg

On 2014-04-25 10:32, Atila Neves wrote:

> 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.

Sure I can, I already does this. I would be quite nice with mostly pure D tools. People have been almost hostile in my attempts to use D together with Ruby. I was building a package manager that use Ruby for writing the package description files. That was far from popular.

Oh, then why are you adding support for D to Cucumber ;)

-- 
/Jacob Carlborg

On Saturday, 26 April 2014 at 07:51:45 UTC, Jacob Carlborg wrote:
> On Friday, 25 April 2014 at 08:45:20 UTC, Atila Neves wrote:
>
>> 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.
>
> What do you mean, it's right there, at the bottom of the first example [1]:
>
> @Bar(3) int d;
>
> [1] http://dlang.org/attribute.html#UserDefinedAttribute
>
> --
> /Jacob Carlborg

Oh. Oops.

Atila

On Saturday, 26 April 2014 at 09:36:30 UTC, Jacob Carlborg wrote:
> On 2014-04-25 10:31, Atila Neves wrote:
>
>> 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.
>
> I see.
>
> A pure D implementation would be even better.

I thought of that, but decided it wasn't worth the bother. The Ruby version already exists, is familiar to pretty much anyone who's used or heard of Cucumber, and works.
To me a pure D implementation would be cool in and of itself, but personally wouldn't be that much better or useful as using the wire protocol.

Atila

On Saturday, 26 April 2014 at 09:40:14 UTC, Jacob Carlborg wrote:
> On 2014-04-25 10:32, Atila Neves wrote:
>
>> 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.
>
> Sure I can, I already does this. I would be quite nice with mostly pure D tools. People have been almost hostile in my attempts to use D together with Ruby. I was building a package manager that use Ruby for writing the package description files. That was far from popular.
>
> Oh, then why are you adding support for D to Cucumber ;)

Ah, well, so I can easily have Cucumber steps to call D code that has side-effects. Anything else I unit test.

I can even test some of my D code without this project. In the MQTT case I just implemented the step definitions in Ruby, opened a socket and sent in binary data. But it'd be handy to call D code as well, hence the project.

Actually I started writing this so I could learn BDD with Cucumber on a D project. Little did I know that Cucumber uses itself to specify behaviour, which meant I learned BDD with Cucumber as I was doing a project to learn BDD with Cucumber! So meta.

Atila