Re: [Rd] LAPACK and BLAS libraries
Please don't post to multiple lists. It seems you are using Windows, but have not told us so: this is one of many things in the posting guide you have not followed (and that is why you did not get at least one answer on R-help). There are many packages on CRAN that use LAPACK and work under Windows. You should test your setup on one of those. (DPackage is one of the first in C collation.) On Tue, 29 May 2007, Tommy Ouellet wrote: > Hi, > > I don't know if I'm sending this to the right place but I've looked throught > tens and tens of topics on http://tolstoy.newcastle.edu.au/ and finally > found that email address where I can maybe find some help. > > Well my main goal is to get to use the lapack library within my R package > (which can be done using calls from C). But in order to do this I have to > create a file src/Makevars with the following line : PKG_LIBS=$(LAPACK_LIBS) > $(BLAS_LIBS) $(FLIBS) > > However when I create this file, my package won't build anymore. Actually > the checking results in the following : The actual line that failed having been omitted! > mingw32\bin\ld.exe: cannot find -lg2c > collect2: ld returned 1 exit status > make[3]: *** [PACKAGE.dll] Error 1 > make[2]: *** [srcDynlib] Error 2 > make[1]: *** [all] Error 2 > make: *** [pkg-PACKAGE] Error 2 > *** Installation of PACKAGE failed *** > > I've installed all the following tools : > mingw-runtime-3.12.tar.gz > w32api-3.9.tar.gz > binutils-2.17.50-20060824-1.tar.gz > gcc-core-3.4.5-20060117-1.tar.gz > gcc-g++-3.4.5-20060117-1.tar.gz > gcc-g77-3.4.5-20060117-1.tar.gz > So I don't know what to do next for the package to build... Any help would > be greatly appreciated. > > I am using R v. 2.5.0 > > Thanks! > > [[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] S4 assignment \alias and \usage
What is the Rd file alias and usage syntax for an S4 assignment method?
I have been trying variations on
\alias{TSdoc<-,default-method}
\usage{
\S4method{TSdoc}{default}(x) <- value
but so far I have not got it right according to various codoc, etc, checks.
Paul Gilbert
La version française suit le texte anglais.
This email may contain privileged and/or confidential inform...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R 2.5.0 MAC OS X version
Please accept my apologies if this was addressed before, I could not find any solution so I am posting my question here. I am having a lot of difficulties with installing and developing R packages with the latest version of R 2.5.0. I am using a MacBook Pro. I never had these problems with the previous versions of R. I think part of the problem is caused by the GNU Fortran 4.2.0 or my lack of knowledge... If anybody else had similar problems and found the solution, please let me know. Best. -- Recai Yucel, Ph.D. Assistant Professor of Biostatistics Biostatistics and Epidemiology UMASS-Amherst __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] S4 assignment \alias and \usage
Paul Gilbert <[EMAIL PROTECTED]> writes:
> What is the Rd file alias and usage syntax for an S4 assignment method?
>I have been trying variations on
>
> \alias{TSdoc<-,default-method}
>
> \usage{
> \S4method{TSdoc}{default}(x) <- value
>
> but so far I have not got it right according to various codoc, etc,
> checks.
If you have your own generic TSdoc<-, then I think you want:
\alias{TSdoc<-}
\alias{TSdoc<-,someClass,anotherClass-method}
You may not be allowed to specify usage, but I think the issue only
arises when setting methods for a generic documented elsewhere.
+ seth
--
Seth Falcon | Computational Biology | Fred Hutchinson Cancer Research Center
http://bioconductor.org
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 2.5.0 MAC OS X version
Hi Recal: To save you from some possible flames, it would probably help if you describe what the problems are, with specific examples and some of the relevant error messages. It would be difficult to for someone to know if they are seeing similar problems without knowing what the problems are. I believe such information is in the posting guides, which do contain good information on how to frame a question to the mail list that will elicit useful responses. -Roy On May 30, 2007, at 7:08 AM, Recai Yucel wrote: > Please accept my apologies if this was addressed before, I could not > find any solution so I am posting my question here. > > I am having a lot of difficulties with installing and developing R > packages with the latest version of R 2.5.0. I am using a MacBook > Pro. I > never had these problems with the previous versions of R. I think part > of the problem is caused by the GNU Fortran 4.2.0 or my lack of > knowledge... > > If anybody else had similar problems and found the solution, please > let > me know. > > Best. > > -- > Recai Yucel, Ph.D. > Assistant Professor of Biostatistics > Biostatistics and Epidemiology > UMASS-Amherst > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel ** "The contents of this message do not reflect any position of the U.S. Government or NOAA." ** Roy Mendelssohn Supervisory Operations Research Analyst NOAA/NMFS Environmental Research Division Southwest Fisheries Science Center 1352 Lighthouse Avenue Pacific Grove, CA 93950-2097 e-mail: [EMAIL PROTECTED] (Note new e-mail address) voice: (831)-648-9029 fax: (831)-648-8440 www: http://www.pfeg.noaa.gov/ "Old age and treachery will overcome youth and skill." __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] S4 assignment \alias and \usage
> "PaulG" == Paul Gilbert <[EMAIL PROTECTED]>
> on Wed, 30 May 2007 09:27:14 -0400 writes:
PaulG> What is the Rd file alias and usage syntax for an S4 assignment
method?
PaulG> I have been trying variations on
PaulG> \alias{TSdoc<-,default-method}
Do you really have a class called "default"
Using ".default" is an S3 concept which in S4 is replaced
by defining methods for "ANY".
In Matrix, we have
\alias{dim<-,Matrix-method}
and that works fine
-- though we don't have a \usage{.} there, since this really is in
Matrix-class.Rd
Martin Maechler
PaulG> \usage{
PaulG> \S4method{TSdoc}{default}(x) <- value
PaulG> but so far I have not got it right according to various codoc, etc,
checks.
PaulG> Paul Gilbert
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 2.5.0 MAC OS X version
And beyond that good advice, the mailing list for MacOS issues is R-sig-mac. Are you really using 'GNU Fortran 4.2.0' (which was released well after R 2.5.0), or some pre-release of it? Such details do matter. On Wed, 30 May 2007, Roy Mendelssohn wrote: > Hi Recal: > > To save you from some possible flames, it would probably help if you > describe what the problems are, with specific examples and some of > the relevant error messages. It would be difficult to for someone to > know if they are seeing similar problems without knowing what the > problems are. > > I believe such information is in the posting guides, which do contain > good information on how to frame a question to the mail list that > will elicit useful responses. > > -Roy > > > > > On May 30, 2007, at 7:08 AM, Recai Yucel wrote: > >> Please accept my apologies if this was addressed before, I could not >> find any solution so I am posting my question here. >> >> I am having a lot of difficulties with installing and developing R >> packages with the latest version of R 2.5.0. I am using a MacBook >> Pro. I >> never had these problems with the previous versions of R. I think part >> of the problem is caused by the GNU Fortran 4.2.0 or my lack of >> knowledge... >> >> If anybody else had similar problems and found the solution, please >> let >> me know. >> >> Best. >> >> -- >> Recai Yucel, Ph.D. >> Assistant Professor of Biostatistics >> Biostatistics and Epidemiology >> UMASS-Amherst -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 2.5.0 MAC OS X version
Right. I thought the problems might be obvious enough for MAC users, probably not! I was mistaken with the GNU Fortran version, it is 4.0 as seen below. A specific example where I had problems is given below: When I try to install a package called lmm (which was installed with no problem with the previous versions of R), I get the following messages, specifically on the make, chmod, etc. * trying URL 'http://cran.us.r-project.org/src/contrib/lmm_0.3-4.tar.gz' Content type 'application/x-tar' length 31471 bytes opened URL == downloaded 30Kb WARNING: ignoring environment value of R_HOME tar: Read 4096 bytes from - * Installing *source* package 'lmm' ... ** libs ** arch - i386 gfortran-4.0 -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -fPIC -g -O2 -march=nocona -c lmm.f -o lmm.o gcc-4.0 -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -dynamiclib -Wl,-macosx_version_min -Wl,10.3 -undefined dynamic_lookup -single_module -multiply_defined suppress -L/usr/local/lib -o lmm.so lmm.o -L/usr/local/lib/gcc/i686-apple-darwin8/4.2.0 -lgfortran -lgcc_s.10.4 -F/Library/Frameworks/R.framework/.. -framework R /usr/bin/libtool: for architecture cputype (16777223) cpusubtype (3) object: /usr/local/lib/libgfortran.dylib malformed object (unknown load command 4) /usr/bin/libtool: for architecture cputype (16777223) cpusubtype (3) object: /usr/local/lib/libgcc_s.10.4.dylib malformed object (unknown load command 4) ** arch - ppc gfortran-4.0 -arch ppc -isysroot /Developer/SDKs/MacOSX10.4u.sdk -fPIC -g -O2 -c lmm.f -o lmm.o make: *** [lmm.so] Error 1 chmod: /Library/Frameworks/R.framework/Versions/2.5/Resources/library/lmm/libs/i386/*: No such file or directory gcc-4.0 -arch ppc -isysroot /Developer/SDKs/MacOSX10.4u.sdk -std=gnu99 -dynamiclib -Wl,-macosx_version_min -Wl,10.3 -undefined dynamic_lookup -single_module -multiply_defined suppress -L/usr/local/lib -o lmm.so lmm.o -L/usr/local/lib/gcc/powerpc-apple-darwin8/4.2.0 -lgfortran -lgcc_s.10.4 -lSystemStubs -F/Library/Frameworks/R.framework/.. -framework R The downloaded packages are in /private/tmp/Rtmpe4c9Of/downloaded_packages ** Removing '/Library/Frameworks/R.framework/Versions/2.5/Resources/library/lmm' ** Restoring previous '/Library/Frameworks/R.framework/Versions/2.5/Resources/library/lmm' /usr/bin/libtool: for architecture cputype (16777223) cpusubtype (3) object: /usr/local/lib/libgfortran.dylib malformed object (unknown load command 4) /usr/bin/libtool: for architecture cputype (16777223) cpusubtype (3) object: /usr/local/lib/libgcc_s.10.4.dylib malformed object (unknown load command 4) make: *** [lmm.so] Error 1 chmod: /Library/Frameworks/R.framework/Versions/2.5/Resources/library/lmm/libs/ppc/*: No such file or directory ERROR: compilation failed for package 'lmm' * Prof Brian Ripley wrote: > And beyond that good advice, the mailing list for MacOS issues is > R-sig-mac. > > Are you really using 'GNU Fortran 4.2.0' (which was released well > after R 2.5.0), or some pre-release of it? Such details do matter. > > > On Wed, 30 May 2007, Roy Mendelssohn wrote: > >> Hi Recal: >> >> To save you from some possible flames, it would probably help if you >> describe what the problems are, with specific examples and some of >> the relevant error messages. It would be difficult to for someone to >> know if they are seeing similar problems without knowing what the >> problems are. >> >> I believe such information is in the posting guides, which do contain >> good information on how to frame a question to the mail list that >> will elicit useful responses. >> >> -Roy >> >> >> >> >> On May 30, 2007, at 7:08 AM, Recai Yucel wrote: >> >>> Please accept my apologies if this was addressed before, I could not >>> find any solution so I am posting my question here. >>> >>> I am having a lot of difficulties with installing and developing R >>> packages with the latest version of R 2.5.0. I am using a MacBook >>> Pro. I >>> never had these problems with the previous versions of R. I think part >>> of the problem is caused by the GNU Fortran 4.2.0 or my lack of >>> knowledge... >>> >>> If anybody else had similar problems and found the solution, please >>> let >>> me know. >>> >>> Best. >>> >>> -- >>> Recai Yucel, Ph.D. >>> Assistant Professor of Biostatistics >>> Biostatistics and Epidemiology >>> UMASS-Amherst > -- Recai Yucel, Ph.D. Assistant Professor of Biostatistics Biostatistics and Epidemiology UMASS-Amherst __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] S4 assignment \alias and \usage
Let me back up a bit, I may be making another mistake. My code has
setGeneric("TSdoc<-",
def= function(x, value) standardGeneric("TSdoc<-"),
useAsDefault= function (x, value) {attr(x, "TSdoc") <- value ; x })
setGeneric("TSdoc",
def= function(x) standardGeneric("TSdoc"),
useAsDefault= function(x) attr(x, "TSdoc"))
In the Rd file I can document the generics with
\alias{TSdoc}
\alias{TSdoc<-}
and usage
TSdoc(x)
TSdoc(x) <- value
and these seems to work for the extraction method:
\alias{TSdoc,default-method}
and usage
\S4method{TSdoc}{default}(x)
but perhaps it is not correct. My attempts to find an equivalent for
the assignment method have not been successful. Perhaps the first
questions are whether this is the correct way to document the generic,
and whether the extraction method documentation is only working by
accident. The error that is being flagged by chechDocFiles is that there
is \usage without a corresponding \alias.
Paul
Seth Falcon wrote:
> If you have your own generic TSdoc<-, then I think you want:
>
> \alias{TSdoc<-}
> \alias{TSdoc<-,someClass,anotherClass-method}
>
> You may not be allowed to specify usage, but I think the issue only
> arises when setting methods for a generic documented elsewhere.
>
> + seth
>
Martin Maechler wrote:
>> "PaulG" == Paul Gilbert <[EMAIL PROTECTED]>
>> on Wed, 30 May 2007 09:27:14 -0400 writes:
>
> PaulG> What is the Rd file alias and usage syntax for an S4 assignment
> method?
> PaulG> I have been trying variations on
>
>
> PaulG> \alias{TSdoc<-,default-method}
>
> Do you really have a class called "default"
>
> Using ".default" is an S3 concept which in S4 is replaced
> by defining methods for "ANY".
>
>
> In Matrix, we have
>
> \alias{dim<-,Matrix-method}
>
> and that works fine
> -- though we don't have a \usage{.} there, since this really is in
> Matrix-class.Rd
>
> Martin Maechler
>
> PaulG> \usage{
> PaulG> \S4method{TSdoc}{default}(x) <- value
>
> PaulG> but so far I have not got it right according to various codoc,
> etc, checks.
>
> PaulG> Paul Gilbert
La version française suit le texte anglais.
This email may contain privileged and/or confidential inform...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] S4 assignment \alias and \usage
Paul Gilbert <[EMAIL PROTECTED]> writes:
> Let me back up a bit, I may be making another mistake. My code has
>
> setGeneric("TSdoc<-",
>def= function(x, value) standardGeneric("TSdoc<-"),
>useAsDefault= function (x, value) {attr(x, "TSdoc") <- value ; x })
>
> setGeneric("TSdoc",
>def= function(x) standardGeneric("TSdoc"),
>useAsDefault= function(x) attr(x, "TSdoc"))
Aside:
It seems odd to me to define such defaults. How do you know x is
going to have a TSdoc attribute?
--
Seth Falcon | Computational Biology | Fred Hutchinson Cancer Research Center
http://bioconductor.org
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Possible changes to connections
When I originally implemented connections in R 1.2.0, I followed the model
in the 'Green Book' closely. There were a number of features that forced
a particular implementation, and one was getConnection() that allows one
to recreate a connection object from a number.
I am wondering if anyone makes use of this, and if so for what?
It would seem closer to the R philosophy to have connection objects that
get garbage collected when no R object refers to them. This would allow
for example
readLines(gzfile("foo.gz"))
which currently leaks a connection slot as the connection cannot be closed
(except via closeAllConnections() or getConnection()) without an R object
being returned.
The correct usage currently is
readLines(con <- gzfile("foo.gz")); close(con)
which is a little awkward but more importantly seems little understood.
Another issue is that the current connection objects can be saved and
restored but refer to a global table that is session-specific so they lose
their meaning (and perhaps gain an unintended one).
What I suspect is that very few users are aware of the Green Book
description and so we have freedom to make some substantial changes
to the implementation. Both issues suggest that connection objects should
be based on external pointers (which did not exist way back in 1.2.0).
[I know there is a call to getConnection in package gtools, but the return
value is unused!]
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] S4 assignment \alias and \usage
On Wed, 30 May 2007, Seth Falcon wrote:
> Paul Gilbert <[EMAIL PROTECTED]> writes:
>
>> Let me back up a bit, I may be making another mistake. My code has
>>
>> setGeneric("TSdoc<-",
>>def= function(x, value) standardGeneric("TSdoc<-"),
>>useAsDefault= function (x, value) {attr(x, "TSdoc") <- value ; x })
>>
>> setGeneric("TSdoc",
>>def= function(x) standardGeneric("TSdoc"),
>>useAsDefault= function(x) attr(x, "TSdoc"))
>
> Aside:
>
> It seems odd to me to define such defaults. How do you know x is
> going to have a TSdoc attribute?
I don't think you do, but then you extract NULL if it does not do so.
This is just what names(), comment() ... would do if they were not
internal functions and you converted them to S4 generics, so this seems
fairly natural to me (at least if there are legacy objects about that
need to be handled).
The issue of attributes on S4 objects is one that I consider still open: R
and S4 differ in implementation but the issue seems undocumented in R.
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] S4 assignment \alias and \usage
Seth Falcon wrote:
> Paul Gilbert <[EMAIL PROTECTED]> writes:
>
>> Let me back up a bit, I may be making another mistake. My code has
>>
>> setGeneric("TSdoc<-",
>>def= function(x, value) standardGeneric("TSdoc<-"),
>>useAsDefault= function (x, value) {attr(x, "TSdoc") <- value ; x })
>>
>> setGeneric("TSdoc",
>>def= function(x) standardGeneric("TSdoc"),
>>useAsDefault= function(x) attr(x, "TSdoc"))
>
> Aside:
>
> It seems odd to me to define such defaults. How do you know x is
> going to have a TSdoc attribute?
attr returns NULL if the attibute does not exist so, in my S3 way of
thinking, it seems very natural. Now knowing only a very little about S4
classes, I can see you might think it is odd.
Paul
La version française suit le texte anglais.
This email may contain privileged and/or confidential inform...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Sort in ecdf
Hi!
I've noticed the ecdf() R code (R ver. 2.5.0) contains two call to sort:
--- [R-code] ---
ecdf <- function(x)
x <- sort(x)
n <- length(x)
if (n < 1)
stop("'x' must have 1 or more non-missing values")
vals <- sort(unique(x))
rval <- approxfun(vals, cumsum(tabulate(match(x, vals)))/n,
method = "constant", yleft = 0, yright = 1, f = 0, ties = "ordered")
class(rval) <- c("ecdf", "stepfun", class(rval))
attr(rval, "call") <- sys.call()
rval
--- [/R-code] ---
I think one of the two calls to sort can be removed, improving the performance.
What do you think?
Sincerely,
-- Marco
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Sort in ecdf
> "Shiazy" == Shiazy Fuzzy <[EMAIL PROTECTED]>
> on Wed, 30 May 2007 20:07:24 +0200 writes:
Shiazy> Hi!
Shiazy> I've noticed the ecdf() R code (R ver. 2.5.0) contains two call to
sort:
Shiazy> --- [R-code] ---
Shiazy> ecdf <- function(x)
Shiazy> x <- sort(x)
Shiazy> n <- length(x)
Shiazy> if (n < 1)
Shiazy> stop("'x' must have 1 or more non-missing values")
Shiazy> vals <- sort(unique(x))
Shiazy> rval <- approxfun(vals, cumsum(tabulate(match(x, vals)))/n,
Shiazy> method = "constant", yleft = 0, yright = 1, f = 0, ties = "ordered")
Shiazy> class(rval) <- c("ecdf", "stepfun", class(rval))
Shiazy> attr(rval, "call") <- sys.call()
Shiazy> rval
Shiazy> --- [/R-code] ---
Shiazy> I think one of the two calls to sort can be removed, improving the
performance.
Shiazy> What do you think?
I agree, and I have removed the 2nd one.
Thank you for your note.
Martin
Shiazy> Sincerely,
Shiazy> -- Marco
Shiazy> __
Shiazy> R-devel@r-project.org mailing list
Shiazy> 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] Possible changes to connections
In a previous version of the 'filehash' package, the 'filehashDB1'
class had a slot for an open connection corresponding to the database
file. I quickly learned that if the R object ever got removed or
reassigned I was left hanging with an open file connection.
If I remember correctly, I resorted to creating an environment in the
R object which stored the connection number for the the database file
connection. Then I registered a finalizer for that environment which
grabbed the connection via 'getConnection' and then closed the
connection.
I eventually abandoned this approach since it was error-prone and I
often ran into strange difficult-to-reproduce situations where the R
object representing the database had been removed but the file
connection was still open because garbage collection had not yet
occurred. I would have very much preferred a system where the file
connection was automatically closed once any references to it were
gone.
-roger
On 5/30/07, Prof Brian Ripley <[EMAIL PROTECTED]> wrote:
> When I originally implemented connections in R 1.2.0, I followed the model
> in the 'Green Book' closely. There were a number of features that forced
> a particular implementation, and one was getConnection() that allows one
> to recreate a connection object from a number.
>
> I am wondering if anyone makes use of this, and if so for what?
>
> It would seem closer to the R philosophy to have connection objects that
> get garbage collected when no R object refers to them. This would allow
> for example
>
> readLines(gzfile("foo.gz"))
>
> which currently leaks a connection slot as the connection cannot be closed
> (except via closeAllConnections() or getConnection()) without an R object
> being returned.
>
> The correct usage currently is
>
> readLines(con <- gzfile("foo.gz")); close(con)
>
> which is a little awkward but more importantly seems little understood.
>
> Another issue is that the current connection objects can be saved and
> restored but refer to a global table that is session-specific so they lose
> their meaning (and perhaps gain an unintended one).
>
> What I suspect is that very few users are aware of the Green Book
> description and so we have freedom to make some substantial changes
> to the implementation. Both issues suggest that connection objects should
> be based on external pointers (which did not exist way back in 1.2.0).
>
> [I know there is a call to getConnection in package gtools, but the return
> value is unused!]
>
> --
> Brian D. Ripley, [EMAIL PROTECTED]
> Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
> University of Oxford, Tel: +44 1865 272861 (self)
> 1 South Parks Road, +44 1865 272866 (PA)
> Oxford OX1 3TG, UKFax: +44 1865 272595
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Roger D. Peng | http://www.biostat.jhsph.edu/~rpeng/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Possible changes to connections
Prof Brian Ripley <[EMAIL PROTECTED]> writes:
> When I originally implemented connections in R 1.2.0, I followed the model
> in the 'Green Book' closely. There were a number of features that forced
> a particular implementation, and one was getConnection() that allows one
> to recreate a connection object from a number.
>
> I am wondering if anyone makes use of this, and if so for what?
I don't see any uses of it in the Bioconductor package sources.
> It would seem closer to the R philosophy to have connection objects that
> get garbage collected when no R object refers to them. This would allow
> for example
>
> readLines(gzfile("foo.gz"))
I think this would be a nice improvement as it matches what many
people already assume happens as well as matches what some other
languages do (in particular, Python).
+ seth
--
Seth Falcon | Computational Biology | Fred Hutchinson Cancer Research Center
http://bioconductor.org
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Possible changes to connections
Prof Brian Ripley wrote: > When I originally implemented connections in R 1.2.0, I followed the model > in the 'Green Book' closely. There were a number of features that forced > a particular implementation, and one was getConnection() that allows one > to recreate a connection object from a number. [...] > Another issue is that the current connection objects can be saved and > restored but refer to a global table that is session-specific so they lose > their meaning (and perhaps gain an unintended one). > > What I suspect is that very few users are aware of the Green Book > description and so we have freedom to make some substantial changes > to the implementation. Both issues suggest that connection objects should > be based on external pointers (which did not exist way back in 1.2.0). Sounds great! I would also like to see the following interface (all or in parts) added for working with connections from C. This is an update to the patch I created here: http://wiki.r-project.org/rwiki/doku.php?id=developers:r_connections_api /* Acting upon a connection */ void R_CloseConnection(SEXP); int R_VfprintfConnection(SEXP, const char *format, va_list ap); int R_FgetcConnection(SEXP); double R_SeekConnection(SEXP, double where, int origin, int rw); void R_TruncateConnection(SEXP); int R_FlushConnection(SEXP); size_t R_ReadConnection(SEXP, void *buf, size_t size, size_t n); size_t R_WriteConnection(SEXP, const void *buf, size_t size, size_t n); /* Querying a connection */ Rboolean R_ConnectionIsText(SEXP); Rboolean R_ConnectionIsOpen(SEXP); Rboolean R_ConnectionCanRead(SEXP); Rboolean R_ConnectionCanWrite(SEXP); Rboolean R_ConnectionCanSeek(SEXP); Rboolean R_ConnectionIsBlocking(SEXP); /* Prototypes for new connections created in C */ typedef Rboolean (*Rc_open)(void *private); typedef void (*Rc_close)(void *private); typedef void (*Rc_destroy)(void *private); /* when closing connection */ typedef int (*Rc_vfprintf)(void *private, const char *, va_list); typedef int (*Rc_fgetc)(void *private); typedef double (*Rc_seek)(void *private, double, int, int); typedef void (*Rc_truncate)(void *private); typedef int (*Rc_fflush)(void *private); typedef size_t (*Rc_read)(void *, size_t, size_t, void *private); typedef size_t (*Rc_write)(const void *, size_t, size_t, void *private); /* Create a Connection */ SEXP R_NewConnection(char *class, char *description, char *mode, Rboolean blocking, Rc_open, Rc_close, Rc_destroy, Rc_vfprintf, Rc_fgetc, Rc_seek, Rc_truncate, Rc_fflush, Rc_read, Rc_write, void *private); /* Swap out the standard C streams. More exotic, but it may clean up the messy R_ConsoleFile, R_Outputfile, WriteConsole(), WriteConsoleEx(), etc... confusion. */ Rboolean R_RegisterStdinConnection(SEXP scon); Rboolean R_RegisterStdoutConnection(SEXP scon); Rboolean R_RegisterStderrConnection(SEXP scon); Jeff -- http://biostat.mc.vanderbilt.edu/JeffreyHorner __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
