Forking phobos

Jens Mueller jens.k.mueller at gmx.de
Mon Apr 4 16:43:32 PDT 2011


Jens Mueller wrote:
> Steven Schveighoffer wrote:
> > On Sun, 03 Apr 2011 18:31:12 -0400, Jens Mueller
> > <jens.k.mueller at gmx.de> wrote:
> > 
> > >Thank you. I'm doing it right now. It works.
> > >
> > >Sean Kelly wrote:
> > >>You'll need to build DMD from source. A change was checked in
> > >>the other day that requires it.
> > >>
> > 
> > Please note, the last time I checked, dmd is built in debug mode by
> > default.  Not sure if this has changed, but if you are getting weird
> > extraneous message, that's probably why.
> > 
> > I think you have to do make release, or something like that.
> 
> Looking at the output of
> $ make -f linux.mak
> and inside linux.mak it seems that is not a debug build.
> But thanks anyway.
> 
> I needed to build 64 bit because my Linux ships no 32-bit libcurl and I
> don't want to build that as well. I had to add a symbolic link from
> libcurl.so.4 to libcurl.so. Don't know why it wasn't there. It should
> have, shouldn't it.
> 
> BTW I see --- std.regex(3443) broken test ---
> The code is
> unittest
> {
> // DAC: This doesn't create the file before running the test!
> pragma(msg, " --- std.regex("~ __LINE__.stringof ~") broken test --- ");
> /+  
>     string tmp = "/tmp/deleteme";
>     std.file.write(tmp, "1 abc\n2 defg\n3 hijklm");
>     auto t = loadFile!(uint, string)(tmp, regex("([0-9])+ +(.+)"));
>     //writeln(t);
>     assert(t[0] == tuple(1, "abc"));
>     assert(t[1] == tuple(2, "defg"));
>     assert(t[2] == tuple(3, "hijklm"));
> +/
> }
> 
> I do not understand that comment. I ran this test by commenting in the
> code and it worked.

Maybe even better using a temporary file like this
auto file = File.tmpfile();
file.write("1 abc\n2 defg\n3 hijklm");
file.rewind();
auto t = loadFile!(uint, string)(file, regex("([0-9])+ +(.+)"));
//writeln(t);
assert(t[0] == tuple(1, "abc"));
assert(t[1] == tuple(2, "defg"));
assert(t[2] == tuple(3, "hijklm"));

Because I have seen the auto-tester failing because of forgotten files.
A good test shouldn't leave any trace if it was successful. Every change
may cause another test to behave differently. Tests should be isolated
as much as possible. Thus, not influencing each other. There may be
cases where one wants to influence another test but these are very rare
I guess.

Jens


More information about the Digitalmars-d mailing list