Re: [Rd] recursion problem using do.call(rbind, list(..,,..))

[Hadley Wickham]

Hi Martin,

I think this is a general problem with any function that does dispatch
on ... - I think for well-defined behaviour you always need to
dispatch on pairs, folding/reducing (like in your code) to get a
single value. The downside of this approach is obviously performance:
for n inputs, you need n - 1 temporary objects, which is going to
hamper performance (which is problematic for rbind since it's not
uncommon to have lists of thousands of small data frames). I don't see
anyway around this, except maybe you just have to have specialised
variants (like dplyr::bind_rows() and data.table::rbindlist()) that
don't do dispatch.

I've cc'd Michael since he might have missed the original thread, and
I suspect he's probably thought more about this than me.

Hadley

On Tue, May 10, 2016 at 5:43 AM, Martin Maechler
 wrote:
> This was originally a bug report about Matrix,
>   
> https://r-forge.r-project.org/tracker/?func=detail=294=6325_id=61
> but the bug is rather a "design" bug in R, or a limitation.
>
> This e-mail is a report of the status quo as I see it, and
> call for comments, sugguests, help/hints for workarounds,
> or even a suggestion for a programming task helping R core to
> amend the status {re-writing the methods:::cbind and ...:rbind functions}:
>
>
> If you read  ?rbind  carefully, you may have learned that rbind() and
> cbind() are able to deal with S4 "matrix-like" objects, via the
> hidden methods:::rbind /  methods:::cbind functions
> where these recursively build on appropriate S4 methods for
> rbind2() / cbind2().
>
> That is how cbind() and rbind() work nowadays for Matrix-package
> matrices.
>
> However, there is problem lurking from the above paragraph, and
> for experienced programmers / computer scientists that may even
> be obvious: recursion.
>
> A simple MRE (minimal reproducible example) for the problem seen with Matrix:
>
>   S <- sparseMatrix(i=1:4, j=9:6, x=pi*1:4)
>   n <- 410 # it succeeds for 407 -- sometimes even with 408
>   X <- replicate(n, S, simplify = FALSE)
>   Xb <- do.call("rbind", X)
>   ## -> Error in as(x, "CsparseMatrix") : node stack overflow
>
> But as I said, that's not really the Matrix package. A small
> reproducible example, not involving the Matrix package at all:
>
>   MM <- setClass("mmatrix", contains="matrix")
>   setMethod("rbind2", signature(x="mmatrix", y="mmatrix"),
> function(x,y) as(base::rbind(unclass(x), unclass(y)), "mmatrix"))
>
>   (m5 <- MM(diag(5)))
>   m45 <- MM(matrix(1:20, 4,5))
>   rbind(m5, m45) # fine
>
>   ## fine with 400 :
>   mL.4c <- replicate(400, m45, simplify=FALSE)
>   mmm4 <- do.call(rbind, mL.4c)
>   stopifnot(is(mmm4, "mmatrix"), dim(mmm4) == c(1600L, 5L))
>   ## not ok with 410 :
>   mL.410 <- replicate(410, m45, simplify=FALSE)
>   mmm4 <- do.call(rbind, mL.410)
>   ## Error in getExportedValue(pkg, name) (from #2) : node stack overflow
>
> and the "node stack overflow"  is not too helpful.
> Unfortunately, this is more than one problem, the first one being
> that recursive function calls nowadays often end with this
> "node stack overflow" error, rather than the somewhat more understandable
> error message, namely
>
>   Error: evaluation nested too deeply: infinite recursion / 
> options(expressions=)?
>
> And even worse, that nowadays increasing the option to a higher number N,
> options(expressions = N)
>
> does not help at all in this situation, once the code is byte
> compiled which of course is true for everything in base R.
>
> But that is basically only the reason for the not-so-helpful
> error message (and that raising 'expressions' does not help!),
> but the underlying problem is somewhat harder, namely the full
> setup the S4-serving methods:::rbind() {and ...cbind()} using
> recursion (in the way it does) at all.
>
> There is a simple, in my eyes ugly workaround which also will not scale well,
> but works fine and fast enough for the above example:
>
> ## Simple ugly workaround .. but well fast enough :
>> system.time({
> + r <- mL.410[[1]]
> + for(i in seq_along(mL.410)[-1])
> + r <- rbind2(r, mL.410[[i]])
> + })
>user  system elapsed
>   0.083   0.000   0.083
>> dim(r)
> [1] 16405
>>
>
> This should help Ben (the OP of the Matrix bug), and may be
> something like that should also guide on how to re-write
> the  methods:::rbind()  / methods:::cbind()  in a non-recursive
> fashion ?
>
> Thank you for your thoughts.
>
> Martin Maechler
> ETH Zurich
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel



-- 
http://hadley.nz

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

Re: [Bioc-devel] new download stats

[Hervé Pagès]

Hi Weijun,

I restored the old URLs for all packages but instead of
showing the new stats, the page at the old URL says the stats
has moved and the new URL is provided. See for example:

  http://bioconductor.org/packages/stats/bioc/pathview.html

Cheers,
H.

On 05/12/2016 10:57 PM, Hervé Pagès wrote:

Hi Weijun,

Mmmh... we never promised that the link to the download
stats for a given package was going to be a permanent URL.
The only permanent URLs we promised are the short URLs to the
package landing page which is

   https://bioconductor.org/packages/pathview

in the case of the pathview package. That's the URL to give to
people. The download stats are linked from there so when people
land there, they're 1 click away from the stats.

Anyway, I'll restore the old URL for pathview but it will show the
same content as the new URL, which is not exactly the same as the
old content.

Cheers,
H.

On 05/12/2016 05:27 PM, Luo Weijun wrote:

Hervé,
Thanks for the update, it looks great!
Here is one problem though. I noticed that the original download stats
link has change too. For my pathview package, it was:
http://bioconductor.org/packages/stats/bioc/pathview.html
now changed to:
https://bioconductor.org/packages/stats/bioc/pathview/

I happened to include the old link in a submitted grant application as
an objective impact metric for the Pathview project. And now the old
one is not used any more, and my application suddenly look bad now
because the supportive evidence claimed does not even exist. Not sure
how that may affect our grant application.
can we still keep the old URL or at least make it a alias to the new
one? Thank you!
Weijun


On Thu, 5/12/16, Hervé Pagès  wrote:

  Subject: [Bioc-devel] new download stats
  To: "bioc-devel@r-project.org" 
  Date: Thursday, May 12, 2016, 1:55 PM

  Hi,

  We've refactored the download stats a little:

 https://bioconductor.org/packages/stats/

  2 new visible features are (1) yearly stats since 2009 to
  present
  and (2) downloadable stats in tabulated format (.tab
  extension,
  import in R with 'read.table(, header=TRUE)').

  Feedback welcome.

  Cheers,
  H.

  PS: Updated stats for annotation and experiment packages
  coming soon.

  --
  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

  ___
  Bioc-devel@r-project.org
  mailing list
  https://stat.ethz.ch/mailman/listinfo/bioc-devel





--
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

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] new download stats

[Luo Weijun via Bioc-devel]

Hi Dan and Hervé,
Thank you for the special attention and quick action. I agree the the bioc 
project need updates/additions all the time. Some stability or 
back-compatibility as you guys did would make the project greater.
Weijun


On Fri, 5/13/16, Dan Tenenbaum  wrote:

 Subject: Re: [Bioc-devel] new download stats

 Cc: "bioc-devel" , "Hervé Pagès" 

 Date: Friday, May 13, 2016, 1:52 AM



 - Original Message -
 > From: "bioc-devel" 
 > To: "bioc-devel" ,
 "Hervé Pagès" 
 > Sent: Thursday, May 12, 2016 5:27:17 PM
 > Subject: Re: [Bioc-devel] new download stats

 > Hervé,
[[elided Yahoo spam]]
 > Here is one problem though. I noticed that the original
 download stats link has
 > change too. For my pathview package, it was:
 > http://bioconductor.org/packages/stats/bioc/pathview.html
 > now changed to:
 > https://bioconductor.org/packages/stats/bioc/pathview/
 >    

 I made the old url work for now, just for your
 package...until we can decide what to do about this. 
 It's just a copy of the file at 
http://bioconductor.org/packages/stats/bioc/pathview.html
 , with the url paths adjusted,
 it won't be updated the next time the scripts are run, but
 hopefully by then we will have a solution in place.

 Dan


 > I happened to include the old link in a submitted grant
 application as an
 > objective impact metric for the Pathview project. And
 now the old one is not
 > used any more, and my application suddenly look bad now
 because the supportive
 > evidence claimed does not even exist. Not sure how that
 may affect our grant
 > application.
 > can we still keep the old URL or at least make it a
 alias to the new one? Thank
 > you!
 > Weijun
 > 
 > 
 > On Thu, 5/12/16, Hervé Pagès 
 wrote:
 > 
 > Subject: [Bioc-devel] new download stats
 > To: "bioc-devel@r-project.org"
 
 > Date: Thursday, May 12, 2016, 1:55 PM
 > 
 > Hi,
 > 
 > We've refactored the download stats a little:
 > 
 >    https://bioconductor.org/packages/stats/
 > 
 > 2 new visible features are (1) yearly stats since 2009
 to
 > present
 > and (2) downloadable stats in tabulated format (.tab
 > extension,
 > import in R with 'read.table(,
 header=TRUE)').
 > 
 > Feedback welcome.
 > 
 > Cheers,
 > H.
 > 
 > PS: Updated stats for annotation and experiment
 packages
 > coming soon.
 > 
 > --
 > 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
 > 
 > ___
 > Bioc-devel@r-project.org
 > mailing list
 > https://stat.ethz.ch/mailman/listinfo/bioc-devel
 > 
 > ___
 > Bioc-devel@r-project.org
 mailing list
 > https://stat.ethz.ch/mailman/listinfo/bioc-devel

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Rd] LaTeX errors new with R 3.3.0

[Duncan Murdoch]

On 13/05/2016 10:41 AM, Spencer Graves wrote:

Hello:


I could use help understanding an error reported by "R CMD build
sos" that's new with R 3.3.0:


Error in texi2dvi(file = file, pdf = TRUE, clean = clean, quiet = quiet,  :
Running 'texi2dvi' on 'sos.tex' failed.
LaTeX errors:
! Undefined control sequence.
l.1 \Sconcordance
   {concordance:sos.tex:sos.Rnw:%
The control sequence at the end of the top line
of your error message was never \def'ed. If you have
Calls:  -> texi2pdf -> texi2dvi


[http://r-forge.r-project.org/R/?group_id=235=build_src=sos=patched]


That might mean that latex isn't finding Sweave.sty, which is in 
RHOME/share/texmf/tex/latex, or more likely it is finding a bad version 
somewhere else.


But in your case I think it's because you're telling latex to use 
RJournal.sty instead of Sweave.sty, and never defining \Sconcordance.


You can avoid the need for it by setting the Sweave option 
"concordance=FALSE".




   The above was on R-Forge.  When I run "R CMD build sos" with R
3.3.0 on my MacBook Pro running OS X 10.11.4, I get a different LaTeX
error, also in texi2dvi:


Error in texi2dvi(file = file, pdf = TRUE, clean = clean, quiet = quiet,  :
   Running 'texi2dvi' on 'sos.tex' failed.
BibTeX errors:
The top-level auxiliary file: sos.aux
The style file: abbrvnat.bst
I found no \bibdata command---while reading file sos.aux
Calls:  -> texi2pdf -> texi2dvi
Execution halted



Don't know about that one.

Duncan Murdoch

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

[Rd] LaTeX errors new with R 3.3.0

[Spencer Graves]

Hello:


  I could use help understanding an error reported by "R CMD build 
sos" that's new with R 3.3.0:



Error in texi2dvi(file = file, pdf = TRUE, clean = clean, quiet = quiet,  :
  Running 'texi2dvi' on 'sos.tex' failed.
LaTeX errors:
! Undefined control sequence.
l.1 \Sconcordance
 {concordance:sos.tex:sos.Rnw:%
The control sequence at the end of the top line
of your error message was never \def'ed. If you have
Calls:  -> texi2pdf -> texi2dvi


[http://r-forge.r-project.org/R/?group_id=235=build_src=sos=patched] 




  The above was on R-Forge.  When I run "R CMD build sos" with R 
3.3.0 on my MacBook Pro running OS X 10.11.4, I get a different LaTeX 
error, also in texi2dvi:



Error in texi2dvi(file = file, pdf = TRUE, clean = clean, quiet = quiet,  :
  Running 'texi2dvi' on 'sos.tex' failed.
BibTeX errors:
The top-level auxiliary file: sos.aux
The style file: abbrvnat.bst
I found no \bibdata command---while reading file sos.aux
Calls:  -> texi2pdf -> texi2dvi
Execution halted


  Suggestions?
  Thanks,
  Spencer Graves

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

Re: [R-pkg-devel] develop package with lots of tcltk in it

[Thomas J. Leeper]

Daniel,

It doesn't really sound like you're structuring this in the best way.
Your tcltk code should probably be in your /R folder. I don't know why
you're proposing to put it in /data.

Can you also clarify why your code would generating files in the
working directory? This isn't necessary to create a tcltk interface;
and you shouldn't even need to create any objects in the R global
environment. The suggestion to store all of your tcltk variables in a
package environment is definitely the way to go here.

You may want to look at other packages that use tcltk in order to get
an idea of how this is typically used. Looking through the Rcmdr
source would be a good example.

Best,
-Thomas


> On Thu, May 12, 2016 at 1:25 PM, Dalthorp, Daniel 
> wrote:
>
>> Thanks, Dirk.
>>
>> Sorry for my lack of clarity. I do want to create a package and have
>> created one and it works, but the structure is awkward. I'm hoping someone
>> can help me straighten out the organization.
>>
>> In package/R folder, I have several files that define standalone functions
>> that crunch data.
>> In package/data folder, I have several source files that construct
>> appropriate tktoplevel() windows with the desired widgets
>> To start the application, user opens a main tktoplevel() window by entering
>> a simple command from R.
>> That main window has several buttons that source() files in package/data
>> folder to build a new tktoplevel(), depending on user choice
>>
>> For users who don't know anything about R, this solution may work fine. But
>> for users that do know R, it is unsatisfactory...program changes the
>> working directory, fills it with hundreds of alien-looking functions and
>> data, and crashes if working directory is changed or variables are modified
>> by hand.
>>
>> I came up with that goofy solution to get around two issues:
>> 1. I wasn't able to get away with defining tktoplevel windows with
>> associated widgets and storing in .Rda's packaged in /data or as
>> devtools::use_data(...internal = T), so I figured they needed to be defined
>> and created as needed;
>> 2. it is easy to define the tktoplevels via code in source() files, but I
>> was having trouble with scoping and bookkeeping issues when trying to
>> define them via functions instead. It would be convenient to have all the
>> interesting data stored as globals and use the tkwidgets to edit and
>> manipulate them without having to think specifically about how to pass the
>> interesting data back and forth.
>>
>> E.g. is there an easy way to organize the following into a package that
>> does not use 'source', treats tk.x and tk.y as globals, and does not take
>> over the user's working directory with a bunch of variables like tt1,
>> x.edit, tk.x, tk.y, etc.?
>> tt1 <- tktoplevel()
>> tk.x <- tclVar()
>> x.edit <- tkentry(tt1, textvariable = tk.x, width = 5)
>> x.lbl <- tklabel(tt1, text = "Enter x value: ")
>> xcalc <- tkbutton(tt1, text = "Calculate", command = function()
>> tkmessageBox(message = tclvalue(tk.x)))
>> doMoreStuff <- tkbutton(tt1, text = "Do more...", command = function()
>>  source('doStuff_form.R'))
>> tkgrid(x.lbl, x.edit)
>> tkgrid(xcalc,doMoreStuff)
>>
>> # in doStuff_form.R:
>> tt2 <- tktoplevel()
>> tk.y<-tclVar()
>> y.edit<- tkentry(tt2, textvariable = tk.y, width = 5)
>> anscalc <- tkbutton(tt2, text = "calculate answer", command = function()
>>   tkmessageBox(message=as.numeric(tclvalue(tk.y)) *
>> as.numeric(tclvalue(tk.x)))
>> )
>> tkgrid(y.edit, anscalc)
>>
>> -Dan
>>
>> On Thu, May 12, 2016 at 8:30 AM, Dirk Eddelbuettel  wrote:
>>
>> >
>> > On 11 May 2016 at 12:56, Dalthorp, Daniel wrote:
>> > | I have an R/tcltk application that is designed for use primarily by
>> > people
>> > | who don't know R and don't care to learn much about it. I'd like users
>> to
>> > | be able to use the software with a bare minimum interaction with R.
>> > |
>> > | Although the application has some 15000 lines of code in a couple dozen
>> > .R
>> > | files, in essence I don't think it's much more than an elaborate
>> version
>> > of
>> > | the following:
>> > |
>> > | library(tcltk)
>> > | tt <- tktoplevel() # a required container for tk objects (textboxes,
>> > | radiobuttons, data tables, etc.)
>> > | tk.x <- tclVar() # a tcl version of user variable x
>> > | x.edit <- tkentry(tt, textvariable = tk.x, width = 5) # box for user to
>> > | enter x value
>> > | x.lbl <- tklabel(tt, text = "Enter x value: ") # a fixed label
>> > | xcalc <- tkbutton(tt, text = "Calculate", command = function()
>> > | tkmessageBox(message = tclvalue(tk.x))) # button that prints x to R
>> > console
>> > | tkgrid(x.lbl, x.edit, xcalc) # a function that puts the textbox, label,
>> > and
>> > | button onto the tk window
>> > |
>> > | The following doesn't work:
>> > | # tt, x.edit, x.lbl, xcalc all seem to me like an R objects that will
>> not
>> > | be modified, so I tried
>> > | devtools::use_data(tt, x.edit, x.lbl, xcalc, internal 

Re: [Rd] R process killed when allocating too large matrix (Mac OS X)

[Kirill Müller]

On 12.05.2016 09:51, Martin Maechler wrote:

 > My ulimit package exposes this API ([1], should finally submit it to
 > CRAN); unfortunately this very API seems to be unsupported on OS X
 > [2,3]. Last time I looked into it, neither of the documented settings
 > achieved the desired effect.

 > -Kirill

 > [1] http://krlmlr.github.io/ulimit
 > [2]
 > 
http://stackoverflow.com/questions/3274385/how-to-limit-memory-of-a-os-x-program-ulimit-v-neither-m-are-working
 > [3]
 > 
https://developer.apple.com/library/ios/documentation/System/Conceptual/ManPages_iPhoneOS/man2/getrlimit.2.html


...

In an ideal word, some of us,
 from R core, Jeroen, Kyrill, ,
 maintainer("microbenchmark>, ...
would sit together and devise an R function interface (based on
low level platform specific interfaces, specifically for at least
Linux/POSIX-compliant, Mac, and Windows) which would allow
something  like your rlimit(..) calls below.

We'd really need something to work on all platforms ideally,
to be used by R package maintainers
and possibly even better by R itself at startup, setting a
reasonable memory cap - which the user could raise even to +Inf (or lower
even more).

I haven't found a Windows API that allows limiting the address space, 
only one that limits the working set size; it seems likely that this is 
the best we can get on OS X, too, but then my experience with OS X is 
very limited.


mallinfo() is used on Windows and seems to be available on Linux, too, 
but not on OS X.



-Kirill

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

Re: [Rd] where to send patches to R source code

[Martin Maechler]

>   
> on Thu, 12 May 2016 15:23:04 -0700 writes:

> Hi Peter, Martin, and others,
> Thanks for your replies.

> - The bugs apply to all systems that use GNU Readline, not just Linux
> or Arch Linux.

yes... but

> - Readline version 6.3 changed the signal handling so that SIGWINCH is
> no longer handled automatically by the library. This means it's not
> currently possible for people using R on e.g. Linux to resize the
> terminal, or at least when they do so they have to make sure that
> all their commands fit in one line and don't wrap.

> - There is also a long-standing bug in Readline where the callback
> interface didn't properly clear the line on SIGINT (^C). This means
> that "exiting" reverse-incremental-search with ^C would give an
> apparently empty prompt which still had some pending input, so if
> you hit ^C-Return then an unintended command would get executed.

> If they're not "bothering all that many people", then perhaps it's
> because everyone uses Windows or Mac OS X or RStudio 

or  ESS [ := Emacs Speaks Statistics]  https://ess.r-project.org/ ),
really the first cross platform UI, and the most used one by R 
"gurus" for a long time...

or StatET (an Eclipse based GUI, also cross platform)

or ... {quite a few more}.

I'm pretty sure (but may be wrong) that 99% of useRs do not work
much with R in a readline-enabled console, but rather via
another interface.
Maybe only 95% if you restrict yourself to non-Mac, non-Windows
(i.e. typically Linux) users. 

> For me these are pretty significant bugs. 

I agree they should be fixed.. only just because regular bash
users may like the readline-enabled R in a terminal, and because
readline is nice in itself, and it'd be a pity if our using it
started to lag. ... or has started to lag, as you found..


> The second one causes unintended code to be
> executed. Random code could delete files, for example, or worse. The
> first one bites me every time I want to change the size of a window,
> which is pretty often.

> I tried to get Readline maintainer Chet Ramey to fix these on the
> Readline side, but he disagreed with my proposal:

> https://lists.gnu.org/archive/html/bug-readline/2016-04/threads.html

> I'm glad that my message here at least was seen and I hope that
> someone who uses the R command line on Linux will have time to verify
> that the patches work correctly. They are basically Chet-approved
> workarounds for bugs/changes in Readline, not very complicated.

> Do either of you know a Linux R person you could ping to get these
> patches checked out? I'm not overly frustrated, and I'm not in a major
> hurry, but from what we've observed it seems like waiting for someone
> concerned to come along and finally read Bugzilla or the R-Devel
> archives is not going to result in a very dense Poisson process...

Well, many of us from R core use Linux regularly or at least occasionally and
hence can take time to confirm the bug ... and if the patch
seems to fix it.

However, most of experienced R users, not just R core,
"believes" in reproducibility and hence we want to work with *.R
scripts (or *.Rmd etc nowadays):

We had a saying in the ESS manuals for 20 years or so:

   "The source code is real."

which had later been extended to

"The source code is real.
 The objects are realizations of the source code."

As a consequence, we do not "work" in the R console; we may tinker
a bit for experiments, but we really work "in" the R source files.

For that reason, if apply your patches and quickly check that
the previous bug seems gone, I would not notice if the patch had
introduced new bugs ... just because I almost never work in
"readline-R"  but always (99.9%) work in Linux.

Martin


> Thanks,
> Frederick Eaton

> On Thu, May 12, 2016 at 03:42:59PM +0200, peter dalgaard wrote:
>> 
>> > On 12 May 2016, at 10:03 , Martin Maechler 
 wrote:
>> > 
>> >>  
>> >>on Wed, 11 May 2016 23:00:20 -0700 writes:
>> > 
>> >> Dear R Developers,
>> >> I wrote to this list a week ago with some patches that fix bugs in R's
>> >> GNU Readline interface, but I haven't had a reply. I'm not in a hurry
>> >> but I'd like to make sure that my message is getting read by the right
>> >> people. Should I be sending my patches somewhere else?
>> > 
>> > Thank you Frederick for your reports and patches.
>> > You did send them to the correct place, https://bugs.r-project.org/
>> > 
>> > Sometimes (as here) a combination of circumstances do lead to
>> > nobody picking them up quickly.
>> > In this case,
>> > 
>> > - probably none of R-core use or even have easy access to Arch Linux
>> >  so we cannot easily veryify that there is a bug at all
>> >  nor 

Re: [Rd] where to send patches to R source code

[peter dalgaard]

Actually, I think both Martin and I use reaadline R versions on a daily basis 
(Linux and OSX Terminal respectively). For my case, it is just that I rarely 
use the backwards search feature and I'm old enough that terminal widths other 
than 80 look odd to me so I don't resize much either. Of course that doesn't 
mean that the bugs aren't annoying to others!

-pd



On 13 May 2016, at 00:23 , frede...@ofb.net wrote:

> Hi Peter, Martin, and others,
> 
> Thanks for your replies.
> 
> - The bugs apply to all systems that use GNU Readline, not just Linux
>  or Arch Linux.
> 
> - Readline version 6.3 changed the signal handling so that SIGWINCH is
>  no longer handled automatically by the library. This means it's not
>  currently possible for people using R on e.g. Linux to resize the
>  terminal, or at least when they do so they have to make sure that
>  all their commands fit in one line and don't wrap.
> 
> - There is also a long-standing bug in Readline where the callback
>  interface didn't properly clear the line on SIGINT (^C). This means
>  that "exiting" reverse-incremental-search with ^C would give an
>  apparently empty prompt which still had some pending input, so if
>  you hit ^C-Return then an unintended command would get executed.
> 
> If they're not "bothering all that many people", then perhaps it's
> because everyone uses Windows or Mac OS X or RStudio. For me these are
> pretty significant bugs. The second one causes unintended code to be
> executed. Random code could delete files, for example, or worse. The
> first one bites me every time I want to change the size of a window,
> which is pretty often.
> 
> I tried to get Readline maintainer Chet Ramey to fix these on the
> Readline side, but he disagreed with my proposal:
> 
> https://lists.gnu.org/archive/html/bug-readline/2016-04/threads.html
> 
> I'm glad that my message here at least was seen and I hope that
> someone who uses the R command line on Linux will have time to verify
> that the patches work correctly. They are basically Chet-approved
> workarounds for bugs/changes in Readline, not very complicated.
> 
> Do either of you know a Linux R person you could ping to get these
> patches checked out? I'm not overly frustrated, and I'm not in a major
> hurry, but from what we've observed it seems like waiting for someone
> concerned to come along and finally read Bugzilla or the R-Devel
> archives is not going to result in a very dense Poisson process...
> 
> Thanks,
> 
> Frederick Eaton
> 
> On Thu, May 12, 2016 at 03:42:59PM +0200, peter dalgaard wrote:
>> 
>>> On 12 May 2016, at 10:03 , Martin Maechler  
>>> wrote:
>>> 
 
   on Wed, 11 May 2016 23:00:20 -0700 writes:
>>> 
 Dear R Developers,
 I wrote to this list a week ago with some patches that fix bugs in R's
 GNU Readline interface, but I haven't had a reply. I'm not in a hurry
 but I'd like to make sure that my message is getting read by the right
 people. Should I be sending my patches somewhere else?
>>> 
>>> Thank you Frederick for your reports and patches.
>>> You did send them to the correct place, https://bugs.r-project.org/
>>> 
>>> Sometimes (as here) a combination of circumstances do lead to
>>> nobody picking them up quickly.
>>> In this case,
>>> 
>>> - probably none of R-core use or even have easy access to Arch Linux
>>> so we cannot easily veryify that there is a bug at all
>>> nor -consequently- veryify that your patch does fix the bug.
>> 
>> Actually, the bugs look like they should apply fairly generally, just maybe 
>> not bothering all that many people. But there could be portability issues 
>> with the fixes, so I suspect some of us were waiting for "a readline expert" 
>> to check them out.
>> 
>> -pd
>> 
>> BTW: Anyone with a fix for the stuck-at-eol issue? (aaabbbccc) 
>> 
>>> 
>>> - no other user has confirmed the bug on his/her platform, so
>>> there did not seem a huge demand...
>>> 
>>> - Accidentally many in R core may be busy with other bugs, teaching, .
>>> and just lack the extra resources to delve into these problems
>>> at the current moment.
>>> 
>>> Hence, there was not even an 'Acknowledged' change to your
>>> reports--indeed as nobody had been able to see there is a problem
>>> existing outside of your personal computer.
>>> 
>>> I agree that this must seem a bit frustrating to you.
>>> 
>>> --
>>> Martin
>>> 
>>> __
>>> R-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>> 
>> -- 
>> 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
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 

-- 
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: 

Re: [Rd] objects intermittently shared between vignettes

[Duncan Murdoch]

On 12/05/2016 9:21 PM, Spencer Graves wrote:

Hello:


Is it widely known that objects not explicitly deleted from one
vignette in a package can be available to a second in "R CMD build" and
"R CMD check" but not when the second vignette is built manually, at
least under RStudio on Mac OS X 10.11.4 using R 3.3.0?


 For an example, see


install.packages("pkgW2vignettes", repos="http://R-Forge.R-project.org;)


This package contains two toy vignettes.


This is not a big deal, but it spooked me, when I saw 227 objects
listed by "objects()" in a vignette built by "R CMD build" + "R CMD
check", when the same "objects()" command only listed 4 objects when I
built the same vignette by itself from within RStudio.



Yes, this is a known flaw in the current build system.  It would be 
better if vignettes were built in a separate process that was started 
with an empty workspace.


There's an intention to clean up several vignette building issues, but 
so far no action.


Duncan Murdoch

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

Re: [Rd] where to send patches to R source code

[Göran Broström]

Dear Frederik,

I can confirm that especially the first issue on your list (resizing the 
terminal) has "bothered me" badly for some time now: I'm on Ubuntu 
(usually).


Göran Broström


On 2016-05-13 00:23, frede...@ofb.net wrote:

Hi Peter, Martin, and others,

Thanks for your replies.

- The bugs apply to all systems that use GNU Readline, not just Linux
   or Arch Linux.

- Readline version 6.3 changed the signal handling so that SIGWINCH is
   no longer handled automatically by the library. This means it's not
   currently possible for people using R on e.g. Linux to resize the
   terminal, or at least when they do so they have to make sure that
   all their commands fit in one line and don't wrap.

- There is also a long-standing bug in Readline where the callback
   interface didn't properly clear the line on SIGINT (^C). This means
   that "exiting" reverse-incremental-search with ^C would give an
   apparently empty prompt which still had some pending input, so if
   you hit ^C-Return then an unintended command would get executed.

If they're not "bothering all that many people", then perhaps it's
because everyone uses Windows or Mac OS X or RStudio. For me these are
pretty significant bugs. The second one causes unintended code to be
executed. Random code could delete files, for example, or worse. The
first one bites me every time I want to change the size of a window,
which is pretty often.

I tried to get Readline maintainer Chet Ramey to fix these on the
Readline side, but he disagreed with my proposal:

https://lists.gnu.org/archive/html/bug-readline/2016-04/threads.html

I'm glad that my message here at least was seen and I hope that
someone who uses the R command line on Linux will have time to verify
that the patches work correctly. They are basically Chet-approved
workarounds for bugs/changes in Readline, not very complicated.

Do either of you know a Linux R person you could ping to get these
patches checked out? I'm not overly frustrated, and I'm not in a major
hurry, but from what we've observed it seems like waiting for someone
concerned to come along and finally read Bugzilla or the R-Devel
archives is not going to result in a very dense Poisson process...

Thanks,

Frederick Eaton

On Thu, May 12, 2016 at 03:42:59PM +0200, peter dalgaard wrote:



On 12 May 2016, at 10:03 , Martin Maechler  wrote:


  
on Wed, 11 May 2016 23:00:20 -0700 writes:



Dear R Developers,
I wrote to this list a week ago with some patches that fix bugs in R's
GNU Readline interface, but I haven't had a reply. I'm not in a hurry
but I'd like to make sure that my message is getting read by the right
people. Should I be sending my patches somewhere else?


Thank you Frederick for your reports and patches.
You did send them to the correct place, https://bugs.r-project.org/

Sometimes (as here) a combination of circumstances do lead to
nobody picking them up quickly.
In this case,

- probably none of R-core use or even have easy access to Arch Linux
  so we cannot easily veryify that there is a bug at all
  nor -consequently- veryify that your patch does fix the bug.


Actually, the bugs look like they should apply fairly generally, just maybe not bothering 
all that many people. But there could be portability issues with the fixes, so I suspect 
some of us were waiting for "a readline expert" to check them out.

-pd

BTW: Anyone with a fix for the stuck-at-eol issue? (aaabbbccc)



- no other user has confirmed the bug on his/her platform, so
  there did not seem a huge demand...

- Accidentally many in R core may be busy with other bugs, teaching, .
  and just lack the extra resources to delve into these problems
  at the current moment.

Hence, there was not even an 'Acknowledged' change to your
reports--indeed as nobody had been able to see there is a problem
existing outside of your personal computer.

I agree that this must seem a bit frustrating to you.

--
Martin

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


--
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



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