Re: [Rd] suggestion for "sets" tools upgrade
On Thu, Feb 6, 2014 at 8:31 PM, Carl Witthoft wrote:
> First, let me apologize in advance if this is the wrong place to submit a
> suggestion for a change to functions in the base-R package. It never really
> occurred to me that I'd have an idea worthy of such a change.
>
> My idea is to provide an upgrade to all the "sets" tools (intersect, union,
> setdiff, setequal) that allows the user to apply them in a strictly
> algebraic style.
>
> The current tools, as well documented, remove duplicate values in the input
> vectors. This can be helpful in stats work, but is inconsistent with the
> mathematical concept of sets and set measure.
No comments about back-compatability concerns, etc. but why do you
think this is closer to the "mathematical concept of sets"? As I
learned them, sets have no repeats (or order) and other languages with
set primitives tend to agree:
python> {1,1,2,3} == {1,2,3}
True
I believe C++ calls what you're looking for a multiset (albeit with a
guarantee or orderedness).
Cheers,
Michael
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] user defined macros in Rd files
On Oct 9, 2013, at 21:18, Duncan Murdoch wrote: > On 13-10-09 7:54 PM, Henrik Bengtsson wrote: >> >> >> On my related wishlist: A standardized mechanism to 'R CMD build' for >> building man/*.Rd from any input format (e.g. roxygen and so on) >> analogously how we can now build vignettes of any input format. With >> that in place, it would a be piece of cake to include macros from >> external files. >> >> Just wanted to throw it out there. > > No, we certainly won't do that. We rely on being able to process the Rd > files in multiple ways. > I'm a but confused here Duncan: Henrik's proposal still results in the Rd files being created and then all of the cool things which get done (example checking, HTML, PDF, etc.) can carry on as usual. Since those are all done from the tarball by R CMD build, they can't know how the Rd files were created in the first place. Can you say a bit more about what would break? I'm afraid I'm missing something obvious. Michael > Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R CMD check fails in R-devel r63910
On Sep 13, 2013, at 7:44, alku wrote:
> Hi,
>
> The R CMD check is successful in R 3.0.1 but fails to install package
> lmerTest under R-devel r63910,
> Here is what I get:
>
> ** preparing package for lazy loading
> Error in reconcilePropertiesAndPrototype(name, slots, prototype,
> superClasses, :
> no definition was found for superclass "merMod" in the specification of
> class "merModLmerTest"
The line you point out below isn't relevant to this error: it's saying it can't
find a definition of merMod and that it knows you meant to define one since
it's part of merModLmerTest.
>
> In DESCRIPTION file I have:
> Depends: Matrix, stats, methods, lme4
> Imports: numDeriv, MASS, Hmisc, gplots, pbkrtest
>
> I have classes.R file where I specify that "merModLmerTest" class should
> inherit "merMod":
>
> merModLmerTest <- setClass("merModLmerTest", contains = "merMod")
Which would be trouble if you don't define "merMod" elsewhere.
M
>
> But it seems like in R devel r63910 this line cannot be seen...
>
> This error I have seen for a few days
>
> Alexandra
>
>
>
> --
> View this message in context:
> http://r.789695.n4.nabble.com/R-CMD-check-fails-in-R-devel-r63910-tp4676046.html
> Sent from the R devel mailing list archive at Nabble.com.
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Accessing the formals() of a non-exported method without :::?
On Aug 23, 2013, at 11:15, Gavin Simpson wrote: > Dear List, > > I'm in the process of making tweaks to my various R packages following > changes in r-devel for package checks. I'm wondering about the one use > of ::: in one of my packages. I am arranging for a call to a > non-exported S3 method via do.call. For this I need the arguments of > the function and hence I was doing > >Args <- head(formals(analogue:::wa.default), -1) > > Following the recent thread on legitimate uses of ::: I think the > above is both acceptable and won't generate a Note now with R CMD > check following a recent change to that code. But is there a better > way to get the formal arguments of a non-exported S3 method? > Something like (untested) formalsS3 <- function(...) formals(getS3method(...)) might work. I haven't checked to see how R CMD check feels about getS3method() though. Michael > Thanks. > > G > > -- > Gavin Simpson > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Confusion about Depends:, Imports:, Enhances:, import(), inportFrom()
On Aug 22, 2013, at 15:33, Henrik Bengtsson wrote: > On Thu, Aug 22, 2013 at 10:05 AM, R. Michael Weylandt > wrote: >> >> >> On Aug 22, 2013, at 9:09, Michael Friendly wrote: >> >>> In checking my vcdExtra package, the following NOTE newly appeared >>> (R-Forge, using R version 3.0.1 Patched (2013-08-20 r63635)) >>> >>> Package in Depends field not imported from: ‘gnm’ >>> These packages needs to imported from for the case when >>> this namespace is loaded but not attached. >>> >>> In the DESCRIPTION file, I have >>> >>> Depends: R (>= 2.10), vcd, gnm (>= 1.0.3) >>> >>> In NAMESPACE: >>> >>> # we are a vcd extension >>> import(vcd) >>> >>> I've read 1.1.1 of R-Exts, but it is not clear to me whether I should also >>> import gnm or change >>> the DESCRIPTION file to use >>> >>> Imports: vcd, gnm (>= 1.0.3) >>> >>> R-Exts says: The ‘Imports’ field lists packages whose namespaces are >>> imported from (as specified in the >>> NAMESPACE file) but which do not need to be attached, but how can I tell if >>> gnm needs to be attached? >> >> I think the current best practice is to use Imports unless gnm provides >> functions the end user needs in order to use your package. >> >> Practically, I think this usually comes down to asking whether gnm provides >> relevant generics -- if you provide methods only, the end user would only be >> able to call them directly (ick!) unless gnm is both loaded and attached >> (Depends) >> >> If gnm is tools for your code, but not the user to call directly, Imports is >> cleaner. >> >> Does that help? >> >> Michael >> >>> >>> Also, what is the difference between Imports: in DESCRIPTION and imports() >>> in NAMESPACE? >> >> One enables the other: Imports in DESCRIPTION allows for both imports() and >> importsFrom(). It could probably be automatic, but the DESC file is much >> older than the NAMESPACE file. > > I pretty sure you can also use import()/importFrom() in NAMESPACE for > packages listed under Depends in DESCRIPTION. > Agreed, but you couldn't auto-generate Depends from the namespace file. I suppose if (per my above) Depends was only used for generics... Not sure if the devtools world does anything like this, though it seems logical enough. Michael > /Henrik > >> >> >>> -Michael >>> >>> -- >>> Michael Friendly Email: friendly AT yorku DOT ca >>> Professor, Psychology Dept. & Chair, Quantitative Methods >>> York University Voice: 416 736-2100 x66249 Fax: 416 736-5814 >>> 4700 Keele StreetWeb: http://www.datavis.ca >>> Toronto, ONT M3J 1P3 CANADA >>> >>> __ >>> R-devel@r-project.org mailing list >>> https://stat.ethz.ch/mailman/listinfo/r-devel >> >> __ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Confusion about Depends:, Imports:, Enhances:, import(), inportFrom()
On Aug 22, 2013, at 9:09, Michael Friendly wrote: > In checking my vcdExtra package, the following NOTE newly appeared (R-Forge, > using R version 3.0.1 Patched (2013-08-20 r63635)) > > Package in Depends field not imported from: ‘gnm’ > These packages needs to imported from for the case when > this namespace is loaded but not attached. > > In the DESCRIPTION file, I have > > Depends: R (>= 2.10), vcd, gnm (>= 1.0.3) > > In NAMESPACE: > > # we are a vcd extension > import(vcd) > > I've read 1.1.1 of R-Exts, but it is not clear to me whether I should also > import gnm or change > the DESCRIPTION file to use > > Imports: vcd, gnm (>= 1.0.3) > > R-Exts says: The ‘Imports’ field lists packages whose namespaces are imported > from (as specified in the > NAMESPACE file) but which do not need to be attached, but how can I tell if > gnm needs to be attached? I think the current best practice is to use Imports unless gnm provides functions the end user needs in order to use your package. Practically, I think this usually comes down to asking whether gnm provides relevant generics -- if you provide methods only, the end user would only be able to call them directly (ick!) unless gnm is both loaded and attached (Depends) If gnm is tools for your code, but not the user to call directly, Imports is cleaner. Does that help? Michael > > Also, what is the difference between Imports: in DESCRIPTION and imports() in > NAMESPACE? > One enables the other: Imports in DESCRIPTION allows for both imports() and importsFrom(). It could probably be automatic, but the DESC file is much older than the NAMESPACE file. > -Michael > > -- > Michael Friendly Email: friendly AT yorku DOT ca > Professor, Psychology Dept. & Chair, Quantitative Methods > York University Voice: 416 736-2100 x66249 Fax: 416 736-5814 > 4700 Keele StreetWeb: http://www.datavis.ca > Toronto, ONT M3J 1P3 CANADA > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Extending suggestion for stopifnot
On Aug 20, 2013, at 14:41, ivo welch wrote:
> A second enhancement would be a "smart string", which knows that
> everything inside {{...}} should be evaluated.
I think one the HTML templating libraries (whisker or mustache or some such)
provides something not unlike this. Perhaps take a look.
>
> stopifnot( is.matrix(m), "m is not a matrix, but a {{class(m)}}" )
>
>
> my own programming variant looks even nicer,
>
> is.matrix(m) %or% "m is not a matrix but a {{class(m)}}"
>
> but requesting base R to add the %and% and %or% (or, better yet, 'and'
> and 'or') operators by default would be pushing my luck.
Does %or% throw an error or is this wrapped in something else?
The former seems rather perl-ish, but the latter might suggest you look into
the || and && operators if you only know their single counterparts.
Michael
>
> /iaw
>
>
>
> Ivo Welch (ivo.we...@gmail.com)
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Depends vs Imports
On Wed, Jul 31, 2013 at 7:35 PM, Simon Urbanek wrote: > > On Jul 31, 2013, at 7:14 PM, Paul Gilbert wrote: > >> I am being asked to modernize the Depends line in the DESCRIPTION file of >> some packages. Writing R Extensions says: >> >> The general rules are >> >> Packages whose namespace only is needed to load the package using >> library(pkgname) must 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, only. >> >> Could someone please explain a few points I thought I understood but >> obviously do not, or point to where these are explained: >> >> -What does it mean for the namespace only to be needed? I thought the >> namespace was needed if the package or some of its functions were mentioned >> in the NAMESPACE file, and that only the namespace was needed if only the >> generics were called, and not other functions. The above suggests that I may >> be wrong about this. If so, that is, Imports will usually suffice, then when >> would Depends ever be needed when a package is mentioned in the NAMESPACE >> file? >> > > In the namespace era Depends is never really needed. All modern packages have > no technical need for Depends anymore. Loosely speaking the only purpose of > Depends today is to expose other package's functions to the user without > re-exporting them. > Just to make sure I understand this: an example would be if A provides an S3 generic and B provides a (registered but unexported) method for that generic -- this would be a great time for B to list A as "Depends" instead of "Imports" to make sure the generic is available to the user? Thanks, Michael __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] On the mechanics of function evaluation and argument matching
On Wed, Jul 17, 2013 at 9:58 AM, Brian Rowe wrote: > Hello, > > Section 4.3.2 of the R language definition [1] states that argument matching > to formal arguments is a 3-pass process to match arguments to a function. An > error is generated if any (supplied) arguments are left unmatched. > Interestingly the opposite is not true as any unmatched formals does not > generate an error. > >> f <- function(x,y,z) x >> f(2) > [1] 2 >> f(2,3) > [1] 2 > > Since R is lazily evaluated, I understand that it is not an error for an > unused argument to be unassigned. However, it is surprising to me that a > function need not be called with all its required arguments. I guess in this > situation technically "required arguments" means required and referenced > arguments. > >> f() > Error in f() : argument "x" is missing, with no default > > Can anyone shed light on the reasoning for this design choice? I'm not sure I can, but I'd look around at how the missing() function is used. Cheers, MW __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Inconsistent results from .C()
It might also help if you can point us to the C code to help debug.
MW
On Tue, May 21, 2013 at 10:53 AM, Robin Evans wrote:
> I should add to this that I'm running on Scientific Linux 6. I later
> noticed that the bug only seems to occur when I run the code from Rstudio,
> and not if I use the terminal directly, so this may be the key to the
> problem.
>
> Robin
>
> On 20 May 2013 16:12, Robin Evans wrote:
>
>> Hello,
>>
>> I've run into a problem which is both maddening and rather hard to
>> replicate, therefore I wondered if someone might know of a plausible
>> explanation for it. I couldn't find anything in the archives, though
>> maybe I'm searching for the wrong thing.
>>
>> I'm calling some C code using .C, and get the vector I'm interested in
>> back as the 7th location in the returned list. However I find that if
>> I try to inspect the contents of this entry in the list in some ways,
>> I get one answer, and if I look at it in others I get a different
>> answer. It's quite possible that there's something wrong with the C
>> code, but this doesn't seem to explain why this phenomenon would occur
>> in R.
>>
>> The problem does not always occur - I have to run the code a few times
>> and then call the console when it does, but the commands below show
>> what can happen when it does. I apologise for not being able to get a
>> cleaner example. Full code and output is below, but here is a
>> stylised version:
>>
>> The following all give one answer (which is the wrong answer as far as
>> I'm concerned) :
>> * printing the whole list :
>> .C(...) # and looking at the 7th entry
>> * applying c() to the 7th element of the list
>> c(.C(...)[[7]])
>> * assigning the 7th element to a vector:
>> x = .C(...)[[7]];
>> x
>>
>> these give a different answer (which is the answer I would hope the C
>> code returns):
>> * using dput on the 7th entry:
>> dput(.C(...)[[7]])
>> * applying c() and then dput()
>> dput(c(.C(...)[[7]]))
>> * just printing the 7th entry of the list
>> .C(...)[[7]]
>>
>> The answers are consistent in the sense that I always get the same
>> answers from running the same command in the console. I have tried
>> inspecting the returned objects to see if the objects are somehow of a
>> different class than I expect, or are just being printed oddly, but
>> have not found anything untoward.
>>
>> Any suggestions would be much appreciated!
>>
>> Regards,
>>
>> Robin
>>
>>
>> # THESE COMMANDS GIVE ONE ANSWER
>> # [the correct answer always begins with 1, the incorrect with -1]
>>
>> > .C("oneMargin", c(1L,1L,1L,1L,1L), c(1L,1L,1L,1L,1L), 1L,
>> c(2L,2L,2L,2L,2L), 5L, ptr1, ptr2)[[7]]
>> [1] 1 -1 -1 1 -1 1 1 -1 -1 1 1 -1 1 -1 -1 1 -1 1 1 -1 1 -1
>> -1 1 1 -1 -1 1 -1 1 1 -1
>>
>> > dput(.C("oneMargin", c(1L,1L,1L,1L,1L), c(1L,1L,1L,1L,1L), 1L,
>> c(2L,2L,2L,2L,2L), 5L, ptr1, ptr2)[[7]])
>> c(1L, -1L, -1L, 1L, -1L, 1L, 1L, -1L, -1L, 1L, 1L, -1L, 1L, -1L,
>> -1L, 1L, -1L, 1L, 1L, -1L, 1L, -1L, -1L, 1L, 1L, -1L, -1L, 1L,
>> -1L, 1L, 1L, -1L)
>>
>> > x=dput(c(.C("oneMargin", c(1L,1L,1L,1L,1L), c(1L,1L,1L,1L,1L), 1L,
>> c(2L,2L,2L,2L,2L), 5L, ptr1, ptr2)[[7]]))
>> c(1L, -1L, -1L, 1L, -1L, 1L, 1L, -1L, -1L, 1L, 1L, -1L, 1L, -1L,
>> -1L, 1L, -1L, 1L, 1L, -1L, 1L, -1L, -1L, 1L, 1L, -1L, -1L, 1L,
>> -1L, 1L, 1L, -1L)
>> > x
>> [1] 1 -1 -1 1 -1 1 1 -1 -1 1 1 -1 1 -1 -1 1 -1 1 1 -1 1 -1
>> -1 1 1 -1 -1 1 -1 1 1 -1
>>
>> # THESE ALL GIVE A DIFFERENT ONE!
>>
>> > .C("oneMargin", c(1L,1L,1L,1L,1L), c(1L,1L,1L,1L,1L), 1L,
>> c(2L,2L,2L,2L,2L), 5L, ptr1, ptr2)
>>
>> # (OTHER ELEMENTS OF LIST REMOVED)
>> [[7]]
>> [1] -1 -1 1 1 1 1 -1 -1 1 1 -1 -1 -1 -1 1 1 1 1 -1 -1 -1 -1
>> 1 1 -1 -1 1 1 1 1 -1 -1
>>
>> > c(.C("oneMargin", c(1L,1L,1L,1L,1L), c(1L,1L,1L,1L,1L), 1L,
>> c(2L,2L,2L,2L,2L), 5L, ptr1, ptr2)[[7]])
>> [1] -1 -1 1 1 1 1 -1 -1 1 1 -1 -1 -1 -1 1 1 1 1 -1 -1 -1 -1
>> 1 1 -1 -1 1 1 1 1 -1 -1
>> > x = .C("oneMargin", c(1L,1L,1L,1L,1L), c(1L,1L,1L,1L,1L), 1L,
>> c(2L,2L,2L,2L,2L), 5L, ptr1, ptr2)[[7]]
>> > x
>> [1] -1 -1 1 1 1 1 -1 -1 1 1 -1 -1 -1 -1 1 1 1 1 -1 -1 -1 -1
>> 1 1 -1 -1 1 1 1 1 -1 -1
>>
>>
>> --
>> Robin Evans
>> Statistical Laboratory
>> University of Cambridge
>> blog: itsastatlife.blogspot.com
>> web: www.statslab.cam.ac.uk/~rje42
>>
>> Causal Inference Workshop July 15th:
>> http://www.statslab.cam.ac.uk/~rje42/uai13/main.htm
>>
>
>
>
> --
> Robin Evans
> Statistical Laboratory
> University of Cambridge
> blog: itsastatlife.blogspot.com
> web: www.statslab.cam.ac.uk/~rje42
>
> Causal Inference Workshop July 15th:
> http://www.statslab.cam.ac.uk/~rje42/uai13/main.htm
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
___
Re: [Rd] locking down R
On Sun, May 19, 2013 at 7:16 PM, Ben Bolker wrote: > > Is anyone on this list aware of discussions about locking down/securing R? > > My colleagues and I are working with health statistics in an office > that disallows many useful tools (e.g. emacs, vim, perl, make) on the > grounds that they represent a security risk. We are considering pushing > back, but we are worried that if we attract the attention of the Powers > That Be to the reality that R allows execution of arbitrary shell > commands, they will then disallow the use of R (SAS and Stata are our > other optiona). It might be useful to be able to give them options for > securing R. > > Possibly useful information: > > * the office allows use of SAS (and Stata, MLWiN, etc.) but uses the > NOXCMD specification to prevent shell access from within SAS. They also > disallow access to the Windows shell (in the current configuration, > shell() works fine from within R, but we think this may have escaped > their notice ...) The workstations have no access to external networks, > nor to external media (thumb drives etc.) [information transfer to the > outside world is via shared drives that can be accessed by > administrators with network access]. > > * I stipulate that (1) the security policies don't make sense, (2) > allowing users access to arbitrary shell commands should _not_ represent > a security risk on a well-administered, modern operating system (they're > running WinXP), (3) R probably offers many other avenues for system > access to a malicious user, even in the absence of shell access, > compilers, etc.. If you really mean a "modern operating system"... ;-) http://arxiv.org/abs/1303.4808 Cheers, MW > > * I suspect the answer given here will be "if you really want to secure > R, run it within a standard restricted-access shell (e.g. chroot on a > Linux system)". If anyone has experience of 'locking down' R on Windows > (XP) in a sensitive environment, I'd be curious about the details. > > thanks > Ben Bolker > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Latex errors (build on windows)
Can you post the offending package?
On Fri, May 3, 2013 at 8:46 AM, Knut Krueger wrote:
> Where can I found hepl about latex errors:
>
> the R CMD check tells me less, but:
> * checking PDF version of manual ... WARNING
> LaTeX errors when creating PDF version.
> This typically indicates Rd problems.
> * checking PDF version of manual without hyperrefs or index ... ERROR
> Re-running with no redirection of stdout/stderr.
> Hmm ... looks like a package
> Error in texi2dvi(file = file, pdf = TRUE, clean = clean, quiet = quiet, :
> pdflatex is not available
> Error in running tools::texi2pdf()
>
> The http://win-builder.r-project.org tells me more details but I am
> comlpetely lost
>
> especially.:
>
> LaTeX errors found:
>
>
>
> ! Paragraph ended before \hyper@n@rmalise was complete.
>
>\par
> l.575 \end
>
> {ExampleCode}
> ! You can't use `macro parameter character #' in horizontal mode.
> ...1,1,1,-1),stringsAsFactors=FALSE) ##
> ## comment text in the
> examples ...
> l.575 \end
>
>
> {ExampleCode}
> ! Missing $ inserted.
>
> $
> l.575 \end
>
> Knut
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Minimal build of R ...
On Thu, May 2, 2013 at 5:12 PM, Jony Hudson wrote:
> Hi,
>
> I'm trying to cross-compile R to javascript so that it can run in a
> web-browser. Take as long as you need to stop laughing. So, as I was saying -
> I want to try and get a build of R running in the browser. [If you're not
> familiar with it already, you might enjoy looking at emscripten.org. It's a
> remarkably capable tool for translating LLVM bitcode to javascript. Check out
> some of the demos!]
>
> I'm trying to start out with the most minimal build of R possible. I can turn
> off various options in the configure script, but I'm wondering about the
> bundled R packages (base, stats etc). I'm guessing that the native code
> portions of these packages are dynamically loaded at runtime, which will
> probably need patching. To start off, I'd like to not build these packages if
> possible.
>
> So, is there a way to configure which packages in the library get built or is
> it just a case of editing the makefile? And is there a minimal set of them
> that would still allow R to run (not be useful - that can come later - just
> run)?
You can run just "base:"
for(i in 1:(length(search()) - 2)){detach(2)}
search()
Not sure if you need "compiler" around for the build process, but we
survived without it once, so I'd assume you can get by without it if
you're willing to tweak.
Godspeed,
MW
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] diag() when input is a numeric scalar
On Thu, May 2, 2013 at 12:35 AM, philchalmers wrote: > Hi All, > > I'm wondering why when passing a single numeric value that contains any > decimals to diag() that the value is silently coerced to a integer for > constructing an identify matrix. To me, an input like diag(5.435) seems > fairly ambiguous and is more than likely a programming mistake, since it's > not obvious that a 5x5 identity matrix should be created. I've seen some > code where other writers have been burned on this as well, especially when > trying extract diagonal elements but forget about the scalar case. A warning > or message would help track this problem down really quickly to force the > author to use diag(floor(5.435)) explicitly, if indeed that is there > intention. Thoughts? > I agree it's probably rather dangerous, but it does seem consistent with much of R: matrix(0, ncol = 3.5) replicate(2.525, rnorm(3)) etc. So would you propose a global change (the oft talked about "strict mode") of R or just here? Either way, does this play nicely with R's goals of having integers and floats behave more or less interchangeably? That said, I'm slightly confused by a bit of your message: are you conflating the rounding to integer issue with the different behavior for scalars issue (same as with sample())? Michael __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Catch SIGINT from user in backend C++ code
On Thu, May 2, 2013 at 12:50 AM, Jewell, Chris wrote: > Hi, > > I was wondering if anybody knew how to trap SIGINTs (ie Ctrl-C) in backend > C++ code for R extensions? I'm writing a package that uses the GPU for some > hefty matrix operations in a tightly coupled parallel algorithm implemented > in CUDA. > > The problem is that once running, the C++ module cannot apparently be > interrupted by a SIGINT, leaving the user sat waiting even if they realise > they've launched the algorithm with incorrect settings. Occasionally, the > SIGINT gets through and the C++ module stops. However, this leaves the CUDA > context hanging, meaning that if the algorithm is launched again R dies. If > I could trap the SIGINT, then I could make sure a) that the algorithm stops > immediately, and b) that the CUDA context is destructed nicely. > > Is there a "R-standard" method of doing this? > I think R_CheckUserInterrupt() might be the right way to go but I haven't used it much, so not sure if it gives you recovery ability. Cheers, Michael > Thanks, > > Chris > > > -- > Dr Chris Jewell > Lecturer in Biostatistics > Institute of Fundamental Sciences > Massey University > Private Bag 11222 > Palmerston North 4442 > New Zealand > Tel: +64 (0) 6 350 5701 Extn: 3586 > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Why does typeof() modify an object's "named" field?
On Fri, Mar 22, 2013 at 7:43 PM, Josh O'Brien wrote: > Some other functions that query the nature of an object (e.g. class(), > length(), attributes()) do not modify the object's "named" field. Is > there a reason that typeof() should? > Because it's not implemented as a primitive and the closure used in setting up the internal call [1] bumps up the NAMED field: compare x <- 1:3; y <- 1:4; z <- 1:5 .Internal(inspect(x)) typeof(x) # Closure .Internal(inspect(x)) .Internal(inspect(y)) class(y) # Primitive .Internal(inspect(y)) .Internal(inspect(z)) .Internal(typeof(z)) .Internal(inspect(z)) giving > x <- 1:3; y <- 1:4; z <- 1:5 > > .Internal(inspect(x)) @7886c78 13 INTSXP g0c2 [NAM(1)] (len=3, tl=0) 1,2,3 > typeof(x) # Closure [1] "integer" > .Internal(inspect(x)) @7886c78 13 INTSXP g0c2 [NAM(2)] (len=3, tl=0) 1,2,3 > > .Internal(inspect(y)) @7886cf0 13 INTSXP g0c2 [NAM(1)] (len=4, tl=0) 1,2,3,4 > class(y) # Primitive [1] "integer" > .Internal(inspect(y)) @7886cf0 13 INTSXP g0c2 [NAM(1)] (len=4, tl=0) 1,2,3,4 > > .Internal(inspect(z)) @7a8e9d8 13 INTSXP g0c3 [NAM(1)] (len=5, tl=0) 1,2,3,4,5 > .Internal(typeof(z)) [1] "integer" > .Internal(inspect(z)) @7a8e9d8 13 INTSXP g0c3 [NAM(1)] (len=5, tl=0) 1,2,3,4,5 Michael [1] I'm not super certain about the fact it's the closure vs argument passing (or if the distinction even makes sense) but I know that this behavior is part of the reason primitives are important. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Typo-let in NEWS.Rd
Applicable against current trunk and (I believe) R-3.0.0 branch.
Michael
Index: doc/NEWS.Rd
===
--- doc/NEWS.Rd (revision 62340)
+++ doc/NEWS.Rd (working copy)
@@ -183,7 +183,7 @@
through as bytes inputs invalid in the current locale.
\item Specifying both \code{rate} and \code{scale} to
- \code{[dpar]gamma} is a warning (if they are essentially the same
+ \code{[dpqr]gamma} is a warning (if they are essentially the same
value) or an error.
\item \code{merge()} works in more cases where the data frames
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Viewing Compelete Decision Tree in R - R.2.15.2 - Wndows7 32bit
Not an R-devel question. Wait for a response for your cross post to R-help. MW On Thu, Mar 14, 2013 at 9:51 AM, Manoj G wrote: > I tried drawing some decision trees. Since the number of levels are more in > the tree, the plot result for the decision tree is not clear and > conjusted. If i save it as pdf or png also, the image is same. > > So how can i view the complete clear plot of decision tree? > > [[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] It's a BUG or a Feature? Generating seq break comparing operators
R FAQ 7.31 Cheers, MW On Thu, Feb 7, 2013 at 10:05 AM, Davide Rambaldi wrote: > Hello everybody: > > I get a strange behavior with seq, take a look at this: > >> msd <- seq(0.05,0.3, 0.01) >> msd[13] > [1] 0.17 >> class(msd) > [1] "numeric" >> class(msd[13]) > [1] "numeric" >> typeof(msd[13]) > [1] "double" > > now the problem: > >> msd[13] == 0.17 > [1] FALSE > > It is strange only to me? > > Consider that: > >> 0.17 == 0.17 > [1] TRUE > > and also > >> a <- c(0,1,0.17) >> a > [1] 0.00 1.00 0.17 >> a[3] == 0.17 > [1] TRUE > > It's a BUG in seq? I suspect something related to doubles … > > sessionInfo(): > > R version 2.15.2 (2012-10-26) > Platform: x86_64-apple-darwin9.8.0/x86_64 (64-bit) > > locale: > [1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8 > > attached base packages: > [1] stats graphics grDevices utils datasets methods base > > loaded via a namespace (and not attached): > [1] tools_2.15.2 > > > --- > PLEASE NOTE MY NEW EMAIL ADDRESS > --- > > - > Davide Rambaldi, PhD. > - > IEO ~ MolMed > [e] davide.ramba...@ieo.eu > [e] davide.ramba...@gmail.com > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] error in plot(table(c('a','a')))
Should I file an issue for this in the bug tracker?
Slighly rearranged discussion with reproducible example follows on below.
> Em 26-11-2012 21:39, R. Michael Weylandt escreveu:
>>
>> On Mon, Nov 26, 2012 at 2:41 PM, Ludo Pagie wrote:
>>> tbl.char1 <- table(c('a','a'))
>>> tbl.char2 <- table(c('a','a','b'))
>>> tbl.int1 <- table(c(1,1))
>>>
>>> # error:
>>> plot(tbl.char1)
>>>
>>> # no errors:
>>> plot(tbl.char2)
>>> plot(tbl.int1)
>>>
>> Confirmed in current R-devel. It seems to arise from plot.table's use
>> of seq.int(x) when the dimnames of the table are not integers. I'm not
>> sure if this shouldn't be seq_along(x) instead, but I'm not sure I
>> totally follow the internal logic, so perhaps someone can offer second
>> opinion?
On Mon, Nov 26, 2012 at 11:34 PM, Rui Barradas wrote:
> I'd change "when the dimnames of the table are not integers "
> to not numeric as that's what the code for plot.table tests. And it
> seems to come from seq.int, since with table value
> of 2, seq.int produces a vector of length 2 but the table length is 1:
>
> seq_along seems to solve the matter.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] choose folder interactively
On Wed, Nov 28, 2012 at 12:47 PM, Duncan Murdoch wrote: > On 12-11-28 7:39 AM, Ivan Calandra wrote: >> >> Dear users, >> >> I am looking for a function to choose a folder interactively, just like >> file.choose() but for a folder. >> > "choose.dir()" does exist on Windows, so you could switch to that OS, or > write your own equivalent for MacOS. Is this the sort of thing for which a patch to the Mac-specific code would be welcomed/of some interest by R-Core or are their good reasons this doesn't already exist? Michael __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Retrieving data from aspx pages
Hi Jose, I think this is more of an r-help question so I'm going to forward your question there: R-devel is really for the development of R itself, not development with R. Cheers, Michael On Mon, Oct 29, 2012 at 8:11 PM, jose ramon mazaira wrote: > Hi. I'm trying to write an application to retrieve financial data > (specially bonds data) from FINRA. The web page is served dynamically > from an asp.net application: > > http://cxa.gtm.idmanagedsolutions.com/finra/BondCenter/AdvancedScreener.aspx > > I'd like to know if it's possible to fill dynamically the web page > form from R and, after filling it (with the issuer name), retrieve the > web page, parse the data, and covert it to appropiate R objects. > For example, suppose I want to search data for AT&T bonds. I'd like to > know if it's possible, within R, to fill the page served from: > > http://cxa.gtm.idmanagedsolutions.com/finra/BondCenter/AdvancedScreener.aspx > > select the "corporate" option and fill with AT&T the field for "Issuer > name", ask the page to display the results, and retrieve the results > for each of the bonds issued by AT&T (for example: > > http://cxa.gtm.idmanagedsolutions.com/finra/BondCenter/BondDetail.aspx?ID=MDAxOTU3Qko3) > > and parsing the data from the web page. > > Thanks in advance. > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] malloc error in tab-completion: OS X
I've just built R-devel (r60889) from source on my Mac OS X 10.6.8 using gcc from Xcode and gfortran from Simon. I didn't use all the recommended configuration flags only ./configure && make Still, I seem to pass "make check" and "make test-Segfault" in the tests directory with no problem, but the following leads to a persistent error + instant abort. 1) Start R 2) Type "tools::" 3) Tab to attempt to auto-complete resulting in some variation on mweylandt-laptop:~ michaelweylandt$ rDEVEL/bin/R --vanilla -q > tools::R(44436) malloc: *** error for object 0x1006d8700: incorrect checksum > for freed object - object was probably modified after being freed. *** set a breakpoint in malloc_error_break to debug Abort trap at which point hitting drops me back into bash. This seems to only occur with tools and no other packages (that I've found). It also occurs whether tools has been library()'d or not, but sometimes it takes two tabbings. My compiler info follows mweylandt-laptop:~ michaelweylandt$ gcc --version i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) (dot 3) Copyright (C) 2007 Free Software Foundation, Inc. mweylandt-laptop:~ michaelweylandt$ gfortran --version GNU Fortran (GCC) 4.2.1 (Apple Inc. build 5664) Copyright (C) 2007 Free Software Foundation, Inc. I do think that it's only a problem with my local build, as I can't replicate with Simon's nightly builds (http://r.research.att.com/), which are at r60887 currently. Is there anything else I should check with my setup? I don't see any advice on this particular issue in the R installation manual, but I easily could have overlooked it. Thanks, Michael __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Small Extension to license()/licence()
By analogy with maintainer(), I suggest extending license() to give
the licensing terms of packages as well as R itself when prompted.
Below is a small patch in that direction. This won't break anything
and imposes no significant maintenance burden; it has the advantage of
making it ever so marginally easier to know package licenses.
Given the existence of license forms like GPL >=2, I don't see a easy
programmatic way of identifying what RShowDoc() can provide and what
it can't, so I've left that out.
Cheers,
Michael
-
Index: src/library/base/R/license.R
===
--- src/library/base/R/license.R(revision 60839)
+++ src/library/base/R/license.R(working copy)
@@ -16,8 +16,14 @@
# A copy of the GNU General Public License is available at
# http://www.r-project.org/Licenses/
-licence <- license <- function() {
-cat("\nThis software is distributed under the terms of the GNU General\n")
+licence <- license <- function(pkg = NULL) {
+ if(!is.null(pkg)) pkgd <- packageDescription(pkg)
+ if(is.null(pkg) || pkgd[["Priority"]] == "base"){
+if(is.null(pkg)){
+ cat("\nThis software is distributed under the terms of the GNU
General\n")
+} else {
+ cat(pkg, "is part of R and distributed under the terms of the
GNU General\n")
+}
cat("Public License, either Version 2, June 1991 or Version 3,
June 2007.\n")
cat("The terms of version 2 of the license are in a file called
COPYING\nwhich you should have received with\n")
cat("this software and which can be displayed by RShowDoc(\"COPYING\").\n")
@@ -34,4 +40,9 @@
cat("Version 3 of the license can be displayed by RShowDoc(\"LGPL-3\").\n")
cat("\n")
cat("'Share and Enjoy.'\n\n")
+ } else {
+cat(pkg, "is distributed under the", pkgd[["License"]],"License.\n")
+ }
+
+ invisible(NULL)
}
Index: src/library/base/man/license.Rd
===
--- src/library/base/man/license.Rd (revision 60839)
+++ src/library/base/man/license.Rd (working copy)
@@ -8,13 +8,18 @@
\alias{license}
\alias{licence}
\description{
- The license terms under which \R is distributed.
+ The license terms under which \R or a contributed package is distributed.
}
\usage{
-license()
-licence()
+license(pkg = NULL)
+licence(pkg = NULL)
}
\details{
+ If pkg is "NULL", the licensing terms of R are given; else, the
+ license of the package (as taken from the package DESCRIPTION file) is
+ returned. Major open-source licenses can be found in
+ \file{\var{\link{R_HOME}}/share/licenses} and viewed with \link{RShowDoc}.
+
\R is distributed under the terms of the GNU GENERAL PUBLIC LICENSE,
either Version 2, June 1991 or Version 3, June 2007. A copy of the
version 2 license is in file \file{\var{\link{R_HOME}}/COPYING} and
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R crashes when printing a named numeric vector of a specific class - Bug?
On Tue, Sep 11, 2012 at 4:35 PM, Milan Bouchet-Valat wrote:
> Le mardi 11 septembre 2012 à 16:53 +0200, Basil Abou El-Komboz a écrit :
>> Dear useR's,
>>
>> today I stumbled over an interesting phenomenon: First, I created a
>> named numeric vector with a certain class and several attributes via the
>> structure() function. After that, I implemented a simple print method
>> for this class. When calling this function it produces an endless loop
>> of print calls until R crashes. :/
>>
>> What is going on here? Is this a bug or have I done something completely
>> wrong? :)
>>
>> Below is a minimal example which reproduces the behavior. Be careful
>> when calling foo() as this automatically calls print.bar() which causes
>> R to crash (at least on my PC, see further informations about my system
>> below.)
>>
>> Greetings,
>> Basil
>>
>> --
>>
>> Minimal example:
>>
>> foo <- function () {
>> x <- c("A" = 1.3, "B" = 0.7, "C" = -0.3)
>> structure(x, class = "bar")
>> }
>>
>> print.bar <- function (x, ...) {
>> print(x, ...)
>> }
> What is your code supposed to do exactly? ;-)
>
> You're calling print() in your class' print.bar() function, so calling
> print() on such an object will call print.bar(), which calls print(),
> which calls print.bar()... In a few moments the recursion will have gone
> so deep that some system limit about the stack size must be reached, and
> R is killed.
>
> If you just want to print the object as a vector, you do not need to
> define any function. Or, at least, call print.default() instead of the
> generic print().
>
>
> My two cents
>
NextMethod() may also be of some help here, depending on the
inheritance you're envisioning.
Michael
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Don't dput() data frames?
On Tue, Aug 28, 2012 at 1:00 PM, Simon Urbanek
wrote:
>
> On Aug 28, 2012, at 1:51 PM, R. Michael Weylandt wrote:
>
>> /src/main/attrib.c contains this comment in row_names_gets():
>>
>> /* This should not happen, but if a careless user dput()s a
>> data frame and sources the result, it will */
>>
>> which svn blame says Prof Ripley placed there in r39830 with the
>> commit message "correct the work of dput() on the row names of a data
>> frame with compact representation."
>>
>> Is there a problem / better way to use the result of a hefty dput than
>> source()ing it?
>
> It's pretty much the least efficient and most dangerous (as in insecure) way.
> That's why there is serialization instead ...
>
My most common use of dput() is for sending plain text data over
r-help; would this be an official/unofficial advisement to push folks
to use
serialize(x, NULL, ascii = TRUE)
instead? At first blush that seems to be less space efficient:
sum(nchar(capture.output(dput(iris # 3767
sum(nchar(serialize(iris, NULL, ascii = TRUE))) # 5922: probably even
more if we dump it properly to plain text in a copy+pasteable form
Michael
> Cheers,
> Simon
>
>
>
>> This seems to work rather robustly:
>>
>> data(iris)
>> source(textConnection(paste0("iris2 <- ", capture.output(dput(iris)
>> identical(iris, iris2)
>>
>> Cheers,
>> Michael
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>>
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Don't dput() data frames?
/src/main/attrib.c contains this comment in row_names_gets():
/* This should not happen, but if a careless user dput()s a
data frame and sources the result, it will */
which svn blame says Prof Ripley placed there in r39830 with the
commit message "correct the work of dput() on the row names of a data
frame with compact representation."
Is there a problem / better way to use the result of a hefty dput than
source()ing it? This seems to work rather robustly:
data(iris)
source(textConnection(paste0("iris2 <- ", capture.output(dput(iris)
identical(iris, iris2)
Cheers,
Michael
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [BUG?] utils::prompt(name=f)
Just for the record, I don't see that error with 2.15.0 or with
R-Devel 60040-someodd. Both display
> foo <- function(x) cat(x, "\n")
> prompt(name = "foo")
Created file named ‘foo.Rd’.
Edit the file and move it to the appropriate directory.
Best,
Michael
On Sun, Jul 29, 2012 at 12:17 PM, Paul Roebuck wrote:
>> ?prompt
> [SNIP]
> ## Create a help file for each function in the .GlobalEnv:
> for(f in ls()) if(is.function(get(f))) prompt(name = f)
>
>> foo <- function(x) { cat(x, '\n')}
>> prompt(name="foo")
> Error in utils:::prompt(object, filename = filename, name = name, ...) :
> argument "object" is missing, with no default
>> version
> platform x86_64-apple-darwin9.8.0
> arch x86_64
> os darwin9.8.0
> system x86_64, darwin9.8.0
> status Patched
> major 2
> minor 15.1
> year 2012
> month 07
> day05
> svn rev59734
> language R
> version.string R version 2.15.1 Patched (2012-07-05 r59734)
> nickname Roasted Marshmallows
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] questions on R CMD INSTALL et al
On Tue, Jul 24, 2012 at 2:30 PM, luxInteg wrote: > Greetings, > > I am learning R > My machine has these; > CPU: 3cores amd64 > OS pure-64bit CBLFS liux compiled from sources (kernel 3.2.1, gcc-4.6.2 > R-2.15 > When I compiled R the compiler spewed out lines like these:- > > make[3]: Entering directory `/tmp/RtmpiHdDJy/R.INSTALL472339eeb23a/mgcv/src' > gcc -m64 -std=gnu99 -I/home/Rman/R-2.15.0/include -DNDEBUG - > I/usr/local/atlas/include -I/usr/local/numerics/include-fpic -g -O2 -c > gcv.c -o gcv.o > gcc -m64 -std=gnu99 -I/home/Rman/R-2.15.0/include -DNDEBUG - > I/usr/local/atlas/include -I/usr/local/numerics/include-fpic -g -O2 -c > gdi.c -o gdi.o > gcc -m64 -std=gnu99 -I/home/Rman/R-2.15.0/include -DNDEBUG - > I/usr/local/atlas/include -I/usr/local/numerics/include-fpic -g -O2 -c > init.c -o init.o > gcc -m64 -std=gnu99 -I/home/Rman/R-2.15.0/include -DNDEBUG - > I/usr/local/atlas/include -I/usr/local/numerics/include-fpic -g -O2 -c > magic.c -o magic.o > gcc -m64 -std=gnu99 -I/home/Rman/R-2.15.0/include -DNDEBUG - > I/usr/local/atlas/include -I/usr/local/numerics/include-fpic -g -O2 -c > mat.c -o mat.o > gcc -m64 -std=gnu99 -I/home/Rman/R-2.15.0/include -DNDEBUG - > I/usr/local/atlas/include -I/usr/local/numerics/include-fpic -g -O2 -c > matrix.c -o matrix.o > gcc -m64 -std=gnu99 -I/home/Rman/R-2.15.0/include -DNDEBUG - > I/usr/local/atlas/include -I/usr/local/numerics/include-fpic -g -O2 -c > mgcv.c -o mgcv.o > gcc -m64 -std=gnu99 -I/home/Rman/R-2.15.0/include -DNDEBUG - > I/usr/local/atlas/include -I/usr/local/numerics/include-fpic -g -O2 -c > misc.c -o misc.o > gcc -m64 -std=gnu99 -I/home/Rman/R-2.15.0/include -DNDEBUG - > I/usr/local/atlas/include -I/usr/local/numerics/include-fpic -g -O2 -c > qp.c -o qp.o > gcc -m64 -std=gnu99 -I/home/Rman/R-2.15.0/include -DNDEBUG - > I/usr/local/atlas/include -I/usr/local/numerics/include-fpic -g -O2 -c > sparse-smooth.c -o sparse-smooth.o > gcc -m64 -std=gnu99 -I/home/Rman/R-2.15.0/include -DNDEBUG - > I/usr/local/atlas/include -I/usr/local/numerics/include-fpic -g -O2 -c > tprs.c -o tprs.o > gcc -m64 -std=gnu99 -shared -L/usr/local/atlas/lib -L/usr/local/numerics/lib - > L/usr/lib -o mgcv.so gcv.o gdi.o init.o magic.o mat.o matrix.o mgcv.o misc.o > qp.o sparse-smooth.o tprs.o -L/home/Rman/R-2.15.0/lib -lRlapack - > L/home/Rman/R-2.15.0/lib -lRblas -lgfortran -lm -L/home/Rman/R-2.15.0/lib -lR > make[3]: Leaving directory `/tmp/RtmpiHdDJy/R.INSTALL472339eeb23a/mgcv/src' > installing to /home/Rman/R-2.15.0/library/mgcv/libs > ** R > ** data > ** inst > ** byte-compile and prepare package for lazy loading > ** help > *** installing help indices > ** building package indices > ** testing if installed package can be loaded > > * DONE (mgcv) > make[2]: Leaving directory `/home/Rman/R-2.15.0/src/library/Recommended' > make[1]: Leaving directory `/home/Rman/R-2.15.0/src/library/Recommended' > > -here is the source_tree for mgcv ---A > mgcv_SR_tree/mgcv/R > mgcv_SR_tree/mgcv/data > mgcv_SR_tree/mgcv/inst > mgcv_SR_tree/mgcv/man > mgcv_SR_tree/mgcv/po > mgcv_SR_tree/mgcv/src > mgcv_SR_tree/mgcv/DESCRIPTION > mgcv_SR_tree/mgcv/MD5 > mgcv_SR_tree/mgcv/NAMESPACE > mgcv_SR_tree/mgcv/changeLog > mgcv_SR_tree/mgcv/gnugpl2.txt > mgcv_SR_tree/mgcv/index > > #--and here is the build tree ---B > mgcv_postBuild_Tree/mgcv/Meta > mgcv_postBuild_Tree/mgcv/R > mgcv_postBuild_Tree/mgcv/data > mgcv_postBuild_Tree/mgcv/help > mgcv_postBuild_Tree/mgcv/html > mgcv_postBuild_Tree/mgcv/libs > mgcv_postBuild_Tree/mgcv/CITATION > mgcv_postBuild_Tree/mgcv/DESCRIPTION > mgcv_postBuild_Tree/mgcv/INDEX > mgcv_postBuild_Tree/mgcv/NAMESPACE > > I havent a clue what is happening in the lines prepended by ** Messages (to you) being given by the build script -- it looks like you got a good build. (The big "DONE" is a good sign) > > Also I used make VERBOSE=1 but the compiler gave no indication of how one > arives at B from A and > how the library created mgcv.so) is installed in mgcv_postBuild_Tree/mgcv/libs > > advise on hese would be much appreciated > > > Reading the manual I noticed the way of installing these recommendd packages > appears to be > R CMD -l path/to/libraries recommended_tarball.tar.gz I think you have a command missing after CMD. Usually the format is R CMD __what_to_do__ -flag options tarball.tar.gz. I.e., if I want to build xts, I get the source and run R CMD INSTALL xts_0.8-7.tar.gz and it all "just works." Linking uses -l as you noted, but only if you need libraries above and beyond the R headers (which are included automatically with R CMD install) that aren't in the package's */src directory. You'll see above the the appropriate flags were passed to gcc for you in specifing ATLAS and the gnu c99 extensions. Linking within R should be done properly for you. I'm not an expert on the package build process, so I'll wait for someone else to say more / correct me if neede
Re: [Rd] large dataset - confused
1) Move this off R-devel to R-help. 2) Read the IO manual here: http://cran.r-project.org/manuals.html 3) You probably want to look at the read.table() function's help page by typing ?read.table Michael On Mon, Jul 23, 2012 at 12:32 PM, walcotteric wrote: > I'm trying to load a dataset into R, but I'm completely lost. This is > probably due mostly to the fact that I'm a complete R newb, but it's got me > stuck in a research project. > I've tried just opening the text file in WordPad and copying the data > directly into R, but it's too big and causes the program to crash. > > Any suggestions or assistance? I'm kinda desperate and lost. > > > > -- > View this message in context: > http://r.789695.n4.nabble.com/large-dataset-confused-tp4637476.html > Sent from the R devel mailing list archive at Nabble.com. > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Interaction parameter for split()
Tal's wonderful aggregator recently reblogged this post: http://rsnippets.blogspot.com/2012/06/you-should-not-use-split-in-production.html It's a rather obscure little buglet [and probably only arises in pathological cases], but I don't know if it's not a case that deserves a bit of consideration (in spite of the point "Anonymous" makes in the comments). His second proposal (giving an "sep=" parameter for interaction) seems the easiest fix and won't break back compatibility. It's not my use case, but I hadn't seen any noise about it here and would be happy to submit a patch if the powers that be are interested. Best, Michael __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Object-oriented programming (OOP)
R has multiple OO paradigms, but since you're starting from a point of "I want object oriented," I'd guess you would be interested in the S4 paradigm which is stricter rather than the far more sane S3 system. If S4 is for you, there are some good links here: http://stackoverflow.com/questions/4143611/sources-on-s4-objects-methods-and-programming-in-r See also the relatively new "Reference Classes" -- I don't have much documentation on those, but you could start here: http://www.bioconductor.org/help/course-materials/2010/HeidelbergNovember2010/ReferenceClasses-Morgan.pdf Best, Michael On Tue, May 15, 2012 at 9:55 AM, Alfredo Naime wrote: > Hello everybody, please excuse my bad English. I am Alfredo Naime and > I'm from to Venezuela. > > I want to make a lib with tools for simulation (queues, inventories, > factory, etc.) using object-oriented programming (OOP). > > You have any manuals on the handling of data types, classes, > inheritance, etc. in R with examples and how to make a R lib. > > Thank you, very much. > > Alfredo > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] StructTS Examples
In the examples for StructTS -- ($RHOME)/library/stats/man/StructTS.Rd -- could par(mfrow = c(4, 1)) plot(log10(UKgas)) plot(cbind(fitted(fit), resids=resid(fit)), main = "UK gas consumption") become plot(log10(UKgas)) par(mfrow = c(4, 1)) plot(cbind(fitted(fit), resids=resid(fit)), main = "UK gas consumption") ## Note that par was moved down This makes the plot of UKgas use the whole plot screen (as opposed to one small panel while three remain empty) which seems like an improvement. Best, Michael __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] creating a package in R
http://cran.r-project.org/doc/manuals/R-exts.pdf Ships with every distribution of R Michael On Apr 29, 2012, at 10:08 AM, nossa wrote: > Please give me the necessary links that permits me to create my own package > inR > > -- > View this message in context: > http://r.789695.n4.nabble.com/creating-a-package-in-R-tp4596411p4596411.html > Sent from the R devel mailing list archive at Nabble.com. > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Typo in ?Logistic
In the source section of ?rlogis, we see: Source: ‘[dpr]logis’ are calculated directly from the definitions. ‘rlogis’ uses inversion. Should that read "[dpq]logis" instead? Michael __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] enableJIT(3) with Primitives
I'm not sure if this is a bug or expected behavior, but I don't see anything in the documentation that explains it, so I thought I'd mention it: ~ michaelweylandt$ R -q --vanilla library(compiler) enableJIT(3) `+` # Throws an error `+` # Throws a warning `+` # Prints the primitive as expected sessionInfo() R version 2.14.1 (2011-12-22) Platform: i386-apple-darwin9.8.0/i386 (32-bit) locale: [1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8 attached base packages: [1] compiler stats graphics grDevices utils datasets methods [8] base It seems to be independent of which primitives are used and I get the same behavior with r58785 built locally. Michael __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
