I recently began porting an existing C++ project of mine (a
compiler/interpreter for a dynamic language) to D. In the process I found that
the built-in unit testing support, while an awesome concept, was a little bit
sparse. In particular, assert() is fairly useless for unit tests, since it
thr
Lutger Wrote:
>
> You can use line and file info with default arguments, this works
> (special case). I just hack around the default unittest system,
> something like this:
>
> void test(string testName)(void delegate () testClosure,
> int line = __LINE__,
>
Nick Sabalausky Wrote:
> The deferAssert module (possible name change and other API improvements
> pending) of my SemiTwist D Tools library (
> http://www.dsource.org/projects/semitwist ) is designed to get around those
> problems.
Good to know I'm not the only one who's had to working around
I installed the DMD2 compiler as per the instructions here:
http://www.digitalmars.com/d/2.0/dmd-linux.html
After tweaking the conf file to get it actually working, I tried compiling a
simple "hello, world" program. This was the result:
/usr/bin/ld: skipping incompatible
/usr/lib/gcc/x86_64-li
Nick Sabalausky Wrote:
> I haven't gotten into D2 yet, but D1 (DMD) works fine on Ubuntu 9.04 for me.
>
Hm, just tried DMD 1.0, same exact result. Do you have a 32-bit installation of
Ubuntu?
Pelle MÃ¥nsson Wrote:
>
> An assertion handler should be created for use in unittests. Preferably
> with colorized output. :)
>
> I stole and changed slightly from std.contracts.enforce (untested)
>
> T test(T, string file=__FILE__, int line=__LINE__)
> (T value, string message="T
Walter Bright Wrote:
> Here's what I use on Ubuntu 64:
>
> sudo apt-get install gcc-multilib libc6-i386 lib6-dev-i386
> sudo apt-get install gcc-multilib
> sudo apt-get install g++-multilib
That did the trick. Thanks much! :-)
I'm working on a set of handy unit testing accessories for my projects. What
I'd love to achieve is something like this:
expectEqual( myFoo, 3 );
Which, on failure, would result in something along the lines of this diagnostic:
somefile.d:37: Test failure!
Expected: myFoo == 3
Joel Anderson Wrote:
>
> You could potentially use a mixin to do this. The resulting code would
> look something like this.
>
> void main()
> {
>int myFoo = 100;
>mixin(expectEquals! ( "myFoo == 3" ));
> }
Yeah, mixins could work, but they're ugly. ;-)
Forcing the use
Joel Anderson Wrote:
>
> That's one of the reasons I've wished D had a nicer syntax for the
> string mixin format. This one kinda scares people away :p
What kind of syntax do you have in mind?
Making mixins less obtrusive might ease aggravation when they're being used as
boilerplate, but mak
Lutger Wrote:
>
> This syntax should be possible, which also gives syntax highlighting:
>
> expectEquals!q{ myFoo == 3 };
>
> But there is the problem that expectEquals is defined in a module which
> doesn't have access to myFoo. I don't know how to solve that.
>
Template alias parameters han
I'm currently writing a compiler for my own language in D, and one of the
things I'm implementing at the moment is the processing of floating-point
literals. My primary reference is William Clinger's "How to read floating point
numbers accurately," which is available here:
ftp://ftp.ccs.neu.edu
Paul D. Anderson Wrote:
> I know there are a lot of D programmers rooting for enhancements to the
> unittests in D (and I don't want to re-open that discussion), but are there
> any of the best and brightest among us who have developed a module to allow
> for named tests and tests that keep run
I recently upgraded from DMD 2.03something to the latest alpha. Previously, I
was able to do this:
import std.stdio;
import core.runtime;
void main() {
foreach( m; ModuleInfo ) {
writefln( m.name );
}
}
Which would list the names of all modules. I was using the property to provide
bearophile Wrote:
> Among those four solutions the one I like more is the 'IV'. Because it keeps
> the work of developing the library out of the busy hands of Walter, but
> produces something that can have nice enough syntax, with a not too much
> complex compiler, and it probably allows for som
Trip Volpe Wrote:
> ...and if an assert fails in one test in a module, _all_ subsequent tests in
> that module will be aborted, even though this makes no sense.
Actually I said this wrong. It's worse than that: after one assert failure,
_all_ further execution is aborted, meaning tha
16 matches
Mail list logo
