[Rd] Recent examples of calling R from .net managed code

[rkanderson]

Are there any recent examples of calling R from C#?.   The examples that I
have found are all using deprecated function.
-- 
View this message in context: 
http://r.789695.n4.nabble.com/Recent-examples-of-calling-R-from-net-managed-code-tp2068586p2068586.html
Sent from the R devel mailing list archive at Nabble.com.

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Consulta

[Kjetil Halvorsen]

Mariana:

First, this post has nothing to do with future development of R, and
so should be sent to R-help, not R-devel.

Second, for questions in spanish you should consider the list R-help-es

kjetil

On Tue, Apr 27, 2010 at 1:38 PM, Mariana Gomez
 wrote:
> Estoy escribiendo una función en R para análisis de modelos lineales y tengo 
> problemas al ejecutarla porque dicha función usa otra función, también creada 
> por mi, y cuando ejecuto al primera me dice que no encuentra la segunda. 
> Ambas funciones están guardadas en la carpeta work y al entrar al programa 
> siempre cambio el directorio a work. No sé cual es el problema, si está mal 
> el search-path o es algo que me falta definir correctamente. Muchas gracias
>
> No sé si entienden español así que a continuación trataré de explicar mi 
> problema en inglés.
> Here is the same in english:
> I am writing a function
>  in R for analysis of linear models and I have run into problems because
>  the function uses another function, also created by me, and when I run
> the first the program said that can not found the second. Both features are 
> stored in the work
> folder and wen I enter the program always change the directory to work. I do 
> not know what the problem is, if the search-path
> is wrong or something I need to define properly. Thank you very much
>
>
>
>
>        [[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

Re: [Rd] Resolving functions using R's namespace mechanism can double runtime

[Romain Francois]

Le 27/04/10 22:16, Dominick Samperi a écrit :

It appears that the runtime for an R script can more than double if a few
references to a function foo() are replaced by more explict references
of the form pkgname::foo().


It would probably help your question if you provide some benchmarks.

a::b is just a shortcut for `::`( a, b ).


The more explicit references are of course required when two
loaded packages define the same function.


Not really. You can :
- resolve once: my_foo <- pkgname::foo
- import the variable into your namespace using the importFrom namespace 
directive.



I can understand why use of this mechanism is not free in an
interpreted environment like R, but the cost seems rather high.

Dominick


--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://bit.ly/9aKDM9 : embed images in Rd documents
|- http://tr.im/OIXN : raster images and RImageJ
|- http://tr.im/OcQe : Rcpp 0.7.7

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Resolving functions using R's namespace mechanism can double runtime

[Seth Falcon]

On 4/27/10 1:16 PM, Dominick Samperi wrote:

It appears that the runtime for an R script can more than double if a few
references to a function foo() are replaced by more explict references
of the form pkgname::foo().

The more explicit references are of course required when two
loaded packages define the same function.

I can understand why use of this mechanism is not free in an
interpreted environment like R, but the cost seems rather high.


`::` is a function, so there is going to be overhead.  OTOH, there is no 
reason to pay for the lookup more than once.  For example at startup, 
you could do:


myfoo <- pkgname::foo

And then later call myfoo() and I don't think you will see the added cost.

You can formalize the above approach in package code by renaming 
function in the importFrom directive where I believe you can do:


importFrom(pkgname, myfoo=foo)


+ seth

--
Seth Falcon | @sfalcon | http://userprimary.net/

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Resolving functions using R's namespace mechanism can double runtime

[Dominick Samperi]

It appears that the runtime for an R script can more than double if a few
references to a function foo() are replaced by more explict references
of the form pkgname::foo().

The more explicit references are of course required when two
loaded packages define the same function.

I can understand why use of this mechanism is not free in an
interpreted environment like R, but the cost seems rather high.

Dominick

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Unable to compile crc32_x86.S on windows (R-2.10.1).

[Vaish Anjur]

Thank you for any pointers.

Windows XP
**
*# as -version
GNU assembler (GNU Binutils) 2.19.1
Copyright 2007 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `mingw32'.*
**
**
*as   -o crc32_x86.o crc32_x86.s*

crc32_x86.S: Assembler messages:
crc32_x86.S:80: Warning: .type pseudo-op used outside of .def/.endef
ignored.
crc32_x86.S:80: Error: junk at end of line, first unrecognized character is
`L'
crc32_x86.S:83: Error: invalid character '(' in mnemonic
crc32_x86.S:118: Error: junk at end of line, first unrecognized character is
`|'

crc32_x86.S:137: Error: invalid character '(' in mnemonic
crc32_x86.S:160: Error: invalid character '(' in mnemonic
crc32_x86.S:271: Error: invalid character '(' in mnemonic
crc32_x86.S:279: Error: bad or irreducible absolute expression
crc32_x86.S:279: Error: junk at end of line, first unrecognized character is
`,'

crc32_x86.S:281: Error: unknown pseudo-op: `.indirect_symbol'
crc32_x86.S:293: Warning: .size pseudo-op used outside of .def/.endef
ignored.
crc32_x86.S:293: Error: junk at end of line, first unrecognized character is
`L'

crc32_x86.S:302: Error: junk at end of line, first unrecognized character is
`-'

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Consulta

[Mariana Gomez]

Estoy escribiendo una función en R para análisis de modelos lineales y tengo 
problemas al ejecutarla porque dicha función usa otra función, también creada 
por mi, y cuando ejecuto al primera me dice que no encuentra la segunda. Ambas 
funciones están guardadas en la carpeta work y al entrar al programa siempre 
cambio el directorio a work. No sé cual es el problema, si está mal el 
search-path o es algo que me falta definir correctamente. Muchas gracias
 
No sé si entienden español así que a continuación trataré de explicar mi 
problema en inglés.
Here is the same in english:
I am writing a function
 in R for analysis of linear models and I have run into problems because
 the function uses another function, also created by me, and when I run 
the first the program said that can not found the second. Both features are 
stored in the work 
folder and wen I enter the program always change the directory to work. I do 
not know what the problem is, if the search-path 
is wrong or something I need to define properly. Thank you very much



  
[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Should mcnemar.test use as.factor instead of factor

[Greg Snow]

I am working with the mcnemar.test function and the help does not show a 
maintainer/author, but it is part of the stats package.

My issue is that I want to use the test on 2 variables with possible values of 
0:3, in one of the tests one of the variables does not have any 3's, so to make 
sure that the matrix is square I do:

> x <- factor(x, levels=0:3)
> y <- factor(y, levels=0:3)

If I run mcnemar.test on the table of x and y then everything works fine, but 
if I pass in x and y without running table first then I get an error about both 
variables needing to have the same number of levels (which they did when I 
passed them in).  The problem occurs because the function when handed the raw 
data does its own conversion to factor using the factor function which drops 
the unused level in the one variable.  A simple fix should be to replace the 
call to factor with a call to as.factor (which will not change anything for 
variables that are already factors and therefore not drop levels).  I cannot 
imagine any code that would break from this change, but that could just be a 
lack of imagination on my part.

So, can anyone think of a reason not to change factor to as.factor?

Is this worth a bug report/enhancement request?



> sessionInfo()
R version 2.11.0 (2010-04-22) 
i386-pc-mingw32 

locale:
[1] LC_COLLATE=English_United States.1252 
[2] LC_CTYPE=English_United States.1252   
[3] LC_MONETARY=English_United States.1252
[4] LC_NUMERIC=C  
[5] LC_TIME=English_United States.1252

attached base packages:
[1] stats graphics  grDevices utils datasets  methods   base 

loaded via a namespace (and not attached):
[1] tools_2.11.0

-- 
Gregory (Greg) L. Snow Ph.D.
Statistical Data Center
Intermountain Healthcare
greg.s...@imail.org
801.408.8111

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] 00LOCK and nfs

[Tony Plate]

I have some tools and an R package that together provide a solution to 
the problem of updating an R package while it is attached in one or more 
running R sessions (whether on the same machine or not.)  The technique 
is to always create a new directory for the newly installed package, so 
that existing installed packages are never overwritten.  The tricky part 
is to manage this in a way that is transparent to the user, which is 
what the package accomplishes.  If this is any interest in this I could 
make it available; email me privately or respond on the list.


-- Tony Plate

On 4/26/2010 1:05 PM, Kasper Daniel Hansen wrote:

2010/4/26 Christian Brechbühler:
   


On Mon, Apr 26, 2010 at 11:15 AM, Kasper Daniel Hansen
  wrote:
 

I am running into a problem with the 00LOCK file and .nfs files.  It
seemed to be caused by the following
  R is installed on NFS
  user A has loaded pkg_A containing a dynamically loaded library
  user B (the administrator) runs install.packages("pkg_A")
  as the final part of the installation process the 00LOCK directory is
removed
  this creates a .nfs file because user A has the dynamic library open
  this .nfs file cannot be removed until user A exits R
  because of this, 00LOCK cannot be removed, and if the
install.packages call is going to install packages after pkg_A, they
fail
   

Yup, I've seen that.  The program "lsof" can be useful to find which process
has the library open.
User A does not need to exit R; it's enough to detach(package:pkg_A);
library(pkg_A);.
 

I have now done more careful experimentation with a colleague so I
have more than 1 user, and my earlier description was wrong.  I can
reliably trigger this 00LOCK problem if a single user does
library(pkg_A) and then in a separate R session does
install.packages(pkg_A).

I cannot reliable trigger it if
1) the library() and install.packages() were done by the same user,
but on different nodes
2) the library() and install.packages() were done by different users, same node
3) the library() and install.packages() were done by different users,
different nodes

I believe I have run into this problem with 00LOCK when I only had one
R session running (the one doing the install.packages), so I am
beginning to believe that what I seem to run into is a race problem.
But I could of course be wrong.

Kasper

__
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

Re: [Rd] serial connection patch

[Matt Shotwell]

Oh, I just put that there for the bit about "WITHOUT ANY WARRANTY" :). I
am satisfied with GPLv2 and have updated the license notice to reflect a
change from GPLv3 to GPLv2 or later.

-Matt

On Tue, 2010-04-27 at 09:33 -0400, Peter Dalgaard wrote:
> On Apr 27, 2010, at 2:42 PM, Duncan Murdoch wrote:
> 
> > On 27/04/2010 8:32 AM, Matt Shotwell wrote:
> >> Simon, 
> >> Thanks for reviewing it! All the modified files are under the GPL
> >> version 2 (except the configure script). According to the GPLv2, I am
> >> granted permission to modify and redistribute the code as long as I make
> >> a notice in the files of their modification and the date (which I have
> >> not done yet). As I understand (I'm not lawyer), the copyright is
> >> necessary for, and does not alter the terms of the GPLv2. Is there
> >> something specific you're thinking of that invalidates this?
> >>  
> > 
> > I don't know what Simon noticed, but I saw that you had indicated a GPL v3 
> > license on the web page.  GPL2 is not compatible with GPL3, so that makes 
> > your contribution unusable by us.
> 
> Yes, this is a bit messy, but some got sufficiently annoyed by the added 
> restrictions of GPL3 that they insist on keeping their contributions GPL2, so 
> adding GPL3-only stuff is off limits. 
> 
> I don't think we have a problem with merging user contributions that are 
> licensed "GPL2 or later". A copyright transfer gives some legal 
> clarification, but is only really required in case the R Foundation wants to 
> (dual-) relicense under a GPL incompatible license, or need to be able to 
> legally defend users' code against infringement. The former is highly 
> unlikely, and it would require major disentanglement in other areas anyway, 
> and I don't see contributions of this order of magnitude as a target of legal 
> dispute either. 
> 
> > 
> > Duncan Murdoch
>

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] serial connection patch

[Peter Dalgaard]

On Apr 27, 2010, at 2:42 PM, Duncan Murdoch wrote:

> On 27/04/2010 8:32 AM, Matt Shotwell wrote:
>> Simon, 
>> Thanks for reviewing it! All the modified files are under the GPL
>> version 2 (except the configure script). According to the GPLv2, I am
>> granted permission to modify and redistribute the code as long as I make
>> a notice in the files of their modification and the date (which I have
>> not done yet). As I understand (I'm not lawyer), the copyright is
>> necessary for, and does not alter the terms of the GPLv2. Is there
>> something specific you're thinking of that invalidates this?
>>  
> 
> I don't know what Simon noticed, but I saw that you had indicated a GPL v3 
> license on the web page.  GPL2 is not compatible with GPL3, so that makes 
> your contribution unusable by us.

Yes, this is a bit messy, but some got sufficiently annoyed by the added 
restrictions of GPL3 that they insist on keeping their contributions GPL2, so 
adding GPL3-only stuff is off limits. 

I don't think we have a problem with merging user contributions that are 
licensed "GPL2 or later". A copyright transfer gives some legal clarification, 
but is only really required in case the R Foundation wants to (dual-) relicense 
under a GPL incompatible license, or need to be able to legally defend users' 
code against infringement. The former is highly unlikely, and it would require 
major disentanglement in other areas anyway, and I don't see contributions of 
this order of magnitude as a target of legal dispute either. 

> 
> Duncan Murdoch

-- 
Peter Dalgaard
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Email: pd@cbs.dk  Priv: pda...@gmail.com

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] serial connection patch

[Duncan Murdoch]

On 27/04/2010 8:32 AM, Matt Shotwell wrote:
Simon, 


Thanks for reviewing it! All the modified files are under the GPL
version 2 (except the configure script). According to the GPLv2, I am
granted permission to modify and redistribute the code as long as I make
a notice in the files of their modification and the date (which I have
not done yet). As I understand (I'm not lawyer), the copyright is
necessary for, and does not alter the terms of the GPLv2. Is there
something specific you're thinking of that invalidates this?
  


I don't know what Simon noticed, but I saw that you had indicated a GPL 
v3 license on the web page.  GPL2 is not compatible with GPL3, so that 
makes your contribution unusable by us.


Duncan Murdoch


I updated the patch to open with O_NOCTTY to prevent opening the tty as
the controlling terminal. Looks like this is default in BSD and GNU but
maybe not in OS X. I'd like to hear how it goes if you try it again. 


I see the rationale for a tty (in scope) connection. As you observed,
there are lots of options. However, some of them are designed to be used
when the terminal IS the controlling terminal, for example, if you were
writing a program like getty, so barring the use of R as a job control
shell (which would be cool also, but probably not in the scope of R),
some of the options need not be exposed. For instance, canonical mode
may never be necessary/appropriate. But it would be cool to use RTS/CTS,
XON/XOFF, blocking, and some of the other stuff that is not there yet. I
have some ideas on how to expose these features concisely.

I'll continue to work on this as time permits (i.e. probably at
weekend), with consideration for your suggestions. Thanks again,

-Matt



On Mon, 2010-04-26 at 14:18 -0400, Simon Urbanek wrote: 
> Matt,
> 
> thanks for you efforts. We cannot directly use your patch due to licensing issues (please note the licenses in the files you are modifying - I don't think anyone can currently use the patch and redistribute the resulting R; also/or we may possibly need to clarify that the work is either done on behalf of the R-foundation or the copyright is assigned to R-foundation or something similar so future licensing issues can be solved by the Foundation since that is the copyright holder of most of R).
> 
> Apart from that, the overall structure looks good, but the devil is in the details. It does not quite work for me on OS X (any read/writes just hang in the same way that it would if you used a file connection on the tty device) - I don't think it is as simple (AFAIR you have to make sure you open it such that it doesn't become the controlling terminal). Also it would definitely need "blocking" argument like most other connections have.
> 
> In general I don't think serial is the right name (and scope) here - what we're really looking for a is a tty connection (and serial just an application of it). What you have so far is a file connection with setserial functionality on it - and I think that may be more easily done by really using setserial on the already implemented file connection. The difference with tty is the other parts such as flow control, modes etc. It's much more work to expose those, but I think that is what the direction would be. In fact it could well be that tty is simply file connection + termio so you don't have to re-invent the wheel (under the hood). Also that would give you many aspects for free since you could inherit from file at the R level.
> 
> I hope it helps. I was thinking about the above but in the end decided to back off once I was looking at the flood of parameters you have to take care of in tty. But it would be nice if someone did that ;).
> 
> Cheers,

> Simon
> 
> 
> On Apr 26, 2010, at 12:28 PM, Matt Shotwell wrote:
> 
> > All,

> >
> > Our discussion of serial interfaces last week motivated me to dig into
> > the R connections API. In short, I spent the weekend writing a patch for
> > version 2.11.0 that adds a serial connection. I posted a blog entry that
> > gives instructions for applying, configuring, and compiling the patched
> > version .
> >
> > The patch currently only enables a serial connection for POSIX compliant
> > OSs. It should NOT be considered well tested, though I feel it is fairly
> > safe. I would really like to hear from someone who can try it on Mac OS
> > X (and Windows to ensure that it has the correct 'null' behavior).
> >
> > Briefly, the connection utilizes (and checks for) the termios.h header.
> > I opted not to extend the 'file' connection in a manner similar to the
> > 'pipe' connection because this might not be suitable under Win32. Hence,
> > there are new read, write, flush, open, and close methods and a struct
> > serialconn for the serial connection. Opens are non-blocking and binary
> > only. Serial parameters can be passed when the connection is created. I
> > overloaded the summary method in order for the user to see the serial
> > settings.

Re: [Rd] serial connection patch

[Matt Shotwell]

Simon, 

Thanks for reviewing it! All the modified files are under the GPL
version 2 (except the configure script). According to the GPLv2, I am
granted permission to modify and redistribute the code as long as I make
a notice in the files of their modification and the date (which I have
not done yet). As I understand (I'm not lawyer), the copyright is
necessary for, and does not alter the terms of the GPLv2. Is there
something specific you're thinking of that invalidates this?

I updated the patch to open with O_NOCTTY to prevent opening the tty as
the controlling terminal. Looks like this is default in BSD and GNU but
maybe not in OS X. I'd like to hear how it goes if you try it again. 

I see the rationale for a tty (in scope) connection. As you observed,
there are lots of options. However, some of them are designed to be used
when the terminal IS the controlling terminal, for example, if you were
writing a program like getty, so barring the use of R as a job control
shell (which would be cool also, but probably not in the scope of R),
some of the options need not be exposed. For instance, canonical mode
may never be necessary/appropriate. But it would be cool to use RTS/CTS,
XON/XOFF, blocking, and some of the other stuff that is not there yet. I
have some ideas on how to expose these features concisely.

I'll continue to work on this as time permits (i.e. probably at
weekend), with consideration for your suggestions. Thanks again,

-Matt



On Mon, 2010-04-26 at 14:18 -0400, Simon Urbanek wrote: 
> Matt,
> 
> thanks for you efforts. We cannot directly use your patch due to licensing 
> issues (please note the licenses in the files you are modifying - I don't 
> think anyone can currently use the patch and redistribute the resulting R; 
> also/or we may possibly need to clarify that the work is either done on 
> behalf of the R-foundation or the copyright is assigned to R-foundation or 
> something similar so future licensing issues can be solved by the Foundation 
> since that is the copyright holder of most of R).
> 
> Apart from that, the overall structure looks good, but the devil is in the 
> details. It does not quite work for me on OS X (any read/writes just hang in 
> the same way that it would if you used a file connection on the tty device) - 
> I don't think it is as simple (AFAIR you have to make sure you open it such 
> that it doesn't become the controlling terminal). Also it would definitely 
> need "blocking" argument like most other connections have.
> 
> In general I don't think serial is the right name (and scope) here - what 
> we're really looking for a is a tty connection (and serial just an 
> application of it). What you have so far is a file connection with setserial 
> functionality on it - and I think that may be more easily done by really 
> using setserial on the already implemented file connection. The difference 
> with tty is the other parts such as flow control, modes etc. It's much more 
> work to expose those, but I think that is what the direction would be. In 
> fact it could well be that tty is simply file connection + termio so you 
> don't have to re-invent the wheel (under the hood). Also that would give you 
> many aspects for free since you could inherit from file at the R level.
> 
> I hope it helps. I was thinking about the above but in the end decided to 
> back off once I was looking at the flood of parameters you have to take care 
> of in tty. But it would be nice if someone did that ;).
> 
> Cheers,
> Simon
> 
> 
> On Apr 26, 2010, at 12:28 PM, Matt Shotwell wrote:
> 
> > All,
> >
> > Our discussion of serial interfaces last week motivated me to dig into
> > the R connections API. In short, I spent the weekend writing a patch for
> > version 2.11.0 that adds a serial connection. I posted a blog entry that
> > gives instructions for applying, configuring, and compiling the patched
> > version .
> >
> > The patch currently only enables a serial connection for POSIX compliant
> > OSs. It should NOT be considered well tested, though I feel it is fairly
> > safe. I would really like to hear from someone who can try it on Mac OS
> > X (and Windows to ensure that it has the correct 'null' behavior).
> >
> > Briefly, the connection utilizes (and checks for) the termios.h header.
> > I opted not to extend the 'file' connection in a manner similar to the
> > 'pipe' connection because this might not be suitable under Win32. Hence,
> > there are new read, write, flush, open, and close methods and a struct
> > serialconn for the serial connection. Opens are non-blocking and binary
> > only. Serial parameters can be passed when the connection is created. I
> > overloaded the summary method in order for the user to see the serial
> > settings.
> >
> > I've done my best to be consistent and conforming with the connections
> > API and coding style. However, I would be great if someone with more
> > experience with the R API (Simon? :

Re: [Rd] Miktex does not work with R CMD check

[Ulrike Grömping]

Uwe,

I think it must be some problem on my computer, it happens for all my 
packages in R CMD check. I don't use TeX for anything else (if I can 
avoid it), therefore it might be something stupid that a regular 
TeX-user would never think about. However, it can't be a completely 
wrong setup of MikTeX, since direct application of pdflatex to 
pkg-manual.tex works without problems.


Best regards,
Ulrike

Uwe Ligges schrieb:

Ulrike,

I just upgraded to the full MikTeX 2.8 distribution from today (still 
on 2.7 before) and checking my tuneR package worked fine.

Hence  Which package are you referring to?

Best wishes,
Uwe


On 25.04.2010 18:57, Ulrike Grömping wrote:

Dear DevelopeRs,

the issue I am stuck with (I am on Windows, R-2.11): My Miktex (version
2.8) does not work with R CMD check, although Miktex on its own can
pdflatex the tex-file in the Rcheck directory. (This issue has been
going on for a while, and now, after having updated to R-2.11, I finally
want to get it fixed.) Although I have found several similar posts, none
of the answers appears to solve my problem, which seems to be
path-related. In case it is relevant: in the past, I did have issues
with paths to "my documents" because these contain a German Umlaut on my
computer, which is why I moved all R packages to the directory 
c:/rtests.


I would appreciate any help on this issue. The relevant portion of R CMD
check and the content of Rdlatex.log are included below.

Best regards,
Ulrike

The end of the R CMD check output looks like this:

* checking PDF version of manual ... WARNING
LaTeX errors when creating PDF version.
This typically indicates Rd problems.
* checking PDF version of manual without index ... ERROR
LaTeX error when running command:
Rcmd.exe Rd2dvi --batch --no-preview --pdf
--build-dir=C:/WINDOWS/Temp/Rd2dvi611638299 --no-clean --no-index -o
DoE.base-manual.pdf >/dev/null 2>&1 C:/rtests/DoE.base.Rcheck/DoE.base
Re-running with no redirection of stdout/stderr.

The file Rdlatex.log contains the following text:

Hmm ... looks like a package
latex.exe: A required file system path could not be retrieved.
latex.exe: Data: 28
Creating pdf output from LaTeX ...
pdflatex.exe: A required file system path could not be retrieved.
pdflatex.exe: Data: 28
Error in running pdflatex command ('pdflatex')
You may want to clean up by 'rm -rf C:/WINDOWS/Temp/Rd2dvi611638299'

__
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

Re: [Rd] Miktex does not work with R CMD check

[Uwe Ligges]

Ulrike,

I just upgraded to the full MikTeX 2.8 distribution from today (still on 
2.7 before) and checking my tuneR package worked fine.

Hence  Which package are you referring to?

Best wishes,
Uwe


On 25.04.2010 18:57, Ulrike Grömping wrote:

Dear DevelopeRs,

the issue I am stuck with (I am on Windows, R-2.11): My Miktex (version
2.8) does not work with R CMD check, although Miktex on its own can
pdflatex the tex-file in the Rcheck directory. (This issue has been
going on for a while, and now, after having updated to R-2.11, I finally
want to get it fixed.) Although I have found several similar posts, none
of the answers appears to solve my problem, which seems to be
path-related. In case it is relevant: in the past, I did have issues
with paths to "my documents" because these contain a German Umlaut on my
computer, which is why I moved all R packages to the directory c:/rtests.

I would appreciate any help on this issue. The relevant portion of R CMD
check and the content of Rdlatex.log are included below.

Best regards,
Ulrike

The end of the R CMD check output looks like this:

* checking PDF version of manual ... WARNING
LaTeX errors when creating PDF version.
This typically indicates Rd problems.
* checking PDF version of manual without index ... ERROR
LaTeX error when running command:
Rcmd.exe Rd2dvi --batch --no-preview --pdf
--build-dir=C:/WINDOWS/Temp/Rd2dvi611638299 --no-clean --no-index -o
DoE.base-manual.pdf >/dev/null 2>&1 C:/rtests/DoE.base.Rcheck/DoE.base
Re-running with no redirection of stdout/stderr.

The file Rdlatex.log contains the following text:

Hmm ... looks like a package
latex.exe: A required file system path could not be retrieved.
latex.exe: Data: 28
Creating pdf output from LaTeX ...
pdflatex.exe: A required file system path could not be retrieved.
pdflatex.exe: Data: 28
Error in running pdflatex command ('pdflatex')
You may want to clean up by 'rm -rf C:/WINDOWS/Temp/Rd2dvi611638299'

__
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