gth one.
#' @name CACHE
#' @docType data
NULL
Hadley
On Tue, Aug 25, 2015 at 7:56 AM, Rainer M Krug wrote:
> Hadley Wickham writes:
>
>> You possibly don't have LazyData: true in your DESCRIPTION.
>
> Thank - I had
>
> LazyData: yes
>
> and now I have
>
You possibly don't have LazyData: true in your DESCRIPTION.
Hadley
On Tue, Aug 25, 2015 at 4:43 AM, Rainer M Krug wrote:
> Hi
>
> I am trying to document data which is defined in a file named
> ./data/fileNames.R which looks as follow:
>
> --8<---cut here---start--
gt; Roxygen field in DESCRIPTION. To configure this explicitly, add the
> following line to the DESCRIPTION file: `Roxygen: list(wrap = FALSE)`
>
>
> On Wednesday, March 19, 2014 4:55:25 PM UTC, Hadley Wickham wrote:
>>
>> On Wed, Mar 19, 2014 at 11:53 AM, Timothy Bates
>
On Wed, Mar 19, 2014 at 11:53 AM, Timothy Bates
wrote:
> I'm getting an error running document() which is
>
>> devtools::document()
> Updating umx.twin documentation
> Loading umx.twin
> Using the default option wrap = FALSE since it was not specified in the
> Roxygen field in DESCRIPTION
> Error:
On Thu, Mar 13, 2014 at 12:02 PM, Timothy Bates
wrote:
> If I cd into the directory of a package under devtools control, then this
> result obtains
>
>> roxygen2::upgradeRoxygen()
> Error in file(con, "w") : cannot open the connection
> In addition: Warning message:
> In file(con, "w") : cannot op
It's looking for a DESCRIPTION file in your working directory. Any
chance you're running it from a different place?
Hadley
On Thu, Mar 13, 2014 at 10:39 AM, Timothy Bates
wrote:
> FYI, I installed, and ran the upgrade function, but got this error:
>
> devtools::install_github("klutometis/roxygen
Hi all,
I'm planning to push roxygen2 4.0.0 to CRAN in the next week or so.
There are three main new features:
* all outputs are flagged with a comment that indicates that roxygen2
produced them, and roxygen2 will not overwrite a file it didn't
create. (This is the reason it's a major version bu
> Roxygen2 4.0.0 is a major update to roxygen2 that makes provides
> enhanced error handling and considerably safer default behaviour. Now,
> roxygen2 will never overwrite a file that it did not create. This
> means that before you run it for the first time, you'll need to all
> files generated by
Hi all,
I'll getting ready to release a new version of roxygen2 in the next
couple of weeks. It contains vastly improved error handling and two
useful new tags. If you use roxygen2, I'd appreciate your feedback.
Try the dev version out by running
devtools::install_github("klutometis/roxygen"). Com
Hi all,
The code below implements a proposal for adding support for reference
class methods to ?. If you think it looks reasonable, I'll forward on
to Duncan Murdoch for further review, and hopefully inclusion in base
R. The logic is rather complicated because of the many possible
inputs, but ba
> If I just do:
>
> #' @rdname c-codeDefinition
> setMethod("c", signature("codeDefinition"), function(x, ...)
> new("ListOfcodeDefinition", list(x, ...)))
>
> Then check complains about missing \name and \title for the method.
I meant @rdname class-codeDefinition - but you'll need to chec
> Um, I'm still unclear on what information I do need to properly document the
> S4 methods. Without adding any roxygen documentation, check is unhappy,
> e.g.
>
> Undocumented S4 methods:
> generic 'c' and siglist 'codeDefinition'
>
> What should I be doing here?
Adding some documentat
e
> that ideally some of this could be generated programmatically from the
> method definition instead?
>
>
> Thanks for any hints or suggestions.
>
> Cheers,
>
> Carl
>
>
> On Fri, Nov 15, 2013 at 5:57 AM, Hadley Wickham wrote:
>>
>> Hi all,
>>
&
Hi all,
This is just a quick note to let you know that I'm moving towards a
new release of roxygen2, bringing in the most important new features
and bug fixes from roxygen3. The most important new features are:
* S4 support (generics, methods and classes), generating correct
aliases and usage sta
> > The big advantage (in the current situation), is that it's much easier
> > to have both versions installed simultaneously.
>
> Yes, but you can name old-version as roxygen-old and whoever wants to
> use the old version can used that. This is uniformly better than giving
> new names to the pac
>> > But is there a variable which specifu which roxygen (roxygen,
>> roxygen2,
>> > roxygen3) will be used for previewing, so that the preview and the
>> final
>> > result are consistent?
>>
>> Ok, that is a good question. This roxygenN naming does complicate the
>> stuff a bit. I have to lo
> I want to include some preformated text (ASCII art) in a function
> documentation using roxygen2. I found the #'' tag, but it does not seem
> to be working - is it included in roxygen2? Or are there any other
> approaches to include preformatted text in function documentations using
> roxygen2?
Hi Joh,
roxygen3 will eventually get merged back in to roxygen2 - I definitely
plan to continue maintaining it, but other projects have priority at
the moment.
If you're having problems with roxygen3, it's probably namespace
related - if you ping me and remind me, I can try and make a few
minutes
> In case the documented thing is a data set ...
> etc.
>
> Wouldn't that make sense?
>
> Joh
>
> On Thursday, January 03, 2013 17:30:23 Hadley Wickham wrote:
>> Hi Johannes,
>>
>> I'm not sure what the purpose would be do - do you want some autom
Hi Johannes,
I'm not sure what the purpose would be do - do you want some automated
way of ensuring that you've provided a predefined set of tags?
Hadley
On Sat, Dec 29, 2012 at 11:40 PM, Johannes Graumann
wrote:
> Hello,
>
> Is there a ROxygen-integral mechanism for doc-type specific templatin
Hi Johannes,
It's probably because I haven't written the correct NAMESPACE file :(
You might be able to work around it by cloning the repo and using
devtools::load_all to load it - that's my development process so it
should work.
Hadley
On Mon, Nov 12, 2012 at 11:54 AM, Johannes Graumann
wrote:
> Is there any chance Roxygen3 could support a bit of markdown syntax?
Yes, that's definitely on the to do list - but I'm waiting on support
from the RMarkdown package.
Hadley
--
RStudio / Rice University
http://had.co.nz/
___
Roxygen-devel mailing li
Hi all,
Roxygen3 (which will eventually get merged back into roxygen2) is at a
state where your comments on the design and implementation would be
appreciated. The code is at https://github.com/hadley/roxygen3/, and
there's a brief introduction to the structure in the readme.
The code is fairly c
> I'd personally prefer that if there is such functionality, it is disabled by
> default, since we tend to like to hide new(). Since overriding initialize is
> problematic, using new() would expose the slots, which are normally
> considered implementation details. Others may differ.
Ah ok, so slot
Or should that just come from documenting the constructor and class in
the same file?
Hadley
On Wed, Sep 12, 2012 at 7:44 PM, Hadley Wickham wrote:
> Hi all,
>
> Do you think it makes sense to add usage statement to S4 classes? i.e.
>
> new("MyClass", a, b, c, d = 1)
Hi all,
Do you think it makes sense to add usage statement to S4 classes? i.e.
new("MyClass", a, b, c, d = 1)
where a, b, c, d are taken from the representation and prototype.
Hadley
--
RStudio / Rice University
http://had.co.nz/
___
Roxygen-devel m
> Reference classes basically are S4 classes, so it would be nice to the same
> basic features for both.
I think that should just work. I have:
setClass("R5ClassObject", contains = "S4ClassObject")
so reference classes will inherit all S4 class behaviour by default.
> Reference classes of cour
>> * a picture showing the class graph to the class documentation
>> * a list of "nearby" methods to method documentation
>
> I miss the old CallGraph functionality from the original roxygen, so I'd
> like to hope that any graphing capability would include this , and support
Do you have any partic
Hi all,
After a survey of packages that use S4 and talking to a few people who
use S4 a lot, here are my thoughts on how method documentation would
work.
Methods need to be documented in three places:
* individually, for complex methods
* in the class (briefly)
* in the generic (briefly)
This d
Hi all,
I'm starting to think more about S4 documentation, and wondered what
people thought about automatically adding:
* a list of all subclasses and superclasses to class documentation
* a picture showing the class graph to the class documentation
* a list of all methods to the generic document
> There's no way we could develop this as a branch in the preëxisting
> Roxygen repo, is there?
Yes, probably. I'm becoming more certain that this won't break any
existing roxygen code, so I'll move back over in the not too distant
future.
Hadley
--
RStudio / Rice University
http://had.co.nz/
> May be the best thing is that you give it a try, and build the first
> version of the package according to your vision. Then if I still think
> that my approach is more parsimonious I will give a rewrite. Afterward
> we can talk in more concrete terms.
I think that's a really good idea :) Thank
On Thu, Aug 30, 2012 at 2:12 PM, Vitalie Spinu wrote:
> >> Hadley Wickham
> >> on Thu, 30 Aug 2012 11:29:07 -0500 wrote:
>
>
> >> So roxygenize will iterate 3 times over all tags and call prepareTag on
> >> first iteration, then prepareDoc,
> How about this. You can have 3 levels on which a tag can perform an
> aciton -- a local tag level, on the object documentation (block) level
> and on a package level. For each of this actions you have a generic
> dispatched on *tag* object:
>
> setGeneric("prepareTag", function(tag) standardGene
> * Similarly, I still don't see how tags that operate globally would
> work. I think that's partly because the model is so focussed on the
> individual tag - the tag classes become very heavy - that's where all
> the logic is stored. That's not such a good fit for actions that work
> on multiple
> I have done my best here https://gist.github.com/3516476
Thanks - that's useful. A few comments/questions:
* I don't think the spec for processTag is quite right yet - currently
you have it returning a transformed object of the same class as the
input - but that only works for a limited number
On Wed, Aug 29, 2012 at 12:00 PM, Vitalie Spinu wrote:
> >> Hadley Wickham
> >> on Wed, 29 Aug 2012 09:07:41 -0500 wrote:
>
> > Hi Vitalie,
> > It would also be really useful if you could sketch out the S4 design
> > to work with a tag like
> Indeed, this is a slight complication which is solved (is it?) by
> stacking the evaluation environments. That is, each new code chunk is
> evaluated in an environment whose parent is the environment from the
> previous evaluation.
Yes, I think that would work (although I'm not sure what will h
Hi Vitalie,
It would also be really useful if you could sketch out the S4 design
to work with a tag like usage.
Would you need multiple dispatch so that usage looks like:
setMethod("ProcessTag", signature(tag = "RoccerUsage", object =
"function"), ...)
setMethod("ProcessTag", signature(tag = "Ro
> > One option would be to evaluate each source block as you encounter it.
> > That would resolve the problem above (and would make it possible to do
> > `my_class <- setClass` and still know that it was creating a class).
> > The problem is that the S4 functions don't seem to be very good
> It looks like you want a simple interface, but it ends up being a cross
> between S3 and internal roxygen object (i.e. tag) keeping system. Sort
> of _roxyClasses_ approach, and it looks like you haven't yet get to the
> inheritance and extension mechanism.
Hmmm, point taken.
> (Actually, I thi
Below I've attempted to outline the basic object structure of
roxygen3. I would really appreciate any feedback. There's a prettier
version at https://gist.github.com/3512194. Thanks!
Hadley
[Important terminology: __roc__ is short for roxygen comment block,
__rocblock__ and for combination of
[splitting out into separate emails instead of one huge one]
> Not that difficult, S4 always leave traces in the evaluation
> environment, objects starting with:
>
> methods:::.TableMetaPattern()
> [1] "^[.]__T__"
> methods:::.ClassMetaPattern()
> [1] "^[.]__C__"
>
> Inspecting those, you
> HW> I've also been wondering about splitting "roxygen3" into two packages
> HW> - one that defines all the basic objects etc and one that creates all
> HW> the tags.
>
> An add-on package would have to load both right? So what is the
> advantage of the split then?
* When you look at the do
ild alternative documentation systems. One priority for roxygen3 is
that it should be much easier to extend, so that if I don't want to
include something, it's still easy for you to put it in an add-on
package.
Hadley
On Tue, Aug 28, 2012 at 11:46 AM, Hadley Wickham wrote:
>> Is it o
> Is it object oriented this time? From what I can follow from the HEAD,
> it comes pretty close, but it is not S4 driven.
Yes, it's more object-oriented, but with S3, not S4.
> May be I am missing the point here, but it looks to me that doc/tag
> parsers should be generics. A package might want
> May be it's time to revert to "roxygen" name?
Roxygen3 may well revert to roxygen2, but I don't currently want to
tie myself to non-breaking changes. (e.g. I'm considering allow
markdown syntax in roxygen comments)
> Roxygen is not required by any other package; so no dependence
> problems. Al
parser or R>2.16 if we use Duncan's
> version that made it into the core-R. But we have all the machinery to
> extract the information. Perhaps if we could form a standard for organizing
> the information so that the roccers could handle it.
>
> -Andrew
>
>
>
>
2012 at 10:13 AM, Andrew Redd wrote:
> Hadley,
> Great news. Will we be able to do the Doxygen style commenting of function
> parameters that I have discussed with you earlier? Will that be possible or
> should I still pursue doing that within lint?
>
> Thanks,
> Andrew Red
> Could you *please* talk to some actual computer scientists and at least
> consider calling it roxygen version 3.0 or roxygen2 version 3.0 instead of
> releasing a new package name every time you feel the need to refactor the
> code? It is commonly understood that major version numbers may break
Hi all,
I thought I should mention I've started working on roxygen3 at
https://github.com/hadley/roxygen3. It's a ground up rewrite of
roxygen2, aiming to produce the same results as roxygen3, but without
a completely different backend. Currently the roxygen2 code is hard
to extend - the idea of
Could you please file a bug report?
Thanks,
Hadley
On Sun, Mar 25, 2012 at 1:24 PM, meik michalke
wrote:
> hi,
>
> shouldn't docs for generics also have a usage section? mine somehow don't.
>
> roxygenizing this file:
>
>
> #' Test method
> #'
> #' Just a test. Where's the usage section?
> #'
>
On Mon, Feb 20, 2012 at 10:06 PM, Steve Lianoglou
wrote:
> Hadley,
>
> Sorry for pestering, but what's the right way to comment a setGeneric
> and its derivatives, eg:
>
> ##' Make your object think
> ##'
> ##' We are building self aware objects
> ##'
> ##' @export
> ##'
> ##' @param x The object
>> Are the hints found here still the right way to go, more or less?:
>>
>> http://stackoverflow.com/questions/4396768/how-to-properly-document-s4-and-methods-using-roxygen
>
> Yes, that's ok, but you shouldn't need to manually set the rdname
> (it's a bug if you do), and @slot isn't supported yet.
> Is there an update "gold reference" for how we'd document S4 classes
> (setClass) and method definitions? (setGeneric vs. setMethod)?
>
> Are the hints found here still the right way to go, more or less?:
>
> http://stackoverflow.com/questions/4396768/how-to-properly-document-s4-and-methods-using
>> Basically, I don't want to add code that I know doesn't work -
>> obviously, I'd prefer not to already have code that doesn't work, but
>> I want to make it better, not worse.
>
> i agree. we just seem to have different views on what would be an improvement.
> i'll leave it to this and switch ba
> in theory, i see the problem. allthough i'd suggest to break lines after
> commas only, so the only problematic case would be a comma followed by space
> inside a quote:
>
> c(" ", ' ', "', '", "\" \"", "\\ ")
>
> but still, even if we ignored this for the time being, i fail to see the
> benefit
Hi all,
I've been working on a minimal set of changes to roxygen2 to get it
working with S4 classes. I have code that works but it needs broader
testing, so if you're using roxygen with S4 I'd really appreciate your
feedback. You can see the code at
https://github.com/klutometis/roxygen/tree/s4, o
2012/2/9 meik michalke :
> hi hadley,
>
> Am Donnerstag, 9. Februar 2012 05:03:28 schrieb Hadley Wickham:
>> > the first is regarding the automatically generated usage section. this
>> > usally works great, except when an option is very long. some automatic
>
> the first is regarding the automatically generated usage section. this usally
> works great, except when an option is very long. some automatic line breaks
> and additional indentation would be great here. see this generated doc, page
> 70, on the function "readability":
> o http://r.reaktanz.de
Hi all,
I've made the first steps towards proper S4 in a new S4 branch:
https://github.com/klutometis/roxygen/tree/s4
Please try it out and let me know what works and doesn't work. At a
minimum, it should be generating correct aliases and usage statements.
Hadley
--
Assistant Professor / Dobe
Hi Paul,
You should just export the method, i.e.:
#' @S3method summary mcreg
and don't document use any other roxygen tags, unless you want to
fully document the method (which is not usually necessary)
Exporting the method means that summary(mymcregobject) will work, but
summary.mcreg(mymcrego
On Mon, Nov 14, 2011 at 11:57 AM, Michael Lawrence
wrote:
>
>
> On Mon, Nov 14, 2011 at 9:21 AM, Hadley Wickham wrote:
>>
>> > In roxygen (v1) existing Rd files in the Rd directory are merged with
>> > the documentation generated by roxygen based
> Yes that's true. BTW: that reminds me that it would be nice to
> have an indicater in Rd files which says that this Rd file is
> generated by roxygen (maybe a comment). Would make a "make clean"
> easier.
https://github.com/klutometis/roxygen/issues/69
Hadley
--
Assistant Professor / Dobelma
> To add on to this a little bit, there needs to be convenient support for
> generating NAMESPACE imports.
>
> If a class is included in a method signature, or is passed in "contains" to
> setClass(), and it is not defined within the package, Roxygen should search
> the dependent packages for a cla
> After fiddling around a little is seems like Romains parser package
> does all that you need to be able to extract the comments and the
> blocks that they belong to. It even differentiates roxygen comments
> from others. here is an example:
Capturing the comments isn't the hard part - it's ass
>>> Some of my packages use S4 but for the most part I've moved onto R5
>>> reference classes that interface Rcpp and java classes. Does anyone
>>> have any good examples of documenting an R5 class?
>>
>> I don't. Have you read ?referenceClasses for John Chambers suggested
>> form of documentatio
;
>
> On Sat, Dec 24, 2011 at 5:17 AM, Hadley Wickham wrote:
>>
>> Have you tried something like
>>
>> # \dontrun{
>> R code here
>> # }
>>
>> ?
>>
>> Hadley
>>
>> On Sat, Dec 24, 2011 at 12:48 AM, Jeroen Ooms
>>
Have you tried something like
# \dontrun{
R code here
# }
?
Hadley
On Sat, Dec 24, 2011 at 12:48 AM, Jeroen Ooms wrote:
> I know I can use \dontrun inside of an @examples block, but is there also a
> way to use it inside an @example /path/to/example.R?
>
>
>
> _
> I saw the discussion on the archive about S4 documentation. My
> opinion is that methods should at the very least be included in the
> class documentation, but as far as including the documentation in the
> generic, I'm not quite sure I see how that is to be accomplished.
> Many of the generics
> In roxygen (v1) existing Rd files in the Rd directory are merged with
> the documentation generated by roxygen based on the file name and
> @rdname.
>
> Maybe we can implement something similar in roxygen2? Would that help?
I really don't like mixing generated and hand-written files in the
same
>> There may be a use-case for @including Roxygen comments, but I think my
>> use-case would benefit more from pure Rd that would just be concatenated
>> into the resulting Rd file. These would be things like extra \section{}s.
>> Maybe make that more explicit with a @section that refers to a file?
> Although in many cases one could create such class-based methods
> with simple functions, if someone wants to override one in a subclass, they
> will need to create a method (which would create an implicit generic,
> defaulting to the original function). Usually though, that implicit generic
> is
# Roxygen2
The premise of `roxygen2` is simple: describe your functions in
comments next to where their definitions and `roxygen2` will process
your source code and comments to produce R compatible Rd files.
Here's a simple example from the `stringr` package:
#' The length of a string (in char
> For the most part, packages that I've written (and am currently writing) have
> complex classes that store and process a large amount of data. There are
> usually many generics with only a single method each. The xcms package has
> several such classes:
>
> http://www.bioconductor.org/packages
Hi all,
I've been spending some time thinking about how to document S4
methods, and I've included my current thoughts so far. I'd really
appreciate your feedback, so we can get roxygen2 working well with S4.
# Methods
Two types of generics:
* Large number of simple methods such as in the Matri
Awesome - thanks Jeroen!
Hadley
On Fri, Oct 28, 2011 at 2:41 PM, Jeroen Ooms wrote:
> We had a useR meetup at UCLA this week about R package development and
> productivity tools, in which we did a brief intro/demo of StatET, roxygen,
> Sweave, devtools, testthat, etc.
> A video recording is avail
Hi all,
Starting to look into improving roxygen2's S4 support. Does any one
have a good set of test cases? (e.g. simple package that uses S4 and
has good documentation). I'm also interested in full list of
outstanding issues so that I can squash them all at once.
Hadley
--
Assistant Profess
> Thanks - works perfectly.
>
> Is there a list of all tags available?
They should be listed in the documentation for the applicable roclet,
but useDynLib seems to be missing. Would you mind filing a bug report
at https://github.com/klutometis/roxygen/issues ?
Thanks,
Hadley
--
Assistant Pro
Hi Rainer,
It's @useDynLib ;)
Hadley
On Wed, Sep 28, 2011 at 6:15 AM, Rainer M Krug wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi
>
> I have a package which needs a useDynLib() in the NAMESPACE file.
> I am using roxygenize as follow:
>
> Rscript -e "library(roxygen2);roxygeni
> If one puts roxygen documentation before a statement setClassUnion one gets
> the error of Missing name at the line of setClassUnion.
> I think it is because this statement is not known to roxygen2 parser.
> Adding the following to roclet-rd.R makes it aware it, but I am not sure if
> the name 'S
> Renaud
>
> On 21/09/2011 21:38, Hadley Wickham wrote:
>>>
>>> in one of the R files I have something like this, that defines a
>>> temporary
>>> function in order to define a static variable:
>>>
>>> f<- function(){
>>> .a&l
stood the question.
>
> Rd2roxygen seems to completely fail to parse \section tags in the
> existing Rd files. There's no error, but no section data is converted
> either.
>
> Regards,
>
> - Brian
>
>
>
> On Wed, 2011-09-21 at 14:39 -0500, Hadley Wickham wrote:
Hi Daniel,
Would you mind filing a bug at https://github.com/klutometis/roxygen?
That way it will get fixed when we start preparing for the next
version of roxygen.
Hadley
2011/9/8 Daniel Sabanés Bové :
> Hi,
>
> I have switched to roxygen2, which is a lot faster than roxygen it
> seems. Thanks
What format are you using for the section tag? In plyr, I have:
#' @section Output:
#' The most unambiguous behaviour is achieved when \code{.fun} returns a
#' data frame - in that case pieces will be combined with
#' \code{\link{rbind.fill}}. If \code{.fun} returns an atomic vector of
#'
> in one of the R files I have something like this, that defines a temporary
> function in order to define a static variable:
>
> f <- function(){
> .a <- 0
> function(x=1){
> .a <<- .a + x
> .a
> }
> }
> f2 <- f()
> rm(f)
>
> When running roxygenise on this I get the error:
On Wed, Sep 21, 2011 at 7:16 AM, Renaud Gaujoux
wrote:
> Hi,
>
> Suppose a package directory that contains R files that are not in the
> Collate field in the DESCRIPTION.
> Running:
> roxygenise('.', roclets='rd')
>
> will parse all the R files, even those that are not in Collate.
> I explicitly u
Hi Martin,
Roxygen development has transition to github
(https://github.com/klutometis/roxygen) and to a new name (roxygen2),
because we made some api/format breaking changes. If you let me know
what the bug was I can make sure it's also fixed in the new version.
Hadley
2011/4/26 Martin Maechle
On Wed, Sep 21, 2011 at 11:10 AM, Renaud Gaujoux wrote:
> It was very straightforward indeed.
> Patching line 324 of roclet-rd.R with the following seems to do the trick:
>
> if (is.null(name)){
> # get the location and filename from srcref
> ll <- partitum$srcref$lloc
> stop("Missing nam
> I know it is my third post today... I would really like to migrate my
> package (at least partially) to roxygen2 documentations, but I keep getting
> into troubles (...).
> I now get the following error message:
>
> Error in roclet_rd_one(partitum, base_path) : Missing name
>
> It seems that any
Would you mind adding this to
https://github.com/klutometis/roxygen/issues/24? That way it won't
get lost in my inbox.
Hadley
On Thu, Sep 1, 2011 at 12:39 PM, meik michalke
wrote:
> hi,
>
> as R CMD check revealed to me, the values of \alias{} must not be quoted.
> otherwise you run into warning
Fixed in
https://github.com/klutometis/roxygen/commit/4ccbb3e21bf17f561ad5ba0aee337fe3b559a279.
Thanks!
Hadley
On Mon, Aug 29, 2011 at 5:11 PM, meik michalke
wrote:
> hi,
>
> am Montag 29 August 2011 (15:44) schrieb Hadley Wickham:
>> Ok, doesn't look like I'll have a
>> i get this in the created NAMESPACE file:
>>
>> exportClasses(XiMpLe.doc)
>> exportClasses(XiMpLe.node)
>> exportMethods(node<-)
>> exportMethods(node)
>> export(parseXMLTree)
>> export(pasteXMLTag)
>> export(rk.write.about)
>
> Thanks for the reproducible example - the critical detail se
Not currently, but it would be pretty easy to hook the two up.
Hadley
On Mon, Aug 22, 2011 at 10:06 PM, Jeroen Ooms wrote:
> Suppose I have a single R file myfunction.R that contains a single R
> function with appropriate roxygen comments. Is it possible to:
> ( 1) Convert this to an Rd using rox
>> As far as I can tell that's what roxygen produces for me already - I
>> just added a test to verify it. Are you sure you have the latest
>> version (2.1) ?
>
> positive:
>
> > packageVersion("roxygen2")
> [1] ‘2.1’
>
> however, when i roxygenize this small package
> o http://R.reaktanz.de/sr
> when i define a function/method named like "functionName<-", it causes an
> error at installation time if the NAMESPACE file was created by roxygen2. the
> reason is simply the assignment operator "<-" in the name, which is needed for
> functionality like
>
> functionName(object) <- "new value"
> - The tags that one should be to automatically generate are:
> @aliases, @usage, and even the @param for the arguments from the signature
> if no better description is provided by the user in the embedded doc for a
> given method. In such case an sub-itemized list for the argument could be
> crea
> By the way is there a reason why the aliases are not generated
> automatically, since one knows exactly which doc to put in which file, as
> well as the type and signatures of the documented object.
> For example, when documenting a S4 generic, the aliases to the different
> methods could be put
> judging by the time stamps, which won't be updated after a first round,
> roxygenize() seems to try to write those files at least a second time after
> they have already been copied (i mean within one call). which perhaps fails
> because of some "overwrite=FALSE" or so. but apart from that, it wo
>> I was not roxigenising in place because I had some manually made Rd
>> files in the man directory, and didn't want to overwrite them.
>
> I can second this rationale.
So then you manually copy across the new files into the existing
directory? Sounds painful!
> The addition of the @rdfile tag
1 - 100 of 111 matches
Mail list logo
