code-d 0.10.1 released (D support for vscode)
I just released a new version of code-d, it now supports projects without any dub.json file which some people probably will like. This is really useful for standalone projects with a custom build system like writing an OS/Kernel or other projects that don't want to use dub. Additionally some bugs like the dcd-server staying open got fixed. But probably the biggest news for this update is the improved support for DlangUI markup language. It's is now completing enums for enum fields and true/false. Also it knows about the relations between the Widget classes so it will also complete all inherited children. If you want to give it a try just install the most recent workspace-d build using the workspace-d CLI installer: https://github.com/Pure-D/workspace-d-installer Once you have workspace-d installed and added the binaries to your path you can simply install the latest stable release of code-d in vscode using 'ext install code-d' If you have any suggestions/ideas/feedback don't forget to post it as reply to this post. Project github: https://github.com/Pure-D/code-d PS: If you need a debugger frontend (currently GDB and LLDB) for vscode, try my debugging extension. It supports most features and D is working like a charm in there: https://github.com/WebFreak001/code-debug (install using 'ext install gdb')
Re: unit-threaded v0.6.5 - Type-parametrized tests
On Friday, 11 March 2016 at 14:26:34 UTC, Atila Neves wrote: Didn't Robert have a QuickCheck-alike as well? Yes, https://github.com/D-Programming-Language/phobos/pull/2995
Re: unit-threaded v0.6.5 - Type-parametrized tests
On Friday, 11 March 2016 at 08:06:19 UTC, Jacob Carlborg wrote:
On 2016-03-10 12:05, Atila Neves wrote:
No, sorry. I haven't needed it yet. Something like this?
Yes.
@Types!(int, string)
void testArray(T)() {
import std.container;
auto arr = Array!T();
arr.empty.shouldBeTrue;
arr.insertBack(T.init);
arr.empty.shouldBeFalse;
auto l = arr.length;
l.shouldEqual(1);
}
I'm trying to think how this would be useful. Would you want to
test with different values than T.init? Or is there some
library that can generate random values based on a type?
What about user defined types? T.init my not be useful at all.
I don't want to sound negative but I'm trying to see the use
cases.
There's this: https://github.com/mcandre/dashcheck
Didn't Robert have a QuickCheck-alike as well?
Like I said, I'm not sure of the use cases, but I thought I'd
enable it and it was fun to do. I know I've written template unit
tests in C++ in the past, but I can't remember why.
Atila
Re: New Article: My Experience Porting Python Dateutil's Date Parser to D
On Thursday, 10 March 2016 at 21:25:16 UTC, Jack Stouffer wrote: On Wednesday, 9 March 2016 at 22:12:42 UTC, Walter Bright wrote: I haven't read the article yet, but you'll get more interest by putting a summary as the first comment on reddit. Thanks for the advice, I think it caused more people to read it. Also, I forgot to mention in the article that the unit tests with coverage reports enabled run in 110ms. I love fast tests :) Did you time the python tests too? A value by itself doesn't mean much to me
Re: Hotfix release vibe.d 0.7.28
Am 10.03.2016 um 20:40 schrieb Eugene Wissner: Sönke, is your current work on core available somewhere? Since my vibe.d related work isn't stable it wouldn't a problem to use unstable core-component. It is better than rewriting later if a lot of things change. It's still in a very early state (barely enough to run a TCP based server) and the user facing API will stay more or less backwards compatible. The main exceptions are that some callbacks will now have to be nothrow and/or @safe and that some types change from class to struct. So at this point I'd not recommend this for anything more than quick experiments and possibly as the basis for early feedback about certain API decisions: https://github.com/vibe-d/
Re: unit-threaded v0.6.5 - Type-parametrized tests
On 2016-03-10 12:05, Atila Neves wrote:
No, sorry. I haven't needed it yet. Something like this?
Yes.
@Types!(int, string)
void testArray(T)() {
import std.container;
auto arr = Array!T();
arr.empty.shouldBeTrue;
arr.insertBack(T.init);
arr.empty.shouldBeFalse;
auto l = arr.length;
l.shouldEqual(1);
}
I'm trying to think how this would be useful. Would you want to test
with different values than T.init? Or is there some library that can
generate random values based on a type?
What about user defined types? T.init my not be useful at all.
I don't want to sound negative but I'm trying to see the use cases.
--
/Jacob Carlborg
