Everytime I install a system via Quicklisp, i always find myself searching for the name of essential package, which an average user will be interested because it exports the 'final product' API to be played with. Thus anyone needs to know its name and issue the command on REPL:
(use-package :package)
in order to play with it on REPL.
Is there a quick and easy way to determine the packages contained by a system loaded by Quicklisp without searching archaic documentation.
You can list all packages with LIST-ALL-PACKAGES.
If you keep them before and after loading software, you can compare them.
CL-USER 14 > (setf *print-length* 10)
10
CL-USER 15 > (list-all-packages)
(#<The SQL-COMMON package, 0/4 internal, 28/32 external> #<The QL-LISPWORKS package, 0/16 internal, 5/16 external> #<The QL-SETUP package, 25/32 internal, 3/16 external> #<The QL-ALLEGRO package, 0/16 internal, 6/16 external> #<The QL-DIST package, 110/256 internal, 81/256 external> #<The COMM package, 1053/4096 internal, 949/1024 external> #<The MP package, 921/1024 internal, 209/256 external> #<The REG package, 41/64 internal, 0/4 external> #<The LOOP package, 247/256 internal, 3/4 external> #<The QL-DIST-USER package, 0/16 internal, 0/16 external> ...)
CL-USER 16 > (defpackage "FOO")
#<The FOO package, 0/16 internal, 0/16 external>
CL-USER 17 > (list-all-packages)
(#<The SQL-COMMON package, 0/4 internal, 28/32 external> #<The QL-LISPWORKS package, 0/16 internal, 5/16 external> #<The QL-SETUP package, 25/32 internal, 3/16 external> #<The QL-ALLEGRO package, 0/16 internal, 6/16 external> #<The QL-DIST package, 110/256 internal, 81/256 external> #<The COMM package, 1053/4096 internal, 949/1024 external> #<The MP package, 921/1024 internal, 209/256 external> #<The REG package, 41/64 internal, 0/4 external> #<The LOOP package, 247/256 internal, 3/4 external> #<The QL-DIST-USER package, 0/16 internal, 0/16 external> ...)
CL-USER 18 > (set-difference * ***)
(#<The FOO package, 0/16 internal, 0/16 external>)
So you found that between two package listings, there was a package FOO introduced.
Also note that USE-PACKAGE is not necessarily a useful thing. USE-PACKAGE imports the exported symbols into your current package. This may or may not work. It can lead to arbitrary symbol name clashes.
No, there isn't. In general, you can't load a project without reading its documentation to know how to use it.
Unfortunately, sometimes the only documentation is the code itself. Slime helps explore code with M-. but you do have to know where to start.
Related
I installed julia version 1.7.2 successfully, and Julia works fine with simple Julia program constructs.
To use 'symbolics' package, I read that I need to enter:
julia> using Pkg
=> this line executed with julia prompt
julia> Pkg.add("symbolics")
=> this line gives the following error:
symbolics (not found in project, manifest or registry)
I cannot follow this error, and I do not know how to add symbolics pakage to julia to use julia symbolics.jl package.
It should be Pkg.add("Symbolics"), as mentioned in the package installation instructions.
As a rule, Julia packages start with a Capital letter, and generally follow the CamelCase convention.
I have a package which does nothing but reexport other packages' functions.*
However, one of these functions is DBI::dbBegin:
#' #importFrom DBI dbBegin
#' #export
DBI::dbBegin
If I then use roxygen to build the documentation, it works just fine.
==> devtools::document(roclets = c('rd', 'collate', 'namespace'))
Updating foo documentation
Writing NAMESPACE
Loading foo
Writing reexports.Rd
Writing NAMESPACE
Documentation completed
However, when I build the package, a warning is thrown:
==> Rcmd.exe INSTALL --no-multiarch --with-keep.source foo
[...]
*** installing help indices
converting help for package 'foo'
reexports html
Rd warning: C:/Users/xxx/Documents/foo/man/reexports.Rd:14: file link 'dbBegin' in package 'DBI' does not exist and so has been treated as a topic
[...]
The problem here is that DBI::dbBegin's man page is actually called transactions.Rd (along with other functions).
The build itself is successful, and even using the documentation itself works: ?foo::dbBegin opens the standard "Objects exported from other packages" page which successfully links to the correct man page.
So, as far as I can tell, the warning seems harmless, but is there anything I can declare using roxygen to point it to the correct man page?
* That's a lie
I have created an R package (not yet on CRAN) and sent it to a colleague (as a .zip file).
Unfortunately, they were unable to properly build/install it without R throwing an error.
The error received was:
Error: Command failed (1)
In addition: Warning message:
The following packages are referenced using Rcpp::depends attributes however are not listed in the Depends, Imports or LinkingTo fields of the package DESCRIPTION file: RcppProgress
To create the package, I used the RcppArmadillo.package.skeleton() function in R v. 3.4.3.
I works for me, but not for my colleague.
My method in building/installing is:
build("package name") # creates a .tar.gz file
install("package name")
Would simply sending the .tar.gz file to my colleague and simply running install() work?
Here is the DESCRIPTION file:
Package: HACSim
Type: Package
Title: Iterative simulation of species haplotype accumulation curves
Version: 1.0
Date: 2018-04-06
Author: Jarrett Phillips
Maintainer: Jarrett Phillips
Description: Iterative simulation of species haplotype accumulation curves for assessment of sampling completeness
License: GPL (>= 3)
NeedsCompilation: Yes
Imports: ape (>= 5.0),
boot (>= 1.3-20),
investr (>= 1.4.0),
mgcv (>= 1.8-23),
pegas (>= 0.10),
Rcpp (>= 0.12.16),
scam (>= 1.2-2)
LinkingTo: Rcpp,
RcppArmadillo
and NAMESPACE
useDynLib(HACSim, .registration=TRUE)
importFrom(Rcpp, evalCpp)
importFrom(ape, base.freq)
importFrom(ape, read.dna)
importFrom(boot, boot)
importFrom(boot, boot.ci)
importFrom(investr, predFit)
importFrom(MASS, mvrnorm)
importFrom(mgcv, gam)
importFrom(mgcv, gam.check)
importFrom(mgcv, predict.gam)
importFrom(pegas, haplotype)
importFrom(rootSolve, uniroot.all)
importFrom(rootSolve, multiroot)
importFrom(scam, scam)
importFrom(scam, scam.check)
importFrom(scam, predict.scam)
exportPattern("^[[:alpha:]]+")
The error is
The following packages are referenced using Rcpp::depends attributes \
however are not listed in the Depends, Imports or LinkingTo fields of\
the package DESCRIPTION file: RcppProgress
which seems plausible given what you now posted for DESCRIPTION and NAMESPACE.
So here is what I would do:
Create the package using the skeleton generator as you have. Extend as neeed as you have. Then ...
Run R CMD build mypackage then
Run R CME check mypackage_1.2.3.tar.gz
This should give you a clear idea as to whether your sources are in good shape. After that, you can create a binary or zip or ... which your colleague should be able to utilise.
Edit: And you should of course grep for RcppProgress upon which you may indeed have an undeclared dependency.
I'm writing an R package with the help of devtools.
I have a R function which uses Fortran subroutines (called with .Fortran() function) from a packagename.so file located in the src folder.
I put #useDynLib packagename in R/packagename.R and ran devtools::document() to add useDynLib(packagename) to NAMESPACE but when I run devtools::check() an error occures.
I read the R packages documentation and googled the question but I haven't found a solution yet.
Two related questions come to my mind:
do I need the Fortran source code and let R compile it?
should the shared object have the same name of the package or not?
TL;DR
How do I get rid of the following error after running devtools::check()?
Error: package or namespace load failed for ‘ROCkerMeth’ in library.dynam(lib, package, package.lib):
shared object ‘ROCkerMeth.so’ not found
I am using foreach() function in the foreach R package for parallel computing. Besides that function, I think it is also required to use registerDoMC() function in the doMC package.
However, when I write my DESCRIPTION file, the Imports section contains doMC (>= 1.3.0), foreach (>= 1.4.1), but when I run my code, an error indicates: cannot find the iter function. Thus, I also import the iterators package.
It seems that there is still error: the mclapply() function is to be used by foreach(), and this function appears in both the parallel and the multicore package. I include both packages in the Imports section, but when I run search(), the warnings show up:
Warning messages:
1: replacing previous import ‘mclapply’ when loading ‘parallel’
2: replacing previous import ‘mcparallel’ when loading ‘parallel’
3: replacing previous import ‘pvec’ when loading ‘parallel’
This is pretty weird: even though I explicitly imports both packages of iterators and multicore, I still cannot use their functions after loading my own package... Instead, I have to explicitly run:
library(iterators)
library(multicore)
in order to use my own function in my package which makes use of parallel computing. Is there anything wrong in my package writing? Thank you so much!
If you modify your DESCRIPTION file by adding doMC to the "Depends", then the "cannot find the iter function" error should go away, and functions from foreach, iterators and doMC will be available when your package is loaded, which seems to be your preference. The first chapter of Writing R Extensions discusses the differences between "Imports" and "Depends". Generally, it's preferable to use "Imports" to avoid forcing users of your package to load packages that are only needed within a package, but it has uses.
Actually, the "cannot find the iter function" error that you saw is caused by a bug in the doMC package, and using "Depends" rather than "Imports" works around this bug. Your package should only have to import packages that it directly uses, so if you don't explicitly call iter or mclapply, you shouldn't have to import iterators, parallel, or multicore. And since parallel has subsumed multicore, you should never import both parallel and multicore, which should avoid the warning messages that you saw.
I submitted a fix for the doMC bug to the package maintainer, so you should be able to import foreach and doMC into packages without an error in the next version of the package.