Re: [R-pkg-devel] Trouble installing XML on Windows 7 (64-bit)

On Fri, Dec 15, 2017 at 12:02 PM, Haigh, Rowan wrote: > Hi Duncan, > > Well I finally managed to install XML from source in Windows under R-devel. > Basically it was a clue provided by user wlandau-lilly (last message on > https://github.com/igraph/igraph/issues/915),

Re: [R-pkg-devel] New package submission error (ieee_arithmetic)

On Wed, Nov 29, 2017 at 4:37 PM, Waleed Almutiry wrote: > Hi all, > > I tried to upload my package to CRAN and did not pass the the incoming > checks. This was because the use of ieee_arithmetic module in a fortran > subroutine in the src folder. I built and checked the

Re: [R-pkg-devel] New package submission error (ieee_arithmetic)

On Wed, Nov 29, 2017 at 4:37 PM, Waleed Almutiry wrote: > I tried to upload my package to CRAN and did not pass the the incoming > checks. This was because the use of ieee_arithmetic module in a fortran > subroutine in the src folder. I built and checked the package using

Re: [Rd] Debate: Shall some of Microsoft R Open Code be ported to mainstream R?

On Mon, Oct 30, 2017 at 12:45 PM, Cohn, Robert S wrote: > I think the thing that is missing is a simple way for end users on windows to > replace blas/lapack libraries with MKL-a package that you install that puts > the libraries in the right place. > > Microsoft

Re: [Rd] Debate: Shall some of Microsoft R Open Code be ported to mainstream R?

[Sent offlist accidentally] What concerns me first and foremost is that the licensure would have to be ironclad (including for commercial use like vanilla R now) as well as ensuring that R remains completely FLOSS. Anything “added” to R has to be a no-strings-attached gift to R. Also, I would

Re: [Rd] Duncan's retirement: who's taking over Rtools?

On Thu, Sep 28, 2017 at 11:47 AM, David Smith via R-devel wrote: > The Microsoft R team is willing and able to produce builds for R on Windows > going forward. As Duncan noted, we've been doing this already for some time > for MRAN. I'd love to hear thoughts from this

Re: [Rd] Duncan's retirement: who's taking over Rtools?

On Thu, Sep 28, 2017 at 11:27 AM, Joris Meys wrote: > Dear dev team, > > I was sorry to see the announcement of Duncan about his retirement from > maintaining the R Windows build and Rtools. Duncan, thank you incredibly > much for your 15 years of devotion and your impressive

[Rd] Solaris SPARC testbed

I've looked at some package testing results and I'm not seeing Solaris SPARC. Has that test-bed been deprecated for package testing? Thanks, Avi __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Philosophy behind converting Fortran to C for use in R

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

Re: [Rd] TEXINFO error when building R-3.4.0

The fault was mine. -I/C:/R/texinfo should have been -IC:/R/texinfo Thank you, Avi __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] TEXINFO error when building R-3.4.0

Hello. I am trying to build 64 bit R-3.4.0 (specifically R-patched_2017-04-23) on Windows 64 and have run into an issue with building the html files. I am using Rtools34 version 1962, the texinfo zip from unzipped into C:\R\texinfo, and Strawberry perl

Re: [R-pkg-devel] R_registerRoutines, etc.

On Sun, Apr 23, 2017 at 7:51 PM, Dirk Eddelbuettel wrote: > > On 24 April 2017 at 11:47, Rolf Turner wrote: > > And per Duncan's last (and his earlier emails) maybe you need to call from R > into C (for finer control over the interface) and only then call your Fortran > worker

Re: [R-pkg-devel] R_registerRoutines, etc.

On Sun, Apr 23, 2017 at 7:36 PM, Duncan Murdoch wrote: > On 23/04/2017 6:18 PM, Rolf Turner wrote: [SNIP] > This is important: *there is no way to pass a Fortran "LOGICAL" from R to > Fortran*. > > The issue is that different Fortran compilers store LOGICAL in different

Re: [R-pkg-devel] Solaris SPARC, Fortran, and logical errors?

On Wed, Mar 15, 2017 at 12:19 PM, William Dunlap wrote: > I don't know about the current Sparc Fortran compilers, but over the > years have learned not to try to pass logicals and character strings > between C and Fortran. I have seen Fortran compilers that treated > integer

Re: [Rd] R 3.4.0

Perhaps the darkness is so stupid it forgot to update the year? Avi On Fri, Mar 17, 2017 at 12:24 PM wrote: > Your dates are for 2016 :-) in your email and developer.r-project.com > > Best, > > luke > > On Fri, 17 Mar 2017, Peter Dalgaard wrote: > > > R 3.4.0 "You Stupid

Re: [R-pkg-devel] Solaris SPARC, Fortran, and logical errors?

On Wed, Mar 15, 2017 at 11:09 AM, J C Nash wrote: > Possibly tangential, but has there been any effort to set up a Sparc > testbed? It > seems we could use a network-available (virtual?) machine, since this > platform is > often the unfortunate one. Unless, of course,

Re: [R-pkg-devel] Solaris SPARC, Fortran, and logical errors?

On Wed, Mar 15, 2017 at 12:19 PM, William Dunlap wrote: > I don't know about the current Sparc Fortran compilers, but over the > years have learned not to try to pass logicals and character strings > between C and Fortran. I have seen Fortran compilers that treated > integer

Re: [Rd] Registration of native routines

I believe Dr. Ripley said that the UseDynLib doesn't address the middle two points of the list. I experimented with the Delaporte package timing calls using both methods, and they were within 1~2 microseconds of each other using microbenchmark. Since the more complicated way is now expressly

Re: [Rd] Wish List: Extensions to the derivatives table

Hi. Unless I'm misremembering, log, exp, sin, cos, and tan are all handled in deriv3. The functions listed are specially coded slightly more accurate versions but can be substituted with native ones for which deriv/deriv3 will work automatically. I believe that if you write your functions using

[R-pkg-devel] Packages which use Fortran call "rwarn" for warnings?

Hello. Would anyone know of a package which uses the rwarn subroutine, as described in Writing R extensions 6.2.1, for error handling from Fortran? I'm experimenting with it and getting overwhelmed with stack errors and crashes, and could benefit from seeing it used properly. Thank you, Avi

[Rd] R-devel 2017-02-15: repeated line in /src/gnuwin32/MkRules.dist

Hello. Unless I am mistakedn, it seems that lines 49 and 72 are copies of each other and only one should be necessary to set the whether or not Windows is 32- or 64-bit. If it were my guess, I'd say lines 48 & 49 are redundant. Thanks, Avi __

Re: [Rd] Registration of native routines

On Tue, Feb 14, 2017 at 11:25 AM, Prof Brian Ripley wrote: > Registration of 'native routines' (entry points in compiled code loaded into > R) has been available for over 14 years, but few packages make use of it > (less than 10% of those on CRAN with compiled code). > >

[R-pkg-devel] Delaporte: Test Errors on Sun Sparc

I recently changed the back-end compiled code for the Delaporte package from C++ to Fortran/C, and after some birthing pains (and a lot of patience shown by CRAN), it's fully functional _except_ on sparc-sun-solaris2.10 [1]. There, 10 of the 44 tests return errors. I've done enough research to

Re: [Rd] Unexpected EOF in R-patched_2017-01-30

On Wed, Feb 1, 2017 at 3:14 AM, Martin Maechler wrote: > Or the file was corrupted during download? > > Here are the md5sum s from the server itself for the last three snapshots: > > 388b607afe732c92442dbb49845fe377 /ftp/R/R-patched_2017-01-31.tar.gz >

Re: [Rd] Unexpected EOF in R-patched_2017-01-30

On Wed, Feb 1, 2017 at 3:14 AM, Martin Maechler <maech...@stat.math.ethz.ch> wrote: > >>>>> Avraham Adler <avraham.ad...@gmail.com> > >>>>> on Tue, 31 Jan 2017 16:07:20 -0500 writes: > > > On Tue, Jan 31, 2017 at 3:30 PM, peter dalg

Re: [Rd] Unexpected EOF in R-patched_2017-01-30

On Tue, Jan 31, 2017 at 3:30 PM, peter dalgaard <pda...@gmail.com> wrote: > >> On 31 Jan 2017, at 18:56 , Avraham Adler <avraham.ad...@gmail.com> wrote: >> >> Hello. >> >> When trying to unpack today's version of R-patched, > > From which sourc

[Rd] Unexpected EOF in R-patched_2017-01-30

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

Re: [Rd] unlicense

A number of years ago I asked here for the ISC to be added and was told you have to ask CRAN, not Rd. Good luck, Avi On Fri, Jan 13, 2017 at 3:22 PM Charles Geyer wrote: > I would like the unlicense (http://unlicense.org/) added to R > > licenses. Does anyone else think

Re: [Rd] optim(…?=, =?utf-8?Q?method=‘L-BFGS-B’) stops with an error message while violating the lower bound

I believe the code can be found here: http://users.iems.northwestern.edu/~nocedal/lbfgsb.html. Specifically, lbfgsb.f in version 3.0 starts: This is a modified version of L-BFGS-B. Minor changes in the updated c code appear preceded by a line comment as follows c c c-jlm-jn c c Major

[Rd] Setting Gnu++11 when compiling R-devel on Windows

Recently, there have been changes to R-devel to make it more compatible with GCC 6.x, which is great. Unfortunately, Windows still uses a toolset based on GCC 4.9.3. When compiling R release or R-patched, one can have GCC called with -std=gnu++11 by having it in the CXXFLAGS in one's

[Rd] Is it intentional that the Fortran optimization flags changefrom O3 to O2 on Windows?

When compiling R-devel (2016-08-07) on Windows (64bit) using Rtools (3.4.0), the C++ optimization flags are manually changed to -O2 from -O3. This has been the situation for years, and I believe this is to prevent certain optimizations which may cause downstream problems. In

Re: [Rd] Error building Tcl: R-patched_2016-07-05

6 5:47 PM, Avraham Adler wrote: >> >> I am trying to build R under 64bit Windows7. I am using a fresh >> install of Rtools34 and R-patched_2016-07-05. I am getting the >> following error: >> >> C:/Rtools/mingw_64/bin/gcc -shared -s -static-libgcc -o tcltk.

[Rd] Error building Tcl: R-patched_2016-07-05

I am trying to build R under 64bit Windows7. I am using a fresh install of Rtools34 and R-patched_2016-07-05. I am getting the following error: C:/Rtools/mingw_64/bin/gcc -shared -s -static-libgcc -o tcltk.dll tmp.def init.o tcltk.o tcltk_win.o ../../../gnuwin32/dllversion.o

[Rd] Building manuals are failing now that MikTex 2.9 has removed texi2dvi.exe

According to the MikTex bug reports [1], MikTex 2.9 has removed texi2dvi.exe last week (on 2015-09-29) as "it was not compatible (anymore) with the original shell script texi2dvi (GNU Texinfo)." I found this out the hard way as I just (unknowingly) updated MikTex this evening, and then, while

Re: [Rd] Building manuals are failing now that MikTex 2.9 has removed texi2dvi.exe

On Fri, Oct 9, 2015 at 1:44 AM, Prof Brian Ripley wrote: > Hmm, look in MkRules.dist for the setting you failed to make Obviously > available in R-patched and R-devel only as we cannot foretell such changes. > >[snip] Yes, I see my error. For efficiency, I had copied

[Rd] R-devel_2015-09-14 throws an error in reg-packages test

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

[Rd] Has the changelog for R-devel and R-patched moved?

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? Thank you, Avi [1] [2]

Re: [R-pkg-devel] recreating CRAN Testing environment

Even if you don't use Windows, it pays to submit your package to the Winbuilder test of buth R-release and R-devel. The error reports, if any, are often not-OS dependant and will serve as a good gaage as to how the real CRAN will respond. Avi On Mon, Jul 20, 2015 at 1:59 PM, Ben Bolker

[Rd] GCC update in Rtools?

Hello. There was a lot of discussion in March about the difficulties in having Rtools use a more recent version of GCC than 4.6.3. May we know if there has been any progress since then, or has dveleopment/testing been put on hold for the time being? Thank you, Avi

Re: [Rd] alternate licensing for package data?

To get around this last problem, perhaps you can take advantage of CRAN's suggestion regarding large data files [1] where they say [w]here a large amount of data is required (even after compression), consideration should be given to a separate data-only package which can be updated only rarely

Re: [Rd] behavior of as.integer(5000000000)

On Tue, Apr 14, 2015 at 1:19 AM, Hervé Pagès hpa...@fredhutch.org wrote: Hi, as.integer(50) [1] 2147483647 Warning message: inaccurate integer conversion in coercion as.integer(-50) [1] NA Warning message: inaccurate integer conversion in coercion Is

[Rd] Rtools version 3.3.0.1957 looking for C even though RTOOLS variable is pointing elsewhere

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

Re: [Rd] Rtools version 3.3.0.1957 looking for C even though RTOOLS variable is pointing elsewhere

, but not R-devel_2015-03-09.tar.gz, so it must have been something between 09 and 10. Avi On Thu, Mar 12, 2015 at 11:15 PM, Avraham Adler avraham.ad...@gmail.com wrote: Good evening. Testing the most recent version of Rtools, the build stops about when text.c is being compiled in the tools package

Re: [Rd] Rtools version 3.3.0.1957 looking for C even though RTOOLS variable is pointing elsewhere

The following changes may be responsible: src\gnuwin32\fixed\Makefile lines 31 and 47 where version 9 has '-e s|BINPREF =|BINPREF = $(BINPREF)| \' and version 10 has '-e 's|BINPREF =|BINPREF ?= $$(RTOOLS)gcc492_64/bin/|' \'. Or, it may have been the addition of RTOOLS ?= C:/Rtools/ on line 17 of

Re: [Rd] Rtools version 3.3.0.1957 looking for C even though RTOOLS variable is pointing elsewhere

Removing the extra '$' from $$(RTOOLS) solves the issue. Thank you, Avi __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Notes on building a gcc toolchain for Rtools (but not multilib)

On Wed, Mar 11, 2015 at 1:40 AM, Hsiu-Khuern Tang tan...@gmail.com wrote: On Tue, Mar 10, 2015 at 8:54 PM, Avraham Adler avraham.ad...@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

Re: [Rd] Notes on building a gcc toolchain for Rtools (but not multilib)

On Mon, Mar 9, 2015 at 10:40 AM, Duncan Murdoch murdoch.dun...@gmail.com wrote: It's now on the main site at CRAN, and should propagate to the mirrors reasonably quickly. I'm hoping that tomorrow's R-devel build will use it, but there may be some last minute problems. Using Rtools 3.3, once

Re: [Rd] ICU_531 and sjlj vs.seh

Just to close the loop (and prevent this xkcd cartoon from becoming even more true https://xkcd.com/979/), the answer to this question was addressed in this post https://stat.ethz.ch/pipermail/r-devel/2015-March/070784.html and subsequent. Avi __

Re: [Rd] Notes on building a gcc toolchain for Rtools (but not multilib)

On Mon, Mar 9, 2015 at 6:50 AM, Duncan Murdoch murdoch.dun...@gmail.com wrote: It is also not multilib. It uses static linking of libraries, and SJLJ exception handling in both 32 and 64 bit builds -- this is necessary for compatibility with existing compiles of external libraries, but may

Re: [Rd] Notes on building a gcc toolchain for Rtools (but not multilib)

On Mon, Mar 9, 2015 at 11:07 AM, Hsiu-Khuern Tang tan...@gmail.com wrote: I also worked off R-devel (I said wrongly that it was R-patched in my original post) and benefited from your compatibility changes. Hsiu-Khuern, using your suggest filter in NM, I was able to build Rcpp in the R_devel

Re: [Rd] Notes on building a gcc toolchain for Rtools (but not multilib)

On Sun, Mar 8, 2015 at 10:02 PM, Hsiu-Khuern Tang tan...@gmail.com wrote: Hi, [This is a follow-up to the New version of Rtools for Windows thread in January, but I just subscribed and don't know how to reply to an old thread -- my apologies.] I was able to use the nuwen distro to build a

[Rd] ICU_531 and sjlj vs.seh

It seems that version of ICU_531 in http://www.stats.ox.ac.uk/pub/Rtools/goodies/ as of June 25, 2014, was compiled using sjlj exception handling (current gcc-4.6.3, perhaps?). I say that as I am trying a 4.9.2 distribution which uses seh handling, and I get errors like: gcc -std=gnu99 -m64

Re: [Rd] Notes on building a gcc toolchain for Rtools (but not multilib)

Spurred by Hsiu-Khuern's post, I was able to compile R-devel_2015-03-08 using the already compiled distribution at

[Rd] Building rinstaller using R-devel (3.2.0-to-be) halts when trying to copy html files

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

Re: [Rd] Building rinstaller using R-devel (3.2.0-to-be) halts when trying to copy html files

On Mon, Jan 26, 2015 at 8:36 PM, Duncan Murdoch murdoch.dun...@gmail.com wrote: On 26/01/2015 5:12 PM, Avraham Adler wrote: 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

Re: [Rd] Request for help with UBSAN and total absense of CRAN response

Hello, Dirk. I have no experience with UBSAN etc., but as you mention not being able to recreate the CRAN errors, it reminds me of the time I had trouble getting my pacakge approved for CRAN as it passed all tets but Win32, and I have a Win64 setup and could not test it. Have you tried submitting

Re: [Rd] New version of Rtools for Windows

On Fri, Jan 9, 2015 at 12:19 PM, Duncan Murdoch murdoch.dun...@gmail.com wrote: On 09/01/2015 10:56 AM, Henric Winell wrote: On 2015-01-08 02:31, Duncan Murdoch wrote: On 07/01/2015 5:20 PM, Jeroen Ooms wrote: On Wed, Jan 7, 2015 at 8:00 AM, Duncan Murdoch murdoch.dun...@gmail.com wrote:

Re: [Rd] New version of Rtools for Windows

-- On Thu, Jan 8, 2015 2:01 PM GMT Henric Winell wrote: On 2015-01-08 14:18, Avraham Adler wrote: Very timely, as this is how I got into the problem I posted about earlier; maybe some of the problems I ran into will mean more to the you and the experts on this thread, Dr

Re: [Rd] New version of Rtools for Windows

Very timely, as this is how I got into the problem I posted about earlier; maybe some of the problems I ran into will mean more to the you and the experts on this thread, Dr. Murdoch.For reference, I run Windows 7 64bit, and I am trying to build a 64 bit version of R-3.1.2. As we discussed

Re: [Rd] New version of Rtools for Windows

-- On Thu, Jan 8, 2015 2:01 PM GMT Henric Winell wrote: On 2015-01-08 14:18, Avraham Adler wrote: Very timely, as this is how I got into the problem I posted about earlier; maybe some of the problems I ran into will mean more to the you and the experts on this thread, Dr. Murdoch.For

[Rd] Failing lm-tests due to extra 0 in scientific notation?

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

Re: [Rd] Failing lm-tests due to extra 0 in scientific notation?

apologize for any unintentional implications. Avi On Wed, Jan 7, 2015 at 1:24 AM, Avraham Adler avraham.ad...@gmail.com wrote: 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

[Rd] Compiling R with ATLAS

Hello. I know almost nothing about Linux, so I apologize if the answer to this is obvious. I am trying to compile R with ATLAS (successfully compiled 3.9.24 on Ubuntu 10.04 64 bit). I configured with: ./configure --enable-R-shlib --enable-BLAS-shlib --with-blas=-L/usr/local/atlas/lib -lf77blas

Re: [Rd] Compiling R with ATLAS

of this for you. Take a look at http://cran.r-project.org/bin/linux/ubuntu for information on how to get started. It will probably be much easier to install the pre-compiled packages first and worry about compilation for customization later. On Thu, May 13, 2010 at 11:16 PM, Avraham Adler

[Rd] Fwd: Compiling R with ATLAS

, 2010 at 11:16 PM, Avraham Adler avraham.ad...@gmail.com wrote: Hello. I know almost nothing about Linux, so I apologize if the answer to this is obvious. I am trying to compile R with ATLAS (successfully compiled 3.9.24 on Ubuntu 10.04 64 bit). I configured with: ./configure --enable-R

<    1   2