Open jeffreyevans opened 4 years ago
@jeffreyevans I think here you can find a different email address and contact info:
https://icr.ethz.ch/people/hunziker/
it would be a pity to lose this package!
Lorenzo
@jeffreyevans
No, forget about the previous message - most probably outdated. I now tried contacting the mainteiner on linkedin at:
https://www.linkedin.com/in/hunzikp/
, though unfortunately his contact info does not include an email address.
HTH
Does anybody knows what was the issue?
Here's the snapshot of the CRAN checks from just before the package was archived:
https://cran-archive.r-project.org/web/checks/2020/2020-03-17_check_results_velox.html
I could easily fix it. But if the maintainer is not responding this won't be useful.
Gotcha. Thanks for taking a look! Is there a means for someone else to take over maintainer duties, or does the original maintainer have to approve first?
We cannot submit a fix on CRAN for the maintainer. He could agree for transferring the role of maintainer to somebody else. But for that we need to get in touch with the current maintainer.
Hello all,
I received a nice email from Philipp Hunziker (included below) regarding this issue. His current email is hunzikp@gmail.commailto:hunzikp@gmail.com. It sounds like he is not intending on maintaining the package any longer but, is more than willing to turn over maintenance to anybody that wants to take the package over. I should point out that I moved the velox
dependency to the exactextractr
(https://github.com/isciences/exactextractr and on CRAN) package which, not only benchmarks better than velox
, but does not require any object coercion to a different object class. In the case of large spatial-temporal data I have found velox
coercion to add quite a bit of overhead. The exactextractr
package is intended for only extracting raster values and does not provide rasterization functionality. For this, I use the fasterize
(https://github.com/ecohealthalliance/fasterize and on CRAN) package, which has also recently updated its C code to work under C++17 compiler requirements. Both of these packages require a sf
class object but are easily coercible to sp
classes using x <- methods::as(x, "Spatial")
.
Currently, the exactextractr
package only operates on polygons but, I have had some correspondence with the developer and he is planning on adding support for points and lines. After benchmarking, we found that operating on the the raw value list object that exactextractr:: exactextractr
outputs is much faster than using the internal function argument for outputting statistics. This is likely because we are using apply type functions and not for loops or operating in the tidyverse.
Best, Jeffrey Evans
Jeffrey S. Evans, Ph.D., | Senior Landscape Ecologist & Biometrician The Nature Conservancy | Protected Lands Science Visiting Professor | University of Wyoming | Zoology & Physology Laramie, WY | jeffrey_evans@tnc.orgmailto:jeffrey_evans@tnc.org | (970) 672-6766<tel:(970)%20672-6766>
Hi folks,
Hope you're doing well!
Sorry for not being on top of this sooner. As you might have guessed, I'm not actively maintaining velox anymore (and the gmail autofilter grouped these mails as a newsletter, so I just noticed them).
At this point we have two options: (1) I can try to get the code to a point where it passes the checks next weekend. Judging from the warnings this should be possible with reasonable effort, but I have very limited time on my hands, so there's a risk I won't make it before March 17th. (2) I'd be happy to give either of you co-ownership of the package and let you have a go at a fix. Let me know if you'd like to do that.
Cheers (and sorry again for the late reply!), Phil
On Tue, Mar 3, 2020 at 4:32 PM Kurt Hornik Kurt.Hornik@r-project.org<mailto:Kurt.Hornik@r-project.org> wrote: Dear maintainers,
This concerns the CRAN packages
GeNetIt amt spatialEco velox
maintained by one of you:
Jeffrey S. Evans jeffrey_evans@tnc.org<mailto:jeffrey_evans@tnc.org>: GeNetIt spatialEco Johannes Signer jsigner@gwdg.de<mailto:jsigner@gwdg.de>: amt Philipp Hunziker hunzikp@gmail.com<mailto:hunzikp@gmail.com>: velox
We have repeatedly asked for an update fixing the check problems shown on https://cran.r-project.org/web/checks/check_results_velox.html<https://cran.r-project.org/web/checks/check_results_velox.html> with no reply from the maintainer thus far.
Thus, package velox is now scheduled for archival on 2020-03-17, and archiving this will necessitate also archiving its strong reverse dependencies.
Please negotiate the necessary actions.
Philipp Hunziker
From: Jean-Romain notifications@github.com Sent: Thursday, March 26, 2020 11:11 AM To: hunzikp/velox velox@noreply.github.com Cc: Jeffrey Evans jeffrey_evans@TNC.ORG; Mention mention@noreply.github.com Subject: Re: [hunzikp/velox] CRAN archive notification (#43)
We cannot submit a fix on CRAN for the maintainer. He could agree for transferring the role of maintainer to somebody else. But for that we need to get in touch with the current maintainer.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/hunzikp/velox/issues/43#issuecomment-604554600, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACLKH74NCZLZV2FHID6NMYTRJOEA7ANCNFSM4LAOMD2Q.
I can fix it. Then he will only need to accept the PR resubmit the package.
Hey @Jean-Romain did you happen to ever take this over? We have a bunch of scripts that are based on velox and I'm debating the effort to migrate them over versus just waiting a few weeks
I waiting for a validation from the author (or somebody in contact with him). I won't spent time on that if my PR won't be accepted because the author no longer check github and won't release the fix.
@cjcarlson: Can you install from GitHub and have it work, or are the failing CRAN checks relevant for your OS? (remotes::install_github("hunzikp/velox@master")
) Is this COVID work and would you deem it critical? In which case I'll ask on your behalf whether @Jean-Romain might reconsider patching the package so it can at least be installed via his GitHub repository, but only if he has the bandwidth for it. Colin, please kibosh this request if I'm off base with it.
The problem is not a serious issue. It is a C++ compiler warning to protect against not fully explicit way to copy the memory. It does not affect the package itself. The code should be written differently but the code does what it is expected to do. So the package is still workable but the CRAN takes very seriously every warnings.
Good news is (thank god) this isn't for COVID, no.
I've tried to install_github with devtools before and it's been failing. Hadn't thought to try using remotes, and sure enough, it looks like it works for now. Let me double-check whether it works across machines just as a precaution! But that was a good shout, thanks @mikoontz
I should point out that devtools has been split out into a few packages, remotes being one of them. The install_github
in devtools is actually coming from remotes (where the function now lives). I have found that sometimes the function forwarding fails when called from devtools so, a good practice is the call the function directly from remotes.
Best, Jeff
Jeffrey S. Evans, Ph.D., | Senior Landscape Ecologist & Biometrician The Nature Conservancy | Protected Lands Science Visiting Professor | University of Wyoming | Zoology & Physology Laramie, WY | jeffrey_evans@tnc.orgmailto:jeffrey_evans@tnc.org | (970) 672-6766<tel:(970)%20672-6766>
From: Colin J. Carlson notifications@github.com Sent: Saturday, April 4, 2020 12:29 PM To: hunzikp/velox velox@noreply.github.com Cc: Jeffrey Evans jeffrey_evans@TNC.ORG; Mention mention@noreply.github.com Subject: Re: [hunzikp/velox] CRAN archive notification (#43)
Good news is (thank god) this isn't for COVID, no.
I've tried to install_github with devtools before and it's been failing. Hadn't thought to try using remotes, and sure enough, it looks like it works for now. Let me double-check whether it works across machines just as a precaution! But that was a good shout, thanks @mikoontzhttps://github.com/mikoontz
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/hunzikp/velox/issues/43#issuecomment-609070310, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACLKH7ZQOITB5XHWWWQA3MDRK54AHANCNFSM4LAOMD2Q.
Sorry, strike that comment about install_github in devtools/remotes. In the current versions, it looks like they have now just replicated the function in both packages. Previously, calling install_github from devtools just passed the function arguments to remotes::install_github. Not sure why they changed it because Hadley is trying to split out specific functionality to each individual package rather than having devtools be a catch all. If you look at the two package calls they are the identical function devtools:: install_github or remotes::install_github
From: Colin J. Carlson notifications@github.com Sent: Saturday, April 4, 2020 12:29 PM To: hunzikp/velox velox@noreply.github.com Cc: Jeffrey Evans jeffrey_evans@TNC.ORG; Mention mention@noreply.github.com Subject: Re: [hunzikp/velox] CRAN archive notification (#43)
Good news is (thank god) this isn't for COVID, no.
I've tried to install_github with devtools before and it's been failing. Hadn't thought to try using remotes, and sure enough, it looks like it works for now. Let me double-check whether it works across machines just as a precaution! But that was a good shout, thanks @mikoontzhttps://github.com/mikoontz
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/hunzikp/velox/issues/43#issuecomment-609070310, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACLKH7ZQOITB5XHWWWQA3MDRK54AHANCNFSM4LAOMD2Q.
Huh! Maybe it's a machine difference. I'll keep tinkering, in that case.
Another possibility is installing the archived CRAN version using devtools::install_version():
devtools::install_version("velox", version = "0.2.0")
Hey folks, package author and (former) maintainer checking in. Sorry for not being on top of this. @Jean-Romain if you'd be able to make the changes to ensure we can reupload to CRAN, that'd be amazing. I'd also be more happy to give you authorship on the package. The same applies to anyone else wanting to pitch in. Since my email has already been posted here publicly, feel free to reach out: hunzikp [at] gmail [dot] com.
Just wondering: any advances on this issue?
This package is no longer being maintained and the author has moved on to other things. For fast raster extraction I would reccomend using the exact_extract function in exactextractr package.
Sent from Outlook Mobilehttps://aka.ms/blhgte
From: Thiago V. dos Santos notifications@github.com Sent: Monday, June 15, 2020 6:29:44 PM To: hunzikp/velox velox@noreply.github.com Cc: Jeffrey Evans jeffrey_evans@TNC.ORG; Mention mention@noreply.github.com Subject: Re: [hunzikp/velox] CRAN archive notification (#43)
Just wondering: any advances on this issue?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/hunzikp/velox/issues/43#issuecomment-644459982, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACLKH7ZAOQBZWWAA7AVMQT3RW24HRANCNFSM4LAOMD2Q.
This package is no longer being maintained and the author has moved on to other things. For fast raster extraction I would reccomend using the exact_extract function in exactextractr package. Sent from Outlook Mobilehttps://aka.ms/blhgte …
Such a pity... I thought someone would take over the development/maintenance of the package.
Any recommendations for faster raster cropping/masking operations using polygons? raster
is a good, reliable tool in like 95% of the times, but sometimes my workflow is really bottlenecked by its cropping/masking capabilities...
I made a PR to fix velox. See https://github.com/hunzikp/velox/pull/48
Bad new. The package was removed based on warning on Linux and Windows. The problems are gone on Linux but I checked on Windows and are still present. Troubleshooting are coming from boost
and cannot be fixed easily. The code sounds legit and CRAN is maybe too aggressive on its check. Because it is not allowed to change compilation directives I don't think I can do anything. I suspect an issue with gcc 8 specifically
Does anybody know how to contact the author of this package? He is being unresponsive to issue requests on GitHub and not responding to CRAN regarding check errors. CRAN maintainers are getting ready to archive the velox package from the repositories.
From CRAN "We have repeatedly asked for an update fixing the check problems with no reply from the maintainer thus far. Thus, package velox is now scheduled for archival on 2020-03-17, and archiving this will necessitate also archiving its strong reverse dependencies."