Sounds reasonable on both fronts. Out of curiousity, how would I repro? 'Verbosity' seems to be set by a run-time variable. Remind where I set 64 bit for indices? (I mean I am of course aware that int64_t needs %ld ...) [ Oh right that's the first template argument which we tend to default to int32_t for R to match its integer... ]

Also, as always, a ChangeLog entry would be appreciated. Format is an emacs default, but I guess you can see how it works. Two spaces on the date/author/email line, a tab to the * for the change description.

A much simpler solution to the same problem would be to just use %ld (or %ud) and cast to int64_t (or uint64_t) in the two or three cases where node count is printed:

edd@paul:~/git/rcppannoy(master)$ grep annoylib_showUpdate inst/include/*
inst/include/annoylib.h:  #define annoylib_showUpdate(...) { fprintf(stderr, __VA_ARGS__ ); }
inst/include/annoylib.h:  #define annoylib_showUpdate(...) { __ERROR_PRINTER_OVERRIDE__( __VA_ARGS__ ); }
inst/include/annoylib.h:  annoylib_showUpdate("%s: %s (%d)\n", msg, strerror(errno), errno);
inst/include/annoylib.h:  annoylib_showUpdate("%s\n", msg);
inst/include/annoylib.h:    if (_verbose) annoylib_showUpdate("has %d nodes\n", _n_nodes);
inst/include/annoylib.h:    if (_verbose) annoylib_showUpdate("unloaded\n");
inst/include/annoylib.h:      annoylib_showUpdate("prefault is set to true, but MAP_POPULATE is not defined on this platform");
inst/include/annoylib.h:    if (_verbose) annoylib_showUpdate("found %zu roots with degree %d\n", _roots.size(), m);
inst/include/annoylib.h:      if (_verbose) annoylib_showUpdate("pass %zd...\n", thread_roots.size());
inst/include/annoylib.h:          annoylib_showUpdate("File truncation error\n");
inst/include/annoylib.h:    if (_verbose) annoylib_showUpdate("Reallocating to %d nodes: old_address=%p, new_address=%p\n", new_nodes_size, old, _nodes);
inst/include/annoylib.h:          annoylib_showUpdate("No node for index %d?\n", j);
inst/include/annoylib.h:        annoylib_showUpdate("\tNo hyperplane found (left has %zu children, right has %zu children)\n",
edd@paul:~/git/rcppannoy(master)$ 

For the well-established reason that R has no native int64_t I don't think the issue is all that critical here either way.

@elbamos Would you mind adding a ChangeLog entry? Alternatively I have a simpler PR in #82 but this one is also good because it keeps the change out of (upstream files) annoylib.h.

I've updated the ChangeLog. I agree your PR #82 is simpler; I thought about doing it that way but didn't think you'd take a PR that put the package out of sync with upstream.

Out of curiousity, how would I repro?

I'm getting the issue because I'm using both RcppAnnoy and RcppArmadillo, compiled with -DARMA_64BIT_WORD. I confess, it probably isn't really necessary for me to have 64-bit vertex counts, and there's probably another way to work around the warning. On the other hand, I'm not sure why Annoy makes the vertex index a templated variable if they don't intend to support 64-bit indices.

you'd take a PR that put the package out of sync with upstream.

Yep. Clearly preferable to have it in our header, and your function is more general.

I'm getting the issue because I'm using both RcppAnnoy and RcppArmadillo, compiled with -DARMA_64BIT_WORD.

Yep. And Annoy is after all a Python + C++ package upstream so they can do 65 bit integers easily. We may want to look into supporting it with bit64. (I used it quite extensively but a little care if usually needed when setting it up.)

Your ChangeLog needs a bit of whitespace fixing, I'll take care of that tomorrow.

Thanks for the PR. The way I changed the vignette setup means I have to wait for the new Rcpp to be on CRAN, likely early January, before we can upload a new version. So it'll be a few weeks.

Thank you!