search for: stringized

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.

...s are incompatible with -traditional + */ +#define MAKESTR(x) #x +#define XSTR(x) MAKESTR(x) +#define XCONC(args...) args +#define CONCSTR(x...) #x +#define XCSTR(x...) CONCSTR(x) + +/* + * Propagate these definitions as strings up to C code for convenient use + * in stringized assembler as pseudo-mnemonics; we must emit assembler + * directives to generate equates for the VMI_CALL_XXX symbols, since they + * will not be available otherwise to the assembler, and we can't emit + * the C versions of these functions from within an inline assembler + * string. + */ +asm(&...

...s are incompatible with -traditional + */ +#define MAKESTR(x) #x +#define XSTR(x) MAKESTR(x) +#define XCONC(args...) args +#define CONCSTR(x...) #x +#define XCSTR(x...) CONCSTR(x) + +/* + * Propagate these definitions as strings up to C code for convenient use + * in stringized assembler as pseudo-mnemonics; we must emit assembler + * directives to generate equates for the VMI_CALL_XXX symbols, since they + * will not be available otherwise to the assembler, and we can't emit + * the C versions of these functions from within an inline assembler + * string. + */ +asm(&...