<div dir="ltr">Hey there<br><br>The thing that remains extremely puzzling to me is that using `Linking to: Rcpp, RcppEigen` (without the RcppSpdlog calls), it compiles correctly on i386. I've created a branch here: <br><a href="https://github.com/kharchenkolab/N2R/tree/without_RcppSpdlog">https://github.com/kharchenkolab/N2R/tree/without_RcppSpdlog</a><br><br><a href="https://win-builder.r-project.org/04120gdc336K/">https://win-builder.r-project.org/04120gdc336K/</a><div><div><br></div><div>It compiles correctly, and the package words as intended. <br><br>Why would including `Linking to: Rcpp, RcppEigen, RcppSpdlog` result in these 32-bit/64-bit errors, in particular that RcppEigen error? <br><br>It's a bit strange---I'll keep looking into this. <br><br><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Sep 20, 2020 at 12:34 AM Evan Biederstedt <<a href="mailto:evan.biederstedt@gmail.com">evan.biederstedt@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">Hey Dirk<br><br>I really appreciate the help here. I've been trying this via Mac OS with VMWare Fusion using a Windows 10 32-bit ISO. (Yeesh, it's slow.)<br><br></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>> 1. You get an R CMD check warning on use of stderr. That is understandable as</div><div>you included _upstream_ spdlog. It will do that. Once you instrument it the</div><div>way RcppSpdlog does, this issue goes away.  The change is minimal as we can</div><div>simply create the 'r_sink_mt' instance we need in the Hnsw constructor. I</div><div>will send you a PR for that in a minute.</div></blockquote><div dir="ltr"><br>Yes, this is entirely correct. Although the spdlog library installs successfully, I would love to use RcppSpdlog to get rid of the stderr warning. <br><br>RcppSpdlog does precisely what I need here :) Thank you<br><br></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>> 2. The 32bit issue. I have not yet looked into this but it might be best to</div><div>disentangle this.  As I mentioned, _maybe_ we need to switch to int64_t</div><div>use. Very very worst case you could simply disable the code via #define and</div><div>state that 'legacy systems' will no longer be supported ;-).  I am</div><div>half-kidding here but it is an option. Nobody is running your genomics</div><div>workload on systems from 15 years ago so ..</div></blockquote><div><br>I have no successful updates, sadly. I'm using int64_t for every `int` here: <a href="https://github.com/kharchenkolab/N2R/blob/master/src/n2knn.cpp" target="_blank">https://github.com/kharchenkolab/N2R/blob/master/src/n2knn.cpp</a><br>I still get this error. <br><br>What's difficult for me is that it's only RcppEigen code, so I'm finding it a bit difficult to trace back where the issue is. <br><br>I guess the next step could be explicitly made every 'int' in the /src int64_t...</div><div dir="ltr"><br></div><div>I'd also be very welcome to disable code for 32-bit systems, if CRAN would allow this. I think a warning message suggesting developers no longer support this is entirely appropriate. :)</div><div><br></div><div>Best, Evan</div><div dir="ltr"><br><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Sep 19, 2020 at 6:25 PM Dirk Eddelbuettel <<a href="mailto:edd@debian.org" target="_blank">edd@debian.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
Evan,<br>
<br>
As you posted a link to the repo, I took a look -- given my recent work on<br>
RcppSpdlog this was of obvious interest.<br>
<br>
Now, as I understand it, you are fighting two battles here:<br>
<br>
1. You get an R CMD check warning on use of stderr. That is understandable as<br>
you included _upstream_ spdlog. It will do that. Once you instrument it the<br>
way RcppSpdlog does, this issue goes away.  The change is minimal as we can<br>
simply create the 'r_sink_mt' instance we need in the Hnsw constructor. I<br>
will send you a PR for that in a minute.<br>
<br>
2. The 32bit issue. I have not yet looked into this but it might be best to<br>
disentangle this.  As I mentioned, _maybe_ we need to switch to int64_t<br>
use. Very very worst case you could simply disable the code via #define and<br>
state that 'legacy systems' will no longer be supported ;-).  I am<br>
half-kidding here but it is an option. Nobody is running your genomics<br>
workload on systems from 15 years ago so ...<br>
<br>
Cheers, Dirk<br>
<br>
-- <br>
<a href="https://dirk.eddelbuettel.com" rel="noreferrer" target="_blank">https://dirk.eddelbuettel.com</a> | @eddelbuettel | <a href="mailto:edd@debian.org" target="_blank">edd@debian.org</a><br>
</blockquote></div></div>
</blockquote></div>