[Rd] possible bug with log of complex zero

[Richard . Cotton]

Notice that 

> log(0i)
[1] -Inf+0i

but

> log(0i, )
[1] -Inf+NaNi

To me, it seems that these should be the same value.  I'll record this on 
the bug tracker if you agree; otherwise please can someone explain why 
this is the case.

Regards,
Richie.

Mathematical Sciences Unit
HSL
4D Pie Charts



ATTENTION:

This message contains privileged and confidential inform...{{dropped:22}}

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

Re: [Rd] Unicode display problem with data frames under Windows

[Richard Cotton]

On 25 May 2015 at 19:43, Duncan Murdoch  wrote:
>> http://stackoverflow.com/questions/17715956/why-do-some-unicode-characters-display-in-matrices-but-not-data-frames-in-r

> Yes, but it is a bug, just a hard one to fix.  It needs someone to dedicate
> a serious amount of time to deal with it.
>
> Since most of the people who tend to do that generally use systems in UTF-8
> locales where this isn't a problem, or don't use Windows, it is languishing.

Thanks for the link and the explanation of why the bug exists.

>> On May 25, 2015 9:39 AM, "Richard Cotton"  wrote:
>>
>> > Here's a data frame with some Unicode symbols (set intersection and
>> > union).
>> >
>> > d <- data.frame(x = "A \u222a B \u2229 C")
>> >
>> > Printing this data frame under R 3.2.0 patched (r68378) and Windows 7, I
>> > see
>> >
>> > d
>> > ##  x
>> > ## 1 A  B n C

For future readers searching for a solution to this, you can get
correct printing by setting the CTYPE part of the locale to
Chinese/Japanese/Korean.

Sys.setlocale("LC_CTYPE", "Chinese")
## [1] "Chinese (Simplified)_People's Republic of China.936"

d
##x
## 1 A ∪ B ∩ C

-- 
Regards,
Richie

Learning R
4dpiecharts.com

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

[Rd] Are import-reexport-only packages allowed on CRAN?

[Richard Cotton]

One piece of feedback that I received at useR was that the assertive
package is getting too big, and should be broken down into smaller
pieces.

I want to split the functionality into assertive.base,
assertive.types, and a few others, then have the assertive package as
a virtual package (suggestions for better terminology welcomed) that
just imports and reexports the contents of the underlying pieces.

That way end-users can can still type library(assertive) and have the
same behaviour as before, and package developers who worry about
having lightweight dependencies can just use the parts that they need.

Before I do the refactoring, I wanted to check that it is OK to have a
package without any of its own content (other than vignettes) on CRAN.
Is it OK?

-- 
Regards,
Richie

Learning R
4dpiecharts.com

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

[Rd] Using IDs to suppress specific messages and warnings

[Richard Cotton]

The suppressMessages and suppressWarnings functions currently suppress
all the message or warnings that are generated by the input
expression.

The ability to suppress only specific messages or warnings is
sometimes useful, particularly for cases like file import where there
are lots of things that can go wrong.

Suppressing only messages that match a regular expression has rightly
been rejected as problematic due to non-portability across locales.
See, for example,

https://stat.ethz.ch/pipermail/r-devel/2012-October/065089.html

A better way of suppressing certain conditions would be to allow them
to have an identifier.  (This is how MATLAB allows control over
individual conditions.)

The implementation ought to be fairly simple.

simpleMessage, simpleWarning, and simpleError gain an id arg, which is
stored in their structure.

simpleMessage <- function (message, call = NULL, id = NULL)
{
  structure(
list(message = message, call = call, id = id),
class = c("simpleMessage", "message", "condition")
  )
}

I envisage IDs being strings, for example, the "NaN produced" warning
when you ask call, e.g., sqrt(-1) could have an ID of
"base:sqrt:nan_produced".

suppressMessage and suppressWarnings gain an ids arg, defaulting to
NULL, which preserves existing behaviour.  If it takes a character
vector, messages with the IDs provided get muffled.  Something like:

suppressMessages <- function (expr, ids = NULL)
{
  withCallingHandlers(
expr,
message = function(c)
{
   if(is.null(ids) || (inherits(c, "simpleMessage") && c$id %in%
as.character(ids)))
   {
 invokeRestart("muffleMessage")
   }
}
  )
}

The hard part is providing IDs for all the existing messages in R and
its packages.  It's certainly do-able, but I imagine would take quite
a lot of time.

Is there any enthusiasm for implementing this feature, or something like it?

-- 
Regards,
Richie

Learning R
4dpiecharts.com

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

Re: [Rd] Proposed change in file.exists() to tolerate Windows

[Richard Cotton]

Two solutions:

1. Use the wrapper function is_existing_file in assertive.

2. Use standardize_path in pathological before you call file.exists.



On 27 August 2015 at 17:02, Paul Johnson  wrote:
> I'm writing to ask if R Core would make file.exists more Windows
> tolerant when the argument has a trailing slash. This has been
> discussed by users a few times here, I know it is not a new topic. But
> it is not a solved problem, yet. I acknowledge that CRAN packages
> exist which fix this by replacing file.exists(), but it seems more
> elegant to me to fix the problem in R itself.
>
> R Core goes to great extremes to accommodate Windows users and the
> refusal to make file.exists() work in a cross-platform way is
> incongruous.
>
> I often do have slashes on the end of directory names being tested.
> Now that I understand the meaning of ?file.exists,  I need to wrap the
> name being checked in a slash-deleter
>
> ## delete trailing slashes
> dts <- function(name) gsub("/$", "", name)
> if(!file.exists(dts(any_name))) { ...
>
> Can't you make file.exists do this invisibly? Maybe the argument could
> be filtered through normalizePath() instead.
>
> If not, would you please consider putting a workaround like mine into
> the file.exists documentation so Windows users can see how easy this
> is to avoid?
>
> Respectfully yours,
>
> pj
>
> --
> Paul E. Johnson
> Professor, Political ScienceDirector
> 1541 Lilac Lane, Room 504  Center for Research Methods
> University of Kansas University of Kansas
> http://pj.freefaculty.org  http://crmda.ku.edu
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel



-- 
Regards,
Richie

Learning R
4dpiecharts.com

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

Re: [Rd] Using IDs to suppress specific messages and warnings

[Richard Cotton]

Thanks Luke,

On 10 September 2015 at 14:47,   wrote:
> Conditions have classes and the condition system is designed around
> the idea that classes would be used for this sort of thing. That is
> already how tryCatch and withCallingHandlers discriminate the
> conditions to handle.

That makes sense.  Though with my sqrt example, it's just a plain
simpleWarning, which doesn't give you the opportunity to do special
handling.

tryCatch(sqrt(-1), warning = function(w) class(w))
## [1] "simpleWarning" "warning"   "condition"


> Designing and implementing a condition class hierarchy to support this
> is indeed the hard/tedious part.

There are precedents from other languages that could be used as a
template.  For example, .NET and Java both have very well defined
exception hierarchies that could serve as a starting point.

https://msdn.microsoft.com/en-us/library/z4c5tckx%28v=vs.110%29.aspx
https://docs.oracle.com/javase/7/docs/api/java/lang/package-tree.html

Who is the best person to ask/cajole to start getting this implemented?

-- 
Regards,
Richie

Learning R
4dpiecharts.com

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

[Rd] Differences in printing UTF-8 strings to stdout vs. stderr under Windows

[Richard Cotton]

It seems that under Windows, some UTF-8 strings that print OK to
stdout do not print correctly to stderr.  To reproduce:

x <- "\ub124"
cat(x, file = stdout())
## 네
cat(x, file = stderr())
## 

Original motivating problem here:
https://stackoverflow.com/questions/32696241/how-to-display-a-message-warning-error-with-unicode-characters-under-windows

How does printing to stderr differ from printing to stdout?

And more importantly, is there any way I can ensure correct printing
of Unicode characters when I need to write to stderr (when throwing
errors or warnings)?

-- 
Regards,
Richie

Learning R
4dpiecharts.com

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

[Rd] PDFs and SVGs containing rasterGrobs don't display correctly in some other software

[Richard Cotton]

I've just been trying to post-process some R-created heatmaps using
Inkscape, but I can't get them to display correctly in that software.

To reproduce:

library(grid)
r <- as.raster(matrix(runif(25), 5, 5))
pdf("test.pdf")
grid.newpage()
grid.raster(r, interpolate = FALSE)
dev.off()

This figure should be a five by five block of grey squares.  This is
what I see in the R GUI device window, and when I open test.pdf in
Abode Reader or SumatraPDF.

However, when I open the file in Inkscape or Firefox, each of the
squares is blurred.

I tried swapping grDevices::pdf for Cairo::CairoPDF and got the same
result.  I also tried generating SVGs using both grDevices::svg and
Cairo::CairoSVG, and also got the same result.

I see the same thing using R-devel and R3.2.2 under Windows, and (with
an older version of R) under Linux.

I don't know whether the problem is with grid's rasterGrobs, or how R
writes PDF and SVG files, or with Inkscape and Firefox's method of
rendering those files, or with me.  Please can you help me narrow it
down.

- Can you reproduce my problem?  That is, when you run the above code,
does the file look OK in a PDF reader but blurry in Inkscape?
- Do you know of any issues with using rasterGrobs in PDFs or SVGs?

-- 
Regards,
Richie

Learning R
4dpiecharts.com

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

Re: [Rd] Best way to implement optional functions?

[Richard Cotton]

On 22 October 2015 at 22:55, Duncan Murdoch  wrote:
> I'm planning on adding some new WebGL functionality to the rgl package, but
> it will pull in a very large number of dependencies. Since many people won't
> need it, I'd like to make the new parts optional.

> Can people suggest other packages that solve this kind of problem in a good
> way?

I had the same issue with the assertive package: it was getting big,
and not everyone wanted all the functionality.

The solution was to create several smaller packages with individual
components of functionality, for example assertive.base contains the
bare-minimum functionality; assertive.numbers contains functionality
related to numbers, etc.

Then the assertive package imports all the functions from the
component packages and reexports them.

That way people who want a small footprint (mostly other package
developers) can specify only what they need, and people who don't care
(mostly end users) can just type library(assertive) and get access to
everything.

-- 
Regards,
Richie

Learning R
4dpiecharts.com

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

Re: [Rd] Best way to implement optional functions?

[Richard Cotton]

Yes, you do need at least a token about of documentation in both
packages.  I keep full documentation in the package where they
originate, and minimal documentation in the rexporting package.  The
roxygen code in the reexporting package looks like this:

#' Some function
#'
#' See \code{\link[originating_pkg]{some_function}}.
#' @name some_function
#' @export
NULL

I borrowed this idea from dplyr's reexporting of magrittr's pipe.

On 17 November 2015 at 00:02, Duncan Murdoch  wrote:
> On 16/11/2015 4:00 AM, Richard Cotton wrote:
>>
>> On 22 October 2015 at 22:55, Duncan Murdoch 
>> wrote:
>>>
>>> I'm planning on adding some new WebGL functionality to the rgl package,
>>> but
>>> it will pull in a very large number of dependencies. Since many people
>>> won't
>>> need it, I'd like to make the new parts optional.
>>
>>
>>> Can people suggest other packages that solve this kind of problem in a
>>> good
>>> way?
>>
>>
>> I had the same issue with the assertive package: it was getting big,
>> and not everyone wanted all the functionality.
>>
>> The solution was to create several smaller packages with individual
>> components of functionality, for example assertive.base contains the
>> bare-minimum functionality; assertive.numbers contains functionality
>> related to numbers, etc.
>>
>> Then the assertive package imports all the functions from the
>> component packages and reexports them.
>>
>> That way people who want a small footprint (mostly other package
>> developers) can specify only what they need, and people who don't care
>> (mostly end users) can just type library(assertive) and get access to
>> everything.
>>
>
> When you import and re-export functions, do they need to be documented in
> both places?  I forget if we have a simple way to say "this function is
> documented in that package", to avoid duplication.
>
> Duncan Murdoch



-- 
Regards,
Richie

Learning R
4dpiecharts.com

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

[Rd] capturing warnings using capture.output

[Richard Cotton]

>From the Details section of ?capture.output:

Messages sent to stderr() (including those from message, warning and stop)
are captured by type = "message". Note that this can be "unsafe" and should
only be used with care.

Capturing messages works as expected:

capture.output(message("!!!"), type = "message")
## [1] "!!!"

Capturing warnings doesn't seems to work:

capture.output(warning("!!!"), type = "message")
## character(0)
## Warning message:
## In eval(expr, envir, enclos) : !!!

Is the documentation wrong, or is this a bug, or am I doing doing silly?

-- 
Regards,
Richie

Learning R
4dpiecharts.com

[[alternative HTML version deleted]]

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

[Rd] Too many spaces in deparsed complex numbers with digits17 control option

[Richard Cotton]

If you set the "digits17" control option in deparse, you get a lot of
unnecessary space in the representation of complex numbers.

> deparse(0 + 0i)
[1] "0+0i"
> deparse(0 + 0i, control = "digits17")
[1] "0 + 0i"

As far as I can tell, the logic for this comes from this piece of
/src/main/deparse.c:

if (TYPEOF(vector) == CPLXSXP && (d->opts & DIGITS16)) {
  Rcomplex z =  COMPLEX(vector)[i];
  if (R_FINITE(z.r) && R_FINITE(z.i)) {
  snprintf(hex, 64, "%.17g + %17gi", z.r, z.i);
  strp = hex;
  } else
  strp = EncodeElement(vector, i, quote, '.');
}

I think this is a small bug, and that "%17gi" in the snprintf call
ought to be "%.17gi".

Also there shouldn't be any space around the plus sign for consistency
with the non-digits17 option.

Is this a real bug, or is it deliberate behaviour?

-- 
Regards,
Richie

Learning R
4dpiecharts.com

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

Re: [Rd] Is it possible to retrieve the last error? (not error *message*)

[Richard Cotton]

I wondered the same thing a few days ago.

https://stackoverflow.com/questions/36966036/how-to-get-the-last-error

The here's the solution from that discussion:

get_last_error <- function()
{
  tr <- .traceback()
  if(length(tr) == 0)
  {
return(NULL)
  }
  tryCatch(eval(parse(text = tr[[1]])), error = identity)
}

Note that it uses .traceback() from R 3.3.0; you'll have to use
baseenv()$.Traceback with earlier version of R.

On 4 May 2016 at 22:41, Henrik Bengtsson  wrote:
> Hi,
>
> at the R prompt, is it possible to retrieve the last error (as in
> condition object of class "error")?
>
> I'm not asking for geterrmessage(), which only returns the error
> message (as a character string).  I'm basically looking for a
> .Last.error or .Last.condition, analogously to .Last.value for values,
> which can be used when it is "too late" (not possible) to go back an
> use try()/tryCatch().
>
> Thanks,
>
> Henrik
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel



-- 
Regards,
Richie

Learning R
4dpiecharts.com

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

[Rd] using with inside loop breaks next

[Richard Cotton]

If I want to use with inside a loop, it seems that next gets confused.
To reproduce:

for(lst in list(list(a = 1), list(a = 2), list(a = 3)))
{
  with(lst, if(a == 2) next else print(a))
}

I expect 1 and 3 to be printed, but I see

[1] 1
 Error in eval(expr, envir, enclos) :
  no loop for break/next, jumping to top level

Is this
a) by design, or
b) a bug, or
c) a thing that is rare enough that I should just rewrite my code?

-- 
Regards,
Richie

Learning R
4dpiecharts.com

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

Re: [Rd] improve 'package not installed' load errors?

[Richard Cotton]

> A side question, which I do not know the answer to, is how users get 
> themselves into this state.

I've fallen over this a few times.  It happens when you have multiple
R sessions running, and R tries to update Rcpp while it is loaded in
the other session.

For example, I'm working on one project, then I open another copy of R
to work on a different project.  Because I have update.packages in my
Rprofile, R occasionally tries to update Rcpp.  If that is loaded in
the first session, then a clean uninstall doesn't happen (the
directory and the dll are left).  Since the directory is still there,
update.packages thinks that the package exists, and I'm left with a
mangled copy of Rcpp that I need to manually remove.

On 24 October 2016 at 20:51, Kevin Ushey  wrote:
> Hi R-devel,
>
> One of the more common issues that new R users see, and become stumped
> by, is error messages during package load of the form:
>
>> library(ggplot2)
> Error in loadNamespace(j <- i[[1L]], c(lib.loc, .libPaths()),
> versionCheck = vI[[j]]) :
>   there is no package called 'Rcpp'
> Error: package or namespace load failed for 'ggplot2'
>
> Typically, error messages of this form are caused simply by one or
> more dependent packages (in this case, 'Rcpp') not being installed or
> available on the current library paths. (A side question, which I do
> not know the answer to, is how users get themselves into this state.)
>
> I believe it would be helpful for new users if the error message
> reported here was a bit more direct, e.g.
>
>> library(ggplot2)
> Error: 'ggplot2' depends on package 'Rcpp', but 'Rcpp' is not installed
> consider installing 'Rcpp' with install.packages("Rcpp")
>
> In other words, it might be helpful to avoid printing the
> 'loadNamespace()' call on error (since it's mostly just scary /
> uninformative), and check up-front that the package is installed
> before attempting to call 'loadNamespace()'. I'm sure a number of
> novice users will still just throw their hands up in the air and say
> "I don't know what to do", but I think this would help steer a number
> of users in the right direction.
>
> (The prescription to suggest installing a package from CRAN if
> available might be a step too far, but I think making it more clear
> that the error is due to a missing dependent package would help.)
>
> Any thoughts?
> Kevin
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel



-- 
Regards,
Richie

Learning R
4dpiecharts.com

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

[Rd] S3 dispatch for primitive generics

[Richard Cotton]

I seem to recall reading that for primitive generics, S3 will dispatch
on class first, then on mode.  Unfortunately, I can't find the place
that I read this, and I don't trust my memory.

1) Is this correct?  Or is it dispatch on class, then on typeof? Or
something else?

2) Where is this documented?

-- 
Regards,
Richie

Learning R
4dpiecharts.com

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

[Rd] .S4methods inconsistent behavior with methods, .S3methods

[Richard Cotton]

If I call

.S4methods(sd)

I get the error

## Error in getGeneric(generic.function) :
##   argument 'f' must be a string, generic function, or primitive:
got an ordinary function

By contrast, methods and .S3methods just state that no methods are found.

methods(sd)
## no methods found
S3methods(sd)
## no methods found

It seems like the behavior of these functions ought to be consistent.

Maybe they should split the difference and say no methods are found,
but warn the the input is not generic?

-- 
Regards,
Richie

Learning R
4dpiecharts.com

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

[Rd] R-ints Argument Evaluation has out of date examples

[Richard Cotton]

In R-ints section 1.5

https://cran.r-project.org/doc/manuals/r-devel/R-ints.html#Argument-evaluation

it states

> Note that being a special/builtin is separate from being primitive
> or .Internal: quote is a special primitive, + is a builtin primitive,
> cbind is a special .Internal and grep is a builtin .Internal.

I think that the examples of cbind and grep might be out of date since
these both appear to be closures now.

typeof(cbind)
## "closure"
typeof(grep)
## "closure"

In fact, as far as I can tell, all the special and builtin functions
now use the primitive interface.  The following code returns an empty
list in R 3.3.2:

e <- as.environment("package:base")
vars <- mget(ls(e), e)
Filter(
  function(x) {
typeof(x) %in% c("special", "builtin") && Negate(is.primitive)(x)
  },
  vars
)

Is it true to say that "being a special/builtin is separate from being
primitive on .Internal, however in practice all special and builtin
functions are primitive"?

-- 
Regards,
Richie

Learning R
4dpiecharts.com

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

[Rd] A rep_each function

[Richard Cotton]

The rep function is very versatile, but that versatility comes at a
cost: it takes a bit of effort to learn (and remember) its syntax.
This is a problem, since rep is one of the first functions many
beginners will come across.  Of the three main uses of rep, two have
simpler alternatives.

rep(x, times = ) has rep.int
rep(x, length.out  = ) has rep_len

I think that a rep_each function would be a worthy addition for the
third use case

rep(x, each = )

(It might also be worth having rep_times as a synonym for rep.int.)

While this could go in a package, since one of its main benefits is to
help beginners, I feel it ought to go in base R.

Before I submit this as a feature request, I thought I'd check here to
see if there was any enthusiasm.  Does rep_len sound useful to you?

-- 
Regards,
Richie

Learning R 
4dpiecharts.com

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

[Rd] --vanilla option for creating cluster nodes

[Richard Cotton]

When a PSOCK cluster (maybe other cluster types too) is created by the
parallel package, an Rscript process is spawned for each node.  At
least by default, the Rprofile.site file is read for each node that is
created, which can constitute the majority of the time to create a
cluster.  See:

http://stackoverflow.com/q/23540129/134830

Is there a way to create nodes using the --vanilla argument, so that
Rprofile doesn't get read?

Alternatively, is there a way to persuade R to only read the file
once?  It seems inefficient to do the same thing four times.

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

[Rd] Is using devtools::release no longer allowed?

[Richard Cotton]

I recently tried to submit a package to CRAN using the release
function in the devtools package and got the response:

> The policies asked you to use the webform: do so in future.

I think that the relevant line in the policies are:

> When submitting a package to CRAN you should use the submission form at
> http://CRAN.R-project.org/submit.html (and not send an email). You will be 
> sent
> a confirmation email which needs to be accepted.

> If this fails, upload by anonymous ftp to ftp://CRAN.R-project.org/incoming/ 
> and
> send a (plain text ASCII) email at the same time, with subject line as 
> specified below.

As far as I know, the release function uses the second method, so I
don't quite understand what the problem is.

Has that method of submission been banned?

-- 
Regards,
Richie

Learning R
4dpiecharts.com

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

[Rd] The behaviour of setting names differs between lists and atomic vectors

[Richard Cotton]

If you set the names in a list, some cat-style processing seems to
happen.  For example, backslashes are modified.  This behaviour
doesn't happen with atomic vectors.  Compare, for example:

setNames(1, "a\\b")
## a\\b
##   1
setNames(list(1), "a\\b")
## $`a\b`
## [1] 1

Notice that the name of the element in the list has been changed to
'a', 'backspace'.

Is this behaviour intended, or a bug?

-- 
Regards,
Richie

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

[Rd] normalizePath is sometimes very slow for nonexistent UNC paths

[Richard Cotton]

I'm having an issue with occasionally slow-running calls to
normalizePath.  If the path is a non-existent UNC path, then
normalizePath sometimes takes 6 or 7 seconds to run, rather than its
usual few microseconds.  My big problem is that I can't reliably
reproduce this across machines.

The example below generates one or two slow runs out of 1 on my
Windows machine. I haven't been able to generate slow runs on my Linux
machine, though I've had problems with slow running examples submitted
to CRAN that I suspect may be caused by this.

library(microbenchmark)
(timings <- microbenchmark(
  normalizePath("some/network/drive", mustWork = FALSE),
  times = 1e4,
  unit  = "s"
))
boxplot(timings)

Please can a few people run this code and see if they can reproduce the issue.

It isn't clear to me whether this is a bug in R or an underlying OS or
network problem.

-- 
Regards,
Richie

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

[Rd] \U with more than 4 digits returns the wrong character

[Richard Cotton]

If I type a character using \U syntax that has more than 4 digits, I
get the wrong character.  For example,

"\U1d4d0"

should print a mathematical bold script capital A.  See
http://www.fileformat.info/info/unicode/char/1d4d0/index.htm

On my machine, it prints the Hangul character corresponding to

"\Ud4d0"
http://www.fileformat.info/info/unicode/char/d4d0/index.htm

It seems that the hex-digit part is overflowing at 16^4.

I tested this on R3.1.2 and devel (2014-12-03 r67101) x64 under
Windows.  I played around with Sys.setlocale and options("encoding"),
but couldn't get the expected value.

Can others reproduce this?  It feels like a bug, but experience tells
me I probably have something silly going on with my setup.

-- 
Regards,
Richie

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

Re: [Rd] \U with more than 4 digits returns the wrong character

[Richard Cotton]

Great spot, thanks Mark.

This really ought to appear somewhere in the ?Quotes help page.

Having a warning under Windows might be nicer behaviour than silently
returning the wrong value too.

On 4 December 2014 at 22:24, Mark van der Loo  wrote:
> Richie,
>
> The R language definition [1] says (10.3.1):
>
> \U \U{}
> (where multibyte locales are supported and not on Windows, otherwise
> an error). Unicode character with given hex code – sequences of up to
> eight hex digits.
>
>
> Best,
> Mark
>
> [1] http://cran.r-project.org/doc/manuals/r-release/R-lang.html
> http://www.markvanderloo.eu
> ---
> If you cannot quantify it,
> you don't know what you're talking about
>
>
> On Thu, Dec 4, 2014 at 8:00 PM, Richard Cotton  wrote:
>> If I type a character using \U syntax that has more than 4 digits, I
>> get the wrong character.  For example,
>>
>> "\U1d4d0"
>>
>> should print a mathematical bold script capital A.  See
>> http://www.fileformat.info/info/unicode/char/1d4d0/index.htm
>>
>> On my machine, it prints the Hangul character corresponding to
>>
>> "\Ud4d0"
>> http://www.fileformat.info/info/unicode/char/d4d0/index.htm
>>
>> It seems that the hex-digit part is overflowing at 16^4.
>>
>> I tested this on R3.1.2 and devel (2014-12-03 r67101) x64 under
>> Windows.  I played around with Sys.setlocale and options("encoding"),
>> but couldn't get the expected value.
>>
>> Can others reproduce this?  It feels like a bug, but experience tells
>> me I probably have something silly going on with my setup.
>>
>> --
>> Regards,
>> Richie
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel



-- 
Regards,
Richie

Learning R
4dpiecharts.com

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

[Rd] update.packages with ask = FALSE will sometimes ask about updates

[Richard Cotton]

Today while running update.packages(ask = FALSE), R stopped to ask me
a question:

  There are binary versions available but the source versions are later:
binary  source needs_compilation
KernSmooth 2.23-13 2.23-14  TRUE
mixture1.2 1.3  TRUE

Do you want to install from sources the packages which need compilation?
y/n:


update.packages calls install.packages which calls getDependencies,
which was where there question originated.

It seems to me that if I've set ask = FALSE, stopping to ask questions
is a bug.  There are a few possible interpretations of the best
behaviour though, so I thought I'd put it up for discussion here
before (maybe) submitting as a bug.

1. The existing behaviour is correct: the case of out-of-date binaries
causes a special situation, and R is right to ask.

2. ask = FALSE means I want all updates, so don't ask me any
questions, just install all possible updates.

3. ask = FALSE means that I don't want any interactivity, but
out-of-date binaries is a special case, so R should just fail to
update these packages, with an error message stating that they need to
be manually updated.

4. There should be an extra argument that decides between the some or
all of the behaviours described in 1, 2 and 3.

Which of these options is best?  (Or have I missed an option?)

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

Re: [Rd] update.packages with ask = FALSE will sometimes ask about updates

[Richard Cotton]

On 13 February 2015 at 10:11, Prof Brian Ripley  wrote:
> On 11/02/2015 10:46, Richard Cotton wrote:
>
> The 'at a minimum' information required by the posting guide is conspicuous
> by its absence.
>
> At a guess, this is R-devel and Windows.

What I'm running doesn't matter if I'm asking for general opinion on
the best behaviour.  It has to work for everyone.

> He missed the documented options (and the NEWS items, the posting guide
> ...).

All this is irrelevant.  Whatever my OS, and whatever the documented
options are, if I explicitly say I don't want interactive behaviour by
specifying ask = FALSE, then R stopping to ask me things feels like
incorrect behaviour.



Since there seems to be resistance to making any changes to the
behaviour, for future readers, the solution that has been suggested to
me to ensure that you don't get asked any questions is:

Make sure you can compile packages (on Windows this involves
installing Rtools).  Then explicitly set type = "source" when you use
ask = FALSE.

update.packages(ask = FALSE, type = "source")

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

[Rd] Possible values for R version status

[Richard Cotton]

Is there a complete list somewhere of the possible values for R's
status, as returned by version$status?

I know about these values:
Stable: ""
Devel: "Under development (unstable)"
Patched: "Patched"
Release candidate: "RC"
Alpha: "Alpha"

Are there any others that I've missed?

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

Re: [Rd] Possible values for R version status

[Richard Cotton]

Thanks for this.  You are right that it's a lowercase "a"; the
documentation on the R.Version help page is incorrect.  That describes
status as 'the status of the version (e.g., "Alpha")'.

On 23 March 2015 at 16:36, Duncan Murdoch  wrote:
> On 23/03/2015 9:17 AM, Richard Cotton wrote:
>>
>> Is there a complete list somewhere of the possible values for R's
>> status, as returned by version$status?
>>
>> I know about these values:
>> Stable: ""
>> Devel: "Under development (unstable)"
>> Patched: "Patched"
>> Release candidate: "RC"
>> Alpha: "Alpha"
>
>
> I don't think we use "Alpha", I think it's lowercase.  There is also "beta".
> You can see the list at
> http://developer.r-project.org/release-checklist.html, in the lines that
> describe the version being set.
>
> Duncan Murdoch



-- 
Regards,
Richie

Learning R
4dpiecharts.com

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

[Rd] Unicode display problem with data frames under Windows

[Richard Cotton]

Here's a data frame with some Unicode symbols (set intersection and union).

d <- data.frame(x = "A \u222a B \u2229 C")

Printing this data frame under R 3.2.0 patched (r68378) and Windows 7, I see

d
##  x
## 1 A  B n C

Printing the column itself works fine.

d$x
## [1] A ∪ B ∩ C
## Levels: A ∪ B ∩ C

The encoding is correctly UTF-8.

Encoding(as.character(d$x))
## [1] "UTF-8"

Under Linux both forms of printing are fine for me.

I'm not quite sure whether I've missed a setting or if this is a bug, so

Am I doing something silly?
Can anyone else reproduce this?

-- 
Regards,
Richie

Learning R
4dpiecharts.com

[[alternative HTML version deleted]]

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

[Rd] Speed issue when writing to RGui console from tcl/tk GUI

[Richard Cotton]

It seems that there are speed issues when printing to the R console from a
tcl/tk GUI.

Here are functions to write a lot of output, and to display how long it
takes.

printsalot <- function(n)
{
  for(i in 1:n) cat(i, fill = TRUE)
}

timings <- function(n = 1e3)
{
  print(system.time(printsalot(n)))
}

Calling timings() from the console reveals a run time of a few hundredths
of a second.

The following GUI has two buttons.  Clicking the "slow" buttons just calls
timings directly, and takes several seconds to run.  However, if we request
input from the console, via readline (the "fast" button) then the timing
drops back down to hundredths of a second.

library(tcltk)
win <- tktoplevel()
btn1 <- ttkbutton(win, text = "slow", command = function() timings())
btn2 <- ttkbutton(win, text = "fast", command = function() {readline("Press
ENTER > "); timings()})
tkpack(btn1, btn2)

I've only observed this slow behaviour with RGui on Windows (XP) - it
doesn't happen with Rterminal or eclipse/StatET or RStudio.

I want a few people to run this code to see if it affects, for example,
other OSes, to narrow down the extent of the problem before I submit it as
a bug.

Also, if you have any insight as to what is happening or fixes, I'd be
interested to know.

Regards,
Richie.

[[alternative HTML version deleted]]

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

[Rd] .Internal(inspect(x)) gives overly verbose output for reference classes

[Richard Cotton]

Even for an extremely simple instance of a reference class

x <- setRefClass("x")
y <- x$new()

calling the internal inspect function

.Internal(inspect(y))

produces enough output that it takes several minutes to print to the
console.  (Actually I gave up and terminated the command after ~10
mins.  It isn't clear whether the output would eventually complete.)

Are reference classes really so complicated inside, or is this a bug?

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

[Rd] Why is there no within.environment function?

[Richard Cotton]

If I want to assign some variables into an environment, it seems
natural to do something like

e <- new.env()
within(e,
{
  x <- 1:5
  y <- runif(5)
}
)

This throws an error, since within.environment doesn't exist.  I
realise I can work around it using

as.environment(within(as.list(e),
{
  x <- 1:5
  y <- runif(5)
}
))

Just wondering why I can't use within directly with environments.

--
4dpiecharts.com

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

[Rd] Codoc mismatch for roxygen-documented foo<- functions

[Richard Cotton]

I have a roxygen2 documented package with functions for getting and
setting an attribute.

#' Get or set the foo attribute.
#'
#' Dummy function!
#'
#' @param x Object to hold the attribute.
#' @param value Value to set the attribute to.
#' @return The get function returns the "foo" attribute of \code{x}.
#' @export
foo <- function(x)
{
  attr(x, "foo")
}

#' @rdname foo
#' @export
`foo<-` <- function(x, value)
{
  attr(x, "foo") <- value
}

If I save the above to foo.R and then do

library(roxygen2)
library(devtools)
package.skeleton("foo", code_files="foo.R")
roxygenize("foo")
check("foo")

then the package checker gives me the warning

Codoc mismatches from documentation object 'foo':
foo<-
  Code: function(x, value)
  Docs: function(x, value, value)

How should I be documenting this sort of setter function?

--
Regards,
Richie

live-analytics.com
4dpiecharts.com

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

Re: [Rd] Expected behaviour of is.unsorted?

[Richard Cotton]

>> is.unsorted(data.frame(1:2))
> [1] FALSE
>> is.unsorted(data.frame(2:1))
> [1] FALSE
>> is.unsorted(data.frame(1:2,3:4))
> [1] TRUE
>> is.unsorted(data.frame(2:1,4:3))
> [1] TRUE
>
> IIUC, is.unsorted is intended for atomic vectors only (description of x in
> ?is.unsorted). Indeed the C source (src/main/sort.c) contains an error
> message "only atomic vectors can be tested to be sorted". So that is the
> error message I expected to see in all cases above, since I know that
> data.frame is not an atomic vector. But there is also this in
> ?is.unsorted: "except for atomic vectors and objects with a class (where
> the >= or > method is used)" which I don't understand. Where >= or > is
> used by what, and where?
>
> I understand why the first two are FALSE (1 item of anything must be
> sorted). I don't understand the 3rd and 4th cases where length is 2:
> do_isunsorted seems to call lang3(install(".gtn"), x, CADR(args))). Does
> that fall back to TRUE for some reason?

I've just been having similar worries with this today.  The odd
behaviour seems to be particular to data.frames.  Compare for example,

is.unsorted(list(1, 3, 2))  #NA
is.unsorted(data.frame(1, 3, 2)) #FALSE
is.unsorted(data.frame(1, 2, 3)) #TRUE

IMHO, it would be clearer if is.unsorted either always returned NA for
recursive objects of length 2 or more, or it called unlist to make it
atomic.  Either way, it should really provide some sort of warning
about non-standard input.

-- 
Regards,
Richie

live-analytics.com
4dpiecharts.com

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

[Rd] How deep can/should lists be nested?

[Richard Cotton]

I started idly wondering how deeply lists could be nested, and
couldn't find an explicit limit in the documentation.  With this
simple test

a_list <- list()
count <- 0
repeat
{
  a_list[[1]] <- a_list
  count <- count + 1
}

my (Win7, R-2.16.0 devel) machine threw an error when count got close to 25000.

The error that stopped it was

Error: protect(): protection stack overflow

I don't know how easy it would be to stop such an error occuring, and
it probably isn't that useful to be able to nest lists any further.  I
do think it might be useful for users to be able to know how deeply
they can nest lists though.

Perhaps it would be better to limit nesting to the value of
getOption("expressions").  Does anyone have any strong feelings on
what the correct behaviour should be?

--
Regards,
Richie

live-analytics.com
4dpiecharts.com

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

Re: [Rd] How deep can/should lists be nested?

[Richard Cotton]

I agree that real-world uses of nesting this deep are rare enough to
not worry about fixing code (unless there is something extremely
trivial that can done).

My main concern is that it doesn't seem to be documented how much
nesting is possible, and I couldn't even guess the order of magnitude
without trying it.

This was why I thought setting the value to getOption("expressions")
might be beneficial - at least the user knows when they have to stop.
The simpler alternative may just be to add a line to the documentation
to say something like "although lists can theoretically be nested
indefinitely, in practice allocation is limited by memory and stack
size, typically to tens of thousands of levels".

The obvious place to put such a message would be in ?list, though at
the moment there are no nesting examples on the page.

On 14 October 2012 13:39, Prof Brian Ripley  wrote:
> On 14/10/2012 12:53, Duncan Murdoch wrote:
>>
>> On 12-10-14 7:06 AM, Richard Cotton wrote:
>>>
>>> I started idly wondering how deeply lists could be nested, and
>>> couldn't find an explicit limit in the documentation.  With this
>>> simple test
>>>
>>> a_list <- list()
>>> count <- 0
>>> repeat
>>> {
>>>a_list[[1]] <- a_list
>>>count <- count + 1
>>> }
>>>
>>> my (Win7, R-2.16.0 devel) machine threw an error when count got close
>>> to 25000.
>>>
>>> The error that stopped it was
>>>
>>> Error: protect(): protection stack overflow
>>>
>>> I don't know how easy it would be to stop such an error occuring, and
>>> it probably isn't that useful to be able to nest lists any further.  I
>>> do think it might be useful for users to be able to know how deeply
>>> they can nest lists though.
>>>
>>> Perhaps it would be better to limit nesting to the value of
>>> getOption("expressions").  Does anyone have any strong feelings on
>>> what the correct behaviour should be?
>>
>>
>> There should be no limit other than memory.  That overflow you saw is a
>> bug.  Not sure it's worth fixing, since 25000 is far beyond any sensible
>> nesting level, but I'll take a look.
>
>
> I'm not so sure it is a bug.  There have to be limits other than the total
> amount of memory (the C stack size is another one): one was reached and the
> computation was stopped cleanly.  We even allow the size of the ppstack to
> be changed in the extremely rare cases where this might matter.
>
> But the real point is that that limit is not on the nesting of lists but on
> that particular way to create a deeply nested list.  We know that some code
> to copy lists is sub-optimal, but we've not been shown a real-world example
> where it mattered enough to prioritize looking into.
>
>>
>> Duncan Murdoch
>
>
>
> --
> Brian D. Ripley,  rip...@stats.ox.ac.uk
> Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
> University of Oxford, Tel:  +44 1865 272861 (self)
> 1 South Parks Road, +44 1865 272866 (PA)
> Oxford OX1 3TG, UKFax:  +44 1865 272595



-- 
Regards,
Richie

live-analytics.com
4dpiecharts.com

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

Re: [Rd] Colour Schemes

[Richard . Cotton]

> I've been thinking hard about generating colour schemes for data.
> There's quite a bit of existing code scattered in various packages for
> playing with colours and colour palettes, but I can't find the sort of
> thing I'm after for applying colours to data...
> 
> To my mind a colour scheme is a mapping from data values to colours.
> There's a multitude of such mappings depending on the nature of the
> data. For example, for a factor you might want to map levels to unique
> colours. For numbers that run from -4 to +2 you might want to use a
> diverging colour palette centred on zero. This might be continuous in
> some colour space or composed of a small number of discrete colours,
> each of which covers a range of values. Or it could be piecewise
> continuous as used in topographic maps - less than zero is blue, zero
> to 400 goes from sandy yellow to grassy green, 400 to 1000 goes from
> grassy green to rocky brown, then suddenly you hit the ice and 1000
> and upwards is white.  Or you could have a multivariate mapping where
> (x,y,z) -> (r,g,b,a) in complex and non-linear ways.
> 
> I see a set of factory functions that return colour scheme mapping
> functions that map data to colours, so you'd do:
> 
>  # unique colour for each factor level
>  scheme1 = exactColours(data$f,someColours)  # data$f is a factor,
> someColours is a vector of colour values
>  plot(data$x,data$y,col=scheme1(data$f))
> 
>  # topological map colouring
>  scheme2 = continuousColours(list(-1000,"blue",0,"sandYellow",
> 400,"grassGreen",1000,"rockBrown",1000,"white",1))
> # or something...
>  plot(data$x,data$y,col=scheme2(data$height))
> 
> Now just because I can't find existing functions like this doesn't
> mean they don't exist. There's stuff in plotrix, colorspace,
> RColorBrewer etc for creating palettes but then the user is left to
> their own devices to map colours to data values.
> 
>  Does this kind of thing sound useful? Has it been done? Is it worth
> doing? Anybody got any better ideas?

Most of the plots where colour is typically used to signify a variable 
already do map colours to data values.  Take a look at help pages for 
levelplot/contourplot/wireframe from the lattice package, and image from 
base graphics.

(The format is typically slightly different to your suggested 
specification, though the principle is the same.  The functions take a 
vector of cut points, and a vector of colours.)

There may be some utility in creating functions to generate these colour 
maps outside of the plotting functions, if only so that the code can be 
recycled for new functions.

Regards,
Richie.

Mathematical Sciences Unit
HSL




ATTENTION:

This message contains privileged and confidential inform...{{dropped:20}}

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

Re: [Rd] Colour Schemes

[Richard . Cotton]

I'm going to take your second example first.

>  The base graphics "image" function has zlim arguments which let you do:
> 
>  z=outer(1:10,1:10,"*")
>  image(z)
>  image(z/2, zlim=range(z))
> 
>  but again, not obvious, and complex/impossible when using more
> sophisticated colour mappings.

The way to do more complex examples, similar to the manner you suggested 
originally, is use the breaks and col arguments, e.g.

breaks <- c(0,25,75,100)
col <- c("red", "blue", "green")
image(z, breaks=breaks, col=col)
image(z/2, breaks=breaks, col=col)

So it is possible here, though perhaps not obvious.

With your first example ...
>  The problem here is that the user doesn't have exact control of the
> mapping from value to colour. For example (using a slightly more
> safe-for-use-after-lunch version of the levelplot example grid):
> 
>  x <- seq(pi/4, 5 * pi, length.out = 100)
>  y <- seq(pi/4, 5 * pi, length.out = 100)
>  r <- as.vector(sqrt(outer(x^2, y^2, "+")))
>  grid <- expand.grid(x=x, y=y)
>  grid$z <- r
>  grid$z2 = r *0.5
> 
> 
> Then I do:
> 
>   levelplot(z~x*y, grid, cuts = 5, col.regions=rainbow(5))
> 
>  very nice, but suppose I want to show $r2 on the same colour scale, I
> can't just do:
> 
>  levelplot(z2~x*y, grid, cuts = 5, col.regions=rainbow(5))
> 
>  because that looks the same as the first one since levelplot uses the
> whole colour range.

... I agree that the inability to specify a vector of cut points ruins 
your chances of doing what you want.

> > There may be some utility in creating functions to generate these 
colour
> > maps outside of the plotting functions, if only so that the code can 
be
> > recycled for new functions.
> 
>  Exactly, it would make a new package.

Excellent.  I reckon keeping the cut vector/colour vector input format 
would be sensible, e.g.

continuousColours <- function(x, breaks, col)
{
   if(length(breaks) != length(col)+1) stop("must have one more break than 
colour") 
   col[as.numeric(cut(x, breaks))]
}

x <- runif(10, 0, 5)
breaks <- 0:5
col <- c("red", "blue", "green", "cyan", "magenta")
plot(1:10, x, col=continuousColours(x, breaks, col))

Regards,
Richie.

Mathematical Sciences Unit
HSL



ATTENTION:

This message contains privileged and confidential inform...{{dropped:20}}

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

[Rd] RGui Configuration Editor crashes when using an unlisted font

[Richard . Cotton]

I am using R2.9.0 under Windows XP SP 2 (32-bit).

I just discovered a rather excellent programming font 
(http://www.dafont.com/bitstream-vera-mono.font).  Since it isn't one of 
the fonts listed as an option in the RGui Configuration Editor, I manually 
editted my RConsole file font line to

font = Bitstream Vera Sans Mono

When I opened R, the text in the console displayed correctly, but when I 
tried to open the RGui Configuration Editor (via Edit -> Gui preferences), 
R crashed.

I've repeated this with several other fonts that aren't on the standard 
list of available fonts and the behaviour is reproduced.  I've also 
reproduced the crash on another machine running R2.9.0 and WinXP.

Please can someone check to see if the problem occurs on the development 
build/other operating systems, and I will file a bug report.

Regards,
Richie.

Mathematical Sciences Unit
HSL



ATTENTION:

This message contains privileged and confidential inform...{{dropped:20}}

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

[Rd] RGui Configuration editor crashes when using an unlisted font (PR#13780)

[richard . cotton]

Full_Name: Richard Cotton
Version: 2.9.0
OS: Windows XP, SP2, 32 bit
Submission from: (NULL) (87.102.99.18)


To reproduce the crash:

1. Create an RConsole file for your user account.

2. Close R.

3. Manually edit the font line to include a font that is not on the standard
list of available fonts, e.g.

font = Verdana

4. Open R.  (At this point the console text should appear in the new font you
have chosen.)

5. Click Edit -> Gui preferences to open the RGui Configuration Editor.  R will
now crash.


I have reproduced this using the names of several different fonts in the
RConsole file, and on several WinXP boxes.

I also tried contacting the R-Devel list [1] to see if the problem extends to
other OSes, though there has been no response so far.

[1] 
http://www.nabble.com/RGui-Configuration-Editor-crashes-when-using-an-unlisted-font-td24111311.html

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

[Rd] n=1 default for random number generators

[Richard Cotton]

One tiny thing that would be very nice to have is a default value of n=1 in
the random number generator functions, enabling, e.g., runif() instead of
runif(1).  This won't break anyone's existing code and ought to be
relatively straightforward to do.  

Is there anyone in the core team who would be willing to include this
change?

-
Regards,
Richie.

Mathematical Sciences Unit
HSL
-- 
View this message in context: 
http://old.nabble.com/n%3D1-default-for-random-number-generators-tp26374371p26374371.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

[Rd] %s in filename when opening device causes crash (PR#10571)

[richard . cotton]

Full_Name: Richard Cotton
Version: 2.6.1
OS: Windows XP (32bit)
Submission from: (NULL) (193.119.236.82)


Using %s in a filename when opening a device causes R to crash, e.g.,

pdf("foo%s.pdf")
win.metafile("foo%s.wmf")
postscript("foo%s.ps")

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

Re: [Rd] %s in filename when opening device causes crash (PR#10571)

[Richard . Cotton]

> > Using %s in a filename when opening a device causes R to crash, e.g.,
> >
> > pdf("foo%s.pdf")
> > win.metafile("foo%s.wmf")
> > postscript("foo%s.ps")
> 
> Do you have a workaround for this?  Since that is done at C level, we 
> can't easily trap this (especially on Windows), and the list of possible 

> errors that might cause a crash is rather long.
> 
> It has been considered as a vulnerability, but there seems no simple 
> solution.

The simplest workaround is probably to check that '%s' isn't included in 
the character string for the file argument to each of the R wrapper 
functions, something like

if(length(grep("%s", file))) stop("using '%s' in a filename is invalid")

This of course means that we couldn't use '%s' in a file string (is this a 
great loss?), and that users could still cause a crash by calling the 
.External code directly.

Regards,
Richie.

Mathematical Sciences Unit
HSL



ATTENTION:

This message contains privileged and confidential inform...{{dropped:21}}

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

Re: [Rd] %s in filename when opening device causes crash (PR#10571)

[Richard Cotton]

Prof Brian Ripley wrote:
> 
>> Yes. The problem is of course that we do want a sprintf() format there
>> for "Rplot%03d.pdf" et al. One  option would be to escape "%" except
>> when in (regexp) "%[0-9]*d", which seems nontrivial, but not impossible.
> 
> But there are other integer formats (%i, %u, %x, %X), and other flags (# 
> might be useful).  So the list of valid inputs is also rather long.  It 
> would be tedious to do at C level, but a check in the R-level wrapper 
> would be easier (if not 'simple').
> 

Having just worked my way through the alphabet, I can say that it is only
the letters 's' and 'n' that cause any problems.  Thus, if you do decide to
handle the error in the R wrapper functions, the regex for bad inputs is
fairly straightforward "%[#[:blank:]\\+\\-]*[[:digit:]]*[sn]".
-- 
View this message in context: 
http://www.nabble.com/-s-in-filename-when-opening-device-causes-crash-%28PR-10571%29-tp14806982p14877649.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

Re: [Rd] Call R from C#

[Richard Cotton]

guox wrote:
> 
> I would like to call functions/objects of R from
> C#.NET environment. I was wondering whether or not
> it is possible. If yes, could you please give me some suggestions
> on how to approach it (any examples/documentation on this)? Thanks!
> 

Here are some instructions on calling R from F#; they are easily adaptable
to any dotnet language.

http://cs.hubfs.net/blogs/thepopeofthehub/archive/2007/11/06/FSharpWithR.aspx

-
Regards,
Richie.

Mathematical Sciences Unit
HSL
-- 
View this message in context: 
http://www.nabble.com/Call-R-from-C--tp16410255p16556822.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

[Rd] Filename bug in png

[Richard Cotton]

In R2.7.1, the first line of the body of png() reads:
checkIntFormat(filename)

This should really be: 
if (!checkIntFormat(file)) 
stop("invalid 'file'")

Otherwise a command such as png("foo%s.png") causes R to crash (see bug
#10571).

-
Regards,
Richie.

Mathematical Sciences Unit
HSL
-- 
View this message in context: 
http://www.nabble.com/Filename-bug-in-png-tp18256526p18256526.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

Re: [Rd] A strange behaviour of file.path in Windows? (PR#13119)

[Richard . Cotton]

> If you send these lines of code:
> 
> outdir="c:/pippo"
> file.path(outdir,"pluto.html")
> 
> R replies correctly:
> 
> [1] "c:/pippo/pluto.html"
> 
> But if you change the first steps to:
> 
> outdir=""
> file.path(outdir,"pluto.html")
> 
> R replies (uncorrectly, I think)
> 
> [1] "/c:/pippo/pluto.html"

I don't get the same output as you.  Are you sure you haven't changed 
output somewhere else in your code?

outdir="c:/pippo"
file.path(outdir,"pluto.html")

[1] "c:/pippo/pluto.html"

outdir=""
file.path(outdir,"pluto.html")

[1] "/pluto.html"

This is under R2.7.2/ Win XP.

Regards,
Richie.

Mathematical Sciences Unit
HSL



ATTENTION:

This message contains privileged and confidential inform...{{dropped:20}}

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