From byron.ellis at gmail.com  Fri Jun  1 09:42:43 2007
From: byron.ellis at gmail.com (Byron Ellis)
Date: Fri, 1 Jun 2007 00:42:43 -0700
Subject: [Rd] Possible changes to connections
In-Reply-To: <Pine.GSO.4.56.0705311734520.2074@durian.statsci.com>
References: <Pine.LNX.4.64.0705301726400.11532@gannet.stats.ox.ac.uk>
	<465E7B0B.2080005@altk.com>
	<Pine.LNX.4.64.0705311534280.27499@gannet.stats.ox.ac.uk>
	<m24plssytq.fsf@ziti.local>
	<Pine.GSO.4.56.0705311734520.2074@durian.statsci.com>
Message-ID: <7098abec0706010042u437fd9c1y5d1c71e062125e64@mail.gmail.com>

On 5/31/07, Bill Dunlap <bill at insightful.com> 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 connections do
follow the same pattern as the other resource allocation type,
graphics devices. Not that this should be taken as endorsement, I
think I would like to see graphics devices head in the direction of
being actual objects as well (and I think I would want with() to be
involved with that).

It would also be really nice if connections became more like graphics
devices in that new connections could be implemented from a package.
That would make, for example, implementing clipboard connections on OS
X do the Right Thing under X11 and the GUI.

CLIM-style event streams would also be nice, but is almost surely too
much to ask. :-)

>
> 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 bill    3r   REG    8,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=.

Maybe the actual solution is actually two types of objects? An
abstract resource object that describes a potential connection and
then leave the connection object to active I/O streams?

>
> ----------------------------------------------------------------------------
> 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 at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>


-- 
Byron Ellis (byron.ellis at gmail.com)
"Oook" -- The Librarian



[Rd] Possible changes to connections
Byron Ellis