search for: visibility

Dear R People: Hello! I'm putting together another RcmdrPlugin package and need to add a FORTRAN subroutine to speed things up a bit. I've never added compiled code to a package. Anyhow, I put my code into a /src directory. Here are the statements: * using log directory 'c:/R/R-2.11.1/bin/RcmdrPlugin.push.Rcheck' * using R version 2.11.1 (2010-05-31) * using session charset:

Are the messages below to be expected from make check-all ? using the rc today, Aug 21, on Red Hat Enterprise Linux AS release 4 (Nahant Update 4) Kernel 2.6.9-42.0.8.ELsmp on an x86_64 Paul ________ .... checking package 'utils' .... * checking R code for possible problems ... NOTE install.packages: no visible global function definition for ?.install.winbinary? install.packages: no

Hi all, I am a RoR newbie and have the following scenario set up: There are 2 ActiveRecords involved, the first one being "User", the second one being "Visibility". The corresponding users table holds address informations regarding a User. The visibilities table holds visibility settings for the individual columns of the users table (i.e. firstname, lastname, country should be visible to everybody while the credit card data should be only visible t...

when I try to make a package coping R code such as tab1, summ, titleString, setTitle from epicalc package, the following problems are found. * using log directory 'C:/Rpackage/EpiStat.Rcheck' * using R version 2.10.0 (2009-10-26) * using session charset: ISO8859-1 * checking for file 'EpiStat/DESCRIPTION' ... OK * checking extension type ... Package * this is package

...ow, there are a number of things about linkage that are kindof orthogonal, >> and it would be nice to model them more orthogonally. That would be a major >> change in representation, though. Absent the will to do that, I propose >> that we: >> - remove/deprecate protected visibility, making visibility purely a hidden >> vs. non-hidden flag > > This would prevent us from propagating > __attribute__((visibility("protected")) to a STV_PROTECTED in the .o, > so I don't think we should do it. The whole point of this proposal is to get us to a state...

...up and I create some test cases. RFC: Safe Whole Program Devirtualization Enablement =================================================== High Level Summary ------------------ The goal of the changes described in this RFC is to support aggressive Whole Program Devirtualization without requiring -fvisibility=hidden at compile time, by pre-enabling bitcode for whole program devirtualization, but delaying the decision on whether to apply devirtualization until LTO link time. This is needed both because we may not know whether the link mode is safe for hidden LTO visibility until link time, and also to al...

Hi, I am trying to use 'GridR' package for the first time, and I'm running into a strange error from grid.check: > grid.check(gridFun) Error in exists(add) : invalid first argument After playing around in recover mode, I see that this because the variable 'add' created by grid.check is blank: Browse[1]> split[[1]][k] [1] " : " Browse[1]> add [1]

Recently I started getting these warnings - thousands of them - and I'm not sure what I did to cause them or how to solve them: ld: warning llvm::MemoryBuffer::getBufferStart() const has different visibility (1) in /usr/local/lib/libLLVMSupport.a(MemoryBuffer.o) and (2) in /usr/local/lib/libLLVMSupport.a(CommandLine.o) ld: warning llvm::OwningPtr<llvm::MemoryBuffer>::OwningPtr(llvm::MemoryBuffer*)has different visibility (1) in /usr/local/lib/libLLVMSupport.a(MemoryBuffer.o) and (2) in /usr/...

Hello, JIT compiler interferes with internal R completions: compiler::enableJIT(2) utils:::functionArgs("density", '') gives: utils:::functionArgs("density", '') Note: no visible global function definition for 'bw.nrd0' Note: no visible global function definition for 'bw.nrd' Note: no visible global function definition for 'bw.ucv'

...or evalq(x <- 2) gives the same effect as x <- 2 . The result is invisible. In function 'eval2', res <- eval(withVisible(expr), envir=envir, ...) is effectively res <- withVisible(expr) . ------------------- Would it be possible to have the value of eval() preserve the "visibility" of the value of the expression? "PROBLEM": # Invisible > x <- 1 # Visible > eval(x <- 2) [1] 2 "TROUBLESHOOTING": > withVisible(x <- 1) $value [1] 1 $visible [1] FALSE > withVisible(eval(x <- 2)) $value [1] 2 $visible [1] TRUE WORKAROUND: ev...

Would it be possible to have the value of eval() preserve the "visibility" of the value of the expression? "PROBLEM": # Invisible > x <- 1 # Visible > eval(x <- 2) [1] 2 "TROUBLESHOOTING": > withVisible(x <- 1) $value [1] 1 $visible [1] FALSE > withVisible(eval(x <- 2)) $value [1] 2 $visible [1] TRUE WORKAROUND: e...

...ev/2008-August/016763.html On 2008-09-05, at 22:46, Talin wrote: > Recently I started getting these warnings - thousands of them - and > I'm > not sure what I did to cause them or how to solve them: > > ld: warning llvm::MemoryBuffer::getBufferStart() const has different > visibility (1) in /usr/local/lib/libLLVMSupport.a(MemoryBuffer.o) and > (2) in /usr/local/lib/libLLVMSupport.a(CommandLine.o) > ld: warning > llvm::OwningPtr<llvm::MemoryBuffer>::OwningPtr(llvm::MemoryBuffer*)has > different visibility (1) in > /usr/local/lib/libLLVMSupport.a(MemoryBuffer...

Hello, I have a question about addTaskCallback It is said that the argument visible allows to know wether the result of the top-level evaluation was printed or not. Nevertheless, in the following example, I encountered a problem, as it seems not all printed objects are visible... Could someone tell me where is the tip? TIA

Dear R-Helpers, I suspect I'm about to ask a FAQ, but I haven't been able to find an answer in the FAQ, AItR or an R Site Search. When I look at the methods of summary (below) it says, "Non-visible functions are asterisked". I looked at the help file for summary.princomp, which did not comment on it being non-visible. I ran its help file example, which printed visible output. I

Hi! I have a question about whole program devirtualization pass. According to my understanding devirtualization is performed only for the classes that have hidden LTO visibility and this visibility is controlled by attributes in the source level or command line options. So visibility analysis is currently performed only in the front-end. But LLVM has LTO internalization pass that uses information from the linker to mark symbols as internal if it is possible. Have you eve...

I am using some constants that should be visible in the controller and in a view. Declaring the constant in the controller does not make the constant visible in the view. So my question: Where can I declare the constant to be visible in all views and controllers ? Thanks a lot in advance Christian -- Posted via http://www.ruby-forum.com/.

Dear list, This is related to the change discussed in the thread "no visible binding for global variables for data sets in a package". I went to look at the Check results for one of my packages (analogue) on CRAN: http://cran.r-project.org/web/checks/check_results_analogue.html Under the r-devel build machines I'm seeing a lot of things like this: Stratiplot.default :

I'm updating the Lahman package of baseball statistics to the 2013 release. In addition to the main data sets, the package also contains several convenience functions that make use of these data sets. These now trigger the notes below from R CMD check run with Win builder, R-devel. How can I avoid these? * using R Under development (unstable) (2014-08-25 r66471) * using platform:

...t 9:41 AM, John McCall <rjmccall at apple.com <mailto:rjmccall at apple.com>> wrote: > Okay, so, it sounds to me like LLVM basically treats strong definitions as protected, then. Should we just formalize that? > > I guess the proposal here would be: > 1. Remove protected visibility from LLVM. (Or deprecate it as equivalent to default.) > 2. Teach the ELF emitter to emit non-hidden strong definitions using ELF protected visibility. > 3. Teach the ELF emitter to emit non-hidden weak definitions using ELF default visibility (unless they’re unnamed_addr?). > > L...

On Tue, Feb 17, 2015 at 1:55 PM, Sedat Dilek <sedat.dilek at gmail.com> wrote: > On Tue, Feb 17, 2015 at 10:40 AM, Marc Dietrich <marvin24 at gmx.de> wrote: >> Patch 1 adds a check for the compilers visibility macro to configure.ac. >> Patch 2 avoids redefined symbol errors in clang of the tls entry points. >> Based on a suggestion from Rafael Ávila de Espíndola <rafael.espindola at gmail.com> >> in http://llvm.org/bugs/show_bug.cgi?id=19778. >> >> Tested with gcc 4.9...