Yea, I'm guilty of breaking the Linux builds. I think a good
enhancement to your auto testing system would be to have it
automatically nag the Phobos list whenever something breaks (instead of
you doing it manually). The reasons why things slip through the cracks
seem to be:
1. Breaking platform-specific code for a platform you don't develop on.
2. Bits of code in your tree that you never committed that you forgot
about, that change the results.
Realistically, these things will always slip through the cracks once in
a while, but when they do quick and automatic feedback is a Good Thing (TM).
On 9/18/2010 9:45 PM, Brad Roberts wrote:
I just tried building with link upgraded to the 8.00.7 beta.. no better.
Guys, it's really important that all of these packages continue to build and
pass their respective tests. It seems like we can't go more than a day or so
without something new being introduced that breaks something.
I recognize that we're all volunteers here, but please be responsible for making
sure your changes don't cause any platform to stop building and passing tests.
It might well be that there's a lurking problem that's just surfaced somehow,
but the bottom line is that being unable to build and run the tests successfully
is a blocker for everyone.
I also recognize that not everyone has access to more than one platform. That's
exactly one of the reasons I setup the auto build/test system. Hopefully we'll
get os/x and freebsd added soon. Use it.. watch the results.
In case your head has been in the sand, the url:
http://d.puremagic.com/test-results/
Fix or revert.. file bugs.. figure out work arounds.. but don't leave broken.
Please?
Thanks,
Brad
On 9/18/2010 5:49 PM, David Simcha wrote:
Yeh, I had experimentally added std.parallelism to my DMD directory and
compiled Phobos and encountered similar things. When I ran the unittests for
std.parallelism by itself, they passed. Whenever I ran them along with the rest
of Phobos, there was an access violation somewhere (I don't know where). I
didn't say anything because I wasn't sure where the bug was at the time, and
didn't have a clue where to start tracking it down.
On 9/18/2010 8:39 PM, Shin Fujishiro wrote:
Brad Roberts<[email protected]> wrote:
The win32 phobos tests started failing after this submit.. with an access
violation.
http://d.puremagic.com/test-results/test_data.ghtml?dataid=3525
Probably it's related to the executable size.
With the following pragma, I found that the access violation starts
from about 82 instantiations of std.typecons.Tuple.
----------
struct Tuple(Specs...)
{
pragma(msg, "@@@");
...
----------
Removing some Tuple instantiations in Tuple's unittests suppressed the
access violation. Try removing first two blocks in Tuple's unittests;
phobos tests should succeed with no access violation.
Or, run the tests without a random module. For instance, inserting
__EOF__ at the beginning of std/json.d fixes the access violation!
My commit r2025 erased the body of a dummy function in Tuple. I reckon
that changeset could suppress the access violation thanks to smaller
executable. Now, another commit increased the size, and...
Shin
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
