On 9/19/2010 5: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.

I think this is unreasonable for a few reasons:

1.  It will encourage bit rot in the Windows stuff.  Wine is pretty good, but it isn't perfect.

2.  It will strongly discourage me from fixing a few low hanging fruit bugs whenever I have a little spare time if I constantly have to reboot, fire up a VM, etc. just to get started.

3.  The platform-specific parts of Phobos are a very small fraction of it.  Maybe it's reasonable to insist on testing on Unix when committing changes that are very far-reaching and likely to have a lot of ripple effects (like the one I broke the Linux builds on), but for run of the mill changes that aren't likely to have tons of ripple effects, it's overkill.

4.  Even if you don't get feedback before the commit, the feedback is reasonably rapid with Brad's system.

In short, imposing this requirement on me will substantially lessen my contribution to Phobos.

On 21 September 2010 02:09, David Simcha <dsimcha at gmail.com> wrote:
> ?On 9/19/2010 5: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.
>
> I think this is unreasonable for a few reasons:
>
> 1. ?It will encourage bit rot in the Windows stuff. ?Wine is pretty good, but it isn't perfect.
>
> 2. ?It will strongly discourage me from fixing a few low hanging fruit bugs whenever I have a little spare time if I constantly have to reboot, fire up a VM, etc. just to get started.
>
> 3. ?The platform-specific parts of Phobos are a very small fraction of it. ?Maybe it's reasonable to insist on testing on Unix when committing changes that are very far-reaching and likely to have a lot of ripple effects (like the one I broke the Linux builds on), but for run of the mill changes that aren't likely to have tons of ripple effects, it's overkill.
>
> 4. ?Even if you don't get feedback before the commit, the feedback is reasonably rapid with Brad's system.
>
> In short, imposing this requirement on me will substantially lessen my contribution to Phobos.

I agree.
For a large chunk of the past six weeks, unit tests were broken on
Windows. Situations where tests have passed on Windows but failed on
*nix have been quite rare. And there are still unit tests which are
disabled in Windows because they fail, even though they pass on *nix.
(From memory, there are about five of them).
IMHO, the main problem was simply been that unit tests were not being
run at all.

On Monday, September 20, 2010 18:23:31 Don Clugston wrote:
> I agree.
> For a large chunk of the past six weeks, unit tests were broken on
> Windows. Situations where tests have passed on Windows but failed on
> *nix have been quite rare. And there are still unit tests which are
> disabled in Windows because they fail, even though they pass on *nix.
> (From memory, there are about five of them).
> IMHO, the main problem was simply been that unit tests were not being
> run at all.


I'm not sure that it's necessarily something that we'd want to do, but would it be possible to make it so that checkins which break unit tests not be accepted? My guess would be that you can't, and it could be quite annoying to never be able to checkin something that breaks unit tests (much as you usually wouldn't want to - but it would make sure that the unit tests don't break.

- Jonathan M Davis

On 09/20/2010 08:23 PM, Don Clugston wrote:
>> In short, imposing this requirement on me will substantially lessen my contribution to Phobos.
>
> I agree.
> For a large chunk of the past six weeks, unit tests were broken on
> Windows. Situations where tests have passed on Windows but failed on
> *nix have been quite rare. And there are still unit tests which are
> disabled in Windows because they fail, even though they pass on *nix.
> (From memory, there are about five of them).
> IMHO, the main problem was simply been that unit tests were not being
> run at all.

Passing on Linux and failing on Windows has happened to me quite a few times back before the wine build was not set up. Also there's been cases more recently than that when math idiosyncrasies showed up on one system but not the other.

I don't think bit rot is an issue - Walter always tests on Windows before deploying. This puts the onus on the unittests and the test suite.

The main issue here is discouraging people from working on Phobos. I understand that starting a VM and dealing with an unfamiliar environment can be unpleasant. Perhaps a good middle ground would be cygwin, and passing on cygwin is also a good sign of code portability and non-reliance on OS quirks. Could a primarily-Windows person volunteer to modify posix.mak to accommodate cygwin?


Thanks,

Andrei

On 9/20/2010 8:32 PM, Andrei Alexandrescu wrote:
> On 09/20/2010 08:23 PM, Don Clugston wrote:
>>> In short, imposing this requirement on me will substantially lessen my contribution to Phobos.
>>
>> I agree.
>> For a large chunk of the past six weeks, unit tests were broken on
>> Windows. Situations where tests have passed on Windows but failed on
>> *nix have been quite rare. And there are still unit tests which are
>> disabled in Windows because they fail, even though they pass on *nix.
>> (From memory, there are about five of them).
>> IMHO, the main problem was simply been that unit tests were not being
>> run at all.
> 
> Passing on Linux and failing on Windows has happened to me quite a few times back before the wine build was not set up. Also there's been cases more recently than that when math idiosyncrasies showed up on one system but not the other.
> 
> I don't think bit rot is an issue - Walter always tests on Windows before deploying. This puts the onus on the unittests and the test suite.

I think it's a symptom of exactly what we fixed on the posix side of life.. actually RUNNING the tests.  I'll bet that the windows side is running a subset of the full set of tests.

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<braddr at puremagic.com>    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
>> phobos at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/phobos
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

It's doable with svn too. When we initiated the repository I'd created a "candidate" branch that was parallel with the trunk. The idea was that anything not-yet-sure was to go in candidate, reviewed, tested, and then merged into the trunk.

As there were only 2-3 people working on Phobos at the time, the practice was more overhead than usefulness so it was abandoned. PErhaps we should reenact it.


Andrei

On 9/21/10 10:53 CDT, Sean Kelly wrote:
> 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<braddr at puremagic.com>     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
>>> phobos at puremagic.com
>>> http://lists.puremagic.com/mailman/listinfo/phobos
>> _______________________________________________
>> phobos mailing list
>> phobos at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/phobos
>
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

The current SVN server is 1.4.5 (see http://svn.dsource.org/projects/phobos/)

Merge tracking wasn't added until 1.5.  I'd oppose any use of branches/merging unless svn was upgraded.  I've tried to use merging with the std.process stuff and it's a nightmare.  Basically, svn has no clue where changes came from, so unless you have really really simple merging (i.e. you only merge one direction *once*) it's more trouble than it's worth.

But I've been following this discussion quietly, and I don't really understand the objection to checking in changes that break other builds.  It's not like checking in changes is a release, so it has no bearing on people who aren't actively developing phobos/druntime.  Isn't it enough for Brad's automated builds to maybe just post an email to this list when a build fails (after he changes it to be triggered by checkins of course)?  And then it's just on the developer to make sure it works on his system at least (shame on you if you checkin a change that wasn't tested in at least *one* system).  In other words, why should each developer check all builds when we have an automated system that does that?

-Steve




----- Original Message ----
> From: Andrei Alexandrescu <andrei at erdani.com>
> To: Discuss the phobos library for D <phobos at puremagic.com>
> Sent: Tue, September 21, 2010 12:07:04 PM
> Subject: Re: [phobos] phobos commit, revision 2028
> 
> It's doable with svn too. When we initiated the repository I'd created a "candidate" branch that was parallel with the trunk. The idea was that anything not-yet-sure was to go in candidate, reviewed, tested, and then merged into the trunk.
> 
> As there were only 2-3 people working on  Phobos at the time, the practice was more overhead than usefulness so it was  abandoned. PErhaps we should reenact it.
> 
> 
> Andrei
> 
> On 9/21/10  10:53 CDT, Sean Kelly wrote:
> > 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<braddr at puremagic.com>      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
> >>> phobos at puremagic.com
> >>>  http://lists.puremagic.com/mailman/listinfo/phobos
> >>  _______________________________________________
> >> phobos mailing  list
> >> phobos at puremagic.com
> >> http://lists.puremagic.com/mailman/listinfo/phobos
> >
> >  _______________________________________________
> > phobos mailing  list
> > phobos at puremagic.com
> > http://lists.puremagic.com/mailman/listinfo/phobos
> _______________________________________________
> phobos  mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
> 

On 9/21/10 11:24 CDT, Steve Schveighoffer wrote:
> But I've been following this discussion quietly, and I don't really understand the objection to checking in changes that break other builds.  It's not like checking in changes is a release, so it has no bearing on people who aren't actively developing phobos/druntime.  Isn't it enough for Brad's automated builds to maybe just post an email to this list when a build fails (after he changes it to be triggered by checkins of course)?  And then it's just on the developer to make sure it works on his system at least (shame on you if you checkin a change that wasn't tested in at least *one* system).  In other words, why should each developer check all builds when we have an automated system that does that?

The idea is that the trunk should be clean such that people can rebase their code freely to benefit of the latest source and avoid conflicts when checking in. The current system discourages synchronization. Even with the automated build in place, and even if we know that yesterday's build succeeded, there's no info whether the build would work with whatever is in the trunk. Ideally the cycle is change code -> make sure it builds -> commit.

Andrei

----- Original Message ----
> From: Andrei Alexandrescu <andrei at erdani.com>
> To: Discuss the phobos library for D <phobos at puremagic.com>
> Sent: Thu, September 23, 2010 12:28:24 PM
> Subject: Re: [phobos] phobos commit, revision 2028
> 
> On 9/21/10 11:24 CDT, Steve Schveighoffer wrote:
> > But I've been following  this discussion quietly, and I don't really
>understand
> > the objection to  checking in changes that break other builds.  It's not
like
> >  checking in changes is a release, so it has no bearing on people who
aren't
> > actively developing phobos/druntime.  Isn't it enough for  Brad's automated builds to maybe just post an email to this list when a  build fails (after
he
> > changes it to be triggered by checkins of  course)?  And then it's just on
>the
> > developer to make sure it works  on his system at least (shame on you if you checkin a change that wasn't  tested in at least *one* system).  In other
>words,
> > why should each  developer check all builds when we have an automated system
>that
> > does  that?
> 
> The idea is that the trunk should be clean such that people can  rebase their
>code freely to benefit of the latest source and avoid conflicts  when checking in. The current system discourages synchronization. Even with the  automated build in place, and even if we know that yesterday's build succeeded,  there's no info whether the build would work with whatever is in the trunk.  Ideally the cycle is change code -> make sure it builds ->  commit.

That would be ideal, but not everyone has a mac, a windows box, and a Linux box (and what about freeBSD?).  And even if they did, to require them to check the build on all three before checking in would be quite tedious (you can't just svn update because you haven't checked in yet!).

If you check in a change that builds on nothing, then yeah, that's an obvious problem.  But I don't think we should attach so much negativity to checking in a change that breaks a build by accident -- nobody is purposely checking in broken code.  Branches are usually for when you know you are going to be working on something for a while and may check in incomplete or non-functioning code.

Note, you are free to rebase your code from a specific version -- which can be determined by the last valid build from Brad's server (in fact, Brad, you could tag the

latest successfully tested build automatically).

-Steve