[Rd] Building R package: “Found 'rand', possibly from 'rand' (C)” NOTE when checking package
I am building a package that makes a simple visualization. A part of the code is in C++, and utilizes the functions srand() and rand() for purposes not related to statistics (introducing random noise in the visualization). The package compiles without problems on my workstation(s), but when I submitted it to the winbuilder service, I got the following weird message: * checking compiled code ... NOTE File 'tagcloud/libs/i386/tagcloud.dll': Found 'rand', possibly from 'rand' (C) Object: 'overlap.o' Found 'srand', possibly from 'srand' (C) Object: 'overlap.o' File 'tagcloud/libs/x64/tagcloud.dll': Found 'rand', possibly from 'rand' (C) Object: 'overlap.o' Found 'srand', possibly from 'srand' (C) Object: 'overlap.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. To the best of my knowledge, I don't see where in the code I "call entry points which might terminate R" or "write to stdout/stderr", but then, if I remove the calls to rand/srand, this message disappears. You can review the package here: http://win-builder.r-project.org/toy6frr57aCU/ Kind regards, January -- January Weiner -- __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Building R package: “Found 'rand', possibly from 'rand' (C)” NOTE when checking package
Dear Berend, thank you for your kind response. You are right, and I am blind. I will use the R RNG instead. Kind regards, j. On 2 November 2014 12:40, Berend Hasselman wrote: > > On 02-11-2014, at 12:20, January Weiner wrote: > >> I am building a package that makes a simple visualization. A part of >> the code is in C++, and utilizes the functions srand() and rand() for >> purposes not related to statistics (introducing random noise in the >> visualization). The package compiles without problems on my >> workstation(s), but when I submitted it to the winbuilder service, I >> got the following weird message: >> >> * checking compiled code ... NOTE >> File 'tagcloud/libs/i386/tagcloud.dll': >> Found 'rand', possibly from 'rand' (C) >>Object: 'overlap.o' >> Found 'srand', possibly from 'srand' (C) >>Object: 'overlap.o' >> File 'tagcloud/libs/x64/tagcloud.dll': >> Found 'rand', possibly from 'rand' (C) >>Object: 'overlap.o' >> Found 'srand', possibly from 'srand' (C) >>Object: 'overlap.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. >> >> To the best of my knowledge, I don't see where in the code I "call >> entry points which might terminate R" or "write to stdout/stderr", but >> then, if I remove the calls to rand/srand, this message disappears. >> > > Which version of R on your workstation? > Your code should also not call the C RNG (rand and srand) as the message > clearly states. > > Berend > >> You can review the package her:e >> http://win-builder.r-project.org/toy6frr57aCU/ >> >> Kind regards, >> >> January >> >> -- >> January Weiner -- >> >> __ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel > -- January Weiner -- __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Changing style for the Sweave vignettes
As a user, I am always annoyed beyond measure that Sweave vignettes precede the code by a command line prompt. It makes running examples by simple copying of the commands from the vignette to the console a pain. I know the idea is that it is clear what is the command, and what is the output, but I'd rather precede the output with some kind of marking. Is there any other solution possible / allowed in vignettes? I would much prefer to make my vignettes easier to use for people like me. Kind regards, j. -- January Weiner -- __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Changing style for the Sweave vignettes
Thank you, Søren and Brian for your answers. Whether this is the right list -- well, I think it is, since I am developing a package and would like to create a vignette which is useful and convenient for my users. I know how to extract the vignette code. However, most of my users don't. Or if they do, they do not bother, but copy the examples from the PDF while they are reading it. At least that is my observation. I'm sorry that my e-mail was unclear -- I started my e-mail with "as a user, ...", but I did mention that it is my vignettes that I am concerned with. options(prompt=...) is an idea, though I'm still not sure as to the second part of my question - whether a vignette without a command prompt is acceptable in a package or not. Kind regards, j. On 13 November 2014 12:36, Brian G. Peterson wrote: > On 11/13/2014 05:09 AM, January Weiner wrote: >> >> As a user, I am always annoyed beyond measure that Sweave vignettes >> precede the code by a command line prompt. It makes running examples >> by simple copying of the commands from the vignette to the console a >> pain. I know the idea is that it is clear what is the command, and >> what is the output, but I'd rather precede the output with some kind >> of marking. >> >> Is there any other solution possible / allowed in vignettes? I would >> much prefer to make my vignettes easier to use for people like me. > > > I agree with Søren that this is not the right list, but to complete the > thread... > > See the examples in > > ?vignette > > start just above > > ## Now let us have a closer look at the code > > All vignette's are compiled. You can trivially extract all the code used > for any vignette in R, including any code not displayed in the text and > hidden from the user, from within R, or saved out to an editor so you can > source it line by line from Rstudio (or vim or emacs or...). That's the > whole point. > > Regards, > > Brian > > -- > Brian G. Peterson > http://braverock.com/brian/ > Ph: 773-459-4973 > IM: bgpbraverock > > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- January Weiner -- __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Changing style for the Sweave vignettes
Dear Paul and Martin,
thanks for the useful tips. I'll start with Paul's suggestion (getting
rid of these '+'-es will already be a boon!), and move from my old
Sweave vignettes when possible.
Thank you!
j.
On 13 November 2014 15:35, Paul Gilbert wrote:
> You might also consider starting your vignettes with
>
> \begin{Scode}{echo=FALSE,results=hide}
> options(continue=" ")
> \end{Scode}
>
> Then you get one prompt but it is still easy to cut and paste. This has been
> in many of my packages for many years, so I think it would be fair to assume
> it is acceptable.
>
> Paul
>
>
> On 11/13/2014 06:56 AM, January Weiner wrote:
>>
>> Thank you, Søren and Brian for your answers.
>>
>> Whether this is the right list -- well, I think it is, since I am
>> developing a package and would like to create a vignette which is
>> useful and convenient for my users. I know how to extract the vignette
>> code. However, most of my users don't. Or if they do, they do not
>> bother, but copy the examples from the PDF while they are reading it.
>> At least that is my observation.
>>
>> I'm sorry that my e-mail was unclear -- I started my e-mail with "as a
>> user, ...", but I did mention that it is my vignettes that I am
>> concerned with.
>>
>> options(prompt=...) is an idea, though I'm still not sure as to the
>> second part of my question - whether a vignette without a command
>> prompt is acceptable in a package or not.
>>
>> Kind regards,
>>
>> j.
>>
>>
>> On 13 November 2014 12:36, Brian G. Peterson wrote:
>>>
>>> On 11/13/2014 05:09 AM, January Weiner wrote:
>>>>
>>>>
>>>> As a user, I am always annoyed beyond measure that Sweave vignettes
>>>> precede the code by a command line prompt. It makes running examples
>>>> by simple copying of the commands from the vignette to the console a
>>>> pain. I know the idea is that it is clear what is the command, and
>>>> what is the output, but I'd rather precede the output with some kind
>>>> of marking.
>>>>
>>>> Is there any other solution possible / allowed in vignettes? I would
>>>> much prefer to make my vignettes easier to use for people like me.
>>>
>>>
>>>
>>> I agree with Søren that this is not the right list, but to complete the
>>> thread...
>>>
>>> See the examples in
>>>
>>> ?vignette
>>>
>>> start just above
>>>
>>> ## Now let us have a closer look at the code
>>>
>>> All vignette's are compiled. You can trivially extract all the code used
>>> for any vignette in R, including any code not displayed in the text and
>>> hidden from the user, from within R, or saved out to an editor so you can
>>> source it line by line from Rstudio (or vim or emacs or...). That's the
>>> whole point.
>>>
>>> Regards,
>>>
>>> Brian
>>>
>>> --
>>> Brian G. Peterson
>>> http://braverock.com/brian/
>>> Ph: 773-459-4973
>>> IM: bgpbraverock
>>>
>>>
>>> __
>>> R-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>>
>>
>>
>
--
January Weiner --
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Creating a vignette which depends on a non-distributable file
Dear all, I am writing a vignette that requires a file which I am not allowed to distribute, but which the user can easily download manually. Moreover, it is not possible to download this file automatically from R: downloading requires a (free) registration that seems to work only through a browser. (I'm talking here about the MSigDB from the Broad Institute, http://www.broadinstitute.org/gsea/msigdb/index.jsp). In the vignette, I tell the user to download the file and then show how it can be parsed and used in R. Thus, I can compile the vignette only if this file is present in the vignettes/ directory of the package. However, it would then get included in the package -- which I am not allowed to do. What should I do? (1) finding an alternative to MSigDB is not a solution -- there simply is no alternative. (2) I could enter the code (and the results) in a verbatim environment instead of using Sweave. This has obvious drawbacks (for one thing, it would look incosistent). (3) I could build vignette outside of the package and put it into the inst/doc directory. This also has obvious drawbacks. (4) Leaving this example out defies the purpose of my package. I am tending towards solution (2). What do you think? Kind regards, j. -- January Weiner -- [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Creating a vignette which depends on a non-distributable file
Dear Martin, thank you for the food for thought. My package does not depend on MSigDB (it implements something better than MSigDB), but being able to work with MSigDB (for comparative purposes) is important. Also, Bioconductor makes sense only if you really want to take advantage of the Bioconductor structures / tools, which I don't. However, I find your suggestion with eval=FALSE and data subsets very good, I will implement it, using hidden sections to simulate the output, thanks! Kind regards, j. On 15 May 2015 at 01:50, Martin Morgan wrote: > On 05/14/2015 04:33 PM, Henrik Bengtsson wrote: > >> On May 14, 2015 15:04, "January Weiner" wrote: >> >>> >>> Dear all, >>> >>> I am writing a vignette that requires a file which I am not allowed to >>> distribute, but which the user can easily download manually. Moreover, it >>> is not possible to download this file automatically from R: downloading >>> requires a (free) registration that seems to work only through a browser. >>> (I'm talking here about the MSigDB from the Broad Institute, >>> http://www.broadinstitute.org/gsea/msigdb/index.jsp). >>> >>> In the vignette, I tell the user to download the file and then show how >>> it >>> can be parsed and used in R. Thus, I can compile the vignette only if >>> this >>> file is present in the vignettes/ directory of the package. However, it >>> would then get included in the package -- which I am not allowed to do. >>> >>> What should I do? >>> >>> (1) finding an alternative to MSigDB is not a solution -- there simply is >>> no alternative. >>> (2) I could enter the code (and the results) in a verbatim environment >>> instead of using Sweave. This has obvious drawbacks (for one thing, it >>> would look incosistent). >>> >> > use the chunk argument eval=FALSE instead of placing the code in a > verbatim argument. See ?RweaveLatex if you're compiling a PDF vignette from > Rnw or the knitr documentation for (much nicer for users of your vignette, > in my opinion) Rmd vignettes processed to HTML. > > A common pattern is to process chunks 1, 2, 3, 4, and then there is a > 'leap of faith' in chunk 5 (with eval=FALSE) and a second chunk (maybe with > echo=FALSE, eval=TRUE) that reads the _result_ that would have been > produced by chunk 5 from a serialized instance into the R session for > processing in chunks 6, 7, 8... > > Also very often while it might make sense to analyse an entire data set as > part of a typical work flow, for illustrative purposes a much smaller > subset or simulated data might be relevant; again a strategy would be to > illustrate the problematic steps with simulated data, and then resume the > narrative with the analyzed full data. > > A secondary consideration may be that if your package _requires_ MSigDB to > function, then it can't be automatically tested by repository build > machines -- you'll want to have unit tests or other approaches to ensure > that 'bit rot' does not set in without you being aware of it. > > If this is a Bioconductor package, then it's appropriate to ask on the > Bioconductor devel mailing list. > > http://bioconductor.org/developers/ > > http://bioconductor.org/packages/BiocStyle/ might be your friend for > producing stylish vignettes. > > Martin > > > (3) I could build vignette outside of the package and put it into the >>> inst/doc directory. This also has obvious drawbacks. >>> (4) Leaving this example out defies the purpose of my package. >>> >>> I am tending towards solution (2). What do you think? >>> >> >> Not clear how big of a static piece you're taking about, but maybe you >> could set it up such that you use (2) as a fallback, i.e. have the >> vignette >> include a static/pre-generated piece (which is clearly marked as such) >> only >> if the external dependency is not available. >> >> Just a thought >> >> Henrik >> >> >>> Kind regards, >>> >>> j. >>> >>> >>> >>> -- >>> January Weiner -- >>> >>> [[alternative HTML version deleted]] >>> >>> __ >>> R-devel@r-project.org mailing list >>> https://stat.ethz.ch/mailman/listinfo/r-devel >>> >> >> [[alternative HTML version deleted]] >> >> __ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> >> > > -- > Computational Biology / Fred Hutchinson Cancer Research Center > 1100 Fairview Ave. N. > PO Box 19024 Seattle, WA 98109 > > Location: Arnold Building M1 B861 > Phone: (206) 667-2793 > -- January Weiner -- [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
