Re: [Bioc-devel] R6 and Bioconductor

[Michael Lawrence]

Just to add to what Gabe already said, defer your performance concerns
until you've actually got something that works and is well written. If
you hit up against a performance barrier, come back and we can help.

On Fri, May 12, 2017 at 4:22 PM, Garth Ilsley  wrote:
> Thank you.
>
>> One place where one might think of using R6 is in the implementation of a 
>> mutable data model underlying a GUI like a Shiny app. > If mutable semantics 
>> are required, consider using S4 reference classes, as they offer more 
>> features than R6 and will integrate
>> directly with Bioconductor S4 classes.
>
> If I understand correctly, you are saying that it is fine to use Reference 
> classes (mutable semantics) in Bioconductor. A GUI is one clear place for 
> this. However, what about a large dataset that is subject to progressive 
> analysis with various fields updated as the analysis proceeds? The typical 
> Bioconductor approach (as far as I have seen) is to call a method defined for 
> an S4 functional class that produces a new object of the same class, with the 
> result assigned to the same name as the original object.  For a project 
> considered in isolation, it wouldn't be unreasonable to use a Reference class 
> for this instead, but that's not what I'm asking. My question is about the 
> standards and approach that Bioconductor has agreed on - to ensure 
> consistency. Is a Reference Class permissible in this situation? If not, case 
> closed. If they are permitted, I would suggest that R6 semantics are 
> consistent with Reference Class semantics, but with the added benefit of 
> private members and "active bin
 di
>  ngs" (they look like fields, but call a function). This is nice and simple 
> (for the creator and user of the class), but if not desired (for consistency 
> etc.), then I presume Reference Classes will do fine.
>
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] R6 and Bioconductor

[Gabe Becker]

On May 12, 2017 4:23 PM, "Garth Ilsley"  wrote:

Thank you.

> One place where one might think of using R6 is in the implementation of a
mutable data model underlying a GUI like a Shiny app. > If mutable
semantics are required, consider using S4 reference classes, as they offer
more features than R6 and will integrate
> directly with Bioconductor S4 classes.

If I understand correctly, you are saying that it is fine to use Reference
classes (mutable semantics) in Bioconductor. A GUI is one clear place for
this. However, what about a large dataset that is subject to progressive
analysis with various fields updated as the analysis proceeds? The typical
Bioconductor approach (as far as I have seen) is to call a method defined
for an S4 functional class that produces a new object of the same class,
with the result assigned to the same name as the original object.  For a
project considered in isolation, it wouldn't be unreasonable to use a
Reference class for this instead, but that's not what I'm asking. My
question is about the standards and approach that Bioconductor has agreed
on - to ensure consistency. Is a Reference Class permissible in this
situation?


I dont speak for the project, but i would suggest that reference classes
are really best/(almost) only useful for encoding state in
complex/unusual-for-r package code. Having user-facing objects with these
mechanics violates a pretty central idiom of R (copy on write) and thus is
imo substantially more damaging than it is worth in general.

One of the things that makes r simpler for beginners than other languages
is that when they pass an object to a function that function "can't" change
the version they have in their workspace.

If not, case closed. If they are permitted, I would suggest that R6
semantics are consistent with Reference Class semantics, but with the added
benefit of private members and "active bindi
 ngs" (they look like fields, but call a function).


Refence classes absolutely can have active binding fields. It is pretty
standard practice I think.

As for private fields, no they don't have that, but I've never really been
convinced you need them in the vast vast majority of cases. R is designed
such that the user owns their data (ie the contents of their objects). I've
never really heard a good augment why that shouldn't be the case.

That said the typical idiom in all of my code is to have paired fields, an
active binding which is a function. That does some checking/processing and
a classed field with the same name prepended with a . That it corresponds
to.

Also R6 aren't really compatible with reference class/S4 mechanics because
the fields are not classed. This may sound like a small thing but imo it's
actually quite important.

Best,
~G


This is nice and simple (for the creator and user of the class), but if not
desired (for consistency etc.), then I presume Reference Classes will do
fine.


___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] R6 and Bioconductor

[Garth Ilsley]

Thank you.

> One place where one might think of using R6 is in the implementation of a 
> mutable data model underlying a GUI like a Shiny app. > If mutable semantics 
> are required, consider using S4 reference classes, as they offer more 
> features than R6 and will integrate
> directly with Bioconductor S4 classes.

If I understand correctly, you are saying that it is fine to use Reference 
classes (mutable semantics) in Bioconductor. A GUI is one clear place for this. 
However, what about a large dataset that is subject to progressive analysis 
with various fields updated as the analysis proceeds? The typical Bioconductor 
approach (as far as I have seen) is to call a method defined for an S4 
functional class that produces a new object of the same class, with the result 
assigned to the same name as the original object.  For a project considered in 
isolation, it wouldn't be unreasonable to use a Reference class for this 
instead, but that's not what I'm asking. My question is about the standards and 
approach that Bioconductor has agreed on - to ensure consistency. Is a 
Reference Class permissible in this situation? If not, case closed. If they are 
permitted, I would suggest that R6 semantics are consistent with Reference 
Class semantics, but with the added benefit of private members and "active bindi
 ngs" (they look like fields, but call a function). This is nice and simple 
(for the creator and user of the class), but if not desired (for consistency 
etc.), then I presume Reference Classes will do fine.


___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] Question about BiocGeneric::order

[Michael Lawrence]

Thanks for noticing that. I'll fix that in R soon. I'm going through
and generalizing many of the stats default methods so that they work
automatically with Rle.

For order,Rle(), I fixed the method argument default and added a fast
path for the single arg case. I guess we'll keep it around.

On Thu, May 11, 2017 at 6:47 PM, Hervé Pagès  wrote:
> On 05/11/2017 06:44 PM, Hervé Pagès wrote:
>>
>> Hi Michael,
>>
>> On 05/11/2017 03:27 PM, Michael Lawrence wrote:
>>>
>>> There is a bug in S4Vectors, but thanks to an R 3.4 bug in the methods
>>> package (recently fixed in devel), the bug is masked. So, we should
>>> fix S4Vectors. The problem is that order,Rle has a default for the
>>> 'method' argument that differs from that of the generic. Since R 3.3,
>>> base::order() is smart enough to basically do the same thing as
>>> order,Rle(). I'll go ahead and remove the method.
>>
>>
>> Note that base::order() is much slower than the method for Rle objects:
>
>
> Forgot to copy/paste this:
>
>   library(S4Vectors)
>   x <- Rle(sample(25L, 50L, replace=TRUE) - 8L,
>sample(13L, 50L, replace=TRUE))
>
>>
>>> system.time(oo1 <- order(x))
>>
>>user  system elapsed
>>   0.018   0.000   0.018
>>
>>> system.time(oo2 <- base::order(x))
>>
>>user  system elapsed
>>   1.089   0.000   1.103
>>
>>> identical(oo1, oo2)
>>
>> [1] TRUE
>>
>> Looks like by default, base::order() does not pick up the fastest
>> method (radix):
>>
>>> system.time(oo2 <- base::order(x, method="radix"))
>>
>>user  system elapsed
>>   0.020   0.000   0.019
>
>
> and to provide my sessionInfo():
>
>> sessionInfo()
> R version 3.4.0 Patched (2017-04-26 r72630)
> Platform: x86_64-pc-linux-gnu (64-bit)
> Running under: Ubuntu 14.04.5 LTS
>
> Matrix products: default
> BLAS: /home/hpages/R/R-3.4.r72630/lib/libRblas.so
> LAPACK: /home/hpages/R/R-3.4.r72630/lib/libRlapack.so
>
> locale:
>  [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C
>  [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
>  [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
>  [7] LC_PAPER=en_US.UTF-8   LC_NAME=C
>  [9] LC_ADDRESS=C   LC_TELEPHONE=C
> [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
>
> attached base packages:
> [1] parallel  stats4stats graphics  grDevices utils datasets
> [8] methods   base
>
> other attached packages:
> [1] S4Vectors_0.15.2BiocGenerics_0.23.0
>
> loaded via a namespace (and not attached):
> [1] compiler_3.4.0 tools_3.4.0
>
> H.
>
>
>>
>> H.
>>
>>>
>>> Michael
>>>
>>> On Thu, May 11, 2017 at 1:29 PM, Ou, Jianhong
>>>  wrote:

 Thank you Hervé,

 I got that. Good to know that BioC 3.6 require R 3.4.0.

 Yours Sincerely,

 Jianhong Ou

 TEL: 508-856-5379
 LRB 608
 Bioinformatician of Bioinformatics core at
 Department of Molecular, Cell and Cancer Biology
 UMASS Medical School
 364 Plantation Street Worcester,
 MA 01605

 Confidentiality Notice:
 This e-mail message, including any attachments, is for the sole use
 of the intended recipient(s) and may contain confidential,
 proprietary and privileged information. Any unauthorized review, use,
 disclosure or distribution is prohibited. If you are not the intended
 recipient, please contact the sender immediately and destroy or
 permanently delete all copies of the original message.





 On 5/11/17, 4:25 PM, "Hervé Pagès"  wrote:

 Hi Jianhong,

 I can't reproduce this but I'm using R 3.4.0.
 You seem to be using Bioc devel (aka BioC 3.6) with R devel.
 This is not supported. Both, BioC 3.5 (current release) and
 BioC 3.6 require R 3.4.0.

 Cheers,
 H.


 On 05/11/2017 01:11 PM, Ou, Jianhong wrote:
 > I got error when I try order for Rle object by following codes:
 >
 > library("BiocGenerics")
 > library(XVector)
 > order(Rle(1))
 > ## Error in match.arg(method) : 'arg' must be of length 1
 >
 >> sessionInfo()
 > R Under development (unstable) (2017-05-10 r72667)
 > Platform: x86_64-apple-darwin16.5.0 (64-bit)
 > Running under: macOS Sierra 10.12.4
 >
 > Matrix products: default
 > BLAS:

 /Library/Frameworks/R.framework/Versions/3.5/Resources/lib/libRblas.dylib

 > LAPACK:

 /Library/Frameworks/R.framework/Versions/3.5/Resources/lib/libRlapack.dylib

 >
 > locale:
 > [1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
 >
 > attached base packages:
 > [1] stats4parallel  stats graphics  grDevices utils
 datasets
 > [8] methods   base
 >
 > other attached packages:
 > [1] XVector_0.17.0  IRanges_2.11.2  S4Vectors_0.15.1

Re: [Bioc-devel] unable to push local changes to bioconductor svn repository

[Martin Morgan]

On 05/11/2017 10:02 AM, Xu, Zongli (NIH/NIEHS) [E] wrote:

Hi,



I got a new Linux computer, cloned my package from github, made some
changes. I am able to update the changes to github, but can not push
it to Bioconductor svn repository. Can someone help me to solve the
problem.



The following is what I did:



git svn clone https://github.com/xuz1/ENmix


The github repository is just a git repository, not SVN; you should 
follow the directions at scenario 2 of


  http://bioconductor.org/developers/how-to/git-mirrors/

checkout the git repository, add svn remotes, rebase with svn, make git 
commits, then dcommit to svn.


Martin




cd ENmix

bash ../update_remotes.sh



#push to github

git checkout master

git add -A .

git commit -a -s -m "commit made by Xu"

git remote -v

git push origin master



#push to Bioconductor svn

git checkout devel



I am good up to here, but when I run the following command

git svn rebase --username  z.xu



It showed the following error message:



Data from a previous version of git-svn exists, but

.git/svn

(required for this version (1.7.1) of git-svn) does not exist.

Done migrating from a git-svn v1 layout

Unable to determine upstream SVN information from working tree
history



Can anyone guide me what should I do to solve this problem.



Thanks,

Zongli

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel




This email message may contain legally privileged and/or...{{dropped:2}}

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Rd] xrealloc namespace conflict

[Patrick Perry]

Thanks for the response. It looks like there is a dlopen flag that will 
fix the issue on Linux (RTLD_DEEPBIND); on Mac OS, symbols get resolved 
by searching in the library first, so the flag isn't needed. I don't 
know what the default behavior is on other platforms. See, e.g. 
https://software.intel.com/en-us/articles/ensuring-shared-library-uses-intel-math-functions
 
.

The use of RTLD_DEEPBIND is not portable, and "should only be used as a 
last resort" according to Ulrich Drepper: 
https://software.intel.com/sites/default/files/m/a/1/e/dsohowto.pdf .

I'll probably end up prefixing all of my functions with "corpus_" to 
avoid future namespace clashers.


Patrick


Dirk Eddelbuettel wrote:
>
> On 11 May 2017 at 12:16, Patrick Perry wrote:
> | I've done a bit more investigation into this issue. Here is my current
> | understanding of the situation:
> |
> | 1. I have a package on CRAN (corpus-0.3.1) that passes tests on all
> | platforms except for Linux.
> | 2. My package defines a C function, "xrealloc", for internal use.
> | 3. The libreadline library that R links to defines a different version
> | of "xrealloc".
> | 4. On Linux, when I load my package, references to "xrealloc" get linked
> | to the libreadline version of that function.
> | 5. This causes one of my tests to fail, calling exit(2), because the
> | libreadline version of xrealloc does not allow calls of the form
> | "xrealloc(ptr, 0)".
> |
> | I can work around this issue pretty easily, by either renaming my
> | version of xrealloc to something else, or by avoiding calls of the form
> | "xrealloc(ptr, 0)". So, this is not a major issue, but it's a little
> | unsettling to see this behavior when my package does not explicitly link
> | to or use anything from libreadline.
> |
> | Is there a reason this behavior is only manifesting on Linux? Is there
> | something wrong with the way I'm compiling my package on that platform?
> | Is this just some quirk about the way R is loading dynamic libraries on
> | Linux? I'd appreciate any insight into the issue.
>
> It may just be the flat namespace and linking order. AFAIK there is 
> nothing
> in C preventing so maybe you 'just got lucky' on the other platforms. 
> See eg
> http://stackoverflow.com/questions/7998770/
>
> But then I don't use pure C that after anymore ... and in C++ you 
> could just
> wrap a namespace around your code, avoiding the issue.
>
>
> Dirk


> Dirk Eddelbuettel 
> May 11, 2017 at 1:29 PM
> On 11 May 2017 at 12:16, Patrick Perry wrote:
> | I've done a bit more investigation into this issue. Here is my current
> | understanding of the situation:
> |
> | 1. I have a package on CRAN (corpus-0.3.1) that passes tests on all
> | platforms except for Linux.
> | 2. My package defines a C function, "xrealloc", for internal use.
> | 3. The libreadline library that R links to defines a different version
> | of "xrealloc".
> | 4. On Linux, when I load my package, references to "xrealloc" get 
> linked
> | to the libreadline version of that function.
> | 5. This causes one of my tests to fail, calling exit(2), because the
> | libreadline version of xrealloc does not allow calls of the form
> | "xrealloc(ptr, 0)".
> |
> | I can work around this issue pretty easily, by either renaming my
> | version of xrealloc to something else, or by avoiding calls of the form
> | "xrealloc(ptr, 0)". So, this is not a major issue, but it's a little
> | unsettling to see this behavior when my package does not explicitly 
> link
> | to or use anything from libreadline.
> |
> | Is there a reason this behavior is only manifesting on Linux? Is there
> | something wrong with the way I'm compiling my package on that platform?
> | Is this just some quirk about the way R is loading dynamic libraries on
> | Linux? I'd appreciate any insight into the issue.
>
> It may just be the flat namespace and linking order. AFAIK there is 
> nothing
> in C preventing so maybe you 'just got lucky' on the other platforms. 
> See eg
> http://stackoverflow.com/questions/7998770/
>
> But then I don't use pure C that after anymore ... and in C++ you 
> could just
> wrap a namespace around your code, avoiding the issue.
>
>
> Dirk
>
> Patrick Perry 
> May 11, 2017 at 12:16 PM
> I've done a bit more investigation into this issue. Here is my current 
> understanding of the situation:
>
> 1. I have a package on CRAN (corpus-0.3.1) that passes tests on all 
> platforms except for Linux.
> 2. My package defines a C function, "xrealloc", for internal use.
> 3. The libreadline library that R links to defines a different version 
> of "xrealloc".
> 4. On Linux, when I load my package, references to "xrealloc" get 
> linked to the libreadline version of that function.
> 5. This causes one of my tests to fail, calling exit(2), because the 
> libreadline version of xrealloc does not allow calls of the form 
> "xrealloc(ptr, 0)".
>
> I can work around this issue pretty easily, by either 

Re: [Bioc-devel] R6 and Bioconductor

[Michael Lawrence]

One place where one might think of using R6 is in the implementation
of a mutable data model underlying a GUI like a Shiny app. If mutable
semantics are required, consider using S4 reference classes, as they
offer more features than R6 and will integrate directly with
Bioconductor S4 classes.

Michael

On Thu, May 11, 2017 at 11:05 PM, Garth Ilsley  wrote:
> Hello,
>
> I am thinking of creating package for Bioconductor, and I am wondering about 
> the use of R6 classes (from the R6 package). I do indeed intend to use 
> existing Bioconductor classes such as SummarizedExperiment and interact and 
> make use of other Bioconductor packages, such as scater and DESeq2. This 
> appears to be in accordance with the guidelines 
> (https://www.bioconductor.org/developers/package-guidelines/#classes), but 
> does the use of R6 classes disqualify the package from being in Bioconductor? 
> Do I need to write my classes as S4 in order to qualify?
>
> Thank you for your help.
>
> Best regards,
> Garth
>
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] R6 and Bioconductor

[Martin Morgan]

On 05/12/2017 07:11 AM, Martin Morgan wrote:

On 05/12/2017 02:05 AM, Garth Ilsley wrote:

Hello,

I am thinking of creating package for Bioconductor, and I am wondering
about the use of R6 classes (from the R6 package). I do indeed intend
to use existing Bioconductor classes such as SummarizedExperiment and
interact and make use of other Bioconductor packages, such as scater
and DESeq2. This appears to be in accordance with the guidelines
(https://www.bioconductor.org/developers/package-guidelines/#classes),
but does the use of R6 classes disqualify the package from being in
Bioconductor? Do I need to write my classes as S4 in order to qualify?



I think there's little value in exposing R6 classes to Bioconductor
users, introducing yet another syntax and semantics, and would strongly
discourage their use outside the package name space.

Inside the package name space the maintainer has more liberty to adopt
programming practices that are geared toward correct and efficient
implementations; if R6 fills this role (I'm not an expert, but I don't
think R6 enforces strong type checking and is not particularly
efficient) then it would be appropriate to use them.


Maybe one additional point is that perhaps 'write my classes' implies 
that you'll be creating new classes; it might often be better to re-use 
existing classes, or worst-case write simple extensions (e.g., an 
additional slot to SummarizedExperiment) to existing classes. In this 
way you re-use existing robust software and don't further overwhelm the 
cognitive burden placed on the user struggling to navigate yet more 
functionality.


Martni



Martin


Thank you for your help.

Best regards,
Garth


[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel




This email message may contain legally privileged and/or...{{dropped:2}}

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel



This email message may contain legally privileged and/or...{{dropped:2}}

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Bioc-devel] R6 and Bioconductor

[Martin Morgan]

On 05/12/2017 02:05 AM, Garth Ilsley wrote:

Hello,

I am thinking of creating package for Bioconductor, and I am wondering about 
the use of R6 classes (from the R6 package). I do indeed intend to use existing 
Bioconductor classes such as SummarizedExperiment and interact and make use of 
other Bioconductor packages, such as scater and DESeq2. This appears to be in 
accordance with the guidelines 
(https://www.bioconductor.org/developers/package-guidelines/#classes), but does 
the use of R6 classes disqualify the package from being in Bioconductor? Do I 
need to write my classes as S4 in order to qualify?



I think there's little value in exposing R6 classes to Bioconductor 
users, introducing yet another syntax and semantics, and would strongly 
discourage their use outside the package name space.


Inside the package name space the maintainer has more liberty to adopt 
programming practices that are geared toward correct and efficient 
implementations; if R6 fills this role (I'm not an expert, but I don't 
think R6 enforces strong type checking and is not particularly 
efficient) then it would be appropriate to use them.


Martin


Thank you for your help.

Best regards,
Garth


[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel




This email message may contain legally privileged and/or...{{dropped:2}}

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

[Bioc-devel] R6 and Bioconductor

[Garth Ilsley]

Hello,

I am thinking of creating package for Bioconductor, and I am wondering about 
the use of R6 classes (from the R6 package). I do indeed intend to use existing 
Bioconductor classes such as SummarizedExperiment and interact and make use of 
other Bioconductor packages, such as scater and DESeq2. This appears to be in 
accordance with the guidelines 
(https://www.bioconductor.org/developers/package-guidelines/#classes), but does 
the use of R6 classes disqualify the package from being in Bioconductor? Do I 
need to write my classes as S4 in order to qualify?

Thank you for your help.

Best regards,
Garth


[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Rd] R-3.3.3/R-3.4.0 change in sys.call(sys.parent())

[Deepayan Sarkar]

On Thu, May 11, 2017 at 8:03 PM, William Dunlap  wrote:
> Here is a case where the current scheme fails:
>
>   > with(datasets::mtcars, xyplot(mpg~wt|gear)$call)
>   xyplot(substitute(expr), data, enclos = parent.frame())

Right, thanks. So I guess I can't avoid setting $call inside every method.

-Deepayan

> Bill Dunlap
> TIBCO Software
> wdunlap tibco.com
>
> On Thu, May 11, 2017 at 1:09 AM, Deepayan Sarkar 
> wrote:
>>
>> On Wed, May 10, 2017 at 2:36 AM, William Dunlap via R-devel
>>  wrote:
>> > Some formula methods for S3 generic functions use the idiom
>> > returnValue$call <- sys.call(sys.parent())
>> > to show how to recreate the returned object or to use as a label on a
>> > plot.  It is often followed by
>> >  returnValue$call[[1]] <- quote(myName)
>> > E.g., I see it in packages "latticeExtra" and "leaps", and I suspect it
>> > used in "lattice" as well.
>> >
>> > This idiom has not done good things for quite a while (ever?) but I
>> > noticed
>> > while running tests that it acts differently in R-3.4.0 than in R-3.3.3.
>> > Neither the old or new behavior is nice.  E.g., in R-3.3.3 we get
>> >
>> >> parseEval <- function(text, envir) eval(parse(text=text), envir=envir)
>> >> parseEval('lattice::xyplot(mpg~hp, data=datasets::mtcars)$call',
>> > envir=new.env())
>> > xyplot(expr, envir, enclos)
>> >
>> > and
>> >
>> >> evalInEnvir <- function(call, envir) eval(call, envir=envir)
>> >> evalInEnvir(quote(lattice::xyplot(mpg~hp, data=datasets::mtcars)$call),
>> > envir=new.env())
>> > xyplot(expr, envir, enclos)
>> >
>> > while in R-3.4.0 we get
>> >> parseEval <- function(text, envir) eval(parse(text=text), envir=envir)
>> >> parseEval('lattice::xyplot(mpg~hp, data=datasets::mtcars)$call',
>> > envir=new.env())
>> > xyplot(parse(text = text), envir = envir)
>> >
>> > and
>> >
>> >> evalInEnvir <- function(call, envir) eval(call, envir=envir)
>> >> evalInEnvir(quote(lattice::xyplot(mpg~hp, data=datasets::mtcars)$call),
>> > envir=new.env())
>> > xyplot(call, envir = envir)
>> >
>> > Should these packages be be fixed up to use just sys.call()?
>>
>> I admit to not understanding these things very well, but I'll try to
>> explain why I ended up with the usage I have. The main use of the
>> $call component within lattice is to use it in the summary method, as
>> in:
>>
>> > summary(xyplot(mpg~hp, data=mtcars))
>>
>> Call:
>> xyplot(mpg ~ hp, data = mtcars)
>>
>> Number of observations:
>> [1] 32
>>
>> Here is a minimal approximation to what I need: Here foo() and bar()
>> are generics producing objects of class "foobar", bar() calls foo()
>> with one argument changed, and the print() method for "foobar" is just
>> supposed to print the call that produced it:
>>
>> 
>>
>> foo <- function(x, ...) UseMethod("foo")
>> bar <- function(x, ...) UseMethod("bar")
>> print.foobar <- function(x, ...) print(x$call)
>>
>> ## Using plain sys.call():
>>
>> foo.formula <- function(x, ...)
>> {
>> ans <- structure(list(), class = "foobar")
>> ans$call <- sys.call()
>> ans
>> }
>>
>> bar.formula <- function(x, ..., panel)
>> {
>> foo.formula(x, ..., panel = panel.bar)
>> }
>>
>> foo.table <- function(x, ...)
>> {
>> ans <- foo.formula(Freq ~ Var1,
>>as.data.frame.table(x), ...)
>> ans
>> }
>>
>> ## I would get
>>
>> foo(y ~ x)
>> # foo.formula(y ~ x)
>>
>> bar(y ~ x)
>> # foo.formula(x, ..., panel = panel.bar)
>>
>> foo(as.table(1:10))
>> # foo.formula(Freq ~ Var1, as.data.frame.table(x), ...)
>>
>> ## The last two are improved by
>>
>> foo.formula <- function(x, ...)
>> {
>> ans <- structure(list(), class = "foobar")
>> ans$call <- sys.call(sys.parent())
>> ans
>> }
>>
>> bar(y ~ x)
>> ## bar.formula(y ~ x)
>>
>> foo(as.table(1:10))
>> ## foo.table(as.table(1:10))
>>
>> 
>>
>> Adding
>>
>> ans$call[[1]] <- quote(foo)
>>
>> (or quote(bar) in bar.formula) is needed to replace the unexported
>> method name (foo.formula) with the generic name (foo), but that's
>> probably not the problem.
>>
>> With this approach in lattice,
>>
>> p <- some.function(...)
>> eval(p$call)
>>
>> usually works, but not always, if I remember correctly.
>>
>> I'm happy to consider more robust solutions. Maybe I just need to have a
>>
>> ...$call <- sys.call()
>>
>> statement in every method?
>>
>> -Deepayan
>
>

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