similar to: FW: very minor Rgui problem in rw0641 (PR#204)

In Rgui (rw0641) the dialog boxes opened by Help->R(standard interface) and Help->Apropos have to be closed by actually clicking on OK, rather than by hitting return. (Once I'm at the keyboard typing in the search term, return is more natural than going back to the mouse. But maybe I'm just old-fashioned.) Is it OK to mention two bugs in one report? After using

I hesitate to report this one because it is very likely system dependent, and I have very little faith in my browser. Still, it may point to something useful for someone to know. On NT4, after help.start() brings up the web interface just fine (despite the pessimistic warning on the terminal; is that still necessary?), I can do apparaently anything in the help system, except search. If I'm

================================================= This is an automated summary of the status of the R-bugs repository. Note that this may be neither complete nor perfectly correct at any given instance: Not all bugs are reported, and some reported bugs may have been fixed, but the repository not yet updated. Some bug fixes are difficult to verify because they pertain to specific hardware or

Under NT 4.0, using Version 0.63.2 Beta (Jan 12, 1999): Not sure if this is a bug or a feature (forcing me to program less clumsily) so I'll report it here rather than to bugs. With a medium size data set (1700 observations,70 explanatory variables) and plenty of memory, specifically > gc() free total Ncells 886738 1000000 Vcells 7912909 8388608 I get a fatal error when

================================================= This is an automated summary of the status of the R-bugs repository. Note that this may be neither complete nor perfectly correct at any given instance: Not all bugs are reported, and some reported bugs may have been fixed, but the repository not yet updated. Some bug fixes are difficult to verify because they pertain to specific hardware or

I really don't think this is an R bug; sorry if I've got it wrong twice within a week. Using rw0632 on NT 4.0, I can get R running quite happily under ESS 5.1.3. However, whenever I use help(), although I do get the required help in a split screen, I also get the minibuffer error message: wrong argument type: processp, nil Note: I get this under ESS 5.0 as well. I could live with this,

================================================= This is an automated summary of the status of the R-bugs repository. Note that this may be neither complete nor perfectly correct at any given instance: Not all bugs are reported, and some reported bugs may have been fixed, but the repository not yet updated. Some bug fixes are difficult to verify because they pertain to specific hardware or

================================================= This is an automated summary of the status of the R-bugs repository. Note that this may be neither complete nor perfectly correct at any given instance: Not all bugs are reported, and some reported bugs may have been fixed, but the repository not yet updated. Some bug fixes are difficult to verify because they pertain to specific hardware or

Dear R users: Today (December 18th) I downloaded R1.2.0 for Windows from ftp://ftp.stat.unipd.it/users/guido/RWin and then invoked its Rgui.exe to change its gui configuration. After I set new values in Rgui configuration Editor frame and saved the set of new parameters as a "Rconsole" file, then I re-started Rgui and R issued an error message concerning the buffer-line-value in the

================================================= This is an automated summary of the status of the R-bugs repository. Note that this may be neither complete nor perfectly correct at any given instance: Not all bugs are reported, and some reported bugs may have been fixed, but the repository not yet updated. Some bug fixes are difficult to verify because they pertain to specific hardware or

================================================= This is an automated summary of the status of the R-bugs repository. Note that this may be neither complete nor perfectly correct at any given instance: Not all bugs are reported, and some reported bugs may have been fixed, but the repository not yet updated. Some bug fixes are difficult to verify because they pertain to specific hardware or

Guido: Thank you so much for this, but I wonder, when there is a new release of R, how can I know which packages in contrib need to be re-compiled? I still have all the .zip files from 1.1.0 on my hard drive here, but I am unsure whether to install them under 1.1.1. Thanks for your help. Tom Richards > -----Original Message----- > From: Guido Masarotto [mailto:guido at

A binary distribution of R-1.3.0 to run on Windows 95, 98, NT4.0 and 2000 on Intel/clone chips is available at http://sirio.stat.unipd.it/RWin It will be mirrored at a CRAN site near you in a couple of days. See below for a list of Windows-specific changes. guido masarotto (for the R-core team) Windows-specific changes to R =============================

================================================= This is an automated summary of the status of the R-bugs repository. Note that this may be neither complete nor perfectly correct at any given instance: Not all bugs are reported, and some reported bugs may have been fixed, but the repository not yet updated. Some bug fixes are difficult to verify because they pertain to specific hardware or

================================================= This is an automated summary of the status of the R-bugs repository. Note that this may be neither complete nor perfectly correct at any given instance: Not all bugs are reported, and some reported bugs may have been fixed, but the repository not yet updated. Some bug fixes are difficult to verify because they pertain to specific hardware or

On Tue, 2 Jan 2001 H.RINNER@TIROL.GV.AT wrote: > [These things don't seem to be of too great importance and may well not meet > the criteria of a "bug", but, for what it's worth,I thought I'd submit them > to r-bugs anyway:] > > This is the R version: > > version > _ > platform i386-pc-mingw32 > arch x86

[These things don't seem to be of too great importance and may well not meet the criteria of a "bug", but, for what it's worth,I thought I'd submit them to r-bugs anyway:] This is the R version: > version _ platform i386-pc-mingw32 arch x86 os Win32 system x86, Win32 status major 1

I have just uploaded to CRAN a binary distribution of R for Windows3.1 + Win32s. You can also find it at ftp://sirio.stat.unipd.it/pub/R guido m. ---------------------------readme.31---------------------------------------- rwin31b.zip contains a binary distribution of R-0.61.3 for MsWindows3.1 with Win32s installed. The executable and the dll's are compiled with egcs-mingw32. This

I have just uploaded to CRAN a binary distribution of R for Windows3.1 + Win32s. You can also find it at ftp://sirio.stat.unipd.it/pub/R guido m. ---------------------------readme.31---------------------------------------- rwin31b.zip contains a binary distribution of R-0.61.3 for MsWindows3.1 with Win32s installed. The executable and the dll's are compiled with egcs-mingw32. This

Debuggers, I wrote to r-help about this and was appropriately told off by Peter Dalgaard. I append that mail in case you have not seen it. Following Peter's advice I have attempted to simplify the problem. First note that the following does *not* fail (by which I mean crash, as in generate a memory access violation): > tmp<-matrix(c(1,0,0,1,1,1),2,3) >