search for: stringizing

On Mon, Jul 11, 2016 at 02:02:56PM -0700, Kevin Duraj wrote: > You are saying that when I search for "delve Xapian 1.4" on Google, a > company worth of 491 Billion of Dollars and you saying that their top > of the search result has nothing to do with Xapian. > > https://www.google.com/search?q=xapian+delve&ie=utf-8&oe=utf-8#q=delve+xapian+1.4 Well, I'm not

>From the language guide: "The one non-intuitive notation for constants is the optional hexadecimal form of floating point constants. For example, the form 'double 0x432ff973cafa8000' is equivalent to (but harder to read than) 'double 4.5e+15'. The only time hexadecimal floating point constants are required (and the only time that they are generated by the disassembler) is

On Aug 23, 2009, at 9:50 PM, OvermindDL1 wrote: > On Sun, Aug 23, 2009 at 10:20 PM, Chris Lattner<clattner at apple.com> > wrote: >> On Aug 23, 2009, at 9:11 PM, OvermindDL1 wrote: >>>> >>>> Again, forget boost regex. :) >>> >>> What about std::regex? >> >> No, we have to build with c++'98 compilers. I think you're

James, I would like to propose to change the following code while indexing a term that is larger than 245 characters and then crashing and aborting the entire index, we could rather truncate the term to 245 characters and continue with indexing. if (tname.size() > MAX_SAFE_TERM_LENGTH) throw Xapian::InvalidArgumentError("Term too long (> " STRINGIZE(MAX_SAFE_TERM_LENGTH) "):

> From: Martin Maechler <maechler at lynne.stat.math.ethz.ch> > diag() should not work only for pure matrices, but for all > "matrix-like" objects for which ``the usual methods'' work, such > as > as.vector(.), c(.) > > That's why there has been the c(.) in there. > > You can always make code faster if you write the code so it only >

On Mon, Feb 13, 2017 at 05:34:01PM -0500, Waiman Long wrote: > It is the address of &steal_time that will exceed the 32-bit limit. That seems extremely unlikely. That would mean we have more than 4G worth of per-cpu variables declared in the kernel.

On Mon, Feb 13, 2017 at 05:34:01PM -0500, Waiman Long wrote: > It is the address of &steal_time that will exceed the 32-bit limit. That seems extremely unlikely. That would mean we have more than 4G worth of per-cpu variables declared in the kernel.

Macros to use VMI calls from assembly and C languages are introduced. The macros are quite complex, but the end result is rather impressive. The result is that when compiling a VMI kernel, the native code is emitted inline, with no function call overhead, and some wiggle room for register allocation. The hypervisor compatibility code is emitted out of line into a separate section, and patched

Macros to use VMI calls from assembly and C languages are introduced. The macros are quite complex, but the end result is rather impressive. The result is that when compiling a VMI kernel, the native code is emitted inline, with no function call overhead, and some wiggle room for register allocation. The hypervisor compatibility code is emitted out of line into a separate section, and patched