Comments (188)
bkandel
commented on August 30, 2024
I thought the major issue with CRAN was the size of the package. Did you
find a way to work around that?
On 26 January 2015 at 10:32, stnava [email protected] wrote:
@ntustison https://github.com/ntustison , @bkandel
https://github.com/bkandel , @dorianps https://github.com/dorianps,
@jeffduda https://github.com/jeffduda , @cookpa
https://github.com/cookpa , @armaneshaghi
https://github.com/armaneshaghi, @muschellij2
https://github.com/muschellij2hoping to work toward a CRAN submission for ANTsR - some updates on this
topic:i ran rd2roxygen and dealt with most of the issues. hopefully wont have
to do that again ... so, in the future, we should write documentation
using the roxygen2 style and just roxygenize() regularly.
a couple other changes
enabled plot( antsImage ) so we dont need to type plotANTsImage
added resampleImage
updated invariantImageSimilarity to use reflection as well as
rotation, only tested in 2D so faradded CreateJacobianDeterminantImage
added a simple kmeansSegmentation filter ...
would like to start running R CMD CHECK and get failures to a minimum
...need to write a quick vignette, possibly based on the README.md ...
@muschellij2 https://github.com/muschellij2 - would appreciated any
advice / help on this ....some advice from wickham:
http://www.rstudio.com/products/rpackages/devtools/it's a very good page with strategies that will help with most of the
issues we've had in the past ...any thoughts appreciated.
—
Reply to this email directly or view it on GitHub
#8.
from antsr.
armaneshaghi
commented on August 30, 2024
Brian, this is an excellent idea, and really essential for the whole community. I know R and Cpp both very well, but I have been involved only in ANTs development, and not ANTsR and would appreciate if you could give me pointers where you need help.
from antsr.
armaneshaghi
commented on August 30, 2024
Perhaps by assigning something (more specifically)
from antsr.
stnava
commented on August 30, 2024
cran policies are here
100MB is the limit which ANTsR just sneaks under (last i checked) after R
CMD Build
the package must pass on 2 platforms ( e.g. linux , osx ) for CRAN
acceptance ...
compile time might be an issue but this can likely be resolved by making
a thin ANTs build that focuses on only the programs necessary for ANTsR
... this could be done within a new ANTs branch that gets updated as needed.
i still see install_github or R CMD INSTALL being the way we employ ANTsR
but, for broader use, CRAN would be great. so hopefully we would branch
to thin ANTs only occasionally ... primarily, it would be a change to one
or maybe two CMakeLists.txt files ...
ref issue thin ants
brian
On Mon, Jan 26, 2015 at 10:43 AM, bkandel [email protected] wrote:
I thought the major issue with CRAN was the size of the package. Did you
find a way to work around that?On 26 January 2015 at 10:32, stnava [email protected] wrote:
@ntustison https://github.com/ntustison , @bkandel
https://github.com/bkandel , @dorianps https://github.com/dorianps,
@jeffduda https://github.com/jeffduda , @cookpa
https://github.com/cookpa , @armaneshaghi
https://github.com/armaneshaghi, @muschellij2
https://github.com/muschellij2hoping to work toward a CRAN submission for ANTsR - some updates on this
topic:i ran rd2roxygen and dealt with most of the issues. hopefully wont have
to do that again ... so, in the future, we should write documentation
using the roxygen2 style and just roxygenize() regularly.
a couple other changes
enabled plot( antsImage ) so we dont need to type plotANTsImage
added resampleImage
updated invariantImageSimilarity to use reflection as well as
rotation, only tested in 2D so far
added CreateJacobianDeterminantImage
added a simple kmeansSegmentation filter ...
would like to start running R CMD CHECK and get failures to a minimum
...
need to write a quick vignette, possibly based on the README.md ...
@muschellij2 https://github.com/muschellij2 - would appreciated any
advice / help on this ....some advice from wickham:
http://www.rstudio.com/products/rpackages/devtools/it's a very good page with strategies that will help with most of the
issues we've had in the past ...any thoughts appreciated.
—
Reply to this email directly or view it on GitHub
#8.—
Reply to this email directly or view it on GitHub
#8 (comment).
from antsr.
stnava
commented on August 30, 2024
oops - just checked latest R CMD Build & it's quite large ... easy to
resolve with some carefully crafted rm calls ... will assign myself to that.
brian
On Mon, Jan 26, 2015 at 11:12 AM, brian avants [email protected] wrote:
cran policies are here
100MB is the limit which ANTsR just sneaks under (last i checked) after R
CMD Buildthe package must pass on 2 platforms ( e.g. linux , osx ) for CRAN
acceptance ...compile time might be an issue but this can likely be resolved by making
a thin ANTs build that focuses on only the programs necessary for ANTsR
... this could be done within a new ANTs branch that gets updated as needed.i still see install_github or R CMD INSTALL being the way we employ ANTsR
but, for broader use, CRAN would be great. so hopefully we would branch
to thin ANTs only occasionally ... primarily, it would be a change to one
or maybe two CMakeLists.txt files ...ref issue thin ants
brian
On Mon, Jan 26, 2015 at 10:43 AM, bkandel [email protected]
wrote:I thought the major issue with CRAN was the size of the package. Did you
find a way to work around that?On 26 January 2015 at 10:32, stnava [email protected] wrote:
@ntustison https://github.com/ntustison , @bkandel
https://github.com/bkandel , @dorianps https://github.com/dorianps,@jeffduda https://github.com/jeffduda , @cookpa
https://github.com/cookpa , @armaneshaghi
https://github.com/armaneshaghi, @muschellij2
https://github.com/muschellij2hoping to work toward a CRAN submission for ANTsR - some updates on
this
topic:i ran rd2roxygen and dealt with most of the issues. hopefully wont have
to do that again ... so, in the future, we should write documentation
using the roxygen2 style and just roxygenize() regularly.
a couple other changes
enabled plot( antsImage ) so we dont need to type plotANTsImage
added resampleImage
updated invariantImageSimilarity to use reflection as well as
rotation, only tested in 2D so far
added CreateJacobianDeterminantImage
added a simple kmeansSegmentation filter ...
would like to start running R CMD CHECK and get failures to a minimum
...
need to write a quick vignette, possibly based on the README.md ...
@muschellij2 https://github.com/muschellij2 - would appreciated any
advice / help on this ....some advice from wickham:
http://www.rstudio.com/products/rpackages/devtools/it's a very good page with strategies that will help with most of the
issues we've had in the past ...any thoughts appreciated.
—
Reply to this email directly or view it on GitHub
#8.—
Reply to this email directly or view it on GitHub
#8 (comment).
from antsr.
bkandel
commented on August 30, 2024
100 MB sounds ambitious to me if we're going to include ITK build--in my
current ANTsR build, the ITKv4-build dir alone is 392MB. I imagine that
most of this can be deleted safely, though, once ANTs is installed.
On 26 January 2015 at 11:16, stnava [email protected] wrote:
oops - just checked latest R CMD Build & it's quite large ... easy to
resolve with some carefully crafted rm calls ... will assign myself to
that.brian
On Mon, Jan 26, 2015 at 11:12 AM, brian avants [email protected] wrote:
cran policies are here
100MB is the limit which ANTsR just sneaks under (last i checked) after
R
CMD Buildthe package must pass on 2 platforms ( e.g. linux , osx ) for CRAN
acceptance ...compile time might be an issue but this can likely be resolved by
making
a thin ANTs build that focuses on only the programs necessary for
ANTsR
... this could be done within a new ANTs branch that gets updated as
needed.i still see install_github or R CMD INSTALL being the way we employ
ANTsR
but, for broader use, CRAN would be great. so hopefully we would branch
to thin ANTs only occasionally ... primarily, it would be a change to
one
or maybe two CMakeLists.txt files ...ref issue thin ants
brian
On Mon, Jan 26, 2015 at 10:43 AM, bkandel [email protected]
wrote:I thought the major issue with CRAN was the size of the package. Did
you
find a way to work around that?On 26 January 2015 at 10:32, stnava [email protected] wrote:
@ntustison https://github.com/ntustison , @bkandel
https://github.com/bkandel , @dorianps https://github.com/dorianps,@jeffduda https://github.com/jeffduda , @cookpa
https://github.com/cookpa , @armaneshaghi
https://github.com/armaneshaghi, @muschellij2
https://github.com/muschellij2hoping to work toward a CRAN submission for ANTsR - some updates on
this
topic:i ran rd2roxygen and dealt with most of the issues. hopefully wont
haveto do that again ... so, in the future, we should write documentation
using the roxygen2 style and just roxygenize() regularly.
a couple other changes
enabled plot( antsImage ) so we dont need to type plotANTsImage
added resampleImage
updated invariantImageSimilarity to use reflection as well as
rotation, only tested in 2D so far
added CreateJacobianDeterminantImage
added a simple kmeansSegmentation filter ...
would like to start running R CMD CHECK and get failures to a minimum
...
need to write a quick vignette, possibly based on the README.md ...
@muschellij2 https://github.com/muschellij2 - would appreciated
any
advice / help on this ....some advice from wickham:
http://www.rstudio.com/products/rpackages/devtools/it's a very good page with strategies that will help with most of the
issues we've had in the past ...any thoughts appreciated.
—
Reply to this email directly or view it on GitHub
#8.—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).
from antsr.
stnava
commented on August 30, 2024
ANTsR.so is the main indicator and it's currently around 77MB
brian
On Mon, Jan 26, 2015 at 11:24 AM, bkandel [email protected] wrote:
100 MB sounds ambitious to me if we're going to include ITK build--in my
current ANTsR build, the ITKv4-build dir alone is 392MB. I imagine that
most of this can be deleted safely, though, once ANTs is installed.On 26 January 2015 at 11:16, stnava [email protected] wrote:
oops - just checked latest R CMD Build & it's quite large ... easy to
resolve with some carefully crafted rm calls ... will assign myself to
that.brian
On Mon, Jan 26, 2015 at 11:12 AM, brian avants [email protected]
wrote:cran policies are here
100MB is the limit which ANTsR just sneaks under (last i checked)
after
R
CMD Buildthe package must pass on 2 platforms ( e.g. linux , osx ) for CRAN
acceptance ...compile time might be an issue but this can likely be resolved by
making
a thin ANTs build that focuses on only the programs necessary for
ANTsR
... this could be done within a new ANTs branch that gets updated as
needed.i still see install_github or R CMD INSTALL being the way we employ
ANTsR
but, for broader use, CRAN would be great. so hopefully we would
branch
to thin ANTs only occasionally ... primarily, it would be a change to
one
or maybe two CMakeLists.txt files ...ref issue thin ants
brian
On Mon, Jan 26, 2015 at 10:43 AM, bkandel [email protected]
wrote:I thought the major issue with CRAN was the size of the package. Did
you
find a way to work around that?On 26 January 2015 at 10:32, stnava [email protected]
wrote:@ntustison https://github.com/ntustison , @bkandel
https://github.com/bkandel , @dorianps <
https://github.com/dorianps>,@jeffduda https://github.com/jeffduda , @cookpa
https://github.com/cookpa , @armaneshaghi
https://github.com/armaneshaghi, @muschellij2
https://github.com/muschellij2hoping to work toward a CRAN submission for ANTsR - some updates on
this
topic:i ran rd2roxygen and dealt with most of the issues. hopefully wont
haveto do that again ... so, in the future, we should write
documentationusing the roxygen2 style and just roxygenize() regularly.
a couple other changes
enabled plot( antsImage ) so we dont need to type plotANTsImage
added resampleImage
updated invariantImageSimilarity to use reflection as well as
rotation, only tested in 2D so far
added CreateJacobianDeterminantImage
added a simple kmeansSegmentation filter ...
would like to start running R CMD CHECK and get failures to a
minimum...
need to write a quick vignette, possibly based on the README.md ...
@muschellij2 https://github.com/muschellij2 - would appreciated
any
advice / help on this ....some advice from wickham:
http://www.rstudio.com/products/rpackages/devtools/it's a very good page with strategies that will help with most of
the
issues we've had in the past ...any thoughts appreciated.
—
Reply to this email directly or view it on GitHub
#8.—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).
from antsr.
stnava
commented on August 30, 2024
http://cran.r-project.org/doc/manuals/r-release/R-exts.html#Configure-and-cleanup
brian
On Mon, Jan 26, 2015 at 11:28 AM, brian avants [email protected] wrote:
ANTsR.so is the main indicator and it's currently around 77MB
brian
On Mon, Jan 26, 2015 at 11:24 AM, bkandel [email protected]
wrote:100 MB sounds ambitious to me if we're going to include ITK build--in my
current ANTsR build, the ITKv4-build dir alone is 392MB. I imagine that
most of this can be deleted safely, though, once ANTs is installed.On 26 January 2015 at 11:16, stnava [email protected] wrote:
oops - just checked latest R CMD Build & it's quite large ... easy to
resolve with some carefully crafted rm calls ... will assign myself to
that.brian
On Mon, Jan 26, 2015 at 11:12 AM, brian avants [email protected]
wrote:cran policies are here
100MB is the limit which ANTsR just sneaks under (last i checked)
after
R
CMD Buildthe package must pass on 2 platforms ( e.g. linux , osx ) for CRAN
acceptance ...compile time might be an issue but this can likely be resolved by
making
a thin ANTs build that focuses on only the programs necessary for
ANTsR
... this could be done within a new ANTs branch that gets updated as
needed.i still see install_github or R CMD INSTALL being the way we employ
ANTsR
but, for broader use, CRAN would be great. so hopefully we would
branch
to thin ANTs only occasionally ... primarily, it would be a change to
one
or maybe two CMakeLists.txt files ...ref issue thin ants
brian
On Mon, Jan 26, 2015 at 10:43 AM, bkandel [email protected]
wrote:I thought the major issue with CRAN was the size of the package. Did
you
find a way to work around that?On 26 January 2015 at 10:32, stnava [email protected]
wrote:@ntustison https://github.com/ntustison , @bkandel
https://github.com/bkandel , @dorianps <
https://github.com/dorianps>,@jeffduda https://github.com/jeffduda , @cookpa
https://github.com/cookpa , @armaneshaghi
https://github.com/armaneshaghi, @muschellij2
https://github.com/muschellij2hoping to work toward a CRAN submission for ANTsR - some updates
on
this
topic:i ran rd2roxygen and dealt with most of the issues. hopefully wont
haveto do that again ... so, in the future, we should write
documentationusing the roxygen2 style and just roxygenize() regularly.
a couple other changes
enabled plot( antsImage ) so we dont need to type plotANTsImage
added resampleImage
updated invariantImageSimilarity to use reflection as well as
rotation, only tested in 2D so far
added CreateJacobianDeterminantImage
added a simple kmeansSegmentation filter ...
would like to start running R CMD CHECK and get failures to a
minimum...
need to write a quick vignette, possibly based on the README.md
...@muschellij2 https://github.com/muschellij2 - would appreciated
any
advice / help on this ....some advice from wickham:
http://www.rstudio.com/products/rpackages/devtools/it's a very good page with strategies that will help with most of
the
issues we've had in the past ...any thoughts appreciated.
—
Reply to this email directly or view it on GitHub
#8.—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).
from antsr.
jefferis
commented on August 30, 2024
Would be happy to see this on CRAN. Would there be any sense in producing an ITK only package. Could be useful for others and could help re space. Of course you could rely on system ITK but that would somewhat defeat the ease of use advantage of a CRAN package (on OS X one can have binary installs, which is convenient for many). Best,
Gregory Jefferis
On 26 Jan 2015, at 08:24, bkandel [email protected] wrote:
100 MB sounds ambitious to me if we're going to include ITK build--in my
current ANTsR build, the ITKv4-build dir alone is 392MB. I imagine that
most of this can be deleted safely, though, once ANTs is installed.On 26 January 2015 at 11:16, stnava [email protected] wrote:
oops - just checked latest R CMD Build & it's quite large ... easy to
resolve with some carefully crafted rm calls ... will assign myself to
that.brian
On Mon, Jan 26, 2015 at 11:12 AM, brian avants [email protected] wrote:
cran policies are here
100MB is the limit which ANTsR just sneaks under (last i checked) after
R
CMD Buildthe package must pass on 2 platforms ( e.g. linux , osx ) for CRAN
acceptance ...compile time might be an issue but this can likely be resolved by
making
a thin ANTs build that focuses on only the programs necessary for
ANTsR
... this could be done within a new ANTs branch that gets updated as
needed.i still see install_github or R CMD INSTALL being the way we employ
ANTsR
but, for broader use, CRAN would be great. so hopefully we would branch
to thin ANTs only occasionally ... primarily, it would be a change to
one
or maybe two CMakeLists.txt files ...ref issue thin ants
brian
On Mon, Jan 26, 2015 at 10:43 AM, bkandel [email protected]
wrote:I thought the major issue with CRAN was the size of the package. Did
you
find a way to work around that?On 26 January 2015 at 10:32, stnava [email protected] wrote:
@ntustison https://github.com/ntustison , @bkandel
https://github.com/bkandel , @dorianps https://github.com/dorianps,@jeffduda https://github.com/jeffduda , @cookpa
https://github.com/cookpa , @armaneshaghi
https://github.com/armaneshaghi, @muschellij2
https://github.com/muschellij2hoping to work toward a CRAN submission for ANTsR - some updates on
this
topic:i ran rd2roxygen and dealt with most of the issues. hopefully wont
haveto do that again ... so, in the future, we should write documentation
using the roxygen2 style and just roxygenize() regularly.
a couple other changes
enabled plot( antsImage ) so we dont need to type plotANTsImage
added resampleImage
updated invariantImageSimilarity to use reflection as well as
rotation, only tested in 2D so far
added CreateJacobianDeterminantImage
added a simple kmeansSegmentation filter ...
would like to start running R CMD CHECK and get failures to a minimum
...
need to write a quick vignette, possibly based on the README.md ...
@muschellij2 https://github.com/muschellij2 - would appreciated
any
advice / help on this ....some advice from wickham:
http://www.rstudio.com/products/rpackages/devtools/it's a very good page with strategies that will help with most of the
issues we've had in the past ...any thoughts appreciated.
—
Reply to this email directly or view it on GitHub
#8.—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub.
from antsr.
stnava
commented on August 30, 2024
yes - we have talked about that ... i do believe the right way to do this
is to have a CRAN RcppITK package (or whatever it is called) that might be
similar to Rcpp, RcppArmadillo, RcppEigen etc. its primary purpose would
be to make ITK libraries available s.t. projects like ANTsR might use them.
the primary obstacle is not so much technical but more so the burden of
maintaining two separate packages, test suites, documentation "parties",
etc ... however, with ants releases becoming more standardized, we might
hope to deal w/this in more streamlined fashion.
i cannot volunteer to make such a package but would be happy to assist /
build against such a package if it were created.
brian
On Mon, Jan 26, 2015 at 11:41 AM, Gregory Jefferis <[email protected]
wrote:
Would be happy to see this on CRAN. Would there be any sense in producing
an ITK only package. Could be useful for others and could help re space. Of
course you could rely on system ITK but that would somewhat defeat the ease
of use advantage of a CRAN package (on OS X one can have binary installs,
which is convenient for many). Best,Gregory Jefferis
On 26 Jan 2015, at 08:24, bkandel [email protected] wrote:
100 MB sounds ambitious to me if we're going to include ITK build--in my
current ANTsR build, the ITKv4-build dir alone is 392MB. I imagine that
most of this can be deleted safely, though, once ANTs is installed.On 26 January 2015 at 11:16, stnava [email protected] wrote:
oops - just checked latest R CMD Build & it's quite large ... easy to
resolve with some carefully crafted rm calls ... will assign myself to
that.brian
On Mon, Jan 26, 2015 at 11:12 AM, brian avants [email protected]
wrote:cran policies are here
100MB is the limit which ANTsR just sneaks under (last i checked)
after
R
CMD Buildthe package must pass on 2 platforms ( e.g. linux , osx ) for CRAN
acceptance ...compile time might be an issue but this can likely be resolved by
making
a thin ANTs build that focuses on only the programs necessary for
ANTsR
... this could be done within a new ANTs branch that gets updated as
needed.i still see install_github or R CMD INSTALL being the way we employ
ANTsR
but, for broader use, CRAN would be great. so hopefully we would
branch
to thin ANTs only occasionally ... primarily, it would be a change
to
one
or maybe two CMakeLists.txt files ...ref issue thin ants
brian
On Mon, Jan 26, 2015 at 10:43 AM, bkandel [email protected]
wrote:
I thought the major issue with CRAN was the size of the package.
Did
you
find a way to work around that?On 26 January 2015 at 10:32, stnava [email protected]
wrote:@ntustison https://github.com/ntustison , @bkandel
https://github.com/bkandel , @dorianps <
https://github.com/dorianps>,@jeffduda https://github.com/jeffduda , @cookpa
https://github.com/cookpa , @armaneshaghi
https://github.com/armaneshaghi, @muschellij2
https://github.com/muschellij2hoping to work toward a CRAN submission for ANTsR - some updates
on
this
topic:i ran rd2roxygen and dealt with most of the issues. hopefully
wont
haveto do that again ... so, in the future, we should write
documentationusing the roxygen2 style and just roxygenize() regularly.
a couple other changes
enabled plot( antsImage ) so we dont need to type plotANTsImage
added resampleImage
updated invariantImageSimilarity to use reflection as well as
rotation, only tested in 2D so far
added CreateJacobianDeterminantImage
added a simple kmeansSegmentation filter ...
would like to start running R CMD CHECK and get failures to a
minimum...
need to write a quick vignette, possibly based on the README.md
...@muschellij2 https://github.com/muschellij2 - would
appreciated
any
advice / help on this ....some advice from wickham:
http://www.rstudio.com/products/rpackages/devtools/it's a very good page with strategies that will help with most of
the
issues we've had in the past ...any thoughts appreciated.
—
Reply to this email directly or view it on GitHub
#8.—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub.—
Reply to this email directly or view it on GitHub
#8 (comment).
from antsr.
stnava
commented on August 30, 2024
am working on R cmd check ... here is the procedure that i am using (likely to be refined in the future)
- R CMD INSTALL ANTsR # to a custom library location
- R CMD build ANTsR
- R CMD check ANTsR_1.0.tar.gz --library=~/code/RLibs/ --no-install
after this passes (does not yet) will try vanilla and as-cran flags
this procedure lets you build the c++ once and then check the documentation / R examples - several issues arise at this stage which need to be dealt with manually. here you iterate this procedure:
- make manual changes
- R CMD INSTALL ANTsR # to custom location
- R CMD check ANTsR_1.0.tar.gz --library=~/code/RLibs/ --no-install
until R CMD check issues are eliminated ....
one way to speed up checking examples is to directly run .R file called ANTsR-Ex.R that is generated by R cmd check ....
from antsr.
stnava
commented on August 30, 2024
@ntustison , @bkandel , @dorianps, @jeffduda , @cookpa
substantial progress towards passing R cmd check ... it's not there yet but i eliminated several "mysterious" warnings, notes and the like and fixed many documentation issues. also removed what i thought was dead code. in the future, it would be very helpful if we could adhere to documenting everything that goes into the main branch of antsr. if you want to do some test development, please do so on a repository branch. by doing this, we can avoid getting into the current situation described below.
the current R cmd check produces 2 warnings. one is for undocumented functions (mostly helper functions and dead code) and one for inconsistent documentation (should be resolvable with roxygen2's help but must be done manually). the list of issues is below - i will whittle away at these and would appreciate if you would help with any of these as you get time:
undocumented functions - will remove these when possible
‘ExtractDenseNetwork’ ‘LabelClustersUniquely’ ‘LabelGeometryMeasures’
‘LabelImageCentroids’ ‘N4BiasFieldCorrection’ ‘SummarizeClusters’
‘TileImages’ ‘antsAffineInitializer’ ‘antsBOLDNetworkAnalysis’
‘antsCopyImageInfo’ ‘antsGetDirection’ ‘antsGetOrigin’
‘antsGetPixels’ ‘antsGetSpacing’ ‘antsImagePair’
‘antsMotionCorrStats’ ‘antsSetDirection’ ‘antsSetOrigin’
‘antsSetPixels’ ‘antsSetSpacing’ ‘antsTransformIndexToPhysicalPoint’
‘antsTransformPhysicalPointToIndex’ ‘ants_brain_extraction’
‘ants_motion_estimation’ ‘ants_to_template’ ‘antsrGetPointerName’
‘antsrParseListToString’ ‘antsrParseListToString2’
‘antsr_frequency_filter’ ‘antsr_resting_state_corr_eigenanat’
‘antsrmakeRandomString’ ‘arCorrection’ ‘as.data.frame.antsMatrix’
‘as.list.antsMatrix’ ‘binarizeSNPs’ ‘computeDVARS’ ‘conjGradS’
‘cosineDist’ ‘diffmat’ ‘eanatcolMaxs’ ‘eanatsparsify’
‘eanatsparsifyv’ ‘filterPASLforNetworkAnalysis’ ‘getANTsRData’
‘getNetwork’ ‘getValueAtPoint’ ‘get_perfusion_predictors’
‘getvertices’ ‘int_antsProcessArguments’ ‘labels2matrix’
‘labels2vector’ ‘largeScaleCommunity’ ‘lowrank’ ‘lowrankRowMatrix’
‘makeDiffGraph’ ‘makefacet’ ‘makestl’ ‘matrix2timeseries’ ‘matrixSeg’
‘mergeLabels’ ‘motion_correction’ ‘networkCorrelation’
‘networkCovariance’ ‘networkOverlap’ ‘plot.antsImage’ ‘plotNetwork’
‘quantifySNPs’ ‘reduceNetwork’ ‘sliceTimingCorrection’ ‘snapColors’
undocumented arguments - will also remove these when possible or fix by hand
00check.log:Undocumented arguments in documentation object 'Atropos'
00check.log:Undocumented arguments in documentation object 'CreateJacobianDeterminantImage'
00check.log:Undocumented arguments in documentation object 'ImageMath'
00check.log:Undocumented arguments in documentation object 'KellyKapowski'
00check.log:Undocumented arguments in documentation object 'MeasureMinMaxMean'
00check.log:Undocumented arguments in documentation object 'N3BiasFieldCorrection'
00check.log:Undocumented arguments in documentation object 'SmoothImage'
00check.log:Undocumented arguments in documentation object 'ThresholdImage'
00check.log:Undocumented arguments in documentation object 'abpBrainExtraction'
00check.log:Undocumented arguments in documentation object 'abpN4'
00check.log:Undocumented arguments in documentation object 'antsApplyTransforms'
00check.log:Undocumented arguments in documentation object 'antsGetNeighborhood'
00check.log:Undocumented arguments in documentation object 'antsImageMutualInformation'
00check.log:Undocumented arguments in documentation object 'antsMotionCorr'
00check.log:Undocumented arguments in documentation object 'antsPreprocessfMRI'
00check.log:Undocumented arguments in documentation object 'antsRegistration'
00check.log:Undocumented arguments in documentation object 'aslDenoiseR'
00check.log:Undocumented arguments in documentation object 'aslPerfusion'
00check.log:Undocumented arguments in documentation object 'bayesianCBF'
00check.log:Undocumented arguments in documentation object 'bayesianlm'
00check.log:Undocumented arguments in documentation object 'clusterTimeSeries'
00check.log:Undocumented arguments in documentation object 'compcor'
00check.log:Undocumented arguments in documentation object 'corw'
00check.log:Undocumented arguments in documentation object 'eigSeg'
00check.log:Undocumented arguments in documentation object 'fastwhiten'
00check.log:Undocumented arguments in documentation object 'filterfMRIforNetworkAnalysis'
00check.log:Undocumented arguments in documentation object 'frequencyFilterfMRI'
00check.log:Undocumented arguments in documentation object 'getAverageOfTimeSeries'
00check.log:Undocumented arguments in documentation object 'getCentroids'
00check.log:Undocumented arguments in documentation object 'getMultivariateTemplateCoordinates'
00check.log:Undocumented arguments in documentation object 'getROIValues'
00check.log:Undocumented arguments in documentation object 'getTemplateCoordinates'
00check.log:Undocumented arguments in documentation object 'getfMRInuisanceVariables'
00check.log:Undocumented arguments in documentation object 'icawhiten'
00check.log:Undocumented arguments in documentation object 'image2ClusterImages'
00check.log:Undocumented arguments in documentation object 'imageFileNames2ImageList'
00check.log:Undocumented arguments in documentation object 'initializeEigenanatomy'
00check.log:Undocumented arguments in documentation object 'inspectImageData3D'
00check.log:Undocumented arguments in documentation object 'interleaveMatrixWithItself'
00check.log:Undocumented arguments in documentation object 'invariantImageSimilarity'
00check.log:Undocumented arguments in documentation object 'joinEigenanatomy'
00check.log:Undocumented arguments in documentation object 'kmeansSegmentation'
00check.log:Undocumented arguments in documentation object 'labelClusters'
00check.log:Undocumented arguments in documentation object 'lappend'
00check.log:Undocumented arguments in documentation object 'makeGraph'
00check.log:Undocumented arguments in documentation object 'makeImage'
00check.log:Undocumented arguments in documentation object 'mni2tal'
00check.log:Undocumented arguments in documentation object 'networkEiganat'
00check.log:Undocumented arguments in documentation object 'pairwiseImageDistanceMatrix'
00check.log:Undocumented arguments in documentation object 'partialVolumeCorrection'
00check.log:Undocumented arguments in documentation object 'perfusionregression'
00check.log:Undocumented arguments in documentation object 'plotANTsImage'
00check.log:Undocumented arguments in documentation object 'plotBasicNetwork'
00check.log:Undocumented arguments in documentation object 'plotPrettyGraph'
00check.log:Undocumented arguments in documentation object 'projectImageAlongAxis'
00check.log:Undocumented arguments in documentation object 'quantifyCBF'
00check.log:Undocumented arguments in documentation object 'regressionNetworkViz'
00check.log:Undocumented arguments in documentation object 'renderImageLabels'
00check.log:Undocumented arguments in documentation object 'renderNetwork'
00check.log:Undocumented arguments in documentation object 'renderSurfaceFunction'
00check.log:Undocumented arguments in documentation object 'reorientImage'
00check.log:Undocumented arguments in documentation object 'rfSegmentation'
00check.log:Undocumented arguments in documentation object 'rfSegmentationPredict'
00check.log:Undocumented arguments in documentation object 'rsfDenoise'
00check.log:Undocumented arguments in documentation object 'sccan'
00check.log:Undocumented arguments in documentation object 'sparseDecom'
00check.log:Undocumented arguments in documentation object 'sparseDecom2'
00check.log:Undocumented arguments in documentation object 'sparseDecom2boot'
00check.log:Undocumented arguments in documentation object 'sparseDecomboot'
00check.log:Undocumented arguments in documentation object 'subgradientL1Regression'
00check.log:Undocumented arguments in documentation object 'taskFMRI'
00check.log:Undocumented arguments in documentation object 'temporalwhiten'
00check.log:Undocumented arguments in documentation object 'timeseriesN3'
00check.log:Undocumented arguments in documentation object 'usePkg'
00check.log:Undocumented arguments in documentation object 'whiten'
from antsr.
stnava
commented on August 30, 2024
for vignettes: will follow http://stackoverflow.com/questions/24861970/using-rmarkdown-as-a-vignette-engine
from antsr.
bkandel
commented on August 30, 2024
I'll try to cover most or all of the ASL-related functions.
One note on style: It looks like a lot of the undocumented functions were
intended to be subroutines in documented functions but were put outside the
brackets. R does support subroutines that don't pollute the global
namespace.
I know that naming is a big mess now, but maybe we can decide on a system
going forward. Are we prefacing everything with ants (e.g.
antsBlahBlahBlah)? I would prefer not to, and just use ANTsR:: as a
preface if necessary, while avoiding conflicts with core packages. Should
we decide on lower-case camelCase? It seems to me to be trending as the
preferred naming style for functions.
Ben
On 2 February 2015 at 18:20, stnava [email protected] wrote:
for vignettes: will follow
http://stackoverflow.com/questions/24861970/using-rmarkdown-as-a-vignette-engine—
Reply to this email directly or view it on GitHub
#8 (comment).
from antsr.
jefferis
commented on August 30, 2024
One note on style: It looks like a lot of the undocumented functions were
intended to be subroutines in documented functions but were put outside the
brackets. R does support subroutines that don't pollute the global
namespace.
I would recommend allowing roxygen2 to generate your NAMESPACE file (a build option in rstudio if you are using that). The normal approach would be to have a file ANTsR-package.R looking something like this:
#' Access to ANTs routines in R
#'
#' R package \bold{ANTsR} provides functions to do ...
#'
#' @name ANTsR-package
#' @aliases ANTsR
#' @useDynLib ANTsR
#' @import Rcpp methods
#' @references some ref
#' @seealso \code{\link{useful_func1}}, \code{\link{useful_func2}}
NULLThen you would tag all functions that you want exported with @export tags in their doc sections. The use of
exportPattern("^[^.]")
in NAMESPACE is generally not recommended (see http://cran.r-project.org/doc/manuals/r-release/R-exts.html#Specifying-imports-and-exports), but you can prefix all private functions with a period as an alternative to using the approach mentioned above.
I know that naming is a big mess now, but maybe we can decide on a system
going forward. Are we prefacing everything with ants (e.g.
antsBlahBlahBlah)? I would prefer not to, and just use ANTsR:: as a
preface if necessary, while avoiding conflicts with core packages.
That seems reasonable to me, although you may want to keep an eye out for functions from popular extension packages (e.g. the hadleyverse)
from antsr.
bkandel
commented on August 30, 2024
I assume this is related: I'm now getting errors building ANTsR because I'm
missing packages 'irlba' and 'png'. These aren't in the dependency list,
but they must have crept in somewhere.
On 2 February 2015 at 17:51, stnava [email protected] wrote:
@ntustison https://github.com/ntustison , @bkandel
https://github.com/bkandel , @dorianps https://github.com/dorianps,
@jeffduda https://github.com/jeffduda , @cookpa
https://github.com/cookpasubstantial progress towards passing R cmd check ... it's not there yet
but i eliminated several "mysterious" warnings, notes and the like and
fixed many documentation issues. also removed what i thought was dead code.
in the future, it would be very helpful if we could adhere to documenting
everything that goes into the main branch of antsr. if you want to do
some test development, please do so on a repository branch. by doing this,
we can avoid getting into the current situation described below.the current R cmd check produces 2 warnings. one is for undocumented
functions (mostly helper functions and dead code) and one for inconsistent
documentation (should be resolvable with roxygen2's help but must be done
manually). the list of issues is below - i will whittle away at these and
would appreciate if you would help with any of these as you get time:
undocumented functions - will remove these when possible‘ExtractDenseNetwork’ ‘LabelClustersUniquely’ ‘LabelGeometryMeasures’
‘LabelImageCentroids’ ‘N4BiasFieldCorrection’ ‘SummarizeClusters’
‘TileImages’ ‘antsAffineInitializer’ ‘antsBOLDNetworkAnalysis’
‘antsCopyImageInfo’ ‘antsGetDirection’ ‘antsGetOrigin’
‘antsGetPixels’ ‘antsGetSpacing’ ‘antsImagePair’
‘antsMotionCorrStats’ ‘antsSetDirection’ ‘antsSetOrigin’
‘antsSetPixels’ ‘antsSetSpacing’ ‘antsTransformIndexToPhysicalPoint’
‘antsTransformPhysicalPointToIndex’ ‘ants_brain_extraction’
‘ants_motion_estimation’ ‘ants_to_template’ ‘antsrGetPointerName’
‘antsrParseListToString’ ‘antsrParseListToString2’
‘antsr_frequency_filter’ ‘antsr_resting_state_corr_eigenanat’
‘antsrmakeRandomString’ ‘arCorrection’ ‘as.data.frame.antsMatrix’
‘as.list.antsMatrix’ ‘binarizeSNPs’ ‘computeDVARS’ ‘conjGradS’
‘cosineDist’ ‘diffmat’ ‘eanatcolMaxs’ ‘eanatsparsify’
‘eanatsparsifyv’ ‘filterPASLforNetworkAnalysis’ ‘getANTsRData’
‘getNetwork’ ‘getValueAtPoint’ ‘get_perfusion_predictors’
‘getvertices’ ‘int_antsProcessArguments’ ‘labels2matrix’
‘labels2vector’ ‘largeScaleCommunity’ ‘lowrank’ ‘lowrankRowMatrix’
‘makeDiffGraph’ ‘makefacet’ ‘makestl’ ‘matrix2timeseries’ ‘matrixSeg’
‘mergeLabels’ ‘motion_correction’ ‘networkCorrelation’
‘networkCovariance’ ‘networkOverlap’ ‘plot.antsImage’ ‘plotNetwork’
‘quantifySNPs’ ‘reduceNetwork’ ‘sliceTimingCorrection’ ‘snapColors’
undocumented arguments - will also remove these when possible or fix by
hand00check.log:Undocumented arguments in documentation object 'Atropos'
00check.log:Undocumented arguments in documentation object
'CreateJacobianDeterminantImage'
00check.log:Undocumented arguments in documentation object 'ImageMath'
00check.log:Undocumented arguments in documentation object 'KellyKapowski'
00check.log:Undocumented arguments in documentation object
'MeasureMinMaxMean'
00check.log:Undocumented arguments in documentation object
'N3BiasFieldCorrection'
00check.log:Undocumented arguments in documentation object 'SmoothImage'
00check.log:Undocumented arguments in documentation object 'ThresholdImage'
00check.log:Undocumented arguments in documentation object
'abpBrainExtraction'
00check.log:Undocumented arguments in documentation object 'abpN4'
00check.log:Undocumented arguments in documentation object
'antsApplyTransforms'
00check.log:Undocumented arguments in documentation object
'antsGetNeighborhood'
00check.log:Undocumented arguments in documentation object
'antsImageMutualInformation'
00check.log:Undocumented arguments in documentation object 'antsMotionCorr'
00check.log:Undocumented arguments in documentation object
'antsPreprocessfMRI'
00check.log:Undocumented arguments in documentation object
'antsRegistration'
00check.log:Undocumented arguments in documentation object 'aslDenoiseR'
00check.log:Undocumented arguments in documentation object 'aslPerfusion'
00check.log:Undocumented arguments in documentation object 'bayesianCBF'
00check.log:Undocumented arguments in documentation object 'bayesianlm'
00check.log:Undocumented arguments in documentation object
'clusterTimeSeries'
00check.log:Undocumented arguments in documentation object 'compcor'
00check.log:Undocumented arguments in documentation object 'corw'
00check.log:Undocumented arguments in documentation object 'eigSeg'
00check.log:Undocumented arguments in documentation object 'fastwhiten'
00check.log:Undocumented arguments in documentation object
'filterfMRIforNetworkAnalysis'
00check.log:Undocumented arguments in documentation object
'frequencyFilterfMRI'
00check.log:Undocumented arguments in documentation object
'getAverageOfTimeSeries'
00check.log:Undocumented arguments in documentation object 'getCentroids'
00check.log:Undocumented arguments in documentation object
'getMultivariateTemplateCoordinates'
00check.log:Undocumented arguments in documentation object 'getROIValues'
00check.log:Undocumented arguments in documentation object
'getTemplateCoordinates'
00check.log:Undocumented arguments in documentation object
'getfMRInuisanceVariables'
00check.log:Undocumented arguments in documentation object 'icawhiten'
00check.log:Undocumented arguments in documentation object
'image2ClusterImages'
00check.log:Undocumented arguments in documentation object
'imageFileNames2ImageList'
00check.log:Undocumented arguments in documentation object
'initializeEigenanatomy'
00check.log:Undocumented arguments in documentation object
'inspectImageData3D'
00check.log:Undocumented arguments in documentation object
'interleaveMatrixWithItself'
00check.log:Undocumented arguments in documentation object
'invariantImageSimilarity'
00check.log:Undocumented arguments in documentation object
'joinEigenanatomy'
00check.log:Undocumented arguments in documentation object
'kmeansSegmentation'
00check.log:Undocumented arguments in documentation object 'labelClusters'
00check.log:Undocumented arguments in documentation object 'lappend'
00check.log:Undocumented arguments in documentation object 'makeGraph'
00check.log:Undocumented arguments in documentation object 'makeImage'
00check.log:Undocumented arguments in documentation object 'mni2tal'
00check.log:Undocumented arguments in documentation object 'networkEiganat'
00check.log:Undocumented arguments in documentation object
'pairwiseImageDistanceMatrix'
00check.log:Undocumented arguments in documentation object
'partialVolumeCorrection'
00check.log:Undocumented arguments in documentation object
'perfusionregression'
00check.log:Undocumented arguments in documentation object 'plotANTsImage'
00check.log:Undocumented arguments in documentation object
'plotBasicNetwork'
00check.log:Undocumented arguments in documentation object
'plotPrettyGraph'
00check.log:Undocumented arguments in documentation object
'projectImageAlongAxis'
00check.log:Undocumented arguments in documentation object 'quantifyCBF'
00check.log:Undocumented arguments in documentation object
'regressionNetworkViz'
00check.log:Undocumented arguments in documentation object
'renderImageLabels'
00check.log:Undocumented arguments in documentation object 'renderNetwork'
00check.log:Undocumented arguments in documentation object
'renderSurfaceFunction'
00check.log:Undocumented arguments in documentation object 'reorientImage'
00check.log:Undocumented arguments in documentation object 'rfSegmentation'
00check.log:Undocumented arguments in documentation object
'rfSegmentationPredict'
00check.log:Undocumented arguments in documentation object 'rsfDenoise'
00check.log:Undocumented arguments in documentation object 'sccan'
00check.log:Undocumented arguments in documentation object 'sparseDecom'
00check.log:Undocumented arguments in documentation object 'sparseDecom2'
00check.log:Undocumented arguments in documentation object
'sparseDecom2boot'
00check.log:Undocumented arguments in documentation object
'sparseDecomboot'
00check.log:Undocumented arguments in documentation object
'subgradientL1Regression'
00check.log:Undocumented arguments in documentation object 'taskFMRI'
00check.log:Undocumented arguments in documentation object 'temporalwhiten'
00check.log:Undocumented arguments in documentation object 'timeseriesN3'
00check.log:Undocumented arguments in documentation object 'usePkg'
00check.log:Undocumented arguments in documentation object 'whiten'—
Reply to this email directly or view it on GitHub
#8 (comment).
from antsr.
stnava
commented on August 30, 2024
Yes. For cran check, we must list all dependencies ... we know how to
reduce these for future work but for now , need to be explicit. Can relax
in the future.
On Feb 3, 2015 4:20 PM, "bkandel" [email protected] wrote:
I assume this is related: I'm now getting errors building ANTsR because
I'm
missing packages 'irlba' and 'png'. These aren't in the dependency list,
but they must have crept in somewhere.On 2 February 2015 at 17:51, stnava [email protected] wrote:
@ntustison https://github.com/ntustison , @bkandel
https://github.com/bkandel , @dorianps https://github.com/dorianps,
@jeffduda https://github.com/jeffduda , @cookpa
https://github.com/cookpasubstantial progress towards passing R cmd check ... it's not there yet
but i eliminated several "mysterious" warnings, notes and the like and
fixed many documentation issues. also removed what i thought was dead
code.
in the future, it would be very helpful if we could adhere to
documenting
everything that goes into the main branch of antsr. if you want to do
some test development, please do so on a repository branch. by doing
this,
we can avoid getting into the current situation described below.the current R cmd check produces 2 warnings. one is for undocumented
functions (mostly helper functions and dead code) and one for
inconsistent
documentation (should be resolvable with roxygen2's help but must be
done
manually). the list of issues is below - i will whittle away at these
and
would appreciate if you would help with any of these as you get time:
undocumented functions - will remove these when possible‘ExtractDenseNetwork’ ‘LabelClustersUniquely’ ‘LabelGeometryMeasures’
‘LabelImageCentroids’ ‘N4BiasFieldCorrection’ ‘SummarizeClusters’
‘TileImages’ ‘antsAffineInitializer’ ‘antsBOLDNetworkAnalysis’
‘antsCopyImageInfo’ ‘antsGetDirection’ ‘antsGetOrigin’
‘antsGetPixels’ ‘antsGetSpacing’ ‘antsImagePair’
‘antsMotionCorrStats’ ‘antsSetDirection’ ‘antsSetOrigin’
‘antsSetPixels’ ‘antsSetSpacing’ ‘antsTransformIndexToPhysicalPoint’
‘antsTransformPhysicalPointToIndex’ ‘ants_brain_extraction’
‘ants_motion_estimation’ ‘ants_to_template’ ‘antsrGetPointerName’
‘antsrParseListToString’ ‘antsrParseListToString2’
‘antsr_frequency_filter’ ‘antsr_resting_state_corr_eigenanat’
‘antsrmakeRandomString’ ‘arCorrection’ ‘as.data.frame.antsMatrix’
‘as.list.antsMatrix’ ‘binarizeSNPs’ ‘computeDVARS’ ‘conjGradS’
‘cosineDist’ ‘diffmat’ ‘eanatcolMaxs’ ‘eanatsparsify’
‘eanatsparsifyv’ ‘filterPASLforNetworkAnalysis’ ‘getANTsRData’
‘getNetwork’ ‘getValueAtPoint’ ‘get_perfusion_predictors’
‘getvertices’ ‘int_antsProcessArguments’ ‘labels2matrix’
‘labels2vector’ ‘largeScaleCommunity’ ‘lowrank’ ‘lowrankRowMatrix’
‘makeDiffGraph’ ‘makefacet’ ‘makestl’ ‘matrix2timeseries’ ‘matrixSeg’
‘mergeLabels’ ‘motion_correction’ ‘networkCorrelation’
‘networkCovariance’ ‘networkOverlap’ ‘plot.antsImage’ ‘plotNetwork’
‘quantifySNPs’ ‘reduceNetwork’ ‘sliceTimingCorrection’ ‘snapColors’
undocumented arguments - will also remove these when possible or fix by
hand00check.log:Undocumented arguments in documentation object 'Atropos'
00check.log:Undocumented arguments in documentation object
'CreateJacobianDeterminantImage'
00check.log:Undocumented arguments in documentation object 'ImageMath'
00check.log:Undocumented arguments in documentation object
'KellyKapowski'
00check.log:Undocumented arguments in documentation object
'MeasureMinMaxMean'
00check.log:Undocumented arguments in documentation object
'N3BiasFieldCorrection'
00check.log:Undocumented arguments in documentation object 'SmoothImage'
00check.log:Undocumented arguments in documentation object
'ThresholdImage'
00check.log:Undocumented arguments in documentation object
'abpBrainExtraction'
00check.log:Undocumented arguments in documentation object 'abpN4'
00check.log:Undocumented arguments in documentation object
'antsApplyTransforms'
00check.log:Undocumented arguments in documentation object
'antsGetNeighborhood'
00check.log:Undocumented arguments in documentation object
'antsImageMutualInformation'
00check.log:Undocumented arguments in documentation object
'antsMotionCorr'
00check.log:Undocumented arguments in documentation object
'antsPreprocessfMRI'
00check.log:Undocumented arguments in documentation object
'antsRegistration'
00check.log:Undocumented arguments in documentation object 'aslDenoiseR'
00check.log:Undocumented arguments in documentation object
'aslPerfusion'
00check.log:Undocumented arguments in documentation object 'bayesianCBF'
00check.log:Undocumented arguments in documentation object 'bayesianlm'
00check.log:Undocumented arguments in documentation object
'clusterTimeSeries'
00check.log:Undocumented arguments in documentation object 'compcor'
00check.log:Undocumented arguments in documentation object 'corw'
00check.log:Undocumented arguments in documentation object 'eigSeg'
00check.log:Undocumented arguments in documentation object 'fastwhiten'
00check.log:Undocumented arguments in documentation object
'filterfMRIforNetworkAnalysis'
00check.log:Undocumented arguments in documentation object
'frequencyFilterfMRI'
00check.log:Undocumented arguments in documentation object
'getAverageOfTimeSeries'
00check.log:Undocumented arguments in documentation object
'getCentroids'
00check.log:Undocumented arguments in documentation object
'getMultivariateTemplateCoordinates'
00check.log:Undocumented arguments in documentation object
'getROIValues'
00check.log:Undocumented arguments in documentation object
'getTemplateCoordinates'
00check.log:Undocumented arguments in documentation object
'getfMRInuisanceVariables'
00check.log:Undocumented arguments in documentation object 'icawhiten'
00check.log:Undocumented arguments in documentation object
'image2ClusterImages'
00check.log:Undocumented arguments in documentation object
'imageFileNames2ImageList'
00check.log:Undocumented arguments in documentation object
'initializeEigenanatomy'
00check.log:Undocumented arguments in documentation object
'inspectImageData3D'
00check.log:Undocumented arguments in documentation object
'interleaveMatrixWithItself'
00check.log:Undocumented arguments in documentation object
'invariantImageSimilarity'
00check.log:Undocumented arguments in documentation object
'joinEigenanatomy'
00check.log:Undocumented arguments in documentation object
'kmeansSegmentation'
00check.log:Undocumented arguments in documentation object
'labelClusters'
00check.log:Undocumented arguments in documentation object 'lappend'
00check.log:Undocumented arguments in documentation object 'makeGraph'
00check.log:Undocumented arguments in documentation object 'makeImage'
00check.log:Undocumented arguments in documentation object 'mni2tal'
00check.log:Undocumented arguments in documentation object
'networkEiganat'
00check.log:Undocumented arguments in documentation object
'pairwiseImageDistanceMatrix'
00check.log:Undocumented arguments in documentation object
'partialVolumeCorrection'
00check.log:Undocumented arguments in documentation object
'perfusionregression'
00check.log:Undocumented arguments in documentation object
'plotANTsImage'
00check.log:Undocumented arguments in documentation object
'plotBasicNetwork'
00check.log:Undocumented arguments in documentation object
'plotPrettyGraph'
00check.log:Undocumented arguments in documentation object
'projectImageAlongAxis'
00check.log:Undocumented arguments in documentation object 'quantifyCBF'
00check.log:Undocumented arguments in documentation object
'regressionNetworkViz'
00check.log:Undocumented arguments in documentation object
'renderImageLabels'
00check.log:Undocumented arguments in documentation object
'renderNetwork'
00check.log:Undocumented arguments in documentation object
'renderSurfaceFunction'
00check.log:Undocumented arguments in documentation object
'reorientImage'
00check.log:Undocumented arguments in documentation object
'rfSegmentation'
00check.log:Undocumented arguments in documentation object
'rfSegmentationPredict'
00check.log:Undocumented arguments in documentation object 'rsfDenoise'
00check.log:Undocumented arguments in documentation object 'sccan'
00check.log:Undocumented arguments in documentation object 'sparseDecom'
00check.log:Undocumented arguments in documentation object
'sparseDecom2'
00check.log:Undocumented arguments in documentation object
'sparseDecom2boot'
00check.log:Undocumented arguments in documentation object
'sparseDecomboot'
00check.log:Undocumented arguments in documentation object
'subgradientL1Regression'
00check.log:Undocumented arguments in documentation object 'taskFMRI'
00check.log:Undocumented arguments in documentation object
'temporalwhiten'
00check.log:Undocumented arguments in documentation object
'timeseriesN3'
00check.log:Undocumented arguments in documentation object 'usePkg'
00check.log:Undocumented arguments in documentation object 'whiten'—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).
from antsr.
stnava
commented on August 30, 2024
Another useful resource: http://r-pkgs.had.co.nz/description.html
Regarding suggests, imports, etc ... we could do a better job of these ...
am working on it.
On Feb 3, 2015 6:48 PM, "brian avants" [email protected] wrote:
Yes. For cran check, we must list all dependencies ... we know how to
reduce these for future work but for now , need to be explicit. Can relax
in the future.
On Feb 3, 2015 4:20 PM, "bkandel" [email protected] wrote:I assume this is related: I'm now getting errors building ANTsR because
I'm
missing packages 'irlba' and 'png'. These aren't in the dependency list,
but they must have crept in somewhere.On 2 February 2015 at 17:51, stnava [email protected] wrote:
@ntustison https://github.com/ntustison , @bkandel
https://github.com/bkandel , @dorianps https://github.com/dorianps,@jeffduda https://github.com/jeffduda , @cookpa
https://github.com/cookpasubstantial progress towards passing R cmd check ... it's not there yet
but i eliminated several "mysterious" warnings, notes and the like and
fixed many documentation issues. also removed what i thought was dead
code.
in the future, it would be very helpful if we could adhere to
documenting
everything that goes into the main branch of antsr. if you want to do
some test development, please do so on a repository branch. by doing
this,
we can avoid getting into the current situation described below.the current R cmd check produces 2 warnings. one is for undocumented
functions (mostly helper functions and dead code) and one for
inconsistent
documentation (should be resolvable with roxygen2's help but must be
done
manually). the list of issues is below - i will whittle away at these
and
would appreciate if you would help with any of these as you get time:
undocumented functions - will remove these when possible‘ExtractDenseNetwork’ ‘LabelClustersUniquely’ ‘LabelGeometryMeasures’
‘LabelImageCentroids’ ‘N4BiasFieldCorrection’ ‘SummarizeClusters’
‘TileImages’ ‘antsAffineInitializer’ ‘antsBOLDNetworkAnalysis’
‘antsCopyImageInfo’ ‘antsGetDirection’ ‘antsGetOrigin’
‘antsGetPixels’ ‘antsGetSpacing’ ‘antsImagePair’
‘antsMotionCorrStats’ ‘antsSetDirection’ ‘antsSetOrigin’
‘antsSetPixels’ ‘antsSetSpacing’ ‘antsTransformIndexToPhysicalPoint’
‘antsTransformPhysicalPointToIndex’ ‘ants_brain_extraction’
‘ants_motion_estimation’ ‘ants_to_template’ ‘antsrGetPointerName’
‘antsrParseListToString’ ‘antsrParseListToString2’
‘antsr_frequency_filter’ ‘antsr_resting_state_corr_eigenanat’
‘antsrmakeRandomString’ ‘arCorrection’ ‘as.data.frame.antsMatrix’
‘as.list.antsMatrix’ ‘binarizeSNPs’ ‘computeDVARS’ ‘conjGradS’
‘cosineDist’ ‘diffmat’ ‘eanatcolMaxs’ ‘eanatsparsify’
‘eanatsparsifyv’ ‘filterPASLforNetworkAnalysis’ ‘getANTsRData’
‘getNetwork’ ‘getValueAtPoint’ ‘get_perfusion_predictors’
‘getvertices’ ‘int_antsProcessArguments’ ‘labels2matrix’
‘labels2vector’ ‘largeScaleCommunity’ ‘lowrank’ ‘lowrankRowMatrix’
‘makeDiffGraph’ ‘makefacet’ ‘makestl’ ‘matrix2timeseries’ ‘matrixSeg’
‘mergeLabels’ ‘motion_correction’ ‘networkCorrelation’
‘networkCovariance’ ‘networkOverlap’ ‘plot.antsImage’ ‘plotNetwork’
‘quantifySNPs’ ‘reduceNetwork’ ‘sliceTimingCorrection’ ‘snapColors’
undocumented arguments - will also remove these when possible or fix by
hand00check.log:Undocumented arguments in documentation object 'Atropos'
00check.log:Undocumented arguments in documentation object
'CreateJacobianDeterminantImage'
00check.log:Undocumented arguments in documentation object 'ImageMath'
00check.log:Undocumented arguments in documentation object
'KellyKapowski'
00check.log:Undocumented arguments in documentation object
'MeasureMinMaxMean'
00check.log:Undocumented arguments in documentation object
'N3BiasFieldCorrection'
00check.log:Undocumented arguments in documentation object
'SmoothImage'
00check.log:Undocumented arguments in documentation object
'ThresholdImage'
00check.log:Undocumented arguments in documentation object
'abpBrainExtraction'
00check.log:Undocumented arguments in documentation object 'abpN4'
00check.log:Undocumented arguments in documentation object
'antsApplyTransforms'
00check.log:Undocumented arguments in documentation object
'antsGetNeighborhood'
00check.log:Undocumented arguments in documentation object
'antsImageMutualInformation'
00check.log:Undocumented arguments in documentation object
'antsMotionCorr'
00check.log:Undocumented arguments in documentation object
'antsPreprocessfMRI'
00check.log:Undocumented arguments in documentation object
'antsRegistration'
00check.log:Undocumented arguments in documentation object
'aslDenoiseR'
00check.log:Undocumented arguments in documentation object
'aslPerfusion'
00check.log:Undocumented arguments in documentation object
'bayesianCBF'
00check.log:Undocumented arguments in documentation object 'bayesianlm'
00check.log:Undocumented arguments in documentation object
'clusterTimeSeries'
00check.log:Undocumented arguments in documentation object 'compcor'
00check.log:Undocumented arguments in documentation object 'corw'
00check.log:Undocumented arguments in documentation object 'eigSeg'
00check.log:Undocumented arguments in documentation object 'fastwhiten'
00check.log:Undocumented arguments in documentation object
'filterfMRIforNetworkAnalysis'
00check.log:Undocumented arguments in documentation object
'frequencyFilterfMRI'
00check.log:Undocumented arguments in documentation object
'getAverageOfTimeSeries'
00check.log:Undocumented arguments in documentation object
'getCentroids'
00check.log:Undocumented arguments in documentation object
'getMultivariateTemplateCoordinates'
00check.log:Undocumented arguments in documentation object
'getROIValues'
00check.log:Undocumented arguments in documentation object
'getTemplateCoordinates'
00check.log:Undocumented arguments in documentation object
'getfMRInuisanceVariables'
00check.log:Undocumented arguments in documentation object 'icawhiten'
00check.log:Undocumented arguments in documentation object
'image2ClusterImages'
00check.log:Undocumented arguments in documentation object
'imageFileNames2ImageList'
00check.log:Undocumented arguments in documentation object
'initializeEigenanatomy'
00check.log:Undocumented arguments in documentation object
'inspectImageData3D'
00check.log:Undocumented arguments in documentation object
'interleaveMatrixWithItself'
00check.log:Undocumented arguments in documentation object
'invariantImageSimilarity'
00check.log:Undocumented arguments in documentation object
'joinEigenanatomy'
00check.log:Undocumented arguments in documentation object
'kmeansSegmentation'
00check.log:Undocumented arguments in documentation object
'labelClusters'
00check.log:Undocumented arguments in documentation object 'lappend'
00check.log:Undocumented arguments in documentation object 'makeGraph'
00check.log:Undocumented arguments in documentation object 'makeImage'
00check.log:Undocumented arguments in documentation object 'mni2tal'
00check.log:Undocumented arguments in documentation object
'networkEiganat'
00check.log:Undocumented arguments in documentation object
'pairwiseImageDistanceMatrix'
00check.log:Undocumented arguments in documentation object
'partialVolumeCorrection'
00check.log:Undocumented arguments in documentation object
'perfusionregression'
00check.log:Undocumented arguments in documentation object
'plotANTsImage'
00check.log:Undocumented arguments in documentation object
'plotBasicNetwork'
00check.log:Undocumented arguments in documentation object
'plotPrettyGraph'
00check.log:Undocumented arguments in documentation object
'projectImageAlongAxis'
00check.log:Undocumented arguments in documentation object
'quantifyCBF'
00check.log:Undocumented arguments in documentation object
'regressionNetworkViz'
00check.log:Undocumented arguments in documentation object
'renderImageLabels'
00check.log:Undocumented arguments in documentation object
'renderNetwork'
00check.log:Undocumented arguments in documentation object
'renderSurfaceFunction'
00check.log:Undocumented arguments in documentation object
'reorientImage'
00check.log:Undocumented arguments in documentation object
'rfSegmentation'
00check.log:Undocumented arguments in documentation object
'rfSegmentationPredict'
00check.log:Undocumented arguments in documentation object 'rsfDenoise'
00check.log:Undocumented arguments in documentation object 'sccan'
00check.log:Undocumented arguments in documentation object
'sparseDecom'
00check.log:Undocumented arguments in documentation object
'sparseDecom2'
00check.log:Undocumented arguments in documentation object
'sparseDecom2boot'
00check.log:Undocumented arguments in documentation object
'sparseDecomboot'
00check.log:Undocumented arguments in documentation object
'subgradientL1Regression'
00check.log:Undocumented arguments in documentation object 'taskFMRI'
00check.log:Undocumented arguments in documentation object
'temporalwhiten'
00check.log:Undocumented arguments in documentation object
'timeseriesN3'
00check.log:Undocumented arguments in documentation object 'usePkg'
00check.log:Undocumented arguments in documentation object 'whiten'—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).
from antsr.
stnava
commented on August 30, 2024
Explanation of current dev/check system:
-
hide utility functions by using .functionName
-
these are still accessible via ANTsR:::.functionName in the R user (scripting) space
-
these can be called internally w/in ANTsR as .functionName
-
these functions do not need documentation
-
document all other functions with roxygen2
-
make sure usage variable names and roxygen2 variable names are consistent
-
NAMESPACE: put packages that we minimally rely on in Suggests
- call haverobust<-usePkg("robust") to use this package internally - never use require or library
- if ( ! haverobust ) { do something useful like print message and return Null } e.g.
if ( !usePkg("fpc") ) { print("Need fpc package"); return(NULL) }- another example
if ( predalgorithm == 'svm' )
{
havesvm<-usePkg("e1071")
if ( !havesvm ) predalgorithm<-"lm"
}
- Regularly build and check the package .... My current approach is to build two versions of ANTsR
- one with only the Depends packages
- another that includes the Suggests packages
then call
R CMD build ANTsR
on a clean version of ANTsR - e.g. a fresh clone or git pull w/o any extra files related to installation ... this creates ANTsR_1.0.tar.gz
then point R CMD check to a library version of ANTsR
R CMD check ANTsR_1.0.tar.gz --library=${R_LIBS} --no-install --as-cran --no-examples
will check that code and not run examples
R CMD check ANTsR_1.0.tar.gz --library=${R_LIBS} --no-install --as-cran
will check the code and run examples
R CMD check ANTsR_1.0.tar.gz --library=${R_LIBS} --no-install --as-cran
will install, check the code and run examples
this last call is the one that we must ultimately pass.
from antsr.
stnava
commented on August 30, 2024
Currently, there are a few undocumented code bits that @jeffduda will contribute. There are many more inconsistent documentation and usage functions. This is where the most help is currently needed in order to get over the first major barrier to submitting to CRAN. They are here ( note: i reduced this list by a third with about 2 hours' work it's still over 300 lines)
- checking Rd \usage sections ... WARNING
Undocumented arguments in documentation object 'ThresholdImage'
‘...’
Documented arguments not in \usage in documentation object 'ThresholdImage':
‘imageDimension2|3’ ‘thresh-low’ ‘thresh-high’ ‘inside-value’
‘outside-value’ ‘number-of-thresholds’ ‘inputImage’ ‘outputImage’
Undocumented arguments in documentation object 'antsApplyTransforms'
‘moving’ ‘whichtoinvert’ ‘...’
Documented arguments not in \usage in documentation object 'antsApplyTransforms':
‘movingImage’
Undocumented arguments in documentation object 'antsGetNeighborhood'
‘x’
Documented arguments not in \usage in documentation object 'antsGetNeighborhood':
‘image’
Undocumented arguments in documentation object 'antsImage-class'
‘.Object’ ‘pixeltype’ ‘dimension’ ‘x’ ‘mask’ ‘region’ ‘i’ ‘j’ ‘e1’
‘e2’
Undocumented arguments in documentation object 'antsMatrix-class'
‘.Object’ ‘elementtype’ ‘x’
Undocumented arguments in documentation object 'antsMotionCorr'
‘...’
Documented arguments not in \usage in documentation object 'antsMotionCorr':
‘d-or-dimensionality=’
Undocumented arguments in documentation object 'antsPreprocessfMRI'
‘maskingMeanRatioThreshold’ ‘residualizeMatrix’
Documented arguments not in \usage in documentation object 'antsPreprocessfMRI':
‘maskingThreshold’
Undocumented arguments in documentation object 'antsRegistration'
‘...’
Undocumented arguments in documentation object 'as.antsImage'
‘pixeltype’ ‘spacing’ ‘origin’
Documented arguments not in \usage in documentation object 'as.antsImage':
‘data’ ‘Fun’
Undocumented arguments in documentation object 'as.antsMatrix'
‘elementtype’
Documented arguments not in \usage in documentation object 'as.antsMatrix':
‘Fun’
Undocumented arguments in documentation object 'aslDenoiseR'
‘boldmatrix’ ‘targety’ ‘motionparams’ ‘selectionthresh’
‘maxnoisepreds’ ‘debug’ ‘polydegree’ ‘crossvalidationgroups’
‘scalemat’ ‘noisepoolfun’ ‘usecompcor’
Documented arguments not in \usage in documentation object 'aslDenoiseR':
‘mat’
Undocumented arguments in documentation object 'aslPerfusion'
‘asl’ ‘maskThresh’ ‘moreaccurate’ ‘dorobust’ ‘m0’ ‘skip’ ‘mask’
‘interpolation’ ‘checkmeansignal’ ‘moco_results’ ‘regweights’
‘useDenoiser’ ‘useBayesian’ ‘verbose’ ‘ncompcor’ ‘N3’
Documented arguments not in \usage in documentation object 'aslPerfusion':
‘maskThresh=’ ‘dorobust=’
‘asl_antsr_image_or_filename’
Undocumented arguments in documentation object 'eigSeg'
‘imgList’
Documented arguments not in \usage in documentation object 'eigSeg':
‘imageList’
Undocumented arguments in documentation object 'fastwhiten'
‘x’ ‘mynu’
Documented arguments not in \usage in documentation object 'fastwhiten':
‘mat’
Undocumented arguments in documentation object 'filterfMRIforNetworkAnalysis'
‘aslmat’ ‘tr’ ‘freqLo’ ‘freqHi’ ‘cbfnetwork’ ‘mask’ ‘labels’
‘graphdensity’ ‘seg’ ‘useglasso’ ‘nuisancein’ ‘usesvd’ ‘robustcorr’
Documented arguments not in \usage in documentation object 'filterfMRIforNetworkAnalysis':
‘tr=’ ‘freqLo=’ ‘freqHi=’ ‘cbfnetwork="ASLCBF"’
‘maskThresh=’ ‘smoother=’ ‘outputprefix=’
‘asl_antsr_image_or_filename’
Undocumented arguments in documentation object 'frequencyFilterfMRI'
‘boldmat’ ‘tr’ ‘freqLo’ ‘freqHi’ ‘opt’
Documented arguments not in \usage in documentation object 'frequencyFilterfMRI':
‘tr=’ ‘freqLo=’ ‘freqHi=’ ‘opt=c('trig'’
‘'butt'’ ‘'stl')’ ‘boldMatrix’
Undocumented arguments in documentation object 'getAverageOfTimeSeries'
‘timeseriesimage’
Documented arguments not in \usage in documentation object 'getAverageOfTimeSeries':
‘img’
Undocumented arguments in documentation object 'getCentroids'
‘outprefix’
Undocumented arguments in documentation object 'getMultivariateTemplateCoordinates'
‘templateWithLabels’ ‘labelnames’ ‘outprefix’ ‘convertToTal’
‘threshparam’ ‘clustparam’ ‘identifier’
Undocumented arguments in documentation object 'getROIValues'
‘maskImage’
Duplicated \argument entries in documentation object 'getROIValues':
‘valueImage’
Undocumented arguments in documentation object 'getTemplateCoordinates'
‘imagePairToBeLabeled’ ‘templatePairWithLabels’ ‘labelnames’
‘outprefix’ ‘convertToTal’
Documented arguments not in \usage in documentation object 'getTemplateCoordinates':
‘x’
Undocumented arguments in documentation object 'getfMRInuisanceVariables'
‘fmri’ ‘moreaccurate’
Documented arguments not in \usage in documentation object 'getfMRInuisanceVariables':
‘boldImageOrFileName’
Undocumented arguments in documentation object 'icawhiten'
‘Xin’ ‘verbose’
Documented arguments not in \usage in documentation object 'icawhiten':
‘mat’
Undocumented arguments in documentation object 'image2ClusterImages'
‘x’ ‘minClusterSize’ ‘minThresh’ ‘maxThresh’
Documented arguments not in \usage in documentation object 'image2ClusterImages':
‘img’
Undocumented arguments in documentation object 'imageFileNames2ImageList'
‘dim’
Undocumented arguments in documentation object 'initializeEigenanatomy'
‘initmat’
Documented arguments not in \usage in documentation object 'initializeEigenanatomy':
‘mat’
Undocumented arguments in documentation object 'interleaveMatrixWithItself'
‘x’ ‘n’
Documented arguments not in \usage in documentation object 'interleaveMatrixWithItself':
‘mat’
Undocumented arguments in documentation object 'invariantImageSimilarity'
‘in_image1’ ‘in_image2’ ‘txfn’
Documented arguments not in \usage in documentation object 'invariantImageSimilarity':
‘fixedImg’ ‘movingImg’ ‘txFilename’
Undocumented arguments in documentation object 'kmeansSegmentation'
‘img’ ‘kmask’ ‘mrf’
Undocumented arguments in documentation object 'labelClusters'
‘imagein’ ‘minClusterSize’ ‘minThresh’ ‘maxThresh’
Documented arguments not in \usage in documentation object 'labelClusters':
‘img’
Undocumented arguments in documentation object 'lappend'
‘lst’ ‘obj’
Documented arguments not in \usage in documentation object 'lappend':
‘inlist’ ‘myitem’
Undocumented arguments in documentation object 'makeImage'
‘imagesize’ ‘voxval’
Documented arguments not in \usage in documentation object 'makeImage':
‘mat’ ‘val’
Documented arguments not in \usage in documentation object 'matrixToImages':
‘outputRoot’
Undocumented arguments in documentation object 'mni2tal'
‘xin’
Documented arguments not in \usage in documentation object 'mni2tal':
‘x’
Undocumented arguments in documentation object 'networkEiganat'
‘Xin’ ‘sparseness’ ‘nvecs’ ‘its’ ‘gradparam’ ‘mask’ ‘v’ ‘prior’
‘pgradparam’ ‘clustval’ ‘downsample’ ‘doscale’ ‘domin’ ‘verbose’
‘dowhite’ ‘timeme’ ‘addb’ ‘useregression’
Documented arguments not in \usage in documentation object 'networkEiganat':
‘inmatrix’ ‘inmask’ ‘otherparams’
Undocumented arguments in documentation object 'pairwiseImageDistanceMatrix'
‘metrictype’ ‘nclusters’
Undocumented arguments in documentation object 'perfusionregression'
‘skip’ ‘selectionValsForRegweights’ ‘useBayesian’
Documented arguments not in \usage in documentation object 'perfusionregression':
‘m0’
Undocumented arguments in documentation object 'plot.antsImage'
‘color’ ‘axis’ ‘slices’ ‘threshold’ ‘quality’ ‘outname’ ‘alpha’ ‘...’
Documented arguments not in \usage in documentation object 'plot.antsImage':
‘color=’ ‘axis=’ ‘slices=’
‘threshold=’ ‘quality=’ ‘outname='figx.jpg'’
Undocumented arguments in documentation object 'plotBasicNetwork'
‘weights’ ‘edgecolors’ ‘nodecolors’ ‘nodetype’ ‘scaling’ ‘lwd’
‘radius’ ‘showOnlyConnectedNodes’
Undocumented arguments in documentation object 'plotPrettyGraph'
‘functionToPlot’ ‘hueval’
Documented arguments not in \usage in documentation object 'plotPrettyGraph':
‘graphMetricValue’
Undocumented arguments in documentation object 'projectImageAlongAxis'
‘imageND’ ‘referenceImageNDminus1’
Documented arguments not in \usage in documentation object 'projectImageAlongAxis':
‘img4d’ ‘refimg3d’
Undocumented arguments in documentation object 'quantifyCBF'
‘perfusion’ ‘mask’ ‘M0val’ ‘outlierValue’
Documented arguments not in \usage in documentation object 'quantifyCBF':
‘aslmat’ ‘aslmask’
Undocumented arguments in documentation object 'regressionNetworkViz'
‘mylm’
Documented arguments not in \usage in documentation object 'regressionNetworkViz':
‘myLM’
Undocumented arguments in documentation object 'renderImageLabels'
‘blobrender’ ‘alphafunc’ ‘outdir’ ‘outfn’ ‘labels’
Undocumented arguments in documentation object 'renderNetwork'
‘nodecolors’
Undocumented arguments in documentation object 'renderSurfaceFunction'
‘smoothsval’ ‘smoothfval’ ‘alphasurf’ ‘alphafunc’ ‘outdir’ ‘outfn’
‘mycol’ ‘physical’
Undocumented arguments in documentation object 'reorientImage'
‘axis1’ ‘doscale’
Documented arguments not in \usage in documentation object 'reorientImage':
‘axis’
Undocumented arguments in documentation object 'rfSegmentation'
‘labelimg’ ‘ntrees’ ‘verbose’
Documented arguments not in \usage in documentation object 'rfSegmentation':
‘labelimage’
Undocumented arguments in documentation object 'rsfDenoise'
‘boldmatrix’ ‘targety’ ‘motionparams’ ‘selectionthresh’
‘maxnoisepreds’ ‘debug’ ‘polydegree’ ‘crossvalidationgroups’ ‘tr’
‘scalemat’ ‘noisepoolfun’
Documented arguments not in \usage in documentation object 'rsfDenoise':
‘mat’
Undocumented arguments in documentation object 'sparseDecom2'
‘sparseness’ ‘nvecs’ ‘its’ ‘cthresh’ ‘statdir’ ‘perms’ ‘uselong’ ‘z’
‘smooth’ ‘robust’ ‘mycoption’ ‘initializationList’
‘initializationList2’ ‘ell1’
Documented arguments not in \usage in documentation object 'sparseDecom2':
‘otherparams’
Undocumented arguments in documentation object 'sparseDecom2boot'
‘sparseness’ ‘nvecs’ ‘its’ ‘cthresh’ ‘statdir’ ‘perms’ ‘uselong’ ‘z’
‘smooth’ ‘robust’ ‘mycoption’ ‘initializationList’
‘initializationList2’ ‘ell1’ ‘doseg’
Documented arguments not in \usage in documentation object 'sparseDecom2boot':
‘otherparams’
Undocumented arguments in documentation object 'subgradientL1Regression'
‘s’ ‘percentvals’ ‘nits’ ‘betas’ ‘sparval’
Undocumented arguments in documentation object 'taskFMRI'
‘mat’ ‘hrf’ ‘myvars’ ‘correctautocorr’ ‘residualizedesignmatrix’
‘myformula’
Documented arguments not in \usage in documentation object 'taskFMRI':
‘fmriMatrix’ ‘blockDesign’
Undocumented arguments in documentation object 'timeseriesN3'
‘boldimg’
Documented arguments not in \usage in documentation object 'timeseriesN3':
‘mat’
Bad \usage lines found in documentation object 'combineNuisancePredictors':
combineNuisancePredictors <- function(inmat, target,
globalpredictors=NA, localpredictors=NA, maxpreds=4, k=5)
Functions with \usage entries need to have the appropriate \alias
entries, and all their arguments documented.
The \usage entries must correspond to syntactically valid R code.
See the chapter ‘Writing R documentation files’ in the ‘Writing R
Extensions’ manual.
from antsr.
dorianps
commented on August 30, 2024
I am having trouble with updating ANTsR in cluster. This is what happens when loading the package:
Error in dyn.load(file, DLLpath = DLLpath, ...) :
unable to load shared object '/home/dpustina/R/x86_64-unknown-linux-gnu-library/3.1/ANTsR/libs/ANTsR.so':
/home/dpustina/R/x86_64-unknown-linux-gnu-library/3.1/ANTsR/libs/ANTsR.so: undefined symbol: _ZN3itk24ImageToImageFilterCommon34GetGlobalDefaultDirectionToleranceEv
Is this related to the problems described above? Do you advise to start over with a clean build?
Dorian
from antsr.
stnava
commented on August 30, 2024
Unrelated ... probably just need clean build.
On Feb 5, 2015 11:21 AM, "dorianps" [email protected] wrote:
I am having trouble with updating ANTsR in cluster. This is what happens
when loading the package:Error in dyn.load(file, DLLpath = DLLpath, ...) :
unable to load shared object
'/home/dpustina/R/x86_64-unknown-linux-gnu-library/3.1/ANTsR/libs/ANTsR.so':
/home/dpustina/R/x86_64-unknown-linux-gnu-library/3.1/ANTsR/libs/ANTsR.so:
undefined symbol:
_ZN3itk24ImageToImageFilterCommon34GetGlobalDefaultDirectionToleranceEvIs this related to the problems described above? Do you advise to start
over with a clean build?Dorian
—
Reply to this email directly or view it on GitHub
#8 (comment).
from antsr.
bkandel
commented on August 30, 2024
@jeffduda Not sure what the status of the undocumented get/set antsImage
methods is. It looks like the best way to go about this would be to have
one common 'get-set' methods man file, like what R has for ?Normal. It
appears that it is possible to do this with Roxygen:
http://r-pkgs.had.co.nz/man.html#dry2
http://stackoverflow.com/questions/15932585/roxygen-two-functions-in-one-rd-file
If you haven't done this yet, I'll take a stab at it, but I don't want to
replicate your work if you've already done some of it.
On 4 February 2015 at 14:16, stnava [email protected] wrote:
Currently, there are a few undocumented code bits that @jeffduda
https://github.com/jeffduda will contribute. There are _many more
_inconsistent* documentation and usage functions. This is where the most
help is currently needed in order to get over the first major barrier to
submitting to CRAN. They are here:
- checking Rd \usage sections ... WARNING Undocumented arguments in
documentation object 'Atropos' ‘d’ ‘a’ ‘x’ ‘i’ ‘m’ ‘c’ ‘priorweight’ ‘...’
Duplicated \argument entries in documentation object 'Atropos': ‘list()’
‘list()’ ‘’ ‘list()’ ‘’ ‘list(list()’ ‘list()’ ‘’ ‘’ ‘’ ‘)')’ ‘list()’ ‘’
‘’ ‘’ ‘list(list()’ ‘list()’ ‘list()’ ‘list()’ ‘list()’ ‘list(list()’
‘list()’ ‘list(list()’ ‘list()’ ‘To’ Documented arguments not in \usage in
documentation object 'Atropos': ‘d-or-'image-dimensionality'=’
‘a-or-'intensity-image'=c(’ ‘’ ‘etc)’ ‘b-or-bspline=list(’ ‘’ ‘)’
‘i-or-initialization=’ ‘list(list()’ ‘list('list(name='Random'’ ‘)')’
‘list()’ ‘list('list(name='Otsu'’ ‘)')’ ‘list('list(name='KMeans'’ ‘’
‘)')’ ‘list('list(name='PriorProbabilityImages'’ ‘’ ‘’ ‘)')’
‘list('list(name='PriorLabelImage'’ ‘’ ‘)')’
‘s-or-'partial-volume-label-set'=’ ‘'use-partial-volume-likelihoods'=’
‘p-or-'posterior-formulation'=’ ‘list('list(name='Socrates'’ ‘’ ‘’ ‘’
‘)')’ ‘list('list(name='Plato'’ ‘list('list(name='Aristotle'’ ‘)'))’
‘x-or-'mask-image'=’ ‘c-or-convergence=list(’ ‘)’
‘k-or-'likelihood-model'=’ ‘list(''Gaussian'')’
‘list('list(name='HistogramParzenWindows'’ ‘’ ‘)')’
‘list('list(name='ManifoldParzenWindows'’ ‘’ ‘’ ‘’ ‘)')’
‘list('list(name='JointShapeAndOrientationProbability'’ ‘’ ‘’ ‘’ ‘)')’
‘list(''LogEuclideanGaussian'')’ ‘m-or-mrf=’ ‘list('list(’ ‘)')’
‘list('list(’ ‘)'))’ ‘g-or-icm=list(’ ‘’ ‘)’ ‘o-or-output=list(’ ‘)’
‘u-or-'minimize-memory-usage'=’ ‘w-or-'winsorize-outliers'=’
‘list('list(name=BoxPlot’ ‘’ ‘’ ‘)')’ ‘list('list(name=GrubbsRosner’ ‘’
‘)'))’ ‘e-or-'use-euclidean-distance'=’
‘l-or-'label-propagation'=list(name=whichLabel’ ‘’ ‘)’ ‘To’ ‘Different’
‘Both’ ‘Markov’Undocumented arguments in documentation object 'ImageMath'
‘...’
Documented arguments not in \usage in documentation object 'ImageMath':
‘imageDimension2|3’ ‘outputImage’ ‘operator’ ‘inputImage’
‘otherParams’Undocumented arguments in documentation object 'KellyKapowski'
‘d’ ‘outimg’ ‘...’
Documented arguments not in \usage in documentation object 'KellyKapowski':
‘imageDimension2|3|4’ ‘inputImage’Undocumented arguments in documentation object 'MeasureMinMaxMean'
‘mask’Undocumented arguments in documentation object 'N3BiasFieldCorrection'
‘...’
Documented arguments not in \usage in documentation object
'N3BiasFieldCorrection':
‘imageDimension2|3’ ‘inputImage’ ‘outputImage’ ‘shrikFactor’
‘maskImage’ ‘numberofIterations’ ‘numberofFittingLevels’
‘outputBiasField’Undocumented arguments in documentation object 'SmoothImage'
‘...’
Documented arguments not in \usage in documentation object 'SmoothImage':
‘imageDimension2|3|4’ ‘inputImage’ ‘Sigma’ ‘outputImage’Undocumented arguments in documentation object 'ThresholdImage'
‘...’
Documented arguments not in \usage in documentation object
'ThresholdImage':
‘imageDimension2|3’ ‘thresh-low’ ‘thresh-high’ ‘inside-value’
‘outside-value’ ‘number-of-thresholds’ ‘inputImage’ ‘outputImage’Undocumented arguments in documentation object 'abpBrainExtraction'
‘temmask’ ‘tempriors’ ‘tdir’
Documented arguments not in \usage in documentation object
'abpBrainExtraction':
‘tempriors=c(img1’ ‘imgN)’ ‘tmask’ ‘img2’Undocumented arguments in documentation object 'abpN4'
‘img’ ‘weightimg’
Documented arguments not in \usage in documentation object 'abpN4':
‘image’ ‘weightimage’Undocumented arguments in documentation object 'antsApplyTransforms'
‘moving’ ‘whichtoinvert’ ‘...’
Documented arguments not in \usage in documentation object
'antsApplyTransforms':
‘movingImage’Undocumented arguments in documentation object 'antsGetNeighborhood'
‘x’
Documented arguments not in \usage in documentation object
'antsGetNeighborhood':
‘image’Undocumented arguments in documentation object 'antsImage-class'
‘.Object’ ‘pixeltype’ ‘dimension’ ‘x’ ‘mask’ ‘region’ ‘i’ ‘j’ ‘e1’
‘e2’Undocumented arguments in documentation object 'antsMatrix-class'
‘.Object’ ‘elementtype’ ‘x’Undocumented arguments in documentation object 'antsMotionCorr'
‘...’
Documented arguments not in \usage in documentation object
'antsMotionCorr':
‘d-or-dimensionality=’Undocumented arguments in documentation object 'antsPreprocessfMRI'
‘maskingMeanRatioThreshold’ ‘residualizeMatrix’
Documented arguments not in \usage in documentation object
'antsPreprocessfMRI':
‘maskingThreshold’Undocumented arguments in documentation object 'antsRegistration'
‘moving’ ‘...’
Documented arguments not in \usage in documentation object
'antsRegistration':
‘movingImage’Undocumented arguments in documentation object 'as.antsImage'
‘pixeltype’ ‘spacing’ ‘origin’
Documented arguments not in \usage in documentation object 'as.antsImage':
‘data’ ‘Fun’Undocumented arguments in documentation object 'as.antsMatrix'
‘elementtype’
Documented arguments not in \usage in documentation object 'as.antsMatrix':
‘Fun’Undocumented arguments in documentation object 'aslDenoiseR'
‘boldmatrix’ ‘targety’ ‘motionparams’ ‘selectionthresh’
‘maxnoisepreds’ ‘debug’ ‘polydegree’ ‘crossvalidationgroups’
‘scalemat’ ‘noisepoolfun’ ‘usecompcor’
Documented arguments not in \usage in documentation object 'aslDenoiseR':
‘mat’Undocumented arguments in documentation object 'aslPerfusion'
‘asl’ ‘maskThresh’ ‘moreaccurate’ ‘dorobust’ ‘m0’ ‘skip’ ‘mask’
‘interpolation’ ‘checkmeansignal’ ‘moco_results’ ‘regweights’
‘useDenoiser’ ‘useBayesian’ ‘verbose’ ‘ncompcor’ ‘N3’
Documented arguments not in \usage in documentation object 'aslPerfusion':
‘maskThresh=’ ‘dorobust=’
‘asl_antsr_image_or_filename’Documented arguments not in \usage in documentation object 'basicInpaint':
‘speedimage’ ‘its’ ‘gparam’
Assignments in \usage in documentation object 'basicInpaint':
approximg <- basicInpaint(img, paintMask)Undocumented arguments in documentation object 'bayesianCBF'
‘seg’
Documented arguments not in \usage in documentation object 'bayesianCBF':
‘segmentation’Undocumented arguments in documentation object 'bayesianlm'
‘priorPrecision’ ‘priorIntercept’ ‘regweights’
Documented arguments not in \usage in documentation object 'bayesianlm':
‘precisionMatrix’Undocumented arguments in documentation object 'clusterTimeSeries'
‘mat’ ‘nsvddims’ ‘criterion’
Documented arguments not in \usage in documentation object
'clusterTimeSeries':
‘img’ ‘mask’Undocumented arguments in documentation object 'compcor'
‘fmri’ ‘ncompcor’ ‘variance_extreme’ ‘mask’ ‘fastsvd’ ‘useimagemath’
‘randomSamples’ ‘returnhighvarmatinds’ ‘highvarmatinds’
Documented arguments not in \usage in documentation object 'compcor':
‘mat’ ‘returnhighvarmat’Undocumented arguments in documentation object 'corw'
‘weights’Undocumented arguments in documentation object 'eigSeg'
‘imgList’
Documented arguments not in \usage in documentation object 'eigSeg':
‘imageList’Undocumented arguments in documentation object 'fastwhiten'
‘x’ ‘mynu’
Documented arguments not in \usage in documentation object 'fastwhiten':
‘mat’Undocumented arguments in documentation object
'filterfMRIforNetworkAnalysis'
‘aslmat’ ‘tr’ ‘freqLo’ ‘freqHi’ ‘cbfnetwork’ ‘mask’ ‘labels’
‘graphdensity’ ‘seg’ ‘useglasso’ ‘nuisancein’ ‘usesvd’ ‘robustcorr’
Documented arguments not in \usage in documentation object
'filterfMRIforNetworkAnalysis':
‘tr=’ ‘freqLo=’ ‘freqHi=’ ‘cbfnetwork="ASLCBF"’
‘maskThresh=’ ‘smoother=’ ‘outputprefix=’
‘asl_antsr_image_or_filename’Undocumented arguments in documentation object 'frequencyFilterfMRI'
‘boldmat’ ‘tr’ ‘freqLo’ ‘freqHi’ ‘opt’
Documented arguments not in \usage in documentation object
'frequencyFilterfMRI':
‘tr=’ ‘freqLo=’ ‘freqHi=’ ‘opt=c('trig'’
‘'butt'’ ‘'stl')’ ‘boldMatrix’Undocumented arguments in documentation object 'getAverageOfTimeSeries'
‘timeseriesimage’
Documented arguments not in \usage in documentation object
'getAverageOfTimeSeries':
‘img’Undocumented arguments in documentation object 'getCentroids'
‘outprefix’Undocumented arguments in documentation object
'getMultivariateTemplateCoordinates'
‘templateWithLabels’ ‘labelnames’ ‘outprefix’ ‘convertToTal’
‘threshparam’ ‘clustparam’ ‘identifier’Undocumented arguments in documentation object 'getROIValues'
‘maskImage’
Duplicated \argument entries in documentation object 'getROIValues':
‘valueImage’Undocumented arguments in documentation object 'getTemplateCoordinates'
‘imagePairToBeLabeled’ ‘templatePairWithLabels’ ‘labelnames’
‘outprefix’ ‘convertToTal’
Documented arguments not in \usage in documentation object
'getTemplateCoordinates':
‘x’Undocumented arguments in documentation object 'getfMRInuisanceVariables'
‘fmri’ ‘moreaccurate’
Documented arguments not in \usage in documentation object
'getfMRInuisanceVariables':
‘boldImageOrFileName’Undocumented arguments in documentation object 'icawhiten'
‘Xin’ ‘verbose’
Documented arguments not in \usage in documentation object 'icawhiten':
‘mat’Undocumented arguments in documentation object 'image2ClusterImages'
‘x’ ‘minClusterSize’ ‘minThresh’ ‘maxThresh’
Documented arguments not in \usage in documentation object
'image2ClusterImages':
‘img’Undocumented arguments in documentation object 'imageFileNames2ImageList'
‘dim’Undocumented arguments in documentation object 'initializeEigenanatomy'
‘initmat’
Documented arguments not in \usage in documentation object
'initializeEigenanatomy':
‘mat’Undocumented arguments in documentation object 'inspectImageData3D'
‘myfiles’
Documented arguments not in \usage in documentation object
'inspectImageData3D':
‘fn’Undocumented arguments in documentation object 'interleaveMatrixWithItself'
‘x’ ‘n’
Documented arguments not in \usage in documentation object
'interleaveMatrixWithItself':
‘mat’Undocumented arguments in documentation object 'invariantImageSimilarity'
‘in_image1’ ‘in_image2’ ‘txfn’
Documented arguments not in \usage in documentation object
'invariantImageSimilarity':
‘fixedImg’ ‘movingImg’ ‘txFilename’Undocumented arguments in documentation object 'joinEigenanatomy'
‘list_of_eanat_images’ ‘verbose’
Documented arguments not in \usage in documentation object
'joinEigenanatomy':
‘listEanatImages’Undocumented arguments in documentation object 'kmeansSegmentation'
‘img’ ‘kmask’ ‘mrf’Undocumented arguments in documentation object 'labelClusters'
‘imagein’ ‘minClusterSize’ ‘minThresh’ ‘maxThresh’
Documented arguments not in \usage in documentation object 'labelClusters':
‘img’Undocumented arguments in documentation object 'lappend'
‘lst’ ‘obj’
Documented arguments not in \usage in documentation object 'lappend':
‘inlist’ ‘myitem’Undocumented arguments in documentation object 'makeGraph'
‘myrsfnetworkcorrsin’ ‘getEfficiency’
Documented arguments not in \usage in documentation object 'makeGraph':
‘mat’Undocumented arguments in documentation object 'makeImage'
‘imagesize’ ‘voxval’
Documented arguments not in \usage in documentation object 'makeImage':
‘mat’ ‘val’Documented arguments not in \usage in documentation object
'matrixToImages':
‘outputRoot’Undocumented arguments in documentation object 'mni2tal'
‘xin’
Documented arguments not in \usage in documentation object 'mni2tal':
‘x’Undocumented arguments in documentation object 'networkEiganat'
‘Xin’ ‘sparseness’ ‘nvecs’ ‘its’ ‘gradparam’ ‘mask’ ‘v’ ‘prior’
‘pgradparam’ ‘clustval’ ‘downsample’ ‘doscale’ ‘domin’ ‘verbose’
‘dowhite’ ‘timeme’ ‘addb’ ‘useregression’
Documented arguments not in \usage in documentation object
'networkEiganat':
‘inmatrix’ ‘inmask’ ‘otherparams’Undocumented arguments in documentation object
'pairwiseImageDistanceMatrix'
‘metrictype’ ‘nclusters’Undocumented arguments in documentation object 'partialVolumeCorrection'
‘img’ ‘img.gm’ ‘img.wm’
Documented arguments not in \usage in documentation object
'partialVolumeCorrection':
‘image’ ‘image.gm’ ‘image.wm’Undocumented arguments in documentation object 'perfusionregression'
‘skip’ ‘selectionValsForRegweights’ ‘useBayesian’
Documented arguments not in \usage in documentation object
'perfusionregression':
‘m0’Undocumented arguments in documentation object 'plot.antsImage'
‘color’ ‘axis’ ‘slices’ ‘threshold’ ‘quality’ ‘outname’ ‘alpha’ ‘...’
Documented arguments not in \usage in documentation object
'plot.antsImage':
‘color=’ ‘axis=’ ‘slices=’
‘threshold=’ ‘quality=’ ‘outname='figx.jpg'’Undocumented arguments in documentation object 'plotBasicNetwork'
‘weights’ ‘edgecolors’ ‘nodecolors’ ‘nodetype’ ‘scaling’ ‘lwd’
‘radius’ ‘showOnlyConnectedNodes’Undocumented arguments in documentation object 'plotPrettyGraph'
‘functionToPlot’ ‘hueval’
Documented arguments not in \usage in documentation object
'plotPrettyGraph':
‘graphMetricValue’Undocumented arguments in documentation object 'projectImageAlongAxis'
‘imageND’ ‘referenceImageNDminus1’
Documented arguments not in \usage in documentation object
'projectImageAlongAxis':
‘img4d’ ‘refimg3d’Undocumented arguments in documentation object 'quantifyCBF'
‘perfusion’ ‘mask’ ‘M0val’ ‘outlierValue’
Documented arguments not in \usage in documentation object 'quantifyCBF':
‘aslmat’ ‘aslmask’Undocumented arguments in documentation object 'regressionNetworkViz'
‘mylm’ ‘sigthresh’ ‘whichviz’ ‘outfile’ ‘mygroup’ ‘logvals’ ‘verbose’
‘correlateMyOutcomes’ ‘corthresh’ ‘zoom’ ‘doFDR’
Documented arguments not in \usage in documentation object
'regressionNetworkViz':
‘myLM’Undocumented arguments in documentation object 'renderImageLabels'
‘blobrender’ ‘alphafunc’ ‘outdir’ ‘outfn’ ‘labels’Undocumented arguments in documentation object 'renderNetwork'
‘nodecolors’Undocumented arguments in documentation object 'renderSurfaceFunction'
‘smoothsval’ ‘smoothfval’ ‘alphasurf’ ‘alphafunc’ ‘outdir’ ‘outfn’
‘mycol’ ‘physical’Undocumented arguments in documentation object 'reorientImage'
‘axis1’ ‘doscale’
Documented arguments not in \usage in documentation object 'reorientImage':
‘axis’Undocumented arguments in documentation object 'rfSegmentation'
‘labelimg’ ‘ntrees’ ‘verbose’
Documented arguments not in \usage in documentation object
'rfSegmentation':
‘labelimage’Undocumented arguments in documentation object 'rfSegmentationPredict'
‘rfSegmentationModel’ ‘mask’ ‘verbose’
Documented arguments not in \usage in documentation object
'rfSegmentationPredict':
‘model’Undocumented arguments in documentation object 'rsfDenoise'
‘boldmatrix’ ‘targety’ ‘motionparams’ ‘selectionthresh’
‘maxnoisepreds’ ‘debug’ ‘polydegree’ ‘crossvalidationgroups’ ‘tr’
‘scalemat’ ‘noisepoolfun’
Documented arguments not in \usage in documentation object 'rsfDenoise':
‘mat’Undocumented arguments in documentation object 'sparseDecom'
‘sparseness’ ‘nvecs’ ‘its’ ‘cthresh’ ‘statdir’ ‘z’ ‘smooth’
‘initializationList’ ‘mycoption’ ‘robust’ ‘ell1’
Documented arguments not in \usage in documentation object 'sparseDecom':
‘otherparams’Undocumented arguments in documentation object 'sparseDecom2'
‘sparseness’ ‘nvecs’ ‘its’ ‘cthresh’ ‘statdir’ ‘perms’ ‘uselong’ ‘z’
‘smooth’ ‘robust’ ‘mycoption’ ‘initializationList’
‘initializationList2’ ‘ell1’
Documented arguments not in \usage in documentation object 'sparseDecom2':
‘otherparams’Undocumented arguments in documentation object 'sparseDecom2boot'
‘sparseness’ ‘nvecs’ ‘its’ ‘cthresh’ ‘statdir’ ‘perms’ ‘uselong’ ‘z’
‘smooth’ ‘robust’ ‘mycoption’ ‘initializationList’
‘initializationList2’ ‘ell1’ ‘doseg’
Documented arguments not in \usage in documentation object
'sparseDecom2boot':
‘otherparams’Undocumented arguments in documentation object 'sparseDecomboot'
‘sparseness’ ‘nvecs’ ‘its’ ‘cthresh’ ‘statdir’ ‘z’ ‘smooth’
‘initializationList’ ‘mycoption’ ‘robust’ ‘doseg’
Documented arguments not in \usage in documentation object
'sparseDecomboot':
‘otherparams’Undocumented arguments in documentation object 'subgradientL1Regression'
‘s’ ‘percentvals’ ‘nits’ ‘betas’ ‘sparval’Undocumented arguments in documentation object 'taskFMRI'
‘mat’ ‘hrf’ ‘myvars’ ‘correctautocorr’ ‘residualizedesignmatrix’
‘myformula’
Documented arguments not in \usage in documentation object 'taskFMRI':
‘fmriMatrix’ ‘blockDesign’Undocumented arguments in documentation object 'temporalwhiten'
‘myord’Undocumented arguments in documentation object 'timeseriesN3'
‘boldimg’
Documented arguments not in \usage in documentation object 'timeseriesN3':
‘mat’Bad \usage lines found in documentation object 'combineNuisancePredictors':
combineNuisancePredictors <- function(inmat, target,
globalpredictors=NA, localpredictors=NA, maxpreds=4, k=5)Functions with \usage entries need to have the appropriate \alias
entries, and all their arguments documented.
The \usage entries must correspond to syntactically valid R code.
See the chapter ‘Writing R documentation files’ in the ‘Writing R
Extensions’ manual.—
Reply to this email directly or view it on GitHub
#8 (comment).
from antsr.
dorianps
commented on August 30, 2024
@stnava Thanks, a clean install resolved the problem.
from antsr.
jeffduda
commented on August 30, 2024
@bkandel https://github.com/bkandel, I haven't had a chance to work on
that yet, but I agree that a common man file would be best if possible.
On Thu, Feb 5, 2015 at 1:04 PM, dorianps [email protected] wrote:
@stnava https://github.com/stnava Thanks, a clean install resolved the
problem.—
Reply to this email directly or view it on GitHub
#8 (comment).
from antsr.
stnava
commented on August 30, 2024
We crushed it over the last few days. Here is the new R CMD check result:
- using log directory ‘/Users/stnava/Downloads/temp/ANTsR.Rcheck’
- using R version 3.1.2 (2014-10-31)
- using platform: x86_64-apple-darwin13.4.0 (64-bit)
- using session charset: UTF-8
- using options ‘--no-install --no-examples’
- checking for file ‘ANTsR/DESCRIPTION’ ... OK
- checking extension type ... Package
- this is package ‘ANTsR’ version ‘1.0’
- checking CRAN incoming feasibility ... NOTE
Maintainer: ‘Brian B. Avants [email protected]’
New submission - checking if this is a source package ... OK
- checking if there is a namespace ... OK
- checking for executable files ... OK
- checking for hidden files and directories ... OK
- checking for portable file names ... OK
- checking for sufficient/correct file permissions ... OK
- checking package directory ... OK
- checking DESCRIPTION meta-information ... OK
- checking top-level files ... OK
- checking for left-over files ... OK
- checking index information ... OK
- checking package subdirectories ... OK
- checking R files for non-ASCII characters ... OK
- checking R files for syntax errors ... OK
- checking dependencies in R code ... OK
- checking S3 generic/method consistency ... OK
- checking replacement functions ... OK
- checking foreign function calls ... OK
- checking R code for possible problems ... OK
- checking Rd files ... OK
- checking Rd metadata ... OK
- checking Rd line widths ... OK
- checking Rd cross-references ... OK
- checking for missing documentation entries ... WARNING
Undocumented code objects:
‘antsCopyImageInfo’ ‘antsGetPixels’ ‘antsMotionCorrStats’
‘antsSetPixels’ ‘antsTransformIndexToPhysicalPoint’
‘antsTransformPhysicalPointToIndex’ ‘as.data.frame.antsMatrix’
All user-level objects in a package should have documentation entries.
See the chapter ‘Writing R documentation files’ in the ‘Writing R
Extensions’ manual. - checking for code/documentation mismatches ... OK
- checking Rd \usage sections ... WARNING
Undocumented arguments in documentation object 'antsImage-class'
‘.Object’ ‘pixeltype’ ‘dimension’ ‘x’ ‘mask’ ‘region’ ‘i’ ‘j’ ‘e1’
‘e2’
Undocumented arguments in documentation object 'antsMatrix-class'
‘.Object’ ‘elementtype’ ‘x’
Undocumented arguments in documentation object 'as.antsImage'
‘pixeltype’ ‘spacing’ ‘origin’
Documented arguments not in \usage in documentation object 'as.antsImage':
‘data’ ‘Fun’
Undocumented arguments in documentation object 'as.antsMatrix'
‘elementtype’
Documented arguments not in \usage in documentation object 'as.antsMatrix':
‘Fun’
Functions with \usage entries need to have the appropriate \alias
entries, and all their arguments documented.
The \usage entries must correspond to syntactically valid R code.
See the chapter ‘Writing R documentation files’ in the ‘Writing R
Extensions’ manual.
- checking Rd contents ... OK
- checking contents of ‘data’ directory ... OK
- checking data for non-ASCII characters ... OK
- checking data for ASCII and uncompressed saves ... OK
- checking line endings in C/C++/Fortran sources/headers ... OK
- checking line endings in Makefiles ... OK
- checking compilation flags in Makevars ... OK
- checking for portable use of
$(BLAS_LIBS) and $ (LAPACK_LIBS) ... OK - checking examples ... SKIPPED
- checking PDF version of manual ... OK
- DONE
WARNING: There were 2 warnings.
NOTE: There was 1 note.
from antsr.
stnava
commented on August 30, 2024
Current state on OSX Yosemite:
- all examples run well with dependencies installed (and likely even without, though i've not tested this recently)
- almost all code is documented ( except above ) hopefully can figure out above soon
- compile time remains an issue that will bother cran - may be helped by "thin ants"
- example run time remains an issue that will bother cran but this can be fixed w/just a little effort
- checking examples ... OK
Examples with CPU or elapsed time > 5s
user system elapsed
combineNuisancePredictors 135.926 9.865 90.198
getASLNoisePredictors 87.043 5.630 37.793
antsMotionCalculation 84.499 5.454 35.636
antsGetNeighborhoodMatrix 11.707 0.930 12.812 - much of the time cost in some examples is in downloading data
- package footprint may be an issue but seems to be under official 100MB limit --- need to check this again .... the result of R cmd build is under 500k ....
- will be some small issues with MAKEFILE and git calls but @jeffduda is working on this
that's all i can think of at the moment re:cran... other design issues include
- quality of documentation is inconsistent
- should have rimageMath to complement ImageMath with the former following R style and the latter ANTs style
- similar for other functions ...
- need a vignette ...
am ultimately hopeful these issues may be overcome .... but if not, perhaps install_github isnt so bad .... esp if we have well-documented code with use-cases etc readily available.
from antsr.
stnava
commented on August 30, 2024
ok - major progress: no documentation inconsistencies for the first time ... but still some undocumented code:
Undocumented code objects:
‘antsCopyImageInfo’ ‘antsGetPixels’ ‘antsMotionCorrStats’
‘antsSetPixels’ ‘antsTransformIndexToPhysicalPoint’
‘antsTransformPhysicalPointToIndex’
am reading through the antsr manual and correcting typos etc though this will probably take several iterations to get right.
- inconsistent use of quotations is a major annoyance
- need to use double quotes "r16" to keep the quotations in the final documentation pdf
so we are down to 1 warning ...
from antsr.
jeffduda
commented on August 30, 2024
will work on adding in that documentation now.
On Fri, Feb 6, 2015 at 12:24 PM, stnava [email protected] wrote:
ok - major progress: no documentation inconsistencies for the first
time ... but still some undocumented code:Undocumented code objects:
‘antsCopyImageInfo’ ‘antsGetPixels’ ‘antsMotionCorrStats’
‘antsSetPixels’ ‘antsTransformIndexToPhysicalPoint’
‘antsTransformPhysicalPointToIndex’am reading through the antsr manual and correcting typos etc though this
will probably take several iterations to get right.
inconsistent use of quotations is a major annoyance
need to use double quotes "r16" to keep the quotations in the final
documentation pdfso we are down to 1 warning ...
—
Reply to this email directly or view it on GitHub
#8 (comment).
from antsr.
stnava
commented on August 30, 2024
re STYLE: have mostly eliminated calls of the form FunctionName(dim, img, ... ) and replaced with functionName( img , ... ) stragglers include:
- ThresholdImage
- ImageMath
for the latter, i will implement antsImageMath with usage similar to:
output<-iMath( img,"operationName", ... )
and (maybe) where you will be able to do
ops<-iMath("GetOperations")
to see its possible uses ...
will keep ImageMath(...) around but replace with iMath in documentation examples ....
any suggestions welcome before i start this ....
from antsr.
jeffduda
commented on August 30, 2024
probably worth getting rid of antsMotionCorrStats.R for now and build a
R-native version of something similar in the future.
On Fri, Feb 6, 2015 at 1:02 PM, stnava [email protected] wrote:
re STYLE: have mostly eliminated calls of the form FunctionName(dim, img,
... ) and replaced with functionName( img , ... ) stragglers include:
ThresholdImage
ImageMath
for the latter, i will implement antsImageMath with usage similar to:
output<-iMath( img,"operationName", ... )
and (maybe) where you will be able to do
ops<-iMath("GetOperations")
to see its possible uses ...
will keep ImageMath(...) around but replace with iMath in documentation
examples ....any suggestions welcome before i start this ....
—
Reply to this email directly or view it on GitHub
#8 (comment).
from antsr.
stnava
commented on August 30, 2024
as of commit: 2e32fb7
we have 0 example errors ( though some are in dontrun ) and 0 documentation issues ...
@bkandel : i "hid" antsMotionCorrStats since it is only called as a helper function anyway
the current ants reference manual is here: http://we.tl/LI0tQSS7PE ( link active for 7 days )
from antsr.
stnava
commented on August 30, 2024
hmm real cran check produces additional warnings:
- not sure about this one
Undocumented S4 methods:
generic '[' and siglist 'antsImage,NULL,NULL'
generic '[' and siglist 'antsImage,NULL,numeric'
generic '[' and siglist 'antsImage,numeric,NULL'
generic '[' and siglist 'antsImage,numeric,numeric'
generic '[<-' and siglist 'antsImage,NULL,ANY,ANY'
generic '[<-' and siglist 'antsImage,NULL,NULL,numeric'
generic '[<-' and siglist 'antsImage,NULL,antsRegion,ANY'
generic '[<-' and siglist 'antsImage,NULL,numeric,numeric'
generic '[<-' and siglist 'antsImage,array,ANY,ANY'
generic '[<-' and siglist 'antsImage,array,antsRegion,ANY'
generic '[<-' and siglist 'antsImage,list,ANY,ANY'
generic '[<-' and siglist 'antsImage,logical,ANY,ANY'
generic '[<-' and siglist 'antsImage,logical,antsRegion,ANY'
generic '[<-' and siglist 'antsImage,matrix,ANY,ANY'
generic '[<-' and siglist 'antsImage,matrix,antsRegion,ANY'
generic '[<-' and siglist 'antsImage,numeric,NULL,numeric'
generic '[<-' and siglist 'antsImage,numeric,numeric,numeric'
generic 'as.list' and siglist 'antsImageList'
- another oddball ... no cerr in that code ... must be in a linked library ...
- checking compiled code ... NOTE
File ‘ANTsR/libs/ANTsR.so’:
Found ‘__ZNSt3__14cerrE’, possibly from ‘std::cerr’ (C++)
Object: ‘invariantImageSimilarity.o’
- presumably can clean up this one via cleanup
- checking package subdirectories ... WARNING
Found the following directories with names of version control directories:
./src/ANTS/ANTS-build/ITKv4/.git
./src/ANTS/ANTS-build/ITKv4/Modules/Remote/MGHIO/.git
./src/ANTS/ANTS-src/.git
from antsr.
muschellij2
commented on August 30, 2024
So I've been following this thread closely and I didn't give a lot of
feedback because you guys are doing fantastic.
I'm sure it was a hurdle getting R CMD check to work but I'm very excited
for this package to be on CRAN!
On Feb 6, 2015 2:59 PM, "stnava" [email protected] wrote:
we have 0 example errors ( though some are in dontrun ) and 0
documentation issues ...@bkandel https://github.com/bkandel : i "hid" antsMotionCorrStats since
it is only called as a helper function anywaythe current ants reference manual is here: http://we.tl/LI0tQSS7PE ( link
active for 7 days )—
Reply to this email directly or view it on GitHub
#8 (comment).
from antsr.
bkandel
commented on August 30, 2024
I don't think we really need ThresholdImage now that we can just do
img[img<thresh] <- 0 or whatever. It was more useful when everything was
a command-line binary.
I would also move for throwing out ImageMath and only keep imageMath (with
R style) -- having two nearly identical commands that do different things
is bound to be a source of confusion.
On 6 February 2015 at 16:34, John Muschelli [email protected]
wrote:
So I've been following this thread closely and I didn't give a lot of
feedback because you guys are doing fantastic.I'm sure it was a hurdle getting R CMD check to work but I'm very excited
for this package to be on CRAN!
On Feb 6, 2015 2:59 PM, "stnava" [email protected] wrote:as of commit: 2e32fb7
<
2e32fb7we have 0 example errors ( though some are in dontrun ) and 0
documentation issues ...@bkandel https://github.com/bkandel : i "hid" antsMotionCorrStats
since
it is only called as a helper function anywaythe current ants reference manual is here: http://we.tl/LI0tQSS7PE (
link
active for 7 days )—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).
from antsr.
stnava
commented on August 30, 2024
understood - but one reason to keep the older version is it's still useful
for some functions that dont actually match the R variant syntax.
probably best dealt with by recommending ( via link in ImageMath
documentation ) that people use iMath ...
ThresholdImage is now thresholdImage so it'll stick around mainly b/c it's
used in several places and is much faster ( i think ) than the equivalent R
operation ...
am now working on getting this https://travis-ci.org/stnava/ANTsR right
it's pretty close, i think ....
brian
On Fri, Feb 6, 2015 at 4:50 PM, bkandel [email protected] wrote:
I don't think we really need ThresholdImage now that we can just do
img[img<thresh] <- 0 or whatever. It was more useful when everything was
a command-line binary.I would also move for throwing out ImageMath and only keep imageMath (with
R style) -- having two nearly identical commands that do different things
is bound to be a source of confusion.On 6 February 2015 at 16:34, John Muschelli [email protected]
wrote:So I've been following this thread closely and I didn't give a lot of
feedback because you guys are doing fantastic.I'm sure it was a hurdle getting R CMD check to work but I'm very excited
for this package to be on CRAN!
On Feb 6, 2015 2:59 PM, "stnava" [email protected] wrote:as of commit: 2e32fb7
<we have 0 example errors ( though some are in dontrun ) and 0
documentation issues ...@bkandel https://github.com/bkandel : i "hid" antsMotionCorrStats
since
it is only called as a helper function anywaythe current ants reference manual is here: http://we.tl/LI0tQSS7PE (
link
active for 7 days )—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).
from antsr.
stnava
commented on August 30, 2024
OK - this is finally set up (more or less) correctly for antsr
https://travis-ci.org/stnava/ANTsR
so we can see whether builds (on linux and osx in the future http://docs.travis-ci.com/user/multi-os/ ) are passing, which includes a coarse R CMD check call ...
the results are displayed in the red/green badge on http://stnava.github.io/ANTsR/ or on the github page
these builds also trigger an email to whoever wants one ( currently only me ) which indicate pass / failure and show the build log ...
this was already set up on ants thanks to @armaneshaghi and i built from his work ... there remain some issues wrt which specific compile configuration is most stable for travis but i'll keep testing til it's settled.
from antsr.
armaneshaghi
commented on August 30, 2024
We could also add automatic coverage testing similar to dplyr , but I need Brian to activate coverall for ANTsR here if everyone agrees. I will then start writing test codes.
CRAN requires each package to have the following structure, and we are still missing tests
• A file named DESCRIPTION with descriptions of the package, author, and license conditions in a structured text format that is readable by computers and by people.
• A man/ subdirectory of documentation files.
• An R/ subdirectory of R code.
• A data/ subdirectory of datasets.
Less commonly it contains
• A src/ subdirectory of C, Fortran or C++ source.
• tests/ for validation tests.
• exec/ for other executables (eg Perl or Java).
• inst/ for miscellaneous other stuff. The contents of this directory are completely copied to the installed version of a package.
• A configure script to check for other required software or handle differences between sys- tems.
from antsr.
armaneshaghi
commented on August 30, 2024
also we need a license file that CRAN understands, I recommend creative commons, but you have other options
EDIT: sorry, found the license in DESCRIPTION file
from antsr.
stnava
commented on August 30, 2024
we have GPL >= 2 - following https://github.com/RcppCore/Rcpp
brian
On Mon, Feb 9, 2015 at 6:17 AM, Arman Eshaghi [email protected]
wrote:
also we need a license file that CRAN understands, I recommend creative
commons, but you have other options
https://svn.r-project.org/R/trunk/share/licenses/license.db—
Reply to this email directly or view it on GitHub
#8 (comment).
from antsr.
stnava
commented on August 30, 2024
happy to try this ... will activate momentarily
brian
On Mon, Feb 9, 2015 at 6:17 AM, Arman Eshaghi [email protected]
wrote:
also we need a license file that CRAN understands, I recommend creative
commons, but you have other options
https://svn.r-project.org/R/trunk/share/licenses/license.db—
Reply to this email directly or view it on GitHub
#8 (comment).
from antsr.
stnava
commented on August 30, 2024
The saga continues though we are very close to having a clean and efficient ANTsR build.
This "pure" CRAN check:
R CMD INSTALL ANTsR
R CMD build ANTsR
R CMD check ANTsR_1.0.tar.gz --as-cran
produces several issues:
- it uncovered some actual bugs which i fixed ( not pushed yet )
- it uncovers namespace issues e.g. functions that you call but which are not resolved ... our "usePkg" trick can't get past this afaik. two options
- we add all actual dependencies as defined by cran - this is a long list ... i will update antsr with the full list in a little bit ... ultimately, we can "back out" these changes once we get the CRAN check to pass which will get us back to a "quick loading" antsr ( agree this is very desirable ) ... furthermore, for development, we can always go back to a simplified DESCRIPTION/NAMESPACE and change to the CRAN ready DESCRIPTION/NAMESPACE as needed
- we make a different (R code only) project ANTsRMas which has (1) extra test data (2) houses functions that cause lots (unwanted) dependencies to increase ... e.g. rapidlyInspectImageData, plotPrettyGraph, frequencyFilterfMRI, antsSpatialICAfMRI.R .... i already have an "extra" package that could be repurposed for this and which has some useful stuff in it anyway : RKRNS ... we could add (more) data and these extra functions ... this would clean up ANTsR a bit ... but then we'd have to get 2 repos on CRAN to enable full functionality .... or just accept this 2nd one would be an install_github which would be easy b/c it would be fast.
- a long list of this
generic '[' and siglist 'antsImage,NULL,ANY,ANY'
... and ...
generic '[<-' and siglist 'antsImage,NULL,ANY,ANY'
...
related to our versions of: http://stackoverflow.com/questions/10961842/how-to-define-the-subset-operators-for-a-s4-class
this last one is tricky b/c it take a long time to test at least i havent figured out a way to get the check for this w/o a full install from scratch ...
from antsr.
armaneshaghi
commented on August 30, 2024
I'm stuck here for travis after R CMD build ANTsR:
Error: processing vignette 'ANTsR.Rmd' failed with diagnostics: 'html_vignette' is not an exported object from 'namespace:rmarkdown'
First it was a problem with pandoc version, but now seems to be something else
from antsr.
bkandel
commented on August 30, 2024
Why can't we use Suggests for all of the extra packages that are only
occasionally needed? That shouldn't affect installation or loading speed,
and we'd be able to keep all the functions in ANTsR.
In any case, I think we should have some centralized list of all packages
needed at one time or another in ANTsR.
It may not be a bad idea to have a "core" ANTsR and a "bells and whistles"
version that would do more, but I'm not sure it's really worth it. I think
having a decent set of vignettes would go a long way to making the basic
functions not get lost in all the more specialized stuff.
On 9 February 2015 at 11:36, stnava [email protected] wrote:
The saga continues though we are very close to having a clean and
efficient ANTsR build.This "pure" CRAN check:
R CMD INSTALL ANTsR
R CMD build ANTsR
R CMD check ANTsR_1.0.tar.gz --as-cranproduces several issues:
it uncovered some actual bugs which i fixed ( not pushed yet )
2.it uncovers namespace issues e.g. functions that you call but which
are not resolved ... our "usePkg" trick can't get past this afaik. two
options
-we add all actual dependencies as defined by cran - this is a long list ... i will update antsr with the full list in a little bit ... ultimately, we can "back out" these changes once we get the CRAN check to pass which will get us back to a "quick loading" antsr ( agree this is very desirable ) ... furthermore, for development, we can always go back to a simplified DESCRIPTION/NAMESPACE and change to the CRAN ready DESCRIPTION/NAMESPACE as needed - we make a different (R code only) project ANTsRMas which has (1) extra test data (2) houses functions that cause lots (unwanted) dependencies to increase ... e.g. rapidlyInspectImageData, plotPrettyGraph, frequencyFilterfMRI, antsSpatialICAfMRI.R .... i already have an "extra" package that could be repurposed for this and which has some useful stuff in it anyway : RKRNS ... we could add (more) data and these extra functions ... this would clean up ANTsR a bit ... but then we'd have to get 2 repos on CRAN to enable full functionality .... or just accept this 2nd one would be an install_github which would be easy b/c it would be fast. 3.a long list of this
generic '[' and siglist 'antsImage,NULL,ANY,ANY'
... and ...
generic '[<-' and siglist 'antsImage,NULL,ANY,ANY'
...this last one is tricky b/c it take a long time to test at least i havent
figured out a way to get the check for this w/o a full install from scratch
...—
Reply to this email directly or view it on GitHub
#8 (comment).
from antsr.
stnava
commented on August 30, 2024
"Suggests" contributes to the problem - names of functions dont get imported thus triggering several different types of check failures. Importing is what's time consuming on startup.
from antsr.
bkandel
commented on August 30, 2024
Would using "suggests" also trigger failures if all the functions were
accessed via '::' calls?
On 9 February 2015 at 12:05, stnava [email protected] wrote:
"Suggests" contributes to the problem - names of functions dont get
imported thus triggering several different types of check failures.
Importing is what's time consuming on startup.—
Reply to this email directly or view it on GitHub
#8 (comment).
from antsr.
stnava
commented on August 30, 2024
yes - those are prohibited
brian
On Mon, Feb 9, 2015 at 12:14 PM, bkandel [email protected] wrote:
Would using "suggests" also trigger failures if all the functions were
accessed via '::' calls?On 9 February 2015 at 12:05, stnava [email protected] wrote:
"Suggests" contributes to the problem - names of functions dont get
imported thus triggering several different types of check failures.
Importing is what's time consuming on startup.—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).
from antsr.
bkandel
commented on August 30, 2024
The R extension manual (
http://cran.r-project.org/doc/manuals/r-release/R-exts.html#Package-Dependencies)
says:
R code in the package should call library or require only exceptionally.
Such calls are never needed for packages listed in ‘Depends’ as they will
already be on the search path. It used to be common practice to use require
calls for packages listed in ‘suggests’ in functions which used their
functionality, but nowadays it is better to access such functionality via
:: calls.
Doesn't this imply that Suggests + :: calls are acceptable? (Or,
'exceptionally', to use require, but in any case Suggests + using external
packages should be allowed.)
On 9 February 2015 at 12:20, stnava [email protected] wrote:
yes - those are prohibited
brian
On Mon, Feb 9, 2015 at 12:14 PM, bkandel [email protected] wrote:
Would using "suggests" also trigger failures if all the functions were
accessed via '::' calls?On 9 February 2015 at 12:05, stnava [email protected] wrote:
"Suggests" contributes to the problem - names of functions dont get
imported thus triggering several different types of check failures.
Importing is what's time consuming on startup.—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).
from antsr.
stnava
commented on August 30, 2024
yes - maybe you are right .... definitely ::: is prohibited ...
if you want to pursue this, then you can try the following:
(1) change imports to suggests
(2) using NAMESPACE as a guide, identify all the functions that need ::
and then fix them ...
(3) test with
R CMD INSTALL ANTsR
R CMD build ANTsR
R CMD check ANTsR_1.0.tar.gz --as-cran
i am making progress with the operators but not there yet ...
brian
On Mon, Feb 9, 2015 at 12:39 PM, bkandel [email protected] wrote:
The R extension manual (
http://cran.r-project.org/doc/manuals/r-release/R-exts.html#Package-Dependencies
)
says:
R code in the package should call library or require only exceptionally.
Such calls are never needed for packages listed in ‘Depends’ as they will
already be on the search path. It used to be common practice to use require
calls for packages listed in ‘suggests’ in functions which used their
functionality, but nowadays it is better to access such functionality via
:: calls.Doesn't this imply that Suggests + :: calls are acceptable? (Or,
'exceptionally', to use require, but in any case Suggests + using external
packages should be allowed.)On 9 February 2015 at 12:20, stnava [email protected] wrote:
yes - those are prohibited
brian
On Mon, Feb 9, 2015 at 12:14 PM, bkandel [email protected]
wrote:Would using "suggests" also trigger failures if all the functions were
accessed via '::' calls?On 9 February 2015 at 12:05, stnava [email protected] wrote:
"Suggests" contributes to the problem - names of functions dont get
imported thus triggering several different types of check failures.
Importing is what's time consuming on startup.—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).
from antsr.
bkandel
commented on August 30, 2024
OK, I'll try that.
On 9 February 2015 at 12:43, stnava [email protected] wrote:
yes - maybe you are right .... definitely ::: is prohibited ...
if you want to pursue this, then you can try the following:
(1) change imports to suggests
(2) using NAMESPACE as a guide, identify all the functions that need ::
and then fix them ...(3) test with
R CMD INSTALL ANTsR
R CMD build ANTsR
R CMD check ANTsR_1.0.tar.gz --as-crani am making progress with the operators but not there yet ...
brian
On Mon, Feb 9, 2015 at 12:39 PM, bkandel [email protected] wrote:
The R extension manual (
http://cran.r-project.org/doc/manuals/r-release/R-exts.html#Package-Dependencies
)
says:
R code in the package should call library or require only exceptionally.
Such calls are never needed for packages listed in ‘Depends’ as they will
already be on the search path. It used to be common practice to use
require
calls for packages listed in ‘suggests’ in functions which used their
functionality, but nowadays it is better to access such functionality via
:: calls.Doesn't this imply that Suggests + :: calls are acceptable? (Or,
'exceptionally', to use require, but in any case Suggests + using
external
packages should be allowed.)On 9 February 2015 at 12:20, stnava [email protected] wrote:
yes - those are prohibited
brian
On Mon, Feb 9, 2015 at 12:14 PM, bkandel [email protected]
wrote:Would using "suggests" also trigger failures if all the functions
were
accessed via '::' calls?On 9 February 2015 at 12:05, stnava [email protected]
wrote:"Suggests" contributes to the problem - names of functions dont get
imported thus triggering several different types of check failures.
Importing is what's time consuming on startup.—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).
from antsr.
muschellij2
commented on August 30, 2024
Overall, in any of my packages, I use
@importFrom package functiona functionb
and so forth so that I do not have to load all the functionality of a
package
This can limit what you need and speed up time. Using :: is fine, (":::"
is an auto-reject from CRAN), especially when there are multiple functions
of the same name that are hidden.
On Mon, Feb 9, 2015 at 12:46 PM, bkandel [email protected] wrote:
OK, I'll try that.
On 9 February 2015 at 12:43, stnava [email protected] wrote:
yes - maybe you are right .... definitely ::: is prohibited ...
if you want to pursue this, then you can try the following:
(1) change imports to suggests
(2) using NAMESPACE as a guide, identify all the functions that need ::
and then fix them ...(3) test with
R CMD INSTALL ANTsR
R CMD build ANTsR
R CMD check ANTsR_1.0.tar.gz --as-crani am making progress with the operators but not there yet ...
brian
On Mon, Feb 9, 2015 at 12:39 PM, bkandel [email protected]
wrote:The R extension manual (
http://cran.r-project.org/doc/manuals/r-release/R-exts.html#Package-Dependencies
)
says:
R code in the package should call library or require only
exceptionally.
Such calls are never needed for packages listed in ‘Depends’ as they
will
already be on the search path. It used to be common practice to use
require
calls for packages listed in ‘suggests’ in functions which used their
functionality, but nowadays it is better to access such functionality
via
:: calls.Doesn't this imply that Suggests + :: calls are acceptable? (Or,
'exceptionally', to use require, but in any case Suggests + using
external
packages should be allowed.)On 9 February 2015 at 12:20, stnava [email protected] wrote:
yes - those are prohibited
brian
On Mon, Feb 9, 2015 at 12:14 PM, bkandel [email protected]
wrote:Would using "suggests" also trigger failures if all the functions
were
accessed via '::' calls?On 9 February 2015 at 12:05, stnava [email protected]
wrote:"Suggests" contributes to the problem - names of functions dont
get
imported thus triggering several different types of check
failures.
Importing is what's time consuming on startup.—
Reply to this email directly or view it on GitHub
<#8 (comment)
.—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).
from antsr.
bkandel
commented on August 30, 2024
If we go with '::' calls, is a global import performed on the package or is
only that specific function imported?
On 9 February 2015 at 13:02, John Muschelli [email protected]
wrote:
Overall, in any of my packages, I use
@importFrom package functiona functionb
and so forth so that I do not have to load all the functionality of a
packageThis can limit what you need and speed up time. Using :: is fine, (":::"
is an auto-reject from CRAN), especially when there are multiple functions
of the same name that are hidden.On Mon, Feb 9, 2015 at 12:46 PM, bkandel [email protected] wrote:
OK, I'll try that.
On 9 February 2015 at 12:43, stnava [email protected] wrote:
yes - maybe you are right .... definitely ::: is prohibited ...
if you want to pursue this, then you can try the following:
(1) change imports to suggests
(2) using NAMESPACE as a guide, identify all the functions that need ::
and then fix them ...(3) test with
R CMD INSTALL ANTsR
R CMD build ANTsR
R CMD check ANTsR_1.0.tar.gz --as-crani am making progress with the operators but not there yet ...
brian
On Mon, Feb 9, 2015 at 12:39 PM, bkandel [email protected]
wrote:The R extension manual (
http://cran.r-project.org/doc/manuals/r-release/R-exts.html#Package-Dependencies
)
says:
R code in the package should call library or require only
exceptionally.
Such calls are never needed for packages listed in ‘Depends’ as they
will
already be on the search path. It used to be common practice to use
require
calls for packages listed in ‘suggests’ in functions which used their
functionality, but nowadays it is better to access such functionality
via
:: calls.Doesn't this imply that Suggests + :: calls are acceptable? (Or,
'exceptionally', to use require, but in any case Suggests + using
external
packages should be allowed.)On 9 February 2015 at 12:20, stnava [email protected]
wrote:yes - those are prohibited
brian
On Mon, Feb 9, 2015 at 12:14 PM, bkandel <[email protected]
wrote:
Would using "suggests" also trigger failures if all the functions
were
accessed via '::' calls?On 9 February 2015 at 12:05, stnava [email protected]
wrote:"Suggests" contributes to the problem - names of functions dont
get
imported thus triggering several different types of check
failures.
Importing is what's time consuming on startup.—
Reply to this email directly or view it on GitHub
<
#8 (comment)
.—
Reply to this email directly or view it on GitHub
<#8 (comment)
.—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).
from antsr.
stnava
commented on August 30, 2024
am embarrassed to say i never read these directions before:
The general rules are
- A package should be listed in only one of these fields.
- Packages whose namespace only is needed to load the package using
library(pkgname) should be listed in the ‘Imports’ field and not in the ‘
Depends’ field. Packages listed in imports or importFrom directives in
the NAMESPACE file should almost always be in ‘Imports’ and not ‘Depends
’. - Packages that need to be attached to successfully load the package
using library(pkgname) must be listed in the ‘Depends’ field. - All packages that are needed7
http://cran.r-project.org/doc/manuals/r-release/R-exts.html#FOOT7 to
successfully run R CMD check on the package must be listed in one of ‘
Depends’ or ‘Suggests’ or ‘Imports’. Packages used to run examples or
tests conditionally (e.g. via if(require(pkgname))) should be listed
in ‘Suggests’ or ‘Enhances’. (This allows checkers to ensure that all
the packages needed for a complete check are installed.)
In particular, packages providing “only” data for examples or vignettes
should be listed in ‘Suggests’ rather than ‘Depends’ in order to make lean
installations possible.
brian
On Mon, Feb 9, 2015 at 1:06 PM, bkandel [email protected] wrote:
If we go with '::' calls, is a global import performed on the package or is
only that specific function imported?On 9 February 2015 at 13:02, John Muschelli [email protected]
wrote:Overall, in any of my packages, I use
@importFrom package functiona functionb
and so forth so that I do not have to load all the functionality of a
packageThis can limit what you need and speed up time. Using :: is fine, (":::"
is an auto-reject from CRAN), especially when there are multiple
functions
of the same name that are hidden.On Mon, Feb 9, 2015 at 12:46 PM, bkandel [email protected]
wrote:OK, I'll try that.
On 9 February 2015 at 12:43, stnava [email protected] wrote:
yes - maybe you are right .... definitely ::: is prohibited ...
if you want to pursue this, then you can try the following:
(1) change imports to suggests
(2) using NAMESPACE as a guide, identify all the functions that need
::
and then fix them ...(3) test with
R CMD INSTALL ANTsR
R CMD build ANTsR
R CMD check ANTsR_1.0.tar.gz --as-crani am making progress with the operators but not there yet ...
brian
On Mon, Feb 9, 2015 at 12:39 PM, bkandel [email protected]
wrote:The R extension manual (
http://cran.r-project.org/doc/manuals/r-release/R-exts.html#Package-Dependencies
)
says:
R code in the package should call library or require only
exceptionally.
Such calls are never needed for packages listed in ‘Depends’ as
they
will
already be on the search path. It used to be common practice to use
require
calls for packages listed in ‘suggests’ in functions which used
their
functionality, but nowadays it is better to access such
functionality
via
:: calls.Doesn't this imply that Suggests + :: calls are acceptable? (Or,
'exceptionally', to use require, but in any case Suggests + using
external
packages should be allowed.)On 9 February 2015 at 12:20, stnava [email protected]
wrote:yes - those are prohibited
brian
On Mon, Feb 9, 2015 at 12:14 PM, bkandel <
[email protected]wrote:
Would using "suggests" also trigger failures if all the
functions
were
accessed via '::' calls?On 9 February 2015 at 12:05, stnava [email protected]
wrote:"Suggests" contributes to the problem - names of functions
dont
get
imported thus triggering several different types of check
failures.
Importing is what's time consuming on startup.—
Reply to this email directly or view it on GitHub
<
#8 (comment)
.—
Reply to this email directly or view it on GitHub
<
#8 (comment)
.—
Reply to this email directly or view it on GitHub
<#8 (comment)
.—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).
from antsr.
stnava
commented on August 30, 2024
or this:
1.1.3.1 Suggested packages
Note that someone wanting to run the examples/tests/vignettes may not have
a suggested package available (and it may not even be possible to install
it for that platform). The recommendation used to be to make their use
conditional via if(require("pkgname"))): this is fine if that
conditioning is done in examples/tests/vignettes.
However, using require for conditioning in package code is not good
practice as it alters the search path for the rest of the session and
relies on functions in that package not being masked by other require or
library calls. It is better practice to use code like
if (requireNamespace("rgl", quietly = TRUE)) {
rgl::plot3d(...)
} else {
## do something else not involving rgl.
}
Note the use of rgl:: as that object would not necessarily be visible (and
if it is, it need not be the one from that namespace: plot3d occurs in
several other packages). If the intention is to give an error if the
suggested package is not available, simply use e.g. rgl::plot3d.
As noted above, packages in ‘Enhances’ must be used conditionally and
hence objects within them should always be accessed via ::.
brian
On Mon, Feb 9, 2015 at 1:14 PM, brian avants [email protected] wrote:
am embarrassed to say i never read these directions before:
The general rules are
- A package should be listed in only one of these fields.
- Packages whose namespace only is needed to load the package using
library(pkgname) should be listed in the ‘Imports’ field and not in
the ‘Depends’ field. Packages listed in imports or importFrom directives
in the NAMESPACE file should almost always be in ‘Imports’ and not ‘
Depends’.- Packages that need to be attached to successfully load the package
using library(pkgname) must be listed in the ‘Depends’ field.- All packages that are needed7
http://cran.r-project.org/doc/manuals/r-release/R-exts.html#FOOT7 to
successfully run R CMD check on the package must be listed in one of ‘
Depends’ or ‘Suggests’ or ‘Imports’. Packages used to run examples or
tests conditionally (e.g. via if(require(pkgname))) should be listed
in ‘Suggests’ or ‘Enhances’. (This allows checkers to ensure that all
the packages needed for a complete check are installed.)In particular, packages providing “only” data for examples or vignettes
should be listed in ‘Suggests’ rather than ‘Depends’ in order to make
lean installations possible.brian
On Mon, Feb 9, 2015 at 1:06 PM, bkandel [email protected] wrote:
If we go with '::' calls, is a global import performed on the package or
is
only that specific function imported?On 9 February 2015 at 13:02, John Muschelli [email protected]
wrote:Overall, in any of my packages, I use
@importFrom package functiona functionb
and so forth so that I do not have to load all the functionality of a
packageThis can limit what you need and speed up time. Using :: is fine, (":::"
is an auto-reject from CRAN), especially when there are multiple
functions
of the same name that are hidden.On Mon, Feb 9, 2015 at 12:46 PM, bkandel [email protected]
wrote:OK, I'll try that.
On 9 February 2015 at 12:43, stnava [email protected] wrote:
yes - maybe you are right .... definitely ::: is prohibited ...
if you want to pursue this, then you can try the following:
(1) change imports to suggests
(2) using NAMESPACE as a guide, identify all the functions that
need ::
and then fix them ...(3) test with
R CMD INSTALL ANTsR
R CMD build ANTsR
R CMD check ANTsR_1.0.tar.gz --as-crani am making progress with the operators but not there yet ...
brian
On Mon, Feb 9, 2015 at 12:39 PM, bkandel [email protected]
wrote:The R extension manual (
http://cran.r-project.org/doc/manuals/r-release/R-exts.html#Package-Dependencies
)
says:
R code in the package should call library or require only
exceptionally.
Such calls are never needed for packages listed in ‘Depends’ as
they
will
already be on the search path. It used to be common practice to
use
require
calls for packages listed in ‘suggests’ in functions which used
their
functionality, but nowadays it is better to access such
functionality
via
:: calls.Doesn't this imply that Suggests + :: calls are acceptable? (Or,
'exceptionally', to use require, but in any case Suggests + using
external
packages should be allowed.)On 9 February 2015 at 12:20, stnava [email protected]
wrote:yes - those are prohibited
brian
On Mon, Feb 9, 2015 at 12:14 PM, bkandel <
[email protected]wrote:
Would using "suggests" also trigger failures if all the
functions
were
accessed via '::' calls?On 9 February 2015 at 12:05, stnava <[email protected]
wrote:
"Suggests" contributes to the problem - names of functions
dont
get
imported thus triggering several different types of check
failures.
Importing is what's time consuming on startup.—
Reply to this email directly or view it on GitHub
<
#8 (comment)
.—
Reply to this email directly or view it on GitHub
<
#8 (comment)
.—
Reply to this email directly or view it on GitHub
<#8 (comment)
.—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).
from antsr.
bkandel
commented on August 30, 2024
There was a thread on this exact issue:
https://stat.ethz.ch/pipermail/r-help/2011-January/264516.html
It appears that importFrom will shrink the startup time, because we won't
have to load the entire package, but :: will (I think) minimize startup
time even more because the package is not loaded until the function is
called. It is not clear to me whether this actually works, though--it will
need some experimentation.
On 9 February 2015 at 13:15, stnava [email protected] wrote:
am embarrassed to say i never read these directions before:
The general rules are
- A package should be listed in only one of these fields.
- Packages whose namespace only is needed to load the package using
library(pkgname) should be listed in the ‘Imports’ field and not in the ‘
Depends’ field. Packages listed in imports or importFrom directives in
the NAMESPACE file should almost always be in ‘Imports’ and not ‘Depends
’.- Packages that need to be attached to successfully load the package
using library(pkgname) must be listed in the ‘Depends’ field.- All packages that are needed7
http://cran.r-project.org/doc/manuals/r-release/R-exts.html#FOOT7 to
successfully run R CMD check on the package must be listed in one of ‘
Depends’ or ‘Suggests’ or ‘Imports’. Packages used to run examples or
tests conditionally (e.g. via if(require(pkgname))) should be listed
in ‘Suggests’ or ‘Enhances’. (This allows checkers to ensure that all
the packages needed for a complete check are installed.)In particular, packages providing “only” data for examples or vignettes
should be listed in ‘Suggests’ rather than ‘Depends’ in order to make lean
installations possible.brian
On Mon, Feb 9, 2015 at 1:06 PM, bkandel [email protected] wrote:
If we go with '::' calls, is a global import performed on the package or
is
only that specific function imported?On 9 February 2015 at 13:02, John Muschelli [email protected]
wrote:Overall, in any of my packages, I use
@importFrom package functiona functionb
and so forth so that I do not have to load all the functionality of a
packageThis can limit what you need and speed up time. Using :: is fine,
(":::"
is an auto-reject from CRAN), especially when there are multiple
functions
of the same name that are hidden.On Mon, Feb 9, 2015 at 12:46 PM, bkandel [email protected]
wrote:OK, I'll try that.
On 9 February 2015 at 12:43, stnava [email protected]
wrote:yes - maybe you are right .... definitely ::: is prohibited ...
if you want to pursue this, then you can try the following:
(1) change imports to suggests
(2) using NAMESPACE as a guide, identify all the functions that
need
::
and then fix them ...(3) test with
R CMD INSTALL ANTsR
R CMD build ANTsR
R CMD check ANTsR_1.0.tar.gz --as-crani am making progress with the operators but not there yet ...
brian
On Mon, Feb 9, 2015 at 12:39 PM, bkandel <[email protected]
wrote:
The R extension manual (
http://cran.r-project.org/doc/manuals/r-release/R-exts.html#Package-Dependencies
)
says:
R code in the package should call library or require only
exceptionally.
Such calls are never needed for packages listed in ‘Depends’ as
they
will
already be on the search path. It used to be common practice to
use
require
calls for packages listed in ‘suggests’ in functions which used
their
functionality, but nowadays it is better to access such
functionality
via
:: calls.Doesn't this imply that Suggests + :: calls are acceptable? (Or,
'exceptionally', to use require, but in any case Suggests + using
external
packages should be allowed.)On 9 February 2015 at 12:20, stnava [email protected]
wrote:yes - those are prohibited
brian
On Mon, Feb 9, 2015 at 12:14 PM, bkandel <
[email protected]wrote:
Would using "suggests" also trigger failures if all the
functions
were
accessed via '::' calls?On 9 February 2015 at 12:05, stnava <
[email protected]>
wrote:"Suggests" contributes to the problem - names of functions
dont
get
imported thus triggering several different types of check
failures.
Importing is what's time consuming on startup.—
Reply to this email directly or view it on GitHub
<
#8 (comment)
.—
Reply to this email directly or view it on GitHub
<
#8 (comment)
.—
Reply to this email directly or view it on GitHub
<
#8 (comment)
.—
Reply to this email directly or view it on GitHub
<#8 (comment)
.—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).
from antsr.
muschellij2
commented on August 30, 2024
I don't believe the :: will do much with respect to startup time because
importFrom should only load the package function when the function with the
import directive is called, but I'm not 100% sure on that.
On Mon, Feb 9, 2015 at 1:21 PM, bkandel [email protected] wrote:
There was a thread on this exact issue:
https://stat.ethz.ch/pipermail/r-help/2011-January/264516.html
It appears that importFrom will shrink the startup time, because we won't
have to load the entire package, but :: will (I think) minimize startup
time even more because the package is not loaded until the function is
called. It is not clear to me whether this actually works, though--it will
need some experimentation.On 9 February 2015 at 13:15, stnava [email protected] wrote:
am embarrassed to say i never read these directions before:
The general rules are
- A package should be listed in only one of these fields.
- Packages whose namespace only is needed to load the package using
library(pkgname) should be listed in the ‘Imports’ field and not in the ‘
Depends’ field. Packages listed in imports or importFrom directives in
the NAMESPACE file should almost always be in ‘Imports’ and not ‘Depends
’.- Packages that need to be attached to successfully load the package
using library(pkgname) must be listed in the ‘Depends’ field.- All packages that are needed7
http://cran.r-project.org/doc/manuals/r-release/R-exts.html#FOOT7 to
successfully run R CMD check on the package must be listed in one of ‘
Depends’ or ‘Suggests’ or ‘Imports’. Packages used to run examples or
tests conditionally (e.g. via if(require(pkgname))) should be listed
in ‘Suggests’ or ‘Enhances’. (This allows checkers to ensure that all
the packages needed for a complete check are installed.)In particular, packages providing “only” data for examples or vignettes
should be listed in ‘Suggests’ rather than ‘Depends’ in order to make
lean
installations possible.brian
On Mon, Feb 9, 2015 at 1:06 PM, bkandel [email protected]
wrote:If we go with '::' calls, is a global import performed on the package
or
is
only that specific function imported?On 9 February 2015 at 13:02, John Muschelli [email protected]
wrote:Overall, in any of my packages, I use
@importFrom package functiona functionb
and so forth so that I do not have to load all the functionality of a
packageThis can limit what you need and speed up time. Using :: is fine,
(":::"
is an auto-reject from CRAN), especially when there are multiple
functions
of the same name that are hidden.On Mon, Feb 9, 2015 at 12:46 PM, bkandel [email protected]
wrote:OK, I'll try that.
On 9 February 2015 at 12:43, stnava [email protected]
wrote:yes - maybe you are right .... definitely ::: is prohibited ...
if you want to pursue this, then you can try the following:
(1) change imports to suggests
(2) using NAMESPACE as a guide, identify all the functions that
need
::
and then fix them ...(3) test with
R CMD INSTALL ANTsR
R CMD build ANTsR
R CMD check ANTsR_1.0.tar.gz --as-crani am making progress with the operators but not there yet ...
brian
On Mon, Feb 9, 2015 at 12:39 PM, bkandel <
[email protected]wrote:
The R extension manual (
http://cran.r-project.org/doc/manuals/r-release/R-exts.html#Package-Dependencies
)
says:
R code in the package should call library or require only
exceptionally.
Such calls are never needed for packages listed in ‘Depends’ as
they
will
already be on the search path. It used to be common practice to
use
require
calls for packages listed in ‘suggests’ in functions which used
their
functionality, but nowadays it is better to access such
functionality
via
:: calls.Doesn't this imply that Suggests + :: calls are acceptable?
(Or,
'exceptionally', to use require, but in any case Suggests +
using
external
packages should be allowed.)On 9 February 2015 at 12:20, stnava [email protected]
wrote:yes - those are prohibited
brian
On Mon, Feb 9, 2015 at 12:14 PM, bkandel <
[email protected]wrote:
Would using "suggests" also trigger failures if all the
functions
were
accessed via '::' calls?On 9 February 2015 at 12:05, stnava <
[email protected]>
wrote:"Suggests" contributes to the problem - names of
functions
dont
get
imported thus triggering several different types of check
failures.
Importing is what's time consuming on startup.—
Reply to this email directly or view it on GitHub
<
#8 (comment)
.—
Reply to this email directly or view it on GitHub
<
#8 (comment)
.—
Reply to this email directly or view it on GitHub
<
#8 (comment)
.—
Reply to this email directly or view it on GitHub
<
#8 (comment)
.—
Reply to this email directly or view it on GitHub
<#8 (comment)
.—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).
from antsr.
bkandel
commented on August 30, 2024
General question: Why are we not using roxygen to generate our NAMESPACE
file? It has support for importFrom, and it will be a nightmare to keep
track of all the imports manually.
On 9 February 2015 at 13:25, John Muschelli [email protected]
wrote:
I don't believe the :: will do much with respect to startup time because
importFrom should only load the package function when the function with the
import directive is called, but I'm not 100% sure on that.On Mon, Feb 9, 2015 at 1:21 PM, bkandel [email protected] wrote:
There was a thread on this exact issue:
https://stat.ethz.ch/pipermail/r-help/2011-January/264516.html
It appears that importFrom will shrink the startup time, because we won't
have to load the entire package, but :: will (I think) minimize startup
time even more because the package is not loaded until the function is
called. It is not clear to me whether this actually works, though--it
will
need some experimentation.On 9 February 2015 at 13:15, stnava [email protected] wrote:
am embarrassed to say i never read these directions before:
The general rules are
- A package should be listed in only one of these fields.
- Packages whose namespace only is needed to load the package using
library(pkgname) should be listed in the ‘Imports’ field and not in
the ‘
Depends’ field. Packages listed in imports or importFrom directives in
the NAMESPACE file should almost always be in ‘Imports’ and not
‘Depends
’.- Packages that need to be attached to successfully load the package
using library(pkgname) must be listed in the ‘Depends’ field.- All packages that are needed7
http://cran.r-project.org/doc/manuals/r-release/R-exts.html#FOOT7 to
successfully run R CMD check on the package must be listed in one of ‘
Depends’ or ‘Suggests’ or ‘Imports’. Packages used to run examples or
tests conditionally (e.g. via if(require(pkgname))) should be listed
in ‘Suggests’ or ‘Enhances’. (This allows checkers to ensure that all
the packages needed for a complete check are installed.)In particular, packages providing “only” data for examples or vignettes
should be listed in ‘Suggests’ rather than ‘Depends’ in order to make
lean
installations possible.brian
On Mon, Feb 9, 2015 at 1:06 PM, bkandel [email protected]
wrote:If we go with '::' calls, is a global import performed on the package
or
is
only that specific function imported?On 9 February 2015 at 13:02, John Muschelli <
[email protected]>
wrote:Overall, in any of my packages, I use
@importFrom package functiona functionb
and so forth so that I do not have to load all the functionality
of a
packageThis can limit what you need and speed up time. Using :: is fine,
(":::"
is an auto-reject from CRAN), especially when there are multiple
functions
of the same name that are hidden.On Mon, Feb 9, 2015 at 12:46 PM, bkandel <[email protected]
wrote:
OK, I'll try that.
On 9 February 2015 at 12:43, stnava [email protected]
wrote:yes - maybe you are right .... definitely ::: is prohibited ...
if you want to pursue this, then you can try the following:
(1) change imports to suggests
(2) using NAMESPACE as a guide, identify all the functions that
need
::
and then fix them ...(3) test with
R CMD INSTALL ANTsR
R CMD build ANTsR
R CMD check ANTsR_1.0.tar.gz --as-crani am making progress with the operators but not there yet ...
brian
On Mon, Feb 9, 2015 at 12:39 PM, bkandel <
[email protected]wrote:
The R extension manual (
http://cran.r-project.org/doc/manuals/r-release/R-exts.html#Package-Dependencies
)
says:
R code in the package should call library or require only
exceptionally.
Such calls are never needed for packages listed in ‘Depends’
as
they
will
already be on the search path. It used to be common practice
to
use
require
calls for packages listed in ‘suggests’ in functions which
used
their
functionality, but nowadays it is better to access such
functionality
via
:: calls.Doesn't this imply that Suggests + :: calls are acceptable?
(Or,
'exceptionally', to use require, but in any case Suggests +
using
external
packages should be allowed.)On 9 February 2015 at 12:20, stnava <
[email protected]>
wrote:yes - those are prohibited
brian
On Mon, Feb 9, 2015 at 12:14 PM, bkandel <
[email protected]wrote:
Would using "suggests" also trigger failures if all the
functions
were
accessed via '::' calls?On 9 February 2015 at 12:05, stnava <
[email protected]>
wrote:"Suggests" contributes to the problem - names of
functions
dont
get
imported thus triggering several different types of
check
failures.
Importing is what's time consuming on startup.—
Reply to this email directly or view it on GitHub
<
#8 (comment)
.—
Reply to this email directly or view it on GitHub
<
#8 (comment)
.—
Reply to this email directly or view it on GitHub
<
#8 (comment)
.—
Reply to this email directly or view it on GitHub
<
#8 (comment)
.—
Reply to this email directly or view it on GitHub
<
#8 (comment)
.—
Reply to this email directly or view it on GitHub
<#8 (comment)
.—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).
from antsr.
stnava
commented on August 30, 2024
i tried it but it produced an unloadable result ... it's an experiment that
may require several iterations through all functions to get right.
brian
On Mon, Feb 9, 2015 at 1:39 PM, bkandel [email protected] wrote:
General question: Why are we not using roxygen to generate our NAMESPACE
file? It has support for importFrom, and it will be a nightmare to keep
track of all the imports manually.On 9 February 2015 at 13:25, John Muschelli [email protected]
wrote:I don't believe the :: will do much with respect to startup time because
importFrom should only load the package function when the function with
the
import directive is called, but I'm not 100% sure on that.On Mon, Feb 9, 2015 at 1:21 PM, bkandel [email protected]
wrote:There was a thread on this exact issue:
https://stat.ethz.ch/pipermail/r-help/2011-January/264516.html
It appears that importFrom will shrink the startup time, because we
won't
have to load the entire package, but :: will (I think) minimize startup
time even more because the package is not loaded until the function is
called. It is not clear to me whether this actually works, though--it
will
need some experimentation.On 9 February 2015 at 13:15, stnava [email protected] wrote:
am embarrassed to say i never read these directions before:
The general rules are
- A package should be listed in only one of these fields.
- Packages whose namespace only is needed to load the package using
library(pkgname) should be listed in the ‘Imports’ field and not in
the ‘
Depends’ field. Packages listed in imports or importFrom directives
in
the NAMESPACE file should almost always be in ‘Imports’ and not
‘Depends
’.- Packages that need to be attached to successfully load the package
using library(pkgname) must be listed in the ‘Depends’ field.- All packages that are needed7
http://cran.r-project.org/doc/manuals/r-release/R-exts.html#FOOT7
to
successfully run R CMD check on the package must be listed in one of
‘
Depends’ or ‘Suggests’ or ‘Imports’. Packages used to run examples or
tests conditionally (e.g. via if(require(pkgname))) should be
listed
in ‘Suggests’ or ‘Enhances’. (This allows checkers to ensure that all
the packages needed for a complete check are installed.)In particular, packages providing “only” data for examples or
vignettes
should be listed in ‘Suggests’ rather than ‘Depends’ in order to make
lean
installations possible.brian
On Mon, Feb 9, 2015 at 1:06 PM, bkandel [email protected]
wrote:If we go with '::' calls, is a global import performed on the
package
or
is
only that specific function imported?On 9 February 2015 at 13:02, John Muschelli <
[email protected]>
wrote:Overall, in any of my packages, I use
@importFrom package functiona functionb
and so forth so that I do not have to load all the functionality
of a
packageThis can limit what you need and speed up time. Using :: is fine,
(":::"
is an auto-reject from CRAN), especially when there are multiple
functions
of the same name that are hidden.On Mon, Feb 9, 2015 at 12:46 PM, bkandel <
[email protected]wrote:
OK, I'll try that.
On 9 February 2015 at 12:43, stnava [email protected]
wrote:yes - maybe you are right .... definitely ::: is prohibited
...if you want to pursue this, then you can try the following:
(1) change imports to suggests
(2) using NAMESPACE as a guide, identify all the functions
that
need
::
and then fix them ...(3) test with
R CMD INSTALL ANTsR
R CMD build ANTsR
R CMD check ANTsR_1.0.tar.gz --as-crani am making progress with the operators but not there yet ...
brian
On Mon, Feb 9, 2015 at 12:39 PM, bkandel <
[email protected]wrote:
The R extension manual (
http://cran.r-project.org/doc/manuals/r-release/R-exts.html#Package-Dependencies
)
says:
R code in the package should call library or require only
exceptionally.
Such calls are never needed for packages listed in
‘Depends’
as
they
will
already be on the search path. It used to be common
practice
to
use
require
calls for packages listed in ‘suggests’ in functions which
used
their
functionality, but nowadays it is better to access such
functionality
via
:: calls.Doesn't this imply that Suggests + :: calls are acceptable?
(Or,
'exceptionally', to use require, but in any case Suggests +
using
external
packages should be allowed.)On 9 February 2015 at 12:20, stnava <
[email protected]>
wrote:yes - those are prohibited
brian
On Mon, Feb 9, 2015 at 12:14 PM, bkandel <
[email protected]wrote:
Would using "suggests" also trigger failures if all the
functions
were
accessed via '::' calls?On 9 February 2015 at 12:05, stnava <
[email protected]>
wrote:"Suggests" contributes to the problem - names of
functions
dont
get
imported thus triggering several different types of
check
failures.
Importing is what's time consuming on startup.—
Reply to this email directly or view it on GitHub
<
#8 (comment)
.—
Reply to this email directly or view it on GitHub
<
#8 (comment)
.—
Reply to this email directly or view it on GitHub
<
#8 (comment)
.—
Reply to this email directly or view it on GitHub
<
#8 (comment)
.—
Reply to this email directly or view it on GitHub
<
#8 (comment)
.—
Reply to this email directly or view it on GitHub
<
#8 (comment)
.—
Reply to this email directly or view it on GitHub
<#8 (comment)
.—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).
from antsr.
muschellij2
commented on August 30, 2024
I assumed you were using that to create your NAMESPACE. I highly recommend
that if it's not too much trouble. I don't know how you're building right
now (using devtools I assume?), but it may be easy/hard depending on taht.
On Mon, Feb 9, 2015 at 1:42 PM, stnava [email protected] wrote:
i tried it but it produced an unloadable result ... it's an experiment that
may require several iterations through all functions to get right.brian
On Mon, Feb 9, 2015 at 1:39 PM, bkandel [email protected] wrote:
General question: Why are we not using roxygen to generate our NAMESPACE
file? It has support for importFrom, and it will be a nightmare to keep
track of all the imports manually.On 9 February 2015 at 13:25, John Muschelli [email protected]
wrote:I don't believe the :: will do much with respect to startup time
because
importFrom should only load the package function when the function with
the
import directive is called, but I'm not 100% sure on that.On Mon, Feb 9, 2015 at 1:21 PM, bkandel [email protected]
wrote:There was a thread on this exact issue:
https://stat.ethz.ch/pipermail/r-help/2011-January/264516.html
It appears that importFrom will shrink the startup time, because we
won't
have to load the entire package, but :: will (I think) minimize
startup
time even more because the package is not loaded until the function
is
called. It is not clear to me whether this actually works, though--it
will
need some experimentation.On 9 February 2015 at 13:15, stnava [email protected]
wrote:am embarrassed to say i never read these directions before:
The general rules are
- A package should be listed in only one of these fields.
- Packages whose namespace only is needed to load the package using
library(pkgname) should be listed in the ‘Imports’ field and not in
the ‘
Depends’ field. Packages listed in imports or importFrom directives
in
the NAMESPACE file should almost always be in ‘Imports’ and not
‘Depends
’.- Packages that need to be attached to successfully load the
package
using library(pkgname) must be listed in the ‘Depends’ field.- All packages that are needed7
<http://cran.r-project.org/doc/manuals/r-release/R-exts.html#FOOT7to
successfully run R CMD check on the package must be listed in one
of
‘
Depends’ or ‘Suggests’ or ‘Imports’. Packages used to run examples
or
tests conditionally (e.g. via if(require(pkgname))) should be
listed
in ‘Suggests’ or ‘Enhances’. (This allows checkers to ensure that
all
the packages needed for a complete check are installed.)In particular, packages providing “only” data for examples or
vignettes
should be listed in ‘Suggests’ rather than ‘Depends’ in order to
make
lean
installations possible.brian
On Mon, Feb 9, 2015 at 1:06 PM, bkandel [email protected]
wrote:If we go with '::' calls, is a global import performed on the
package
or
is
only that specific function imported?On 9 February 2015 at 13:02, John Muschelli <
[email protected]>
wrote:Overall, in any of my packages, I use
@importFrom package functiona functionb
and so forth so that I do not have to load all the
functionality
of a
packageThis can limit what you need and speed up time. Using :: is
fine,
(":::"
is an auto-reject from CRAN), especially when there are
multiple
functions
of the same name that are hidden.On Mon, Feb 9, 2015 at 12:46 PM, bkandel <
[email protected]wrote:
OK, I'll try that.
On 9 February 2015 at 12:43, stnava <
[email protected]>
wrote:yes - maybe you are right .... definitely ::: is prohibited
...if you want to pursue this, then you can try the following:
(1) change imports to suggests
(2) using NAMESPACE as a guide, identify all the functions
that
need
::
and then fix them ...(3) test with
R CMD INSTALL ANTsR
R CMD build ANTsR
R CMD check ANTsR_1.0.tar.gz --as-crani am making progress with the operators but not there yet
...brian
On Mon, Feb 9, 2015 at 12:39 PM, bkandel <
[email protected]wrote:
The R extension manual (
http://cran.r-project.org/doc/manuals/r-release/R-exts.html#Package-Dependencies
)
says:
R code in the package should call library or require only
exceptionally.
Such calls are never needed for packages listed in
‘Depends’
as
they
will
already be on the search path. It used to be common
practice
to
use
require
calls for packages listed in ‘suggests’ in functions
which
used
their
functionality, but nowadays it is better to access such
functionality
via
:: calls.Doesn't this imply that Suggests + :: calls are
acceptable?
(Or,
'exceptionally', to use require, but in any case
Suggests +
using
external
packages should be allowed.)On 9 February 2015 at 12:20, stnava <
[email protected]>
wrote:yes - those are prohibited
brian
On Mon, Feb 9, 2015 at 12:14 PM, bkandel <
[email protected]wrote:
Would using "suggests" also trigger failures if all
the
functions
were
accessed via '::' calls?On 9 February 2015 at 12:05, stnava <
[email protected]>
wrote:"Suggests" contributes to the problem - names of
functions
dont
get
imported thus triggering several different types of
check
failures.
Importing is what's time consuming on startup.—
Reply to this email directly or view it on GitHub
<
#8 (comment)
.—
Reply to this email directly or view it on GitHub
<
#8 (comment)
.—
Reply to this email directly or view it on GitHub
<
#8 (comment)
.—
Reply to this email directly or view it on GitHub
<
#8 (comment)
.—
Reply to this email directly or view it on GitHub
<
#8 (comment)
.—
Reply to this email directly or view it on GitHub
<
#8 (comment)
.—
Reply to this email directly or view it on GitHub
<
#8 (comment)
.—
Reply to this email directly or view it on GitHub
<#8 (comment)
.—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).
from antsr.
bkandel
commented on August 30, 2024
OK, I just pushed this change. Only the most minimal set of packages is
required (Rcpp, tools, and methods, although I don't know why tools and
methods are required--Brian, could we make tools and methods "suggested"?),
and all others are loaded on-the-fly via :: calls. Cran checking is still
working.
If everyone agrees that this is the way to go, then from now on please
preface all calls to external packages with '::'.
On 9 February 2015 at 13:50, John Muschelli [email protected]
wrote:
I assumed you were using that to create your NAMESPACE. I highly recommend
that if it's not too much trouble. I don't know how you're building right
now (using devtools I assume?), but it may be easy/hard depending on taht.On Mon, Feb 9, 2015 at 1:42 PM, stnava [email protected] wrote:
i tried it but it produced an unloadable result ... it's an experiment
that
may require several iterations through all functions to get right.brian
On Mon, Feb 9, 2015 at 1:39 PM, bkandel [email protected]
wrote:General question: Why are we not using roxygen to generate our
NAMESPACE
file? It has support for importFrom, and it will be a nightmare to keep
track of all the imports manually.On 9 February 2015 at 13:25, John Muschelli [email protected]
wrote:I don't believe the :: will do much with respect to startup time
because
importFrom should only load the package function when the function
with
the
import directive is called, but I'm not 100% sure on that.On Mon, Feb 9, 2015 at 1:21 PM, bkandel [email protected]
wrote:There was a thread on this exact issue:
https://stat.ethz.ch/pipermail/r-help/2011-January/264516.html
It appears that importFrom will shrink the startup time, because we
won't
have to load the entire package, but :: will (I think) minimize
startup
time even more because the package is not loaded until the function
is
called. It is not clear to me whether this actually works,
though--it
will
need some experimentation.On 9 February 2015 at 13:15, stnava [email protected]
wrote:am embarrassed to say i never read these directions before:
The general rules are
- A package should be listed in only one of these fields.
- Packages whose namespace only is needed to load the package
using
library(pkgname) should be listed in the ‘Imports’ field and not
in
the ‘
Depends’ field. Packages listed in imports or importFrom
directives
in
the NAMESPACE file should almost always be in ‘Imports’ and not
‘Depends
’.- Packages that need to be attached to successfully load the
package
using library(pkgname) must be listed in the ‘Depends’ field.- All packages that are needed7
<
http://cran.r-project.org/doc/manuals/r-release/R-exts.html#FOOT7to
successfully run R CMD check on the package must be listed in one
of
‘
Depends’ or ‘Suggests’ or ‘Imports’. Packages used to run
examples
or
tests conditionally (e.g. via if(require(pkgname))) should be
listed
in ‘Suggests’ or ‘Enhances’. (This allows checkers to ensure that
all
the packages needed for a complete check are installed.)In particular, packages providing “only” data for examples or
vignettes
should be listed in ‘Suggests’ rather than ‘Depends’ in order to
make
lean
installations possible.brian
On Mon, Feb 9, 2015 at 1:06 PM, bkandel <
[email protected]>
wrote:If we go with '::' calls, is a global import performed on the
package
or
is
only that specific function imported?On 9 February 2015 at 13:02, John Muschelli <
[email protected]>
wrote:Overall, in any of my packages, I use
@importFrom package functiona functionb
and so forth so that I do not have to load all the
functionality
of a
packageThis can limit what you need and speed up time. Using :: is
fine,
(":::"
is an auto-reject from CRAN), especially when there are
multiple
functions
of the same name that are hidden.On Mon, Feb 9, 2015 at 12:46 PM, bkandel <
[email protected]wrote:
OK, I'll try that.
On 9 February 2015 at 12:43, stnava <
[email protected]>
wrote:yes - maybe you are right .... definitely ::: is
prohibited
...if you want to pursue this, then you can try the
following:(1) change imports to suggests
(2) using NAMESPACE as a guide, identify all the
functions
that
need
::
and then fix them ...(3) test with
R CMD INSTALL ANTsR
R CMD build ANTsR
R CMD check ANTsR_1.0.tar.gz --as-crani am making progress with the operators but not there yet
...brian
On Mon, Feb 9, 2015 at 12:39 PM, bkandel <
[email protected]wrote:
The R extension manual (
http://cran.r-project.org/doc/manuals/r-release/R-exts.html#Package-Dependencies
)
says:
R code in the package should call library or require
only
exceptionally.
Such calls are never needed for packages listed in
‘Depends’
as
they
will
already be on the search path. It used to be common
practice
to
use
require
calls for packages listed in ‘suggests’ in functions
which
used
their
functionality, but nowadays it is better to access such
functionality
via
:: calls.Doesn't this imply that Suggests + :: calls are
acceptable?
(Or,
'exceptionally', to use require, but in any case
Suggests +
using
external
packages should be allowed.)On 9 February 2015 at 12:20, stnava <
[email protected]>
wrote:yes - those are prohibited
brian
On Mon, Feb 9, 2015 at 12:14 PM, bkandel <
[email protected]wrote:
Would using "suggests" also trigger failures if all
the
functions
were
accessed via '::' calls?On 9 February 2015 at 12:05, stnava <
[email protected]>
wrote:"Suggests" contributes to the problem - names of
functions
dont
get
imported thus triggering several different types
of
check
failures.
Importing is what's time consuming on startup.—
Reply to this email directly or view it on GitHub
<.
—
Reply to this email directly or view it on GitHub
<
#8 (comment)
.—
Reply to this email directly or view it on GitHub
<
#8 (comment)
.—
Reply to this email directly or view it on GitHub
<
#8 (comment)
.—
Reply to this email directly or view it on GitHub
<
#8 (comment)
.—
Reply to this email directly or view it on GitHub
<
#8 (comment)
.—
Reply to this email directly or view it on GitHub
<
#8 (comment)
.—
Reply to this email directly or view it on GitHub
<
#8 (comment)
.—
Reply to this email directly or view it on GitHub
<#8 (comment)
.—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).
from antsr.
stnava
commented on August 30, 2024
so far i like it ... any idea how to get rid of this:
Missing or unexported objects:
‘rgl::drawScene.rgl’ ‘robust::lmrob’ ‘robust::lmrob.control’
brian
On Mon, Feb 9, 2015 at 4:42 PM, bkandel [email protected] wrote:
OK, I just pushed this change. Only the most minimal set of packages is
required (Rcpp, tools, and methods, although I don't know why tools and
methods are required--Brian, could we make tools and methods "suggested"?),
and all others are loaded on-the-fly via :: calls. Cran checking is still
working.If everyone agrees that this is the way to go, then from now on please
preface all calls to external packages with '::'.On 9 February 2015 at 13:50, John Muschelli [email protected]
wrote:
I assumed you were using that to create your NAMESPACE. I highly
recommend
that if it's not too much trouble. I don't know how you're building right
now (using devtools I assume?), but it may be easy/hard depending on
taht.On Mon, Feb 9, 2015 at 1:42 PM, stnava [email protected] wrote:
i tried it but it produced an unloadable result ... it's an experiment
that
may require several iterations through all functions to get right.brian
On Mon, Feb 9, 2015 at 1:39 PM, bkandel [email protected]
wrote:General question: Why are we not using roxygen to generate our
NAMESPACE
file? It has support for importFrom, and it will be a nightmare to
keep
track of all the imports manually.On 9 February 2015 at 13:25, John Muschelli <
[email protected]>
wrote:I don't believe the :: will do much with respect to startup time
because
importFrom should only load the package function when the function
with
the
import directive is called, but I'm not 100% sure on that.On Mon, Feb 9, 2015 at 1:21 PM, bkandel [email protected]
wrote:There was a thread on this exact issue:
https://stat.ethz.ch/pipermail/r-help/2011-January/264516.html
It appears that importFrom will shrink the startup time, because
we
won't
have to load the entire package, but :: will (I think) minimize
startup
time even more because the package is not loaded until the
function
is
called. It is not clear to me whether this actually works,
though--it
will
need some experimentation.On 9 February 2015 at 13:15, stnava [email protected]
wrote:am embarrassed to say i never read these directions before:
The general rules are
- A package should be listed in only one of these fields.
- Packages whose namespace only is needed to load the package
using
library(pkgname) should be listed in the ‘Imports’ field and
not
in
the ‘
Depends’ field. Packages listed in imports or importFrom
directives
in
the NAMESPACE file should almost always be in ‘Imports’ and not
‘Depends
’.- Packages that need to be attached to successfully load the
package
using library(pkgname) must be listed in the ‘Depends’ field.- All packages that are needed7
<
http://cran.r-project.org/doc/manuals/r-release/R-exts.html#FOOT7to
successfully run R CMD check on the package must be listed in
one
of
‘
Depends’ or ‘Suggests’ or ‘Imports’. Packages used to run
examples
or
tests conditionally (e.g. via if(require(pkgname))) should be
listed
in ‘Suggests’ or ‘Enhances’. (This allows checkers to ensure
that
all
the packages needed for a complete check are installed.)In particular, packages providing “only” data for examples or
vignettes
should be listed in ‘Suggests’ rather than ‘Depends’ in order
to
make
lean
installations possible.brian
On Mon, Feb 9, 2015 at 1:06 PM, bkandel <
[email protected]>
wrote:If we go with '::' calls, is a global import performed on the
package
or
is
only that specific function imported?On 9 February 2015 at 13:02, John Muschelli <
[email protected]>
wrote:Overall, in any of my packages, I use
@importFrom package functiona functionb
and so forth so that I do not have to load all the
functionality
of a
packageThis can limit what you need and speed up time. Using :: is
fine,
(":::"
is an auto-reject from CRAN), especially when there are
multiple
functions
of the same name that are hidden.On Mon, Feb 9, 2015 at 12:46 PM, bkandel <
[email protected]wrote:
OK, I'll try that.
On 9 February 2015 at 12:43, stnava <
[email protected]>
wrote:yes - maybe you are right .... definitely ::: is
prohibited
...if you want to pursue this, then you can try the
following:(1) change imports to suggests
(2) using NAMESPACE as a guide, identify all the
functions
that
need
::
and then fix them ...(3) test with
R CMD INSTALL ANTsR
R CMD build ANTsR
R CMD check ANTsR_1.0.tar.gz --as-crani am making progress with the operators but not there
yet
...brian
On Mon, Feb 9, 2015 at 12:39 PM, bkandel <
[email protected]wrote:
The R extension manual (
http://cran.r-project.org/doc/manuals/r-release/R-exts.html#Package-Dependencies
)
says:
R code in the package should call library or require
only
exceptionally.
Such calls are never needed for packages listed in
‘Depends’
as
they
will
already be on the search path. It used to be common
practice
to
use
require
calls for packages listed in ‘suggests’ in functions
which
used
their
functionality, but nowadays it is better to access
such
functionality
via
:: calls.Doesn't this imply that Suggests + :: calls are
acceptable?
(Or,
'exceptionally', to use require, but in any case
Suggests +
using
external
packages should be allowed.)On 9 February 2015 at 12:20, stnava <
[email protected]>
wrote:yes - those are prohibited
brian
On Mon, Feb 9, 2015 at 12:14 PM, bkandel <
[email protected]wrote:
Would using "suggests" also trigger failures if
all
the
functions
were
accessed via '::' calls?On 9 February 2015 at 12:05, stnava <
[email protected]>
wrote:"Suggests" contributes to the problem - names
of
functions
dont
get
imported thus triggering several different
types
of
check
failures.
Importing is what's time consuming on startup.—
Reply to this email directly or view it on
GitHub
<.
—
Reply to this email directly or view it on GitHub
<.
—
Reply to this email directly or view it on GitHub
<
#8 (comment)
.—
Reply to this email directly or view it on GitHub
<
#8 (comment)
.—
Reply to this email directly or view it on GitHub
<
#8 (comment)
.—
Reply to this email directly or view it on GitHub
<
#8 (comment)
.—
Reply to this email directly or view it on GitHub
<
#8 (comment)
.—
Reply to this email directly or view it on GitHub
<
#8 (comment)
.—
Reply to this email directly or view it on GitHub
<
#8 (comment)
.—
Reply to this email directly or view it on GitHub
<#8 (comment)
.—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).
from antsr.
stnava
commented on August 30, 2024
also :
S3 methods shown with full name in documentation object 'plot.antsImage':
‘plot.antsImage’
The \usage entries for S3 methods should use the \method markup and not
their full name.
you can see this via:
R CMD INSTALL ANTsR
R CMD build ANTsR --no-build-vignettes
R CMD check ANTsR_1.0.tar.gz --as-cran --no-install
brian
On Mon, Feb 9, 2015 at 4:54 PM, brian avants [email protected] wrote:
so far i like it ... any idea how to get rid of this:
Missing or unexported objects:
‘rgl::drawScene.rgl’ ‘robust::lmrob’ ‘robust::lmrob.control’
brian
On Mon, Feb 9, 2015 at 4:42 PM, bkandel [email protected] wrote:
OK, I just pushed this change. Only the most minimal set of packages is
required (Rcpp, tools, and methods, although I don't know why tools and
methods are required--Brian, could we make tools and methods
"suggested"?),
and all others are loaded on-the-fly via :: calls. Cran checking is still
working.If everyone agrees that this is the way to go, then from now on please
preface all calls to external packages with '::'.On 9 February 2015 at 13:50, John Muschelli [email protected]
wrote:
I assumed you were using that to create your NAMESPACE. I highly
recommend
that if it's not too much trouble. I don't know how you're building
right
now (using devtools I assume?), but it may be easy/hard depending on
taht.On Mon, Feb 9, 2015 at 1:42 PM, stnava [email protected]
wrote:i tried it but it produced an unloadable result ... it's an experiment
that
may require several iterations through all functions to get right.brian
On Mon, Feb 9, 2015 at 1:39 PM, bkandel [email protected]
wrote:General question: Why are we not using roxygen to generate our
NAMESPACE
file? It has support for importFrom, and it will be a nightmare to
keep
track of all the imports manually.On 9 February 2015 at 13:25, John Muschelli <
[email protected]>
wrote:I don't believe the :: will do much with respect to startup time
because
importFrom should only load the package function when the function
with
the
import directive is called, but I'm not 100% sure on that.On Mon, Feb 9, 2015 at 1:21 PM, bkandel <[email protected]
wrote:
There was a thread on this exact issue:
https://stat.ethz.ch/pipermail/r-help/2011-January/264516.html
It appears that importFrom will shrink the startup time,
because we
won't
have to load the entire package, but :: will (I think) minimize
startup
time even more because the package is not loaded until the
function
is
called. It is not clear to me whether this actually works,
though--it
will
need some experimentation.On 9 February 2015 at 13:15, stnava [email protected]
wrote:am embarrassed to say i never read these directions before:
The general rules are
- A package should be listed in only one of these fields.
- Packages whose namespace only is needed to load the package
using
library(pkgname) should be listed in the ‘Imports’ field and
not
in
the ‘
Depends’ field. Packages listed in imports or importFrom
directives
in
the NAMESPACE file should almost always be in ‘Imports’ and
not
‘Depends
’.- Packages that need to be attached to successfully load the
package
using library(pkgname) must be listed in the ‘Depends’ field.- All packages that are needed7
<
http://cran.r-project.org/doc/manuals/r-release/R-exts.html#FOOT7to
successfully run R CMD check on the package must be listed in
one
of
‘
Depends’ or ‘Suggests’ or ‘Imports’. Packages used to run
examples
or
tests conditionally (e.g. via if(require(pkgname))) should
be
listed
in ‘Suggests’ or ‘Enhances’. (This allows checkers to ensure
that
all
the packages needed for a complete check are installed.)In particular, packages providing “only” data for examples or
vignettes
should be listed in ‘Suggests’ rather than ‘Depends’ in order
to
make
lean
installations possible.brian
On Mon, Feb 9, 2015 at 1:06 PM, bkandel <
[email protected]>
wrote:If we go with '::' calls, is a global import performed on
the
package
or
is
only that specific function imported?On 9 February 2015 at 13:02, John Muschelli <
[email protected]>
wrote:Overall, in any of my packages, I use
@importFrom package functiona functionb
and so forth so that I do not have to load all the
functionality
of a
packageThis can limit what you need and speed up time. Using ::
is
fine,
(":::"
is an auto-reject from CRAN), especially when there are
multiple
functions
of the same name that are hidden.On Mon, Feb 9, 2015 at 12:46 PM, bkandel <
[email protected]wrote:
OK, I'll try that.
On 9 February 2015 at 12:43, stnava <
[email protected]>
wrote:yes - maybe you are right .... definitely ::: is
prohibited
...if you want to pursue this, then you can try the
following:(1) change imports to suggests
(2) using NAMESPACE as a guide, identify all the
functions
that
need
::
and then fix them ...(3) test with
R CMD INSTALL ANTsR
R CMD build ANTsR
R CMD check ANTsR_1.0.tar.gz --as-crani am making progress with the operators but not there
yet
...brian
On Mon, Feb 9, 2015 at 12:39 PM, bkandel <
[email protected]wrote:
The R extension manual (
http://cran.r-project.org/doc/manuals/r-release/R-exts.html#Package-Dependencies
)
says:
R code in the package should call library or require
only
exceptionally.
Such calls are never needed for packages listed in
‘Depends’
as
they
will
already be on the search path. It used to be common
practice
to
use
require
calls for packages listed in ‘suggests’ in functions
which
used
their
functionality, but nowadays it is better to access
such
functionality
via
:: calls.Doesn't this imply that Suggests + :: calls are
acceptable?
(Or,
'exceptionally', to use require, but in any case
Suggests +
using
external
packages should be allowed.)On 9 February 2015 at 12:20, stnava <
[email protected]>
wrote:yes - those are prohibited
brian
On Mon, Feb 9, 2015 at 12:14 PM, bkandel <
[email protected]wrote:
Would using "suggests" also trigger failures if
all
the
functions
were
accessed via '::' calls?On 9 February 2015 at 12:05, stnava <
[email protected]>
wrote:"Suggests" contributes to the problem - names
of
functions
dont
get
imported thus triggering several different
types
of
check
failures.
Importing is what's time consuming on startup.—
Reply to this email directly or view it on
GitHub
<.
—
Reply to this email directly or view it on
GitHub
<.
—
Reply to this email directly or view it on GitHub
<.
—
Reply to this email directly or view it on GitHub
<
#8 (comment)
.—
Reply to this email directly or view it on GitHub
<
#8 (comment)
.—
Reply to this email directly or view it on GitHub
<
#8 (comment)
.—
Reply to this email directly or view it on GitHub
<
#8 (comment)
.—
Reply to this email directly or view it on GitHub
<
#8 (comment)
.—
Reply to this email directly or view it on GitHub
<
#8 (comment)
.—
Reply to this email directly or view it on GitHub
<#8 (comment)
.—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).
from antsr.
bkandel
commented on August 30, 2024
yes--fixing now.
On 9 February 2015 at 16:54, stnava [email protected] wrote:
so far i like it ... any idea how to get rid of this:
Missing or unexported objects:
‘rgl::drawScene.rgl’ ‘robust::lmrob’ ‘robust::lmrob.control’
brian
On Mon, Feb 9, 2015 at 4:42 PM, bkandel [email protected] wrote:
OK, I just pushed this change. Only the most minimal set of packages is
required (Rcpp, tools, and methods, although I don't know why tools and
methods are required--Brian, could we make tools and methods
"suggested"?),
and all others are loaded on-the-fly via :: calls. Cran checking is still
working.If everyone agrees that this is the way to go, then from now on please
preface all calls to external packages with '::'.On 9 February 2015 at 13:50, John Muschelli [email protected]
wrote:
I assumed you were using that to create your NAMESPACE. I highly
recommend
that if it's not too much trouble. I don't know how you're building
right
now (using devtools I assume?), but it may be easy/hard depending on
taht.On Mon, Feb 9, 2015 at 1:42 PM, stnava [email protected]
wrote:i tried it but it produced an unloadable result ... it's an
experiment
that
may require several iterations through all functions to get right.brian
On Mon, Feb 9, 2015 at 1:39 PM, bkandel [email protected]
wrote:General question: Why are we not using roxygen to generate our
NAMESPACE
file? It has support for importFrom, and it will be a nightmare to
keep
track of all the imports manually.On 9 February 2015 at 13:25, John Muschelli <
[email protected]>
wrote:I don't believe the :: will do much with respect to startup time
because
importFrom should only load the package function when the
function
with
the
import directive is called, but I'm not 100% sure on that.On Mon, Feb 9, 2015 at 1:21 PM, bkandel <
[email protected]>
wrote:There was a thread on this exact issue:
https://stat.ethz.ch/pipermail/r-help/2011-January/264516.html
It appears that importFrom will shrink the startup time,
because
we
won't
have to load the entire package, but :: will (I think) minimize
startup
time even more because the package is not loaded until the
function
is
called. It is not clear to me whether this actually works,
though--it
will
need some experimentation.On 9 February 2015 at 13:15, stnava [email protected]
wrote:am embarrassed to say i never read these directions before:
The general rules are
- A package should be listed in only one of these fields.
- Packages whose namespace only is needed to load the package
using
library(pkgname) should be listed in the ‘Imports’ field and
not
in
the ‘
Depends’ field. Packages listed in imports or importFrom
directives
in
the NAMESPACE file should almost always be in ‘Imports’ and
not
‘Depends
’.- Packages that need to be attached to successfully load the
package
using library(pkgname) must be listed in the ‘Depends’ field.- All packages that are needed7
<
http://cran.r-project.org/doc/manuals/r-release/R-exts.html#FOOT7to
successfully run R CMD check on the package must be listed in
one
of
‘
Depends’ or ‘Suggests’ or ‘Imports’. Packages used to run
examples
or
tests conditionally (e.g. via if(require(pkgname))) should
be
listed
in ‘Suggests’ or ‘Enhances’. (This allows checkers to ensure
that
all
the packages needed for a complete check are installed.)In particular, packages providing “only” data for examples or
vignettes
should be listed in ‘Suggests’ rather than ‘Depends’ in order
to
make
lean
installations possible.brian
On Mon, Feb 9, 2015 at 1:06 PM, bkandel <
[email protected]>
wrote:If we go with '::' calls, is a global import performed on
the
package
or
is
only that specific function imported?On 9 February 2015 at 13:02, John Muschelli <
[email protected]>
wrote:Overall, in any of my packages, I use
@importFrom package functiona functionb
and so forth so that I do not have to load all the
functionality
of a
packageThis can limit what you need and speed up time. Using ::
is
fine,
(":::"
is an auto-reject from CRAN), especially when there are
multiple
functions
of the same name that are hidden.On Mon, Feb 9, 2015 at 12:46 PM, bkandel <
[email protected]wrote:
OK, I'll try that.
On 9 February 2015 at 12:43, stnava <
[email protected]>
wrote:yes - maybe you are right .... definitely ::: is
prohibited
...if you want to pursue this, then you can try the
following:(1) change imports to suggests
(2) using NAMESPACE as a guide, identify all the
functions
that
need
::
and then fix them ...(3) test with
R CMD INSTALL ANTsR
R CMD build ANTsR
R CMD check ANTsR_1.0.tar.gz --as-crani am making progress with the operators but not there
yet
...brian
On Mon, Feb 9, 2015 at 12:39 PM, bkandel <
[email protected]wrote:
The R extension manual (
http://cran.r-project.org/doc/manuals/r-release/R-exts.html#Package-Dependencies
)
says:
R code in the package should call library or
require
only
exceptionally.
Such calls are never needed for packages listed in
‘Depends’
as
they
will
already be on the search path. It used to be common
practice
to
use
require
calls for packages listed in ‘suggests’ in
functions
which
used
their
functionality, but nowadays it is better to access
such
functionality
via
:: calls.Doesn't this imply that Suggests + :: calls are
acceptable?
(Or,
'exceptionally', to use require, but in any case
Suggests +
using
external
packages should be allowed.)On 9 February 2015 at 12:20, stnava <
[email protected]>
wrote:yes - those are prohibited
brian
On Mon, Feb 9, 2015 at 12:14 PM, bkandel <
[email protected]wrote:
Would using "suggests" also trigger failures if
all
the
functions
were
accessed via '::' calls?On 9 February 2015 at 12:05, stnava <
[email protected]>
wrote:"Suggests" contributes to the problem - names
of
functions
dont
get
imported thus triggering several different
types
of
check
failures.
Importing is what's time consuming on
startup.—
Reply to this email directly or view it on
GitHub
<.
—
Reply to this email directly or view it on
GitHub
<.
—
Reply to this email directly or view it on GitHub
<.
—
Reply to this email directly or view it on GitHub
<
#8 (comment)
.—
Reply to this email directly or view it on GitHub
<
#8 (comment)
.—
Reply to this email directly or view it on GitHub
<
#8 (comment)
.—
Reply to this email directly or view it on GitHub
<
#8 (comment)
.—
Reply to this email directly or view it on GitHub
<
#8 (comment)
.—
Reply to this email directly or view it on GitHub
<
#8 (comment)
.—
Reply to this email directly or view it on GitHub
<
#8 (comment)
.—
Reply to this email directly or view it on GitHub
<#8 (comment)
.—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).
from antsr.
bkandel
commented on August 30, 2024
The "Missing or unexported" bug is fixed. I also used roxygen to generate
a NAMESPACE file. The only thing I had to change was to insert an
@useDynLib ANTsR tag in antsImage_class.R. It installed and loaded for me
and appears to be working fine.
On 9 February 2015 at 17:01, Ben Kandel [email protected] wrote:
yes--fixing now.
On 9 February 2015 at 16:54, stnava [email protected] wrote:
so far i like it ... any idea how to get rid of this:
Missing or unexported objects:
‘rgl::drawScene.rgl’ ‘robust::lmrob’ ‘robust::lmrob.control’
brian
On Mon, Feb 9, 2015 at 4:42 PM, bkandel [email protected] wrote:
OK, I just pushed this change. Only the most minimal set of packages is
required (Rcpp, tools, and methods, although I don't know why tools and
methods are required--Brian, could we make tools and methods
"suggested"?),
and all others are loaded on-the-fly via :: calls. Cran checking is
still
working.If everyone agrees that this is the way to go, then from now on please
preface all calls to external packages with '::'.On 9 February 2015 at 13:50, John Muschelli [email protected]
wrote:
I assumed you were using that to create your NAMESPACE. I highly
recommend
that if it's not too much trouble. I don't know how you're building
right
now (using devtools I assume?), but it may be easy/hard depending on
taht.On Mon, Feb 9, 2015 at 1:42 PM, stnava [email protected]
wrote:i tried it but it produced an unloadable result ... it's an
experiment
that
may require several iterations through all functions to get right.brian
On Mon, Feb 9, 2015 at 1:39 PM, bkandel [email protected]
wrote:General question: Why are we not using roxygen to generate our
NAMESPACE
file? It has support for importFrom, and it will be a nightmare to
keep
track of all the imports manually.On 9 February 2015 at 13:25, John Muschelli <
[email protected]>
wrote:I don't believe the :: will do much with respect to startup time
because
importFrom should only load the package function when the
function
with
the
import directive is called, but I'm not 100% sure on that.On Mon, Feb 9, 2015 at 1:21 PM, bkandel <
[email protected]>
wrote:There was a thread on this exact issue:
https://stat.ethz.ch/pipermail/r-help/2011-January/264516.html
It appears that importFrom will shrink the startup time,
because
we
won't
have to load the entire package, but :: will (I think)
minimize
startup
time even more because the package is not loaded until the
function
is
called. It is not clear to me whether this actually works,
though--it
will
need some experimentation.On 9 February 2015 at 13:15, stnava <[email protected]
wrote:
am embarrassed to say i never read these directions before:
The general rules are
- A package should be listed in only one of these fields.
- Packages whose namespace only is needed to load the
package
using
library(pkgname) should be listed in the ‘Imports’ field and
not
in
the ‘
Depends’ field. Packages listed in imports or importFrom
directives
in
the NAMESPACE file should almost always be in ‘Imports’ and
not
‘Depends
’.- Packages that need to be attached to successfully load the
package
using library(pkgname) must be listed in the ‘Depends’
field.- All packages that are needed7
<
http://cran.r-project.org/doc/manuals/r-release/R-exts.html#FOOT7to
successfully run R CMD check on the package must be listed
in
one
of
‘
Depends’ or ‘Suggests’ or ‘Imports’. Packages used to run
examples
or
tests conditionally (e.g. via if(require(pkgname)))
should be
listed
in ‘Suggests’ or ‘Enhances’. (This allows checkers to ensure
that
all
the packages needed for a complete check are installed.)In particular, packages providing “only” data for examples
or
vignettes
should be listed in ‘Suggests’ rather than ‘Depends’ in
order
to
make
lean
installations possible.brian
On Mon, Feb 9, 2015 at 1:06 PM, bkandel <
[email protected]>
wrote:If we go with '::' calls, is a global import performed on
the
package
or
is
only that specific function imported?On 9 February 2015 at 13:02, John Muschelli <
[email protected]>
wrote:Overall, in any of my packages, I use
@importFrom package functiona functionb
and so forth so that I do not have to load all the
functionality
of a
packageThis can limit what you need and speed up time. Using
:: is
fine,
(":::"
is an auto-reject from CRAN), especially when there are
multiple
functions
of the same name that are hidden.On Mon, Feb 9, 2015 at 12:46 PM, bkandel <
[email protected]wrote:
OK, I'll try that.
On 9 February 2015 at 12:43, stnava <
[email protected]>
wrote:yes - maybe you are right .... definitely ::: is
prohibited
...if you want to pursue this, then you can try the
following:(1) change imports to suggests
(2) using NAMESPACE as a guide, identify all the
functions
that
need
::
and then fix them ...(3) test with
R CMD INSTALL ANTsR
R CMD build ANTsR
R CMD check ANTsR_1.0.tar.gz --as-crani am making progress with the operators but not
there
yet
...brian
On Mon, Feb 9, 2015 at 12:39 PM, bkandel <
[email protected]wrote:
The R extension manual (
http://cran.r-project.org/doc/manuals/r-release/R-exts.html#Package-Dependencies
)
says:
R code in the package should call library or
require
only
exceptionally.
Such calls are never needed for packages listed in
‘Depends’
as
they
will
already be on the search path. It used to be
common
practice
to
use
require
calls for packages listed in ‘suggests’ in
functions
which
used
their
functionality, but nowadays it is better to access
such
functionality
via
:: calls.Doesn't this imply that Suggests + :: calls are
acceptable?
(Or,
'exceptionally', to use require, but in any case
Suggests +
using
external
packages should be allowed.)On 9 February 2015 at 12:20, stnava <
[email protected]>
wrote:yes - those are prohibited
brian
On Mon, Feb 9, 2015 at 12:14 PM, bkandel <
[email protected]wrote:
Would using "suggests" also trigger failures
if
all
the
functions
were
accessed via '::' calls?On 9 February 2015 at 12:05, stnava <
[email protected]>
wrote:"Suggests" contributes to the problem -
names
of
functions
dont
get
imported thus triggering several different
types
of
check
failures.
Importing is what's time consuming on
startup.—
Reply to this email directly or view it on
GitHub
<.
—
Reply to this email directly or view it on
GitHub
<.
—
Reply to this email directly or view it on
GitHub
<.
—
Reply to this email directly or view it on GitHub
<.
—
Reply to this email directly or view it on GitHub
<
#8 (comment)
.—
Reply to this email directly or view it on GitHub
<
#8 (comment)
.—
Reply to this email directly or view it on GitHub
<
#8 (comment)
.—
Reply to this email directly or view it on GitHub
<
#8 (comment)
.—
Reply to this email directly or view it on GitHub
<
#8 (comment)
.—
Reply to this email directly or view it on GitHub
<
#8 (comment)
.—
Reply to this email directly or view it on GitHub
<#8 (comment)
.—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).
from antsr.
stnava
commented on August 30, 2024
brilliant - this libraryname::functionname this is a lifesaver!
brian
On Mon, Feb 9, 2015 at 5:18 PM, bkandel [email protected] wrote:
The "Missing or unexported" bug is fixed. I also used roxygen to generate
a NAMESPACE file. The only thing I had to change was to insert an
@useDynLib ANTsR tag in antsImage_class.R. It installed and loaded for me
and appears to be working fine.On 9 February 2015 at 17:01, Ben Kandel [email protected] wrote:
yes--fixing now.
On 9 February 2015 at 16:54, stnava [email protected] wrote:
so far i like it ... any idea how to get rid of this:
Missing or unexported objects:
‘rgl::drawScene.rgl’ ‘robust::lmrob’ ‘robust::lmrob.control’
brian
On Mon, Feb 9, 2015 at 4:42 PM, bkandel [email protected]
wrote:OK, I just pushed this change. Only the most minimal set of packages
is
required (Rcpp, tools, and methods, although I don't know why tools
and
methods are required--Brian, could we make tools and methods
"suggested"?),
and all others are loaded on-the-fly via :: calls. Cran checking is
still
working.If everyone agrees that this is the way to go, then from now on please
preface all calls to external packages with '::'.On 9 February 2015 at 13:50, John Muschelli <[email protected]
wrote:
I assumed you were using that to create your NAMESPACE. I highly
recommend
that if it's not too much trouble. I don't know how you're building
right
now (using devtools I assume?), but it may be easy/hard depending on
taht.On Mon, Feb 9, 2015 at 1:42 PM, stnava [email protected]
wrote:i tried it but it produced an unloadable result ... it's an
experiment
that
may require several iterations through all functions to get right.brian
On Mon, Feb 9, 2015 at 1:39 PM, bkandel <[email protected]
wrote:
General question: Why are we not using roxygen to generate our
NAMESPACE
file? It has support for importFrom, and it will be a nightmare
to
keep
track of all the imports manually.On 9 February 2015 at 13:25, John Muschelli <
[email protected]>
wrote:I don't believe the :: will do much with respect to startup
time
because
importFrom should only load the package function when the
function
with
the
import directive is called, but I'm not 100% sure on that.On Mon, Feb 9, 2015 at 1:21 PM, bkandel <
[email protected]>
wrote:There was a thread on this exact issue:
https://stat.ethz.ch/pipermail/r-help/2011-January/264516.html
It appears that importFrom will shrink the startup time,
because
we
won't
have to load the entire package, but :: will (I think)
minimize
startup
time even more because the package is not loaded until the
function
is
called. It is not clear to me whether this actually works,
though--it
will
need some experimentation.On 9 February 2015 at 13:15, stnava <
[email protected]wrote:
am embarrassed to say i never read these directions
before:The general rules are
- A package should be listed in only one of these fields.
- Packages whose namespace only is needed to load the
package
using
library(pkgname) should be listed in the ‘Imports’ field
and
not
in
the ‘
Depends’ field. Packages listed in imports or importFrom
directives
in
the NAMESPACE file should almost always be in ‘Imports’
and
not
‘Depends
’.- Packages that need to be attached to successfully load
the
package
using library(pkgname) must be listed in the ‘Depends’
field.- All packages that are needed7
<
http://cran.r-project.org/doc/manuals/r-release/R-exts.html#FOOT7to
successfully run R CMD check on the package must be listed
in
one
of
‘
Depends’ or ‘Suggests’ or ‘Imports’. Packages used to run
examples
or
tests conditionally (e.g. via if(require(pkgname)))
should be
listed
in ‘Suggests’ or ‘Enhances’. (This allows checkers to
ensure
that
all
the packages needed for a complete check are installed.)In particular, packages providing “only” data for examples
or
vignettes
should be listed in ‘Suggests’ rather than ‘Depends’ in
order
to
make
lean
installations possible.brian
On Mon, Feb 9, 2015 at 1:06 PM, bkandel <
[email protected]>
wrote:If we go with '::' calls, is a global import performed
on
the
package
or
is
only that specific function imported?On 9 February 2015 at 13:02, John Muschelli <
[email protected]>
wrote:Overall, in any of my packages, I use
@importFrom package functiona functionb
and so forth so that I do not have to load all the
functionality
of a
packageThis can limit what you need and speed up time. Using
:: is
fine,
(":::"
is an auto-reject from CRAN), especially when there
are
multiple
functions
of the same name that are hidden.On Mon, Feb 9, 2015 at 12:46 PM, bkandel <
[email protected]wrote:
OK, I'll try that.
On 9 February 2015 at 12:43, stnava <
[email protected]>
wrote:yes - maybe you are right .... definitely ::: is
prohibited
...if you want to pursue this, then you can try the
following:(1) change imports to suggests
(2) using NAMESPACE as a guide, identify all the
functions
that
need
::
and then fix them ...(3) test with
R CMD INSTALL ANTsR
R CMD build ANTsR
R CMD check ANTsR_1.0.tar.gz --as-crani am making progress with the operators but not
there
yet
...brian
On Mon, Feb 9, 2015 at 12:39 PM, bkandel <
[email protected]wrote:
The R extension manual (
http://cran.r-project.org/doc/manuals/r-release/R-exts.html#Package-Dependencies
)
says:
R code in the package should call library or
require
only
exceptionally.
Such calls are never needed for packages listed
in
‘Depends’
as
they
will
already be on the search path. It used to be
common
practice
to
use
require
calls for packages listed in ‘suggests’ in
functions
which
used
their
functionality, but nowadays it is better to
access
such
functionality
via
:: calls.Doesn't this imply that Suggests + :: calls are
acceptable?
(Or,
'exceptionally', to use require, but in any case
Suggests +
using
external
packages should be allowed.)On 9 February 2015 at 12:20, stnava <
[email protected]>
wrote:yes - those are prohibited
brian
On Mon, Feb 9, 2015 at 12:14 PM, bkandel <
[email protected]wrote:
Would using "suggests" also trigger failures
if
all
the
functions
were
accessed via '::' calls?On 9 February 2015 at 12:05, stnava <
[email protected]>
wrote:"Suggests" contributes to the problem -
names
of
functions
dont
get
imported thus triggering several different
types
of
check
failures.
Importing is what's time consuming on
startup.—
Reply to this email directly or view it on
GitHub
<.
—
Reply to this email directly or view it on
GitHub
<.
—
Reply to this email directly or view it on
GitHub
<.
—
Reply to this email directly or view it on
GitHub
<.
—
Reply to this email directly or view it on GitHub
<.
—
Reply to this email directly or view it on GitHub
<
#8 (comment)
.—
Reply to this email directly or view it on GitHub
<
#8 (comment)
.—
Reply to this email directly or view it on GitHub
<
#8 (comment)
.—
Reply to this email directly or view it on GitHub
<
#8 (comment)
.—
Reply to this email directly or view it on GitHub
<
#8 (comment)
.—
Reply to this email directly or view it on GitHub
<
#8 (comment)
.—
Reply to this email directly or view it on GitHub
<#8 (comment)
.—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).
from antsr.
stnava
commented on August 30, 2024
good news - @bkandel made some great improvements that let us get very close to having a cran ready packages ( at least in terms of R CMD check if not content ) ...
residuals are:
- using log directory ‘/Users/stnava/code/ANTsR.Rcheck’
- using R version 3.1.2 (2014-10-31)
- using platform: x86_64-apple-darwin13.4.0 (64-bit)
- using session charset: UTF-8
- checking for file ‘ANTsR/DESCRIPTION’ ... OK
- checking extension type ... Package
- this is package ‘ANTsR’ version ‘1.0’
- checking CRAN incoming feasibility ... NOTE
Maintainer: ‘Brian B. Avants [email protected]’
New submission - checking package namespace information ... OK
- checking package dependencies ... NOTE
No repository set, so cyclic dependency check skipped - checking if this is a source package ... OK
- checking if there is a namespace ... OK
- checking for executable files ... OK
- checking for hidden files and directories ... OK
- checking for portable file names ... OK
- checking for sufficient/correct file permissions ... OK
- checking whether package ‘ANTsR’ can be installed ... OK
- checking installed package size ... NOTE
installed size is 56.7Mb
sub-directories of 1Mb or more:
libs 55.6Mb - checking package directory ... OK
- checking ‘build’ directory ... OK
- checking DESCRIPTION meta-information ... OK
- checking top-level files ... OK
- checking for left-over files ... OK
- checking index information ... OK
- checking package subdirectories ... WARNING
Found the following directories with names of version control directories:
./src/ANTS/ANTS-build/ITKv4/.git
./src/ANTS/ANTS-build/ITKv4/Modules/Remote/MGHIO/.git
./src/ANTS/ANTS-src/.git
These should not be in a package tarball.
- checking R files for non-ASCII characters ... OK
- checking R files for syntax errors ... OK
- checking whether the package can be loaded ... OK
- checking whether the package can be loaded with stated dependencies ... OK
- checking whether the package can be unloaded cleanly ... OK
- checking whether the namespace can be loaded with stated dependencies ... OK
- checking whether the namespace can be unloaded cleanly ... OK
- checking dependencies in R code ... OK
- checking S3 generic/method consistency ... OK
- checking replacement functions ... OK
- checking foreign function calls ... OK
- checking R code for possible problems ... OK
- checking Rd files ... OK
- checking Rd metadata ... OK
- checking Rd line widths ... OK
- checking Rd cross-references ... OK
- checking for missing documentation entries ... OK
- checking for code/documentation mismatches ... OK
- checking Rd \usage sections ... OK
- checking Rd contents ... OK
- checking for unstated dependencies in examples ... OK
- checking contents of ‘data’ directory ... OK
- checking data for non-ASCII characters ... OK
- checking data for ASCII and uncompressed saves ... OK
- checking line endings in C/C++/Fortran sources/headers ... OK
- checking line endings in Makefiles ... OK
- checking compilation flags in Makevars ... OK
- checking for portable use of
$(BLAS_LIBS) and $ (LAPACK_LIBS) ... OK
checking compiled code ... NOTE
File ‘ANTsR/libs/ANTsR.so’:
Found ‘__ZNSt3__14cerrE’, possibly from ‘std::cerr’ (C++)
Object: ‘invariantImageSimilarity.o’
Compiled code should not call entry points which might terminate R nor
write to stdout/stderr instead of to the console, nor the C RNG.
See ‘Writing portable packages’ in the ‘Writing R Extensions’ manual.
- checking installed files from ‘inst/doc’ ... OK
- checking files in ‘vignettes’ ... OK
- checking examples ... OK
- checking for unstated dependencies in tests ... OK
- checking tests ... OK
Running ‘testthat.R’ - checking for unstated dependencies in vignettes ... OK
- checking package vignettes in ‘inst/doc’ ... OK
- checking running R code from vignettes ... OK
- checking re-building of vignette outputs ... OK
- checking PDF version of manual ... OK
- DONE
WARNING: There was 1 warning.
NOTE: There were 4 notes.
from antsr.
stnava
commented on August 30, 2024
for the 1st error - not sure why cleanup + Rbuildignore arent avoiding this - probably something stupid ...
for the 2nd one - no visible use of std::cerr so still mulling that over ... maybe comes from some itk library that we could avoiding linking ...
from antsr.
jefferis
commented on August 30, 2024
Hi @stnava et al ,
(once again, I'm no expert etc etc especially when it comes to the kind of complex cmake/C++ build tree that you chaps are dealing with, but my 2c follows...)
First of all, some encouragement. It looks like preparing for a CRAN release has resulted in a large number of very positive changes for ANTsR, which is great to see.
Now for the cautionary note, relating to your current build structure and CRAN. I think that you may need to look into whether CRAN will accept a package whose build process
- Involves cmake+git downloading some massive source code repositories
- A lengthy build process that seems to build a number of binaries that are not directly related to the package. This is probably only relevant if CRAN actually builds full binary packages for some platforms (which they may well not because I am not sure that they provide cmake on the CRAN build machines) rather than just hosting your source package.
I think point 1 is the key issue at present and you should perhaps try to clarify on e.g. r-devel mailing list (though this is just a place to find knowledgeable people and not somewhere where you can expect an official CRAN answer). In general, I think that when you build an R source package (aka R CMD build) to be distributed via CRAN it should contain all of the source files required for the build. If this is correct, then for example your cleanup file must not remove all of the source files that cmake+git just downloaded. Rather cleanup+.Rbuildignore must together avoid the stuff that you don't want going into the build file. I am myself hazy on the choice of doing this in cleanup vs .Rbuildignore but this may have an influence on how much of your build starts from scratch with R CMD install / devtools::load_all etc.
If my suspicion re point 1 is correct, your next problem is that there are >3000 source files with path names over 100 bytes, e.g. at 154 bytes:
ANTsR/src/ANTS/ANTS-build/ITKv4/Modules/Registration/Metricsv4/include/itkANTSNeighborhoodCorrelationImageToImageMetricv4GetValueAndDerivativeThreader.hxx
My understanding is that CRAN are not at all happy with this and this could be another blocker unless they are dispensable or can be trimmed in some way.
Best wishes,
Greg.
from antsr.
bkandel
commented on August 30, 2024
This makes sense and I was wondering about it myself. We should probably
do the git cloning in the build process, then not incorporate those .git
files into the .tgz. That way the .tgz will have all the code (ITK, ANTs,
etc.) that we need and we won't have to clone anything during install
(which is probably what those warnings are getting at).
On 11 February 2015 at 01:16, Gregory Jefferis [email protected]
wrote:
Hi @stnava https://github.com/stnava et al ,
(once again, I'm no expert etc etc especially when it comes to the kind of
complex cmake/C++ build tree that you chaps are dealing with, but my 2c
follows...)First of all, some encouragement. It looks like preparing for a CRAN
release has resulted in a large number of very positive changes for ANTsR,
which is great to see.Now for the cautionary note, relating to your current build structure and
CRAN. I think that you may need to look into whether CRAN will accept a
package whose build process
- Involves cmake+git downloading some massive source code repositories
- A lengthy build process that seems to build a number of binaries
that are not directly related to the package. This is probably only
relevant if CRAN actually builds full binary packages for some platforms
(which they may well not because I am not sure that they provide cmake on
the CRAN build machines) rather than just hosting your source package.I think point 1 is the key issue at present and you should perhaps try to
clarify on e.g. r-devel mailing list (though this is just a place to find
knowledgeable people and not somewhere where you can expect an official
CRAN answer). In general, I think that when you build an R source
package (aka R CMD build) to be distributed via CRAN it should contain
all of the source files required for the build. If this is correct,
then for example your cleanup file must not remove all of the source
files that cmake+git just downloaded. Rather cleanup+.Rbuildignore must
together avoid the stuff that you don't want going into the build file. I
am myself hazy on the choice of doing this in cleanup vs .Rbuildignore but
this may have an influence on how much of your build starts from scratch
with R CMD install / devtools::load_all etc.If my suspicion re point 1 is correct, your next problem is that there are
3000 source files with path names over 100 bytes, e.g. at 154 bytes:
ANTsR/src/ANTS/ANTS-build/ITKv4/Modules/Registration/Metricsv4/include/itkANTSNeighborhoodCorrelationImageToImageMetricv4GetValueAndDerivativeThreader.hxx
My understanding is that CRAN are not at all happy with this and this
could be another blocker unless they are dispensable or can be trimmed in
some way.Best wishes,
Greg.
—
Reply to this email directly or view it on GitHub
#8 (comment).
from antsr.
bkandel
commented on August 30, 2024
Another idea may be to figure out an automated way to decide which ITK
header files/libs are actually needed by ANTsR and just keep those. This
should help with both issues.
On 11 February 2015 at 08:26, Ben Kandel [email protected] wrote:
This makes sense and I was wondering about it myself. We should probably
do the git cloning in the build process, then not incorporate those .git
files into the .tgz. That way the .tgz will have all the code (ITK, ANTs,
etc.) that we need and we won't have to clone anything during install
(which is probably what those warnings are getting at).On 11 February 2015 at 01:16, Gregory Jefferis [email protected]
wrote:Hi @stnava https://github.com/stnava et al ,
(once again, I'm no expert etc etc especially when it comes to the kind
of complex cmake/C++ build tree that you chaps are dealing with, but my 2c
follows...)First of all, some encouragement. It looks like preparing for a CRAN
release has resulted in a large number of very positive changes for ANTsR,
which is great to see.Now for the cautionary note, relating to your current build structure and
CRAN. I think that you may need to look into whether CRAN will accept a
package whose build process
- Involves cmake+git downloading some massive source code
repositories- A lengthy build process that seems to build a number of binaries
that are not directly related to the package. This is probably only
relevant if CRAN actually builds full binary packages for some platforms
(which they may well not because I am not sure that they provide cmake on
the CRAN build machines) rather than just hosting your source package.I think point 1 is the key issue at present and you should perhaps try to
clarify on e.g. r-devel mailing list (though this is just a place to find
knowledgeable people and not somewhere where you can expect an official
CRAN answer). In general, I think that when you build an R source
package (aka R CMD build) to be distributed via CRAN it should contain
all of the source files required for the build. If this is correct,
then for example your cleanup file must not remove all of the source
files that cmake+git just downloaded. Rather cleanup+.Rbuildignore must
together avoid the stuff that you don't want going into the build file. I
am myself hazy on the choice of doing this in cleanup vs .Rbuildignore but
this may have an influence on how much of your build starts from scratch
with R CMD install / devtools::load_all etc.If my suspicion re point 1 is correct, your next problem is that there
are >3000 source files with path names over 100 bytes, e.g. at 154 bytes:ANTsR/src/ANTS/ANTS-build/ITKv4/Modules/Registration/Metricsv4/include/itkANTSNeighborhoodCorrelationImageToImageMetricv4GetValueAndDerivativeThreader.hxx
My understanding is that CRAN are not at all happy with this and this
could be another blocker unless they are dispensable or can be trimmed in
some way.Best wishes,
Greg.
—
Reply to this email directly or view it on GitHub
#8 (comment).
from antsr.
stnava
commented on August 30, 2024
i am currently leaning toward a straightforward approach which is just to
distribute a minimal ants and itk with antsr ( no cloning ) . so this
would eliminate the .git warning and would "contain all the code" with,
potentially, short enough filenames.
the major work would be in reforming the itk file structure s.t. it's < 100
bytes ... i have to think about if this can be automated ... i'd guess
that one could get something like below to work
-
put the minimally necessary itk .h and .hxx in one folder
-
make a new cmake file for this that would build etc the libraries that
are necessary -
most of the libraries are related to I/O ... if interested see
ANTsR/src/ANTS/ANTS-build/ITKv4-install/lib/
-
build ants pointing to this new itk ( this should be easy enough )
this is more or less the same as making a separate ritk - as ben pointed
out.
brian
On Wed, Feb 11, 2015 at 8:28 AM, bkandel [email protected] wrote:
Another idea may be to figure out an automated way to decide which ITK
header files/libs are actually needed by ANTsR and just keep those. This
should help with both issues.On 11 February 2015 at 08:26, Ben Kandel [email protected] wrote:
This makes sense and I was wondering about it myself. We should probably
do the git cloning in the build process, then not incorporate those .git
files into the .tgz. That way the .tgz will have all the code (ITK, ANTs,
etc.) that we need and we won't have to clone anything during install
(which is probably what those warnings are getting at).On 11 February 2015 at 01:16, Gregory Jefferis <[email protected]
wrote:
Hi @stnava https://github.com/stnava et al ,
(once again, I'm no expert etc etc especially when it comes to the kind
of complex cmake/C++ build tree that you chaps are dealing with, but my
2c
follows...)First of all, some encouragement. It looks like preparing for a CRAN
release has resulted in a large number of very positive changes for
ANTsR,
which is great to see.Now for the cautionary note, relating to your current build structure
and
CRAN. I think that you may need to look into whether CRAN will accept a
package whose build process
- Involves cmake+git downloading some massive source code
repositories- A lengthy build process that seems to build a number of binaries
that are not directly related to the package. This is probably only
relevant if CRAN actually builds full binary packages for some platforms
(which they may well not because I am not sure that they provide cmake
on
the CRAN build machines) rather than just hosting your source package.I think point 1 is the key issue at present and you should perhaps try
to
clarify on e.g. r-devel mailing list (though this is just a place to
find
knowledgeable people and not somewhere where you can expect an official
CRAN answer). In general, I think that when you build an R source
package (aka R CMD build) to be distributed via CRAN it should contain
all of the source files required for the build. If this is correct,
then for example your cleanup file must not remove all of the source
files that cmake+git just downloaded. Rather cleanup+.Rbuildignore must
together avoid the stuff that you don't want going into the build file.
I
am myself hazy on the choice of doing this in cleanup vs .Rbuildignore
but
this may have an influence on how much of your build starts from scratch
with R CMD install / devtools::load_all etc.If my suspicion re point 1 is correct, your next problem is that there
are >3000 source files with path names over 100 bytes, e.g. at 154
bytes:ANTsR/src/ANTS/ANTS-build/ITKv4/Modules/Registration/Metricsv4/include/itkANTSNeighborhoodCorrelationImageToImageMetricv4GetValueAndDerivativeThreader.hxx
My understanding is that CRAN are not at all happy with this and this
could be another blocker unless they are dispensable or can be trimmed
in
some way.Best wishes,
Greg.
—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).
from antsr.
stnava
commented on August 30, 2024
as @jeffduda pointed out , this
ANTsR/src/ANTS/ANTS-build/ITKv4-install/include/ITK-4.8/
already has the structure needed for a simplified itk install - this is like the RcppEigen project ...
the additional issue is then getting the stuff in the lib directories compiled ...
the stuff here: ANTsR/src/ANTS/ANTS-build/ITKv4-install/lib/
@jeffduda any interest in trying this? i.e. making a "flat" itk that still produces the desired libraries?
from antsr.
jeffduda
commented on August 30, 2024
@stnava, yeah, I can take a look at the "flat" itk idea.
On Wed, Feb 11, 2015 at 12:25 PM, stnava [email protected] wrote:
as @jeffduda https://github.com/jeffduda pointed out , this
ANTsR/src/ANTS/ANTS-build/ITKv4-install/include/ITK-4.8/
already has the structure needed for a simplified itk install - this is
like the RcppEigen project ...the additional issue is then getting the stuff in the lib directories
compiled ...the stuff here: ANTsR/src/ANTS/ANTS-build/ITKv4-install/lib/
@jeffduda https://github.com/jeffduda any interest in trying this? i.e.
making a "flat" itk that still produces the desired libraries?—
Reply to this email directly or view it on GitHub
#8 (comment).
from antsr.
armaneshaghi
commented on August 30, 2024
@jeffduda this could be immensely helpful for us to get coverage and test results, if we reduce build time so that I can build a second time without compiler optimization inside travis ...
from antsr.
stnava
commented on August 30, 2024
@jeffduda - one idea might be to distribute the code as "flat itk" but then
(with a utility script) reorganize it into the "standard" itk directory
structure. then this would amount to just writing a script to "flatten"
and "unflatten" itk ...
brian
On Wed, Feb 11, 2015 at 2:52 PM, Arman Eshaghi [email protected]
wrote:
@jeffduda https://github.com/jeffduda this could be immensely helpful
for us to get coverage and test results, if we reduce build time so that I
can build a second time without compiler optimization inside travis ...—
Reply to this email directly or view it on GitHub
#8 (comment).
from antsr.
jeffduda
commented on August 30, 2024
@stnava, ok, should this also deal with the 100 byte issue, i.e store files
with shortened names in the flat structure, but when unflattened, they
would have the correct name?
On Wed, Feb 11, 2015 at 3:03 PM, stnava [email protected] wrote:
@jeffduda - one idea might be to distribute the code as "flat itk" but then
(with a utility script) reorganize it into the "standard" itk directory
structure. then this would amount to just writing a script to "flatten"
and "unflatten" itk ...brian
On Wed, Feb 11, 2015 at 2:52 PM, Arman Eshaghi [email protected]
wrote:@jeffduda https://github.com/jeffduda this could be immensely helpful
for us to get coverage and test results, if we reduce build time so that
I
can build a second time without compiler optimization inside travis ...—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).
from antsr.
stnava
commented on August 30, 2024
for x in find ./ITK/Modules/ -name "*hxx" ; do echo $x | wc ; done
the above script suggests there are not too many files that exceed the 100 byte limit - but yes we'd need these to be "shortened" - but having the flat "install" structure may get us there. e.g.
cd ANTsR/src/ANTS/ANTS-build/ITKv4-install
for x in find ./ -name "*hxx" ; do echo $x ; echo $x | wc ; done
suggests that only this name would be a problem:
itkANTSNeighborhoodCorrelationImageToImageMetricv4GetValueAndDerivativeThreader.hxx
another advantage of repackaging itk is that we would only need to distribute the core cmake files and this directory:
MacBook-Pro:ITK stnava$ ls Modules/
Modules/:
Bridge Core Filtering Nonunit Registration Segmentation Video
Compatibility External IO Numerics Remote ThirdParty
we could exclude:
Documentation Examples Testing Utilities Wrapping
.....
from antsr.
stnava
commented on August 30, 2024
i wonder if we could just do something sneaky like
flatten
zip itk.zip -r ITK
mv itk.zip nevermindme.txt
unflatten
mv nevermindme.txt itk.zip
unzip itk.zip
could be called in configure .... zip would have to be platform independent ...
just not sure if R CMD check would catch this trickery or not
from antsr.
jeffduda
commented on August 30, 2024
is there a human-based check at some point? probably wouldn't pass that.
On Wed, Feb 11, 2015 at 3:18 PM, stnava [email protected] wrote:
i wonder if we could just do something sneaky like
flattenzip itk.zip -r ITK
mv itk.zip nevermindme.txt
unflattenmv nevermindme.txt itk.zip
unzip itk.zipcould be called in configure .... zip would have to be platform
independent ...just not sure if R CMD check would catch this trickery or not
—
Reply to this email directly or view it on GitHub
#8 (comment).
from antsr.
bkandel
commented on August 30, 2024
Wow. I'm just picturing a lion walking around with a "nevermindme.txt"
sign on its back.
I'd be nervous that the cran gods would get irritated. We would also
probably get flagged for having non-ASCII text in the package.
On 11 February 2015 at 15:18, stnava [email protected] wrote:
i wonder if we could just do something sneaky like
flattenzip itk.zip -r ITK
mv itk.zip nevermindme.txt
unflattenmv nevermindme.txt itk.zip
unzip itk.zipcould be called in configure .... zip would have to be platform
independent ...just not sure if R CMD check would catch this trickery or not
—
Reply to this email directly or view it on GitHub
#8 (comment).
from antsr.
jefferis
commented on August 30, 2024
On 11 Feb 2015, at 12:18, stnava [email protected] wrote:
just not sure if R CMD check would catch this trickery or not
possibly not … but one of the CRAN maintainers would eventually – they are famously sharp-eyed – and they would not be amused.
Further to my comments yesterday, writing R exts does not impose an absolute ban on paths >100 bytes
http://cran.r-project.org/doc/manuals/r-release/R-exts.html#Package-structure
but I had heard they were not very sympathetic. Nevertheless it might be better to focus on the other build issues and try to see if the CRAN maintainers would accept paths but (not individual path elements) >100 bytes if that simplifies your life.
Best,
Greg.
from antsr.
jefferis
commented on August 30, 2024
On 11 Feb 2015, at 12:24, bkandel [email protected] wrote:
I'd be nervous that the cran gods would get irritated. We would also
probably get flagged for having non-ASCII text in the package.
Yup!
from antsr.
stnava
commented on August 30, 2024
@jeffduda maybe a better "flattening" approach would be to just loop over all of the itk files and then rename / mv only those with length >= 100 bytes ... we should be able to automate this pretty easily within an R script .... so the 3000 referred to by @jefferis would be the only things we change ... we could add the R function as a hidden function within antsr and keep track of our itk tag there too.
from antsr.
stnava
commented on August 30, 2024
@jeffduda made a test location for flat itk activity https://github.com/stnava/ANTsRCran .... didnt want to experiment in core ANTsR repo b/c of the large size of itk ... it would really pollute the repo and will take too much space .... so we can use this one for itk experiments etc i.e. things that dont have much to do with actual R code but do help us meet cran submission requirements. TODO:
- shorten filenames
- embed shrunken ants and itk in the repo
- get rid of cerr calls
from antsr.
jeffduda
commented on August 30, 2024
One easier option may be to build ITK in src/ instead of via ANTs
superbuild. this seems to fix the path size issue.
On Wed, Feb 11, 2015 at 6:59 PM, stnava [email protected] wrote:
@jeffduda https://github.com/jeffduda made a test location for flat itk
activity https://github.com/stnava/ANTsRCran .... didnt want to
experiment in core ANTsR repo b/c of the large size of itk ... it would
really pollute the repo and will take too much space .... so we can use
this one for itk experiments etc i.e. things that dont have much to do with
actual R code but do help us meet cran submission requirements. TODO:
shorten filenames
embed shrunken ants and itk in the repo
get rid of cerr calls
—
Reply to this email directly or view it on GitHub
#8 (comment).
from antsr.
stnava
commented on August 30, 2024
Awesome!
Can you put non superbuild version in antsrcran? Really don't want to
commit this to main repo just yet.
On Feb 11, 2015 7:44 PM, "Jeffrey Duda" [email protected] wrote:
One easier option may be to build ITK in src/ instead of via ANTs
superbuild. this seems to fix the path size issue.On Wed, Feb 11, 2015 at 6:59 PM, stnava [email protected] wrote:
@jeffduda https://github.com/jeffduda made a test location for flat
itk
activity https://github.com/stnava/ANTsRCran .... didnt want to
experiment in core ANTsR repo b/c of the large size of itk ... it would
really pollute the repo and will take too much space .... so we can use
this one for itk experiments etc i.e. things that dont have much to do
with
actual R code but do help us meet cran submission requirements. TODO:shorten filenames
embed shrunken ants and itk in the repo
get rid of cerr calls
—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).
from antsr.
stnava
commented on August 30, 2024
i made some changes to the build process that will make it much easier ( i think ) to ultimately distribute itk and ants together with antsr. the key things are:
- try to build only the necessary itk modules
- try to build only the necessary ants exes
- make the installed itk/ants libs/includes a little shallower
this should make moving from https://github.com/stnava/ANTsR (development) to https://github.com/stnava/ANTsRCran (where we will store a version of ants and itk source) very easy
in fact, i set up my local https://github.com/stnava/ANTsRCran to be able to pull from https://github.com/stnava/ANTsR ....
from antsr.
stnava
commented on August 30, 2024
a nice example of @bkandel's recent work
fi<-antsImageRead( getANTsRData("r16") ,2)
mi<-antsImageRead( getANTsRData("r64") ,2)
fi<-fi/max(fi)
mi<-mi/max(mi)
plot( fi + mi )
lap<- iMath(fi,"Laplacian")
gr<- iMath(fi,"Grad")
plot( fi , list( lap/mean(lap), gr/mean(gr) ) )
apologies, all, for compilation issues today - should be resolved now as of:
https://travis-ci.org/stnava/ANTsR/builds/50571644
hopefully this compile system is a little better ... at least it's closer to what we might do when we try to submit to cran ....
from antsr.
stnava
commented on August 30, 2024
er - as of: https://travis-ci.org/stnava/ANTsR/builds/50575163
from antsr.
stnava
commented on August 30, 2024
ok - compile issues resolved ... also:
- can now use devtools::check() - this was due to Rcpp::export in our .cpp functions ... removed these, perhaps unwisely, but it gets things "working"
- still need to think about the compile flags --- also needed to pass -fPIC via cmake to ants and itk compile for linux
- needed to add methods to Depends to resolve a loadMethod error on linux
- resolved a strange documentation issue - probably an erroneous commit somewhere
- devtools::check() yields only a few issues now (w/new compile structure)
- complaint: .git files - trivial to resolve in the future, when submitting to cran
- complaint: significant warning: 'long long' is a C++11 extension [-Wc++11-long-long] .... new to me , not sure what to about it ... maybe some compile flag is needed for itk
-Wnolonglong? - finally: File ‘ANTsR/libs/ANTsR.so’:
Found ‘__ZNSt3__14cerrE’, possibly from ‘std::cerr’ (C++)
Object: ‘invariantImageSimilarity.o’ ..... a nasty issue that will be resolved later when we put itk inside of a cran ready ANTsR
so we are down to just a few real warnings .... only 1 (or 2) of which will take some work
from antsr.
stnava
commented on August 30, 2024
Iatest compile strategy produced cleanest R CMD check ( or devtools::check() ) yet ... only 1 major issue:
- checking compiled code ... NOTE
File ‘ANTsR/libs/ANTsR.so’:
Found ‘__ZNSt3__14cerrE’, possibly from ‘std::cerr’ (C++)
Object: ‘invariantImageSimilarity.o’
in addition to:
- checking installed package size ... NOTE
installed size is 60.2Mb
sub-directories of 1Mb or more:
libs 59.0Mb
and
Found the following directories with names of version control directories:
./src/ants/.git
./src/itks/.git
./src/itks/Modules/Remote/MGHIO/.git
from antsr.
bkandel
commented on August 30, 2024
Great!
I think that getting things ready for Coveralls integration would be really
helpful. One major issue I see with that (beside the build time) is that
the coverage estimate is based on lines called during the testing. That
means that if we have any ITK files in our code tree that are not actually
used in ANTsR, those will be flagged as "not covered". So I guess that's
just another motivation to minimize the number of ITK files that we
distribute with ANTsR. Will also help minimize compile time.
On 13 February 2015 at 06:35, stnava [email protected] wrote:
Iatest compile strategy produced cleanest R CMD check ( or
devtools::check() ) yet ... only 1 major issue:
- checking compiled code ... NOTE File ‘ANTsR/libs/ANTsR.so’: Found
‘__ZNSt3__14cerrE’, possibly from ‘std::cerr’ (C++) Object:
‘invariantImageSimilarity.o’in addition to:
- checking installed package size ... NOTE installed size is 60.2Mb
sub-directories of 1Mb or more: libs 59.0Mband
Found the following directories with names of version control directories:
./src/ants/.git
./src/itks/.git
./src/itks/Modules/Remote/MGHIO/.git—
Reply to this email directly or view it on GitHub
#8 (comment).
from antsr.
stnava
commented on August 30, 2024
Today's update ( currently passes devtools::check() w/exception of the "known" issues to be resolved later - cerr, .git and installed size )
- refactored https://github.com/stnava/ANTsR/blob/master/src/Makevars
- i think this is more in line with cran policies / philosophies
- new approach supports both git cloning and a full source installation
- the latter is what will be needed for windows and cran builds
- i think we can succeed with a source build for windows given appropriate configure.win and Makevars.win files ... but am in no hurry for that
- this new style will probably be annoying for a while and we can change it later very easily s.t. it is less annoying once all this is settled
- worked on iMath some more
- the example below shows how to run all available operations and prints the output
- one essential operation that "breaks" the style is LabelStats - it's "bad" but not terrible, i think, that it's in iMath ... this does not necessarily reflect the views, opinions or positions of all developers
- all the other operations are basic, filter, label or intensity operations - each example runs
- inching closer .... any comments appreciated
img<-antsImageRead( getANTsRData('r16') , 2 )
roiImg<-getMask(i)
data( "iMathOps", package = "ANTsR", envir = environment() ) #
for ( j in c(1:nrow(iMathOps)) )
{
op <- as.character( iMathOps$Operation[j] )
i<-antsImageClone(img)
if ( iMathOps$OperationType[j] == "LabelOp" ) i<-antsImageClone(roiImg)
k <- eval( parse( text = toString( iMathOps$Example[j] ) ) )
print( paste( op , j ) )
print(k)
if ( ! is.na( iMathOps$OutputDimensionalityChange[j] ) )
{
plot( k )
Sys.sleep(1)
}
}
from antsr.
bkandel
commented on August 30, 2024
I think it would be reasonable to separate LabelStats into its own
function. We already have it in getROIValues, but that version uses a very
slow R loop. Just taking that one function out and making it into a
separate function that's just a wrapper of the ITK label stats filter makes
the most sense to me. It would also make parsing the inputs and outputs of
iMath simpler.
I'd be happy to implement this if you agree this is the way to go.
On 18 February 2015 at 15:58, stnava [email protected] wrote:
Today's update ( currently passes devtools::check() w/exception of the
"known" issues to be resolved later - cerr, .git and installed size )
refactored https://github.com/stnava/ANTsR/blob/master/src/Makevars
- i think this is more in line with cran policies / philosophies
- new approach supports both git cloning and a full source
installation- the latter is what will be needed for windows and cran builds
- i think we can succeed with a source build for windows given
appropriate configure.win and Makevars.win files ... but am in no hurry for
that- this new style will probably be annoying for a while and we can
change it later very easily s.t. it is less annoying once all this is
settled
- worked on iMath some more
- the example below shows how to run all available operations and
prints the output- one essential operation that "breaks" the style is LabelStats -
it's "bad" but not terrible, i think, that it's in iMath ... this does not
necessarily reflect the views, opinions or positions of all developers- all the other operations are basic, filter, label or intensity
operations - each example runs
- inching closer .... any comments appreciated
img<-antsImageRead( getANTsRData('r16') , 2 )
roiImg<-getMask(i)
data( "iMathOps", package = "ANTsR", envir = environment() ) #
for ( j in c(1:nrow(iMathOps)) )
{
op <- as.character( iMathOps$Operation[j] )
i<-antsImageClone(img)
if ( iMathOps$OperationType[j] == "LabelOp" ) i<-antsImageClone(roiImg)
k <- eval( parse( text = toString( iMathOps$Example[j] ) ) )
print( paste( op , j ) )
print(k)
if ( ! is.na( iMathOps$OutputDimensionalityChange[j] ) )
{
plot( k )
Sys.sleep(1)
}
}—
Reply to this email directly or view it on GitHub
#8 (comment).
from antsr.
stnava
commented on August 30, 2024
fine with me
brian
On Wed, Feb 18, 2015 at 1:13 PM, bkandel [email protected] wrote:
I think it would be reasonable to separate LabelStats into its own
function. We already have it in getROIValues, but that version uses a very
slow R loop. Just taking that one function out and making it into a
separate function that's just a wrapper of the ITK label stats filter makes
the most sense to me. It would also make parsing the inputs and outputs of
iMath simpler.I'd be happy to implement this if you agree this is the way to go.
On 18 February 2015 at 15:58, stnava [email protected] wrote:
Today's update ( currently passes devtools::check() w/exception of the
"known" issues to be resolved later - cerr, .git and installed size )
- refactored https://github.com/stnava/ANTsR/blob/master/src/Makevars
- i think this is more in line with cran policies / philosophies
- new approach supports both git cloning and a full source
installation- the latter is what will be needed for windows and cran builds
- i think we can succeed with a source build for windows given
appropriate configure.win and Makevars.win files ... but am in no hurry
for
that- this new style will probably be annoying for a while and we can
change it later very easily s.t. it is less annoying once all this is
settled- worked on iMath some more
- the example below shows how to run all available operations and
prints the output- one essential operation that "breaks" the style is LabelStats -
it's "bad" but not terrible, i think, that it's in iMath ... this does
not
necessarily reflect the views, opinions or positions of all developers- all the other operations are basic, filter, label or intensity
operations - each example runs- inching closer .... any comments appreciated
img<-antsImageRead( getANTsRData('r16') , 2 )
roiImg<-getMask(i)
data( "iMathOps", package = "ANTsR", envir = environment() ) #
for ( j in c(1:nrow(iMathOps)) )
{
op <- as.character( iMathOps$Operation[j] )
i<-antsImageClone(img)
if ( iMathOps$OperationType[j] == "LabelOp" ) i<-antsImageClone(roiImg)
k <- eval( parse( text = toString( iMathOps$Example[j] ) ) )
print( paste( op , j ) )
print(k)
if ( ! is.na( iMathOps$OutputDimensionalityChange[j] ) )
{
plot( k )
Sys.sleep(1)
}
}—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).
from antsr.
muschellij2
commented on August 30, 2024
It may be good to have a changelog for the function names and any
add/deletion.
For example, I've noticed N3BiasFieldCorrection has changed
to n3BiasFieldCorrection.
May be more of a wish list though.
On Wed, Feb 18, 2015 at 4:16 PM, stnava [email protected] wrote:
fine with me
brian
On Wed, Feb 18, 2015 at 1:13 PM, bkandel [email protected] wrote:
I think it would be reasonable to separate LabelStats into its own
function. We already have it in getROIValues, but that version uses a
very
slow R loop. Just taking that one function out and making it into a
separate function that's just a wrapper of the ITK label stats filter
makes
the most sense to me. It would also make parsing the inputs and outputs
of
iMath simpler.I'd be happy to implement this if you agree this is the way to go.
On 18 February 2015 at 15:58, stnava [email protected] wrote:
Today's update ( currently passes devtools::check() w/exception of the
"known" issues to be resolved later - cerr, .git and installed size )
- refactored https://github.com/stnava/ANTsR/blob/master/src/Makevars
- i think this is more in line with cran policies / philosophies
- new approach supports both git cloning and a full source
installation- the latter is what will be needed for windows and cran builds
- i think we can succeed with a source build for windows given
appropriate configure.win and Makevars.win files ... but am in no hurry
for
that- this new style will probably be annoying for a while and we can
change it later very easily s.t. it is less annoying once all this is
settled- worked on iMath some more
- the example below shows how to run all available operations and
prints the output- one essential operation that "breaks" the style is LabelStats -
it's "bad" but not terrible, i think, that it's in iMath ... this does
not
necessarily reflect the views, opinions or positions of all developers- all the other operations are basic, filter, label or intensity
operations - each example runs- inching closer .... any comments appreciated
img<-antsImageRead( getANTsRData('r16') , 2 )
roiImg<-getMask(i)
data( "iMathOps", package = "ANTsR", envir = environment() ) #
for ( j in c(1:nrow(iMathOps)) )
{
op <- as.character( iMathOps$Operation[j] )
i<-antsImageClone(img)
if ( iMathOps$OperationType[j] == "LabelOp" ) i<-antsImageClone(roiImg)
k <- eval( parse( text = toString( iMathOps$Example[j] ) ) )
print( paste( op , j ) )
print(k)
if ( ! is.na( iMathOps$OutputDimensionalityChange[j] ) )
{
plot( k )
Sys.sleep(1)
}
}—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).
from antsr.
bkandel
commented on August 30, 2024
All function names are changing to camelCase for consistency.
At this point we're aiming for CRAN/release optimization, not backwards
compatibility. Once we get a CRAN release out in the next couple of
months, we'll stabilize the API.
On 19 February 2015 at 18:05, John Muschelli [email protected]
wrote:
It may be good to have a changelog for the function names and any
add/deletion.For example, I've noticed N3BiasFieldCorrection has changed
to n3BiasFieldCorrection.May be more of a wish list though.
On Wed, Feb 18, 2015 at 4:16 PM, stnava [email protected] wrote:
fine with me
brian
On Wed, Feb 18, 2015 at 1:13 PM, bkandel [email protected]
wrote:I think it would be reasonable to separate LabelStats into its own
function. We already have it in getROIValues, but that version uses a
very
slow R loop. Just taking that one function out and making it into a
separate function that's just a wrapper of the ITK label stats filter
makes
the most sense to me. It would also make parsing the inputs and outputs
of
iMath simpler.I'd be happy to implement this if you agree this is the way to go.
On 18 February 2015 at 15:58, stnava [email protected] wrote:
Today's update ( currently passes devtools::check() w/exception of
the
"known" issues to be resolved later - cerr, .git and installed size )
- refactored
https://github.com/stnava/ANTsR/blob/master/src/Makevars- i think this is more in line with cran policies / philosophies
- new approach supports both git cloning and a full source
installation- the latter is what will be needed for windows and cran builds
- i think we can succeed with a source build for windows given
appropriate configure.win and Makevars.win files ... but am in no
hurry
for
that- this new style will probably be annoying for a while and we can
change it later very easily s.t. it is less annoying once all this is
settled- worked on iMath some more
- the example below shows how to run all available operations and
prints the output- one essential operation that "breaks" the style is LabelStats -
it's "bad" but not terrible, i think, that it's in iMath ... this
does
not
necessarily reflect the views, opinions or positions of all
developers- all the other operations are basic, filter, label or intensity
operations - each example runs- inching closer .... any comments appreciated
img<-antsImageRead( getANTsRData('r16') , 2 )
roiImg<-getMask(i)
data( "iMathOps", package = "ANTsR", envir = environment() ) #
for ( j in c(1:nrow(iMathOps)) )
{
op <- as.character( iMathOps$Operation[j] )
i<-antsImageClone(img)
if ( iMathOps$OperationType[j] == "LabelOp" )
i<-antsImageClone(roiImg)
k <- eval( parse( text = toString( iMathOps$Example[j] ) ) )
print( paste( op , j ) )
print(k)
if ( ! is.na( iMathOps$OutputDimensionalityChange[j] ) )
{
plot( k )
Sys.sleep(1)
}
}—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).
from antsr.
stnava
commented on August 30, 2024
still a few stragglers:
R/Atropos.R
R/ExtractDenseNetwork.R
R/ImageMath.R
R/LabelGeometryMeasures.R
R/LabelImageCentroids.R
R/SummarizeClusters.R
brian
On Thu, Feb 19, 2015 at 3:16 PM, bkandel [email protected] wrote:
All function names are changing to camelCase for consistency.
At this point we're aiming for CRAN/release optimization, not backwards
compatibility. Once we get a CRAN release out in the next couple of
months, we'll stabilize the API.On 19 February 2015 at 18:05, John Muschelli [email protected]
wrote:It may be good to have a changelog for the function names and any
add/deletion.For example, I've noticed N3BiasFieldCorrection has changed
to n3BiasFieldCorrection.May be more of a wish list though.
On Wed, Feb 18, 2015 at 4:16 PM, stnava [email protected]
wrote:fine with me
brian
On Wed, Feb 18, 2015 at 1:13 PM, bkandel [email protected]
wrote:I think it would be reasonable to separate LabelStats into its own
function. We already have it in getROIValues, but that version uses a
very
slow R loop. Just taking that one function out and making it into a
separate function that's just a wrapper of the ITK label stats filter
makes
the most sense to me. It would also make parsing the inputs and
outputs
of
iMath simpler.I'd be happy to implement this if you agree this is the way to go.
On 18 February 2015 at 15:58, stnava [email protected]
wrote:Today's update ( currently passes devtools::check() w/exception of
the
"known" issues to be resolved later - cerr, .git and installed
size )
- refactored
https://github.com/stnava/ANTsR/blob/master/src/Makevars- i think this is more in line with cran policies / philosophies
- new approach supports both git cloning and a full source
installation- the latter is what will be needed for windows and cran builds
- i think we can succeed with a source build for windows given
appropriate configure.win and Makevars.win files ... but am in no
hurry
for
that- this new style will probably be annoying for a while and we can
change it later very easily s.t. it is less annoying once all this
is
settled- worked on iMath some more
- the example below shows how to run all available operations and
prints the output- one essential operation that "breaks" the style is LabelStats -
it's "bad" but not terrible, i think, that it's in iMath ... this
does
not
necessarily reflect the views, opinions or positions of all
developers- all the other operations are basic, filter, label or intensity
operations - each example runs- inching closer .... any comments appreciated
img<-antsImageRead( getANTsRData('r16') , 2 )
roiImg<-getMask(i)
data( "iMathOps", package = "ANTsR", envir = environment() ) #
for ( j in c(1:nrow(iMathOps)) )
{
op <- as.character( iMathOps$Operation[j] )
i<-antsImageClone(img)
if ( iMathOps$OperationType[j] == "LabelOp" )
i<-antsImageClone(roiImg)
k <- eval( parse( text = toString( iMathOps$Example[j] ) ) )
print( paste( op , j ) )
print(k)
if ( ! is.na( iMathOps$OutputDimensionalityChange[j] ) )
{
plot( k )
Sys.sleep(1)
}
}—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).
from antsr.
bkandel
commented on August 30, 2024
R/Atropos.R -- should probably be renamed to atropos.
R/ExtractDenseNetwork.R -- hidden, so I don't know that it's such an issue
anyway.
R/ImageMath.R -- to be replaced by iMath
R/LabelGeometryMeasures.R -- I don't know what this function does (couldn't
easily figure out from ANTs command line either).
R/LabelImageCentroids.R -- maybe rename to labelImageCentroids? I can fix
this.
R/SummarizeClusters.R -- hidden, but maybe should be revealed?
On 19 February 2015 at 18:20, stnava [email protected] wrote:
still a few stragglers:
R/Atropos.R
R/ExtractDenseNetwork.R
R/ImageMath.R
R/LabelGeometryMeasures.R
R/LabelImageCentroids.R
R/SummarizeClusters.R
brian
On Thu, Feb 19, 2015 at 3:16 PM, bkandel [email protected] wrote:
All function names are changing to camelCase for consistency.
At this point we're aiming for CRAN/release optimization, not backwards
compatibility. Once we get a CRAN release out in the next couple of
months, we'll stabilize the API.On 19 February 2015 at 18:05, John Muschelli [email protected]
wrote:It may be good to have a changelog for the function names and any
add/deletion.For example, I've noticed N3BiasFieldCorrection has changed
to n3BiasFieldCorrection.May be more of a wish list though.
On Wed, Feb 18, 2015 at 4:16 PM, stnava [email protected]
wrote:fine with me
brian
On Wed, Feb 18, 2015 at 1:13 PM, bkandel [email protected]
wrote:I think it would be reasonable to separate LabelStats into its own
function. We already have it in getROIValues, but that version
uses a
very
slow R loop. Just taking that one function out and making it into a
separate function that's just a wrapper of the ITK label stats
filter
makes
the most sense to me. It would also make parsing the inputs and
outputs
of
iMath simpler.I'd be happy to implement this if you agree this is the way to go.
On 18 February 2015 at 15:58, stnava [email protected]
wrote:Today's update ( currently passes devtools::check() w/exception
of
the
"known" issues to be resolved later - cerr, .git and installed
size )
- refactored
https://github.com/stnava/ANTsR/blob/master/src/Makevars- i think this is more in line with cran policies / philosophies
- new approach supports both git cloning and a full source
installation- the latter is what will be needed for windows and cran builds
- i think we can succeed with a source build for windows given
appropriate configure.win and Makevars.win files ... but am in no
hurry
for
that- this new style will probably be annoying for a while and we can
change it later very easily s.t. it is less annoying once all
this
is
settled- worked on iMath some more
- the example below shows how to run all available operations and
prints the output- one essential operation that "breaks" the style is LabelStats -
it's "bad" but not terrible, i think, that it's in iMath ... this
does
not
necessarily reflect the views, opinions or positions of all
developers- all the other operations are basic, filter, label or intensity
operations - each example runs- inching closer .... any comments appreciated
img<-antsImageRead( getANTsRData('r16') , 2 )
roiImg<-getMask(i)
data( "iMathOps", package = "ANTsR", envir = environment() ) #
for ( j in c(1:nrow(iMathOps)) )
{
op <- as.character( iMathOps$Operation[j] )
i<-antsImageClone(img)
if ( iMathOps$OperationType[j] == "LabelOp" )
i<-antsImageClone(roiImg)
k <- eval( parse( text = toString( iMathOps$Example[j] ) ) )
print( paste( op , j ) )
print(k)
if ( ! is.na( iMathOps$OutputDimensionalityChange[j] ) )
{
plot( k )
Sys.sleep(1)
}
}—
Reply to this email directly or view it on GitHub
<#8 (comment)
.—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).—
Reply to this email directly or view it on GitHub
#8 (comment).
from antsr.
ntustison
commented on August 30, 2024
from antsr.
Related Issues (20)
- Masking 4D image with 3D mask
- Install repeatedly wants to update ITKR
- How to iterate an iMath function over many images HOT 1
- fitTransformToPairedPoints diffeo example doesn't work HOT 2
- Installation fails on Ubuntu 22.04LTS with R4.2.0 HOT 3
- ERROR: Parsing error: The keyword 'const' is reserved
- Errors in buliding ANTsR vigniettes HOT 1
- AAL template extends beyond MNI cortical surface HOT 7
- installation problem antsLibs() Makevars:6: *** missing separator. Stop. HOT 5
- Error
- antsMotionCalculation Error HOT 1
- colorbar key for antsrSurf HOT 6
- Installation fail with devtools HOT 5
- details about mnib HOT 1
- Failing on ITK when running LINDA HOT 6
- Proper similarity metric for Affine registration HOT 3
- MVPA using ANTsR?
- ITK bug in createJacobianDeterminantImage after upgrade HOT 14
- aslPerfusion HOT 11
- Installation error on Mac OS 12.6.3 with devtools HOT 11
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from antsr.