On Friday, 23 December 2016 at 14:43:28 UTC, Chris Wright wrote:
> I *think* you can do that with an ugly API and string mixins and only needing to parse to the level of parentheses and equality operators.

Yeah, you kinda can, or, of course, you can do stuff like assertEquals etc. named functions, or string template args like the existing libraries do.

Just since it is a built in, we can do so much more!

The main hard part would be getting the printing support in the runtime, but meh you can go SUCH a long way just printing the built ins, and it doesn't take that much code.... and it could be under conditional compilation to make it opt out too.

sometimes i confess i want to write a new druntime. maybe i'd call it "dango"

On Friday, 23 December 2016 at 14:06:24 UTC, Adam D. Ruppe wrote:
> Have you seen my filthy hack for getting individual unittests to continue on failure? http://stackoverflow.com/a/40896271/1457000

I have to say you are a master of D hacks :)
This code can potentially reprogram a CPU and break my HW!

pragma(joking, off).

> It'd be a lot easier though to just actually get the compiler or library to do it. There's so many ways, I personally like the RTInfo for modules approach, it is easy to implement, easy to customize per project, and gives us access to the CT features. But there's others too.

And that's why I said *quick development*. In theory, I can add any feature to any language by myself with a certain level of investment. But it's not the reality for 99,999% (all poor and lazy) programmers.

In result I have to accept small obstacles and go on. Otherwise I wouldn't go anywhere.

So the real question is: what can we do and what should we do with the current amount of resources we have?

Personally I can also be involved in development of new (important in my opinion) enhancements to one of the greatest features in D, i.e. built in uinttesting.

I'm even opting for changing the compiler if it's necessary (like expanding "-unittest" switch). But of course limiting to DRuntime only would be a step forward anyway.

I wonder what Walter thinks about it now, because as far as I remember he was against build-in unittest improvements.

Cheers,
Piotrek

On Friday, 23 December 2016 at 11:21:00 UTC, Atila Neves wrote:
> The worst is how useless plain `assert` is. But, all of these issues can (and have) be solved by libraries.
>
> Atila

Would assert fixing take into account it's presence in betterC code?

Cheers,
Piotrek

On Friday, 23 December 2016 at 16:28:58 UTC, Piotrek wrote:
> On Friday, 23 December 2016 at 11:21:00 UTC, Atila Neves wrote:
>> The worst is how useless plain `assert` is. But, all of these issues can (and have) be solved by libraries.
>>
>> Atila
>
> Cheers,
> Piotrek
>
> Would assert fixing take into account it's presence in betterC code?

Why would you care if the unittest build is betterC or not? The main build, sure, but it really shouldn't matter if the unit tests need druntime or the whole kitchen sink.

Atila

On 12/23/2016 06:18 AM, Atila Neves wrote:
> On Thursday, 22 December 2016 at 18:19:31 UTC, Andrei Alexandrescu wrote:
>> On 12/22/2016 12:46 PM, Piotrek wrote:
>>> The inability to give test a name (plus selective unittesting) and
>>> continue on failure is puzzling to me.
>>
>> Both of these are affordable with the current language (attributes)
>> with changes to druntime. Who wants to take this? -- Andrei
>
> I would, but I don't see how this is possible without one of:
>
> 1) A standardised build system
> 2) Changes to the language
>
> Attributes mean static reflection, and that means explicitly (and at
> compile-time) stating every module being built somewhere. There is no
> current way to reflect on packages.

Oh, I see. So there needs to be some sort of cooperation between the compile-time realm (stash the unittest attributes during compilation) and the run-time realm (pick up that data and use it).

> The only way I know how to do this
> is to use the build system to autogenerate a D file listing all modules
> to reflect on, which not coincidentally is how unit-threaded does it,
> with dub. But it only works if you're using dub and even then fails
> sometimes if it can't parse `dub describe` properly.

Got it.

> I would've changed druntime 4 years ago if I could, it's the only reason
> I know of ModuleInfo and what it has to do with unit tests.
>
> Maybe I'm missing something or lacking imagination.

Well clearly some changes in the compiler and/or runtime could bring us to where we want to be.


Andrei

On 12/23/2016 02:37 AM, Jacob Carlborg wrote:
> On 2016-12-22 19:19, Andrei Alexandrescu wrote:
>
>> Both of these are affordable with the current language (attributes) with
>> changes to druntime. Who wants to take this? -- Andrei
>
> What do you think about this idea [1]?
>
> [1] http://forum.dlang.org/post/npptbk$2mk0$1@digitalmars.com

It looks like a solid traditional approach. It would be great to explore approaches where D's unique features would bring a strategic advantage. -- Andrei

On Friday, 23 December 2016 at 16:25:13 UTC, Piotrek wrote:
> In result I have to accept small obstacles and go on. Otherwise I wouldn't go anywhere.
>
> So the real question is: what can we do and what should we do with the current amount of resources we have?

If you need a testing framework, try dunit https://wiki.dlang.org/Libraries_and_Frameworks#Unit_Testing_Framework

On Friday, 23 December 2016 at 17:22:48 UTC, Kagamin wrote:
> On Friday, 23 December 2016 at 16:25:13 UTC, Piotrek wrote:
>> In result I have to accept small obstacles and go on. Otherwise I wouldn't go anywhere.
>>
>> So the real question is: what can we do and what should we do with the current amount of resources we have?
>
> If you need a testing framework, try dunit https://wiki.dlang.org/Libraries_and_Frameworks#Unit_Testing_Framework

No. I want to use build-in unit testing.

Cheers,
Piotrek

On Friday, 23 December 2016 at 17:07:29 UTC, Atila Neves wrote:
> On Friday, 23 December 2016 at 16:28:58 UTC, Piotrek wrote:
>> On Friday, 23 December 2016 at 11:21:00 UTC, Atila Neves wrote:
>>> The worst is how useless plain `assert` is. But, all of these issues can (and have) be solved by libraries.
>>>
>>> Atila
>>
>> Cheers,
>> Piotrek
>>
>> Would assert fixing take into account it's presence in betterC code?
>
> Why would you care if the unittest build is betterC or not? The main build, sure, but it really shouldn't matter if the unit tests need druntime or the whole kitchen sink.
>
> Atila

I was referring to "assert" call in general here. I don't have enough experience for all betterC requirements. And I think I have never used unit tests and betterC switch together.

Cheers,
Piotrek

On 2016-12-23 18:12, Andrei Alexandrescu wrote:

> It looks like a solid traditional approach. It would be great to explore
> approaches where D's unique features would bring a strategic advantage.

I had hoped that D's unique features good be used on top of that low level library.

-- 
/Jacob Carlborg