search for: bissect

...if(i>50){break} if(abs(a-b)<e){m=(a+b)/2 raiz1=m} if(abs(a-b)>e){ m=(a+b)/2 af=f(a) if((af*f(m))>0){a=m} if((af*f(m))<0){b=m}} i=i+1}} -- View this message in context: http://r.789695.n4.nabble.com/Help-in-Bissection-algorithm-tp4651295.html Sent from the R help mailing list archive at Nabble.com.

...imply that only the tip of each push is important. In the Git world, it usually isn't. The flow promoted by Git is precisely to make sure each and every commit passes the tests. So, the granularity of "incremental development" is really the commit, not how often you merge. "git bissect" is a good illustration of this. It does not only bissect accross the mainline, but it does all along the DAG. For example, if you bisect a regression between linux-2.6.38 and linux-2.6.39, you may well end up with a guilty commit that was written long before linux-2.6.38, but merged in the wi...

...day, March 26, 2014 8:14:18 AM > Subject: Re: [LLVMdev] Lots of regtest failures on PPC64/Linux > > Hi Ismail, > > Is there a buildbot for that? There *should* be. Will, we have a -mcpu=native bot now, right? Does it compile Release or Release+Asserts? -Hal > If not, can you bissect to find the > offending commit? > > cheers, > --renato > > On 26 March 2014 13:04, İsmail Dönmez <ismail at donmez.ws> wrote: > > Hi, > > > > Recent trunk has a lot of failures on PPC64/Linux. One seems to be > > crash > > with a backtrace lik...

Hi, Recent trunk has a lot of failures on PPC64/Linux. One seems to be crash with a backtrace like: [ 3149s] -- [ 3149s] 0 libLLVMSupport.so 0x00003fff7ed0b864 llvm::sys::PrintStackTrace(_IO_FILE*) + 4294746876 [ 3149s] 1 libLLVMSupport.so 0x00003fff7ed0bb1c [ 3149s] 2 libLLVMSupport.so 0x00003fff7ed0c520 [ 3149s] 3 linux-vdso64.so.1 0x00003fff7f7b0478 __kernel_sigtramp_rt64 + 0 [ 3149s] 4

On 20 January 2015 at 18:55, Hans Wennborg <hans at chromium.org> wrote: > There weren't many merges between the branch point and the rc1 tag. They were: > > r226023 InstCombine: Don't take A-B<0 into A<B if A-B has other uses > r226029 IR: Fix a use-after-free in RAUW > r226044 IR: Drop metadata references more aggressively during teardown > r226046

On Jul 22, 2011, at 3:45 PM, Bob Wilson wrote: > > On Jul 22, 2011, at 3:33 PM, fly language wrote: > >> >> After git, mainline will still be the most important branch for the *project*, >> but you will work with quite a few branches on parallel. >> >> >> Who's mainline? :) Be prepared to assign a super-merger, like Linus, to maintain the

...This model is based on the idea of some trusted maintainer doing code review of the branch and then pushing it to mainline as a huge batch when everything is happy and working. This is fundamentally in tension with the LLVM model and I have no desire for us to switch. -Chris > > "git bissect" is a good illustration of this. It does not only bissect > accross the mainline, but it does all along the DAG. For example, if you > bisect a regression between linux-2.6.38 and linux-2.6.39, you may well > end up with a guilty commit that was written long before linux-2.6.38, >...

On Jul 22, 2011, at 2:02 PM, Andrew Trick wrote: >> Of course, if you've used SVN extensively, you've been trained to think >> that history has to be somewhat linear, and perhaps even that the trunk >> branch is the only one needing QA attention. Migration from SVN to Git >> is hard because you have to change the mental model, not just command >> names and

...till moving but typing commands blindly doesn't seem to work. The network and SSH deamon being still running, I was able to collect some Kernel logs. I attach them. I also tried to go back to an older version of the Kernel in case the problem was in there but that did not help (So I can't bissect the kernel to find the possible bug) I am not sure if the game is doing something nasty or if there is a bug in the opensource driver. Logs show all kind of error messages I could find. -- You are receiving this mail because: You are the assignee for the bug. -------------- next part ----------...

...rees, commit 13a86519202c5d119d83640d6f781f3181205d2c seems to introduce a regression when booting with a screen attached to displayport (the system otherwise boots fine with the same kernel using an HDMI output). An original bug was filed with the Ubuntu bug tracker and contains information about bissection: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1723619 A (set of) dmesg outputs can be found here: https://pastebin.ubuntu.com/25767385/ 4.14-rc5 still exhibits this behavior on the tested system. Please don't hesitate to reach out to me should you need more information - one affe...