Re: [Rd] Newbie Rccp module question. Failed to initialize module pointer???
Dirk, thanks for your reply. I posted my answer right away and went on vacation. My post was pending since then. Still cannot post, so I opened another profile -- maybe this time it gets through. To answer your questions, I run R-2.12.1 on 64 bit RedHat Linux on Xeon machine. What seems odd that the error message i am getting refers to .GlobalEnv package. The symbol it is looking for, _rcpp_module_boot_mod, is in shared library for my package, i checked it with nm. Is there any doc on how modules are implemented? -- View this message in context: http://r.789695.n4.nabble.com/Newbie-Rccp-module-question-Failed-to-initialize-module-pointer-tp3311388p3332652.html Sent from the R devel mailing list archive at Nabble.com. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] axis, title padj
Hi, I often use par(mex = 0.5) as an easy way to shrink space used for margins. However, I recently noticed that this leads to an asymmetry in the positioning of the x vs. y axis labels and xlab / ylab -- the x-axis labels are pushed into the tic-marks, while the y-axis labels look fine. A more extreme example: dev.new() par(mex=.1, mar=c(10,10,10,10)) plot(1:10) Tracking this down in the code, this effect appears to be arising from: 1) GMtext in graphics.c adjusts the margin line coordinate using dev-yLineBias. After commenting out these adjustments, the x-axis text is clearly shifted up (i.e. the bottom of the text is aligned at the specified margin line) while the y-axis text is shifted left (i.e. the bottom of the text is still aligned with the specified margin line). 2) This observation lead me to realize that do_axis and do_title in plot.c assume padj=0 most of the time (there are exceptions depending on par()$las). I'm no expert in the R code base, but the yLineBias adjustments appears like they might have been intended to restore symmetry -- but it only works for mex=1. Is there a reason why, instead of yLineBias, we can't either: 1) center axis and title text by default (i.e. padj=0.5) -or- 2) align side=1,3 with padj=1; side=2,4 with padj=0 ? Solution 1 is trivial to implement, but this would shift positioning slightly relative to the current code (even for mex=1). Solution 2 is slightly trickier because we have to pay attention to side and las values, but would not change the output for mex=1. I implemented drafts of both solutions, which work at least superficially. Two questions: -Am I missing a larger purpose to yLineBias? -Thoughts about which solution is better / can I contribute a patch to fix this? Regards, Philip __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] read.csv trap
Ben Bolker bbolker at gmail.com writes:
On 02/11/2011 03:37 PM, Laurent Gatto wrote:
On 11 February 2011 19:39, Ben Bolker bbolker at gmail.com wrote:
[snip]
Bump. Is there any opinion about this from R-core??
Will I be scolded if I submit this as a bug ... ??
What is dangerous/confusing is that R silently **wraps** longer lines if
fill=TRUE (which is the default for read.csv). I encountered this when
working with a colleague on a long, messy CSV file that had some phantom
extra fields in some rows, which then turned into empty lines in the
data frame.
[snip snip]
Here is an example and a workaround that runs count.fields on the
whole file to find the maximum column length and set col.names
accordingly. (It assumes you don't already have a file named test.csv
in your working directory ...)
I haven't dug in to try to write a patch for this -- I wanted to test
the waters and see what people thought first, and I realize that
read.table() is a very complicated piece of code that embodies a lot of
tradeoffs, so there could be lots of different approaches to trying to
mitigate this problem. I appreciate very much how hard it is to write a
robust and general function to read data files, but I also think it's
really important to minimize the number of traps in read.table(), which
will often be the first part of R that new users encounter ...
A quick fix for this might be to allow the number of lines analyzed
for length to be settable by the user, or to allow a settable 'maxcols'
parameter, although those would only help in the case where the user
already knows there is a problem.
cheers
Ben Bolker
===
writeLines(c(A,B,C,D,
1,a,b,c,
2,f,g,c,
3,a,i,j,
4,a,b,c,
5,d,e,f,
6,g,h,i,j,k,l,m,n),
con=file(test.csv))
read.csv(test.csv)
try(read.csv(test.csv,fill=FALSE))
## assumes header=TRUE, fill=TRUE; should be a little more careful
## with comment, quote arguments (possibly explicit)
## ... contains information about quote, comment.char, sep
Read.csv - function(fn,sep=,,...) {
colnames - scan(fn,nlines=1,what=character,sep=sep,...)
ncolnames - length(colnames)
maxcols - max(count.fields(fn,sep=sep,...))
if (maxcolsncolnames) {
colnames - c(colnames,paste(V,(ncolnames+1):maxcols,sep=))
}
## assumes you don't have any other columns labeled V[large number]
read.csv(fn,...,col.names=colnames)
}
Read.csv(test.csv)
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Problem building R-2.13 r54645 on Windows
I am building R-2.13 r54645 from source as described here: http://cran.r-project.org/doc/manuals/R-admin.html#Building-from-source The make all recommended command ends as follows on both 32 and 64-bit Windows (Windows Server 2003 R2 Enterprise Edition Service Pack 2 and Windows Server 2008 R2 Enterprise): gcc -std=gnu99 -I../../include -DHAVE_CONFIG_H -O3 -Wall -pedantic -c zutil.c -o z o make[4]: *** No rule to make target `Rzlib.def', needed by `Rzlib.dll'. Stop. make[3]: *** [rlibs] Error 1 make[2]: *** [../../bin/i386/R.dll] Error 2 make[1]: *** [rbuild] Error 2 make: *** [all] Error 2 Thanks Dan [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
