Re: [Rd] Adding text comments to graphics device output files?
On Jul 30, 2013, at 11:04 PM, Duncan Temple Lang wrote: > > Hi Henrik > > I have some extensions of Simon U's png package > to read and write metadata elements for PNG. > They are at > https://github.com/duncantl/png.git > > When I have time to completely test them, maybe Simon > may incorporate them. > I was looking at it and it was the last drop that made me push most of my packages to github so you don't need to fork by hand anymore ;). It's on my ToDo list to add port the changes one way or another - I think it's a good idea - thanks Duncan! Cheers, Simon > D. > > On 7/30/13 7:59 PM, Henrik Bengtsson wrote: >> Hi, >> >> several image file format supports textual/meta data comments in one >> way or the other. For me an obvious usage would be to add >> sessionInfo() information to PNG and PDF image files, ideally from >> within R although external tools would work as well(*). Has anyone >> looked into this or have any suggestions or comments? >> >> /Henrik >> >> (*) One could even imagine including self-contained R >> scripts/vignettes within such comments. >> >> __ >> 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 > > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Adding text comments to graphics device output files?
On Jul 31, 2013, at 12:12 AM, Henrik Bengtsson wrote: > Hi Duncan, > > this is perfect timing. Your > https://github.com/duncantl/png/blob/master/testMeta.R example > illustrates what I'm looking for. > > Yes, it would be great if this would be incorporated into the 'png' package. > Ok, I have added support for both text chunks and arbitrary R metadata to the PNG package. http://rforge.net/png The it is based on Duncan's idea, but the implementation and API is different -- Duncan's approach was implemented before png has support for the PNG info, so it is now simply extending that concept. You can store native text key/values pairs. In addition, R-native matadata can be attached -- it is stored as a special key "R.metadata" holding the serialization of the R object. See the last example in http://rforge.net/doc/packages/png/writePNG.html Feedback is welcome. Cheers, Simon > Thanks, > > Henrik > > On Tue, Jul 30, 2013 at 8:04 PM, Duncan Temple Lang > wrote: >> >> Hi Henrik >> >> I have some extensions of Simon U's png package >> to read and write metadata elements for PNG. >> They are at >> https://github.com/duncantl/png.git >> >> When I have time to completely test them, maybe Simon >> may incorporate them. >> >> D. >> >> On 7/30/13 7:59 PM, Henrik Bengtsson wrote: >>> Hi, >>> >>> several image file format supports textual/meta data comments in one >>> way or the other. For me an obvious usage would be to add >>> sessionInfo() information to PNG and PDF image files, ideally from >>> within R although external tools would work as well(*). Has anyone >>> looked into this or have any suggestions or comments? >>> >>> /Henrik >>> >>> (*) One could even imagine including self-contained R >>> scripts/vignettes within such comments. >>> >>> __ >>> 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 > > __ > 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] S3 internal and group generics
Hi all,
I've noticed a couple of small bugs/documentation errors related to S3
internal and group generics:
* In ?S3groupGeneric, log2 and log10 are not listed as group generics,
even though they are in the equivalent S4 groups, and are the source
code for do_log1arg contains DispatchGroup("Math", ...)
* As well as log2 and log10, tools:::.get_internal_S3_generics() fails
to include cbind and rbind, even though they are listed in ?"internal
generics"
Based on my reading of the documentation and the source code, I
believe this function lists all S3 internal generics:
s3_internal <- function(fname) {
# Functions in S4 group generics should be the same
group <- c(getGroupMembers("Arith"), getGroupMembers("Compare"),
getGroupMembers("Logic"), getGroupMembers("Math"), getGroupMembers("Math2"),
getGroupMembers("Summary"), getGroupMembers("Complex"))
primitive <- .S3PrimitiveGenerics
# Extracted from ?"internal generic"
internal <- c("[", "[[", "$", "[<-", "[[<-", "$<-", "unlist",
"cbind", "rbind", "as.vector")
c(group, primitive, internal)
}
Have I missed anything?
Thanks!
Hadley
--
Chief Scientist, RStudio
http://had.co.nz/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Depends vs Imports
I am being asked to modernize the Depends line in the DESCRIPTION file of some packages. Writing R Extensions says: The general rules are Packages whose namespace only is needed to load the package using library(pkgname) must be listed in the ‘Imports’ field and not in the ‘Depends’ field. Packages listed in imports or importFrom directives in the NAMESPACE file should almost always be in ‘Imports’ and not ‘Depends’. Packages that need to be attached to successfully load the package using library(pkgname) must be listed in the ‘Depends’ field, only. Could someone please explain a few points I thought I understood but obviously do not, or point to where these are explained: -What does it mean for the namespace only to be needed? I thought the namespace was needed if the package or some of its functions were mentioned in the NAMESPACE file, and that only the namespace was needed if only the generics were called, and not other functions. The above suggests that I may be wrong about this. If so, that is, Imports will usually suffice, then when would Depends ever be needed when a package is mentioned in the NAMESPACE file? -Should the package DESCRIPTION make any accommodation for the situation where users will probably need to directly call functions in the imported package, even though the package itself does not? -What does "need to be attached" mean? Is there a distinction between a package being attached and a namespace being attached. -Does "successfully load" mean something different from actually using the package? That is, can we assume that if the package loads then all the functions to run things will actually be found? -If pkg1 uses a function foo in pkg3 indirectly, by a call to a function in pkg2 which then uses foo, how should pkg1 indicate the relationship with foo's pkg3, or is there no need to indicate any relationship with pkg3 because that is all looked after by pkg2? Thanks, Paul __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Depends vs Imports
On Jul 31, 2013, at 7:14 PM, Paul Gilbert wrote: > I am being asked to modernize the Depends line in the DESCRIPTION file of > some packages. Writing R Extensions says: > > The general rules are > > Packages whose namespace only is needed to load the package using > library(pkgname) must be listed in the ‘Imports’ field and not in > the ‘Depends’ field. Packages listed in imports or importFrom > directives in the NAMESPACE file should almost always be in > ‘Imports’ and not ‘Depends’. > > Packages that need to be attached to successfully load the >package using library(pkgname) must be listed in the >‘Depends’ field, only. > > Could someone please explain a few points I thought I understood but > obviously do not, or point to where these are explained: > > -What does it mean for the namespace only to be needed? I thought the > namespace was needed if the package or some of its functions were mentioned > in the NAMESPACE file, and that only the namespace was needed if only the > generics were called, and not other functions. The above suggests that I may > be wrong about this. If so, that is, Imports will usually suffice, then when > would Depends ever be needed when a package is mentioned in the NAMESPACE > file? > In the namespace era Depends is never really needed. All modern packages have no technical need for Depends anymore. Loosely speaking the only purpose of Depends today is to expose other package's functions to the user without re-exporting them. > -Should the package DESCRIPTION make any accommodation for the situation > where users will probably need to directly call functions in the imported > package, even though the package itself does not? > > -What does "need to be attached" mean? Is there a distinction between a > package being attached and a namespace being attached. > No, the distinction is between loaded and attached (namespace/package is synonymous here). > -Does "successfully load" mean something different from actually using the > package? That is, can we assume that if the package loads then all the > functions to run things will actually be found? > Define "found" - they will not be attached to the search path, so they will be found if you address them fully via myPackage::myFn but not just via myFn (except for another package that imports myPackage). > -If pkg1 uses a function foo in pkg3 indirectly, by a call to a function in > pkg2 which then uses foo, how should pkg1 indicate the relationship with > foo's pkg3, or is there no need to indicate any relationship with pkg3 > because that is all looked after by pkg2? > There is no need - how would you imagine being responsible for code that you did not write? pkg2 will import function from pkg1, but you're not importing them in pkg3, you don't even care about them so you have no direct relationship with pkg1 (imagine pkg2 switched to use pkg4 instead of pkg1). IMHO it's all really simple: load = functions exported in myPkg are available to interested parties as myPkg::foo or via direct imports - essentially this means the package can now be used attach = the namespace (and thus all exported functions) is attached to the search path - the only effect is that you have now added the exported functions to the global pool of functions - sort of like dumping them in the workspace (for all practical purposes, not technically) import a function into a package = make sure that this function works in my package regardless of the search path (so I can write fn1 instead of pkg1::fn1 and still know it will come from pkg1 and not someone's workspace or other package that chose the same name) Cheers, Simon __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Depends vs Imports
On Wed, Jul 31, 2013 at 7:35 PM, Simon Urbanek wrote: > > On Jul 31, 2013, at 7:14 PM, Paul Gilbert wrote: > >> I am being asked to modernize the Depends line in the DESCRIPTION file of >> some packages. Writing R Extensions says: >> >> The general rules are >> >> Packages whose namespace only is needed to load the package using >> library(pkgname) must be listed in the ‘Imports’ field and not in >> the ‘Depends’ field. Packages listed in imports or importFrom >> directives in the NAMESPACE file should almost always be in >> ‘Imports’ and not ‘Depends’. >> >> Packages that need to be attached to successfully load the >>package using library(pkgname) must be listed in the >>‘Depends’ field, only. >> >> Could someone please explain a few points I thought I understood but >> obviously do not, or point to where these are explained: >> >> -What does it mean for the namespace only to be needed? I thought the >> namespace was needed if the package or some of its functions were mentioned >> in the NAMESPACE file, and that only the namespace was needed if only the >> generics were called, and not other functions. The above suggests that I may >> be wrong about this. If so, that is, Imports will usually suffice, then when >> would Depends ever be needed when a package is mentioned in the NAMESPACE >> file? >> > > In the namespace era Depends is never really needed. All modern packages have > no technical need for Depends anymore. Loosely speaking the only purpose of > Depends today is to expose other package's functions to the user without > re-exporting them. > Just to make sure I understand this: an example would be if A provides an S3 generic and B provides a (registered but unexported) method for that generic -- this would be a great time for B to list A as "Depends" instead of "Imports" to make sure the generic is available to the user? Thanks, Michael __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Depends vs Imports
Simon
Thanks, that helps a lot, but see below ..
On 13-07-31 08:35 PM, Simon Urbanek wrote:
On Jul 31, 2013, at 7:14 PM, Paul Gilbert wrote:
I am being asked to modernize the Depends line in the DESCRIPTION
file of some packages. Writing R Extensions says:
The general rules are
Packages whose namespace only is needed to load the package using
library(pkgname) must be listed in the ‘Imports’ field and not in
the ‘Depends’ field. Packages listed in imports or importFrom
directives in the NAMESPACE file should almost always be in
‘Imports’ and not ‘Depends’.
Packages that need to be attached to successfully load the package
using library(pkgname) must be listed in the ‘Depends’ field,
only.
Could someone please explain a few points I thought I understood
but obviously do not, or point to where these are explained:
-What does it mean for the namespace only to be needed? I thought
the namespace was needed if the package or some of its functions
were mentioned in the NAMESPACE file, and that only the namespace
was needed if only the generics were called, and not other
functions. The above suggests that I may be wrong about this. If
so, that is, Imports will usually suffice, then when would Depends
ever be needed when a package is mentioned in the NAMESPACE file?
In the namespace era Depends is never really needed. All modern
packages have no technical need for Depends anymore. Loosely speaking
the only purpose of Depends today is to expose other package's
functions to the user without re-exporting them.
This seems to mostly work, except in the situation where a package is
used that enhances an imported package. For example, I Import DBI but
the call dbDriver("MySQL") fails looking for MySQL in package RMySQL if
I only import that and do not list it in Depends. Am I missing something?
Similarly, I have a package tframePlus that provides extra methods (for
zoo and xts) for my package tframe. Since tframe does not depend or
import tframePlus (in fact, the reverse), I seem to need tframePlus in
Depends not Imports of another package that Imports tframe. Does this
sound right or am I missing something else?
Also, I have a package TSMySQL which enhances my package TSdbi. When a
user uses TSMySQL they will want to use many functions in TSdbi. Here
again, I seem to need TSMySQL to Depend on TSdbi, for the reason you
mention, exposing all the functions to the user.
(I'm glad this is simple, I have trouble when things are difficult.)
Thanks again,
Paul
-Should the package DESCRIPTION make any accommodation for the
situation where users will probably need to directly call functions
in the imported package, even though the package itself does not?
-What does "need to be attached" mean? Is there a distinction
between a package being attached and a namespace being attached.
No, the distinction is between loaded and attached (namespace/package
is synonymous here).
-Does "successfully load" mean something different from actually
using the package? That is, can we assume that if the package loads
then all the functions to run things will actually be found?
Define "found" - they will not be attached to the search path, so
they will be found if you address them fully via myPackage::myFn but
not just via myFn (except for another package that imports
myPackage).
-If pkg1 uses a function foo in pkg3 indirectly, by a call to a
function in pkg2 which then uses foo, how should pkg1 indicate the
relationship with foo's pkg3, or is there no need to indicate any
relationship with pkg3 because that is all looked after by pkg2?
There is no need - how would you imagine being responsible for code
that you did not write? pkg2 will import function from pkg1, but
you're not importing them in pkg3, you don't even care about them so
you have no direct relationship with pkg1 (imagine pkg2 switched to
use pkg4 instead of pkg1).
IMHO it's all really simple:
load = functions exported in myPkg are available to interested
parties as myPkg::foo or via direct imports - essentially this means
the package can now be used
attach = the namespace (and thus all exported functions) is attached
to the search path - the only effect is that you have now added the
exported functions to the global pool of functions - sort of like
dumping them in the workspace (for all practical purposes, not
technically)
import a function into a package = make sure that this function works
in my package regardless of the search path (so I can write fn1
instead of pkg1::fn1 and still know it will come from pkg1 and not
someone's workspace or other package that chose the same name)
Cheers, Simon
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
