Re: std.experimental.testing PR review
On Wednesday, 22 July 2015 at 18:46:37 UTC, Jacob Carlborg wrote: On 2015-07-22 17:05, Atila Neves wrote: Bumpity bump? So, what you're trying to say is that it's time for a vote ;) Are you volunteering to be the review manager? ;) Atila
Re: std.experimental.testing PR review
On Monday, 20 July 2015 at 13:20:49 UTC, Atila Neves wrote: On Monday, 20 April 2015 at 13:28:30 UTC, Atila Neves wrote: Original library: http://code.dlang.org/packages/unit-threaded PR: https://github.com/D-Programming-Language/phobos/pull/3207 It's my first Phobos PR, I tried reading the wiki and doing what's required but bear with me if I've screwed up somehow. I wasn't sure whether or not to split the PR. In the end I just took the existing library, edited it a lot and got it ready for review. Unit test blocks can be named with @Name. They execute in parallel by default but that's only if the default runner is used. Atila Bump. Bumpity bump?
Re: std.experimental.testing PR review
On Monday, 20 April 2015 at 13:28:30 UTC, Atila Neves wrote: Original library: http://code.dlang.org/packages/unit-threaded PR: https://github.com/D-Programming-Language/phobos/pull/3207 It's my first Phobos PR, I tried reading the wiki and doing what's required but bear with me if I've screwed up somehow. I wasn't sure whether or not to split the PR. In the end I just took the existing library, edited it a lot and got it ready for review. Unit test blocks can be named with @Name. They execute in parallel by default but that's only if the default runner is used. Atila Looks solid. I'm, shamefully, not a heavy user of unit testing but it appears to have everything I typically use from Google Test (C++) and is much more friendly to use thanks to the reflection and attributes. What's a scenario where you'd want a hidden test?
Re: std.experimental.testing PR review
On 2015-07-22 17:05, Atila Neves wrote: Bumpity bump? So, what you're trying to say is that it's time for a vote ;) -- /Jacob Carlborg
Re: std.experimental.testing PR review
On Monday, 20 April 2015 at 13:28:30 UTC, Atila Neves wrote: Original library: http://code.dlang.org/packages/unit-threaded PR: https://github.com/D-Programming-Language/phobos/pull/3207 It's my first Phobos PR, I tried reading the wiki and doing what's required but bear with me if I've screwed up somehow. I wasn't sure whether or not to split the PR. In the end I just took the existing library, edited it a lot and got it ready for review. Unit test blocks can be named with @Name. They execute in parallel by default but that's only if the default runner is used. Atila Bump.
Re: std.experimental.testing PR review
On Saturday, 27 June 2015 at 16:44:49 UTC, Atila Neves wrote: Your UFCS abuse is my UFCS awesomeness. It doesn't _make_ you use UFCS though, nobody would stop you from writing `shouldEqual(timesTwo(2), 4)` instead, which I think is nearly as readable. Nearly because I prefer UFCS. The advantage of using a word like should is that it enables UFCS, which test doesn't. After that it's a question of code style preferences whether or not you use it. And disagreement about how idiomatic such style preferences should be is exactly the reason why I will vote no. Look at it this way : if this proposal will never get to Phobos, I won't lose anything. It does not have any really important utility I need in standard library. Main thing about this proposal is making certain testing style standard - and thus there is no practical reason to accept any compromises.
Re: std.experimental.testing PR review
On Friday, 26 June 2015 at 15:46:28 UTC, Dicebot wrote: On Friday, 26 June 2015 at 15:32:47 UTC, Jacob Carlborg wrote: On 26/06/15 15:32, Dicebot wrote: Just in case it wasn't clear : I will vote no on this proposal as long as it features longish readable names like shouldEquals. You would vote no because of this? Totally. Remember - this is effectively will make specific API a language standard which will propagate it to all sort of 3d party libraries. I find it unacceptably unreadable and verbose, to the point it will make working with those libraries considerably harder. I use `test!==(a. b)` which is: - short - robust (supports any binary operator D has) - straight to the point (it is about testing, not about what program should/must do) The fact that examples uncourage UFCS abuse makes it even worse. Something that looks like this: `2.timesTwo.shouldEqual(4)` .. gets immediately marked as garbage in my book. Your UFCS abuse is my UFCS awesomeness. It doesn't _make_ you use UFCS though, nobody would stop you from writing `shouldEqual(timesTwo(2), 4)` instead, which I think is nearly as readable. Nearly because I prefer UFCS. The advantage of using a word like should is that it enables UFCS, which test doesn't. After that it's a question of code style preferences whether or not you use it. Atila
Re: std.experimental.testing PR review
On Saturday, 27 June 2015 at 17:37:13 UTC, Dicebot wrote: On Saturday, 27 June 2015 at 16:44:49 UTC, Atila Neves wrote: [...] And disagreement about how idiomatic such style preferences should be is exactly the reason why I will vote no. Look at it this way : if this proposal will never get to Phobos, I won't lose anything. It does not have any really important utility I need in standard library. Main thing about this proposal is making certain testing style standard - and thus there is no practical reason to accept any compromises. I understand your point. _My_ point is that nobody has to use UFCS if they don't want to. In fact, plain asserts could be used too. Atila
Re: std.experimental.testing PR review
On 27/06/15 19:37, Dicebot wrote: Main thing about this proposal is making certain testing style standard - and thus there is no practical reason to accept any compromises. Great, lets settle with the should syntax. -- /Jacob Carlborg
Re: std.experimental.testing PR review
On 26/06/15 17:46, Dicebot wrote: Totally. Remember - this is effectively will make specific API a language standard which will propagate it to all sort of 3d party libraries. I don't mind :) I find it unacceptably unreadable and verbose, to the point it will make working with those libraries considerably harder. I use `test!==(a. b)` which is: - short - robust (supports any binary operator D has) - straight to the point (it is about testing, not about what program should/must do) I would say that using strings as template parameters for everything in D is really ugly and a sign of abuse. Soon all D code will be contained in a single string literal passed to some function. The fact that examples uncourage UFCS abuse makes it even worse. Something that looks like this: `2.timesTwo.shouldEqual(4)` .. gets immediately marked as garbage in my book. So what do you UFCS should be used for, only for arrays/ranges? There are also things like `shouldBeFalse` and `shouldBeTrue`. I couldn't imagine anyone seriously using names like that until I have examined that proposal. You need to try Ruby ;) -- /Jacob Carlborg
Re: std.experimental.testing PR review
On Saturday, 27 June 2015 at 20:42:52 UTC, Jacob Carlborg wrote: `2.timesTwo.shouldEqual(4)` .. gets immediately marked as garbage in my book. So what do you UFCS should be used for, only for arrays/ranges? I see two generally legit use cases for UFCS : range pipelines and user literals (`42.seconds`). The way it becomes (ab)used lately is one of major reasons I like the language now notably less than I did ~2 years ago.
Re: std.experimental.testing PR review
On Friday, 26 June 2015 at 15:32:47 UTC, Jacob Carlborg wrote: On 26/06/15 15:32, Dicebot wrote: Just in case it wasn't clear : I will vote no on this proposal as long as it features longish readable names like shouldEquals. You would vote no because of this? Totally. Remember - this is effectively will make specific API a language standard which will propagate it to all sort of 3d party libraries. I find it unacceptably unreadable and verbose, to the point it will make working with those libraries considerably harder. I use `test!==(a. b)` which is: - short - robust (supports any binary operator D has) - straight to the point (it is about testing, not about what program should/must do) The fact that examples uncourage UFCS abuse makes it even worse. Something that looks like this: `2.timesTwo.shouldEqual(4)` .. gets immediately marked as garbage in my book. There are also things like `shouldBeFalse` and `shouldBeTrue`. I couldn't imagine anyone seriously using names like that until I have examined that proposal.
Re: std.experimental.testing PR review
On 26-Jun-2015 17:30, Atila Neves wrote: On Friday, 26 June 2015 at 13:32:39 UTC, Dicebot wrote: Just in case it wasn't clear : I will vote no on this proposal as long as it features longish readable names like shouldEquals. You'd rather `should!==`? I'm not sure which I'd prefer; the thing is that so far you're the only one strongly against it. The only other thing I heard was a question at DConf on why it wasn't `assertEquals` instead. FWIW I totally prefer should!== to shouldEquals. -- Dmitry Olshansky
Re: std.experimental.testing PR review
On 26/06/15 15:32, Dicebot wrote: Just in case it wasn't clear : I will vote no on this proposal as long as it features longish readable names like shouldEquals. You would vote no because of this? -- /Jacob Carlborg
Re: std.experimental.testing PR review
On Friday, 26 June 2015 at 13:14:40 UTC, Adam D. Ruppe wrote:
Nothing jumps out at me as being especially bad. The posix
escape codes could also be Windows compatible by rewriting them
somehow, instead of building a string, make a struct message {
int color; string text; } or something that you pass to the
thread... but since that's an internal implementation detail
that isn't necessary to work, meh.
Yeah, I know. If I'm not mistaken you have a library for that but
I didn't want to introduce a dependency. Doing colour output on
Windows is just annoying so I left it.
If Phobos had something like that already though...
The docs in package.d could show more higher level examples
too, before I looked at the code, I didn't realize there was
more to it.
I'll see if I can whip some more up.
Atila
Re: std.experimental.testing PR review
On 6/26/15 7:30 AM, Atila Neves wrote: On Friday, 26 June 2015 at 13:32:39 UTC, Dicebot wrote: Just in case it wasn't clear : I will vote no on this proposal as long as it features longish readable names like shouldEquals. You'd rather `should!==`? I'm not sure which I'd prefer; the thing is that so far you're the only one strongly against it. The only other thing I heard was a question at DConf on why it wasn't `assertEquals` instead. Atila Let's paint this bikeshed! I tend to like must instead of should; it's a bit shorter and stronger. I tend to like dot-separated English for testing, e.g. throwRangeError.must.throw!RangeError; One advantage is that the dot after must (or should) can trigger code completion on IDEs. Finally, I wonder if it's possible to hijack operator overloading to support this: 2.timesTwo.must == 4;
Re: std.experimental.testing PR review
On Friday, 26 June 2015 at 13:32:39 UTC, Dicebot wrote: Just in case it wasn't clear : I will vote no on this proposal as long as it features longish readable names like shouldEquals. You'd rather `should!==`? I'm not sure which I'd prefer; the thing is that so far you're the only one strongly against it. The only other thing I heard was a question at DConf on why it wasn't `assertEquals` instead. Atila
Re: std.experimental.testing PR review
On 26/06/15 17:20, David Gileadi wrote: Let's paint this bikeshed! I tend to like must instead of should; it's a bit shorter and stronger. I prefer should. I tend to like dot-separated English for testing, e.g. throwRangeError.must.throw!RangeError; One advantage is that the dot after must (or should) can trigger code completion on IDEs. It will also be more composeable. Currently there are a couple of assertions that have no negative form, i.e. shouldBeTrue. If should/shouldNot would be separate from the actual comparison it would be possible to write shouldNot.beTrue. It could also support custom assertions in the future: should.beA!(Foo). Finally, I wonder if it's possible to hijack operator overloading to support this: 2.timesTwo.must == 4; Yes and no :). For plain == it's possible, but not for = and the other greater/less/negative comparisons. All these operators are implemented using the same method. Although there's an enhancement request (somewhere) to support overloading these operators separately. -- /Jacob Carlborg
Re: std.experimental.testing PR review
On Friday, 26 June 2015 at 15:20:43 UTC, David Gileadi wrote: On 6/26/15 7:30 AM, Atila Neves wrote: On Friday, 26 June 2015 at 13:32:39 UTC, Dicebot wrote: Just in case it wasn't clear : I will vote no on this proposal as long as it features longish readable names like shouldEquals. You'd rather `should!==`? I'm not sure which I'd prefer; the thing is that so far you're the only one strongly against it. The only other thing I heard was a question at DConf on why it wasn't `assertEquals` instead. Atila Let's paint this bikeshed! I tend to like must instead of should; it's a bit shorter and stronger. I tend to like dot-separated English for testing, e.g. throwRangeError.must.throw!RangeError; One advantage is that the dot after must (or should) can trigger code completion on IDEs. Finally, I wonder if it's possible to hijack operator overloading to support this: 2.timesTwo.must == 4; Yes, this works for `==`. Unfortunately it doesn't work for anything else, including but not limited to `!=`. Oh, I tried. Even though `==` is clearly going to be the most used one, I don't like the idea of having to use a compile-time string for the other ones. Atila
Re: std.experimental.testing PR review
Nothing jumps out at me as being especially bad. The posix escape
codes could also be Windows compatible by rewriting them somehow,
instead of building a string, make a struct message { int color;
string text; } or something that you pass to the thread... but
since that's an internal implementation detail that isn't
necessary to work, meh.
The docs in package.d could show more higher level examples too,
before I looked at the code, I didn't realize there was more to
it.
Re: std.experimental.testing PR review
Just in case it wasn't clear : I will vote no on this proposal as long as it features longish readable names like shouldEquals.
Re: std.experimental.testing PR review
On Monday, 22 June 2015 at 14:27:24 UTC, Atila Neves wrote: On Friday, 19 June 2015 at 15:24:25 UTC, Atila Neves wrote: On Monday, 1 June 2015 at 16:38:06 UTC, Atila Neves wrote: I think I've addressed all comments now, except for Robert's one on whether or not multi-threading should be on by default. Also, after much toiling I've managed to get the docs up here: http://atilaneves.github.io/phobos/phobos/std_experimental_testing.html It really should be a lot easier to generate the docs. Anyway, please give it a look and destroy away. Atila On Monday, 20 April 2015 at 13:28:30 UTC, Atila Neves wrote: [...] Methinks all comments have been addressed again, except for the multi-threading by default or not. Atila Bump. Personally I think this is ready for voting. Atila Can I please get either 1) comments 2) a LGTM? Ideally this should make 2.068, assuming it's good enough. Atila
Re: std.experimental.testing PR review
On Friday, 19 June 2015 at 15:24:25 UTC, Atila Neves wrote: On Monday, 1 June 2015 at 16:38:06 UTC, Atila Neves wrote: I think I've addressed all comments now, except for Robert's one on whether or not multi-threading should be on by default. Also, after much toiling I've managed to get the docs up here: http://atilaneves.github.io/phobos/phobos/std_experimental_testing.html It really should be a lot easier to generate the docs. Anyway, please give it a look and destroy away. Atila On Monday, 20 April 2015 at 13:28:30 UTC, Atila Neves wrote: [...] Methinks all comments have been addressed again, except for the multi-threading by default or not. Atila Bump. Personally I think this is ready for voting. Atila
Re: std.experimental.testing PR review
On Monday, 1 June 2015 at 16:38:06 UTC, Atila Neves wrote: I think I've addressed all comments now, except for Robert's one on whether or not multi-threading should be on by default. Also, after much toiling I've managed to get the docs up here: http://atilaneves.github.io/phobos/phobos/std_experimental_testing.html It really should be a lot easier to generate the docs. Anyway, please give it a look and destroy away. Atila On Monday, 20 April 2015 at 13:28:30 UTC, Atila Neves wrote: [...] Methinks all comments have been addressed again, except for the multi-threading by default or not. Atila
Re: std.experimental.testing PR review
On 2015-06-03 12:52, Atila Neves wrote: This work was done before I learned Cucumber. In fact, one of the motivations for learning it in the first place were the bugs I kept introducing and not knowing about. This is (hopefully) going into Phobos, so even if I had Cucumber tests for unit-threaded I probably wouldn't include them in the pull request. It's a big and important one already without having to discuss whether or not we want to test the standard library with an external tool. Yeah, I would not recommend adding Cucumber tests in a pull request. -- /Jacob Carlborg
Re: std.experimental.testing PR review
On 2015-06-03 12:50, Atila Neves wrote: Easily. I toyed with this syntax foo().should == 3; And that works. Unfortunately it doesn't work for `!=` or `=`. I could do the other operators as compile-time strings, but then `==` would be the weird one out. In the end I didn't think there was much value of typing `should.equal` over `shouldEqual` and left it as it is. The reason would/might be custom should functions/matchers. I'd have to think about that. First we'd have to agree on how things should look, though. Yeah, but I would think that if the should function was separate from the operator used it would be easier, but I don't know. No, but it'd be easy to write. Is that actually needed though? It doesn't seem something that would come up often, and one could always write `foo.shouldEqual(bar)`. I don't know. RSpec has it. I might take a look, but really all I've ever seen is expecting to throw a particular exception anyway. This was for when you're expecting a function to _not_ throw an exception. -- /Jacob Carlborg
Re: std.experimental.testing PR review
On Thursday, 4 June 2015 at 06:33:27 UTC, Jacob Carlborg wrote: On 2015-06-03 12:50, Atila Neves wrote: Easily. I toyed with this syntax foo().should == 3; And that works. Unfortunately it doesn't work for `!=` or `=`. I could do the other operators as compile-time strings, but then `==` would be the weird one out. In the end I didn't think there was much value of typing `should.equal` over `shouldEqual` and left it as it is. The reason would/might be custom should functions/matchers. would/might? YAGNI. No, but it'd be easy to write. Is that actually needed though? It doesn't seem something that would come up often, and one could always write `foo.shouldEqual(bar)`. I don't know. RSpec has it. Ruby doesn't have ``. It's not needed in D. I might take a look, but really all I've ever seen is expecting to throw a particular exception anyway. This was for when you're expecting a function to _not_ throw an exception. I used to think this was useful, probably due to symmetry. In practice, it's not. If you want to assert an expression doesn't throw, just... write the expression. The test will fail anyway if it throws. Atila
Re: std.experimental.testing PR review
On Wednesday, 3 June 2015 at 07:30:31 UTC, Jacob Carlborg wrote: On 2015-04-20 15:28, Atila Neves wrote: Original library: http://code.dlang.org/packages/unit-threaded PR: https://github.com/D-Programming-Language/phobos/pull/3207 * Would it be possible to make the should functions more composeable. Instead of a.shouldEqual(b) something like a.should.equal(b). Then you don't need a separate shouldNot function for all functions, just one Easily. I toyed with this syntax foo().should == 3; And that works. Unfortunately it doesn't work for `!=` or `=`. I could do the other operators as compile-time strings, but then `==` would be the weird one out. In the end I didn't think there was much value of typing `should.equal` over `shouldEqual` and left it as it is. There's already some controversy over syntax as it is, see Dicebot's comments. * Is it possible to create custom should functions or marchers as RSpec would call them? Otherwise perhaps the above suggestion would make that easier I'd have to think about that. First we'd have to agree on how things should look, though. * I would recommend writing the actual operator used for a given should function in the documentation Good idea. * Is there a function to compare if two objects are the actual same objects in memory, i.e. comparing using is? No, but it'd be easy to write. Is that actually needed though? It doesn't seem something that would come up often, and one could always write `foo.shouldEqual(bar)`. * Latest versions of RSpec does not allow to specify an exception type when a test should not throw an exception. I don't recall the exact reason now but it might be worth investigating and taking in to consideration I might take a look, but really all I've ever seen is expecting to throw a particular exception anyway. * Is there any special output when running the tests? In that case, how does it look like? Is it possible to use different formatters for the output and create custom ones? Yes. It looks identical to the library that preceded this, unit-threaded. There are examples in the repository for both passing and failing tests on purpose to show what the output is like. Atila
Re: std.experimental.testing PR review
On Wednesday, 3 June 2015 at 07:42:58 UTC, Jacob Carlborg wrote: On 2015-04-20 15:28, Atila Neves wrote: Original library: http://code.dlang.org/packages/unit-threaded PR: https://github.com/D-Programming-Language/phobos/pull/3207 No Cucumber tests? This is what you're up against [1] ;). I think the Cucumber tests in RSpec are a perfect example of how to use Cucumber correctly. And this Relish site is able to generate good looking documentation based on Cucumber feature files. [1] http://www.relishapp.com/rspec/rspec-core/docs This work was done before I learned Cucumber. In fact, one of the motivations for learning it in the first place were the bugs I kept introducing and not knowing about. This is (hopefully) going into Phobos, so even if I had Cucumber tests for unit-threaded I probably wouldn't include them in the pull request. It's a big and important one already without having to discuss whether or not we want to test the standard library with an external tool. Atila
Re: std.experimental.testing PR review
On 2015-04-20 15:28, Atila Neves wrote: Original library: http://code.dlang.org/packages/unit-threaded PR: https://github.com/D-Programming-Language/phobos/pull/3207 * Would it be possible to make the should functions more composeable. Instead of a.shouldEqual(b) something like a.should.equal(b). Then you don't need a separate shouldNot function for all functions, just one * Is it possible to create custom should functions or marchers as RSpec would call them? Otherwise perhaps the above suggestion would make that easier * I would recommend writing the actual operator used for a given should function in the documentation * Is there a function to compare if two objects are the actual same objects in memory, i.e. comparing using is? * Latest versions of RSpec does not allow to specify an exception type when a test should not throw an exception. I don't recall the exact reason now but it might be worth investigating and taking in to consideration * Is there any special output when running the tests? In that case, how does it look like? Is it possible to use different formatters for the output and create custom ones? -- /Jacob Carlborg
Re: std.experimental.testing PR review
On 2015-04-20 15:28, Atila Neves wrote: Original library: http://code.dlang.org/packages/unit-threaded PR: https://github.com/D-Programming-Language/phobos/pull/3207 No Cucumber tests? This is what you're up against [1] ;). I think the Cucumber tests in RSpec are a perfect example of how to use Cucumber correctly. And this Relish site is able to generate good looking documentation based on Cucumber feature files. [1] http://www.relishapp.com/rspec/rspec-core/docs -- /Jacob Carlborg
Re: std.experimental.testing PR review
On Tuesday, 2 June 2015 at 06:31:14 UTC, Jacob Carlborg wrote: On 2015-06-01 18:38, Atila Neves wrote: I think I've addressed all comments now, except for Robert's one on whether or not multi-threading should be on by default. Also, after much toiling I've managed to get the docs up here: http://atilaneves.github.io/phobos/phobos/std_experimental_testing.html It really should be a lot easier to generate the docs. Anyway, please give it a look and destroy away. I would like to have some more documentation, some more examples how to use this. Especially the main page needs some more links and at best a first example of the kicker features of the package. By links I mean pure conveniance, see how far down the left the package is located :D I think all UDA's should start with a lowercase character.
Re: std.experimental.testing PR review
On Tue, 02 Jun 2015 08:31:30 +0200 Jacob Carlborg via Digitalmars-d digitalmars-d@puremagic.com wrote: On 2015-06-01 18:38, Atila Neves wrote: I think I've addressed all comments now, except for Robert's one on whether or not multi-threading should be on by default. Also, after much toiling I've managed to get the docs up here: http://atilaneves.github.io/phobos/phobos/std_experimental_testing.html It really should be a lot easier to generate the docs. Anyway, please give it a look and destroy away. I would like to have some more documentation, some more examples how to use this. I think all UDA's should start with a lowercase character. I think all UDA's should start with a uppercase character ;-). (It is much easier to distinguish between UDAs and non-UDAs(@nogc, @safe, @property ...))
Re: std.experimental.testing PR review
On Tuesday, 2 June 2015 at 06:31:14 UTC, Jacob Carlborg wrote: On 2015-06-01 18:38, Atila Neves wrote: I think I've addressed all comments now, except for Robert's one on whether or not multi-threading should be on by default. Also, after much toiling I've managed to get the docs up here: http://atilaneves.github.io/phobos/phobos/std_experimental_testing.html It really should be a lot easier to generate the docs. Anyway, please give it a look and destroy away. I would like to have some more documentation, some more examples how to use this. Oh yeah, that's a complaint I heard at DConf. I should definitely work on that. I think all UDA's should start with a lowercase character. Why? Atila
Re: std.experimental.testing PR review
On Tuesday, 2 June 2015 at 08:51:11 UTC, extrawurst wrote: On Tuesday, 2 June 2015 at 06:31:14 UTC, Jacob Carlborg wrote: On 2015-06-01 18:38, Atila Neves wrote: I think I've addressed all comments now, except for Robert's one on whether or not multi-threading should be on by default. Also, after much toiling I've managed to get the docs up here: http://atilaneves.github.io/phobos/phobos/std_experimental_testing.html It really should be a lot easier to generate the docs. Anyway, please give it a look and destroy away. I would like to have some more documentation, some more examples how to use this. Especially the main page needs some more links and at best a first example of the kicker features of the package. By links I mean pure conveniance, see how far down the left the package is located :D There was an issue with the dlang.org repository and it didn't generate the usual navigation on the left. I'll see if it's been fixed in the meanwhile and update it. Like I said before, generating the docs should be a lot easier than it is now. Atila
Re: std.experimental.testing PR review
On Tuesday, 2 June 2015 at 19:54:49 UTC, Jacob Carlborg wrote: On 2015-06-02 11:12, Atila Neves wrote: Why? Because I think it's looks better :). It's also same standard as the built-in attributes are using. Changed them to lower case, added examples and updated the docs. Atila
Re: std.experimental.testing PR review
On Tuesday, 2 June 2015 at 20:50:13 UTC, Atila Neves wrote: Changed them to lower case, added examples and updated the docs. Atila The docs look nice. As far as I can tell, this should cover at least 75% (for me it is more like 95%) of what people want and is not built-in.
Re: std.experimental.testing PR review
On 2015-06-02 11:12, Atila Neves wrote: Why? Because I think it's looks better :). It's also same standard as the built-in attributes are using. -- /Jacob Carlborg
Re: std.experimental.testing PR review
On Tuesday, 2 June 2015 at 09:13:49 UTC, Atila Neves wrote: On Tuesday, 2 June 2015 at 08:51:11 UTC, extrawurst wrote: On Tuesday, 2 June 2015 at 06:31:14 UTC, Jacob Carlborg wrote: On 2015-06-01 18:38, Atila Neves wrote: I think I've addressed all comments now, except for Robert's one on whether or not multi-threading should be on by default. Also, after much toiling I've managed to get the docs up here: http://atilaneves.github.io/phobos/phobos/std_experimental_testing.html It really should be a lot easier to generate the docs. Anyway, please give it a look and destroy away. I would like to have some more documentation, some more examples how to use this. Especially the main page needs some more links and at best a first example of the kicker features of the package. By links I mean pure conveniance, see how far down the left the package is located :D There was an issue with the dlang.org repository and it didn't generate the usual navigation on the left. I'll see if it's been fixed in the meanwhile and update it. Like I said before, generating the docs should be a lot easier than it is now. Should work now. Atila
Re: std.experimental.testing PR review
On 2015-06-01 18:38, Atila Neves wrote: I think I've addressed all comments now, except for Robert's one on whether or not multi-threading should be on by default. Also, after much toiling I've managed to get the docs up here: http://atilaneves.github.io/phobos/phobos/std_experimental_testing.html It really should be a lot easier to generate the docs. Anyway, please give it a look and destroy away. I would like to have some more documentation, some more examples how to use this. I think all UDA's should start with a lowercase character. -- /Jacob Carlborg
Re: std.experimental.testing PR review
I think I've addressed all comments now, except for Robert's one on whether or not multi-threading should be on by default. Also, after much toiling I've managed to get the docs up here: http://atilaneves.github.io/phobos/phobos/std_experimental_testing.html It really should be a lot easier to generate the docs. Anyway, please give it a look and destroy away. Atila On Monday, 20 April 2015 at 13:28:30 UTC, Atila Neves wrote: Original library: http://code.dlang.org/packages/unit-threaded PR: https://github.com/D-Programming-Language/phobos/pull/3207 It's my first Phobos PR, I tried reading the wiki and doing what's required but bear with me if I've screwed up somehow. I wasn't sure whether or not to split the PR. In the end I just took the existing library, edited it a lot and got it ready for review. Unit test blocks can be named with @Name. They execute in parallel by default but that's only if the default runner is used. Atila
Re: std.experimental.testing PR review
On 2015-04-20 16:29, Atila Neves wrote: I saw links to PRs past with generated docs but have/had no idea how to get a similar result. Besides the html make target, what is it a person has to do exactly? I'm going to edit the wiki with this information as well. Some developer use Ddox [1], some use the same way as Phobos uses. I think it's enough to add you're files to Phobos (including the makefiles) and the generate the documentation using make in the dlang.org repository. [1] https://github.com/rejectedsoftware/ddox -- /Jacob Carlborg
Re: std.experimental.testing PR review
On Tuesday, 21 April 2015 at 08:17:37 UTC, Robert burner Schadek wrote: On Monday, 20 April 2015 at 14:29:33 UTC, Atila Neves wrote: I saw links to PRs past with generated docs but have/had no idea how to get a similar result. Besides the html make target, what is it a person has to do exactly? I'm going to edit the wiki http://wiki.dlang.org/Building_DMD#Building_the_Docs This part I'd figured out; it's the getting it online for others to see (and the need to do this as part of the PR) I had troubles with. I did a lot of google searches for site:dlang.org std.experimental.logger ;) Atila
Re: std.experimental.testing PR review
On Monday, 20 April 2015 at 14:29:33 UTC, Atila Neves wrote: I saw links to PRs past with generated docs but have/had no idea how to get a similar result. Besides the html make target, what is it a person has to do exactly? I'm going to edit the wiki http://wiki.dlang.org/Building_DMD#Building_the_Docs
Re: std.experimental.testing PR review
On 2015-04-21 15:56, Robert burner Schadek wrote: I did use github pages https://pages.github.com/ I have used dropbox. -- /Jacob Carlborg
Re: std.experimental.testing PR review
On Tuesday, 21 April 2015 at 13:18:59 UTC, Atila Neves wrote: This part I'd figured out; it's the getting it online for others to see (and the need to do this as part of the PR) I had troubles with. I did use github pages https://pages.github.com/
std.experimental.testing PR review
Original library: http://code.dlang.org/packages/unit-threaded PR: https://github.com/D-Programming-Language/phobos/pull/3207 It's my first Phobos PR, I tried reading the wiki and doing what's required but bear with me if I've screwed up somehow. I wasn't sure whether or not to split the PR. In the end I just took the existing library, edited it a lot and got it ready for review. Unit test blocks can be named with @Name. They execute in parallel by default but that's only if the default runner is used. Atila
Re: std.experimental.testing PR review
On 2015-04-20 15:28, Atila Neves wrote: Original library: http://code.dlang.org/packages/unit-threaded PR: https://github.com/D-Programming-Language/phobos/pull/3207 It's my first Phobos PR, I tried reading the wiki and doing what's required but bear with me if I've screwed up somehow. Any new module must go through the review queue [1]. Ask here in the newsgroup for a review on the code. Generated documetnation and code should be available for the module. A review manager will volunteer to manage the review. When a module has been approved, first then should a pull request be created. [1] http://wiki.dlang.org/Review_Queue -- /Jacob Carlborg
Re: std.experimental.testing PR review
On Monday, 20 April 2015 at 13:50:59 UTC, Jacob Carlborg wrote: On 2015-04-20 15:28, Atila Neves wrote: Original library: http://code.dlang.org/packages/unit-threaded PR: https://github.com/D-Programming-Language/phobos/pull/3207 It's my first Phobos PR, I tried reading the wiki and doing what's required but bear with me if I've screwed up somehow. Any new module must go through the review queue [1]. Ask here in the newsgroup for a review on the code. Generated documetnation and code should be available for the module. A review manager will volunteer to manage the review. When a module has been approved, first then should a pull request be created. [1] http://wiki.dlang.org/Review_Queue I saw links to PRs past with generated docs but have/had no idea how to get a similar result. Besides the html make target, what is it a person has to do exactly? I'm going to edit the wiki with this information as well. Atila
