I think if we used something like Git, commits could be made to a staging area where unit testing was done before publishing the changes to the central repository. Not as easy with SVN though.
On Sep 19, 2010, at 2:32 PM, Andrei Alexandrescu wrote: > All great initiatives. But the point is to verify that stuff builds _before_, > not _after_, the commit. Until we have Unix, Windows, and OSX machines that > we can all ssh into, that won't be possible. > > As unpleasant as that is to some of us, I think we need to impose anyone who > commits to use some Unix as their development platform. (There are many > reasons. One is, it wouldn't be reasonable to develop on Windows or OSX as > one needs to pay to get them.) Linux has wine, which is stable enough to be a > good test bed for Windows code. That means any of us can build and unittest > for at least two operating systems. > > Just a reminder: with the current posix.mak running on Linux, to unittest, > type: > > make unittest > > and to unittest under wine, type: > > make OS=win32wine unittest > > If somebody wants to develop on Windows and build on cygwin, that's fine too, > but cygwin support is not currently in our makefile. It would be a great > addition. > > > Andrei > > On 09/18/2010 09:14 PM, Brad Roberts wrote: >> Emails are on my todo list. My top plans: >> >> 1) track svn revision id's >> >> 2) change the build rate to be reactive to submissions (ie, potentially much >> faster than once an hour, but also not at all when no changes have been >> submitted) >> >> 3) send breakage emails >> >> Maybe I should move #3 to be #1. I can add the changes that caused the >> brokenness later. Would everyone be ok with receiving one mail every time >> anything breaks in any build? Right now that'd mean roughly 2 emails per >> hour >> while things are broken.. potentially 4 per hour when osx/freebsd are added. >> >> Another thought I had was to have each build cycle contain one and only one >> change. If multiple changes come in between runs, still just increment >> through >> them with a couple back-to-back builds. It'd make it a lot easier to see >> exactly which change introduced breakage. >> >> Some thoughts on your list.. >> >> 1) I've noticed that most of the breakages have been platform specific. >> Interestingly, most of them have NOT been in platform specific code. So... >> why? >> (Yes, yours was in posix path handling, but that's not typical for the last >> couple weeks). >> >> 2) I find this one easy enough to work around by using two trees.. one being >> my >> do lots of development stuff, all over the place as the fancy suits me. The >> second being the 'carve off a set to be checked in'. I use the latter to >> avoid >> exactly the problem you mention, allowing the testing of the set to submit in >> isolation. The cost of moving changes over adds overhead, but usually isn't >> nearly as hard as writing the code in the first place and is something you >> get >> better at with just a little practice. >> >> But, yes, absolutely, things happen and that's ok. Reacting and resolving >> when >> they do is as important as any other step of the development process. >> >> Later, >> Brad >> >> On 9/18/2010 7:00 PM, David Simcha wrote: >>> 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 _______________________________________________ phobos mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/phobos
