[Rd] inject html code into Rd file
Hello,
I'm trying to inject html code into an Rd file. For example :
\name{test}
\alias{test}
\title{test}
\description{
\if{html}{
\Sexpr[stage=render,results=text,echo=FALSE]{
"hello"
}
}
}
when this file is rendered, instead of having "hello" in bold, I get
hello, i.e. characters < and > are replaced with html entities :
< and >
Is there a way to turn this off ?
Romain
--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://tr.im/OIXN : raster images and RImageJ
|- http://tr.im/OcQe : Rcpp 0.7.7
`- http://tr.im/O1wO : highlight 0.1-5
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] inject html code into Rd file
On 02/04/2010 6:17 AM, Romain Francois wrote:
Hello,
I'm trying to inject html code into an Rd file. For example :
\name{test}
\alias{test}
\title{test}
\description{
\if{html}{
\Sexpr[stage=render,results=text,echo=FALSE]{
"hello"
}
}
}
when this file is rendered, instead of having "hello" in bold, I get
hello, i.e. characters < and > are replaced with html entities :
< and >
Is there a way to turn this off ?
Yes, if you wrap it in \out{}. The example in the manual is
\if{latex}{\out{\alpha}}\ifelse{html}{\out{α}}{alpha}
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] inject html code into Rd file
Le 02/04/10 13:07, Duncan Murdoch a écrit :
On 02/04/2010 6:17 AM, Romain Francois wrote:
Hello,
I'm trying to inject html code into an Rd file. For example :
\name{test}
\alias{test}
\title{test}
\description{
\if{html}{
\Sexpr[stage=render,results=text,echo=FALSE]{
"hello"
}
}
}
when this file is rendered, instead of having "hello" in bold, I get
hello, i.e. characters < and > are replaced with html entities
: < and >
Is there a way to turn this off ?
Yes, if you wrap it in \out{}. The example in the manual is
\if{latex}{\out{\alpha}}\ifelse{html}{\out{α}}{alpha}
Duncan Murdoch
yes, I saw that in WRE, I should have been more specific.
what if instead of a trivial string like "hello" the text is to
be computed by some function. For example:
print( xtable( iris), type = "html" )
Romain
--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://tr.im/OIXN : raster images and RImageJ
|- http://tr.im/OcQe : Rcpp 0.7.7
`- http://tr.im/O1wO : highlight 0.1-5
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] inject html code into Rd file
On 02/04/2010 7:13 AM, Romain Francois wrote:
Le 02/04/10 13:07, Duncan Murdoch a écrit :
On 02/04/2010 6:17 AM, Romain Francois wrote:
Hello,
I'm trying to inject html code into an Rd file. For example :
\name{test}
\alias{test}
\title{test}
\description{
\if{html}{
\Sexpr[stage=render,results=text,echo=FALSE]{
"hello"
}
}
}
when this file is rendered, instead of having "hello" in bold, I get
hello, i.e. characters < and > are replaced with html entities
: < and >
Is there a way to turn this off ?
Yes, if you wrap it in \out{}. The example in the manual is
\if{latex}{\out{\alpha}}\ifelse{html}{\out{α}}{alpha}
Duncan Murdoch
yes, I saw that in WRE, I should have been more specific.
what if instead of a trivial string like "hello" the text is to
be computed by some function. For example:
print( xtable( iris), type = "html" )
I think this should do it:
\Sexpr[stage=render,results=rd,echo=FALSE]{
paste("\\out{", "hello, "}", sep="")}
but this stuff hasn't been tested much, so there might be problems...
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] as(1:4, "numeric") versus as.numeric(1:4, "numeric")
One more (final?) note on this example. A simpler change that would eliminate the inconsistent result from as(): 1. Change the warning on direct calls to coerce() to an error. 2. Move the caching of inherited methods to the actual dispatch code, so selectMethod() itself has no side effect. The example itself suggests that 1 is needed, since a direct call would use ordinary inheritance rules, not those imposed by as(). Unless there is an unnoticed issue with this, I'll make the change, to r-devel of course. John On 4/1/10 5:07 PM, John Chambers wrote: The problem that you have exposed is that if one uses the *standard* form of selectMethod() on function "coerce", this could corrupt the intended set of methods used by as(). Of course, no one was expected to do this, but it's not caught or warned (as opposed to a direct call to coerce(), which does generate a warning). If people think this is something of sufficient importance to put high on the fix-it list, contributions are welcome as always. However, it seems a really bad idea to start making the definition of method selection by inheritance depend in an arbitrary way on which function is operated on. Documenting what selection does is hard enough as it is. A solution localized to the as() computation is to treat the mechanism involved in a call to setAsMethod as something special, and provide whatever information is needed via showAsMethods(), or similar. From a tutorial view, it might be good to emphasize that this is NOT the usual method dispatch--indeed, the present discussion supports that view. Method selection in a functional language is a difficult concept, particularly for programmers coming from a standard OOP background. If we're going to change it, let's aim to make it simpler, not more complicated. What about getting rid of the kludgy argument useInheritance= in a future version, if nobody has a use for it other than in as()? If you look at the code, you'll see that would simplify it significantly, and even speed up selection somewhat. There's a change I would be happy about! John On 4/1/10 2:59 PM, Hervé Pagès wrote: John Chambers wrote: The point I was making was that as() is not just a synonym for selecting a method from coerce() by the usual inheritance rules. I don't believe it should be, and the documentation emphasizes that inheritance is not used in the ordinary way. I got this. If you look carefully at the change I'm suggesting for selectMethod(), you will notice that I said that f="coerce" would then need to become a special case. In other words, when f="coerce", the usual inheritance rules are replaced by the rules that are currently implemented in as() and described in its man page. So to summarize: (1) the code in as() that is currently in charge of selecting/creating/caching the most adequate coerce method is moved to selectMethod(), (2) the sections in ?as that describe the rules of this non-standard inheritance are moved to ?selectMethod. If one were to start rewriting code (which I'm not suggesting) my preference would be to have coerce() not be a generic function, eliminating the offending selectMethod() calls. Then how one would know what as() is doing *exactly* i.e. which coerce method was used or will be used in such or such situation? showMethods()/selectMethod() are great tools because they allow the developer to predict things and troubleshoot. If you don't like putting the non-standard inheritance rules in selectMethod() (when f="coerce") then you can always add something like selectAsMethod() and put them here, and also add something like showAsMethods(). I guess that's more or less what you are saying when you propose to have coerce() not be a generic function, at least not an usual one. But it's important to expose selectAsMethod()/showAsMethods() to the user. We absolutely need them! Now I'm not sure I understand your concern about putting this stuff in the existing selectMethod()/showMethods(). Why not just ignore the useInheritance= arg when f="coerce"? Again, this would be a special case anyway (and documented). The advantage of this solution (over selectAsMethod()/showAsMethods()) is to avoid having to introduce and expose 2 new names, so the user doesn't have to switch between select*/show* tools depending on whether f="coerce" or not. H. John On 4/1/10 12:31 AM, Hervé Pagès wrote: Hi John, John Chambers wrote: The example is confusing and debatable, but not an obvious bug. And your presentation of it is the cause of much of the confusion (unintentionally I'm sure). First, slipping from the as() function to methods for the coerce() function might surprise a less experienced user. And in fact, that is the point here. If you look at the as() function, it jumps through several hoops and in particular selects a method from coerce in such a way as NOT to use inheritance on the from= argument. (I think this makes sense in this case)
Re: [Rd] as(1:4, "numeric") versus as.numeric(1:4, "numeric")
Hi John,
John Chambers wrote:
The problem that you have exposed is that if one uses the *standard*
form of selectMethod() on function "coerce", this could corrupt the
intended set of methods used by as(). Of course, no one was expected to
do this, but it's not caught or warned (as opposed to a direct call to
coerce(), which does generate a warning).
If people think this is something of sufficient importance to put high
on the fix-it list, contributions are welcome as always.
However, it seems a really bad idea to start making the definition of
method selection by inheritance depend in an arbitrary way on which
function is operated on. Documenting what selection does is hard enough
as it is.
The *definition* of method selection is what it is. And it's a fact that
the rules are different for as(). Hence selectMethod("coerce", ...) or
selectAsMethod() should reflect this.
A solution localized to the as() computation is to treat the mechanism
involved in a call to setAsMethod as something special, and provide
whatever information is needed via showAsMethods(), or similar. From a
tutorial view, it might be good to emphasize that this is NOT the usual
method dispatch--indeed, the present discussion supports that view.
Method selection in a functional language is a difficult concept,
particularly for programmers coming from a standard OOP background. If
we're going to change it, let's aim to make it simpler, not more
complicated.
Just to clarify, I'm not proposing to change the *rules* of method
selection. The standard rules would remain exactly the same, and
the special rules used by as() (specified in its man page) would
also remain exactly the same. What would change however is that
selectMethod("coerce", ...) would not be broken anymore i.e. it
would not corrupt the table of "coerce" methods anymore, and it
would return the right method (as specified in the specs).
I hope I made the point that it's not about making things more
complicated ;-)
What about getting rid of the kludgy argument
useInheritance= in a future version, if nobody has a use for it other
than in as()? If you look at the code, you'll see that would simplify
it significantly, and even speed up selection somewhat. There's a change
I would be happy about!
That sounds all good to me.
Thanks,
H.
John
On 4/1/10 2:59 PM, Hervé Pagès wrote:
John Chambers wrote:
The point I was making was that as() is not just a synonym for
selecting a method from coerce() by the usual inheritance rules. I
don't believe it should be, and the documentation emphasizes that
inheritance is not used in the ordinary way.
I got this. If you look carefully at the change I'm suggesting for
selectMethod(), you will notice that I said that f="coerce" would
then need to become a special case.
In other words, when f="coerce", the usual inheritance rules are
replaced by the rules that are currently implemented in as() and
described in its man page.
So to summarize: (1) the code in as() that is currently in charge of
selecting/creating/caching the most adequate coerce method is moved
to selectMethod(), (2) the sections in ?as that describe the rules
of this non-standard inheritance are moved to ?selectMethod.
If one were to start rewriting code (which I'm not suggesting) my
preference would be to have coerce() not be a generic function,
eliminating the offending selectMethod() calls.
Then how one would know what as() is doing *exactly* i.e. which
coerce method was used or will be used in such or such situation?
showMethods()/selectMethod() are great tools because they allow the
developer to predict things and troubleshoot.
If you don't like putting the non-standard inheritance rules in
selectMethod() (when f="coerce") then you can always add something
like selectAsMethod() and put them here, and also add something
like showAsMethods(). I guess that's more or less what you are
saying when you propose to have coerce() not be a generic function,
at least not an usual one.
But it's important to expose selectAsMethod()/showAsMethods() to
the user. We absolutely need them!
Now I'm not sure I understand your concern about putting this
stuff in the existing selectMethod()/showMethods(). Why not just
ignore the useInheritance= arg when f="coerce"? Again, this would
be a special case anyway (and documented). The advantage of this
solution (over selectAsMethod()/showAsMethods()) is to avoid having
to introduce and expose 2 new names, so the user doesn't have to
switch between select*/show* tools depending on whether f="coerce"
or not.
H.
John
On 4/1/10 12:31 AM, Hervé Pagès wrote:
Hi John,
John Chambers wrote:
The example is confusing and debatable, but not an obvious bug. And
your presentation of it is the cause of much of the confusion
(unintentionally I'm sure).
First, slipping from the as() function to methods for the coerce()
function might surprise a less experienced user. And in fact, that
is the point here
[Rd] packages with DLLs under 2.12.0
I realize that R-core must be busy with the imminent release of
2.11.0, so please consider this not urgent.
The NEWS file for 2.12.0 (Windows-specific) says, in part:
For now, 32-bit packages with compiled code built under
2.{10,11}.x can be used, but this will be disabled before
release.
For me, this doesn't work without a tweak. For example,
> library(mvtnorm)
#Error: package 'mvtnorm' is not installed for 'arch=i386'
I tested a few (6 or 7) other randomly selected packages
(bitops, igraph, ...) before wising up and looking at the
recommended and automatically installed packages like
lattice, etc. I see that the 'libs' folder now has an
'i386' subfolder where the DDLs reside.
Making that change by hand fixes the 'problem'.
> sessionInfo()
R version 2.12.0 Under development (unstable) (2010-03-31 r51520)
i386-pc-mingw32
locale:
[1] LC_COLLATE=English_Canada.1252 LC_CTYPE=English_Canada.1252
[3] LC_MONETARY=English_Canada.1252 LC_NUMERIC=C
[5] LC_TIME=English_Canada.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] mvtnorm_0.9-9
loaded via a namespace (and not attached):
[1] tools_2.12.0
--
Peter Ehlers
University of Calgary
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] inject html code into Rd file
On 02/04/2010 8:06 AM, Duncan Murdoch wrote:
On 02/04/2010 7:13 AM, Romain Francois wrote:
Le 02/04/10 13:07, Duncan Murdoch a écrit :
On 02/04/2010 6:17 AM, Romain Francois wrote:
Hello,
I'm trying to inject html code into an Rd file. For example :
\name{test}
\alias{test}
\title{test}
\description{
\if{html}{
\Sexpr[stage=render,results=text,echo=FALSE]{
"hello"
}
}
}
when this file is rendered, instead of having "hello" in bold, I get
hello, i.e. characters < and > are replaced with html entities
: < and >
Is there a way to turn this off ?
Yes, if you wrap it in \out{}. The example in the manual is
\if{latex}{\out{\alpha}}\ifelse{html}{\out{α}}{alpha}
Duncan Murdoch
yes, I saw that in WRE, I should have been more specific.
what if instead of a trivial string like "hello" the text is to
be computed by some function. For example:
print( xtable( iris), type = "html" )
I think this should do it:
\Sexpr[stage=render,results=rd,echo=FALSE]{
paste("\\out{", "hello, "}", sep="")}
but this stuff hasn't been tested much, so there might be problems...
One problem is that the backslashes need to be escaped twice, so you'd want
\Sexpr[stage=render,results=rd,echo=FALSE]{
paste("out{", "hello, "}", sep="")}
and you'd probably want it wrapped in \if or \ifelse so that it doesn't
show up in text or latex output:
\Sexpr[stage=render,results=rd,
echo=FALSE]{"if{html}{out{hello}}"}
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] packages with DLLs under 2.12.0
That may have been true in r51520, but we are at r51566 and that does
work as documented AFAICS.
Note though that this is only a temporary workaround, and it will go
away once repositories are rebuilt for 2.12.0, and simply bulding the
packages from sources would have worked.
On Fri, 2 Apr 2010, Peter Ehlers wrote:
I realize that R-core must be busy with the imminent release of
2.11.0, so please consider this not urgent.
The advice for R-devel is always to try the latest version (preferably
from SVN) and to wait a couple of days and try again if you find a
problem, before reporting.
R-devel is particularly unstable at present as we work on merging the
32- and 64-bit Windows distributions. Unless you have a very good
reason to use it, we suggest using 2.11.0 alpha etc until 2.11.0 is
released.
The NEWS file for 2.12.0 (Windows-specific) says, in part:
You mean the CHANGES file?
For now, 32-bit packages with compiled code built under
2.{10,11}.x can be used, but this will be disabled before
release.
For me, this doesn't work without a tweak. For example,
library(mvtnorm)
#Error: package 'mvtnorm' is not installed for 'arch=i386'
I tested a few (6 or 7) other randomly selected packages
(bitops, igraph, ...) before wising up and looking at the
recommended and automatically installed packages like
lattice, etc. I see that the 'libs' folder now has an
'i386' subfolder where the DDLs reside.
Making that change by hand fixes the 'problem'.
sessionInfo()
R version 2.12.0 Under development (unstable) (2010-03-31 r51520)
i386-pc-mingw32
locale:
[1] LC_COLLATE=English_Canada.1252 LC_CTYPE=English_Canada.1252
[3] LC_MONETARY=English_Canada.1252 LC_NUMERIC=C
[5] LC_TIME=English_Canada.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] mvtnorm_0.9-9
loaded via a namespace (and not attached):
[1] tools_2.12.0
--
Peter Ehlers
University of Calgary
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
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
