Prof Brian Ripley <[EMAIL PROTECTED]> writes:
> [I know there is a call to getConnection in package gtools, but
> the return value is unused!]
Speaking of connections and gtools, I've been wondering if the
gtools setTCPNoDelay function's method of getting the Unix file
descriptor of a socket co
On 5/31/07, Bill Dunlap <[EMAIL PROTECTED]> wrote:
> 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.
Although, playing devil's advocate, it Green Book
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 c
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).
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
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:
> >>
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
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
c
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
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
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 nu
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 connec
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
13 matches
Mail list logo
