On Thu, 06 May 2010 04:14:27 +0200, Don wrote:
> Michel Fortin wrote:
>> I hope it didn't stop you from reading the rest of the post, because it
>> seemed like a nice idea to improve the __trait syntax.
>>
> http://d.puremagic.com/issues/show_bug.cgi?id=3702
This is now the fourth highest voted
bearophile wrote:
> Lutger:
...
>>rdmd has the option --main, together with -unittest you can easily do
>>this.<
>
> This page doesn't list that option:
> http://www.digitalmars.com/d/2.0/rdmd.html
>
> rdmd prints:
> --eval=code evaluate code +� la perl -e (multiple --eval allowed)
> --loo
Michel Fortin wrote:
On 2010-05-05 21:12:47 -0400, Walter Bright
said:
Michel Fortin wrote:
If even Walter has difficulty figuring out the ! around __traits,
Missing a ! is always a problem. People even do not see the word "not".
It was an exaggeration. That "ultimate proof" wasn't meant
On 2010-05-05 21:12:47 -0400, Walter Bright said:
Michel Fortin wrote:
If even Walter has difficulty figuring out the ! around __traits,
Missing a ! is always a problem. People even do not see the word "not".
It was an exaggeration. That "ultimate proof" wasn't meant to be too serious.
I
bearophile wrote:
Don:
One thing which you've not mentioned is in unittests for interfaces (and derived
classes). I would like to be able to check that *all* implementations of an
interface satisfy a sequence of tests.<
A "sequence of tests" can mean a group of tests, see point 6.
So what y
Michel Fortin:
> [...] I'll take that as the ultimate proof that [...]
It's not an ultimate proof.
Bye,
bearophile
Michel Fortin wrote:
If even Walter has difficulty figuring out the ! around __traits,
Missing a ! is always a problem. People even do not see the word "not".
On 2010-05-05 20:25:45 -0400, Walter Bright said:
bearophile wrote:
But the "specs" of the Range template say that Range must not work if
step is zero (this means that the unittest has to fail if Range
compiles when the given step is zero). So I have to test this too. I
can do that with o
bearophile wrote:
But the "specs" of the Range template say that Range must not work if step is
zero (this means that the unittest has to fail if Range compiles when the given step is
zero). So I have to test this too. I can do that with one more unittest (D1 code):
static assert(!is(typ
Another usage example of the strong typedef of D1. This his D2 code, it shows
how it can catch bugs in combineRectangles():
import std.algorithm: max, min;
typedef int Length;
typedef Length HorizPosition;
typedef Length VertPosition;
struct Point {
HorizPosition x;
VertPosition y;
}
On 2010-05-05 14:24:37 -0400, bearophile said:
My post about unit test features contains other things worth discussing
about. This was just the first point :-)
Indeed.
I agree it'd be handy to have named unit tests. I see two reasons to
use named unit tests:
1. to print a list of all the
Walter Bright>I don't see that in the example given.<
I can try with one real example from my dlibs1. This template is the third I
use with foreach to create the fake static foreach, this accepts a step
(stride) value too.
But such step can't be zero, so I add a static assert inside it to make
Lutger:
>Anyway I think if unittests can get a name as a parameter and dmd let's the
>user set the AssertError handler, that will be a sufficient hook to provide
>some useful user extension of the unittest system.<
Ah, I didn't think about an AssertError handler. Among other things, it solves
Lutger wrote:
He wants the opposite: to test that something detects an error correctly,
making sure his template doesn't silently compile wrong code.
I don't see that in the example given.
bearophile wrote:
> dmd D 2.045 improves the built-in unit tests resuming their run when they
> fail (it reports only the first failed assert for each unit test).
>
> There are many features that today a professional unittest system is
> expected to offer, I can write a long list. But in the past
Tomek S.:
>and even doesn't poke your eyes like most mixin code:)<
Thanks, but no thanks. String mixin hacks don't help, they make the situation
worse.
>then you would see the name of the unit test in the stack trace.<
I'd love to see the stack trace with stock dmd :-) I don't know/remember w
Dnia 05-05-2010 o 03:24:50 bearophile
napisał(a):
[snip]
2) Names for unittests. Giving names to things in the universe is a
first essential step if you want to try to understand some part of it.
The compiler makes sure in each module two unittest tests don't share
the same name. An exam
Don:
>I think the majority of the items in your list can already be done fairly well
>(or easily enough by a library), except for giving names to unit tests.<
Let's see the points:
1) The following syntax is compatibile with D2 to implement the two parts of
point 1:
assert(throws!(Ex1, Ex2)(fo
Don wrote:
> bearophile wrote:
>> dmd D 2.045 improves the built-in unit tests resuming their run when they
>> fail (it reports only the first failed assert for each unit test).
>>
>> There are many features that today a professional unittest system is
>> expected to offer, I can write a long lis
Walter Bright wrote:
> bearophile wrote:
>> Walter Bright:
>>> But why? Just use: foo(10);
>>
>> I think you are missing something important here.
>>
>> Static asserts (or other implicit errors) inside a template, etc, test
>> that some input types are correct, some template input values are in
bearophile wrote:
dmd D 2.045 improves the built-in unit tests resuming their run when they fail
(it reports only the first failed assert for each unit test).
There are many features that today a professional unittest system is expected
to offer, I can write a long list. But in the past I have
It is sometime a good idea to assert that a template cannot be
instantiated with bogus arguments.
or to be more generic - do not only test your untis with "working"
scenarios, the "non-working" are also part of the test game :-)
On Wed, 05 May 2010 13:10:07 -0400, Jesse Phillips
wrote:
Robert Jacques Wrote:
On Tue, 04 May 2010 16:51:57 -0400, Rick Trelles
wrote:
[snip]
I'd recommend reading the D language documentation on the Digital Mars
website.
Robert, that is exactly what he did. Each Document page on Digit
On 2010-05-05 14:04:13 -0400, Walter Bright said:
bearophile wrote:
I have to use a syntax like this often enough inside
unittests:
static assert(!__traits(compiles, foo(10)));
But why? Just use:
foo(10);
To put it more simply than bearophile:
foo(10);
// gives you a
Adam D. Ruppe:
> static assert(!__traits(compiles, octal!"not a number"));
> [...]
> So I see the use, but I don't think any special syntax is required. This
> works well enough.
Improving that syntax is not necessary, but in my dlibs1 I have to use
something like that (using is()) for abou
bearophile wrote:
Walter Bright:
But why? Just use: foo(10);
I think you are missing something important here.
Static asserts (or other implicit errors) inside a template, etc, test that
some input types are correct, some template input values are in the correct
range, etc.
In this thread we
Walter Bright:
> But why? Just use:
> foo(10);
I think you are missing something important here.
Static asserts (or other implicit errors) inside a template, etc, test that
some input types are correct, some template input values are in the correct
range, etc.
In this thread we are talkin
On Wed, May 05, 2010 at 11:04:13AM -0700, Walter Bright wrote:
> But why? Just use:
>
>foo(10);
I used the static assert not compiles thing for the octal template -
unittest{
static assert(!__traits(compiles, octal!"not a number"));
// and checking that it doesn't convert im
bearophile wrote:
I have to use a syntax like this often enough inside
unittests:
static assert(!__traits(compiles, foo(10)));
But why? Just use:
foo(10);
Don:
>It seems pretty useless to me. Wanting to make a distinction between "this
>will not compile" and "this will not compile _because it hits a static
>assert_" is an *extremely* niche feature. Because the only times I can imagine
>that you'd care would be because you wanted to ensure it gave
Robert Jacques Wrote:
> On Tue, 04 May 2010 16:51:57 -0400, Rick Trelles
> wrote:
> [snip]
>
> I'd recommend reading the D language documentation on the Digital Mars
> website.
Robert, that is exactly what he did. Each Document page on Digital Mars'
website has a Wiki button in the upper r
bearophile wrote:
Michel Fortin:
Am I right that what you want is this?
static assert(!__traits(compiles, foo(10)));
I want a nice syntax that statically asserts if foo(10) doesn't statically
asserts :-)
What you have written is close (in D1 I have used the is() syntax for a similar
Michel Fortin:
> Am I right that what you want is this?
> static assert(!__traits(compiles, foo(10)));
I want a nice syntax that statically asserts if foo(10) doesn't statically
asserts :-)
What you have written is close (in D1 I have used the is() syntax for a similar
purpose), but besi
On 2010-05-05 07:46:46 -0400, bearophile said:
Michel Fortin:
Can't you do:
static assert(throws!OtherException(sqrt(-5)));
?
Some of those examples of mine were wrong because the main purpose of a
'static throws' is to catch static asserts, not to catch exceptions at
compile time
Michel Fortin:
> Can't you do:
> static assert(throws!OtherException(sqrt(-5)));
> ?
Some of those examples of mine were wrong because the main purpose of a 'static
throws' is to catch static asserts, not to catch exceptions at compile time,
sorry:
static throws(foo(10), StaticException1)
On 2010-05-05 05:10:05 -0400, bearophile said:
unittest {
assert(throws!(OtherException)(sqr(-5)));
assert(throws!(OtherException)( sqr(-5) ));
}
While the static throws can require more compiler support.
Can't you do:
static assert(throws!OtherException(sqrt(-5)));
?
--
Graham Fawcett:
> I just read a provocative critique of a blog article comparing C++ to
> Lisp:
> http://funcall.blogspot.com/2010/05/c-vs-lisp.html
Three years ago I have written this, for D1 with Phobos that doesn't use my
dlibs1:
import std.stdio, std.stream, std.string, std.ctype, std.gc;
>(it reports only the first failed assert for each unit test).<
I was wrong (or the behaviour on this is mutable).
Michel Fortin:
> Your 'throws' template seems good. Should create std.testing and
> include it there.
> Also, perhaps it'd work to use a double-template for this:
> templat
38 matches
Mail list logo
