similar to: Environment variables

Ok, thanks! I'm not dealing with UTF-8 so I don't think Process::GetEnv will work. I was looking for something that caches calls to getenv so checks could be put into tight(-ish) loops without too much performance impact. Would such a utility be of interest to the community? -David Reid Kleckner via llvm-dev <llvm-dev at lists.llvm.org> writes: >

Yes, but in your example getenv is called every time enableFooBar needs to be initialized. What if your code is itself wrapped inside another loop you can't see (for example, the PassManager invoking passes)? Maybe I'm being overly pedantic. We use a lot of environment variables in our compiler because it's really super annoying and takes a lot of developer time to have to update

Env vars that change compiler output make it impossible to write tools such as ccache or distcc. Including the entire env in the hash value that determines whether ccache has a cache hit (as well as the compiler command line and the preprocessed source file) would be ridiculous and would result in very few cache hits. On Thu, Sep 6, 2018 at 11:34 AM, Matthias Braun via llvm-dev < llvm-dev at

I noticed that many configuration options (configure.txt) have environment variable overrides. However, an important one does not. In the configuration.txt file, there is one section: Directories used by NUT at run-time ----------------------------------- --with-pidpath=PATH Changes the directory where pid files are stored. By default this is /var/run. Certain programs like upsmon will

>>>>> Tomas Kalibera >>>>> on Tue, 31 Jan 2023 10:53:21 +0100 writes: > On 1/31/23 09:48, Ivan Krylov wrote: >> Can we use the "bytes" encoding for such environment variables invalid >> in the current locale? The following patch preserves CE_NATIVE for >> strings valid in the current UTF-8 or multibyte locale (or

/Hello. SUMMARY: $ BOOM=$'\xFF' LC_ALL=en_US.UTF-8 Rscript --vanilla -e "Sys.getenv()" Error in substring(x, m + 1L) : invalid multibyte string at '<ff>' $ BOOM=$'\xFF' LC_ALL=en_US.UTF-8 Rscript --vanilla -e "Sys.getenv('BOOM')" [1] "\xff" BACKGROUND: I launch R through an Son of Grid Engine (SGE) scheduler, where the R

> On 31 Jan 2023, at 12:51 , Tomas Kalibera <tomas.kalibera at gmail.com> wrote: > > > On 1/31/23 11:50, Martin Maechler wrote: <snippage> >> hmm.., that's a pity; I had hoped it was a pragmatic and valid strategy, >> but of course you are right that type stability is really a >> valid goal.... >> >> In general, what about behaving close

On Windows, > Sys.getenv("MAKE") MAKE "" when (at a DOS prompt) X:>set MAKE Environment variable MAKE not defined On linux, > Sys.getenv("MAKE") MAKE "make" even when (in a shell) % echo $MAKE returns nothing. This has consequences, e.g., in buildVignette where system(Sys.getenv("MAKE")) dutifully does nothing on

Tomas, I think you're not addressing the actual issue which is a clear regression in Sys.getenv() [because it used to work and still works for single env var, but not a list] and the cryptic error due to that regression (caused by changes in R-devel). So in either case, Sys.getenv needs fixing (i.e., this should really go to the bugzilla). Its behavior is currently inconsistent. The quoted

To R-devel, In `R CMD build`, the ID of the user is automatically inserted into the DESCRIPTION file, e.g. Packaged: 2018-11-06 14:01:50 UTC; <MY USER ID> This is problematic for those of us who work in corporate settings. We must not divulge our user IDs in the packages we develop and release. Jim Hester pointed out that these two lines in `add_build_stamp_to_description_file()`

Dear all, I am trying to use multiple version of R unpacked from CRAN deb files. It does work successfully, except for some packages installation, whether Rscript has been used. I have configured alternatives and switch R environments without any problem and can install most of the packages. '====================================================== $ update-alternatives --display R R - auto

Environment variables set with Sys.putenv() disappear (i.e. become "") after a while, especially after heavy-duty I/O. Example: R> x <- matrix(1., 3000, 3000) R> save(x, file="myx.RData") R> Sys.putenv(HOME="/tmp") R> while (Sys.getenv("HOME") != "") {cat("ok\n"); load("myx.RData")} The loop prints

Thanks, Kurt. I think I now have enough time to write a patch. What are the steps? I have read https://www.r-project.org/bugs.html#how-to-submit-patches but I do not seem to have permission to create a Bugzilla account at https://bugs.r-project.org/bugzilla/. Will On Mon, Nov 12, 2018 at 2:46 AM Kurt Hornik <Kurt.Hornik at wu.ac.at> wrote: > >>>>> Will L writes: >

Hi All, I am developing a package that requires information about the location of a set of files that will be used often in the calculations. In my current version, I define the location in the main file that calls all the subfunctions. This works fine when you are installing from source, but will not work so well if I want people to be able to install binary versions of the package. Therefore, I

Hello! I want to detect some environment on a remote host (in C program, getenv()), but it is failed. Here is a little program which I try to run on a remote host with command: "#ssh myhost myecho" /* myecho */ #include <stdio.h> main (){ char *dir; if ((dir = getenv("MYDIR")) != NULL) printf ("environment is %s\n",dir);

The documentation for the OutDec option says that it should be a 'one-character string'; yet, if I try a unicode character, it doesn't seem to work. Are unicode chars not counted as one-character? This is within the mac GUI, but I also see this on linux boxes. > x <- '\u00B7' > nchar(x) [1] 1 > options(OutDec=x) Error in options(OutDec = x) : invalid value for

On 1/31/23 09:48, Ivan Krylov wrote: > Can we use the "bytes" encoding for such environment variables invalid > in the current locale? The following patch preserves CE_NATIVE for > strings valid in the current UTF-8 or multibyte locale (or > non-multibyte strings) but sets CE_BYTES for those that are invalid: > > Index: src/main/sysutils.c >

On 25/05/2015 11:37 AM, Ista Zahn wrote: > AFAIK this is the way it works on Windows. It has been discussed in several > places, e.g. > http://stackoverflow.com/questions/17715956/why-do-some-unicode-characters-display-in-matrices-but-not-data-frames-in-r > , > http://stackoverflow.com/questions/17715956/why-do-some-unicode-characters-display-in-matrices-but-not-data-frames-in-r

hi, i am working on a little R-project with a couple od other guys.we use CVS, but everyone keeps the R-source files in different locations in his home-directory. of course this causes trouble when sourcing R-files. i thought a UNIX environment variable could be the solution, but R doesn't seem to know about the environment variables. e.g. >> source("$PROJECT/xxx.R")

Here's a data frame with some Unicode symbols (set intersection and union). d <- data.frame(x = "A \u222a B \u2229 C") Printing this data frame under R 3.2.0 patched (r68378) and Windows 7, I see d ## x ## 1 A <U+222A> B n C Printing the column itself works fine. d$x ## [1] A ? B ? C ## Levels: A ? B ? C The encoding is correctly UTF-8.