Re: [Rd] R not running under lldb? (osx)

[Tim Keitt]

Thanks Simon. I'll probably just switch to rocker when needing to debug in
that case.

THK

On Tue, Apr 21, 2020 at 6:51 PM Simon Urbanek 
wrote:

> Tim,
>
> as a security precaution Apple has disabled the ability to debug notarized
> applications*. It means any software distributed on macOS Catalina (and
> they may have retro-actively enabled it for recent updates of Mojave)
> cannot be run in a debugger.
>
> If you want to debug R, you have to use non-release binaries that are not
> notarized and install them by hand, e.g.:
>
> curl -L
> http://mac.r-project.org/high-sierra/R-4.0-branch/x86_64/R-4.0-branch.tar.gz
> | tar fxz - -C /
>
> Of course, this disables the Apple protections and thus is not recommended
> for casual users.
>
> Cheers,
> Simon
>
> * - more technical details: Apple requires notarization of any application
> that will be distributed via an Apple installer. Apple no longer allows
> installation of macOS applications that are not notarized. In order to
> obtain notarization, the application has to be fully signed, has to use
> hardened run-time and may not enable debugging entitlements. One part of
> the hardened run-time is that no debugger is allowed to attach to the
> application.
>
>
> > On 22/04/2020, at 8:59 AM, Tim Keitt  wrote:
> >
> > I see:
> >
> > Tims-Air:~ tkeitt$ R --version
> >
> > R version 3.6.3 (2020-02-29) -- "Holding the Windsock"
> >
> > Copyright (C) 2020 The R Foundation for Statistical Computing
> >
> > Platform: x86_64-apple-darwin15.6.0 (64-bit)
> >
> >
> > R is free software and comes with ABSOLUTELY NO WARRANTY.
> >
> > You are welcome to redistribute it under the terms of the
> >
> > GNU General Public License versions 2 or 3.
> >
> > For more information about these matters see
> >
> > https://www.gnu.org/licenses/.
> >
> >
> > Tims-Air:~ tkeitt$ R -d lldb
> >
> > (lldb) target create
> "/Library/Frameworks/R.framework/Resources/bin/exec/R"
> >
> > Current executable set to
> > '/Library/Frameworks/R.framework/Resources/bin/exec/R' (x86_64).
> >
> > (lldb) run --vanilla
> >
> > error: process exited with status -1 (Error 1)
> >
> > Never happened before. Is this a known issue?
> >
> > Thanks.
> >
> > THK
> >
> >   [[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

[Rd] R not running under lldb? (osx)

[Tim Keitt]

I see:

Tims-Air:~ tkeitt$ R --version

R version 3.6.3 (2020-02-29) -- "Holding the Windsock"

Copyright (C) 2020 The R Foundation for Statistical Computing

Platform: x86_64-apple-darwin15.6.0 (64-bit)


R is free software and comes with ABSOLUTELY NO WARRANTY.

You are welcome to redistribute it under the terms of the

GNU General Public License versions 2 or 3.

For more information about these matters see

https://www.gnu.org/licenses/.


Tims-Air:~ tkeitt$ R -d lldb

(lldb) target create "/Library/Frameworks/R.framework/Resources/bin/exec/R"

Current executable set to
'/Library/Frameworks/R.framework/Resources/bin/exec/R' (x86_64).

(lldb) run --vanilla

error: process exited with status -1 (Error 1)

Never happened before. Is this a known issue?

Thanks.

THK

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] r-project.org dns

[Tim Keitt]

Sorry if this was already discussed. I notice that r-project.org is not
found in dns lookups today. (At least for me -- I tried some online web
look services as well.)

THK

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Experimental package for asan-usan checks

[Tim Keitt]

I've been trying to replicate Brian's excellent work on sanity checks so we
can get that information before submitting. I've put together an
experimental package here: https://github.com/thk686/sanitycheckr

It uses a modified rocker r-devel-san image and attempts to install all
dependencies before running a check.

This would probably be better integrated into TravisCI, et al. It was
nonetheless a good opportunity to learn a bit about docker + asan/usan.
Happy to have people kick the tires, make suggestions or make pull requests.

THK

http://www.keittlab.org/

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Transferring ownership of R-managed buffer

[Tim Keitt]

On Thu, Mar 30, 2017 at 3:15 PM, Gabriel Becker 
wrote:

> technically possible


So the garbage collector knows the buffer length independently of the
SEXPREC length field? Then, yes, its doable, but as you say not advisable.

THK

http://www.keittlab.org/

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Transferring ownership of R-managed buffer

[Tim Keitt]

On Wed, Mar 29, 2017 at 4:56 PM, Gabriel Becker 
wrote:

> The concept of having a vector which is a "window" into another vector
> without duplication ( which I suspect is at least related to your use-case,
> though I could be wrong) is a special case of one of alt-representations I
>  have implemented there.
>

Nice. That is exactly what I need. I was trying out a little experiment,
but I think its not possible right now because the length of an R vector is
identical to the buffer length. I can do everything I need except force the
length of the returned R vector to be only a portion of the allocated
storage.

THK

http://www.keittlab.org/

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Transferring ownership of R-managed buffer

[Tim Keitt]

http://www.keittlab.org/

On Wed, Mar 29, 2017 at 1:04 PM, Hervé Pagès  wrote:

> Hi Tim,
>
> On 03/29/2017 08:24 AM, Tim Keitt wrote:
>
>> I have a use case where I would like to create an SEXP around an existing
>> buffer that is managed by R, thus avoiding a copy operation.
>>
>
> What to you mean exactly by "an existing buffer managed by R"?
>

Not allocated from the general heap, but rather allocated using R's
allocator and therefore returnable (hypothesis!) to the R interpreter as a
vector (not external pointer) without a copy operation.


>
> If I have
>> something like:
>>
>> void *p = (void*) RAW(PROTECT(Rf_allocVector(RAWSXP, n)));
>> ... additional maniupulation ...
>> SEXP x = somefunc(SXPTYPE, n, p);  // 
>>
>> Is there a "placement" constructor available?
>>
>
> What's a "placement" constructor?
>

Function that constructs an object using previously allocated memory (for
example provided by a 3rd party library). In some cases, responsibility for
further management of the buffer is transferred to the new object.


>
> (I have arranged for the
>> corresponding UNPROTECT.) I've looked at and experimented with R_allocator
>> and allocVector3, but can't quite get it right. I know this is odd, but it
>> makes sense for my use case.
>>
>
> Not sure I follow what you are trying to do. Note that an SEXP is a
> pointer to a C struct called SEXPREC. I think that trying to point an
> SEXPREC struct to data pointed to by an existing SEXPREC struct is very
> likely to lead to a disaster.
>

Possibly (although that is not what I am proposing). I'm still trying to
grok where the state resides (all in the SEXPREC or between that and the
allocator).


>
> Note that if the existing buffer managed by R is an SEXP (e.g. b) and
> your code has access to this SEXP then you don't need to create another
> SEXP around its data. Since SEXPs are pointers doing
>
>   SEXP x = b;
>
> is fine and doesn't generate any copy.
>

The buffer in this case might be resized and reallocated and the original
SEXP will have gone out of scope.


>
> And if your code only has access to a "naked" pointer to the buffer
> managed by R (e.g. to RAW(b) is the buffer is actually in an SEXP)
> then why would you need to wrap it inside an SEXP?
>

I'm working with 3rd party structures that can work with a pointer and
buffer length, but cannot track the original SEXP. I just need to construct
an SEXP (SEXPREC) and point it at the buffer, set the vector length and
data type. I was checking to see if there is an API for that (and that wont
interfere with Rcpp declarations as it pulls in parts of Rinternals.h, but
as far as I can tell, not the parts that I need to work with SEXPRECs at a
low-level).

THK


> H.
>
>
>> Thanks for any pointers.
>>
>> THK
>>
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.keit
>> tlab.org_&d=DwICAg&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWd
>> GbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=Ceu5dLU_mdGwmpIk_iUqE0dPNjqw
>> y8wiRy6hS_lWF9k&s=h04DJujKDfqzbLz4FmP3_fZ5bYS3t7UEjSwpLrW5mL0&e=
>>
>> [[alternative HTML version deleted]]
>>
>> __
>> R-devel@r-project.org mailing list
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.et
>> hz.ch_mailman_listinfo_r-2Ddevel&d=DwICAg&c=eRAMFD45gAfqt84V
>> tBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=Ceu5d
>> LU_mdGwmpIk_iUqE0dPNjqwy8wiRy6hS_lWF9k&s=WpLxtWWwjoZ7TjW6oW-
>> vxE6s3LY5kZCG1H5h0xb0Bbs&e=
>>
>>
> --
> Hervé Pagès
>
> Program in Computational Biology
> Division of Public Health Sciences
> Fred Hutchinson Cancer Research Center
> 1100 Fairview Ave. N, M1-B514
> P.O. Box 19024
> Seattle, WA 98109-1024
>
> E-mail: hpa...@fredhutch.org
> Phone:  (206) 667-5791
> Fax:(206) 667-1319
>

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Transferring ownership of R-managed buffer

[Tim Keitt]

I have a use case where I would like to create an SEXP around an existing
buffer that is managed by R, thus avoiding a copy operation. If I have
something like:

void *p = (void*) RAW(PROTECT(Rf_allocVector(RAWSXP, n)));
... additional maniupulation ...
SEXP x = somefunc(SXPTYPE, n, p);  // 

Is there a "placement" constructor available? (I have arranged for the
corresponding UNPROTECT.) I've looked at and experimented with R_allocator
and allocVector3, but can't quite get it right. I know this is odd, but it
makes sense for my use case.

Thanks for any pointers.

THK

http://www.keittlab.org/

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] What happened to Ross Ihaka's proposal for a Common Lisp based R successor?

[Tim Keitt]

My latest project in R + Rcpp + RcppParallel + RcppEigen ran so fast when I
tested it, I thought it was a short-circuit. Not as clean as pure Julia but
if you like C++ its a pretty sweet environment.

(Incidentally, several of the ideas in Julia came from a discussion about
rewriting R I had with Viral many years ago. Its nice to see them come to
life.)

THK

On Fri, Aug 5, 2016 at 12:41 PM Ista Zahn  wrote:

> But you can easily fall back to R from within Julia; see
> http://juliastats.github.io/RCall.jl/latest/
>
> On Aug 5, 2016 1:27 PM, "Hadley Wickham"  wrote:
>
> > No.
> >
> > Hadley
> >
> > On Fri, Aug 5, 2016 at 11:12 AM, Kenny Bell  wrote:
> > > Is it conceivable that Julia could be ported to use R syntax in a way
> > that
> > > would allow the vastly larger numbers of R programmers to seamlessly
> > switch?
> > > Or equivalently, could an iteration of R itself do this?
> > >
> > >
> > > On Fri, Aug 5, 2016, 9:00 AM Hadley Wickham 
> wrote:
> > >>
> > >> When it was being actively worked on, it had the advantage of
> existing.
> > >>
> > >> Hadley
> > >>
> > >> On Fri, Aug 5, 2016 at 10:48 AM, Kenny Bell 
> wrote:
> > >> > Why is the described system preferable to Julia?
> > >> >
> > >> > On Fri, Aug 5, 2016, 4:50 AM peter dalgaard 
> wrote:
> > >> >
> > >> >>
> > >> >> On 05 Aug 2016, at 06:41 , Andrew Judson  wrote:
> > >> >>
> > >> >> > I read this paper
> > >> >> >  > 2008.pdf>
> > >> >> > and
> > >> >> > haven't been able to find out what happened - I have seen some
> > >> >> > sporadic
> > >> >> > mention in message groups but nothing definitive. Does anyone
> know?
> > >> >>
> > >> >> Presumably Ross does...
> > >> >>
> > >> >> You get a hint if you go one level up and look for the newest file:
> > >> >>
> > >> >> https://www.stat.auckland.ac.nz/~ihaka/downloads/New-System.pdf
> > >> >>
> > >> >>
> > >> >> --
> > >> >> Peter Dalgaard, Professor,
> > >> >> Center for Statistics, Copenhagen Business School
> > >> >> Solbjerg Plads 3, 2000 Frederiksberg, Denmark
> > >> >> Phone: (+45)38153501
> > >> >> Office: A 4.23
> > >> >> Email: pd@cbs.dk  Priv: pda...@gmail.com
> > >> >>
> > >> >> __
> > >> >> 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
> > >>
> > >>
> > >>
> > >> --
> > >> http://hadley.nz
> >
> >
> >
> > --
> > http://hadley.nz
> >
> > __
> > 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
>

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Suggestion: mkString(NULL) should be NA

[Tim Keitt]

http://www.keittlab.org/

On Wed, May 25, 2016 at 10:43 AM,  wrote:

> On Wed, 25 May 2016, Tim Keitt wrote:
>
> On Wed, May 25, 2016 at 7:22 AM, Michael Lawrence <
>> lawrence.mich...@gene.com
>>
>>> wrote:
>>>
>>
>> On Wed, May 25, 2016 at 4:23 AM, Jeroen Ooms 
>>> wrote:
>>>
>>>
>> I'm not disagreeing with what's been said in this thread, but I can't help
>> but recall that I brought up this exact issue probably 15 years ago and
>> was
>> told (by Brian, I believe) "don't do that" (pass a null pointer), which
>> was
>> perfectly fine. The real issue was not the behavior but that it was not
>> documented or consistent. I've lived by the mantra since that you can
>> never
>> trust a pointer in R code. User must always check for NULL.
>>
>
> In _C_ code.  This is true whether you are calling into the R C API or
> any other C library: you as the C programmer need to make sure either
> that passing NULL is OK or make sure you don't do that.
>

I agree -- I meant it was "perfectly fine" to remind us we need to check
pointers. Its really a documentation issue.

THK




>
> I wouldn't object to mkXXX checking for NULL and signaling an error
> instead of segfaulting, but good C code calling mkXXX should still
> typically do its own check and handle the situation in an appropriate
> way.
>
> Best,
>
> luke
>
>
>
>> I just wrote my own functions mkXXX_safe that wrap the internals and check
>> the pointer.
>>
>> THK
>>
>> http://www.keittlab.org/
>>
>> [[alternative HTML version deleted]]
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>>
> --
> Luke Tierney
> Ralph E. Wareham Professor of Mathematical Sciences
> University of Iowa  Phone: 319-335-3386
> Department of Statistics andFax:   319-335-3017
>Actuarial Science
> 241 Schaeffer Hall  email:   luke-tier...@uiowa.edu
> Iowa City, IA 52242 WWW:  http://www.stat.uiowa.edu
>

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Suggestion: mkString(NULL) should be NA

[Tim Keitt]

On Wed, May 25, 2016 at 7:22 AM, Michael Lawrence  wrote:

> On Wed, May 25, 2016 at 4:23 AM, Jeroen Ooms 
> wrote:
>

I'm not disagreeing with what's been said in this thread, but I can't help
but recall that I brought up this exact issue probably 15 years ago and was
told (by Brian, I believe) "don't do that" (pass a null pointer), which was
perfectly fine. The real issue was not the behavior but that it was not
documented or consistent. I've lived by the mantra since that you can never
trust a pointer in R code. User must always check for NULL.

I just wrote my own functions mkXXX_safe that wrap the internals and check
the pointer.

THK

http://www.keittlab.org/

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] authorship and citation

[Tim Keitt]

On Wed, Oct 7, 2015 at 2:39 PM, Duncan Murdoch 
wrote:

> I think it was easier to (ab)use that role than to get a "Maintainer"
> role added to the standard ones.
>

Why bother with the relators list at all?

THK

http://www.keittlab.org/

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] authorship and citation

[Tim Keitt]

On Wed, Oct 7, 2015 at 11:29 AM, Spencer Graves  wrote:

> Another example:  The "Author" of the Ecdat package is Yves Croissant <
> yves.croiss...@let.ish-lyon.cnrs.fr>.  I'm the Maintainer.  At some
> point, I may add my name to the list of Authors but I certainly would never
> remove Yves' name.  That package is, I think, exclusively data sets.  I
> added functions, which I later spun off into a separate Edfun package;  I'm
> listed as the Author and Maintainer of that.
>

This reminded me of something I have always found curious about roles
listed in the DESCRIPTION file. Since there is no "maintainer" role in this
list: http://www.loc.gov/marc/relators/relaterm.html, which was used to get
the role names, you will be listed as the "creator" of the package when you
list yourself as maintainer even if you did not initiate the package or
even contribute code.

THK

http://www.keittlab.org/

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Reading exit code of pipe()

[Tim Keitt]

Not sure if it helps for your use case, but I have an experimental package
for controlling bidirectional pipe streams from R. Just thought I'd mention
it. Its at

https://github.com/thk686/pipestreamr

THK

On Thu, May 14, 2015 at 9:30 AM, William Dunlap  wrote:

> The difference in the return value of close(pipeConnectionObject)
> seems to depend on whether the pipe connection was opened via
> the pipe() or open() functions (close() returns NULL)
>> con <- pipe("ls")
>> open(con, "r")
>> readLines(con, n=1)
>[1] "1032.R"
>> print(close(con))
>NULL
>> con <- pipe("ls", "r")
>> scan(con, n=1, what="")
>   Read 1 item
>   [1] "1032.R"
>   > print(close(con))
>   NULL
> or via something like readLines() or scan() (close() returns status
> integer).
>   > con <- pipe("ls")
>   > scan(con, n=1, what="")
>   Read 1 item
>   [1] "1032.R"
>   > print(close(con))
>   [1] 36096
>   > sprintf("0x%x", .Last.value)
>   [1] "0x8d00"
>
>
>
>
>
>
> Bill Dunlap
> TIBCO Software
> wdunlap tibco.com
>
> On Wed, May 13, 2015 at 10:27 PM, Kevin Ushey 
> wrote:
>
> > Hi Jeroen,
> >
> > I think `pipe` might just be returning the status code of the
> > underlying command executed; for example, I get a status code of '0'
> > when I test a pipe on `ls`:
> >
> > conn <- pipe("ls")
> > stream <- readLines(conn)
> > print(close(conn))
> >
> > Similarly, I get an error code if I try to `ls` a non-existent
> > directory (512 in my case), e.g.
> >
> > conn <- pipe("ls /no/path/here/sir")
> > stream <- readLines(conn)
> > print(close(conn))
> >
> > So maybe `cat` just doesn't set a status code, and so there's nothing
> > for R to forward back (ergo -- NULL)?
> >
> > Kevin
> >
> > On Wed, May 13, 2015 at 5:24 PM, Jeroen Ooms 
> > wrote:
> > > Is there a way to get the status code of a pipe() command? The
> > > documentation suggests that it might be returned by close, however
> > > this does not seem to be the case.
> > >
> > >   con <- pipe("cat /etc/passwd", "r")
> > >   stream <- readLines(con, n = 10)
> > >   err <- close(con)
> > >   print(err)
> > >
> > > __
> > > 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
> >
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>



-- 
Timothy H. Keitt
http://www.keittlab.org/

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Typo in src/scripts/config

[Tim Keitt]

Was writing a short R script to modify compile flags and saw this typo:

Index: config
===
--- config (revision 68217)
+++ config (working copy)
@@ -61,7 +61,7 @@
   CXX1X C++ compiler command for C++11 code
   CXX1XSTD  flag used to enable C++11 support
   CXX1XFLAGSC++11 compiler flags
-  CXX1XXPICFLAGS
+  CXX1XPICFLAGS
 special flags for compiling C++11 code to be turned into
 a shared library
   DYLIB_EXT file extension (including '.') for dynamic libraries

-- 
http://www.keittlab.org/

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Documentation for reg.finalizer

[Tim Keitt]

Documentation says (emphasis mine):

"Registers an R function to be called upon garbage collection of
 object OR (optionally) at the end of an R session."

Should this say "and" and not "or"?

THK

-- 
http://www.keittlab.org/

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] :: and ::: as .Primitives?

[Tim Keitt]

On Thu, Jan 22, 2015 at 1:44 PM,  wrote:

> I'm not convinced that how to make :: faster is the right question. If
> you are finding foo::bar being called often enough to matter to your
> overall performance then to me the question is: why are you calling
> foo::bar more than once? Making :: a bit faster by making it a
> primitive will remove some overhead, but your are still left with a
> lot of work that shouldn't need to happen more than once.
>
> For default methods there ought to be a way to create those so the
> default method is computed at creation or load time and stored in an
> environment. For other cases if I want to use foo::bar many times, say
> in a loop, I would do
>
> foo_bar <- foo::bar
>
> and use foo_bar, or something along those lines.
>
> When :: and ::: were introduce they were intended primarily for
> reflection and debugging, so speed was not an issue. ::: is still
> really only reliably usable that way, and making it faster may just
> encourage bad practice. :: is different and there are good arguments
> for using it in code, but I'm not yet seeing good arguments for use in
> ways that would be performance-critical, but I'm happy to be convinced
> otherwise. If there is a need for a faster :: then going to a
> SPECIALSXP is fine; it would also be good to make the byte code
> compiler aware of it, and possibly to work on ways to improve the
> performance further e.g. through cacheing.
>

I think you will find that no matter how much it does not matter in terms
of performance, folks will avoid :: out of principle if they think its
slower. We're conditioned to write efficient code even when it does not
really impact real world usage. As using :: is good practice in many
contexts, making it fast will encourage folks to use it.

THK


>
> Best,
>
> luke
>
>
> On Thu, 22 Jan 2015, Peter Haverty wrote:
>
>
>  Hi all,
>>
>> When S4 methods are defined on base function (say, "match"), the
>> function becomes a method with the body "base::match(x,y)". A call to
>> such a function often spends more time doing "::" than in the function
>> itself.  I always assumed that "::" was a very low-level thing, but it
>> turns out to be a plain old function defined in base/R/namespace.R.
>> What would you all think about making "::" and ":::" .Primitives?  I
>> have submitted some examples, timings, and a patch to the R bug
>> tracker (https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=16134).
>> I'd be very interested to hear your thoughts on the matter.
>>
>> Regards,
>> Pete
>>
>> 
>> Peter M. Haverty, Ph.D.
>> Genentech, Inc.
>> phave...@gene.com
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>>
> --
> Luke Tierney
> Ralph E. Wareham Professor of Mathematical Sciences
> University of Iowa  Phone: 319-335-3386
> Department of Statistics andFax:   319-335-3017
>Actuarial Science
> 241 Schaeffer Hall  email:   luke-tier...@uiowa.edu
> Iowa City, IA 52242 WWW:  http://www.stat.uiowa.edu
>
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>



-- 
http://www.keittlab.org/

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] testing dontrun examples

[Tim Keitt]

On Wed, Nov 26, 2014 at 12:45 PM, Paul Gilbert 
wrote:

> Is there a good strategy for testing examples which should not be run by
> default? For instance, I have examples which get data from the Internet. If
> I wrap them in try() then they can be skipped if the Internet is not
> available, but may not be tested in cases when I would like to know about
> the failure. (Not to mention that the example syntax is ugly.)
>
> If I mark them \dontrun or \donttest then they are not tested. I could
> mark them \dontrun and then use example() but for this, in addition to
> run.dontrun=TRUE, I would need to specify all topics for a package, and I
> don't see how to do this, missing topic does not work.
>
> Wishlist: what I would really like is R CMD check --run-dontrun   pkg
>

I agree that would be nice to have.

My solution was just to have a private function (pkg:::run_examples()) that
runs all the examples. It has to be manually updated when adding a new
example however.

The devtools solution has not always worked for me when there are external
dependencies (like internet download, etc.)

THK


>
> Suggestions?
>
> Thanks,
> Paul
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>



-- 
http://www.keittlab.org/

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Excluding objects from save.image

[Tim Keitt]

On Thu, May 22, 2014 at 10:47 AM, Simon Urbanek  wrote:

> On May 22, 2014, at 11:33 AM, Tim Keitt  wrote:
>
> > On Thu, May 22, 2014 at 9:19 AM, Simon Urbanek <
> simon.urba...@r-project.org> wrote:
> > Tim,
> >
> > On May 21, 2014, at 9:54 PM, Tim Keitt  wrote:
> >
> > > When dealing with object holding pointers that are only valid during a
> single session, it would be convenient to exclude them from being saved
> with the session image. (I am assuming that `quit` calls `save.image`
> before quitting or is it internal?) Currently they are saved with the
> pointer converted to NULL. Its a bit surprising for users not realizing the
> object is no longer valid.
> > >
> >
> > than's not surprising - it's actually very useful, because it tells you
> that the object has been restored. Typically, packages using external
> pointers use this to re-inilitialize the object from serialized data or
> other sources if possible.
> >
> > Automatically or with user intervention?
>
>
> Automatically - that is the point :).
>

Have an example? Do you save a promise?


>
>
> > > My thought is to designate a class name (perhaps "no.save") and
> exclude anything that inherits from that.
> >
> > Why would you want to not save it? It exists, so saving it makes it
> possible to decide on the behavior as needed - as opposed to not saving it
> and thus losing the information.
> >
> > That's a valid argument. I don't necessarily disagree, but it does
> depend on the situation and the author's intentions.
> >
> > My question was not about enforcing policy on authors, rather it was
> about whether this would add value for those that would like to use it for
> cases where they deem it a benefit. I see those as separate issues.
> >
> > Incidentally, I suggested many years ago hooks in load to make
> reinitialization possible. Is there some infrastructure for that in R? (And
> actually hooks on save would be quite useful as well eg one could
> substitute an object designed to reinitialize the original object on load.)
> >
>
> Load time is typically not an issue, since you can just do it lazily.
> (Incidentally, doing that eagerly at load time is the hard part since you'd
> have to load the packages necessary in the right order which is not always
> possible to determine from the serialization alone. It's a full can of
> worms, because R doesn't know anything about sharing and dependencies on
> the native side etc.).
>
> However, having a proper save hook for ext ptrs would be very useful. When
> I was asking for it few years ago, Luke mentioned there were issues - maybe
> it's something that could be re-visited.
>

I'd be interested. I can see it might be tricky deciding when to call the
hook.

THK


>
> Cheers,
> Simon
>
>
>
> > Cheers,
> > THK
> >
> >
> > Cheers,
> > Simon
> >
> >
> >
> > > I've hacked a quick implementation below.
> > > I did not issue a warning, but it would be a simple fix.
> > >
> > > Does anyone else see this as useful?
> > >
> > > THK
> > >
> > > --
> > > http://www.keittlab.org/
> > >
> > > .new.save.image = function (file = ".RData", version = NULL, ascii =
> FALSE,
> > > compress = !ascii,
> > >safe = TRUE, omit.no.save = TRUE)   # added
> > > "omit.no.save" argument
> > > {
> > >  if (!is.character(file) || file == "")
> > >stop("'file' must be non-empty string")
> > >  opts <- getOption("save.image.defaults")
> > >  if (is.null(opts))
> > >opts <- getOption("save.defaults")
> > >  if (missing(safe) && !is.null(opts$safe))
> > >safe <- opts$safe
> > >  if (missing(ascii) && !is.null(opts$ascii))
> > >ascii <- opts$ascii
> > >  if (missing(compress) && !is.null(opts$compress))
> > >compress <- opts$compress
> > >  if (missing(version))
> > >version <- opts$version
> > >  if (safe) {
> > >outfile <- paste0(file, "Tmp")
> > >i <- 0
> > >while (file.exists(outfile)) {
> > >  i <- i + 1
> > >  outfile <- paste0(file, "Tmp", i)
> > >}
> > >  }
> > >  else outfile <- file
> > >  on.exit(file.remove(outfile))
> > >
> > >  ### Omit objects in

Re: [Rd] Excluding objects from save.image

[Tim Keitt]

On Thu, May 22, 2014 at 9:19 AM, Simon Urbanek
wrote:

> Tim,
>
> On May 21, 2014, at 9:54 PM, Tim Keitt  wrote:
>
> > When dealing with object holding pointers that are only valid during a
> single session, it would be convenient to exclude them from being saved
> with the session image. (I am assuming that `quit` calls `save.image`
> before quitting or is it internal?) Currently they are saved with the
> pointer converted to NULL. Its a bit surprising for users not realizing the
> object is no longer valid.
> >
>
> than's not surprising - it's actually very useful, because it tells you
> that the object has been restored. Typically, packages using external
> pointers use this to re-inilitialize the object from serialized data or
> other sources if possible.
>

Automatically or with user intervention?


>
>
> > My thought is to designate a class name (perhaps "no.save") and exclude
> anything that inherits from that.
>
> Why would you want to not save it? It exists, so saving it makes it
> possible to decide on the behavior as needed - as opposed to not saving it
> and thus losing the information.
>

That's a valid argument. I don't necessarily disagree, but it does depend
on the situation and the author's intentions.

My question was not about enforcing policy on authors, rather it was about
whether this would add value for those that would like to use it for cases
where they deem it a benefit. I see those as separate issues.

Incidentally, I suggested many years ago hooks in load to make
reinitialization possible. Is there some infrastructure for that in R? (And
actually hooks on save would be quite useful as well eg one could
substitute an object designed to reinitialize the original object on load.)

Cheers,
THK


>
> Cheers,
> Simon
>
>
>
> > I've hacked a quick implementation below.
> > I did not issue a warning, but it would be a simple fix.
> >
> > Does anyone else see this as useful?
> >
> > THK
> >
> > --
> > http://www.keittlab.org/
> >
> > .new.save.image = function (file = ".RData", version = NULL, ascii =
> FALSE,
> > compress = !ascii,
> >safe = TRUE, omit.no.save = TRUE)   # added
> > "omit.no.save" argument
> > {
> >  if (!is.character(file) || file == "")
> >stop("'file' must be non-empty string")
> >  opts <- getOption("save.image.defaults")
> >  if (is.null(opts))
> >opts <- getOption("save.defaults")
> >  if (missing(safe) && !is.null(opts$safe))
> >safe <- opts$safe
> >  if (missing(ascii) && !is.null(opts$ascii))
> >ascii <- opts$ascii
> >  if (missing(compress) && !is.null(opts$compress))
> >compress <- opts$compress
> >  if (missing(version))
> >version <- opts$version
> >  if (safe) {
> >outfile <- paste0(file, "Tmp")
> >i <- 0
> >while (file.exists(outfile)) {
> >  i <- i + 1
> >  outfile <- paste0(file, "Tmp", i)
> >}
> >  }
> >  else outfile <- file
> >  on.exit(file.remove(outfile))
> >
> >  ### Omit objects inheriting from "no.save" ###
> >
> >  objns <- ls(envir = .GlobalEnv, all.names = TRUE)
> >
> >  if ( omit.no.save )  ### make part of options?
> >objns <- subset(objns, sapply(objns, function(x)
> >{
> >  ! inherits(get(x, envir = .GlobalEnv), "no.save")
> >}))
> >
> >  save(list = objns, file = outfile,
> >   version = version, ascii = ascii, compress = compress,
> >   envir = .GlobalEnv, precheck = FALSE)
> >
> >  ### End code changes ###
> >
> >  if (safe)
> >if (!file.rename(outfile, file)) {
> >  on.exit()
> >  stop(gettextf("image could not be renamed and is left in %s",
> >outfile), domain = NA)
> >}
> >  on.exit()
> > }
> >
> > setClass("no.save")
> > setClass("test.class", slots = c(s1 = "externalptr"))
> > setIs("test.class", "no.save")
> > reg.obj = "regular object"
> > no.save.obj = new("test.class")
> > .image.file = tempfile()
> > save.image(.image.file)
> > rm(reg.obj, no.save.obj)
> > load(.image.file)
> > print(ls())
> > unlink(.image.file)
> > .new.save.image(.image.file)
> > rm(reg.obj, no.save.obj)
> > load(.image.file)
> > print(ls())
> > unlink(.image.file)
> >
> >   [[alternative HTML version deleted]]
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>
>


-- 
http://www.keittlab.org/

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Excluding objects from save.image

[Tim Keitt]

When dealing with object holding pointers that are only valid during a
single session, it would be convenient to exclude them from being saved
with the session image. (I am assuming that `quit` calls `save.image`
before quitting or is it internal?) Currently they are saved with the
pointer converted to NULL. Its a bit surprising for users not realizing the
object is no longer valid.

My thought is to designate a class name (perhaps "no.save") and exclude
anything that inherits from that. I've hacked a quick implementation below.
I did not issue a warning, but it would be a simple fix.

Does anyone else see this as useful?

THK

-- 
http://www.keittlab.org/

.new.save.image = function (file = ".RData", version = NULL, ascii = FALSE,
compress = !ascii,
safe = TRUE, omit.no.save = TRUE)   # added
"omit.no.save" argument
{
  if (!is.character(file) || file == "")
stop("'file' must be non-empty string")
  opts <- getOption("save.image.defaults")
  if (is.null(opts))
opts <- getOption("save.defaults")
  if (missing(safe) && !is.null(opts$safe))
safe <- opts$safe
  if (missing(ascii) && !is.null(opts$ascii))
ascii <- opts$ascii
  if (missing(compress) && !is.null(opts$compress))
compress <- opts$compress
  if (missing(version))
version <- opts$version
  if (safe) {
outfile <- paste0(file, "Tmp")
i <- 0
while (file.exists(outfile)) {
  i <- i + 1
  outfile <- paste0(file, "Tmp", i)
}
  }
  else outfile <- file
  on.exit(file.remove(outfile))

  ### Omit objects inheriting from "no.save" ###

  objns <- ls(envir = .GlobalEnv, all.names = TRUE)

  if ( omit.no.save )  ### make part of options?
objns <- subset(objns, sapply(objns, function(x)
{
  ! inherits(get(x, envir = .GlobalEnv), "no.save")
}))

  save(list = objns, file = outfile,
   version = version, ascii = ascii, compress = compress,
   envir = .GlobalEnv, precheck = FALSE)

  ### End code changes ###

  if (safe)
if (!file.rename(outfile, file)) {
  on.exit()
  stop(gettextf("image could not be renamed and is left in %s",
outfile), domain = NA)
}
  on.exit()
}

setClass("no.save")
setClass("test.class", slots = c(s1 = "externalptr"))
setIs("test.class", "no.save")
reg.obj = "regular object"
no.save.obj = new("test.class")
.image.file = tempfile()
save.image(.image.file)
rm(reg.obj, no.save.obj)
load(.image.file)
print(ls())
unlink(.image.file)
.new.save.image(.image.file)
rm(reg.obj, no.save.obj)
load(.image.file)
print(ls())
unlink(.image.file)

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Can a package override the default color palette?

[Tim Keitt]

Is it is possible for a package to override the default color palette
used by "image". I've tried a few different ways, but was curious if
there is an approved method.

THK

-- 
Timothy H. Keitt, University of Texas at Austin
Contact info and schedule at http://www.keittlab.org/tkeitt/
Reprints at http://www.keittlab.org/tkeitt/papers/
ODF attachment? See http://www.openoffice.org/

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel