[phobos] phobos commit, revision 2028

Steve Schveighoffer schveiguy at yahoo.com
Tue Sep 21 09:24:10 PDT 2010


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
> 


      


More information about the phobos mailing list