Re: [Rd] suggestion to fix packageDescription() for Windows users
> Nathan Sosnovske via R-devel
> on Mon, 26 Jun 2017 18:22:25 + writes:
> I'd be curious to know what others think of Rich's
> patch. If it is acceptable, I can spend time that I was
> going to look at it this week on another bug.
It is a bit kludgy (*) of course, but I confirm it solves the
problem in a "robust" way.
*) Of course I'd hoped you'd find why the underlying
packageDescription() function is not "getting the right thing" in this
case directly -- in Windows only in some locales -- and provide a
Windows-only patch for the underlying problem there, rather than
the workaround patch in citation().
The patch does solve the problem at hand, alright, so thank you,
Rich and Nathan!
Note that Duncan Murdoch did mention in this thread to file
an official bug report and Ben Marwick gave the URL
> From: Ben Marwick ...
> Subject: Re: [Rd] suggestion to fix packageDescription() for Windows users
> Date: Sun, 18 Jun 2017 08:34:56 +1000
> Thanks very much, I see your bug report here:
> https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=17291
so ideally almost all of this follow up should have happened there.
I have followed up there and also there attached a Windows-only
+ commented version of Rich's patch. As mentioned, I've tested
it and confirmed to work for the use case in the mean time, so
plan to commit soon.
This will be too late for the release of R 3.4.1 tomorrow,
of course [code freeze was on June 23].
Martin Maechler
ETH Zurich
> -Original Message-
> From: Rich Calaway
> Sent: Friday, June 23, 2017 6:34 PM
> To: Nathan Sosnovske ; Duncan Murdoch
; Andrie de Vries
> Cc: Ben Marwick ; R-devel Mailing List
(r-devel@r-project.org)
> Subject: RE: [Rd] suggestion to fix packageDescription() for Windows users
> The following patch is not the most elegant, but it restores the Authors
when "LC_CTYPE" is set to either "Chinese" or "Arabic":
>> Sys.setlocale("LC_CTYPE", "Chinese")
> [1] "Chinese (Simplified)_China.936"
>> citation("readr")
> To cite package ‘readr’ in publications use:
> (2016). readr: Read Tabular Data. R package version 1.0.0.
> https://CRAN.R-project.org/package=readr
> A BibTeX entry for LaTeX users is
> @Manual{,
> title = {readr: Read Tabular Data},
> year = {2016},
> note = {R package version 1.0.0},
> url = {https://CRAN.R-project.org/package=readr},
> }
> ATTENTION: This citation information has been auto-generated from the
package DESCRIPTION file and may need manual editing, see ‘help("citation")’.
>> Sys.setlocale("LC_CTYPE", "Arabic")
> [1] "Arabic_Saudi Arabia.1256"
>> citation("readr")
> To cite package ‘readr’ in publications use:
> (2016). readr: Read Tabular Data. R package version 1.0.0.
> https://CRAN.R-project.org/package=readr
> A BibTeX entry for LaTeX users is
> @Manual{,
> title = {readr: Read Tabular Data},
> year = {2016},
> note = {R package version 1.0.0},
> url = {https://CRAN.R-project.org/package=readr},
> }
> ATTENTION: This citation information has been auto-generated from the
package DESCRIPTION file and may need manual editing, see ‘help("citation")’.
>> citation <- newCitation
>> citation("readr")
> To cite package ‘readr’ in publications use:
> Hadley Wickham, Jim Hester and Romain Francois (2016). readr: Read
> Tabular Data. R package version 1.0.0.
> https://CRAN.R-project.org/package=readr
> A BibTeX entry for LaTeX users is
> @Manual{,
> title = {readr: Read Tabular Data},
> author = {Hadley Wickham and Jim Hester and Romain Francois},
> year = {2016},
> note = {R package version 1.0.0},
> url = {https://CRAN.R-project.org/package=readr},
> }
> The patch is:
> Index: citation.R
> ===
> --- citation.R(revision 72852)
> +++ citation.R(working copy)
> @@ -1162,8 +1162,11 @@
> if(dir == "")
> stop(gettextf("package %s not found", sQuote(package)),
> domain = NA)
> -meta <- packageDescription(pkg = package,
> - lib.loc = dirname(dir))
> + args <- list(pkg = package, lib.loc = dirname(dir))
> + if (!is.na(enc <- packageDescription(pkg = package,
lib.loc=dirname(dir), field="Encoding")))
> + args$enc <- enc
> +meta <- do.call("packageDescription", args=args)
> +
> ## if(is.null(auto)): Use default auto-citation if no CITATION
> ## available.
> citfile <- file.path(dir, "CITATION")
> Nathan says he can look into this further next week...
> Cheers,
> Rich Calaway
> Microsoft R Product Team
> 24/1341
> +1 (425) 4219919 X19919
> -Original Message-
> From: R-devel [mailto:r-devel-boun...@r-project.org] On Behalf Of Nathan
Sosnovske v
[Rd] paste strings in C
Dear R-devs,
Below is a small example of what I am trying to achieve, that is trivial in
R and I would like to learn how to do in C, for very large matrices:
> (mymat <- matrix(c(1,0,0,2,2,1), nrow = 2))
[,1] [,2] [,3]
[1,]102
[2,]021
And I would like to produce:
[1] "a*C" "B*c"
Which can be trivially done in R via something like:
foo <- function(mymat, colnms, tilde = FALSE) {
apply(mymat, 1, function(x) {
if (tilde) {
colnms[x == 1] <- paste0("~", colnms[x == 1])
} else {
colnms[x == 1] <- tolower(colnms[x == 1])
}
paste(colnms[x > 0], collapse = "*")
})
}
> foo(mymat, LETTERS[1:3])
[1] "a*C" "B*c"
> foo(mymat, LETTERS[1:3], tilde = TRUE)
[1] "~A*C" "B*~C"
I know that strings in C are far from trivial (encodings being one
important issue), and this is the sort of thing much easier to do in R. On
the other hand I found that, for a large matrix of say 1 million rows and
25 columns, setting the rownames of colnames in R copies the matrix and
costs a lot of memory and time in the process.
Having all necessary headers in C, the solution I came up with involves
calling the function foo() from within C:
SEXP test(SEXP mymat, SEXP colnms, SEXP tilde) {
SEXP call = PROTECT(LCONS(install("foo"),
LCONS(mymat,
LCONS(colnms,
LCONS(tilde, R_NilValue);
SEXP out = PROTECT(eval(call, R_GlobalEnv));
UNPROTECT(2);
return(out);
}
After compilation, say in a file called test.c, back in R I get:
> dyn.load("test.so")
> .Call("test", mymat, LETTERS[1:3], FALSE)
[1] "a*C" "B*c"
> .Call("test", mymat, LETTERS[1:3], TRUE)
[1] "~A*C" "B*~C"
In my real situation, the matrix I am working on is produced in the C code
(and it's much larger).
I don't know for sure, when calling the R function foo(), if the matrix is
copied: if not, this might be the best solution for me.
Otherwise I know there is a function do_paste() in C, and wondered whether
I could use that directly instead of calling R from C.
I hope this explains what I would like to do, many thanks in advance for
any hint,
Adrian
--
Adrian Dusa
University of Bucharest
Romanian Social Data Archive
Soseaua Panduri nr. 90-92
050663 Bucharest sector 5
Romania
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] paste strings in C
To do this in C, it would probably be easier and faster to just do the
string manipulation directly. Luckily, there are already packages that
have done this for you. See an example below using the S4Vectors
package.
foo2 <- function(mymat, colnms, tilde=FALSE) {
chars <- colnms[col(mymat)]
lowerChars <- if (tilde) paste0("~", chars) else tolower(chars)
chars <- ifelse(mymat==1L, lowerChars, chars)
keep <- mymat > 0L
charList <- split(chars[keep], row(chars)[keep])
S4Vectors::unstrsplit(charList, "*")
}
Or perhaps more efficient using the compressed lists of IRanges:
foo3 <- function(mymat, colnms, tilde=FALSE) {
mymat <- t(mymat)
chars <- colnms[row(mymat)]
lowerChars <- if (tilde) paste0("~", chars) else tolower(chars)
chars <- ifelse(mymat==1L, lowerChars, chars)
keep <- mymat > 0L
charList <- IRanges::splitAsList(chars[keep], col(chars)[keep])
S4Vectors::unstrsplit(charList, "*")
}
Michael
On Tue, Jun 27, 2017 at 5:29 AM, Adrian Dușa wrote:
> Dear R-devs,
>
> Below is a small example of what I am trying to achieve, that is trivial in
> R and I would like to learn how to do in C, for very large matrices:
>
>> (mymat <- matrix(c(1,0,0,2,2,1), nrow = 2))
> [,1] [,2] [,3]
> [1,]102
> [2,]021
>
> And I would like to produce:
> [1] "a*C" "B*c"
>
>
> Which can be trivially done in R via something like:
>
> foo <- function(mymat, colnms, tilde = FALSE) {
> apply(mymat, 1, function(x) {
> if (tilde) {
> colnms[x == 1] <- paste0("~", colnms[x == 1])
> } else {
> colnms[x == 1] <- tolower(colnms[x == 1])
> }
> paste(colnms[x > 0], collapse = "*")
> })
> }
>
>> foo(mymat, LETTERS[1:3])
> [1] "a*C" "B*c"
>
>> foo(mymat, LETTERS[1:3], tilde = TRUE)
> [1] "~A*C" "B*~C"
>
>
> I know that strings in C are far from trivial (encodings being one
> important issue), and this is the sort of thing much easier to do in R. On
> the other hand I found that, for a large matrix of say 1 million rows and
> 25 columns, setting the rownames of colnames in R copies the matrix and
> costs a lot of memory and time in the process.
>
> Having all necessary headers in C, the solution I came up with involves
> calling the function foo() from within C:
>
> SEXP test(SEXP mymat, SEXP colnms, SEXP tilde) {
>
> SEXP call = PROTECT(LCONS(install("foo"),
> LCONS(mymat,
> LCONS(colnms,
> LCONS(tilde, R_NilValue);
>
> SEXP out = PROTECT(eval(call, R_GlobalEnv));
>
> UNPROTECT(2);
> return(out);
> }
>
>
> After compilation, say in a file called test.c, back in R I get:
>
>> dyn.load("test.so")
>
>> .Call("test", mymat, LETTERS[1:3], FALSE)
> [1] "a*C" "B*c"
>
>> .Call("test", mymat, LETTERS[1:3], TRUE)
> [1] "~A*C" "B*~C"
>
>
> In my real situation, the matrix I am working on is produced in the C code
> (and it's much larger).
> I don't know for sure, when calling the R function foo(), if the matrix is
> copied: if not, this might be the best solution for me.
>
> Otherwise I know there is a function do_paste() in C, and wondered whether
> I could use that directly instead of calling R from C.
>
> I hope this explains what I would like to do, many thanks in advance for
> any hint,
> Adrian
>
> --
> Adrian Dusa
> University of Bucharest
> Romanian Social Data Archive
> Soseaua Panduri nr. 90-92
> 050663 Bucharest sector 5
> Romania
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Windows iconv() "failure" in certain locales
This is a continuation of the R-devel thread with subject
"suggestion to fix packageDescription() for Windows users" :
As I said there, a patch should rather address the underlying
problem in packageDescription rather than a kludgy workaround
patch for citation().
(For that same reason, Ben Marwick proposed to fix
packageDescription() rather than the symptom seen in citation().)
It's not hard to see that the problem is that iconv() in
Windows does not always succeed to translate from "UTF-8" to the
"current locale", in the case mentioned there.
I'm giving some easier reproducible examples: no need to install
half of tidyverse just to get citation("readr") :
> x <- c("Ekstr\xf8m", "J\xf6reskog", "bi\xdfchen Z\xfcrcher")
> Encoding(x1) <- "latin1"
> xU <- iconv(x1, "latin1", "UTF-8")
> Sys.setlocale("LC_CTYPE", "Chinese")
[1] "Chinese (Simplified)_People's Republic of China.936"
>
> iconv(x1, "latin1", "") # NA NA NA
[1] NA NA NA
> iconv(xU, "UTF-8", "") # NA NA NA
[1] NA NA NA
> iconv(xU, "UTF-8", "//TRANSLIT")
[1] "Ekstrøm" "Jöreskog""bißchen Zürcher"
> iconv(xU, "UTF-8", "", sub = "byte")
[1] "Ekstrm" "Jreskog""bi<9f>chen Z¨¹rcher"
> Sys.setlocale("LC_CTYPE", "Arabic")
[1] "Arabic_Saudi Arabia.1256"
> iconv(x1, "latin1", "") # NA NA NA
[1] NA NA NA
> iconv(xU, "UTF-8", "") # NA NA NA
[1] NA NA NA
> iconv(xU, "UTF-8", "//TRANSLIT")
[1] "Ekstr\370m" "J\366reskog""bißchen Zürcher"
> iconv(xU, "UTF-8", "", sub="byte")
[1] "Ekstrm" "Jreskog""bi<9f>chen Zürcher"
> iconv(xU, "UTF-8", "", sub="?")
[1] "Ekstr??m" "J??reskog""bi??chen Zürcher"
Etc... . As the above is typically garbled between e-mail
transfer agents, I append both the iconv-Windows.R R script and
the corresponding iconv-Windows.Rout R transcript to this
e-mail (using MIME type text/plain (easy using emacs for mail..)),
and they contain a bit more than the above.
Note that the above shows that using 'sub = *' and using
"//TRANSLIT" in case of a previous NA result helps quite a bit,
in the sense that it gives much more information to see
"J?reskog" instead NA.
I'm considering updating packageDescription() to try these in
case it first returns NA. This would make the citation() hack
unnecessary.
Martin
iconv() behavior depending on Locales LC_CTYPE in Windows
=== ==
###
### In a *shell* in Windows (emacs), after doing R.home() in R, use that to do
something like
### c:/PROGRA~1/R/R-devel/bin/R CMD BATCH iconv-Windows.R
### ^^= === = === ==> producing
iconv-Windows.Rout
###
sessionInfo() ## does not matter so much
## -- should be Windows to exhibit the problems
## From help(iconv) 's example : Using "latin1" European language letters:
x1 <- c("Ekstr\xf8m", "J\xf6reskog", "bi\xdfchen Z\xfcrcher")
Encoding(x1) <- "latin1"
xU <- iconv(x1, "latin1", "UTF-8")
## 2 locales that do not work well : -
Sys.setlocale("LC_CTYPE", "Chinese")
iconv(x1, "latin1", "") # NA NA NA
iconv(x1, "latin1", "//TRANSLIT") # perfect for Chinese
iconv(x1, "latin1", "", sub = "byte")
iconv(xU, "UTF-8", "") # NA NA NA
iconv(xU, "UTF-8", "//TRANSLIT")
iconv(xU, "UTF-8", "", sub = "byte")
##--
Sys.setlocale("LC_CTYPE", "Arabic")
iconv(x1, "latin1", "") # NA NA NA
iconv(x1, "latin1", "//TRANSLIT") # not bad, but not perfect
iconv(x1, "latin1", "", sub="byte")
iconv(x1, "latin1", "", sub="?")
iconv(xU, "UTF-8", "") # NA NA NA
iconv(xU, "UTF-8", "//TRANSLIT")
iconv(xU, "UTF-8", "", sub="byte")
iconv(xU, "UTF-8", "", sub="?")
## 2 locales that work well for these examples (no wonder) ---
Sys.setlocale("LC_CTYPE", "German_Switzerland")
iconv(x1, "latin1", "")
iconv(x1, "latin1", "//TRANSLIT")
iconv(x1, "latin1", "", sub="?")
iconv(xU, "UTF-8", "")
iconv(xU, "UTF-8", "//TRANSLIT")
iconv(xU, "UTF-8", "", sub="?")
##--
Sys.setlocale("LC_CTYPE", "English")
iconv(x1, "latin1", "")
iconv(x1, "latin1", "//TRANSLIT")
iconv(x1, "latin1", "", sub="?")
iconv(xU, "UTF-8", "")
iconv(xU, "UTF-8", "//TRANSLIT")
iconv(xU, "UTF-8", "", sub="?")
R Under development (unstable) (2017-06-25 r72854) -- "Unsuffered Consequences"
Copyright (C) 2017 The R Foundation for Statistical Computing
Platform: x86_64-w64-mingw32/x64 (64-bit)
R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.
R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.
Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.
> iconv() behavior depending on Locales LC_CTYPE in Windows
> === ==
> ###
>
Re: [Rd] paste strings in C
Hi Michael, On Tue, Jun 27, 2017 at 5:31 PM, Michael Lawrence wrote: > > To do this in C, it would probably be easier and faster to just do the > string manipulation directly. Luckily, there are already packages that > have done this for you. See an example below using the S4Vectors > package. Thank you for your reply. The goal is to obtain those strings in C, not in R... The result is returned to R just for printing purposes, but I need the strings in C. And if at all possible, using C functions directly rather than calling R functions from C. My first instinct is to try using the do_paste() C function in the src/main/ directory from the R sources, but I haven't been successful so far. Adrian -- Adrian Dusa University of Bucharest Romanian Social Data Archive Soseaua Panduri nr. 90-92 050663 Bucharest sector 5 Romania [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] suggestion to fix packageDescription() for Windows users
> *) Of course I'd hoped you'd find why the underlying
> packageDescription() function is not "getting the right thing" in this case
> directly -- in Windows only in some locales -- and provide a Windows-only
> patch for the underlying problem there, rather than the workaround patch in
> citation().
> The patch does solve the problem at hand, alright, so thank you, Rich and
> Nathan!
This makes sense. I was asking if we wanted to proceed with the
workaround-esque patch Rich suggested because I was trying to understand what
was more useful to the community: diving deeper into the issue to see what was
going on, or spending that time on another issue that was symptomatic. Either
way, I think it makes sense to fix the underlying issue at some point and I do
have time set aside this week to do so.
> so ideally almost all of this follow up should have happened there.
Apologies about this. I'm still learning and appreciate the gentle correction. 😊
-Original Message-
From: Martin Maechler [mailto:maech...@stat.math.ethz.ch]
Sent: Tuesday, June 27, 2017 3:34 AM
To: Nathan Sosnovske
Cc: Rich Calaway ; Duncan Murdoch
; Andrie de Vries ; R-devel
Mailing List (r-devel@r-project.org) ; Ben Marwick
; Martin Maechler
Subject: Re: [Rd] suggestion to fix packageDescription() for Windows users
> Nathan Sosnovske via R-devel
> on Mon, 26 Jun 2017 18:22:25 + writes:
> I'd be curious to know what others think of Rich's
> patch. If it is acceptable, I can spend time that I was
> going to look at it this week on another bug.
It is a bit kludgy (*) of course, but I confirm it solves the problem in a
"robust" way.
*) Of course I'd hoped you'd find why the underlying
packageDescription() function is not "getting the right thing" in this case
directly -- in Windows only in some locales -- and provide a Windows-only patch
for the underlying problem there, rather than the workaround patch in
citation().
The patch does solve the problem at hand, alright, so thank you, Rich and
Nathan!
Note that Duncan Murdoch did mention in this thread to file an official bug
report and Ben Marwick gave the URL
> From: Ben Marwick ...
> Subject: Re: [Rd] suggestion to fix packageDescription() for Windows
> users
> Date: Sun, 18 Jun 2017 08:34:56 +1000
> Thanks very much, I see your bug report here:
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.
> r-project.org%2Fbugzilla3%2Fshow_bug.cgi%3Fid%3D17291&data=02%7C01%7Cn
> sosnov%40microsoft.com%7Ce3ed6ea675b44c908c9208d4bd4817dc%7C72f988bf86
> f141af91ab2d7cd011db47%7C1%7C0%7C636341564724082662&sdata=AFG8tyP5Maqc
> iZwYFqBZ4wylbVJAoyWu4kASsxFZr%2F4%3D&reserved=0
so ideally almost all of this follow up should have happened there.
I have followed up there and also there attached a Windows-only
+ commented version of Rich's patch. As mentioned, I've tested
it and confirmed to work for the use case in the mean time, so plan to commit
soon.
This will be too late for the release of R 3.4.1 tomorrow, of course [code
freeze was on June 23].
Martin Maechler
ETH Zurich
> -Original Message-
> From: Rich Calaway
> Sent: Friday, June 23, 2017 6:34 PM
> To: Nathan Sosnovske ; Duncan Murdoch
; Andrie de Vries
> Cc: Ben Marwick ; R-devel Mailing List
(r-devel@r-project.org)
> Subject: RE: [Rd] suggestion to fix packageDescription() for Windows users
> The following patch is not the most elegant, but it restores the Authors
when "LC_CTYPE" is set to either "Chinese" or "Arabic":
>> Sys.setlocale("LC_CTYPE", "Chinese")
> [1] "Chinese (Simplified)_China.936"
>> citation("readr")
> To cite package ‘readr’ in publications use:
> (2016). readr: Read Tabular Data. R package version 1.0.0.
>
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2FCRAN.R-project.org%2Fpackage%3Dreadr&data=02%7C01%7Cnsosnov%40microsoft.com%7Ce3ed6ea675b44c908c9208d4bd4817dc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636341564724082662&sdata=C91aZ4qu2CT56qCrqFFBshREabZzfkaLXAABgWQSvXg%3D&reserved=0
> A BibTeX entry for LaTeX users is
> @Manual{,
> title = {readr: Read Tabular Data},
> year = {2016},
> note = {R package version 1.0.0},
> url =
{https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2FCRAN.R-project.org%2Fpackage%3Dreadr&data=02%7C01%7Cnsosnov%40microsoft.com%7Ce3ed6ea675b44c908c9208d4bd4817dc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636341564724082662&sdata=C91aZ4qu2CT56qCrqFFBshREabZzfkaLXAABgWQSvXg%3D&reserved=0},
> }
> ATTENTION: This citation information has been auto-generated from the
package DESCRIPTION file and may need manual editing, see ‘help("citation")’.
>> Sys.setlocale("LC_CTYPE", "Arabic")
> [1] "Arabic_Saudi Arabia.1256"
>> citation("readr")
> To cite package ‘readr’ in publications use:
> (2016). readr: Read Tabular Data. R package version 1.0.0.
>
https://na
[Rd] texi2pdf doesn't find the correct MikTex installation due to erroneous Sys.which()
I checked after this question popped up on Stackoverflow:
https://stackoverflow.com/questions/44785961/compile-pdf-in-rstudio-works-but-knit2pdf-does-not-work-in-r-or-rstudio
On Windows, texi2pdf looks for the texify.exe of Miktex, but looks in a
very wrong place:
> Sys.which("texify")
texify
"C:\\PROGRA~1\\MIKTEX~1.9\\miktex\\bin\\x64\\texify.exe"
That folder is not on my computer (I have 2.9 installed), not in my path,
not in my system path and I couldn't find it in my register. So it appears
as if Sys.which() is looking in the wrong place.
What could cause this?
Kind regards
Joris
--
Joris Meys
Statistical consultant
Ghent University
Faculty of Bioscience Engineering
Department of Mathematical Modelling, Statistics and Bio-Informatics
tel : +32 (0)9 264 61 79
joris.m...@ugent.be
---
Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] texi2pdf doesn't find the correct MikTex installation due to erroneous Sys.which()
Ah, but I bet you do have that path...try
> Sys.which("texify")
texify
"C:\\PROGRA~2\\MIKTEX~1.9\\miktex\\bin\\texify.exe"
> normalizePath(Sys.which("texify"))
[1] "C:\\Program Files (x86)\\MiKTeX 2.9\\miktex\\bin\\texify.exe"
Cheers,
Rich Calaway
Microsoft R Product Team
24/1341
+1 (425) 4219919 X19919
-Original Message-
From: R-devel [mailto:r-devel-boun...@r-project.org] On Behalf Of Joris Meys
Sent: Tuesday, June 27, 2017 10:43 AM
To: r-devel@r-project.org
Subject: [Rd] texi2pdf doesn't find the correct MikTex installation due to
erroneous Sys.which()
I checked after this question popped up on Stackoverflow:
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F44785961%2Fcompile-pdf-in-rstudio-works-but-knit2pdf-does-not-work-in-r-or-rstudio&data=02%7C01%7Crichcala%40microsoft.com%7C109c2b63c17443c51ecc08d4bd83fb68%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636341821947377257&sdata=NwIyGCJSQQjf1HY6r1X9a6V9Z1XI%2F74UTEe9ritYYys%3D&reserved=0
On Windows, texi2pdf looks for the texify.exe of Miktex, but looks in a very
wrong place:
> Sys.which("texify")
texify
"C:\\PROGRA~1\\MIKTEX~1.9\\miktex\\bin\\x64\\texify.exe"
That folder is not on my computer (I have 2.9 installed), not in my path, not
in my system path and I couldn't find it in my register. So it appears as if
Sys.which() is looking in the wrong place.
What could cause this?
Kind regards
Joris
--
Joris Meys
Statistical consultant
Ghent University
Faculty of Bioscience Engineering
Department of Mathematical Modelling, Statistics and Bio-Informatics
tel : +32 (0)9 264 61 79
joris.m...@ugent.be
---
Disclaimer :
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhelpdesk.ugent.be%2Fe-maildisclaimer.php&data=02%7C01%7Crichcala%40microsoft.com%7C109c2b63c17443c51ecc08d4bd83fb68%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636341821947377257&sdata=bCbpfOJqYi2M8U7YVbh4DG1oIdQHzxVboCRTkTwXzjI%3D&reserved=0
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fr-devel&data=02%7C01%7Crichcala%40microsoft.com%7C109c2b63c17443c51ecc08d4bd83fb68%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636341821947377257&sdata=5Gy480YnsDT2qgmIfIPPARL8sEmYmg%2BcetIApASA%2FR0%3D&reserved=0
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] texi2pdf doesn't find the correct MikTex installation due to erroneous Sys.which()
Aargh... I've been windofied again. When will I learn...
On 27 Jun 2017 19:49, "Rich Calaway" wrote:
> Ah, but I bet you do have that path...try
>
> > Sys.which("texify")
> texify
> "C:\\PROGRA~2\\MIKTEX~1.9\\miktex\\bin\\texify.exe"
> > normalizePath(Sys.which("texify"))
> [1] "C:\\Program Files (x86)\\MiKTeX 2.9\\miktex\\bin\\texify.exe"
>
> Cheers,
>
> Rich Calaway
> Microsoft R Product Team
> 24/1341
> +1 (425) 4219919 X19919
>
> -Original Message-
> From: R-devel [mailto:r-devel-boun...@r-project.org] On Behalf Of Joris
> Meys
> Sent: Tuesday, June 27, 2017 10:43 AM
> To: r-devel@r-project.org
> Subject: [Rd] texi2pdf doesn't find the correct MikTex installation due to
> erroneous Sys.which()
>
> I checked after this question popped up on Stackoverflow:
>
> https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fstackoverflow.com%2Fquestions%2F44785961%
> 2Fcompile-pdf-in-rstudio-works-but-knit2pdf-does-not-
> work-in-r-or-rstudio&data=02%7C01%7Crichcala%40microsoft.com%
> 7C109c2b63c17443c51ecc08d4bd83fb68%7C72f988bf86f141af91ab2d7cd011
> db47%7C1%7C0%7C636341821947377257&sdata=NwIyGCJSQQjf1HY6r1X9a6V9Z1XI%
> 2F74UTEe9ritYYys%3D&reserved=0
>
> On Windows, texi2pdf looks for the texify.exe of Miktex, but looks in a
> very wrong place:
>
> > Sys.which("texify")
> texify
> "C:\\PROGRA~1\\MIKTEX~1.9\\miktex\\bin\\x64\\texify.exe"
>
> That folder is not on my computer (I have 2.9 installed), not in my path,
> not in my system path and I couldn't find it in my register. So it appears
> as if Sys.which() is looking in the wrong place.
>
> What could cause this?
>
> Kind regards
> Joris
>
> --
> Joris Meys
> Statistical consultant
>
> Ghent University
> Faculty of Bioscience Engineering
> Department of Mathematical Modelling, Statistics and Bio-Informatics
>
> tel : +32 (0)9 264 61 79
> joris.m...@ugent.be
> ---
> Disclaimer : https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fhelpdesk.ugent.be%2Fe-maildisclaimer.php&
> data=02%7C01%7Crichcala%40microsoft.com%7C109c2b63c17443c51ecc08d4bd83
> fb68%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%
> 7C636341821947377257&sdata=bCbpfOJqYi2M8U7YVbh4DG1oIdQHzx
> VboCRTkTwXzjI%3D&reserved=0
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fr-
> devel&data=02%7C01%7Crichcala%40microsoft.com%
> 7C109c2b63c17443c51ecc08d4bd83fb68%7C72f988bf86f141af91ab2d7cd011
> db47%7C1%7C0%7C636341821947377257&sdata=5Gy480YnsDT2qgmIfIPPARL8sEmYmg
> %2BcetIApASA%2FR0%3D&reserved=0
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
