similar to: Wrong bug ID & URL in Daily News about R-devel/NEWS

Hi I think the following behavior is a regression from R 3.2.5: > match(iconv( c("\u00f8", "A"), from = "UTF8", to = "latin1" ), "\u00f8") [1] 1 NA > match(iconv( c("\u00f8"), from = "UTF8", to = "latin1" ), "\u00f8") [1] NA > match(iconv( c("\u00f8"), from = "UTF8",

I'd be curious to know what others think of Rich's patch. If it is acceptable, I can spend time that I was going to look at it this week on another bug. -----Original Message----- From: Rich Calaway Sent: Friday, June 23, 2017 6:34 PM To: Nathan Sosnovske <nsosnov at microsoft.com>; Duncan Murdoch <murdoch.duncan at gmail.com>; Andrie de Vries <apdevries at gmail.com>

According to "CHANGES IN R 3.3.2 patched" in NEWS, rep(x, times) and rep.int(x, times) also work when 'times' has length greater than one and has element larger than the maximal integer. In fact, it is still not the case in R 3.3.3 beta r72259. In seq.c (https://svn.r-project.org/R/branches/R-3-3-branch/src/main/seq.c), 'times' that is a vector with storage mode

Hi all, The "ls" function wears two hats. It allows users to inspect an environment interactively and also serves deeper in code as the accessor for an environment's names/keys. I propose that we separate these two conflicting goals, keeping ls for interactive use and adding names for a quick listing of the hash keys. This involves adding two lines to do_names in attrib.c. The

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

I think ls(, sort=FALSE) would be more explicit and thus clearer. There is much precedent for having arguments that request less work to be done e.g. unlist(use.names=FALSE). Yes, the extra typing is a bit painful, but there is no intuitive reason why names() would be unsorted, while ls() would be sorted. While it is tempting to use an existing function for this, the word "names" is

On Thu, Jan 22, 2015 at 11:44 AM, <luke-tierney at uiowa.edu> wrote: > > 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. We had considered that, but we thought the definition of the function would be easier to interpret if it explicitly specified the namespace, instead of

Since the contract of ls() is to sort, there is nothing wrong with programmers depending on it. And there are many functions that could be made 60X faster, but is it worth it? But I did notice that as.list.environment has a sorted=FALSE argument already, so I guess identical(names(x), names(as.list(x))) could be made to be TRUE, assuming the order is at least persistent, if undefined, so that is a

>>>>> Nathan Sosnovske via R-devel <r-devel at r-project.org> >>>>> on Mon, 26 Jun 2017 18:22:25 +0000 writes: > I'd be curious to know what others think of Rich's > patch. If it is acceptable, I can spend time that I was > going to look at it this week on another bug. It is a bit kludgy (*) of course, but I confirm it solves

On Thu, Jan 22, 2015 at 11:44 AM, <luke-tierney at uiowa.edu> 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

Hi, On 01/23/2015 07:01 AM, luke-tierney at uiowa.edu wrote: > On Thu, 22 Jan 2015, Michael Lawrence wrote: > >> On Thu, Jan 22, 2015 at 11:44 AM, <luke-tierney at uiowa.edu> wrote: >>> >>> 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 >>>

Hi Duncan, I'm guessing I'll be able to look at this over the weekend/next week (probably closer to next week). It is on my list of things to do and I've just had a few other prior commitments that I have to finish first. Sorry for the delay. I'll chime in with a status update next week. Nathan -----Original Message----- From: R-devel [mailto:r-devel-bounces at r-project.org]

For R 3.3.3, if 3.3.3 is really the last in 3.3.x series, I suggest reverting to R 3.3.2 code (and removing the corresponding NEWS entry), if possible. Failure of something like rep(5, list(6)) makes some previously working R code broken in some situation. It is not good to have in an R release that will last long, I think. -------------------------------------------- On Mon, 27/2/17, Martin

Hi! I was wondering whether anybody was looking at the bugs on Bugzilla. I'm asking because I've seen bugs tackled on the mailing list quite quickly, but two fully reproducible reports I've filed on Bugzilla haven't triggered any reaction in several weeks (for the older one). FWIW, these are: - Line goes beyond plot region

Hi Duncan, Thanks for your reply. Yes, it does seem to be specific to the CTYPE setting to Chinese on Windows. If I set it to English using Sys.setlocale() there is no problem, then back to Chinese and the authors disappear: Sys.setlocale("LC_ALL","English") citation("readr") #' To cite package ?readr? in publications use: #' #' Hadley Wickham, Jim

On 15/05/2020 10:39 a.m., Jennifer Lyon wrote: > Hi: > > The "Daily News about R-devel/NEWS" webpage at > http://developer.r-project.org/blosxom.cgi/R-devel/NEWS seems to not be > updating. As of today, the latest entry is Tue, 14 Apr 2020. > > Thanks. > Thanks for noticing that. It's now fixed. (The issue was that R-devel on the news machine didn't

Hi R-core, I have been working on squashing a few bugs in the past couple of days (specifically I have submitted patches for 15425<https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=15425>and 15253 <https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=15253>) , but I haven't been assigning the bugs to myself in bugzilla as I was not sure if that is something only R-core members

Dear Martin, Does the work on nchar mean that bugs #16090 and #16091 will be resolved [1,2]? Thanks, Mark [1] https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=16090 [2] https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=16091 On Sat, Apr 25, 2015 at 11:06 PM, James Cloos <cloos at jhcloos.com> wrote: > >>>>> "GC" == G?bor Cs?rdi <csardi.gabor at

On 16/07/2017 6:17 AM, Anthony Damico wrote: > thank you for taking the time to write this. i set it running last > night and it's still going -- if it doesn't finish by tomorrow, i will > try to find a site to host the problem file and add that link to the bug > report so the archive package can be avoided at least. i'm sorry for > the bother > How big is that

hi, the text file that prompts the segfault is 4gb but only 80,937 lines > file.info( "S:/temp/crash.txt") size isdir mode mtime ctime atime exe S:/temp/crash.txt 4078192743 FALSE 666 2017-07-15 17:24:35 2017-07-15 17:19:47 2017-07-15 17:19:47 no On Sun, Jul 16, 2017 at 6:34 AM, Duncan Murdoch <murdoch.duncan at