<html><head></head><body bgcolor="#FFFFFF"><div>I'd favour either complaining about overflow of numbers rather than types, or auto-convert to strings so it's a bit more like using twitter snowflake ids. Or I guess something like the math.Long trick from Closure.</div><div><br></div><div>Any idea when v8 will get 64 bit support? Or is this not on the roadmap at all?</div><div><br></div><div>On arrays, is there no way of deferring comprehension until later? So you could pass an array-like object around and slice it later.</div><div><br></div><div>J<br><br>On 29 May 2012, at 06:23, Liam <<a href="mailto:xapian@networkimprov.net">xapian@networkimprov.net</a>> wrote:<br><br></div><div></div><blockquote type="cite"><div><br><div class="gmail_quote">On Mon, May 28, 2012 at 2:44 PM, Olly Betts <span dir="ltr"><<a href="mailto:olly@survex.com" target="_blank">olly@survex.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Generally, uint32 isn't necessarily the right type to use everywhere,<br>
and means things will go wrong if someone patches Xapian and rebuilds<br>
it to use (e.g. 64 bit document ids). <br></blockquote><div><br>Javascript doesn't currently support int64. It goes up to 2^53. We should probably raise an error if the Xapian build we're running against uses int64 doc ids.<br>
</div>
<br><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
XOR can also take any number of subqueries. And on trunk, OP_FILTER,<br>
OP_AND_NOT, and OP_AND_MAYBE can also take any number of subqueries<br>
(with OP(A, B, C) being interpreted as OP(OP(A, B), C)<br></blockquote><div><br>XOR is missing from the online docs for Query(Query::op, Iterator, Iterator, termcount)<br><br>We can include support for the other ops you mention and leave it commented out for now.<br>
<br>Marius, that Query object is missing a parameter:uint32 member. <br></div>
<br><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Also, it would be nice to support a mixture of strings and query objects<br>
as the subqueries (like we do in most of the dynamically typed languages).<br></blockquote><div><br>You can include a term query in the list by writing {tname:'string'}, but certainly we could let 'string' be a shorthand for that. <br>
</div>
<br><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I'm dubious about wrapping the various iterators as methods which read<br>
all the entries from the iterator and return an array. <br></blockquote><div><br> We'll take optional start & count arguments for those guys.<br></div></div><br>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>Xapian-devel mailing list</span><br><span><a href="mailto:Xapian-devel@lists.xapian.org">Xapian-devel@lists.xapian.org</a></span><br><span><a href="http://lists.xapian.org/mailman/listinfo/xapian-devel">http://lists.xapian.org/mailman/listinfo/xapian-devel</a></span><br></div></blockquote></body></html>