similar to: cannot destroy connection (?) created by readLines in a tryCatch

Displaying 20 results from an estimated 900 matches similar to: "cannot destroy connection (?) created by readLines in a tryCatch"

2017 Dec 14
4
cannot destroy connection (?) created by readLines in a tryCatch
On Thu, Dec 14, 2017 at 7:56 PM, Gabriel Becker <gmbecker at ucdavis.edu> wrote: > Gabor, > > You can grab the connection and destroy it via getConnection and then a > standard close call. Yeah, that's often a possible workaround, but since this connection was opened by readLines() internally, I don't necessarily know which one it is. E.g. I might open multiple
2017 Dec 15
1
cannot destroy connection (?) created by readLines in a tryCatch
Thanks for tracking this down. Yeah, I should use suppressWarnings(), you are right. Although, readLines() might throw another warning, e.g. for incomplete last lines, and you don't necessarily want to suppress that. TBH I am not sure why that warning is given: ? con <- file(tempfile()) ? open(con) Error in open.connection(con) : cannot open the connection In addition: Warning message: In
2017 Dec 14
0
cannot destroy connection (?) created by readLines in a tryCatch
Gabor, You can grab the connection and destroy it via getConnection and then a standard close call. (it actually lists that it is "closed" already, but still in the set of existing connections. I can't speak to that difference). > tryCatch( + readLines(tempfile(), warn = FALSE)[1], + error = function(e) NA, + warning = function(w) NA + ) [1] NA >
2017 Dec 14
0
cannot destroy connection (?) created by readLines in a tryCatch
On Thu, Dec 14, 2017 at 12:17 PM, G?bor Cs?rdi <csardi.gabor at gmail.com> wrote: > On Thu, Dec 14, 2017 at 7:56 PM, Gabriel Becker <gmbecker at ucdavis.edu> > wrote: > > Gabor, > > > > You can grab the connection and destroy it via getConnection and then a > > standard close call. > > Yeah, that's often a possible workaround, but since this
2017 Dec 14
0
cannot destroy connection (?) created by readLines in a tryCatch
This has nothing to do with on.exit. It is an iteraction between where the warning is signaled in 'file' and your _exiting_ warning handler. This combination has the same issue, tryCatch(file(tempfile(), "r"), warning = identity) showConnections(all = TRUE) as does options(warn=2) file(tempfile(), "r") showConnections(all = TRUE) I haven't looked at the
2007 Nov 14
1
isOpen on closed connections
As far as I can tell, 'isOpen' cannot return FALSE in the case when 'rw = ""'. If the connection has already been closed by 'close' or some other function, then isOpen will produce an error. The problem is that when isOpen calls 'getConnection', the connection cannot be found and 'getConnection' produces an error. The check to see if it is
2006 May 26
2
Too many open files
This may be more of an OS question ... I have this call r = get.hist.quote(symbol, start= format(start, "%Y-%m-%d"), end= format(end, "%Y-%m-%d")) which does a url request in a loop and my program runs out of file handlers after few hundred rotations. The error message is: 'Too many open files'. Other than increasing the file handlers assigned to my process, is there
2018 Oct 31
1
PATCH: Asserting that 'connection' used has not changed + R_GetConnection2()
SUMMARY: I'm proposing that R assert that 'connection' options have not changed since first created such that R will produce the following error: > fh <- file("a.txt", open = "w+") > cat("hello\n", file = fh) > close(fh) > fh2 <- file("b.txt", open = "w+") > cat("world\n", file = fh2) >
2009 May 21
3
file descriptor leak in getSrcLines in R 2.10.0 svn 48590
I noticed the following file descriptor leak when I couldn't remove a package unless I shut down the R session that had loaded and used it. The function that triggered the problem printed the output of a call to parse(). Each time one prints a srcref a connection is opened and not closed. It looks like it happens in as.character.srcref's call to getSrcLines, which has some logic I
2006 Nov 02
3
CRAN task views work only once per session (PR#9330)
Cran task views seems to be a "once-per-session" process -- the first attempt to access views in a (RGui for Windows) session works, but subsequent attempts fail. There is a noticeably long pause before the failing call returns. Example session with two calls to "available.views" follows, but similar effects have been observed with two calls to "install.views" and
2000 Dec 20
1
unlink() is not synchronized with existing connections (PR#783)
> # creating a file > cat("sddfasdf", file="tempfile") > showConnections() class description mode text isopen can read can write > con <- file("tempfile", "r") > readLines(con) [1] "sddfasdf" Warning message: incomplete final line in: readLines(con, n, ok) > showConnections() class description mode text isopen
2013 Jun 19
2
Ryacas loads but yacas has an error
Hello yet again, R People: I was working with Ryacas and yacas last night and all was well. Now this morning, I keep getting the following: > a <- Sym("a") > a Error in summary.connection(x) : invalid connection > When I go to yacas from the command line, it works fine. Any suggestions, please? I'm thinking that a port might be open, but here I have: >
2010 Dec 13
1
errors in getconnection or scan
I was wondering if there was a function like "does connection exists" ? I am currently using loops to build up a database, and I have either > B = getConnection(localization) Error in getConnection(localization) : there is no connection -2147483648 In addition: Warning message: In getConnection(localization) : NAs introduced by coercion or > B = scan(localization) Error in
2005 Feb 01
2
assign connections automatically
Hi all, I am trying to create a function that will open connections to all files of one type within the working directory. I've got the function to open the connections, but I am having a bugger of a time trying to get these connections named as objects in the workspace. I am at the point where I can do it outside of the function, but not inside, using assign. I'm sure I'm
2002 Oct 04
1
Getting rid of extra connections?
I'm trying to figure out how to get out of this situation: > source('monit.r') Error in file(file, "r") : All connections are in use > showConnections() description class mode text isopen can read can write > help.search('connection') Error in file(file, "r") : All connections are in use > q() Save workspace image? [y/n/c]: y Error
2000 Dec 19
2
Problem with sink() in 1.20 on Windows (PR#779)
When I use sink(filename) to save the results of the run, the file does not seem to be closed or released back to the OS after I issue the "sink()" command. Here is a baby example: sink("test.txt") tdta <- data.frame(x = x <- 0:10,y = 2 * x + rnorm(11)) print(summary(lm(y ~ x, data=tdta))) sink() At this point (even after refreshing the Explorer window) the filesize
2007 Jul 03
1
bug in closing gzfile-opened connections?
Hi, I am making multiple calls to gzfile() via read.table(), e.g. > x <- read.table( gzfile( "xxx.gz" ) ) After i do this many times (I haven't counted, but probably between 50 and 100 times) I get the error message: Error in open.connection(file, "r") : unable to open connection In addition: Warning message: cannot open compressed file 'xxx.gz' however, I
2002 Jan 10
1
Closing binary file connections
Hi all, I'm writing a function that read data from a binary file. I want to close all opened connections, but it failed: > showConnections() description class mode text isopen can read can write 3 "daten/t5_all.mea" "file" "rb" "binary" "opened" "yes" "no" 4 "daten/t5_all.mea"
2001 Oct 02
1
connections: remember to close it!
Hi all, I have newly discovered the power of connections (although just a small part of it, namely the file() connection). It allowed me to process data file with arbitrary number of fields per line, which I was using awk for preprocessing before readling into R. The combination of the connection, readLines() and strsplit() really make the work a lot easier and more organized. Thanks a bundle
2006 Oct 09
1
Discussion starter for package level Connection API
Thought I'd try and start a discussion. Feel free to jump in. I guess R needs to strike the right balance between opening up the internals to package writers and not allowing them to do bad things. My first attempt at cracking this nut is to just memcpy() the Rconnection and not allow access to the private stuff: /* Alternative to allowing C code access to connection API. */ Rconnection