search for: stringiz

Displaying 9 results from an estimated 9 matches for "stringiz".

Did you mean: stringi
2016 Jul 12
3
Xapian 1.4.0 released
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
2007 Jul 15
3
[LLVMdev] Floating point constants (bug?)
>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
2009 Aug 24
1
[LLVMdev] Regular Expression lib support
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
2016 Jul 23
0
Xapian 1.4.0 released
...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) "): " + tname); Reference: https://github.com/xapian/xapian/blob/e3692bff7b7c25c8e09536889d5884d033199f36/xapian-core/backends/glass/glass_database.cc#L1083-L1084 On Tue, Jul 12, 2016 at 10:13 AM, James Aylett <james-xapian at tartarus.org> wrote: > On Mo...
2015 May 13
1
Why is the diag function so slow (for extraction)?
> 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 >
2017 Feb 14
3
[PATCH v2] x86/paravirt: Don't make vcpu_is_preempted() a callee-save function
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.
2017 Feb 14
3
[PATCH v2] x86/paravirt: Don't make vcpu_is_preempted() a callee-save function
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.
2007 Apr 18
3
[RFC, PATCH 4/24] i386 Vmi inline implementation
...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...
2007 Apr 18
3
[RFC, PATCH 4/24] i386 Vmi inline implementation
...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...