similar to: PATCH: Asserting that 'connection' used has not changed + R_GetConnection2()

Dear all, I do not completely understand following behaviour : > con <- file("test.txt") > isOpen(con) [1] FALSE > open(con) > isOpen(con) [1] TRUE > close(con) > isOpen(con) Error in isOpen(con) : invalid connection > str(con) Classes 'file', 'connection' atomic [1:1] 3 ..- attr(*, "conn_id")=<externalptr> Why do I get an

Hi all, Looking at the IO.readlines source in io.c, it looks to me like they grab 8k chunks, split on the input record separator, and buffer accordingly. Since it looks like ReadFileScatter() does some of that work automatically (in page file sized chunks), I thought I''d give it a try. Here''s what I''ve got, but it doesn''t work. I have an incorrect parameter

Hi guys, I'm trying to connect Asterisk to the MySQL, but I can't execute it. It returns an error, as below: -- Executing [200 at teste:2] MYSQL("Console/dsp", "Query resultid 1 SELECT/ ramal/ FROM/ colaboradores/ WHERE/ ramal=200") in new stack [Feb 18 15:55:13] WARNING[7696]: app_mysql.c:393 aMYSQL_query: aMYSQL_query: mysql_query failed. Error: You have an error in

Is there a 'proper' way of checking if cluster is active. For example, I create a cluster called .PBcluster > str(.PBcluster) List of 4 $ :List of 3 ..$ con :Classes 'sockconn', 'connection' atomic [1:1] 3 .. .. ..- attr(*, "conn_id")=<externalptr> ..$ host: chr "localhost" ..$ rank: int 1 ..- attr(*, "class")= chr

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

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

On Thu, Nov 08, 2018 at 06:12:40AM +1300, Andrew Bartlett wrote: > On Wed, 2018-11-07 at 15:19 +0300, Albert Berger via samba wrote: > >  > > I tried in sequence to start Samba in following conditions: > > > > 1. With all clients disconnected from Samba server; > > 2. As above + all shares disabled; > > 3. As above + minimal smb.conf > > 4. With

Consider this code. This is R 3.4.2, but based on a quick look at the NEWS, this has not been fixed. tryCatch( readLines(tempfile(), warn = FALSE)[1], error = function(e) NA, warning = function(w) NA ) rm(list=ls(all.names = TRUE)) gc() showConnections(all = TRUE) If you run it, you'll get a connection you cannot close(), i.e. the last showConnections() call prints: ?

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

Hi, > >Thank you very much Park. There is one curious difference I noticed >with the write operations. It seems that there is a line ending issue >between a file descriptor opened with File.open vs File.nopen. You >can see this easily enough by doing something like this: > >fh1 = File.open("test1.txt","w+") >fh1.print "hello\nworld\n"

This largely copies the code from modesetting with minor adjustments. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- I've tried privately to get people to test this out, but to no avail. I don't have the hardware to verify this one way or the other. Ideally with this patch you should be (a) able to use a tiled monitor at 60hz with DP-MST and (b) be able to see connectors

This largely copies the code from modesetting with minor adjustments. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- I've tested this back and forth with a GTX 960 + 2x U2415 monitors, chained to each other. I turned them on/off. I messed with their DP 1.1/1.2 settings. I pulled plugs a few times. This seems to pass the test. No crashes, the connectors seem to come and go

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

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

Dear list, I was trying to create a VarClass for nlme to work with Fay-Herriot (FH) models. The idea was to create a modification of VarComb that instead of multiplying the variance functions made their sum (I called it varSum). After some fails etc... I found that the I was not getting the expected results because I needed to make sigma fixed. Trying to find how to make sigma fixed I run into

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

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 >

Signed-off-by: Haiyang Zhang <haiyangz at microsoft.com> Signed-off-by: Hank Janssen <hjanssen at microsoft.com> --- drivers/staging/hv/channel.c | 48 ++++++------ drivers/staging/hv/channel_mgmt.c | 48 ++++++------ drivers/staging/hv/connection.c | 154 ++++++++++++++++++------------------ drivers/staging/hv/vmbus_drv.c | 2 +-

Signed-off-by: Haiyang Zhang <haiyangz at microsoft.com> Signed-off-by: Hank Janssen <hjanssen at microsoft.com> --- drivers/staging/hv/channel.c | 48 ++++++------ drivers/staging/hv/channel_mgmt.c | 48 ++++++------ drivers/staging/hv/connection.c | 154 ++++++++++++++++++------------------ drivers/staging/hv/vmbus_drv.c | 2 +-

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