>
> Not exactly "minimally reproducible". Do tell beforehand than cloning the
> repo will suck down 300+ megabytes. And that you have build requirements for
> other packages exotic enough that they are NOT met by the reverse depends of
> the now almost 1100 packages I test against. Not nice. And after I wasted
> all that time it STILL failed because you have an unsatisfiable depends in
> 'rwind'. Did you mean rWind?
I really have to fill the page with apologies. Please, forgive me for the
trouble. I feel like I've been beaten to death whenever I get an answer from
Dirk :) But I’m ok with this. This makes me think twice before sending an email
before. You are right. Next question WILL definetely have a minimally
reproducible example. I also understood that I need to decrease the number of
packages that the package depends on.
> Lastly, and regarding the warning of being unable to parse your 'Infinity'
> argument, we have had the following segment in Section 2.2 of the vignette
> 'Rcpp Attributes' for years:
>
> Not all \proglang{C++} default argument values can be parsed into their
> \proglang{R} equivalents, however the most common cases are supported,
> including:
>
> Not all C++ default argument values can be parsed into their R equivalents,
> however
> the most common cases are supported, including:
> • String literals delimited by quotes (e.g. "foo")
> • Decimal numeric values (e.g. 10 or 4.5)
> • Pre-defined constants including true, false, R_NilValue, NA_STRING,
> NA_INTEGER,
> NA_REAL, and NA_LOGICAL.
> • Selected vector types (CharacterVector, IntegerVector, and NumericVector)
> instantiated
> using the ::create static member function.
> • Matrix types instantiated using the rows, cols constructor.
>
> So your use case was out of scope. You could set the default to NA_REAL and
> then (conditionally) replace that value inside the function.
I really thank you for the extra deep investigation and comments. I was aware
of the warnings but ignored them for a while. I need to make a balance between
writing pretty code and main research progress. That’s why the code and design
are messy for now. I hope to publish it on CRAN when it is mature enough.
>
> One of your other problems is that you mix twenty-eight generated function
> interfaces (via the Rcpp::exports() tag, the recommended approach) with the
> very old-school approach of two remaining manual .Call() in your R/hef.R.
>
> That conflicts with us now using underscores, as the symbol name still used
> by you in .Call() now also needs the underscore.
>
> That is not a battle we can win: either we try to help everybody by 'hiding'
> unexported symbols by prefixing with an underscore, or allow random mixing of
> Rcpp Attributes with .Call. I prefer the former.
This was the source of error I figured out an half hour after I sent the e-mail
(Silly me!). You are making a great package to integrate C++ easily into R
which is a complex task. This tempts people (who know or don’t know C++) to use
C++ in their projects and we moslty solve the issues searching by google but it
does not always give the best approach to the problem even if I try to find
newest ones. I always try to follow and use latest updates but this kind of old
approaches might remain in the code.
>
> Thanks for the report though. But next time, __please__ try to submit
> something __minimally reproducible__ and not a blob requiring the
> installation of 15 other packages and a download of 300mb.
I thank you for your help and apology for the trouble again.
best wishes,
Ismail SEZEN
_______________________________________________
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
