[Rd] Wishlist: as.raw [or similar] support for tcl strings (PR#13758)
Full_Name: Rick Sayre
Version: 2.9.0
OS: windows, os x, linux
Submission from: (NULL) (138.72.153.236)
if a tcl "string" contains binary data, there is a problem getting this data
to R, since there appears to be no way to get "raw" data without NULL
interpretation. Here is a simple example. The data should be
Here are 1Here is 2And finally three
> tq <- .Tcl("set tcls [binary format H*
\"4865726520617265203100486572652069732032416E642066696E616C6C7920746872656500\"]")
#tclvalue stops returning data after the first NULL
> tclvalue("tcls")
[1] "Here are 1"
#interestingly, as.character gets more, but gets confused
> as.character(tq)
[1] "Here""are" "1" "is" "2" "finally" "three"
> # we confirm that the tcl representation does indeed have the NULLs:
> .Tcl("binary scan $tcls H* tmps")
1
> tclvalue("tmps")
[1]
"4865726520617265203100486572652069732032416e642066696e616c6c7920746872656500"
I would naively suggest something like tclrawvalue() and/or as.raw() utilizing
Tcl_GetByteArrayFromObj
A good discussion of the basics of this issue for general tcl embedding can be
found here:
http://www2.tcl.tk/1180
For those who might be wondering "what the heck are you doing trying to pass
binary data from tcl?", the answer is that non-blocking I/O does not work on
windows,
and timeouts, modes, and line control for RS232 ports aren't supported at all on
R.
Using tcl provides a nice portable way to do this in R, but currently requires
converting everything to ascii encodings since the binary data fails to make it
across.
Cheers
--Rick
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Typo in 2.10.0 NEWS file (PR#14054)
Full_Name: Rick Sayre Version: 2.10.0 OS: linux/windows/os x Submission from: (NULL) (138.72.146.168) Man, it feels ungrateful to report this, but it looks like in the process of having my wish PR#13758 fulfilled, a typo snuck in to the "NEWS" releasenotes: o New as.raw() method for "tclObj" objects (wish of PR#13578). I'm pretty sure that's a typo, and should be 13758 instead of 13578. Perhaps "nobody cares", but I mention it for completeness. [and thanks for the new method!] Cheers --Rick __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Makevars PKG_LIBS ignored by SHLIB (PR#9473)
Full_Name: Rick Sayre Version: 2.4.0 OS: Windows Submission from: (NULL) (138.72.27.164) PKG_LIBS works fine on *nix on windows, it seems to be ignored by the "SHLIB" script so, R CMD SHLIB blah properly uses PKG_CPPFLAGS and PKG_CFLAGS from Makevars, but PKG_LIBS is ignored __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Bug in TAB handling for Win32 Rterm and Rgui (PR#9820)
Full_Name: Rick Sayre Version: 2.5.1 OS: Windows XP Pro Submission from: (NULL) (138.72.131.190) I floated this to r-help a few days ago just to see if i was off-base. Here we go: Before I start, i want to first extend thanks for the big improvements in integration of command completion for the windows version. Really nice to have now. But i believe there are some issues. In getline/getline.c, the "tab" case of the character handling switch statement in getline() simply "break;"s to the end if tab completion is not enabled, thus eating the tab. Thus, if tab completion is disabled, a tab no longer serves as a tab; it disappears. likewise, in console.c, if k == TABKEY, a return is done without adding the key to kbuf, thus TAB is always discarded, even if completion is disabled. It seems to me that this is wrong. This new TAB behavior now makes it impossible for me to copy/paste text from a text file of R expressions which use TABs. Copy paste behavior which worked in 2.4.x for Rterm now does not, since the discarded TABs mean that keyword separators may disappear, changing the meaning of pasted text. Rgui thankfully still works with copy/paste, since the completion/TAB processing code is bypassed when activating the "paste" command. But pressing the TAB key in Rgui with completion disabled results in the tab being eaten, so in this sense behavior has changed in an undesireable way from previous versions. I'd like to request the ability to have both --- TAB as a working separator, and the ability to configure the completion key to something other than TAB. This way one can both enjoy completion and successfully copy/paste text containing tabs. Cheers --Rick __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] qr.coef and complex numbers - still busted for non-square case? (PR#13305)
Full_Name: Rick Sayre
Version: 2.8.0
OS: windows, linux, os x
Submission from: (NULL) (138.72.153.166)
PR#8476 and PR#8478
http://bugs.r-project.org/cgi-bin/R/Models-fixed?id=8478
http://bugs.r-project.org/cgi-bin/R/Models-fixed?id=8476
discuss fixing qr.coef to handle complex matrices correctly
But it appears the solution now "shipping" only handles square matrices.
In 2.8.0 [linux, windows, and os x] non-square complex arguments cause
an error.
> qr.solve(cbind(1:11,1),2*(20:30))
[1] 2 38
> qr.solve(cbind(as.complex(1:11),as.complex(1)),as.complex(2*(20:30)))
Error in coef[qr$pivot, ] <- .Call("qr_coef_cmplx", qr, y, PACKAGE = "base") :
number of items to replace is not a multiple of replacement length
If I change the section shown by context below from qr.coef as follows:
if (is.complex(qr$qr)) {
if (!is.complex(y))
y[] <- as.complex(y)
coef <- matrix(NA_complex_, nrow = p, ncol = ny)
#coef[qr$pivot, ] <- .Call("qr_coef_cmplx", qr, y, PACKAGE = "base")
coef[qr$pivot, ] <- .Call("qr_coef_cmplx", qr, y, PACKAGE =
"base")[1:p,]
return(if (im) coef else c(coef))
}
then i get goodness:
my.qr.solve(cbind(as.complex(1:11),as.complex(1)),as.complex(2*(20:30)))
[1] 2+0i 38+0i
I do not pretend to fully understand the afflicted code, so it is very likely
"I'm doing it wrong". What I just did above is exactly what Chris
proposed in #8478, but it appears this was declared to be incorrect and
changed.
The current code in qr.coef seems to handle square complex matrices, but as you
see above, it does not handle non-square conditions.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
