Dear all,
I'd like to be able to read from an arbitrary R connection (in the
sense of ?connections), which would be passed to an R function by the
user and then down into some C code via .Call.
The R API, in file R_ext/Connections.h, specifies a function,
R_ReadConnection, which takes a pointer t
0 July 2015 at 10:39, Martin Maechler wrote:
> Dear Jon,
>
> thank you for raising the issue,
>
>>>>>> Jon Clayden
>>>>>> on Tue, 28 Jul 2015 12:14:48 +0100 writes:
>
>> Sorry; minor clarification. The actual test criterion in the examp
Sorry; minor clarification. The actual test criterion in the example I
gave is of course abs((0.1-0.102)/0.1) < 0.01, not abs(0.1) < 0.01. In
any case, this does not match (my reading of) the docs, and the result
is not `TRUE`.
Regards,
Jon
On 28 July 2015 at 11:58, Jon Clayden wrote:
Dear all,
The documentation for `all.equal.numeric` says
Numerical comparisons for ‘scale = NULL’ (the default) are done by
first computing the mean absolute difference of the two numerical
vectors. If this is smaller than ‘tolerance’ or not finite,
absolute differences are used,
gt; However, I'd like to be sure that it isn't a "make dist" issue. We do seem
> to ship the correct files in src/extra/tzone, but could you please check
> Brian's suggestion about TZDIR possibly being set incorrectly?
>
> -pd
>
> On 03 Apr 2014, at 14:47 ,
GMT"
> Warning messages:
> 1: In as.POSIXlt.POSIXct(x, tz) : unknown timezone 'Europe/London'
> 2: In as.POSIXlt.POSIXct(x, tz) : unknown timezone 'GMT'
> 3: In as.POSIXlt.POSIXct(x, tz) : unknown timezone 'America/New_York'
>
> when I do that.
For what it's worth, this issue persists in R-rc_2014-04-02_r65358.
Regards,
Jon
On 24 March 2014 10:40, Jon Clayden wrote:
> Dear all,
>
> As of the current R alpha release, I'm seeing timezone-related warnings on
> installing any package (including the recommended
Dear all,
As of the current R alpha release, I'm seeing timezone-related warnings on
installing any package (including the recommended ones), which I haven't
seen before. For example,
[~/Documents/Source/R-alpha]$ bin/R CMD INSTALL ~/git/tractor/lib/reportr
* installing to library '/Users/jon/Doc
Dear all,
I am trying to find a way to reliably and programmatically establish the
resolution (i.e. DPI or equivalent) of an on-screen device. It seemed to me
that
dev.new(width=1, height=1)
dpi <- dev.size("px")
would do the trick, but the result does not seem to be correct, at least on
OS
using mathematical functions
in my code, and thereby skirt the problem. R CMD LINK now builds the binary
successfully on both platforms.
Regards,
Jon
On 6 July 2013 06:52, Prof Brian Ripley wrote:
> On 06/07/2013 03:19, Simon Urbanek wrote:
>
>> Jon,
>>
>> On Jul 4, 2013, a
Dear all,
I have a simple front-end program which uses the APIs described in section
8 of "Writing R Extensions" to deviate from the standard R behaviour in
fairly minor ways. However, I'm having some difficulty getting it to link
reliably across different platforms.
R CMD LINK seemed like it wou
If you're intending to run some code that may require user input, then I
share your need. I started two threads on this some time ago [1,2], but as
far as I know it still isn't possible. My workaround is to use "expect", or
to create a temporary .Rprofile if that is not available, from within a
she
Dear David,
I can think of two strategies for dealing with this problem:
>
> Strategy 1: Some code like this:
>if (det(X) < epsilon) {
> warning("Near singular matrix")
> return(NULL)
>}
>return(solve(X))
This solution is probably the easiest one to take, but to match
sol
't we always!), so I wouldn't
need access for long.
Regards,
Jon
>
> [Are more Solaris-esque build slaves needed? Someone give a shout if
> so... we can sponsor some infrastructure there.]
>
> --elijah
> (@Joyent)
>
>
>
> On Mon, Dec 3, 2012 at 11:2
Dear all,
The current version of my RNiftyReg package is failing to compile on CRAN's
Solaris testbed, but I don't have access to a Solaris system to debug on,
and Googling the error hasn't been very helpful. The error is
CC -library=stlport4 -I/home/ripley/R/cc/include -DNDEBUG -DNDEBUG
-DRNIFTY
On 16 March 2012 00:48, Martin Morgan wrote:
> On 03/15/2012 02:24 PM, Jon Clayden wrote:
>>
>> Martin,
>>
>> Thanks for your reply. I wonder if you'd be willing to post your
>> "my_fprintf" function, since I'm struggling to get aroun
message still arises because stdout and
stderr still appear. I'm struggling to see how to get around this
without doing something really ugly, like casting integers to FILE*
pointers.
All the best,
Jon
On 15 March 2012 05:04, Martin Morgan wrote:
> On 03/14/2012 05:15 AM, Jon Clayden wro
Dear all,
I recognise the reason for strongly discouraging use of printf() and
similar C functions in R packages, but I wonder what people do in
practice about third-party code which may be littered with such calls.
I maintain a package (RNiftyReg) which provides an R interface to a
third-party li
re good starting points. Allows for accessing binary data on disk
> with very simple R-like semantics, and is very fast. Not as fast as a
> sequential read... but fast. At present this is 'little endian' only
> though, but that describes most of the world today.
>
> Best,
&
Dear all,
In R-devel (2011-09-23 r57050), I'm running into a serious problem
with seek()ing on connections opened with gzfile(). A warning is
generated and the file position does not seek to the requested
location. It doesn't seem to occur all the time - I tried to create a
small example file to i
gnments-to-fields-td3708168.html
>>
>>
>> On Aug 5, 2011, at 6:41 AM, Jon Clayden wrote:
>>
>>> Dear all,
>>>
>>> I've just had a package update bounced from CRAN because of a recent
>>> change in R-devel which seems to affect the behavio
Dear all,
I've just had a package update bounced from CRAN because of a recent
change in R-devel which seems to affect the behaviour of the
initFields() reference class method. (The change must be very recent
because I tested the package on a week-old build of R-devel.) It seems
that the method no
Dear John and others,
I've been wondering about whether there's any way to indicate a "nil"
reference class object, which will represent "no value", and be tested
for, but not fail the internal type checking. NULL is the obvious
choice (or seems so to me), but can only be used if an explicit class
> [mailto:r-devel-boun...@r-project.org] On Behalf Of Simon Urbanek
>>> Sent: Tuesday, March 29, 2011 6:49 PM
>>> To: Duncan Murdoch
>>> Cc: r-devel@r-project.org
>>> Subject: Re: [Rd] Reading 64-bit integers
>>>
>>>
>>> On Mar 29,
ff is against the current beta, but I can provide a SVN diff
against the trunk if that is preferable.
All the best,
Jon
On 30 March 2011 02:49, Simon Urbanek wrote:
>
> On Mar 29, 2011, at 8:47 PM, Duncan Murdoch wrote:
>
>> On 29/03/2011 7:01 PM, Jon Clayden wrote:
>>>
On 30 March 2011 02:49, Simon Urbanek wrote:
>
> On Mar 29, 2011, at 8:47 PM, Duncan Murdoch wrote:
>
>> On 29/03/2011 7:01 PM, Jon Clayden wrote:
>>> Dear Simon,
>>>
>>> On 29 March 2011 22:40, Simon Urbanek wrote:
>>>> Jon,
&g
Dear Simon,
On 29 March 2011 22:40, Simon Urbanek wrote:
> Jon,
>
> On Mar 29, 2011, at 1:33 PM, Jon Clayden wrote:
>
>> Dear Simon,
>>
>> Thank you for the response.
>>
>> On 29 March 2011 15:06, Simon Urbanek wrote:
>>>
>>> On Ma
Dear Simon,
Thank you for the response.
On 29 March 2011 15:06, Simon Urbanek wrote:
>
> On Mar 29, 2011, at 8:46 AM, Jon Clayden wrote:
>
>> Dear all,
>>
>> I see from some previous threads that support for 64-bit integers in R
>> may be an aim for future
Dear all,
I see from some previous threads that support for 64-bit integers in R
may be an aim for future versions, but in the meantime I'm wondering
whether it is possible to read in integers of greater than 32 bits at
all. Judging from ?readBin, it should be possible to read 8-byte
integers to s
I would also be interested in knowing what the rationale is for this.
Moreover, it seems that the "standard" (and documented) approach to
this of calling "options(defaultPackages=c(...))" in ~/.Rprofile does
not get ignored when installing. The environment variable approach may
work, but it seems
Dear all,
Is there a way to force R CMD INSTALL to ignore ~/.Rprofile and
similar? I presume it sources these startup files for a reason, but
I've found that it can cause confusion or problems. In particular, my
~/.Rprofile loads a few packages which I very frequently use, but this
stops me from i
Dear all,
If I load a package which creates reference classes whilst another
such package is also loaded, I get a warning about masking of the
".requireCachedGenerics" variable. (FWIW, both packages are
lazy-loaded.) Googling this variable name turned up only one previous
discussion, which didn't
f the arguments? I am thinking along the
> lines of S4 methods with valid signatures.
>
> Thanks again for the example.
>
>
> On 10/28/2010 12:12 PM, Jon Clayden wrote:
>>
>> Sorry - you don't need to assign the value of initFields(). I was
>> going to do it
Sorry - you don't need to assign the value of initFields(). I was
going to do it in two lines but then realised one was enough... :)
TestClass <- setRefClass ("TestClass",
fields = list (text = "character"),
methods = list (
initialize = function (text) {
initFields(te
Hi Daniel,
I think you want to define an "initialize" method, as in
TestClass <- setRefClass ("TestClass",
fields = list (text = "character"),
methods = list (
initialize = function (text) { object <-
initFields(text=paste(text,"\n")) },
print = functio
On 23 October 2010 00:52, Jon Clayden wrote:
> On 22 October 2010 18:55, John Chambers wrote:
>
>>> As a suggestion, it would be nice if the accessors() method could be
>>> used to create just "getters" or just "setters" for particular fields,
>>
On 22 October 2010 18:55, John Chambers wrote:
>> As a suggestion, it would be nice if the accessors() method could be
>> used to create just "getters" or just "setters" for particular fields,
>> although I realise this can be worked around by removing the unwanted
>> methods afterwards.
>
> In o
Dear all,
First, many thanks to John Chambers, and anyone else who was involved,
for the new support for "reference classes" in R 2.12.0. It's nice to
see this kind of functionality appear in a relatively R-like form, and
with the blessing of the core team. In some contexts it is undoubtedly
appea
On 16 July 2010 13:32, Hadley Wickham wrote:
> On Fri, Jul 16, 2010 at 2:08 PM, Jon Clayden wrote:
>> Dear all,
>>
>> I am trying to create an environment object with additional attributes, viz.
>>
>> Foo <- structure(new.env(), name="Foo")
>&g
Dear all,
I am trying to create an environment object with additional attributes, viz.
Foo <- structure(new.env(), name="Foo")
Doing this in a standard session works fine: I get the environment
with attr(,"name") set as expected. But if the same code appears
inside a package source file, I get j
> > Dear all,
> > The version of readBin() in R-devel includes a use of match(), through
> > `%in%`, which can affect its performance significantly. By using
> > primitives instead of the rather expensive call to match(), I reduce
> > the time spent inside readBin() by more than 30%
Dear all,
The version of readBin() in R-devel includes a use of match(), through
`%in%`, which can affect its performance significantly. By using
primitives instead of the rather expensive call to match(), I reduce
the time spent inside readBin() by more than 30% in some of my code
(part of the tr
in is present in eval.r. The code has been
> fairly well tested - I'm using it in my own implementation of a sweave
> like system.
>
> Hadley
>
> On Wed, Feb 4, 2009 at 6:59 AM, Jon Clayden wrote:
>> Dear all,
>>
>> For an open-source project that I'm
ded, or in an .Rprofile, then I should
never need to worry about whether a bit of code might generate
warnings and so should be wrapped.
Regards,
Jon
2009/2/4 Jeffrey Horner :
> Jon Clayden wrote on 02/04/2009 06:59 AM:
>>
>> Dear all,
>>
>> For an open-source project
Dear all,
For an open-source project that I'm working on (1), which uses R for
all its heavy lifting but includes a wrapper shell script, I was
hoping to find a way to capture all warnings (and, in fact, errors
too), and handle them in my own way. I realise I can do this for a
single expr
2008/9/25 Peter Dalgaard <[EMAIL PROTECTED]>:
> John Chambers wrote:
>>
>> My application, at least, wanted to show (my class) individual commands
>> from the file and then optionally insert some typed commands before going on
>> to the next part of the source file. As far as I can see, the piped s
>> John Chambers wrote:
>>
>>> For an alternative approach to your original goal, take a look at
>>> demoSource() in the SoDA package from CRAN. It's a bit tedious to set
>>> up (see the Details section of the help file) but uses standard R
>>> sess
Dear all,
I have asked before, in R-help [1], about a way to create an
interactive session in which commands are taken from a file or
standard input - like R CMD BATCH but additionally allowing user input
- but there was no response to that question, and the workarounds that
I have found
2008/4/28 Prof Brian Ripley <[EMAIL PROTECTED]>:
>
> On Mon, 28 Apr 2008, Jon Clayden wrote:
>
>
> > Hi,
> >
> > A piece of my code that uses readBin() to read a certain file type is
> > behaving strangely with R 2.7.0. This seems to be because of a
Apologies for missing out the sessionInfo():
R version 2.7.0 (2008-04-22)
i386-apple-darwin8.10.1
locale:
en_GB.UTF-8/en_US.UTF-8/C/C/en_GB.UTF-8/en_GB.UTF-8
attached base packages:
[1] stats graphics grDevices utils datasets methods base
2008/4/28 Jon Clayden <[EMAIL PROTEC
Hi,
A piece of my code that uses readBin() to read a certain file type is
behaving strangely with R 2.7.0. This seems to be because of a failure
to match() strings after using rawToChar() when the original was
terminated with a "\0" character. Direct equality testing with ==
still works as expecte
Dear all,
I'm trying to write an efficient binary file reader for a file type
that is made up of several fields of variable length, and so requires
many small reads. Doing this on the file directly using a sequence of
readBin() calls is a bit too slow for my needs, so I tried buffering
the file in
52 matches
Mail list logo