Re: [Rd] cat cannot write more than 10000 characters? [R 2.8.1]
Yes, I set the encoding to UTF-8 in my .Rprofile. Sorry that I didn't
mention it already. So the complete stand-alone test code which fails in
R --vanilla is the following:
### code begin
options (encoding = utf-8)
testChunk - paste(rep(a, 1 + 1), ## delete + 1 to be successful
collapse=)
output - tempfile()
cat(testChunk, sep = \n, file = output, append = TRUE)
### code end
And the version and locale of my system are
R version 2.8.1 (2008-12-22)
i686-pc-linux-gnu
locale:
LC_CTYPE=de_DE.UTF-8;LC_NUMERIC=C;LC_TIME=de_DE.UTF-8;LC_COLLATE=de_DE.UTF-8;LC_MONETARY=C;LC_MESSAGES=de_DE.UTF-8;LC_PAPER=de_DE.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=de_DE.UTF-8;LC_IDENTIFICATION=C
Prof Brian Ripley schrieb:
Looks like a bug in your iconv. However, that section of code is
conditionalized by
if(con-outconv) { /* translate the buffer */
and I don't see that as non-NULL on my systems. It should only be
called when you specify an encoding on the output connection, so have
you set an option (e.g. encoding) without telling us?
I was able to reproduce a similar problem by
cat(testChunk, sep = \n, file = file(output, encoding=latin1),
append = TRUE)
in a UTF-8 locale, and I'll add a workaround to the R sources.
Please do run your tests with R --vanilla and make sure they are
complete -- see the posting guide.
On Mon, 5 Jan 2009, Daniel Sabanés Bové wrote:
Dear Prof. Ripley,
I have discovered that my cat function cannot write more than 1
characters to a text file.
I think you meant *bytes*, BTW.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] cat cannot write more than 10000 characters? [R 2.8.1]
Thank you very much for your help and advice! Prof Brian Ripley schrieb: On Sun, 11 Jan 2009, Daniel Sabanés Bové wrote: Yes, I set the encoding to UTF-8 in my .Rprofile. Sorry that I didn't You really don't want to do that: it adds a considerable overhead and relies on a bug-free iconv The latest R-patched should work around this. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Firefox 3 and HTML Search
On 1/9/2009 11:59 AM, Duncan Murdoch wrote: I finally upgraded to Firefox 3.05 from 2.x, and now I can reproduce a bug a colleague has been complaining about but which I hadn't been able to reproduce before. In Windows, set Firefox as the default browser. Then in Rgui (seems to affect all versions up to R-devel), use the menu to open HTML Help, and choose Search Engine and Keywords. Enter a keyword (e.g. plot), and click on Search. Things are a lot slower than they used to be with Firefox 2, but eventually I get a result, starting out Search Results The search string was plot base-defunct Defunct Functions in Base Package expression Unevaluated Expressions However, the current URL is not the same as it was before: it is now listed as file:///RHOME/doc/html/index.html so the links don't work: they are entered as ../../../library/base/html/base-defunct.html, etc. in the source, and the expect the current directory to be file:///RHOME/doc/html/search/ If I set Internet Explorer as my default browser (yuck), things are fine, so this is a Firefox 3 bug, or a new Java bug, or an R bug that was masked before. Any suggestions of workarounds? As Brian and Marc pointed out, this is a Firefox 3.0 bug. As it turns out, it was repaired in November, but not approved for release in 3.0.5 or 3.0.6 (due this month??). I've been told it will make it into 3.0.7. For more on this, see https://bugzilla.mozilla.org/show_bug.cgi?id=445004 Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] x - 1:2; dim(x) - 2? A vector or not?
Ran into the follow intermediate case in an external package (w/ recent R v2.8.1 patched and R v2.9.0 devel): x - 1:2 dim(x) - 2 dim(x) [1] 2 x [1] 1 2 str(x) int [, 1:2] 1 2 nrow(x) [1] 2 ncol(x) [1] NA is.vector(x) [1] FALSE is.matrix(x) [1] FALSE is.array(x) [1] TRUE x[1] [1] 1 x[,1] Error in x[, 1] : incorrect number of dimensions x[1,] Error in x[1, ] : incorrect number of dimensions Is str() treating single-dimension arrays incorrectly? What does it mean to have a single dimension this way? Should it equal a vector? I am aware of is.vector returns FALSE if x has any attributes except names. /Henrik __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Package Matrix does not compile in R-devel_2009-01-10
Thank you Brian, for this detailed answer. I think you are right with the new rules. Before contacting the maintainers I will try to collect some more information about the observed failure. Without setting the environment variable MAKE to gmake, I get excatly the same break when installing Matrix under R-2.8.1. So I can test it under 2.8.1. Rainer On 11.01.2009 23:42 (UTC+1), Prof Brian Ripley wrote: You need to take this up with the package maintainers: although recommended packages are distributed with R, they are still contributed packages with separate maintainers. At one point Matrix did work with a non-GNU make (the Solaris one) after suggestions from R-core members on how to remove the obvious GNUisms. It would cetainly be helpful to let the package maintainers know what changes do work. (I presume the issue is amd_i_%.o: amd_%.c $(INC) $(CC) $(ALL_CPPFLAGS) $(ALL_CFLAGS) -I../Include -DDINT -c $ -o $@ amd_l_%.o: amd_%.c $(INC) $(CC) $(ALL_CPPFLAGS) $(ALL_CFLAGS) -I../Include -DDLONG -c $ -o $@ which are new rules since I was able to test.) Unfortunately I can no longer build Matrix (and hence R-devel) on Solaris, as the Sun Studio compilers say some of the C++ code is invalid (and it looks so to me, and I reported it a while back): the file is spqr_front.cpp, so it has not got as far as the point that is giving you trouble. On Sun, 11 Jan 2009, Rainer Hurling wrote: Dear developers, today I tried to build and install R-devel_2009-01-10 on FreeBSD 8.0-CURRENT (i386) for testing purposes. All went well until compiling the now recommended (integrated) Matrix package. At this point the following break occured: begin installing recommended package Matrix * Installing *source* package 'Matrix' ... ** libs gcc -std=gnu99 -I/usr/local/R-devel/include -I./UFconfig -I/usr/local/include -fpic -g -O2 -c CHMfactor.c -o CHMfactor.o [..snip..] gcc -std=gnu99 -I/usr/local/R-devel/include -I../Include -I../../UFconfig -I/usr/local/include-fpic -g -O2 -c colamd_global.c -o colamd_global.o gcc -std=gnu99 -I/usr/local/R-devel/include -I../Include -I../../UFconfig -I/usr/local/include-fpic -g -O2 -I../Include -DDLONG -c colamd.c -o colamd_l.o ar -rucs ../../COLAMD.a colamd_global.o colamd_l.o # colamd.o ( cd Source ; make lib ) gcc -std=gnu99 -I/usr/local/R-devel/include -I../Include -I../../UFconfig -I/usr/local/include-fpic -g -O2 -c amd_global.c -o amd_global.o make: don't know how to make amd_l_1.o. Stop *** Error code 2 Stop in /tmp/Rtmpx5nUS8/R.INSTALL10d63af1/Matrix/src/AMD. *** Error code 1 Stop in /tmp/Rtmpx5nUS8/R.INSTALL10d63af1/Matrix/src. ERROR: compilation failed for package 'Matrix' * Removing '/usr/local/R-devel/library/Matrix' *** Error code 1 Stop in /usr/local/R-devel/src/library/Recommended. *** Error code 1 Stop in /usr/local/R-devel/src/library/Recommended. *** Error code 1 Stop in /usr/local/R-devel. Please note, that on FreeBSD there is a BSD 'make' as default. If I want to use gmake instead, I explicitly have to set it. Unfortunately this does not work within building the whole R-devel system. It would be helpful to know why not. AFAIK GNU make works on other platforms with their own make. With R-2.8.1 I have no problems installing and using R. When I want to build the (external) Matrix package I have to set an environment variable to gmake, found at /usr/local/bin/gmake and all works well. Now my question: Is it possible to change the configure/build of the integrated Matrix package on R-devel? For all other packages there is no need to do so (at least for FreeBSD ;-) Please let me know if I can help. Thanks in advance, Rainer Hurling __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] irrelevant warning message
PS. Here are two interrelated reasons we don't autoconvert: 1. Subject id. Factors give no advantage for a unique id, and some clear problems. In particular when one creates as subset - everyone over 60 say - there is no good reason to remember all the ids you didn't select. 2. Subject id. I work on a lot of studies of fractures and fracture risk. A time-trend model might be gam(fracture ~ subject + x1 + x2 + ..., subset=(sex='F')) Fracture risk for males and females is so different that separate models are the sensible thing. If subject is a factor before the call, then my model has a zillion unneeded levels. There are other ways out of this issue, but avoiding factors is the easiest. 3. Factors take up more memory than character vectors. (This is tongue-in-cheek, but in recent versions of R, factor variables take up (very very slightly) more memory than character variables. It's a common myth that the opposite is true) I think R's handling of character vectors has progressed to the point where they should be the norm, not the exception. Maybe others will have different views. Hadley -- http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] irrelevant warning message
On 12/01/2009 6:12 PM, Terry Therneau wrote: Context: R version 2.7.1 (2008-06-23) I don't know when this was upgraded in the department, I just ran into the aberrent behavior today. Problem: Our group BY CHOICE does not change character variables into factors by default. I can get into a long arguement as to why later, and will give one example of why below. The default behavior of S, Splus and R has been to create dummy variables for factor, character, and logical variables. This is good. Why has R suddenly gotton a compulsion to put out a warning message for any model where we do this? I contend that it is I think you need to be more specific. I just tried x - sample(letters[1:4], 100, rep=T) y - rnorm(x) lm(y ~ x) and got a warning in all R versions I tried back to 2.4.1. In 2.3.1 this was an error. So I suspect the change you saw was to some other modelling function besides lm(), and I would guess that it came from making it consistent with lm(). But it would help if you told use which function, and which version you're comparing 2.7.1 with. Now, it probably does make sense to suppress that warning. I guess it was probably introduced because we used to give an error, and someone was being conservative and didn't think error-ful behaviour should go to accepted behaviour in one step. But maybe it's time for the second step. Duncan Murdoch - confusing - unnecessary - and wrong. It is certainly confusing, as it implies a behavior change when there has been no change. The fact that the factor command was used behind the scenes is irrelevant to anyone - who cares that HOW the rules are implemented. Is there going to soon be a message of WARNING: logical variable turned into numeric? It is the sensible next step. Wrong because the data element in question is not converted - not at the user level at least. It would be much more proper to say was treated as a factor by model.matrix; but that is a semantic issue. In any case- to the real question. 1.What is the easiest way to eliminate this? I would prefer not to have to change the source code and recompile the local versions. Because of namespaces it is not as easy as adding a repaired copy to our local library and loading it first. I remember some discussion about forcing a change into another name space but I've lost the link to it. I'll do this if we must, but it is such a hassle to keep updating the change with new releases of the package. It might still be less than dealing with the training/answer questions burden for our group, which is quite large. 2. Is there any hope of undoing this? Its only real impact is to annoy, and I've always disliked systems that preach at me. (Detested is more like it, I still remember how hard it was to delete certain files in Digital's TOPS os, which was sure you ``didn't actually want to do that''.) Allowing some global stop preaching option would be a fix, or in the same vein to have it look at the existing stringsAsFactors option for a this person knows so don't bother him hint. If this addition followed on some discussion, please point me to it. The reaction of other experienced users in our group has been the same, when I pointed this out. So I am not alone in the why? Terry Therneau PS. Here are two interrelated reasons we don't autoconvert: 1. Subject id. Factors give no advantage for a unique id, and some clear problems. In particular when one creates as subset - everyone over 60 say - there is no good reason to remember all the ids you didn't select. 2. Subject id. I work on a lot of studies of fractures and fracture risk. A time-trend model might be gam(fracture ~ subject + x1 + x2 + ..., subset=(sex='F')) Fracture risk for males and females is so different that separate models are the sensible thing. If subject is a factor before the call, then my model has a zillion unneeded levels. There are other ways out of this issue, but avoiding factors is the easiest. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
