[Rd] Bug in tools::md5sum - does not work when filepath contains tilde (ie home directory)
I've reproduced on ubuntu and winodws with R3.4.3
When the filepath contains a tilde, the result is NA. But if the file path
is expanded then the function works.
Example:
tools::md5sum("~/.Rprofile") returns NA
tools::md5sum(normalizePath("~/.Rprofile")) returns the proper md5
Perhaps this is expected behaviour because the documentation does say NA is
returned for unreadable files, but I didn't think "~" would make a file
unreadable to the function.
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Bug in print.default: dispatches to global show instead of methods::show
This is related to a problem that was fixed in 2015
https://github.com/wch/r-source/commit/38ea40dcd0353af16d35296ee621338c49ae48c9
The problem then was that auto-printing by typing an object to the console
would search for show() in the globalenv instead of in the methods
namespace.
The problem I would like to report is that it seems that when an S4 object
is printed with print(), a similar issue happens. I do realize that S4
objects should be printed with show() rather than print(), which would
solve the issue, but this still seems like a bug to me.
Example:
library(methods)
show <- function(...) message("hijacked!")
setClass("Test", representation(test = "character"))
test <- new("Test")
print(test)
# hijacked!
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Suggestion/opinions: add a `absolute` param to `normalizePath()` to force returning an absolute path
This request stems off a bug report I posted https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17757 where it was determined the current behaviour is as expected. To recap: when given a real file, normalizePath() always* returns the full absolute path. When given a non-existent file, normalizePath() returns a full path on Windows but it returns the input on other systems*. I'd argue that there are benefits to being able to reliably and consistently get a full path, regardless of whether the file exists or not. In order to not break existing behaviour, I propose adding an argument `absolute = FALSE` that will attempt to return an absolute path when the argument is set to TRUE. I don't have any evidence for this claim, but I believe that others who use this function would expect, like I did, that an absolute path is returned regardless of the file state. I understand the documentation is correct because it warns the absolute path may not be returned, but I believe it would be a useful feature to support. * I've tested this on Win7, Win10, two versions of MacOS, ubuntu. This behaviour may not be true in other OSes [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Suggestion/opinions: add a `absolute` param to `normalizePath()` to force returning an absolute path
Thanks Tomas - I can easily believe that other systems have much less
documentation on this issue! Thanks for you work on this.
I try to stick with base packages when possible, but if the `fs` package
provides this functionality then I'm happy to use that in this case, thanks
Jim.
On Wed, 15 Apr 2020 at 10:06, Jim Hester wrote:
> The fs[1] function `fs::path_abs()` does what I believe you were
> expecting `normalizePath()` to do in this case. e.g.
>
> setwd("~")
> normalizePath("foo/bar")
> #> Warning in normalizePath("foo/bar") :
> #> path[1]="foo/bar": No such file or directory
> #> [1] "foo/bar"
>
> fs::path_abs("foo/bar")
> #> /Users/jhester/foo/bar
>
> [1]: https://CRAN.R-project.org/package=fs
>
>
> On Tue, Apr 14, 2020 at 1:03 PM Dean Attali wrote:
> >
> > This request stems off a bug report I posted
> > https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17757 where it was
> > determined the current behaviour is as expected.
> >
> > To recap: when given a real file, normalizePath() always* returns the
> full
> > absolute path. When given a non-existent file, normalizePath() returns a
> > full path on Windows but it returns the input on other systems*. I'd
> argue
> > that there are benefits to being able to reliably and consistently get a
> > full path, regardless of whether the file exists or not. In order to not
> > break existing behaviour, I propose adding an argument `absolute = FALSE`
> > that will attempt to return an absolute path when the argument is set to
> > TRUE. I don't have any evidence for this claim, but I believe that others
> > who use this function would expect, like I did, that an absolute path is
> > returned regardless of the file state. I understand the documentation is
> > correct because it warns the absolute path may not be returned, but I
> > believe it would be a useful feature to support.
> >
> >
> > * I've tested this on Win7, Win10, two versions of MacOS, ubuntu. This
> > behaviour may not be true in other OSes
> >
> > [[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] Defining a `show` function breaks the print-ing of S4 object -- bug or expected?
Hi r-devel
If you define a function named `show` or attach a package with an exported
`show` function, then printing/vieweing S4 objects breaks. This is probably
because the `print` function calls `show`, which is now masked.
Example:
show <- function() {}
> setClass("Person", slots = list(name = "character"))
> tom <- new("Person", name = "Tom")
> tom # error
> methods::show(tom) # works
The error was a surprise to me because I was under the assumption that
`show` would be namespaced and therefore should not break.
I'm wondering if this is intended behaviour, or if this is a problem. My
intuition, and Hadley agreed on Twitter, is that defining a `show` method
should not have such a grave effect on printing S4 objects.
Thanks
---
http://deanattali.com
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Graphical User Interface (GUI)
Isn't this exactly what Shiny is meant for? http://shiny.rstudio.com/ --- http://deanattali.com On 8 July 2015 at 11:43, vthokienj wrote: > I'd like to create a user interface for my R code and have only seen mostly > older posts on the subject. > I'm not looking for an IDE for development, but something that the end user > of the software would use. > So something that would involve displaying buttons, listboxes, and drop > down > menus to a user that will facilitate various actions. > > I doubt there is anything Visual Studio-like that provides a toolbox to > drag > and drop, but what would be the simplest way to approach designing an > interface? The basic goal of my program is to have the user enter data > which > would be saved to a database. Then, through the interface, various buttons > will draw various graphs on that data. > > Thanks in advance for any help on this. > > > > -- > View this message in context: > http://r.789695.n4.nabble.com/Graphical-User-Interface-GUI-tp4709583.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 > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Why no support for 3-digit HEX colours?
When specifying an RGB colour in R, is there a strong reason not to accept 3-character HEX codes? In CSS and many other languages, a colour of "#ABC" is automatically converted to "#AABBCC", and I was wondering if R could support that as well, or if it was a conscious decision to not support it. --- http://deanattali.com [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Why no support for 3-digit HEX colours?
And very recent as well, good to know, thanks! --- http://deanattali.com On 12 July 2015 at 13:32, Duncan Murdoch wrote: > On 12/07/2015 3:51 PM, Dean Attali wrote: > > When specifying an RGB colour in R, is there a strong reason not to > accept > > 3-character HEX codes? In CSS and many other languages, a colour of > "#ABC" > > is automatically converted to "#AABBCC", and I was wondering if R could > > support that as well, or if it was a conscious decision to not support > it. > > This is on the wish list. See > > https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=16426 > > Duncan Murdoch > > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] 'vapply' not returning list element names when returned element is a length-1 list
Hi all
Sorry for the confusing title. I noticed the following inconsistency:
If i have a function that returns a named list with 2 (or more) elements,
then using 'vapply' retains the names of the elements:
> vapply(1:3, function(x) list("foo" = "bar", "hello" = "world"),
> vector("list", 2))
[,1][,2][,3]
foo "bar" "bar" "bar"
hello "world" "world" "world"
But if the function only returns one element, then the name "foo" is lost
> vapply(1:3, function(x) list("foo" = "bar"), vector("list", 1))
[[1]]
[1] "bar"
> [[2]]
[1] "bar"
> [[3]]
[1] "bar"
Note that when 'lapply' is used instead, the name IS retained
>
> > lapply(1:3, function(x) list("foo" = "bar"))
> [[1]]
> [[1]]$foo
> [1] "bar"
>
> [[2]]
> [[2]]$foo
> [1] "bar"
>
> [[3]]
> [[3]]$foo
> [1] "bar"
I'm not sure if this is intentional or a bug, but it's made my life more
difficult on several occasions and I don't see any reason it would behave
like this.
Thanks
---
http://deanattali.com
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 'vapply' not returning list element names when returned element is a length-1 list
Thank you, I do see that now. I still don't completely agree with the
behaviour, I hoped there would be a way to not simplify, but thank you for
pointing me to the fact that it is documented.
---
http://deanattali.com
On 5 August 2015 at 05:08, S Ellison wrote:
>
>
> > -Original Message-
> > From: R-devel [mailto:r-devel-boun...@r-project.org] On Behalf Of Dean
> Attali
> > If i have a function that returns a named list with 2 (or more) elements,
> > then using 'vapply' retains the names of the elements:
> >
> > But if the function only returns one element, then the name "foo" is lost
>
> vapply _always simplifies_ according to the documentation.
>
> In the first case (function return value contains more than one element,
> and each ), vapply simplifies to a matrix of two lists (!). The names
> "foo" and "hello" have been added to the dimnames so you can tell which is
> which.
>
> in the second case the function return value is a single list and not a
> matrix of lists (a simple list is simpler than a matrix of lists). The name
> of the list ('foo') has nowhere to go; instead, you would be assigning the
> list to a named variable and you don't need the name 'foo'.
>
> Whether that is inconsistent is something of a matter of perspective.
> Simplification applied as far as possible will always depend on what
> simplification is possible for the particular return values, so different
> return values provide different behaviour.
>
> S Ellison
>
>
> ***
> This email and any attachments are confidential. Any u...{{dropped:12}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
