[Rd] Windows installer text bug (PR#13445)
Full_Name: Rob Cranfill Version: 2.8.1 OS: Windows XP SP2 Submission from: (NULL) (130.76.32.19) Using the Windows installer for 2.8.1, partway through the process there is a dialog that looks something like this: -- Display Mode Do you prefer the MDI or SDI interface? --- Please specify MDI or SDI, then click Next. (*) MDI (one big window) ( ) SDI (separate windows) -- Those descriptions are reversed: "MDI" is Multiple Document Interface, with separate windows; SDI is Single Document Interface, with one big window. I can send a screen shot if need be. - rob __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem with compiling shared C/C++ library for loading into R (Linux)
Thanks. I figured out the problem finally. The first error I
mentioned was solved by compiling
the external library blitz++ using the configure option --with-pic (or
compiler flag -fPIC). It has something to do with position indepent
code and global variables, which I frankly don't understand. Maybe
somebody can explain...
The second one (undefined symbol: _ZSt4cerr) was because cerr is
a c++ object, and I was doing
"R CMD SHLIB" on the compiled object files, so it was linkiing using
gcc. Changing the linker to g++ (using
cpp source code during linking) works...or as suggested in a previous
post using -lstdc++ with gcc also works.
--Samsiddhi Bhattacharjee
On Sun, Jan 11, 2009 at 7:58 AM, torpedo fisken wrote:
> I think you're not linking it together when you call R CMD SHLIB, use
> something like
>
> R CMD SHLIB mylib.c yourlib1.o yourlib2.o
>
> Otherwise mail again with your Makefile, or all the commands you are using
>
> good luck
>
> 2009/1/11 Samsiddhi Bhattacharjee :
>> Dear all,
>>
>> I am using the .Call interface to call c++ code from R. For that, I am
>> trying to create a dynamic library (mylib.so)
>> using "R CMD SHLIB" by linking my own c++ code and an external c++
>> library (blitz++).
>>
>> The makefile works fine on my Mac, produces mylib.so and I am able to
>> call .Call() from R, but on a linux
>> server (I think Debian), I got the following error:
>>
>> --
>> /usr/bin/ld: /somepath/blitz/lib/libblitz.a(globals.o):
>> relocation R_X86_64_32 against `a local symbol' can not be used when
>> making a shared object; recompile with -fPIC
>> /somepath/blitz/lib/libblitz.a: could not read symbols: Bad value
>> collect2: ld returned 1 exit status
>> --
>>
>> I tried recompiling the blitz++ library with the -fPIC flag, and then
>> linking using -fPIC, it went thorugh without error
>> producing a "mylib.so" file. But when I tried "dyn.load(mylib.so)"
>> from R, I got the error:
>>
>> --
>> Error in dyn.load("mylib.so") :
>> unable to load shared library '/somepath/mylib.so':
>> /somepath/mylib.so: undefined symbol: _ZSt4cerr
>> -
>>
>> I will really appreciate any help or advice on this problem.
>>
>> --Samsiddhi Bhattacharjee
>>
>> __
>> 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] FORTRAN compilation error on Tiger but not for Leopard
Dear list member,
the package urca now contains FORTRAN code in ./src. The
compilation/build works on R-Forge (see project AICTSI with Leopard),
but an error is reported in the build on CRAN (Tiger). My question now
is: Is there anything I can do as a package maintainer such that the
package can be build under Tiger? Any hints and pointers are welcome.
The code is available here:
http://r-forge.r-project.org/plugins/scmsvn/viewcvs.php/pkg/src/?root=ur
ca
And the Mac build log file can be accessed here:
http://www.r-project.org/nosvn/R.check/r-release-macosx-ix86/urca-00chec
k.html
with further information:
http://www.r-project.org/nosvn/R.check/r-release-macosx-ix86/urca-00inst
all.html
Fyi: I have posted this email to R-SIG-Mac yesterday, but have not
received a response by now. Because the issue might also be relevant for
R-Devel I decided to post the problem here, too. In addition, the build
and check for the other architectures/version is passed.
Best,
Bernhard
*
Confidentiality Note: The information contained in this ...{{dropped:10}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] particulars of importing/loading libraries
Sorry Simon, you are right. I tried to recreate a problem that I had
with other packages where the packages were added to Depends but made a
mistake. However the problem remains if I do the following.
Added: pack1 to Depends of pack2. Now I create pack3 with the following
contents: it does not import pack1 directly, nor depends on it. It
rather imports pack2 and depends on pack2. I then expect the
functionality of pack1 to be available still if I only load pack3. But I
now get errors with pack3 calling the function from pack1. Does this
mean I need to import and depend on pack1 and methods explicitly in
pack3. I.e. do I have to import and depend on ALL the packages that may
be in use, even if they are imported by other that I depend on and
import:
pack3: DESCRIPTION -
Package: pack3
Version: 0.0.1
Date: 12 Jan 2009
Title: pack1 to test S3/S4 methods compatibility
Author: Oleg Sklyar
Depends: R (>= 2.7.1), pack2
Maintainer: Oleg Sklyar
Description: pack3
LazyLoad: yes
License: Proprietary
URL: http://www.maninvestments.com
LazyLoad: no
pack3: NAMESPACE --
import(pack2)
exportPattern("^[^\\.]")
pack3: posix.R --
testPosix2 = function() {
z = as.POSIXct(testPosixVal)
print(z)
print(class(z))
z
}
Note, that the above function is the same as in pack2, just a different
name.
*** R 2.9.0 (svn -r 46585) [/share/research/R-devel/20081002/lib64/R]
***
> library(pack3)
Loading required package: pack2
Loading required package: pack1
> as.POSIXct(pack1::testPosixVal)
[1] "2009-01-13 15:29:50 UTC"
> testPosxi() ## called from pack2
[1] "2009-01-13 15:29:50 UTC"
[1] "POSIXt" "POSIXct"
[1] "2009-01-13 15:29:50 UTC"
> testPosix2() ## called from pack3
Error in as.POSIXct.default(testPosixVal) :
do not know how to convert 'testPosixVal' to class "POSIXlt"
Dr Oleg Sklyar
Research Technologist
AHL / Man Investments Ltd
+44 (0)20 7144 3107
oskl...@maninvestments.com
> -Original Message-
> From: Simon Urbanek [mailto:simon.urba...@r-project.org]
> Sent: 14 January 2009 01:51
> To: Sklyar, Oleg (London)
> Cc: r-devel@r-project.org
> Subject: Re: [Rd] particulars of importing/loading libraries
>
> Oleg,
>
> On Jan 13, 2009, at 11:00 , Sklyar, Oleg (London) wrote:
>
> > Dear List:
> >
> > Sorry for posting maybe a trivial question, but I have a basic
> > understanding problem. If I have say pack1 and pack2, two R
> packages,
> > and pack2 depends on and imports pack1 fully (as in the
> code below),
> > is
> > there a way to make all the functionality of pack1 available for the
> > global and other environments (not only for the functions
> called from
> > withing pack2) by loading pack2 only? I thought if pack2
> depends on
> > and
> > imports pack1 and essentially reexports everything, one
> should get the
> > full functionality simply by loading pack2. This does not
> seem to be
> > the
> > case or I am missing something trivial in my NAMESPACE/DESCRIPTION
> > files?
> >
> > If this is documented in Writing R Extensions, I would be thankful
> > for a
> > page number and maybe a quick fix in my example below as so
> far I have
> > not been able to find a clear explanation.
> >
> > The problem can be illustrated by the following simple
> example (this
> > is
> > a simple code for 2 packages, pack1 and pack2; plus an example).
> >
>
> if you bothered to use R CMD check you would find your bug right away:
> * checking package dependencies ... ERROR
> Namespace dependencies not required:
>pack1
>
> You simply forgot to add pack1 to the Depends: line - that's
> all. Once
> you fix that, you'll see what happens:
>
> > library(pack2)
> Loading required package: pack1
> > as.POSIXct(pack1::testPosixVal)
> [1] "2009-01-14 01:38:08 UTC"
>
> Cheers,
> S
>
>
> > Thank you for your replies.
> >
> > Dr Oleg Sklyar
> > Research Technologist
> > AHL / Man Investments Ltd
> > +44 (0)20 7144 3107
> > oskl...@maninvestments.com
> >
> > --- pack1: DESCRIPTION --
> > Package: pack1
> > Version: 0.0.1
> > Date: 12 Jan 2009
> > Title: pack1 to test S3/S4 methods compatibility
> > Author: Oleg Sklyar
> > Depends: R (>= 2.7.1), methods
> > Maintainer: Oleg Sklyar
> > Description: pack1
> > LazyLoad: yes
> > License: Proprietary
> > URL: http://www.maninvestments.com
> > LazyLoad: no
> >
> > --- pack1: NAMESPACE --
> > import(methods)
> > exportPattern("^[^\\.]")
> > exportClasses(posixTime)
> > exportMethods(as.POSIXct)
> >
> > --- pack1: posix.R --
> > setClass("posixTime", "numeric")
> >
> > setGeneric("as.POSIXct")
> > setMethod("as.POSIXct", signature(x="posixTime"),
> >function(x, tz) {
> >z = x...@.data
> >attr(z,"class") = c("POSIXt", "POSIXct")
> >attr(z,"tzone") = "UTC"
> >z
> >}
> > )
> >
> > testPosixVal = new("posixTime", as.numeric(Sys.time()))
> >
> > --- pack2: DESCRIPTION
> > Package: pack2
> > Version: 0.0.1
> > Date: 12 Jan 2009
> > Title: pack2 to test S3/S4 methods compatibil
Re: [Rd] Windows installer text bug (PR#13445)
robert.e.cranf...@boeing.com wrote: Full_Name: Rob Cranfill Version: 2.8.1 OS: Windows XP SP2 Submission from: (NULL) (130.76.32.19) Using the Windows installer for 2.8.1, partway through the process there is a dialog that looks something like this: -- Display Mode Do you prefer the MDI or SDI interface? --- Please specify MDI or SDI, then click Next. (*) MDI (one big window) ( ) SDI (separate windows) -- Those descriptions are reversed: "MDI" is Multiple Document Interface, with separate windows; SDI is Single Document Interface, with one big window. MDI is one big parent window containing sub-windows; in SDI they are unconnected. The description is not reversed, but could perhaps be improved. Duncan Murdoch I can send a screen shot if need be. - rob __ 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] Windows installer text bug (PR#13445)
On Tue, Jan 13, 2009 at 4:30 PM, wrote: Hey, this guy builds engines for aircraft *and* uses freeware! I was on such a jet just few days ago and I can confirm that I did not notice anything strange (except the food). > Full_Name: Rob Cranfill > Version: 2.8.1 > OS: Windows XP SP2 > Submission from: (NULL) (130.76.32.19) > > > Using the Windows installer for 2.8.1, partway through the process there is a > dialog that looks something like this: > > -- > Display Mode > Do you prefer the MDI or SDI interface? > --- > Please specify MDI or SDI, then click Next. > > (*) MDI (one big window) > ( ) SDI (separate windows) > > -- > > Those descriptions are reversed: "MDI" is Multiple Document Interface, with > separate windows; SDI is Single Document Interface, with one big window. Probably not a bug, because this could be read "multiple document interface (MDI) are those whose windows reside under **a single parent window**" and "a single document interface or SDI is [...] organizing applications into **individual windows**" [Wikipedia]. I haven't verified the outcome though. /Henrik > > I can send a screen shot if need be. > > - rob > > __ > 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] particulars of importing/loading libraries
On Jan 14, 2009, at 4:24 , Sklyar, Oleg (London) wrote:
Sorry Simon, you are right. I tried to recreate a problem that I had
with other packages where the packages were added to Depends but
made a mistake. However the problem remains if I do the following.
Added: pack1 to Depends of pack2. Now I create pack3 with the
following contents: it does not import pack1 directly, nor depends
on it. It rather imports pack2 and depends on pack2. I then expect
the functionality of pack1 to be available still if I only load pack3.
That is semantically not a reasonable requirement. pack3 cannot (and
should not) assume anything about the internals of pack2. If it needs
a function from pack1, it has to import it from pack1. If pack2 re-
exported as.POSIXct then that would make it part of pack2's interface
and then you're free to just depend on pack2.
Cheers,
S
But I
now get errors with pack3 calling the function from pack1. Does this
mean I need to import and depend on pack1 and methods explicitly in
pack3. I.e. do I have to import and depend on ALL the packages that
may
be in use, even if they are imported by other that I depend on and
import:
pack3: DESCRIPTION -
Package: pack3
Version: 0.0.1
Date: 12 Jan 2009
Title: pack1 to test S3/S4 methods compatibility
Author: Oleg Sklyar
Depends: R (>= 2.7.1), pack2
Maintainer: Oleg Sklyar
Description: pack3
LazyLoad: yes
License: Proprietary
URL: http://www.maninvestments.com
LazyLoad: no
pack3: NAMESPACE --
import(pack2)
exportPattern("^[^\\.]")
pack3: posix.R --
testPosix2 = function() {
z = as.POSIXct(testPosixVal)
print(z)
print(class(z))
z
}
Note, that the above function is the same as in pack2, just a
different
name.
*** R 2.9.0 (svn -r 46585) [/share/research/R-devel/20081002/lib64/R]
***
library(pack3)
Loading required package: pack2
Loading required package: pack1
as.POSIXct(pack1::testPosixVal)
[1] "2009-01-13 15:29:50 UTC"
testPosxi() ## called from pack2
[1] "2009-01-13 15:29:50 UTC"
[1] "POSIXt" "POSIXct"
[1] "2009-01-13 15:29:50 UTC"
testPosix2() ## called from pack3
Error in as.POSIXct.default(testPosixVal) :
do not know how to convert 'testPosixVal' to class "POSIXlt"
Dr Oleg Sklyar
Research Technologist
AHL / Man Investments Ltd
+44 (0)20 7144 3107
oskl...@maninvestments.com
-Original Message-
From: Simon Urbanek [mailto:simon.urba...@r-project.org]
Sent: 14 January 2009 01:51
To: Sklyar, Oleg (London)
Cc: r-devel@r-project.org
Subject: Re: [Rd] particulars of importing/loading libraries
Oleg,
On Jan 13, 2009, at 11:00 , Sklyar, Oleg (London) wrote:
Dear List:
Sorry for posting maybe a trivial question, but I have a basic
understanding problem. If I have say pack1 and pack2, two R
packages,
and pack2 depends on and imports pack1 fully (as in the
code below),
is
there a way to make all the functionality of pack1 available for the
global and other environments (not only for the functions
called from
withing pack2) by loading pack2 only? I thought if pack2
depends on
and
imports pack1 and essentially reexports everything, one
should get the
full functionality simply by loading pack2. This does not
seem to be
the
case or I am missing something trivial in my NAMESPACE/DESCRIPTION
files?
If this is documented in Writing R Extensions, I would be thankful
for a
page number and maybe a quick fix in my example below as so
far I have
not been able to find a clear explanation.
The problem can be illustrated by the following simple
example (this
is
a simple code for 2 packages, pack1 and pack2; plus an example).
if you bothered to use R CMD check you would find your bug right
away:
* checking package dependencies ... ERROR
Namespace dependencies not required:
pack1
You simply forgot to add pack1 to the Depends: line - that's
all. Once
you fix that, you'll see what happens:
library(pack2)
Loading required package: pack1
as.POSIXct(pack1::testPosixVal)
[1] "2009-01-14 01:38:08 UTC"
Cheers,
S
Thank you for your replies.
Dr Oleg Sklyar
Research Technologist
AHL / Man Investments Ltd
+44 (0)20 7144 3107
oskl...@maninvestments.com
--- pack1: DESCRIPTION --
Package: pack1
Version: 0.0.1
Date: 12 Jan 2009
Title: pack1 to test S3/S4 methods compatibility
Author: Oleg Sklyar
Depends: R (>= 2.7.1), methods
Maintainer: Oleg Sklyar
Description: pack1
LazyLoad: yes
License: Proprietary
URL: http://www.maninvestments.com
LazyLoad: no
--- pack1: NAMESPACE --
import(methods)
exportPattern("^[^\\.]")
exportClasses(posixTime)
exportMethods(as.POSIXct)
--- pack1: posix.R --
setClass("posixTime", "numeric")
setGeneric("as.POSIXct")
setMethod("as.POSIXct", signature(x="posixTime"),
function(x, tz) {
z = x...@.data
attr(z,"class") = c("POSIXt", "POSIXct")
attr(z,"tzone") = "UTC"
z
}
)
testPosixVal = new("posixTime", as.numeric(Sys.time()))
--- pack2: DESCRIPTION
Package: pack2
Version: 0.0.1
Date: 12 J
Re: [Rd] particulars of importing/loading libraries
Well, this is very reasonable and this is how it should be I would say.
If it was consistent, there would be no problem as they would be easy to
nail down. However, the problem is now that if I load pack3 only (which
imports pack2 only) then as.POSIXct exported from pack1 is NOT available
for functions in pack3, but is available for calls from the global env
(see example below). It is obviously available for calls from functions
in pack2 as there it is imported directly. Although, why also
testPosix() of pack2 is then available for calls from the global env as
it was only loaded as import for pack3?
In my understanding if pack3 does not depend on pack1 directly,
functionality of pack1 should not be available anywhere apart from
functions called from pack2 as well as functions in pack2 should only be
available for calls by functions in pack3 but not in the global env...
The semantics seems to be broken here, is it not?
> library(pack3)
Loading required package: pack2
Loading required package: pack1
> testPosix() ## from pack2
[1] "2009-01-13 15:29:50 UTC"
[1] "POSIXt" "POSIXct"
[1] "2009-01-13 15:29:50 UTC"
> testPosix2()
Error in as.POSIXct.default(testPosixVal) :
do not know how to convert 'testPosixVal' to class "POSIXlt"
> as.POSIXct(pack1::testPosixVal)
[1] "2009-01-13 15:29:50 UTC"
Dr Oleg Sklyar
Research Technologist
AHL / Man Investments Ltd
+44 (0)20 7144 3107
oskl...@maninvestments.com
> -Original Message-
> From: Simon Urbanek [mailto:simon.urba...@r-project.org]
> Sent: 14 January 2009 15:38
> To: Sklyar, Oleg (London)
> Cc: r-devel@r-project.org
> Subject: Re: [Rd] particulars of importing/loading libraries
>
>
> On Jan 14, 2009, at 4:24 , Sklyar, Oleg (London) wrote:
>
> > Sorry Simon, you are right. I tried to recreate a problem
> that I had
> > with other packages where the packages were added to Depends but
> > made a mistake. However the problem remains if I do the following.
> >
> > Added: pack1 to Depends of pack2. Now I create pack3 with the
> > following contents: it does not import pack1 directly, nor depends
> > on it. It rather imports pack2 and depends on pack2. I then expect
> > the functionality of pack1 to be available still if I only
> load pack3.
>
>
> That is semantically not a reasonable requirement. pack3 cannot (and
> should not) assume anything about the internals of pack2. If
> it needs
> a function from pack1, it has to import it from pack1. If pack2 re-
> exported as.POSIXct then that would make it part of pack2's
> interface
> and then you're free to just depend on pack2.
>
> Cheers,
> S
>
>
>
> > But I
> > now get errors with pack3 calling the function from pack1. Does this
> > mean I need to import and depend on pack1 and methods explicitly in
> > pack3. I.e. do I have to import and depend on ALL the
> packages that
> > may
> > be in use, even if they are imported by other that I depend on and
> > import:
> >
> > pack3: DESCRIPTION -
> >
> > Package: pack3
> > Version: 0.0.1
> > Date: 12 Jan 2009
> > Title: pack1 to test S3/S4 methods compatibility
> > Author: Oleg Sklyar
> > Depends: R (>= 2.7.1), pack2
> > Maintainer: Oleg Sklyar
> > Description: pack3
> > LazyLoad: yes
> > License: Proprietary
> > URL: http://www.maninvestments.com
> > LazyLoad: no
> >
> > pack3: NAMESPACE --
> > import(pack2)
> > exportPattern("^[^\\.]")
> >
> > pack3: posix.R --
> > testPosix2 = function() {
> >z = as.POSIXct(testPosixVal)
> >print(z)
> >print(class(z))
> >z
> > }
> >
> > Note, that the above function is the same as in pack2, just a
> > different
> > name.
> >
> >
> > *** R 2.9.0 (svn -r 46585)
> [/share/research/R-devel/20081002/lib64/R]
> > ***
> >> library(pack3)
> > Loading required package: pack2
> > Loading required package: pack1
> >> as.POSIXct(pack1::testPosixVal)
> > [1] "2009-01-13 15:29:50 UTC"
> >> testPosxi() ## called from pack2
> > [1] "2009-01-13 15:29:50 UTC"
> > [1] "POSIXt" "POSIXct"
> > [1] "2009-01-13 15:29:50 UTC"
> >> testPosix2() ## called from pack3
> > Error in as.POSIXct.default(testPosixVal) :
> > do not know how to convert 'testPosixVal' to class "POSIXlt"
> >
> >
> >
> >
> > Dr Oleg Sklyar
> > Research Technologist
> > AHL / Man Investments Ltd
> > +44 (0)20 7144 3107
> > oskl...@maninvestments.com
> >
> >> -Original Message-
> >> From: Simon Urbanek [mailto:simon.urba...@r-project.org]
> >> Sent: 14 January 2009 01:51
> >> To: Sklyar, Oleg (London)
> >> Cc: r-devel@r-project.org
> >> Subject: Re: [Rd] particulars of importing/loading libraries
> >>
> >> Oleg,
> >>
> >> On Jan 13, 2009, at 11:00 , Sklyar, Oleg (London) wrote:
> >>
> >>> Dear List:
> >>>
> >>> Sorry for posting maybe a trivial question, but I have a basic
> >>> understanding problem. If I have say pack1 and pack2, two R
> >> packages,
> >>> and pack2 depends on and imports pack1 fully (as in the
> >> code below),
> >>> is
> >>> there a way to make all the functionality of
Re: [Rd] FORTRAN compilation error on Tiger but not for Leopard
Just to let the list know; the issue has been resolved by Simon Urbanek,
again many thanks Simon. His reply is available at:
https://stat.ethz.ch/pipermail/r-sig-mac/2009-January/005759.html
Best,
Bernhard
>
>Dear list member,
>
>the package urca now contains FORTRAN code in ./src. The
>compilation/build works on R-Forge (see project AICTSI with Leopard),
>but an error is reported in the build on CRAN (Tiger). My question now
>is: Is there anything I can do as a package maintainer such that the
>package can be build under Tiger? Any hints and pointers are welcome.
>
>The code is available here:
>http://r-forge.r-project.org/plugins/scmsvn/viewcvs.php/pkg/src
/?root=ur
>ca
>
>And the Mac build log file can be accessed here:
>http://www.r-project.org/nosvn/R.check/r-release-macosx-ix86/ur
ca-00chec
>k.html
>with further information:
>http://www.r-project.org/nosvn/R.check/r-release-macosx-ix86/ur
ca-00inst
>all.html
>
>Fyi: I have posted this email to R-SIG-Mac yesterday, but have not
>received a response by now. Because the issue might also be
>relevant for
>R-Devel I decided to post the problem here, too. In addition, the build
>and check for the other architectures/version is passed.
>
>
>Best,
>Bernhard
>
>*
>Confidentiality Note: The information contained in this
>...{{dropped:10}}
>
>__
>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] particulars of importing/loading libraries
On Jan 14, 2009, at 10:52 , Sklyar, Oleg (London) wrote:
Well, this is very reasonable and this is how it should be I would
say. If it was consistent, there would be no problem as they would
be easy to nail down. However, the problem is now that if I load
pack3 only (which imports pack2 only) then as.POSIXct exported from
pack1 is NOT available for functions in pack3,
Because pack3 didn't request it.
but is available for calls from the global env (see example below).
It is obviously available for calls from functions in pack2 as there
it is imported directly. Although, why also testPosix() of pack2 is
then available for calls from the global env as it was only loaded
as import for pack3?
Global environment is not encapsulated - you have access to anything
that has been attached - sort of implicitly importing anything that
has even been [exported and] attached (there is really no concept of
"importing" for the global environment, but the effect is analogous).
This is a conceptual difference of the "interactive" use vs package
code. Unlike package code you don't know in advance what you will be
doing when you're working interactively, so I think it makes sense to
assume that everything is implicitly imported.
Cheers,
S
In my understanding if pack3 does not depend on pack1 directly,
functionality of pack1 should not be available anywhere apart from
functions called from pack2 as well as functions in pack2 should
only be
available for calls by functions in pack3 but not in the global env...
The semantics seems to be broken here, is it not?
library(pack3)
Loading required package: pack2
Loading required package: pack1
testPosix() ## from pack2
[1] "2009-01-13 15:29:50 UTC"
[1] "POSIXt" "POSIXct"
[1] "2009-01-13 15:29:50 UTC"
testPosix2()
Error in as.POSIXct.default(testPosixVal) :
do not know how to convert 'testPosixVal' to class "POSIXlt"
as.POSIXct(pack1::testPosixVal)
[1] "2009-01-13 15:29:50 UTC"
Dr Oleg Sklyar
Research Technologist
AHL / Man Investments Ltd
+44 (0)20 7144 3107
oskl...@maninvestments.com
-Original Message-
From: Simon Urbanek [mailto:simon.urba...@r-project.org]
Sent: 14 January 2009 15:38
To: Sklyar, Oleg (London)
Cc: r-devel@r-project.org
Subject: Re: [Rd] particulars of importing/loading libraries
On Jan 14, 2009, at 4:24 , Sklyar, Oleg (London) wrote:
Sorry Simon, you are right. I tried to recreate a problem
that I had
with other packages where the packages were added to Depends but
made a mistake. However the problem remains if I do the following.
Added: pack1 to Depends of pack2. Now I create pack3 with the
following contents: it does not import pack1 directly, nor depends
on it. It rather imports pack2 and depends on pack2. I then expect
the functionality of pack1 to be available still if I only
load pack3.
That is semantically not a reasonable requirement. pack3 cannot (and
should not) assume anything about the internals of pack2. If
it needs
a function from pack1, it has to import it from pack1. If pack2 re-
exported as.POSIXct then that would make it part of pack2's
interface
and then you're free to just depend on pack2.
Cheers,
S
But I
now get errors with pack3 calling the function from pack1. Does this
mean I need to import and depend on pack1 and methods explicitly in
pack3. I.e. do I have to import and depend on ALL the
packages that
may
be in use, even if they are imported by other that I depend on and
import:
pack3: DESCRIPTION -
Package: pack3
Version: 0.0.1
Date: 12 Jan 2009
Title: pack1 to test S3/S4 methods compatibility
Author: Oleg Sklyar
Depends: R (>= 2.7.1), pack2
Maintainer: Oleg Sklyar
Description: pack3
LazyLoad: yes
License: Proprietary
URL: http://www.maninvestments.com
LazyLoad: no
pack3: NAMESPACE --
import(pack2)
exportPattern("^[^\\.]")
pack3: posix.R --
testPosix2 = function() {
z = as.POSIXct(testPosixVal)
print(z)
print(class(z))
z
}
Note, that the above function is the same as in pack2, just a
different
name.
*** R 2.9.0 (svn -r 46585)
[/share/research/R-devel/20081002/lib64/R]
***
library(pack3)
Loading required package: pack2
Loading required package: pack1
as.POSIXct(pack1::testPosixVal)
[1] "2009-01-13 15:29:50 UTC"
testPosxi() ## called from pack2
[1] "2009-01-13 15:29:50 UTC"
[1] "POSIXt" "POSIXct"
[1] "2009-01-13 15:29:50 UTC"
testPosix2() ## called from pack3
Error in as.POSIXct.default(testPosixVal) :
do not know how to convert 'testPosixVal' to class "POSIXlt"
Dr Oleg Sklyar
Research Technologist
AHL / Man Investments Ltd
+44 (0)20 7144 3107
oskl...@maninvestments.com
-Original Message-
From: Simon Urbanek [mailto:simon.urba...@r-project.org]
Sent: 14 January 2009 01:51
To: Sklyar, Oleg (London)
Cc: r-devel@r-project.org
Subject: Re: [Rd] particulars of importing/loading libraries
Oleg,
On Jan 13, 2009, at 11:00 , Sklyar, Oleg (London) wrote:
Dear List:
Sorry for posting maybe a tr
Re: [Rd] particulars of importing/loading libraries
Thank you Simon.
Dr Oleg Sklyar
Research Technologist
AHL / Man Investments Ltd
+44 (0)20 7144 3107
oskl...@maninvestments.com
> -Original Message-
> From: Simon Urbanek [mailto:simon.urba...@r-project.org]
> Sent: 14 January 2009 16:11
> To: Sklyar, Oleg (London)
> Cc: r-devel@r-project.org
> Subject: Re: [Rd] particulars of importing/loading libraries
>
>
> On Jan 14, 2009, at 10:52 , Sklyar, Oleg (London) wrote:
>
> > Well, this is very reasonable and this is how it should be I would
> > say. If it was consistent, there would be no problem as they would
> > be easy to nail down. However, the problem is now that if I load
> > pack3 only (which imports pack2 only) then as.POSIXct
> exported from
> > pack1 is NOT available for functions in pack3,
>
> Because pack3 didn't request it.
>
>
> > but is available for calls from the global env (see example
> below).
> > It is obviously available for calls from functions in pack2
> as there
> > it is imported directly. Although, why also testPosix() of
> pack2 is
> > then available for calls from the global env as it was only loaded
> > as import for pack3?
> >
>
> Global environment is not encapsulated - you have access to anything
> that has been attached - sort of implicitly importing anything that
> has even been [exported and] attached (there is really no concept of
> "importing" for the global environment, but the effect is
> analogous).
> This is a conceptual difference of the "interactive" use vs package
> code. Unlike package code you don't know in advance what you will be
> doing when you're working interactively, so I think it makes
> sense to
> assume that everything is implicitly imported.
>
> Cheers,
> S
>
>
> > In my understanding if pack3 does not depend on pack1 directly,
> > functionality of pack1 should not be available anywhere apart from
> > functions called from pack2 as well as functions in pack2 should
> > only be
> > available for calls by functions in pack3 but not in the
> global env...
> > The semantics seems to be broken here, is it not?
> >
> >> library(pack3)
> > Loading required package: pack2
> > Loading required package: pack1
> >> testPosix() ## from pack2
> > [1] "2009-01-13 15:29:50 UTC"
> > [1] "POSIXt" "POSIXct"
> > [1] "2009-01-13 15:29:50 UTC"
> >> testPosix2()
> > Error in as.POSIXct.default(testPosixVal) :
> > do not know how to convert 'testPosixVal' to class "POSIXlt"
> >> as.POSIXct(pack1::testPosixVal)
> > [1] "2009-01-13 15:29:50 UTC"
> >
> >
> >
> > Dr Oleg Sklyar
> > Research Technologist
> > AHL / Man Investments Ltd
> > +44 (0)20 7144 3107
> > oskl...@maninvestments.com
> >
> >> -Original Message-
> >> From: Simon Urbanek [mailto:simon.urba...@r-project.org]
> >> Sent: 14 January 2009 15:38
> >> To: Sklyar, Oleg (London)
> >> Cc: r-devel@r-project.org
> >> Subject: Re: [Rd] particulars of importing/loading libraries
> >>
> >>
> >> On Jan 14, 2009, at 4:24 , Sklyar, Oleg (London) wrote:
> >>
> >>> Sorry Simon, you are right. I tried to recreate a problem
> >> that I had
> >>> with other packages where the packages were added to Depends but
> >>> made a mistake. However the problem remains if I do the following.
> >>>
> >>> Added: pack1 to Depends of pack2. Now I create pack3 with the
> >>> following contents: it does not import pack1 directly, nor depends
> >>> on it. It rather imports pack2 and depends on pack2. I then expect
> >>> the functionality of pack1 to be available still if I only
> >> load pack3.
> >>
> >>
> >> That is semantically not a reasonable requirement. pack3
> cannot (and
> >> should not) assume anything about the internals of pack2. If
> >> it needs
> >> a function from pack1, it has to import it from pack1. If pack2 re-
> >> exported as.POSIXct then that would make it part of pack2's
> >> interface
> >> and then you're free to just depend on pack2.
> >>
> >> Cheers,
> >> S
> >>
> >>
> >>
> >>> But I
> >>> now get errors with pack3 calling the function from
> pack1. Does this
> >>> mean I need to import and depend on pack1 and methods
> explicitly in
> >>> pack3. I.e. do I have to import and depend on ALL the
> >> packages that
> >>> may
> >>> be in use, even if they are imported by other that I depend on and
> >>> import:
> >>>
> >>> pack3: DESCRIPTION -
> >>>
> >>> Package: pack3
> >>> Version: 0.0.1
> >>> Date: 12 Jan 2009
> >>> Title: pack1 to test S3/S4 methods compatibility
> >>> Author: Oleg Sklyar
> >>> Depends: R (>= 2.7.1), pack2
> >>> Maintainer: Oleg Sklyar
> >>> Description: pack3
> >>> LazyLoad: yes
> >>> License: Proprietary
> >>> URL: http://www.maninvestments.com
> >>> LazyLoad: no
> >>>
> >>> pack3: NAMESPACE --
> >>> import(pack2)
> >>> exportPattern("^[^\\.]")
> >>>
> >>> pack3: posix.R --
> >>> testPosix2 = function() {
> >>> z = as.POSIXct(testPosixVal)
> >>> print(z)
> >>> print(class(z))
> >>> z
> >>> }
> >>>
> >>> Note, that the above function is the same as i
[Rd] Documentation suggestions for vignettes
Dear R-devel,
I am putting together a package vignette for the first time (R 2.8.1,
OS X) and had some bumps from section 1.4 ("Writing package
vignettes") of the "Writing R Extensions" document. Here are
suggestions to clean up a few small documentation bugs (I think) and
omissions. This is assuming that R is performing as intended and the
only gaps are in the documentation, not vice-versa.
The statement "Pointers from package help indices to the installed
documents are automatically created" made me think I could put a pdf
in inst/doc and it would automatically be treated as a vignette. When
I did R CMD BUILD and R CMD INSTALL, an index.html was created in
inst/doc (and my pdf was copied there) but it stated there are no
vignettes for this package, and R indeed could not find the vignette.
How about stating that index.html is needed and sticking in an example?
I eventually figured it out by looking at the grid package source.
But before I did that I tried putting my Rnw file in inst/doc to see
if I could get it recognized if R CMD BUILD was generating the pdf
itself. For this method, section 1.4 states the index information is
generated "from the \VignetteIndexEntry statements" but gives no
example of the syntax for this (it takes one argument in curly braces
giving a description of the vignette) or the associated commands
(e.g. \VignettePackage{} and \VignetteDepends{}, as I find from the
grid source, and perhaps others?). This made the documentation read
as if it would only make sense to someone who is already a seasoned
package developer. How about giving an example? After again emulating
the grid package source, the build and install worked beautifully and
index.html was generated correctly.
Clearly my bumps were due to climbing the learning curve, but some
cursory Googling and R help searching for further information to see
if I had missed something obvious did not yield much.
In summary, stating that an index.html is necessary if a vignette is
provided as a pdf, giving an example of its format, and giving an
example of %\VignetteIndexEntry{description} etc. might be helpful.
If these points are not mistaken and the appropriate person wants to
contact me directly I would be happy to redraft this brief section.
Thanks.
Perry de Valpine
University of California, Berkeley
Department of Environmental Science, Policy and Management
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
