similar to: .Rd file exists in 'man' directory, but R CMD CHECK results in warning

Hello, Here is one question regarding the LLVM TableGen: Which file in the llvm/lib/Target/X86 folder describes how the bits in the EFLAGS register are modified by the x86 instructions? For example, in the "X86InstrInfo.td" file, lines 2134-2135, it says: let SchedRW = [WriteALU], Defs = [EFLAGS], Uses = [EFLAGS] in { def CLC : I<0xF8, RawFrm, (outs), (ins), "clc",

On 2015-12-30 09:58, Michael Felt wrote: > On 2015-12-29 11:02, Michael Felt wrote: >> This seems to be a problem that goes back a long time - and I hope >> someone who understands what tre is suppossed to be doing will look >> at this. >> >> A short history of other people who have reported on this on >> different versions of AIX. I shall only add that I

Ok, found the problem - on platforms that support it TRE uses wint_t (from wchar.h) as its type for characters (tre_cint_t) which on AIX is *signed* int. TRE uses liberally conversions between int and tre_cint_t apparently assuming that the latter is unsigned so conversions back to int are suitable for comparisons etc. On other platforms wint_t is unsigned so it works. Manually defining tre_cint_t

This seems to be a problem that goes back a long time - and I hope someone who understands what tre is suppossed to be doing will look at this. A short history of other people who have reported on this on different versions of AIX. I shall only add that I get the same results on AIX 5.3 TL7, AIX 6.1 TL9 and AIX 7.1 TL3. Basically, with settings that work for AIX and 32-bit - the only changes

Dear developeRs, my package FrF2.catlg128 holds large catalogues and is supposed to gain additional ones. All the catalogues are intended for the user. So far, the catalogues were stored in the data directory, and LazyData was "no". I understand that this is not considered wise any more (if it ever was), so that I want to change to LazyData "yes" with the next release

Hi, to speed up computations in our RobASt family of packages, we use interpolation on a grid of precomputed values which we save together with the interpolating functions (results of splinefun essentially) in sysdata.rda in the R folder of our pkg. After adding grids for some more models, this file has grown considerably, even after application of tools::resaveRdaFiles. At the moment we are at

On 2016-01-01 23:48, peter dalgaard wrote: > Nice catch you two!!! > > Happy New Year > -pd I am much happier with this great start! Simon - which compiler)s) did you use: xlc and xlfortran, or gcc/gfortran? I have made some changes to configure(.ac) so maybe my problems are self-inflicted. But would be good to know what environment you are using. Thanks for looking - and

Hi everyone, I hope I'm not repeating someone else, but I am having trouble with my R installation on my MacBook with OS X Universal. I get this error when R starts up: 2006-08-30 10:53:50.222 R[1021] *** -[NSBundle load]: Error loading code /Users/clc/Library/InputManagers/Smart Crash Reports/Smart Crash Reports.bundle/Contents/MacOS/Smart Crash Reports for bundle /Users/

I have been struggling with this error message - and think I finally understand it's context. Start Line by line debugging shows me the function works: ... > saveRDS(val, mapfile) > val $variables $variables$IANA_HTTP_status_code_db [1] 0 1256 $variables$IANA_URI_scheme_db [1] 1256 3458 $variables$table_of_HTTP_status_codes [1] 4714 830 $references named list() $compressed

I would be "pleased" if you would try packages - i.e., none of "Toolbox" or Perzl rpm's. The iconv I supply might not be working as is (I will need to install a new system to check). However, this is why I have been testing with R-3.2.3 - to side-step the system library dependencies. re: xz - I have "installp" version - and any of my packages should work

On 17/12/2015 9:06 AM, Michael Felt wrote: > More experimenting with calling commands: > > tools:::foobar() > Error: Line starting 'Package: tools ...' is malformed! > > tools::foobar() > Error: Line starting 'Package: tools ...' is malformed! These both do a loadNamespace("tools"). > > Tools:::foobar() > Error in loadNamespace(name)

Hi, I am getting a strange error with 15.0 which I've not seen with previous versions of R. If sysdata.rda is included in R directory of the package I am getting: R CMD build betfairly.roxygen/ * checking for file ?betfairly.roxygen/DESCRIPTION? ... OK * preparing ?betfairly?: * checking DESCRIPTION meta-information ... OK * excluding invalid files Subdirectory 'R' contains invalid

A couple of my colleagues are having problems building R-3.2.4 on Mac OS X El Capitan somehow related to libiconv. I personally don't have any problems on either of my Macs. I'm hoping thie make log might trigger something in the readers of this list: gcc -dynamiclib -Wl,-headerpad_max_install_names -undefined dynamic_lookup -single_module -multiply_defined suppress -L../../../../lib

Hi, This problem started as of r73472 ("Merged in the rest of the basic ALTREP framework."); I tested r73471 and it did not exist. I'm building R devel on Ubuntu 16.04.3 LTS (64-bit), with the following flags: CC="gcc -std=gnu99 -fsanitize=address -fno-omit-frame-pointer" CFLAGS="-fno-omit-frame-pointer -g -O2 -Wall -pedantic -mtune=native" and using

Dear list, I'm following the instructions provided here to compile R 64 bit on AIX 6.1. I did export OBJECT_MODE=64 export CC="gcc -maix64 -pthread" export CXX="g++ -maix64 -pthread" export FC="gfortran -maix64 -pthread" export F77="gfortran -maix64 -pthread" export CFLAGS="-O2 -g -mcpu=power6" export FFLAGS="-O2 -g -mcpu=power6"

The R 4.0.0 package migration on Debian is being held back by a failed build on ppc64el [1]. We can see from the history of builds logs [2] that it used to build, briefly failed, worked again and then failed leading to R 4.0.0's release. (And my bad for missing how the alpha1/alpha2/beta/rc builds failed.) I have however neither changed anything, nor did I ever have to accomodate ppc64el (as

Hope I am not sounding too much like a broken record - as far as 64-bit build on AIX is concerned. ** Short - 32-bit builds complete normally, 64-bit builds stop at "installing 'sysdata.rda'" with message: Error: Line starting 'Package: tools ...' is malformed! Execution halted *** Longer... I could file a bug - Importance, showstopper - but I would prefer to better

Hi all, I'm struggling with accessing a package dataset (munsell.map, stored in sysdata.rda) when that package is imported, not required. A simple reproducible example is: install.packages("munsell") munsell::mnsl("10B 4/6") # Error in match(col, munsell.map$name) : object 'munsell.map' not found library(munsell) munsell::mnsl("10B 4/6") # Function

Thanks, Luke, for having a look to it. Sure, I can give you some reproducible example -- even in two degrees of completeness ;-): see below. Thanks again, Peter %----------------------------------- (I) first example %----------------------------------- Just to reproduce the error, on r-devel, try: install.packages("RobAStRDA") require(RobAStRDA) getFromNamespace(".RMXE", ns

On 30 April 2020 at 09:11, luke-tierney at uiowa.edu wrote: | On Thu, 30 Apr 2020, Dirk Eddelbuettel wrote: | Maybe I missed something. How is the 'compiler' package involved? See the other email thread; you replied (~ 26 hours ago) to my message adding that "sysdata.rda in 'tools' hanging was wrong". It gets to the next stage, which is 'compiler'. We know by