Re: [Rd] Possible changes to connections
On Fri, 1 Jun 2007, mel wrote: Prof Brian Ripley a écrit : I use getConnection(). In the context in which I use it, the number of the connection is known a priori. I don't see how you can know it 'a priori': it is an implementation detail (and since R itself uses connections, those details could easily change). (disclaimer : I don't claim its the best way to proceed) Before launching my app, the connections context is : > showConnections(all=TRUE) description class mode text isopen can read can write 0 "stdin" "terminal" "r" "text" "opened" "yes""no" 1 "stdout""terminal" "w" "text" "opened" "no" "yes" 2 "stderr""terminal" "w" "text" "opened" "no" "yes" So, the call to socketConnections() creates always (at least for all my experiments) a connection with number 3. Btw, if (socketConnections(...) != 3) the application simply don't launch. So, if the application runs, it's sure that this is with a connection number==3. That's why I say that "the number of the connection is known a priori". You don't *know* that: it depends on how R internally numbers connections and what the startup code does. That detail will almost certainly change. Of course, the connection number could also be retrieved eg using the description field. For now, at least. -- 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] Possible changes to connections
Prof Brian Ripley a écrit : >> I use getConnection(). >> In the context in which I use it, the number of the connection is >> known a priori. > > I don't see how you can know it 'a priori': it is an implementation detail > (and since R itself uses connections, those details could easily change). (disclaimer : I don't claim its the best way to proceed) Before launching my app, the connections context is : > showConnections(all=TRUE) description class mode text isopen can read can write 0 "stdin" "terminal" "r" "text" "opened" "yes""no" 1 "stdout""terminal" "w" "text" "opened" "no" "yes" 2 "stderr""terminal" "w" "text" "opened" "no" "yes" So, the call to socketConnections() creates always (at least for all my experiments) a connection with number 3. Btw, if (socketConnections(...) != 3) the application simply don't launch. So, if the application runs, it's sure that this is with a connection number==3. That's why I say that "the number of the connection is known a priori". Of course, the connection number could also be retrieved eg using the description field. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problems when linking to R shared library
On 31 May 2007 at 19:04, John Maddock wrote:
| Folks,
|
| I'm fairly sure that I'm doing something stupid, but I'm getting a few
| really strange results from *some* of the distributions, but by no means
| all,
| when I link directly to the R shared library.
When I try to build your program, I get very immediate and explicit messages:
[EMAIL PROTECTED]:~> g++ -Wall -O3 -I/usr/share/R/include -o /tmp/johnmaddock
/tmp/johnmaddock.cc -lRmath
/tmp/ccb5T7l9.o: In function `main':
johnmaddock.cc:(.text+0xae): undefined reference to `Rf_pf'
johnmaddock.cc:(.text+0xed): undefined reference to `Rf_pchisq'
johnmaddock.cc:(.text+0x136): undefined reference to `Rf_pgamma'
johnmaddock.cc:(.text+0x17a): undefined reference to `Rf_ppois'
johnmaddock.cc:(.text+0x1b9): undefined reference to `Rf_qchisq'
johnmaddock.cc:(.text+0x202): undefined reference to `Rf_qgamma'
collect2: ld returned 1 exit status
which shows that the compiler/linker do not yet know about the functions you
use.
Your mistake was to not do
#define MATHLIB_STANDALONE 1
before the #include of Rmath.h. After that, all is well:
[EMAIL PROTECTED]:~> g++ -Wall -O3 -I/usr/share/R/include -o /tmp/johnmaddock
/tmp/johnmaddock.cc -lRmath
[EMAIL PROTECTED]:~> /tmp/johnmaddock
0.646447
0.527633
0.090204
0.124652
1.38629
5.03504
[EMAIL PROTECTED]:~>
| I've tried this on both Windows with the precompiled Mingw binary of R-2.5.0
| (compiling my code with MinGW-3.4.2), and by building R-2.5.0 on Mandriva
| Linux with gcc-3.4.4 and --enable-R-shlib. The actual code is at the end of
| the message, but the main cases are:
|
| std::cout << pf(1.5, 2.0, 3.0, 1, 0) << std::endl;
|
| Outputs 1, expect 0.646447
Good.
| std::cout << pchisq(1.5, 2.0, 1, 0) << std::endl;
|
| Outputs 1, expect 0.527633
Good.
| std::cout << pgamma(1.5, 2.0, 3.0, 1, 0) << std::endl;
|
| Outputs 1, expect 0.090204
Good.
| std::cout << ppois(2.0, 5.0, 1, 0) << std::endl;
|
| Outputs 0, expect 0.124652
Good.
| std::cout << qchisq(0.5, 2.0, 1, 0) << std::endl;
|
| Outputs -0.61379, expect 1.38629
Good.
| std::cout << qgamma(0.5, 2.0, 3.0, 1, 0) << std::endl;
|
| Outputs 0.0282703, expect 5.03504
Good.
| I should stress that within the R environment, I *do* get the values I
| expect: though sometimes the arguments need adjusting as the C functions
| have slightly different argument lists from the R versions.
|
| Also:
|
| std::cout << qpois(0.5, 5.0, 1, 0) << std::endl;
|
| Seems to go into an infinite loop inside qpois, while:
|
| qbeta(0.1, 1e-5, 1e-5, 1, 0);
|
| Raises an access violation inside R: although I should stress that all other
| beta quantiles I've tested come out OK.
|
| Anyway, hopefully you can just tell me what an idiot I am :-)
We are too polite for that, we also insist that folks do the old RTFM -- the
#define you missed is of course mentioned in the R Extensions manual.
Hth, Dirk
| Thanks in advance for any help you can give,
|
| John Maddock.
|
| The complete source code is:
|
| #include
| #include
|
| extern "C" {
| #include "Rmath.h"
| }
|
| int main(int argc, const char** argv)
| {
| std::cout << pf(1.5, 2.0, 3.0, 1, 0) << std::endl;
| std::cout << pchisq(1.5, 2.0, 1, 0) << std::endl;
| std::cout << pgamma(1.5, 2.0, 3.0, 1, 0) << std::endl;
| std::cout << ppois(2.0, 5.0, 1, 0) << std::endl;
| std::cout << qchisq(0.5, 2.0, 1, 0) << std::endl;
| std::cout << qgamma(0.5, 2.0, 3.0, 1, 0) << std::endl;
| //std::cout << qpois(0.5, 5.0, 1, 0) << std::endl;
| return 0;
| }
|
| __
| R-devel@r-project.org mailing list
| https://stat.ethz.ch/mailman/listinfo/r-devel
--
Hell, there are no rules here - we're trying to accomplish something.
-- Thomas A. Edison
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Possible changes to connections
On Thu, 31 May 2007, Seth Falcon wrote:
> > When I ran some tests I found 7 packages on CRAN that in their tests
> > were not closing connections. Four of those are maintained by R-core
> > members.
> > Even though none were by me, I think this is too easy to forget to
> > do!
>
> I agree that it is easy to forget. It is especially easy if one
> creates so-called anonymous connection references like
> readLines(file(path)) -- this anonymous idiom seems nature to me when
> coding R and it would be nice to make it work for connections.
I like the idea of the connection being closed when there
are no more references to it. I guess that means when the
garbage collector notices it has been orphaned, which may
take a while.
However, one of my longstanding complaints about connections
in Splus and R may have a bearing here also. Currently, if you
want to have your file opened in a particular way, say for
only reading or for appending or in binary mode then you
need to specify open=mode when calling file(). However that
also tells it to actually open the file. I would prefer that
there was a mode= argument to file that meant that when the
file is eventually opened it would be opened with that mode.
open= should be restricted to TRUE or FALSE, or IMO, be eliminated.
(We have an open() function for that.) With the current system
readLines(file(path))
does not leave path open but
readLines(file(path, "r"))
does leave it open. E.g., using readLines(file(path))
as Seth did appears to work fine:
> system(paste("/usr/sbin/lsof -p", Sys.getpid(),"|grep /tmp/twolines.txt"))
> readLines(file("/tmp/twolines.txt"))
[1] "One," "two, and that is it."
> system(paste("/usr/sbin/lsof -p", Sys.getpid(),"|grep /tmp/twolines.txt"))
> # no lsof output means the file is not open
but asking to have it opened in readonly and binary
mode leaks a file descriptor:
> system(paste("/usr/sbin/lsof -p", Sys.getpid(),"|grep /tmp/twolines.txt"))
> readLines(file("/tmp/twolines.txt", open="rb"))
[1] "One," "two, and that is it."
> system(paste("/usr/sbin/lsof -p", Sys.getpid(),"|grep /tmp/twolines.txt"))
R 16950 bill3r REG8,2 26 229597 /tmp/twolines.txt
That difference sinces unnatural to me.
Of course, we could just add the mode= argument and hope
people started using it instead of open=.
Bill Dunlap
Insightful Corporation
bill at insightful dot com
360-428-8146
"All statements in this message represent the opinions of the author and do
not necessarily reflect Insightful Corporation policy or position."
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Calling R_PolledEvents from R_CheckUserInterrupt
should be there shortly - I have no way of testing windows (right now,
at least), so hopefully Duncan M will have time to take a look
Deepayan Sarkar wrote:
> On 5/5/07, Luke Tierney <[EMAIL PROTECTED]> wrote:
>
> [...]
>
>> However, R_PolledEvents is only called from a limited set of places
>> now (including the socket reading code to keep things responsive
>> during blocking reads). But it is not called from the interupt
>> checking code, which means if a user does something equivalent to
>>
>> while (TRUE) {}
>>
>> there is not point where events get looked at to see a user interrupt
>> action. The current definition of R_CheckUserInterrupt is
>>
>> void R_CheckUserInterrupt(void)
>> {
>> R_CheckStack();
>> /* This is the point where GUI systems need to do enough event
>> processing to determine whether there is a user interrupt event
>> pending. Need to be careful not to do too much event
>> processing though: if event handlers written in R are allowed
>> to run at this point then we end up with concurrent R
>> evaluations and that can cause problems until we have proper
>> concurrency support. LT */
>> #if ( defined(HAVE_AQUA) || defined(Win32) )
>> R_ProcessEvents();
>> #else
>> if (R_interrupts_pending)
>> onintr();
>> #endif /* Win32 */
>> }
>>
>> So only on Windows or Mac do we do event processing. We could add a
>> R_PolledEvents() call in the #else bit to support this, though the
>> cautions in the comment do need to be kept in mind.
>
> I have been using the following patch to src/main/errors.c for a while
> without any obvious ill effects. Could we add this to r-devel (with
> necessary changes for Windows, if any)?
>
> -Deepayan
>
> Index: errors.c
> ===
> --- errors.c(revision 41764)
> +++ errors.c(working copy)
> @@ -39,6 +39,8 @@
> #include /* for GEonExit */
> #include /* for imax2 */
>
> +#include
> +
> #ifndef min
> #define min(a, b) (a #endif
> @@ -117,6 +119,8 @@
> #if ( defined(HAVE_AQUA) || defined(Win32) )
> R_ProcessEvents();
> #else
> +R_PolledEvents();
> if (R_interrupts_pending)
> onintr();
> #endif /* Win32 */
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Robert Gentleman, PhD
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M2-B876
PO Box 19024
Seattle, Washington 98109-1024
206-667-7700
[EMAIL PROTECTED]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Possible changes to connections
Also nice would be the ability to implement connection types from packages (in much the same way as graphics devices). On 5/31/07, Seth Falcon <[EMAIL PROTECTED]> wrote: > Hi, > > One more comment on this thread... > > Jeffrey Horner <[EMAIL PROTECTED]> writes: > > > 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 > > I wanted to voice a "me too" for wanting to see an interface added for > working with connections from C in package code. There are a number > of places where this would be useful and provide cleaner solution than > what is possible today. > > The proposed interface looks useful. > > + 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 > -- Byron Ellis ([EMAIL PROTECTED]) "Oook" -- The Librarian __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] feature request for page() and options()
Hi,
I have been playing around with a Qt based pager. One of the things I
would like to be able to do is syntax highlighting for R code. This is
mostly relevant with the page function, e.g.
page(ls)
The problem in this case is that the pager has no way of knowing
whether the file it is showing contains R code (e.g. page(,
method="print") need not produce valid R code); the name of the file
is always produced by tempfile("Rpage."), so it looks like
"/tmp/RtmpQfmyH8/Rpage.4a43d33f".
A simple solution is to use an appropriate file extension. Here's a
trivial patch that implements this:
Index: src/library/utils/R/page.R
===
--- src/library/utils/R/page.R (revision 41765)
+++ src/library/utils/R/page.R (working copy)
@@ -19,10 +19,12 @@
} else {
subx <- deparse(substitute(x))
}
-file <- tempfile("Rpage.")
-if(match.arg(method) == "dput")
+if(match.arg(method) == "dput") {
+file <- sprintf("%s.R", tempfile("Rpage."))
local.dput(x, file, ...)
+}
else {
+file <- sprintf("%s.txt", tempfile("Rpage."))
sink(file)
local.print(x, ...)
sink()
Unless there is a downside (or a better solution), I would like to see
this feature added.
My second feature request is a bit more involved. options("pager") can
be a function, which is how I have implemented my pager. I would like
options("browser") and options("editor") to behave similarly, i.e. to
have them be settable to functions as well. This seems to allow more
flexibility, be consistent with S philosophy, and there shouldn't be
any incompatibility as the defaults do not change.
This needs changes in a few different places, but if the idea seems
acceptable, I am happy to supply a patch (I have a working
implementation).
-Deepayan
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Possible changes to connections
Hi, One more comment on this thread... Jeffrey Horner <[EMAIL PROTECTED]> writes: > 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 I wanted to voice a "me too" for wanting to see an interface added for working with connections from C in package code. There are a number of places where this would be useful and provide cleaner solution than what is possible today. The proposed interface looks useful. + 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
[Rd] Calling R_PolledEvents from R_CheckUserInterrupt
On 5/5/07, Luke Tierney <[EMAIL PROTECTED]> wrote:
[...]
> However, R_PolledEvents is only called from a limited set of places
> now (including the socket reading code to keep things responsive
> during blocking reads). But it is not called from the interupt
> checking code, which means if a user does something equivalent to
>
> while (TRUE) {}
>
> there is not point where events get looked at to see a user interrupt
> action. The current definition of R_CheckUserInterrupt is
>
> void R_CheckUserInterrupt(void)
> {
> R_CheckStack();
> /* This is the point where GUI systems need to do enough event
> processing to determine whether there is a user interrupt event
> pending. Need to be careful not to do too much event
> processing though: if event handlers written in R are allowed
> to run at this point then we end up with concurrent R
> evaluations and that can cause problems until we have proper
> concurrency support. LT */
> #if ( defined(HAVE_AQUA) || defined(Win32) )
> R_ProcessEvents();
> #else
> if (R_interrupts_pending)
> onintr();
> #endif /* Win32 */
> }
>
> So only on Windows or Mac do we do event processing. We could add a
> R_PolledEvents() call in the #else bit to support this, though the
> cautions in the comment do need to be kept in mind.
I have been using the following patch to src/main/errors.c for a while
without any obvious ill effects. Could we add this to r-devel (with
necessary changes for Windows, if any)?
-Deepayan
Index: errors.c
===
--- errors.c(revision 41764)
+++ errors.c(working copy)
@@ -39,6 +39,8 @@
#include /* for GEonExit */
#include /* for imax2 */
+#include
+
#ifndef min
#define min(a, b) (ahttps://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Problems when linking to R shared library
Folks,
I'm fairly sure that I'm doing something stupid, but I'm getting a few
really strange results from *some* of the distributions, but by no means
all,
when I link directly to the R shared library.
I've tried this on both Windows with the precompiled Mingw binary of R-2.5.0
(compiling my code with MinGW-3.4.2), and by building R-2.5.0 on Mandriva
Linux with gcc-3.4.4 and --enable-R-shlib. The actual code is at the end of
the message, but the main cases are:
std::cout << pf(1.5, 2.0, 3.0, 1, 0) << std::endl;
Outputs 1, expect 0.646447
std::cout << pchisq(1.5, 2.0, 1, 0) << std::endl;
Outputs 1, expect 0.527633
std::cout << pgamma(1.5, 2.0, 3.0, 1, 0) << std::endl;
Outputs 1, expect 0.090204
std::cout << ppois(2.0, 5.0, 1, 0) << std::endl;
Outputs 0, expect 0.124652
std::cout << qchisq(0.5, 2.0, 1, 0) << std::endl;
Outputs -0.61379, expect 1.38629
std::cout << qgamma(0.5, 2.0, 3.0, 1, 0) << std::endl;
Outputs 0.0282703, expect 5.03504
I should stress that within the R environment, I *do* get the values I
expect: though sometimes the arguments need adjusting as the C functions
have slightly different argument lists from the R versions.
Also:
std::cout << qpois(0.5, 5.0, 1, 0) << std::endl;
Seems to go into an infinite loop inside qpois, while:
qbeta(0.1, 1e-5, 1e-5, 1, 0);
Raises an access violation inside R: although I should stress that all other
beta quantiles I've tested come out OK.
Anyway, hopefully you can just tell me what an idiot I am :-)
Thanks in advance for any help you can give,
John Maddock.
The complete source code is:
#include
#include
extern "C" {
#include "Rmath.h"
}
int main(int argc, const char** argv)
{
std::cout << pf(1.5, 2.0, 3.0, 1, 0) << std::endl;
std::cout << pchisq(1.5, 2.0, 1, 0) << std::endl;
std::cout << pgamma(1.5, 2.0, 3.0, 1, 0) << std::endl;
std::cout << ppois(2.0, 5.0, 1, 0) << std::endl;
std::cout << qchisq(0.5, 2.0, 1, 0) << std::endl;
std::cout << qgamma(0.5, 2.0, 3.0, 1, 0) << std::endl;
//std::cout << qpois(0.5, 5.0, 1, 0) << std::endl;
return 0;
}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Possible changes to connections
mel writes: >> There could be/was the same debate in C/C++. >> That's may be just a matter of education about not forgetting >> to close previously opened doors ! R is not C/C++. In general, one does not expect to explicitly handle memory allocation and release when programming in R. Treating connections differently, when there is no longer any technical reason to do so, is surprising. Prof Brian Ripley <[EMAIL PROTECTED]> writes: > When I ran some tests I found 7 packages on CRAN that in their tests > were not closing connections. Four of those are maintained by R-core > members. > Even though none were by me, I think this is too easy to forget to > do! I agree that it is easy to forget. It is especially easy if one creates so-called anonymous connection references like readLines(file(path)) -- this anonymous idiom seems nature to me when coding R and it would be nice to make it work for connections. + 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
On Thu, 31 May 2007, mel wrote:
Prof Brian Ripley a écrit :
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'm currently using connections (socketConnection(), etc)
and I first want to *thank you* for this nice work.
(imho, it's so much simpler than the underlying C/C++ stuff.)
I am wondering if anyone makes use of this, and if so for what?
I use getConnection().
In the context in which I use it, the number of the connection is
known a priori.
I don't see how you can know it 'a priori': it is an implementation detail
(and since R itself uses connections, those details could easily change).
So getConnection() is an easy way to access to the connection
for the functions which need to.
I do not however pretend this is the best way to proceed.
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(con <- gzfile("foo.gz")); close(con)
which is a little awkward but more importantly seems little understood.
There could be/was the same debate in C/C++.
That's may be just a matter of education about not forgetting
to close previously opened doors !
When I ran some tests I found 7 packages on CRAN that in their tests were
not closing connections. Four of those are maintained by R-core members.
Even though none were by me, I think this is too easy to forget to do!
--
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] Possible changes to connections
Prof Brian Ripley a écrit :
> 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'm currently using connections (socketConnection(), etc)
and I first want to *thank you* for this nice work.
(imho, it's so much simpler than the underlying C/C++ stuff.)
> I am wondering if anyone makes use of this, and if so for what?
I use getConnection().
In the context in which I use it, the number of the connection is
known a priori.
So getConnection() is an easy way to access to the connection
for the functions which need to.
I do not however pretend this is the best way to proceed.
> 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(con <- gzfile("foo.gz")); close(con)
> which is a little awkward but more importantly seems little understood.
There could be/was the same debate in C/C++.
That's may be just a matter of education about not forgetting
to close previously opened doors !
> 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'm not skilled enough for any advice here, but from a simple user
point of view, I just hope it could continue to be as simple and
practical as today.
And I renew my thanks for the existing tool (and also the rest !).
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
