similar to: Has the changelog for R-devel and R-patched moved?

On Tue, Sep 1, 2015 at 10:57 AM, peter dalgaard <pdalgd at gmail.com> wrote: > > On 01 Sep 2015, at 16:21 , Avraham Adler <avraham.adler at gmail.com> wrote: > >> Hello. >> >> There used to be changelog of sorts for R-devel [1] and R-release [2]. >> Neither have been updated since 2015-07-24. Have these moved >> elsewhere, or are they no longer

On 01 Sep 2015, at 16:21 , Avraham Adler <avraham.adler at gmail.com> wrote: > Hello. > > There used to be changelog of sorts for R-devel [1] and R-release [2]. > Neither have been updated since 2015-07-24. Have these moved > elsewhere, or are they no longer being updated? Presumably, something that used to happen daily on the hosting machine (or elsewhere) isn't

On Tue, Jan 31, 2017 at 3:30 PM, peter dalgaard <pdalgd at gmail.com> wrote: > >> On 31 Jan 2017, at 18:56 , Avraham Adler <avraham.adler at gmail.com> wrote: >> >> Hello. >> >> When trying to unpack today's version of R-patched, > > From which source? The files from cran.r-project.org seems OK, both those in src/base-prerelease and those from

Hello. When trying to unpack today's version of R-patched, I get the following error: C:\R>tar -xf R-patched_2017-01-30.tar.gz gzip: stdin: unexpected end of file tar: Unexpected EOF in archive tar: Unexpected EOF in archive tar: Error is not recoverable: exiting now I got the same error for R-patched_2017-01-30.tar.gz but not for R-3.3.2.tar.gz. Thank you, Avi

I am working on compiling R-3.6.0 for Windows 10 64bit using rtools40 (beta 11). I had also installed the most recent update of Inno setup, which is now 6.0.2.With that version, `make risntaller` fails at the call to ""C:/R/Inno/iscc" R.iss > R-3.6.0.log 2>&1" and just exits, pointing to line 175 of the makefile which is: $(RPREFIX)-win.exe: R.iss

On Wed, Mar 11, 2015 at 1:40 AM, Hsiu-Khuern Tang <tangoh at gmail.com> wrote: > On Tue, Mar 10, 2015 at 8:54 PM, Avraham Adler <avraham.adler at gmail.com> wrote: >> >> I successfully rebuilt R-devel_2015-03-09 with the most recent version >> of Rtools tonight, building both ICU_531 and this time libcurl (7.39) >> as well (and OpenBLAS, of course). The

Hello. I have successfully built R on windows scores of times, and have never come across this problem. For this build, I am using the current 4.6.3 prerelease version of Rtools, Windows7 64 bit, and R-devel_2015-09-14.tar.gz When running make check, I get the following error: running code in 'reg-packages.R' ...make[3]: *** [reg-packages.Rout] Error 1 make[2]: *** [test-Reg] Error 2

Hello. This is not a question about a bug or even best practices; rather I'm trying to understand the philosophy or theory as to why certain portions of the R codebase are written as they are. If this question is better posed elsewhere, please point me in the proper direction. In the thread about the issues with the Tukey line, Martin said [1]: > when this topic came up last (for me) in

On 2020-01-19 13:01, Avraham Adler wrote: > Crazy thought, but being that a sum of Poissons is Poisson in the sum, > can you break your ?big? simulation into the sum of a few smaller > ones? Or is the order of magnitude difference just too great? ????? I don't perceive that as feasible.? Once I found what was generating NAs, it was easy to code a function to return pseudo-random

On my Mac: str(.Machine) ... $ integer.max????????? : int 2147483647 ?$ sizeof.long????????? : int 8 ?$ sizeof.longlong????? : int 8 ?$ sizeof.longdouble??? : int 16 ?$ sizeof.pointer?????? : int 8 ????? On a Windows 10 machine I have, $ sizeof.long : int 4; otherwise the same as on my Mac. ????? Am I correct that $ sizeof.long = 4 means 4 bytes = 32 bits? log2(.Machine$integer.max)

Hello. I've compiled R on Windows many times, and this is the first time I've seen this error. While running make check-all (and using testInstalledBasic("both")), the lm-tests routines fail, and, as far as I can tell, the diff is failing because in one file, answers are coming back like this "3.11e-004" while in the save file they are "3.11e-04". Every value

On Mon, Nov 13, 2023 at 12:45?PM Avraham Adler <avraham.adler at gmail.com> wrote: > > On Mon, Nov 13, 2023 at 1:13?AM Dirk Eddelbuettel <edd at debian.org> wrote: > > > > > > Avi, > > > > Might be toolchain-dependent, might be options-dependent--it built fine here. > > Easier for you to vary option two so maybe try that? > > > >

I believe that repo just follows the directions on my blog. Without seeing Dr. Hodges?s code, my initial concern is the many references to Cygwin. My method specifically does not use Cygwin but MSYS2 and Mingw64/Rtools35. That will likely change to solely Rtools40 once R3.6 is released due to the Msys system being built in to it. There may be some library conflicts between Cygwin and

On Fri, Feb 9, 2018 at 2:16 AM, Indrajit Sen Gupta <indrajitsg at gmail.com> wrote: > Hi Avraham, > > A quick question - I realized I did not have Perl installed. So I installed > ActiveState Perl right now. Also I see I need texinfo and texi2any. I was > able to installed texinfo from here: > http://gnuwin32.sourceforge.net/packages/texinfo.htm. But not sure where to >

On Tue, Mar 10, 2015 at 3:17 PM, Duncan Murdoch <murdoch.duncan at gmail.com> wrote: > > That's a bug. I haven't tracked down what's going wrong with our > regular code. If I can't find that and fix it soon, I'll make Internet2 > the default. For now, you can do it yourself using the instructions on > ?setInternet2. > > Duncan Murdoch I

As the build process, especially for Windows, is changing significantly for R 3.2.0, I am trying to build R-devel in preparation. When running `make rinstaller`, I get the following error: cp -p ../../../etc/x64/Makeconf R-devel/etc/x64 mkdir -p R-devel/doc cp -p ../../../doc/CRAN_mirrors.csv R-devel/doc mkdir -p R-devel/doc/manual/images cp -pR ../../../doc/html R-devel/doc

On 10/31/24 18:35, Avraham Adler wrote: > On Thu, Oct 31, 2024 at 12:42?PM Tomas Kalibera > <tomas.kalibera at gmail.com> wrote: >> On 10/31/24 17:30, Avraham Adler wrote: >>> When compiling R, the build fails after byte compiling grDevices with >>> the following error: >>> >>> byte-compiling package 'grDevices' >>> make[4]:

On Mon, Nov 13, 2023 at 1:13?AM Dirk Eddelbuettel <edd at debian.org> wrote: > > > Avi, > > Might be toolchain-dependent, might be options-dependent--it built fine here. > Easier for you to vary option two so maybe try that? > > Dirk Thank you, Dirk. I think it was more a PEBCAK issue. When I deleted the entire trunk folder and started the process from scratch, it

????? This issue arose for me in simulations to estimate confidence, prediction, and tolerance intervals from glm(., family=poisson) fits embedded in a BMA::bic.glm fit using a simulate.bic.glm function I added to the development version of Ecfun, available at "https://github.com/sbgraves237/Ecfun".? This is part of a vignette I'm developing, available at

Good evening. Testing the most recent version of Rtools, the build stops about when text.c is being compiled in the tools package (just after R.Lapack). The compilation is looking for gcc in C:, even though RTOOLS is set for another drive, and the compilation has successfully run until this point. This did not happen last night with version 1955. I've uninstalled and reinstalled Rtools three