You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Utility for package exactextractr, which has non-exportable objects #768
Thanks for sharing. I'd love to add this to the list, but I'd probably need your help since I'm to well versed in the spatial field. What I need it a minimal reproducible example that illustrate the problem. Maybe some similar to the example for raster that results in:
@GatesDupont , I would need your help to come up with a tiny reproducible example that I can document. @dbaston, as the maintainer of exactextractr, would you be able to pitch in here?
@GatesDupont, just a friendly reminder about this one; if you can give me some small example code that allows me to reproduce the problem, I can begin documenting it. Without it, I cannot add any documentation.
@sigmafelix, @kyle-messier, because of your work on https://github.com/ropensci/chopin/, is this small issue something you could help out with? I'm looking for a teeny example for creating a exactextractr object, which I understand cannot be exported to a parallel worker as-is.
externalptr comes from raster or terra dependency. To note, exactextractr::exact_extract() returns one of vector, data.frame, or list object depending on argument values. x argument should be one of RasterBrick, RasterLayer, RasterStack (of raster package, superseded by terra) or RasterLayer (of terra package), and I found some of which cannot be exported to parallel workers under multisession and cluster plans in future. multicore plan can access any of these class objects since it relies on shared memory. It repeats the list of non-exportable objects.
My reproducible examples below demonstrate that SpatRaster in terra with multisession plan failed with a memory reference error. The objects related to raster package did not make errors; presumably, all of RasterLayer or RasterBrick objects were not actually externalptr.
Activity
HenrikBengtsson commentedon Feb 23, 2025
Thanks for sharing. I'd love to add this to the list, but I'd probably need your help since I'm to well versed in the spatial field. What I need it a minimal reproducible example that illustrate the problem. Maybe some similar to the example for raster that results in:
HenrikBengtsson commentedon Mar 12, 2025
@GatesDupont , I would need your help to come up with a tiny reproducible example that I can document. @dbaston, as the maintainer of exactextractr, would you be able to pitch in here?
HenrikBengtsson commentedon Apr 24, 2025
@GatesDupont, just a friendly reminder about this one; if you can give me some small example code that allows me to reproduce the problem, I can begin documenting it. Without it, I cannot add any documentation.
HenrikBengtsson commentedon Jul 13, 2025
@sigmafelix, @kyle-messier, because of your work on https://github.com/ropensci/chopin/, is this small issue something you could help out with? I'm looking for a teeny example for creating a
exactextractrobject, which I understand cannot be exported to a parallel worker as-is.sigmafelix commentedon Jul 13, 2025
@GatesDupont @HenrikBengtsson
externalptrcomes fromrasterorterradependency. To note,exactextractr::exact_extract()returns one ofvector,data.frame, orlistobject depending on argument values.xargument should be one ofRasterBrick,RasterLayer,RasterStack(ofrasterpackage, superseded byterra) orRasterLayer(ofterrapackage), and I found some of which cannot be exported to parallel workers undermultisessionandclusterplans infuture.multicoreplan can access any of these class objects since it relies on shared memory. It repeats the list of non-exportable objects.My reproducible examples below demonstrate that
SpatRasterinterrawithmultisessionplan failed with a memory reference error. The objects related torasterpackage did not make errors; presumably, all ofRasterLayerorRasterBrickobjects were not actuallyexternalptr.