Hi! In R 2.14.0dev (R version 2.14.0 Under development (unstable) (2011-04-29 r55692), Windows release (http://cran.r-project.org/bin/windows/base/rdevel.html), the line : options(width=55) in code chunk of an Rnw file has no effect on sweave's output text file. The same thing in 2.13.0 worked. WBR, ALexander Favorov
If this message is garbled for anyone else, the original question on stackoverflow is here: http://stackoverflow.com/questions/5841339/using-notation-for-reference-class-methods Hadley On Sat, Apr 30, 2011 at 11:35 AM, Chad Goymer <chad.goymer <at> hotmail.co.uk> wrote: > > I've been trying to use methods for reference classes via the notation "[[...]]" (X[["doSomething"]] rather than X$doSomething), but it failed to work. However, I did find that if you use the usual "$" notation first, "[[...]]" can be used afterwards. The following simple example illustrates the point: >> setRefClass("Number", + Â fields = list(+ Â Â value = "numeric"+ Â ),+ Â methods = list(+ Â Â addOne = function() {+ Â Â Â value <<- value + 1+ Â Â }+ Â )+ )> X <- new("Number", value = 1)> X[["value"]][1] 1 >> X[["addOne"]]()Error: attempt to apply non-function> class(X[["addOne"]]) # NULL[1] "NULL" >> class(X$addOne)[1] "refMethodDef"attr(,"package")[1] "methods" >> X[["addOne"]]()> X[["value"]][1] 2> class(X[["addOne"]])[1] "refMethodDef"attr(,"package")[1] "methods" > Is this a bug? > Chad Goymer > > Â Â Â Â [[alternative HTML version deleted]] > > ______________________________________________ > R-devel <at> r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- -- Assistant Professor / Dobelman Family Junior Chair Department of Statistics / Rice University(Continue reading)
On 30/04/11 7:25 PM, Alexander Favorov wrote: > Hi! > > In R 2.14.0dev (R version 2.14.0 Under development (unstable) > (2011-04-29 r55692), Windows release > (http://cran.r-project.org/bin/windows/base/rdevel.html), the line : > > options(width=55) > > in code chunk of an Rnw file has no effect on sweave's output text file. > > The same thing in 2.13.0 worked. > What effect do you expect? That would only have an effect if - the option value was different before that line, and - you printed something that would differ in the two widths. Please put together an example to illustrate what problem you're seeing. Duncan Murdoch
Dear Duncan, dear Uwe, Since I have installed both WinXP and OpenSUSE 11.3 on my Mac in a virtual machine, I have now done the following tests on all three architectures: 1, R CMD build xps: This creates "xps_1.13.1.tar.gz" which DOES contain all vignettes as pdf-file. Thus R CMD build is ok. 2, R CMD check xps: This does NOT build the vignettes as pdf-files on all three architectures. Or to be more precise, R-2.13.0 does no longer build the vignettes since with R-2.12.2 and earlier versions R did create the vignettes as pdf-files. Thus the question is: Why does R CMD check no longer create the vignettes? Best regards Christian On 4/27/11 10:16 AM, Uwe Ligges wrote: > > > On 26.04.2011 21:58, cstrato wrote: >> Dear Duncan, dear Uwe, >> >> Just now I have re-run everything, and today xps.Rnw can be converted to >> a vignette w/o any problems using:(Continue reading)
Yes, as presented on that site it makes a little more sense: "While experimenting with the new reference classes in R I noticed some odd behaviour if you use the "[[ ]]" notation for methods (X[["doSomething"]] instead of X$doSomething). This notation works for fields, but I initially thought it wouldn't work for methods until I found that if you execute "class(X$doSomething)" you can then use "[[ ]]" afterwards. The simple example below illustrates the point." For reference classes, "[[" is not meant to be used either for fields or methods. That it "works" at all is an artifact of the implementation using environments. And arguably the failure to throw an error in that circumstance is a bug. Please use the API as described in the ?ReferenceClasses documentation. These are encapsulated methods, in the usual terminology, with the operator "$" playing the role normally assigned to "." in other languages. A separate but related issue: It is possible to define S4 methods for reference classes, as discussed in a previous thread, arguably also an artifact in that a reference class is implemented as an S4 class of the same name. These are functional methods, associated with a generic function, and so outside the encapsulation paradigm. It would be interesting to get some experience and opinions on whether this is a good idea or not. It breaks encapsulation, in that the behavior of the class can no longer be inferred from the class definition alone. On the other hand, it is convenient and relates to "operator overloading" in some other languages.(Continue reading)
On 05/01/2011 03:09 PM, John Chambers wrote: > Yes, as presented on that site it makes a little more sense: > > "While experimenting with the new reference classes in R I noticed some > odd behaviour if you use the "[[ ]]" notation for methods > (X[["doSomething"]] instead of X$doSomething). This notation works for > fields, but I initially thought it wouldn't work for methods until I > found that if you execute "class(X$doSomething)" you can then use "[[ > ]]" afterwards. The simple example below illustrates the point." > > For reference classes, "[[" is not meant to be used either for fields or > methods. That it "works" at all is an artifact of the implementation > using environments. And arguably the failure to throw an error in that > circumstance is a bug. > > Please use the API as described in the ?ReferenceClasses documentation. > These are encapsulated methods, in the usual terminology, with the > operator "$" playing the role normally assigned to "." in other languages. > > A separate but related issue: It is possible to define S4 methods for > reference classes, as discussed in a previous thread, arguably also an > artifact in that a reference class is implemented as an S4 class of the > same name. These are functional methods, associated with a generic > function, and so outside the encapsulation paradigm. > > It would be interesting to get some experience and opinions on whether > this is a good idea or not. It breaks encapsulation, in that the > behavior of the class can no longer be inferred from the class > definition alone. On the other hand, it is convenient and relates to > "operator overloading" in some other languages.(Continue reading)
On 11-05-01 7:35 AM, Duncan Murdoch wrote: > On 30/04/11 7:25 PM, Alexander Favorov wrote: >> Hi! >> >> In R 2.14.0dev (R version 2.14.0 Under development (unstable) >> (2011-04-29 r55692), Windows release >> (http://cran.r-project.org/bin/windows/base/rdevel.html), the line : >> >> options(width=55) >> >> in code chunk of an Rnw file has no effect on sweave's output text file. >> >> The same thing in 2.13.0 worked. >> > > What effect do you expect? That would only have an effect if > - the option value was different before that line, and > - you printed something that would differ in the two widths. > > Please put together an example to illustrate what problem you're seeing. > > Duncan Murdoch > Turned out (from a private email) that this has nothing to do with line breaking. It is just that the default in 2.14.0 is keep.source=TRUE, whereas it was keep.source=FALSE in previous versions. If you want the old behaviour, put \SweaveOpts{keep.source=FALSE}(Continue reading)
On 11-05-01 4:10 PM, cstrato wrote: > Dear Duncan, dear Uwe, > > Since I have installed both WinXP and OpenSUSE 11.3 on my Mac in a > virtual machine, I have now done the following tests on all three > architectures: > > 1, R CMD build xps: > This creates "xps_1.13.1.tar.gz" which DOES contain all vignettes as > pdf-file. Thus R CMD build is ok. > > 2, R CMD check xps: > This does NOT build the vignettes as pdf-files on all three > architectures. Or to be more precise, R-2.13.0 does no longer build the > vignettes since with R-2.12.2 and earlier versions R did create the > vignettes as pdf-files. > > Thus the question is: > Why does R CMD check no longer create the vignettes? Probably the answer is simply "because it doesn't". For a truly reliable check, you should build the package, then check the tar.gz file. Anything else is, and always has been, an approximation. Duncan Murdoch > > Best regards > Christian >(Continue reading)
On 5/1/11 3:37 PM, Martin Morgan wrote: > On 05/01/2011 03:09 PM, John Chambers wrote: >> Yes, as presented on that site it makes a little more sense: >> >> "While experimenting with the new reference classes in R I noticed some >> odd behaviour if you use the "[[ ]]" notation for methods >> (X[["doSomething"]] instead of X$doSomething). This notation works for >> fields, but I initially thought it wouldn't work for methods until I >> found that if you execute "class(X$doSomething)" you can then use "[[ >> ]]" afterwards. The simple example below illustrates the point." >> >> For reference classes, "[[" is not meant to be used either for fields or >> methods. That it "works" at all is an artifact of the implementation >> using environments. And arguably the failure to throw an error in that >> circumstance is a bug. >> >> Please use the API as described in the ?ReferenceClasses documentation. >> These are encapsulated methods, in the usual terminology, with the >> operator "$" playing the role normally assigned to "." in other >> languages. >> >> A separate but related issue: It is possible to define S4 methods for >> reference classes, as discussed in a previous thread, arguably also an >> artifact in that a reference class is implemented as an S4 class of the >> same name. These are functional methods, associated with a generic >> function, and so outside the encapsulation paradigm. >> >> It would be interesting to get some experience and opinions on whether >> this is a good idea or not. It breaks encapsulation, in that the >> behavior of the class can no longer be inferred from the class(Continue reading)
Hi
This is a basic "feature" of both strheight() and stringHeight(). They
both ignore any descenders in the text. I cannot remember why it was
done this way originally. The future solution is probably to add an
argument that allows descenders to be included in text height.
Plotmath works on bounding boxes so its behaviour is different, but of
course that has its own problems because there is no sense of "baseline"
for expressions.
Paul
On 27/04/2011 11:06 a.m., baptiste auguie wrote:
> Dear all,
>
> I'm puzzled by the behavior of stringHeight in the grid package.
> Consider the following test,
>
> library(grid)
>
> test<- function(lab="dog", ...){
> g1<- textGrob(lab)
> g2<- rectGrob(height=grobHeight(g1), width=grobWidth(g1))
> gg<- gTree(children=gList(g1,g2), ...)
>
> print(c("height:", convertUnit(stringHeight(lab), "mm", "y")))
> grid.draw(gg)
> }
>
(Continue reading)
RSS Feed174 | |
|---|---|
286 | |
230 | |
281 | |
209 | |
214 | |
162 | |
211 | |
176 | |
209 | |
180 | |
148 | |
242 | |
214 | |
343 | |
249 | |
241 | |
201 | |
330 | |
262 | |
221 | |
241 | |
247 | |
283 | |
369 | |
392 | |
285 | |
343 | |
215 | |
274 | |
300 | |
280 | |
322 | |
303 | |
250 | |
189 | |
232 | |
283 | |
285 | |
320 | |
259 | |
352 | |
495 | |
367 | |
463 | |
351 | |
267 | |
324 | |
353 | |
355 | |
529 | |
349 | |
322 | |
226 | |
315 | |
302 | |
207 | |
309 | |
246 | |
262 | |
400 | |
515 | |
314 | |
345 | |
324 | |
323 | |
272 | |
272 | |
267 | |
248 | |
279 | |
246 | |
389 | |
409 | |
371 | |
298 | |
385 | |
282 | |
396 | |
486 | |
456 | |
445 | |
397 | |
365 | |
411 | |
440 | |
382 | |
349 | |
389 | |
260 | |
318 | |
530 | |
366 | |
359 | |
272 | |
403 | |
318 | |
454 | |
271 | |
282 | |
261 | |
194 | |
385 | |
315 | |
269 | |
299 | |
260 | |
278 | |
111 |
