Re: [Rd] R-3.0.3 tar file not on Sources page
On 13 Mar 2014, at 21:08 , Steven McKinney wrote: > Checking CRAN today, I see that on the Sources page > > http://cran.r-project.org/sources.html > > that R-3.0.2.tar.gz is still there. R-3.0.3.tar.gz is available from the > Older releases are available >>here<<. hyperlink to > > http://cran.r-project.org/src/base/ > > Is this the right place to report this, for an update to the Sources page? It's a CRAN issue, so c...@r-project.org reaches the right people more efficiently. The front page of CRAN has the right information, so I guess that the Sources page got overlooked. -- Peter Dalgaard, Professor, 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
[Rd] Detect a terminated pipe
Hi
Is there a way to detect that the process that corresponds to a pipe has
ended? On my system (Ubuntu 13.04), I see
> p <- pipe("true", "w"); Sys.sleep(1); system("ps -elf | grep true |
grep -v grep"); isOpen(p)
[1] TRUE
The "true" process has long ended (as the filtered ps system call emits
no output), still R believes that the pipe p is open.
Thanks for your input.
Best regards
Kirill
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Detect a terminated pipe
On Mar 14, 2014, at 8:09 AM, Kirill Müller
wrote:
> Hi
>
> Is there a way to detect that the process that corresponds to a pipe has
> ended? On my system (Ubuntu 13.04), I see
>
> > p <- pipe("true", "w"); Sys.sleep(1); system("ps -elf | grep true | grep -v
> > grep"); isOpen(p)
> [1] TRUE
>
> The "true" process has long ended (as the filtered ps system call emits no
> output), still R believes that the pipe p is open.
>
As far as R is concerned, the connection is open. In addition, pipes exist even
without the process - you can close one end of a pipe and it will still exist
(that’s what makes pipes useful, actually, because you can choose to close
arbitrary combination of the R/W ends). Detecting that the other end of the
pipe has closed is generally done by sending/receiving data to/from the end of
interest - i.e. reading from a pipe that has closed the write end on the other
side will yield 0 bytes read. Writing to a pipe that has closed the read end on
the other side will yield SIGPIPE error (note that for text connections you
have to call flush() to send the buffer):
> p=pipe("true","r")
> readLines(p)
character(0)
> close(p)
> p=pipe("true","w")
> writeLines("", p)
> flush(p)
Error in flush.connection(p) : ignoring SIGPIPE signal
> close(p)
Cheers,
Simon
> Thanks for your input.
>
>
> Best regards
>
> Kirill
>
> __
> 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] Detect a terminated pipe
On 03/14/2014 03:54 PM, Simon Urbanek wrote:
As far as R is concerned, the connection is open. In addition, pipes exist even
without the process - you can close one end of a pipe and it will still exist
(that’s what makes pipes useful, actually, because you can choose to close
arbitrary combination of the R/W ends). Detecting that the other end of the
pipe has closed is generally done by sending/receiving data to/from the end of
interest - i.e. reading from a pipe that has closed the write end on the other
side will yield 0 bytes read. Writing to a pipe that has closed the read end on
the other side will yield SIGPIPE error (note that for text connections you
have to call flush() to send the buffer):
>p=pipe("true","r")
>readLines(p)
character(0)
>close(p)
>p=pipe("true","w")
>writeLines("", p)
>flush(p)
Error in flush.connection(p) : ignoring SIGPIPE signal
>close(p)
Thanks for your reply. I tried this in an R console and received the
error, just like you described. Unfortunately, the error is not thrown
when trying the same in RStudio. Any ideas?
Cheers
Kirill
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Detect a terminated pipe
On Mar 14, 2014, at 11:03 AM, Kirill Müller
wrote:
> On 03/14/2014 03:54 PM, Simon Urbanek wrote:
>> As far as R is concerned, the connection is open. In addition, pipes exist
>> even without the process - you can close one end of a pipe and it will still
>> exist (that’s what makes pipes useful, actually, because you can choose to
>> close arbitrary combination of the R/W ends). Detecting that the other end
>> of the pipe has closed is generally done by sending/receiving data to/from
>> the end of interest - i.e. reading from a pipe that has closed the write end
>> on the other side will yield 0 bytes read. Writing to a pipe that has closed
>> the read end on the other side will yield SIGPIPE error (note that for text
>> connections you have to call flush() to send the buffer):
>>
>>> >p=pipe("true","r")
>>> >readLines(p)
>> character(0)
>>> >close(p)
>>> >p=pipe("true","w")
>>> >writeLines("", p)
>>> >flush(p)
>> Error in flush.connection(p) : ignoring SIGPIPE signal
>>> >close(p)
> Thanks for your reply. I tried this in an R console and received the error,
> just like you described. Unfortunately, the error is not thrown when trying
> the same in RStudio. Any ideas?
>
RStudio is not R, so it’s possible that they catch signals and fail to
distinguish their use from R’s eating the signal before R can get it. I would
suggest filing a bug report with RStudio.
Cheers,
Simon
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Problems building package vignette: Sweave requires multiple passes to build document.
Dear R-devel,
Question:
How can I get Sweave to recognize that the \thebibliography section
is already created and generate the vignette pdf with a single pass? Or
is there a way to let R CMD build know that Sweave needs to be run twice?
If (1) is not possible, any suggestions how to auto-generate a
crude generic bibtex .bib file from my existing document?
Background:
I maintain serveral R packages that include package vignettes. The
vignettes include the reference citations inline as\bibitem lines inside
a thebiblilography section. For some reason, this requires running
Sweave twice on the document (the first pass is presumably preformatting
the citation information?) to produce a pdf. This seems to be the source
of problems when included in R's preferred vignette location
(/vignettes/myPackage.Rnw) because the R package builder just runs
Sweave once during the check process, so no pdf is produced and warnings
are generated like
checking package vignettes in ‘inst/doc’ ... WARNING
Package vignette without corresponding PDF/HTML
In the past, it has been possible for me to pre-build the pdf, and
include it in the /inst/doc/ directory. But it seems the upcoming
versions of R may prohibit this.
It appears that it is possible to avoid all this by including a bibtex
.bib file along with the vignette instead of doing the citations inline.
If the .bib files exists, it seems to generate with a single pass. But
reformatting all of the citations for each document into bibtex will be
a huge pain. Including a blank \bibliography{} command above my
\thebibliography environment also allows the document to be build in a
single pass, but generates a warning about duplicate biliography and
writes the section header twice (not surprisingly).
Note: I've cross-posted this question at:
http://stackoverflow.com/questions/22237675/how-to-get-sweave-to-recognize-thebibliography-environment-and-build-r-package
thanks for your help,
best,
-skye
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problems building package vignette: Sweave requires multiple passes to build document.
On 14/03/2014 12:28 PM, Skye Bender-deMoll wrote:
Dear R-devel,
Question:
How can I get Sweave to recognize that the \thebibliography section
is already created and generate the vignette pdf with a single pass? Or
is there a way to let R CMD build know that Sweave needs to be run twice?
I think the problem isn't Sweave: it ignores LaTeX code. The problem
is the following step that converts the .tex output into a .pdf, which
is handled by tools::texi2pdf (which runs tools::texi2dvi). That
function makes an effort to determine how many LaTeX passes are
required, but it appears you are fooling it somehow.
Take a look at the source to tools::texi2dvi, and see if you can spot
what's going wrong in your case. There are a number of different paths
through that code that depend on your particular setup, so we can't do
that. If you don't succeed in this, then post a simplified sample
package and someone else will be able to see if they have the same
problem as you, and perhaps fix it.
Duncan Murdoch
If (1) is not possible, any suggestions how to auto-generate a
crude generic bibtex .bib file from my existing document?
Background:
I maintain serveral R packages that include package vignettes. The
vignettes include the reference citations inline as\bibitem lines inside
a thebiblilography section. For some reason, this requires running
Sweave twice on the document (the first pass is presumably preformatting
the citation information?) to produce a pdf. This seems to be the source
of problems when included in R's preferred vignette location
(/vignettes/myPackage.Rnw) because the R package builder just runs
Sweave once during the check process, so no pdf is produced and warnings
are generated like
checking package vignettes in ‘inst/doc’ ... WARNING
Package vignette without corresponding PDF/HTML
In the past, it has been possible for me to pre-build the pdf, and
include it in the /inst/doc/ directory. But it seems the upcoming
versions of R may prohibit this.
It appears that it is possible to avoid all this by including a bibtex
.bib file along with the vignette instead of doing the citations inline.
If the .bib files exists, it seems to generate with a single pass. But
reformatting all of the citations for each document into bibtex will be
a huge pain. Including a blank \bibliography{} command above my
\thebibliography environment also allows the document to be build in a
single pass, but generates a warning about duplicate biliography and
writes the section header twice (not surprisingly).
Note: I've cross-posted this question at:
http://stackoverflow.com/questions/22237675/how-to-get-sweave-to-recognize-thebibliography-environment-and-build-r-package
thanks for your help,
best,
-skye
__
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] Conditional jump or move depends on uninitialised value(s)
Hi, I'm using valgrind to check over some C/C++ code for an R library. I'm getting the report (see below), but can't track down the uninitialised value(s). I tried using --track-origins=yes in valgrind which gives: ==28258== Uninitialised value was created by a stack allocation ==28258==at 0xEE33D98: ??? (in /usr/lib64/R/lib/libRlapack.so) I presume the problem is an uninitialised value being used in my code, rather than in libRlapack, but there is a better way of tracking down where it is? Cheers, Jarrod R -d "valgrind --tool=memcheck --leak-check=full --track-origins=yes" ==28258== Conditional jump or move depends on uninitialised value(s) ==28258==at 0xEE87208: dstemr_ (in /usr/lib64/R/lib/libRlapack.so) ==28258==by 0xEE7F39B: dsyevr_ (in /usr/lib64/R/lib/libRlapack.so) ==28258==by 0x15B23BD9: ??? (in /usr/lib64/R/modules/lapack.so) ==28258==by 0x15B28397: ??? (in /usr/lib64/R/modules/lapack.so) ==28258==by 0x35CA4BFEAC: ??? (in /usr/lib64/R/lib/libR.so) ==28258==by 0x35CA4C8A1F: Rf_eval (in /usr/lib64/R/lib/libR.so) ==28258==by 0x35CA4BB310: Rf_applyClosure (in /usr/lib64/R/lib/libR.so) ==28258==by 0x35CA4C58F9: ??? (in /usr/lib64/R/lib/libR.so) ==28258==by 0x35CA4C8A1F: Rf_eval (in /usr/lib64/R/lib/libR.so) ==28258==by 0x35CA4BB310: Rf_applyClosure (in /usr/lib64/R/lib/libR.so) ==28258==by 0x35CA4C8ACC: Rf_eval (in /usr/lib64/R/lib/libR.so) ==28258==by 0x35CA4CAEE7: ??? (in /usr/lib64/R/lib/libR.so) ==28258== Uninitialised value was created by a stack allocation ==28258==at 0xEE33D98: ??? (in /usr/lib64/R/lib/libRlapack.so) -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Conditional jump or move depends on uninitialised value(s)
On 14/03/2014 17:56, Jarrod Hadfield wrote: Hi, I'm using valgrind to check over some C/C++ code for an R library. I'm R package? getting the report (see below), but can't track down the uninitialised value(s). I tried using --track-origins=yes in valgrind which gives: ==28258== Uninitialised value was created by a stack allocation ==28258==at 0xEE33D98: ??? (in /usr/lib64/R/lib/libRlapack.so) I presume the problem is an uninitialised value being used in my code, rather than in libRlapack, but there is a better way of tracking down where it is? You need debug symbols. Maybe available for your unstated platform, or build a version of R with an internal LAPACK. I doubt this is you: 'Writing R Extensions' has 'Note that memory access errors may be seen with LAPACK, BLAS and Java-using packages: some at least of these seem to be intentional, and some are related to passing characters to Fortran.' Also, it is entirely possible that this is a non-current version of LAPACK: quite a few things like this have been plugged recently. For example, Fedora currently has 3.4.2 and 3.5.0 has been out for a lot longer than Fedora 20. Cheers, Jarrod R -d "valgrind --tool=memcheck --leak-check=full --track-origins=yes" ==28258== Conditional jump or move depends on uninitialised value(s) ==28258==at 0xEE87208: dstemr_ (in /usr/lib64/R/lib/libRlapack.so) ==28258==by 0xEE7F39B: dsyevr_ (in /usr/lib64/R/lib/libRlapack.so) ==28258==by 0x15B23BD9: ??? (in /usr/lib64/R/modules/lapack.so) ==28258==by 0x15B28397: ??? (in /usr/lib64/R/modules/lapack.so) ==28258==by 0x35CA4BFEAC: ??? (in /usr/lib64/R/lib/libR.so) ==28258==by 0x35CA4C8A1F: Rf_eval (in /usr/lib64/R/lib/libR.so) ==28258==by 0x35CA4BB310: Rf_applyClosure (in /usr/lib64/R/lib/libR.so) ==28258==by 0x35CA4C58F9: ??? (in /usr/lib64/R/lib/libR.so) ==28258==by 0x35CA4C8A1F: Rf_eval (in /usr/lib64/R/lib/libR.so) ==28258==by 0x35CA4BB310: Rf_applyClosure (in /usr/lib64/R/lib/libR.so) ==28258==by 0x35CA4C8ACC: Rf_eval (in /usr/lib64/R/lib/libR.so) ==28258==by 0x35CA4CAEE7: ??? (in /usr/lib64/R/lib/libR.so) ==28258== Uninitialised value was created by a stack allocation ==28258==at 0xEE33D98: ??? (in /usr/lib64/R/lib/libRlapack.so) -- Brian D. Ripley, rip...@stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
