search for: reassert

...osure—well, I was > on the verge of tossing it overboard. I can't blame Chris for his > reticence to add such nonsense to LLVM, as it only serves to slow > builds and source control operations for all. Totally agree that we should not be pulling boost into the source tree. But I will reassert my point that using Boost as a library can be a good thing. Yes, it's an additional dependence for llvm, but all of the parts of Boost I use are header-only and thus don't create a linking problem. Honestly, Boost is soo phenomenally good in places that's it's pretty much a second...

Jakob, I have a question about the following (four) asserts recently added in bundleWithPred() and bundleWithSucc() (see below). What is the real danger of reasserting a connection even if it already exist? My problem with them happens when I try to call finalizeBundle() on an existing bundle to which I have added a new instruction. The goal - a new bundle header with liveness abbreviation, but because of these asserts I now have to unbundle all, and re-bundle...

On Feb 1, 2013, at 3:43 PM, "Sergei Larin" <slarin at codeaurora.org> wrote: > I have a question about the following (four) asserts recently added in > bundleWithPred() and bundleWithSucc() (see below). What is the real danger > of reasserting a connection even if it already exist? The intention was to identify code that may have been converted from the old style a little too quickly. I wanted to avoid bugs from a global s/setIsInsideBundle/bundleWithPred/g search and replace. > My problem with them > happens when I try to cal...

On 2008-05-18, at 04:36, Roman Levenstein wrote: > Chris Lattner wrote: > >> We have already imported pieces of boost. > > BTW, which ones? > >> The general rule is that it is ok to use specific pieces, > > Totally agree with you. > >> but they have to be converted to the LLVM style and way of doing >> things. Also, things with huge chains of

...t.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=40b36daad0ac704e6d5c1b75789f371ef5b053c1 “The patch below works around a minor bug found in the UART of the remote management card used in many HP ia64 and parisc servers (aka the Diva UARTs). The problem is that the UART does not reassert the THRE interrupt if it has been previously cleared and the IIR THRI bit is re-enabled. This can produce a very annoying failure mode when used as a serial console, allowing a boot/reboot to hang indefinitely until an RX interrupt kicks it into working again (ie. an unattended reboot could stall)...

...he stupid .html middleman... the world is full of technical dummies who will kiss the feet of the person who gives them the means to return to "the old days" when .html was a simple thing to create... today's xhtml/css mess is one sick joke that the technoids pulled on the public to reassert the role of "required experts". it's time to disintermediate them again... that's my opinion, and i'm stickin' to it... *** david said: > The? comment that started this sub-thread > was a throwaway line, really ok, sorry i made even a small deal about it....

Hi Chris, Thanks a lot for a detailed opinion and explanation! It really answers the original question, without going to far into political discussions about boost and generic allocators pros/cons aspects. ----- Ursprüngliche Mail ---- > Von: Chris Lattner <sabre at nondot.org> > An: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> > Gesendet: Sonntag, den 18. Mai

...> > On Feb 1, 2013, at 3:43 PM, "Sergei Larin" <slarin at codeaurora.org> > wrote: > > > I have a question about the following (four) asserts recently added > in > > bundleWithPred() and bundleWithSucc() (see below). What is the real > > danger of reasserting a connection even if it already exist? > > The intention was to identify code that may have been converted from > the old style a little too quickly. I wanted to avoid bugs from a > global s/setIsInsideBundle/bundleWithPred/g search and replace. > > > My problem with them...

This is an initial series of patches to improve channel recovery on Turing GPUs with the goal of improving reliability enough to eventually enable SVM for Turing. It's likely follow up patches will be required to fully address problems with less trivial workloads than what I have been able to test thus far. This series primarily addresses a number of hardware changes to interrupt layout and

[CCing the libguestfs mailing list - as Rich responded on IRC about your question on timeout.] On Sun, Feb 21, 2016 at 10:07 PM, Thomas Kee <xsited@yahoo.com> wrote: > Hi Kashyap, > > Thanks for offering to help. The day job caused a pause and it took me an > hour to reassert where I was in the process. I usually hang out on freenet > as xsited. I am still reading the process for formally reporting the issue > as described on the site. > > Walking through this has shown me some significant difference from > previously working almost exclusively with qem...

...d3d11_immediate_context_VSSetShader(). d3d11: Partially implement d3d11_immediate_context_PSSetShader(). d3d11: Implement d3d11_immediate_context_ClearRenderTargetView(). d3d11: Implement d3d11_immediate_context_DrawInstanced(). Ken Thomases (2): winemac: Queue an event to reassert the WinAPI window position before Cocoa adjusts its position for a display change. winemac: Remove JPEG 2000 from the bitmap formats that other bitmap formats can be converted to. Marcus Meissner (2): d3d11: Remove useless NULL check (Coverity). hidclass.sys: Fixed copy/paste err...