Re: [Rd] Straight-quotes for usage and examples sections in PDF docs?
There's a trivial variation named Inconsolata-dz, http://nodnod.net/2009/feb/12/adding-straight-single-and-double-quotes-inconsola/ which I've used happily with XeTeX; maybe R can use it in place of the original if you rename it Inconsolata, but that would presumably be against the font licence. baptiste On 8 August 2012 04:13, Prof Brian Ripley wrote: > On 06/08/12 23:01, Mike Lawrence wrote: >> >> Is there any way to ensure that quotation marks are left as straight >> quotes and not converted to curly quotes in the \usage and \examples >> sections when the pdf versions of the docs are created? > > > They are not converted ... so there cannot be a way. > > In standard terminology 'quotation marks' are ASCII/Unicode " , and that is > what is in the PDF files (in so far as we can guess what you mean without an > explicit example). I have no idea what 'straight quotes' and 'curly quotes' > are in your lexicon, but how even ASCII characters are rendered depends on > the fonts used. > > The R pdf manuals by default use inconsolata, where quotation marks are > somewhat italic. We knew that when selecting inconsolata, but it was the > best compromise of the feasible choices. Chose something else it you prefer > a different compromise. > > > -- > 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 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Performance issues with R2.15.1 built from source on Solaris?
I have a question about building R (2.15.1) from source on a Solaris 10
64bit virtual server with 2 cores and 16GB memory that is running on an
Oracle T4 server. Based on several tests I have done this configuration
has been several orders of magnitude slower than any other configuration
I've tested.
A simple test of some code to calculate the standard deviation 1
times (simple code to consume resources) takes on average 121.498
seconds on the Solaris server where the next worst system (Redhat Linux)
takes 1.567 seconds:
t0 <- proc.time()[[3]]
x <- rnorm(1)
for(i in 1:1){
sd(x)
}
print(proc.time()[[3]]-t0)
R-Benchmark (http://r.research.att.com/benchmarks/R-benchmark-25.R) is
taking 185.624 seconds total on Solaris 10 whereas my next worst system
is taking 84.182 seconds
I understand that there would be some performance hit running on a
virtual server; however these differences seem to be several times
larger than I would have expected.
I've consulted the admin guide
(http://cran.r-project.org/doc/manuals/R-admin.pdf) I used the provided
make file and the only other configuration change I made was to use
shared libraries based on some of the packages I wanted to use
(--enable-R-shlib) I did have to use gcc (v3.4.6) as I ran into the
problem referenced in the admin guide about trying to build R with
SunStudio12.2. This was based on a compiled version of gcc that I had
available to me; so not sure if using a newer version of gcc would
provide significant performance gains. It seems that most of the
information in the admin guide for Solaris details how to get R to build
from source and not much detail about performance configurations or
tweaks to make it run faster. I've searched around on the internet as
well as the mailing lists and have not found a lot of information yet
about configuring performance from R on Solaris.
An interesting note is that I was able to build R 2.15.1 from source on
an physical Ultra 27 X86_64 server running Solaris 11 (6GB memory) and
had no problems and performance is comparable to all the other systems I
tested (for example, the standard deviation test only takes about 0.6985
seconds to run on average [gcc v4.5.2])
I'm trying to get hold of a physical Solaris 10 server to evaluate if
Solaris 11 is possibility causing any of the performance gain although I
know that X86_64 will likely perform better than SPARC.
Was wondering if anyone else has experience building R on Solaris or has
thoughts or considerations on what I should look at to increase
performance if possible.
Thanks in advance.
Anthony
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Inserting and testing revised functions in a package
Thanks, that was helpful in finding a bug in a library I was using, but now I'd
like to run the original code (the revised code is unable to access some of the
functions in the package, apparently, but I think I can work around it by
running and checking the original function).
How can I recover the original function? I tried using
insertSource("SourceFileWithOriginalFunctionCode.R", package = "Package",
functions = "functionOfInterest")
but I run into the same inability to access some the package functions used by
the function.
I also tried reloading but got
"The following object(s) are masked _by_ ‘.GlobalEnv’:
probtrans"
Thanks for your help,
Chris
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Inserting and testing revised functions in a package
On 12-08-08 4:59 PM, Chris Warren wrote:
Thanks, that was helpful in finding a bug in a library I was using, but now I'd
like to run the original code (the revised code is unable to access some of the
functions in the package, apparently, but I think I can work around it by
running and checking the original function).
How can I recover the original function? I tried using
insertSource("SourceFileWithOriginalFunctionCode.R", package = "Package",
functions = "functionOfInterest")
but I run into the same inability to access some the package functions used by
the function.
I also tried reloading but got
"The following object(s) are masked _by_ ‘.GlobalEnv’:
probtrans"
When you reply to a message that is more than 2 years old, it's helpful
to give some context.
Generally the reason a function can't see things in a package is because
its environment is wrong. Since all functions in a package normally use
the same environment, a simple fix is to put
environment(newfoo) <- environment(oldbar)
to copy the assignment of an unchanged function oldbar from the package
to the new function you are trying to work with.
But the general way to "recover the original function" is just to
restart R and attach the package.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
