[Rd] Problem with LD_LIBRARY_PATH setting in ldpaths (PR#13637)
When using R on a linux machine (ubuntu 8.10) which DOES NOT have LD_LIBRARY_PATH set (I particularly have it NOT set because it causes problems), the script ldpaths will set LD_LIBRARY_PATH to the R Lib path (in my case $R_HOME/lib:). The placement of the colon makes my system think that the directory "." is also on that lib path. This causes real problems when trying to run R with a remote mounted file structure (over sshfs). In particular, the initialization time for R is about 20 seconds, and a simple command like help(package) takes about 10. It is easily amended by not placing the colon at the end of the lib path if it is empty first. Please fix this so other newbies don't have to spend a day and a half delving through strace output trying to figure out why everything is slow! --please do not edit the information below-- Version: platform = i486-pc-linux-gnu arch = i486 os = linux-gnu system = i486, linux-gnu status = major = 2 minor = 7.1 year = 2008 month = 06 day = 23 svn rev = 45970 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] actual argument matching does not conform to the definition (PR#13634)
> "vQ" == Wacek Kusnierczyk
> on Thu, 02 Apr 2009 15:25:14 +0200 writes:
vQ> Thomas Lumley wrote:
>>
>> The explanation is that quote() is a primitive function and that the
>> argument matching rules do not apply to primitives. That section of
>> the R Language definition should say that primitives are excluded; it
>> is documented in ?.Primitive.
vQ> thanks. indeed, the documentation -- the language *definition* --
vQ> should make this clear. so this is a bug in the definition, which does
vQ> not match the implementation, which in turn is as intended (right?)
vQ> ?.Primitive says:
vQ> " The advantage of '.Primitive' over '.Internal' functions is the
vQ> potential efficiency of argument passing. However, this is done
vQ> by ignoring argument names and using positional matching of
vQ> arguments (unless arranged differently for specific primitives
vQ> such as 'rep'), so this is discouraged for functions of more than
vQ> one argument.
vQ> "
vQ> what is discouraged?
Well...
Wacek, as seem to you want it, and it being Friday afternoon...
here comes
a biased view of one R hobby historian :
Even though R was created originally in New Zealand and then
heavily picked up in Europe slightly before (North) America,
the development model of R, in my eyes, has been closer to
sentiments of people from the land of the free and home of the
brave, rather than European censorship and dictatorship
{being a full-hearted European, I hope I'm allowed the slight
exaggeration ;-)}.
Consequently, there has always been quite a bit of freedom in R
development within the R core development team...
and yes, R is not the result of comittee design-process,
but yes, it's good we have members in the core team (and the
wider R developer base) who have called us to make decisions and
try to stand by them .. ;-) :-)
The frequent vs minimal use of .Primitives has been one of the
areas where some R-core members have tried to discourage other
R-core members from "doing too much" ..
Fact is that using *more* .Primitives rather than less during
the last few years has allowed to make S3 and S4 method
dispatch slightly more uniform and still efficient.
In the long term, ideally we'd diminuish the number of
.Primitives substantially, exactly for reasons some of which you
mention in this thread.
Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Problem building DLL under Windows
Apologies if this has appeared before, but I've searched the archives and all the documentation and I can't find anything which helps. I'm trying to build a DLL under windows. The process (more on that later) works fine under Linux and gives the illusion of working under Windows, but attempting to load the resulting DLL using dyn.load results in: Error in inDL(x, as.logical(local), as.logical(now), ...) : unable to load shared library: 'C:/Documents... ' LoadLibrary failure: Invalid access to memory location. Searching Google shows that the LoadLibrary message is unique to R (Or no-one else is admitting to it). The first problem is that the library is actually a wrapper around an existing library to make it usable under R, but the original library is built as a static object (and for reasons of controlling exciting versioning problems, I'd prefer it to stay that way). Under Linux, I pass the library to gcc using PKG_LIBS=-static lib.a and it builds fine. Under Windows, I put the following in Makevars.win: PKG_LIBS -Lc:/Path/To/Library -llib.name and it builds fine (GCC returns with no errors and I have what appears to be an appropriately sized DLL in the directory). I've tried passing various flags into gcc, but I really don't know what I'm doing at this point with regard to building under windows (I have a pretty good grasp of how to compile libraries under Linux, and understand the concepts involved in shared libraries. I get the impression however that I'm missing something about Windows DLLs. Compulsory version information: OS: Windows XP SP2 R: 2.8.1 GCC: 4.2.1-sjlj (mingw32-2) (From Rtools29.exe) For the record, I've read http://www.stats.uwo.ca/faculty/murdoch/software/compilingDLLs/readme.packages.txt which hints at some requirement for DLLs to use _cdecl. I've started exploring along this line, but there's a lot of documentation to trawl through to make sense of it all and I don't want to go off chasing a red herring if I just need to pass a special --make-it-work flag to gcc. In the only thread I found which appeared to have any similarities, Prof. Ripley said that there was a solution (or hint): "It is there, unfortunately along with a lot of uniformed speculation." Of course, the uninformed speculation is still in the archives making it no easier to find no than in August 2007! Perhaps someone who understands this stuff (or has some experience of it) could provide a hint as to how to proceed. :-) Thanks in advance. -- Jon Senior __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Possible bug in summary.survfit - 'scale' argument ignored?
On Apr 1, 2009, at 7:08 AM, Thomas Lumley wrote: I've sent a fixed version 2.35-4 to CRAN. It turned out to be a fairly simple change. -thomas Thomas, Apologies for the delay in my reply. I am on vacation and will only have sporadic e-mail access thru mid-next week. I noted the fix that you made and it is indeed pretty simple. I do have one comment/question however. It would seem that the nature of the interaction between the 'scale' and 'times' arguments has now changed with this update. Presumably as a result of the transform taking place at the beginning of the old version as opposed to being at the end of the new function. For example, using the prior version of survival included with R 2.8.1 (2.34-1): # Get the summary output in months (eg. days / 30.44) # Note that 'times' is in the 'scale' transformed based time interval (0:21 months) > summary( survfit( Surv(futime, fustat)~1, data=ovarian), scale = 30.44, times = 0:21) Call: survfit(formula = Surv(futime, fustat) ~ 1, data = ovarian) time n.risk n.event survival std.err lower 95% CI upper 95% CI 0 26 01.000 0.1.0001.000 1 26 01.000 0.1.0001.000 2 25 10.962 0.03770.8901.000 3 25 00.962 0.03770.8901.000 4 24 10.923 0.05230.8261.000 5 24 00.923 0.05230.8261.000 6 23 10.885 0.06270.7701.000 7 23 00.885 0.06270.7701.000 8 23 00.885 0.06270.7701.000 9 22 10.846 0.07080.7180.997 10 22 00.846 0.07080.7180.997 11 21 10.808 0.07730.6700.974 12 19 20.731 0.08700.5790.923 13 18 00.731 0.08700.5790.923 14 17 00.731 0.08700.5790.923 15 15 10.688 0.09190.5290.894 16 12 20.596 0.09990.4290.828 17 12 00.596 0.09990.4290.828 18 12 00.596 0.09990.4290.828 19 11 10.546 0.10320.3770.791 20 11 00.546 0.10320.3770.791 21 10 10.497 0.10510.3280.752 However, in the new version: > summary( survfit( Surv(futime, fustat)~1, data=ovarian), scale = 30.44, times = 0:21) Call: survfit(formula = Surv(futime, fustat) ~ 1, data = ovarian) time n.risk n.event survival std.err lower 95% CI upper 95% CI 0. 26 01 011 0.0329 26 01 011 0.0657 26 01 011 0.0986 26 01 011 0.1314 26 01 011 0.1643 26 01 011 0.1971 26 01 011 0.2300 26 01 011 0.2628 26 01 011 0.2957 26 01 011 0.3285 26 01 011 0.3614 26 01 011 0.3942 26 01 011 0.4271 26 01 011 0.4599 26 01 011 0.4928 26 01 011 0.5256 26 01 011 0.5585 26 01 011 0.5913 26 01 011 0.6242 26 01 011 0.6570 26 01 011 0.6899 26 01 011 It would appear that 'times' are 0:21 days, but as fractions of a month: > (0:21) / 30.44 [1] 0. 0.03285151 0.06570302 0.09855453 0.13140604 0.16425756 [7] 0.19710907 0.22996058 0.26281209 0.29566360 0.32851511 0.36136662 [13] 0.39421813 0.42706965 0.45992116 0.49277267 0.52562418 0.55847569 [19] 0.59132720 0.62417871 0.65703022 0.68988173 To get the same output as in the prior version: > summary( survfit( Surv(futime, fustat)~1, data=ovarian), scale = 30.44, times = (0:21) * 30.44) Call: survfit(formula = Surv(futime, fustat) ~ 1, data = ovarian) time n.risk n.event survival std.err lower 95% CI upper 95% CI 0 26 01.000 0.1.0001.000 1 26 01.000 0.1.0001.000
Re: [Rd] Problem building DLL under Windows
Jon, On Apr 3, 2009, at 10:18 , Jon Senior wrote: Apologies if this has appeared before, but I've searched the archives and all the documentation and I can't find anything which helps. I'm trying to build a DLL under windows. The process (more on that later) works fine under Linux and gives the illusion of working under Windows, but attempting to load the resulting DLL using dyn.load results in: Error in inDL(x, as.logical(local), as.logical(now), ...) : unable to load shared library: 'C:/Documents... ' LoadLibrary failure: Invalid access to memory location. Searching Google shows that the LoadLibrary message is unique to R (Or no-one else is admitting to it). The first problem is that the library is actually a wrapper around an existing library to make it usable under R, but the original library is built as a static object (and for reasons of controlling exciting versioning problems, I'd prefer it to stay that way). Under Linux, I pass the library to gcc using PKG_LIBS=-static lib.a and it builds fine. That is true only for very specific architectures and OS combinations but not on most systems (including Linux). Shared objects must be compiled to contain position-independent code (PIC) such that they can be re-located when loaded dynamically. In general you cannot use a static library in a package unless the library was specifically compiled with -fPIC. Also please note that the above is possibly not what you want: -static is not an option that applies to the library - it's a global option for the linker which affects *all* libraries and possibly even the crt code and compiler-related libraries (this depends on the platform). It may cause additional problems since you may need to link R library dynamically. All this is not related to Windows - this applies in general on any platform (including Linux). Under Windows, I put the following in Makevars.win: PKG_LIBS -Lc:/Path/To/Library -llib.name and it builds fine (GCC returns with no errors and I have what appears to be an appropriately sized DLL in the directory). I've tried passing various flags into gcc, but I really don't know what I'm doing at this point with regard to building under windows (I have a pretty good grasp of how to compile libraries under Linux, and understand the concepts involved in shared libraries. I get the impression however that I'm missing something about Windows DLLs. See above, this may not be DLL-specific. Additionally, please make sure you're using the right tools (MinGW gcc) for both your static library and the package (you have indicated the you do, but just making sure :)).. I have tested a toy example with your setup and all was working just fine, so for further help you may have to reveal exactly what library you are using etc. since the devil may be in the details (if the general advice above doesn't help). Compulsory version information: OS: Windows XP SP2 R: 2.8.1 GCC: 4.2.1-sjlj (mingw32-2) (From Rtools29.exe) For the record, I've read http://www.stats.uwo.ca/faculty/murdoch/software/compilingDLLs/readme.packages.txt which hints at some requirement for DLLs to use _cdecl. I've started exploring along this line, but there's a lot of documentation to trawl through to make sense of it all and I don't want to go off chasing a red herring if I just need to pass a special --make-it-work flag to gcc. AFAICS that is only mentioned with respect to VC - the current tools are smart enough with gcc. There are some issues when importing variables from R itself, but that should not be related to your code (unless you use this feature outside of the standard R headers). Cheers, Simon In the only thread I found which appeared to have any similarities, Prof. Ripley said that there was a solution (or hint): "It is there, unfortunately along with a lot of uniformed speculation." Of course, the uninformed speculation is still in the archives making it no easier to find no than in August 2007! Perhaps someone who understands this stuff (or has some experience of it) could provide a hint as to how to proceed. :-) Thanks in advance. -- Jon Senior __ 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
[Rd] Error in par(split.screens[[n]]) : parameter "i" in "mfg" is out of range
I'm working on my 'oce' package, trying split.screen() instead of par(mfrow). My code is too long to post, and I hope it's ok that I ask this question without doing so. My code seems to work fine when I source() it, but when I do "R CMD check" on my package, I get the error that I've put as the subject line, when it runs examples. If I comment out the plot() commands from my examples, and build the package, then I can run those examples (with the plot() uncommented) from the commandline, with no problems. And I can run them from the console. I don't actually understand the error, although I can see that it is occurring in a call to screen(). Has anyone else run across this? Is there a trick I should employ, e.g. making my package depend on the graphics package or setting up a virtual device of some type for use in the building process? PS. This is on OS X with the 2.8.1 version of R. -- View this message in context: http://www.nabble.com/Error-in-par%28split.screens--n--%29-%3A-parameter-%22i%22-in-%22mfg%22-is-out-of-range-tp22873439p22873439.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
Re: [Rd] Problem building DLL under Windows
On Fri, 3 Apr 2009 12:36:00 -0400 Simon Urbanek wrote: > That is true only for very specific architectures and OS combinations > but not on most systems (including Linux). Shared objects must be > compiled to contain position-independent code (PIC) such that they can > be re-located when loaded dynamically. In general you cannot use a > static library in a package unless the library was specifically > compiled with -fPIC. It was indeed compiled with -fPIC on Linux. I had forgotten that and wonder if it might be related. > Also please note that the above is possibly not what you want: -static > is not an option that applies to the library - it's a global option > for the linker which affects *all* libraries and possibly even the crt > code and compiler-related libraries (this depends on the platform). It > may cause additional problems since you may need to link R library > dynamically. All this is not related to Windows - this applies in > general on any platform (including Linux). AFAICT -static can be used to force inclusion of a library statically. It may not be the case, the bulk of my coding experience is in Java, not wrapping esoteric functions in to R-callable C code! :-) Strangely though, it seems to work fine. I'll have to do some more tinkering to see if it can forced into a single build, rather than a 2-stage one. > See above, this may not be DLL-specific. Additionally, please make > sure you're using the right tools (MinGW gcc) for both your static > library and the package (you have indicated the you do, but just > making sure :)).. Checked and doubled checked. It's a clean installation of XP running under QEMU and has nothing but R and Rtools installed. > I have tested a toy example with your setup and all was working just > fine, so for further help you may have to reveal exactly what library > you are using etc. since the devil may be in the details (if the > general advice above doesn't help). OK. Since my previous mail, I discovered the pedump tool, and found that both pedump and objdump will segfault (So it appears, Windoze doesn't give enough information to be sure!) if I attempt to retrieve the Ordinal table from the freshly compiled DLL. This suggests that something is going awry during the second stage of the build (since I can retrieve the same information from the .lib file). The problem with adding more details is the nature of the work. At the minute, I'm obliged to keep the fine details secret. I had a feeling that this might have been the case, but I thought it was worth seeing if someone had already encountered this and solved it in a different specific case. > AFAICS that is only mentioned with respect to VC - the current tools > are smart enough with gcc. There are some issues when importing > variables from R itself, but that should not be related to your code > (unless you use this feature outside of the standard R headers). OK. Thanks for your help. Looks like the next step is probably going to be combining both compilation steps into a single Makefile. I really hate Makefiles! :-( -- Jon Senior __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] RGoogleDocs so close but errors with spreadsheet reading
I went through the installation process using what you had in the prerelease. Unofortunately I am still getting Error in checkSlotAssignment(object, name, value) : assignment of an object of class "NULL" is not valid for slot "access" in an object of class "GoogleSpreadsheet"; is(value, "character") is not TRUE Could you please run a script that gets you in and post it and its output here. I would like to see verbatim how you are getting it to work. Obviously x out your password. Is their anything I could do that would provide insight into what is going wrong? Farrel Buchinsky Google Voice Tel: (412) 567-7870 On Wed, Apr 1, 2009 at 21:15, Duncan Temple Lang wrote: > > You might try my development version which I put at > > http://www.omegahat.org/Prerelease/RGoogleDocs_0.2-0.tar.gz > > I am not certain if there are any substantive differences with the > one in the Omegahat repository, but it works for me with a document > and a spreadsheet in an Google Docs account. > > D. > > Farrel Buchinsky wrote: > >> I got RGoogleDocs to work. It works on documents but not on spreadsheets. >> I get the following error. >> >> getDocs(con, what >> ="http://docs.google.com/feeds/documents/private/full/-/spreadsheet";) >> >> assignment of an object of class "NULL" is not valid for slot "access" >> in an object of class "GoogleSpreadsheet"; is(value, "character") is >> not TRUE >> >> How can I troubleshoot this? >> >> Farrel Buchinsky >> Google Voice Tel: (412) 567-7870 >> >> Sent from Pittsburgh, Pennsylvania, United States >> >> __ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Error in par(split.screens[[n]]) : parameter "i" in "mfg" is out of range
As a followup, in case this is of use to others, I got my code working by
altering R-2.8.1/src/library/graphics/R/screen.R slightly, removing the sole
reference to "mfg", as follows.
assign("par.list",
c("xlog","ylog",
"adj", "bty", "cex", "col", "crt", "err", "font", "lab",
"las", "lty", "lwd", "mar", "mex",
##"mfg",
"mgp", "pch",
"pty", "smo", "srt", "tck", "usr", "xaxp", "xaxs", "xaxt", "xpd",
"yaxp", "yaxs", "yaxt", "fig"), envir=.SSenv)
--
View this message in context:
http://www.nabble.com/Error-in-par%28split.screens--n--%29-%3A-parameter-%22i%22-in-%22mfg%22-is-out-of-range-tp22873439p22878253.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
