[Rd] R Console preference pane has the blues (PR#11466)
Full_Name: Ryan Lovett Version: 2.7.0 OS: Mac OS X 10.5.2 Submission from: (NULL) (128.32.135.6) Each of the six color selection buttons in the Console preference pane revert to blue after attempting to modify the color. The Defaults button and Transparency slider do work. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Missing gfortran man page (PR#11465)
Full_Name: Ryan Lovett Version: 2.7.0 OS: Mac OS X 10.5.2 Submission from: (NULL) (128.32.135.6) The gfortran package for Mac OS X is missing a man page. It does have an .info file but I think a man page would still be useful for those who use R's gfortran. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] 2.3 issues on Mac (PR#8915)
/Library/Frameworks/R.framework/Versions/2.3/Resources/etc/ppc/Renviron and /Library/Frameworks/R.framework/Versions/2.3/Resources/etc/i386/Renviron both use /usr/local/teTeX/bin/powerpc-apple-darwin-current for LaTeX related variables. Could this be updated for i386 to take into account the teTeX intel binaries? Also, Makeconf is not setup to create universal binary libraries. Will this be done at some point? Lastly, R.mpkg crashes Apple's Remote Desktop 2.2 when installing on a client. I was wondering if anyone else sees this? Thanks, Ryan __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] 2.3 issues on Mac (PR#8916)
Full_Name: Ryan Lovett Version: 2.3.0 OS: Mac OS X 10.4 Submission from: (NULL) (128.32.135.41) /Library/Frameworks/R.framework/Versions/2.3/Resources/etc/ppc/Renviron and /Library/Frameworks/R.framework/Versions/2.3/Resources/etc/i386/Renviron both use /usr/local/teTeX/bin/powerpc-apple-darwin-current for LaTeX related variables. Could this be updated for i386 to take into account the teTeX intel binaries? Also, Makeconf is not setup to create universal binary libraries. Will this be done at some point? Lastly, R.mpkg crashes Apple's Remote Desktop 2.2 when installing on a client. I was wondering if anyone else sees this? __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] should base R have a piping operator ?
Is there some concrete example of your “many workflows don’t even make much
sense without pipes nowadays” comment?
I don’t think I’m opposed to pipes in the absolute, but as I am now deep
into my second decade of using R I’ve done just fine without them. As I
would guess have the vast majority of users and code that is used
throughout the world.
Jeff
On Sat, Oct 5, 2019 at 09:34 Ant F wrote:
> Dear R-devel,
>
> The most popular piping operator sits in the package `magrittr` and is used
> by a huge amount of users, and imported /reexported by more and more
> packages too.
>
> Many workflows don't even make much sense without pipes nowadays, so the
> examples in the doc will use pipes, as do the README, vignettes etc. I
> believe base R could have a piping operator so packages can use a pipe in
> their code or doc and stay dependency free.
>
> I don't suggest an operator based on complex heuristics, instead I suggest
> a very simple and fast one (>10 times than magrittr in my tests) :
>
> `%.%` <- function (e1, e2) {
> eval(substitute(e2), envir = list(. = e1), enclos = parent.frame())
> }
>
> iris %.% head(.) %.% dim(.)
> #> [1] 6 5
>
> The difference with magrittr is that the dots must all be explicit (which
> sits with the choice of the name), and that special magrittr features such
> as assignment in place and building functions with `. %>% head() %>% dim()`
> are not supported.
>
> Edge cases are not surprising:
>
> ```
> x <- "a"
> x %.% quote(.)
> #> .
> x %.% substitute(.)
> #> [1] "a"
>
> f1 <- function(y) function() eval(quote(y))
> f2 <- x %.% f1(.)
> f2()
> #> [1] "a"
> ```
>
> Looking forward for your thoughts on this,
>
> Antoine
>
> [[alternative HTML version deleted]]
>
> __
> 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] How do you make a formal "feature" request?
The *user* decides. That would be YOU. Unlike SAS no one has a responsibility to YOU to implement some random request. Packages are how things are implemented. And to continue a previous thread ... maybe you should RTFM. Jeff On Sat, Aug 21, 2010 at 10:41 AM, Donald Winston wrote: > Who decides what features are in R and how they are implemented? If there is > someone here who has that authority I have this request: > > A report() function analogous to the plot() function that makes it easy to > generate a report from a table of data. This should not be in some auxiliary > package, but part of the core R just like plot(). As a long time SAS user I > cannot believe R does not have this. Please don't give me any crap about > Sweave, LaTex, and the "power" of R to roll your own. You don't have to "roll > your own" plot do you? Reports are no different. If you don't agree do not > bother me. If you agree then please bring this request to the appropriate > authorities for consideration or tell me how to do it. > > Thanks. > [[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Jeffrey Ryan jeff.a.r...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Stats not loaded? Method for as.ts() results in error
Janko, You don't mention if you are using S3 or S4. A small example would make it easier to identify where your problem is. Jeff On Fri, Sep 3, 2010 at 4:44 AM, Janko Thyson wrote: > Dear list, > > > > I've got the following problem: > > > > In a package I'm trying to build, there exists a method for the function > "as.ts()". When checking the package, R always throws the error that it > cannot find a function called "as.ts". To me it seems that the package > "stats" (home of "as.ts()") is not loaded during the checking process even > though it's a base package. For testing, I've written a method for "plot()" > to see if it's a general problem with base-functions, but this one passes > just fine. > > > > Did anyone of encounter a similar problem or could help me out with a hint? > > > > Thank you very much, > > Janko > > > > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > > -- Jeffrey Ryan jeff.a.r...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Strange behaviour of read and writeBin
from ?seek
‘seek’ returns the current position (before any move), as a
(numeric) byte offset from the origin, if relevant, or ‘0’ if not.
Your string is nul terminated (9 bytes long). That would be the
current offset. If you only read one byte, you'd have to be more than
0 bytes offset.
Jeff
On Fri, Feb 4, 2011 at 4:35 AM, Christian Ruckert
wrote:
> To me it seems like writeBin() writes one char/byte more than expected.
>
>> con <- file("testbin", "wb")
>> writeBin("ttccggaa", con)
>> close(con)
>
>> con <- file("testbin", "rb")
>> readBin(con, what="character")
> [1] "ttccggaa"
>> seek(con, what=NA)
> [1] 9
>> close(con)
>
>> con <- file("testbin", "rb")
>> readBin(con, what="raw", n=20)
> [1] 74 74 63 63 67 67 61 61 00
>> seek(con, what=NA)
> [1] 9
>> close(con)
>
> As the numbering starts with 0 the position should be 8 and not 9 after
> reading. There were two older threads which look very similar to my problem:
>
> http://tolstoy.newcastle.edu.au/R/e2/devel/06/11/1119.html
> http://r.789695.n4.nabble.com/Re-Problem-reading-binaries-created-with-fortran-More-infos-td974396.html
>
> Thanks in advance,
> Christian
>
>
>
>> sessionInfo()
> R version 2.12.0 (2010-10-15)
> Platform: x86_64-pc-linux-gnu (64-bit)
>
> locale:
> [1] C
>
> attached base packages:
> [1] stats graphics grDevices utils datasets methods base
>
> other attached packages:
> [1] Biostrings_2.18.2 IRanges_1.8.8
>
> loaded via a namespace (and not attached):
> [1] Biobase_2.10.0
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Jeffrey Ryan
jeffrey.r...@lemnica.com
www.lemnica.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] terribly annoying bug with POSIXlt : one o'clock is midnight?
Much of TZ-hell (I almost dare say all) has been sorted through in xts. http://cran.r-project.org/web/packages/xts/index.html Peruse the sources for inspiration or just take some comfort in that you are not the only one ;-) Jeff On Fri, Feb 4, 2011 at 9:24 AM, Joris Meys wrote: > Been too fast : I am in Central European Time (GMT +1), which explains > the time conversion. Still, I find it highly annoying that as.POSIXlt > assumes that the time is given in GMT and has to be converted to > whatever timezone you're in if you don't specify anything. > > Probably this behaviour is not going to be changed, but it's causing > very hard-to-track-down bugs nonetheless. > > Cheers > Joris > > On Fri, Feb 4, 2011 at 4:21 PM, Joris Meys wrote: >> Apparently, as.POSIXlt takes one o'clock as the start of the day : >> >>> as.POSIXlt(0,origin="1970-01-01") >> [1] "1970-01-01 01:00:00 CET" >>> as.POSIXlt(0,origin="1970-01-01 00:00:00") >> [1] "1970-01-01 01:00:00 CET" >>> as.POSIXlt(0,origin="1970-01-01 23:59:59") >> [1] "1970-01-02 00:59:59 CET" >> >> Cheers >> >> >> >> -- >> Joris Meys >> Statistical consultant >> >> Ghent University >> Faculty of Bioscience Engineering >> Department of Applied mathematics, biometrics and process control >> >> tel : +32 9 264 59 87 >> joris.m...@ugent.be >> --- >> Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php >> > > > > -- > Joris Meys > Statistical consultant > > Ghent University > Faculty of Bioscience Engineering > Department of Applied mathematics, biometrics and process control > > tel : +32 9 264 59 87 > joris.m...@ugent.be > --- > Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Jeffrey Ryan jeffrey.r...@lemnica.com www.lemnica.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] matching symbols to objects
Patrick, Take a look at all.vars to start with That will return the vars as characters, from there you can use get to test/proceed. > all.vars(parse.tree) [1] "x" Best, Jeff On Fri, Feb 4, 2011 at 1:37 PM, Patrick Leyshock wrote: > Hello, > > I'm trying to access an object, given only its name as a symbol. I cannot > figure out how to proceed. Suppose I call substitute( ) on the expression > 'x + 2': > >> parse.tree <- substitute(x + 2); > > The constituents of parse.tree are of type symbol and numeric: > >> str(parse.tree[[1]]) > symbol + > >> str(parse.tree[[2]]) > symbol x > >> str(parse.tree[[3]]) > num 2 > > Suppose that x is S4 object, and that I need to access a slot of that > object. How can I do so, using only 'parse.tree' (or parse.tree coerced > into a list)? > > Thanks, Patrick > > [[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Jeffrey Ryan jeffrey.r...@lemnica.com www.lemnica.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] manipulating the Date & Time classes
Firstly, don't double post. On Tue, Feb 8, 2011 at 2:24 PM, Mike Williamson wrote: > Hello, > > This is mostly to developers, but in case I missed something in my > literature search, I am sending this to the broader audience. > > > - Are there any plans in the works to make "time" classes a bit more > friendly to the rest of the "R" world? I am not suggesting to allow for > fancy functions to manipulate times, per se, or to figure out how to > properly "add" times or anything complicated. Just some fixes to make it > easier to work with the "time" classes. Here is a sampling of some strange > bugs with the time classes that, to my knowledge, don't exist with any other > core classes: > 1. you cannot "unlist" a time without losing the class. E.g., if you > unlist "2010-12-14 20:25:40" (POSIXct), you get "1292387141", at > least on my > OS & with my time zone. Regardless of the exact number, unlisting a time > class converts it to a numeric. You didn't say what your OS is, but two things spring to mind. Why are you calling 'unlist' on an object that isn't a list and ... "it works for me": > unlist(Sys.time()) [1] "2011-02-08 14:46:24.262146 CST" > - upon converting to a numeric, it seems there is an underlying, > assumed origin of "1970-01-01 00:00:00". However, this same > assumption does > not underlie the conversion *back* to a POSIX time, e.g., through > as.POSIXct() function. Therefore, whenever a time is "accidentally" > converted to a numeric, I have to force it back to a time through > as.POSIXct(), *providing my own details* as to the origin. There > is no easy way to find the underlying origin. This makes me > nervous for any > persistent functions I create. If the underlying origin ever > changes, then > all this code will be inaccurate. Maybe the origin will > never change, but > regardless it makes more sense to allow for the same underlying origin > default for "as.POSIXct" that is used when unlisting, or > similar activities > that force the time into a numeric. If it is just numeric, it shouldn't have any attribute and since the origin isn't global, you're sort of stuck. You can keep track of it yourself, or just leave it as the standard unix epoch. > 2. you cannot perform functions that otherwise seem trivial, such > as a "max" or "min". I understand why, for instance, adding is > hard. But > what about max or min? Greater than or less than are possible, as is > order(). I have my own simple scripts using these 2 functions > in order to > create a "max" & "min" for times, but it would be nice to have something > vetted & official. > > min(Sys.time()+1:10) [1] "2011-02-08 14:59:26.40236 CST" > max(Sys.time()+1:10) [1] "2011-02-08 14:59:36.762224 CST" Again, works for me. R.version _ platform x86_64-apple-darwin10.2.0 arch x86_64 os darwin10.2.0 system x86_64, darwin10.2.0 status major 2 minor 12.0 year 2010 month 10 day15 svn rev53317 language R version.string R version 2.12.0 (2010-10-15) > > If others could chime in with any strange behaviors they've seen in > working with times, maybe we could get a critical mass of issues that are > worthy of an overhaul. > > Thanks & Regards, > Mike > > > "Telescopes and bathyscaphes and sonar probes of Scottish lakes, > Tacoma Narrows bridge collapse explained with abstract phase-space maps, > Some x-ray slides, a music score, Minard's Napoleanic war: > The most exciting frontier is charting what's already here." > -- xkcd > > -- > Help protect Wikipedia. Donate now: > http://wikimediafoundation.org/wiki/Support_Wikipedia/en > > [[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Jeffrey Ryan jeffrey.r...@lemnica.com www.lemnica.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Writting my own package - 64 bit problem with R_GetCCallable
Hello list,
I've been working on a package of my own. It works fine on the 32bit
linux machines that I've tested it on. Someone using 64bit ubuntu
wanted to try it, and surprising segfaults happened. My test code
results in no segfault, errors, or leaks from my calls when run under
valgrind (I recompiled R with the level 2 valgrind instruments). R
and packages are compiled from source, so this is hopefully not a
debian/ubuntu issue. I'm totally stumped and hoping that this is a
silly / common 32 to 64 bit transition issue.
The problem seems to come when I attempt to access a function
registered by the Matrix package. During compilation (on 64 bit only)
I get the ominous:
--
slim_stolen_from_matrix.c: In function ‘R_as_cholmod_sparse’:
slim_stolen_from_matrix.c:36: warning: implicit declaration of
function ‘R_GetCCallable’
slim_stolen_from_matrix.c:36: warning: cast to pointer from integer of
different size
--
The function in question is an identical copy of Matrix's
M_as_cholmod_sparse, reproduced below
--
CHM_SP
R_as_cholmod_sparse(CHM_SP ans, SEXP x, Rboolean check_Udiag, Rboolean
sort_in_place)
{
static CHM_SP(*fun)(CHM_SP,SEXP,Rboolean,Rboolean)= NULL;
if(fun == NULL)
fun = (CHM_SP(*)(CHM_SP,SEXP,Rboolean,Rboolean))
R_GetCCallable("Matrix", "as_cholmod_sparse");
return fun(ans, x, check_Udiag, sort_in_place);
}
--
I made this duplicate function since using Matrix's #include stubs
conflicts with my copy of the CHOLMOD library (I need some functions
Matrix doesn't make public).
When run, the code gives the following segfault when it reaches te
first call to that function:
--
Program received signal SIGSEGV, Segmentation fault.
0xf54314e2 in ?? ()
*** caught segfault ***
address 0xf54314e2, cause 'memory not mapped'
--
As mentioned above, under valgrind the segault doesn't happen, but in
GDB, the function pointer can be seen to have some problem. In 64 bit
--
35 fun = (CHM_SP(*)(CHM_SP,SEXP,Rboolean,Rboolean))
(gdb) p fun
$1 = (CHM_SP (*)(CHM_SP, SEXP, Rboolean, Rboolean)) 0
(gdb) n
37 return fun(ans, x, check_Udiag, sort_in_place);
(gdb) p fun
$2 = (CHM_SP (*)(CHM_SP, SEXP, Rboolean, Rboolean)) 0xf54314e2
--
vs 32bit
--
(gdb) p fun
$1 = (CHM_SP (*)(CHM_SP, SEXP, Rboolean, Rboolean)) 0xb72a3ec0
--
I've never done 64 bit development, so I don't know what I've probably
done wrong. I don't see an intermediate cast to an int to mess it up.
Checking the pointer sizeof's seems like R_GetCCallable's return
should be the same size as the function pointer.
--
(gdb) p sizeof(void*)
$5 = 8
(gdb) p sizeof(CHM_SP*)
$6 = 8
(gdb) p sizeof(CHM_SP)
$7 = 8
(gdb) p sizeof(SEXP)
$8 = 8
(gdb) p sizeof(CHM_SP(*))
$9 = 8
(gdb) p sizeof(DL_FUNC)
$10 = 8
(gdb) p sizeof(DL_FUNC*)
$11 = 8
--
The function is invoked by
--
fitholder->Zt = R_as_cholmod_sparse
((CHM_SP)malloc(sizeof(cholmod_sparse)), Zt, TRUE, FALSE);
---
where Zt is a SEXP pointing to a Matrix-class sparse matrix passed by
.Call from R. CHM_SP is a typedef'd pointer to a cholmod_sparse
> sessionInfo()
R version 2.12.1 (2010-12-16)
Platform: x86_64-unknown-linux-gnu (64-bit)
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
[3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
[5] LC_MONETARY=C LC_MESSAGES=en_US.UTF-8
[7] LC_PAPER=en_US.UTF-8 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] emmpat_0.001 Matrix_0.999375-46 lattice_0.19-13
loaded via a namespace (and not attached):
[1] grid_2.12.1
Ryan King
University of Chicago
Dept. Health Studies
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Writting my own package - 64 bit problem with R_GetCCallable
Ah thanks, that did fix it.
Ryan King
On Fri, Feb 11, 2011 at 3:53 PM, Simon Urbanek
wrote:
> Ryan,
>
> On Feb 11, 2011, at 4:29 PM, Ryan King wrote:
>
>> Hello list,
>> I've been working on a package of my own. It works fine on the 32bit
>> linux machines that I've tested it on. Someone using 64bit ubuntu
>> wanted to try it, and surprising segfaults happened. My test code
>> results in no segfault, errors, or leaks from my calls when run under
>> valgrind (I recompiled R with the level 2 valgrind instruments). R
>> and packages are compiled from source, so this is hopefully not a
>> debian/ubuntu issue. I'm totally stumped and hoping that this is a
>> silly / common 32 to 64 bit transition issue.
>>
>> The problem seems to come when I attempt to access a function
>> registered by the Matrix package. During compilation (on 64 bit only)
>> I get the ominous:
>>
>> --
>> slim_stolen_from_matrix.c: In function ‘R_as_cholmod_sparse’:
>> slim_stolen_from_matrix.c:36: warning: implicit declaration of
>> function ‘R_GetCCallable’
>> slim_stolen_from_matrix.c:36: warning: cast to pointer from integer of
>> different size
>
>
> This is the key issue - you're missing the declaration of R_GetCCallable() as
> the compiler tells you, so the compiler assumes "int" as the return value.
> However, int is only 32-bit so it won't hold a 64-bit pointer and hence
> you're in trouble.
>
> All you really need is
>
> #include
>
> before you use R_GetCCallable and hopefully your issues should go away.
>
> Note that your bug is there even in 32-bit -- you will see " implicit
> declaration of function" in any case -- it just is not fatal, incidentally.
> It is a good idea to listen to the compiler ... ;).
>
> Cheers,
> Simon
>
>
>> --
>>
>> The function in question is an identical copy of Matrix's
>> M_as_cholmod_sparse, reproduced below
>>
>> --
>> CHM_SP
>> R_as_cholmod_sparse(CHM_SP ans, SEXP x, Rboolean check_Udiag, Rboolean
>> sort_in_place)
>> {
>> static CHM_SP(*fun)(CHM_SP,SEXP,Rboolean,Rboolean)= NULL;
>> if(fun == NULL)
>> fun = (CHM_SP(*)(CHM_SP,SEXP,Rboolean,Rboolean))
>> R_GetCCallable("Matrix", "as_cholmod_sparse");
>> return fun(ans, x, check_Udiag, sort_in_place);
>> }
>> --
>>
>> I made this duplicate function since using Matrix's #include stubs
>> conflicts with my copy of the CHOLMOD library (I need some functions
>> Matrix doesn't make public).
>>
>> When run, the code gives the following segfault when it reaches te
>> first call to that function:
>>
>> --
>> Program received signal SIGSEGV, Segmentation fault.
>> 0xf54314e2 in ?? ()
>> *** caught segfault ***
>> address 0xf54314e2, cause 'memory not mapped'
>> --
>>
>> As mentioned above, under valgrind the segault doesn't happen, but in
>> GDB, the function pointer can be seen to have some problem. In 64 bit
>> --
>> 35 fun = (CHM_SP(*)(CHM_SP,SEXP,Rboolean,Rboolean))
>> (gdb) p fun
>> $1 = (CHM_SP (*)(CHM_SP, SEXP, Rboolean, Rboolean)) 0
>> (gdb) n
>> 37 return fun(ans, x, check_Udiag, sort_in_place);
>> (gdb) p fun
>> $2 = (CHM_SP (*)(CHM_SP, SEXP, Rboolean, Rboolean)) 0xf54314e2
>> --
>>
>> vs 32bit
>> --
>> (gdb) p fun
>> $1 = (CHM_SP (*)(CHM_SP, SEXP, Rboolean, Rboolean)) 0xb72a3ec0
>>
>> --
>>
>> I've never done 64 bit development, so I don't know what I've probably
>> done wrong. I don't see an intermediate cast to an int to mess it up.
>> Checking the pointer sizeof's seems like R_GetCCallable's return
>> should be the same size as the function pointer.
>>
>> --
>> (gdb) p sizeof(void*)
>> $5 = 8
>> (gdb) p sizeof(CHM_SP*)
>> $6 = 8
>> (gdb) p sizeof(CHM_SP)
>> $7 = 8
>> (gdb) p sizeof(SEXP)
>> $8 = 8
>> (gdb) p sizeof(CHM_SP(*))
>> $9 = 8
>> (gdb) p sizeof(DL_FUNC)
>> $10 = 8
>> (gdb) p sizeof(DL_FUNC*)
>> $11 = 8
>> --
>>
>> The function is invoked by
>> --
>> fitholder->Zt = R_as_cholmod_sparse
>> ((CHM_SP)malloc(sizeof(cholmod_sparse)), Zt, TRUE, FALSE);
>> ---
>>
>> where Zt is a SEXP pointing to a Matrix-c
Re: [Rd] Request: Suggestions for "good teaching" packages, esp. with C code
I think for teaching, you need to use R itself. Everything else is going to be a derivative from that, and if you are looking for 'correctness' or 'consistency' with the spirit of R, you can only be disappointed - as everyone will take liberties or bring personal style into the equation. In addition, your points are debatable in terms of priority/value. e.g. what is wrong with 'return'? Certainly provides clarity and consistency if you have if-else constructs. We've all learned from reading R sources, and it seems to have worked out well for many of us. Jeff On Tue, Feb 15, 2011 at 12:04 PM, Paul Johnson wrote: > Hello, > > I am looking for CRAN packages that don't teach bad habits. Can I > have suggestions? > > I don't mean the recommended packages that come with R, I mean the > contributed ones. I've been sampling a lot of examples and am > surprised that many ignore seemingly agreed-upon principles of R > coding. In r-devel, almost everyone seems to support the "functional > programming" theme in Chambers's book on Software For Data Analysis, > but when I go look at randomly selected packages, programmers don't > follow that advice. > > In particular: > > 1. Functions must avoid "mystery variables from nowhere." > > Consider a function's code, it should not be necessary to say "what's > variable X?" and go hunting in the commands that lead up to the > function call. If X is used in the function, it should be in a named > argument, or extracted from one of the named arguments. People who > rely on variables floating around in the user's environment are > creating hard-to-find bugs. > > 2. We don't want functions with indirect effects (no <<- ), almost always. > > 3. Code should be vectorized where possible, C style for loops over > vector members should be avoided. > > 4. We don't want gratuitous use of "return" at the end of functions. > Why do people still do that? > > 5. Neatness counts. Code should look nice! Check out how beautiful > the functions in MASS look! I want code with spaces and " <- " rather > than everything jammed together with "=". > > I don't mean to criticize any particular person's code in raising this > point. For teaching exemples, where to focus? > > Here's one candidate I've found: > > MNP. as far as I can tell, it meets the first 4 requirements. And it > has some very clear C code with it as well. I'm only hesitant there > because I'm not entirely sure that a package's C code should introduce > its own functions for handling vectors and matrices, when some general > purpose library might be more desirable. But that's a small point, > and clarity and completeness counts a great deal in my opinion. > > > > > > -- > Paul E. Johnson > Professor, Political Science > 1541 Lilac Lane, Room 504 > University of Kansas > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Jeffrey Ryan jeffrey.r...@lemnica.com www.lemnica.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Request: Suggestions for "good teaching" packages, esp. with C code
f3 <- function() {
( a <- 5 )
}
f4 <- function() {
a <- 5
a
}
On my machine f1,f2, and f4 all perform approx. the same. The () in
f3 adds about 20% overhead.
Jeff
On Tue, Feb 15, 2011 at 4:22 PM, Kevin Wright wrote:
> For those of you "familiar with R", here's a little quiz. What what's the
> difference between:
>
>
> f1 <- function(){
> a=5
> }
> f1()
>
> f2 <- function(){
> return(a=5)
> }
> f2()
>
>
> Kevin Wright
>
>
>
>
> On Tue, Feb 15, 2011 at 3:55 PM, Geoff Jentry wrote:
>
>> On Wed, 16 Feb 2011, David Scott wrote:
>>
>>> 4. We don't want gratuitous use of "return" at the end of functions.
>>>> Why do people still do that?
>>>>
>>> Well I for one (and Jeff as well it seems) think it is good programming
>>> practice. It makes explicit what is being returned eliminating the
>>> possibility of mistakes and provides clarity for anyone reading the code.
>>>
>>
>> You're unnecessarily adding the overhead of a function call by explicitly
>> calling return().
>>
>> Sure it seems odd for someone coming from the C/C++/Java/etc world, but
>> anyone familiar with R should find code that doesn't have an explicit
>> return() call to be fully readable & clear.
>>
>> -J
>>
>>
>> __
>> 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
>
--
Jeffrey Ryan
jeffrey.r...@lemnica.com
www.lemnica.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] function call overhead
Hi Paul,
> `:::`
function (pkg, name)
{
pkg <- as.character(substitute(pkg))
name <- as.character(substitute(name))
get(name, envir = asNamespace(pkg), inherits = FALSE)
}
and
> `::`
function (pkg, name)
{
pkg <- as.character(substitute(pkg))
name <- as.character(substitute(name))
ns <- tryCatch(asNamespace(pkg), hasNoNamespaceError = function(e) NULL)
if (is.null(ns)) {
pos <- match(paste("package", pkg, sep = ":"), search(),
0L)
if (pos == 0)
stop(gettextf("package %s has no name space and is not on
the search path"),
sQuote(pkg), domain = NA)
get(name, pos = pos, inherits = FALSE)
}
else getExportedValue(pkg, name)
}
are the reasons I think.
Jeff
On Wed, Feb 16, 2011 at 12:13 PM, Paul Gilbert
wrote:
> (subject changed from: RE: [Rd] Avoiding name clashes: opinion on best
> practice naming conventions)
>
> Dominick
>
> Is this really true? Is there a speed advantage to defining a local function
> this way, say, within another function, and then calling it within a loop
> rather than the original? Do you have data on this?
>
> Paul
>
>> -Original Message-
>> From: r-devel-boun...@r-project.org [mailto:r-devel-bounces@r-
>> project.org] On Behalf Of Dominick Samperi
>> Sent: February 16, 2011 12:44 PM
> ...
>> Since the resolution of myPkg::foo() occurs at runtime (via a function
>> call) instead
>> of at compile time (as it would in C++), this practice can introduce a
>> significant
>> performance hit. This can be avoided by doing something like:
>> mylocalfunc <- myPkg::foo
>> [tight loop that uses mylocalfunc repeatedly]
>>
>> Here mylocalfunc would not be exported, of course.
>>
>> Dominick
> ...
>
>
> La version française suit le texte anglais.
>
>
>
> This email may contain privileged and/or confidential information, and the
> Bank of
> Canada does not waive any related rights. Any distribution, use, or copying
> of this
> email or the information it contains by other than the intended recipient is
> unauthorized. If you received this email in error please delete it
> immediately from
> your system and notify the sender promptly by email that you have done so.
>
>
>
> Le présent courriel peut contenir de l'information privilégiée ou
> confidentielle.
> La Banque du Canada ne renonce pas aux droits qui s'y rapportent. Toute
> diffusion,
> utilisation ou copie de ce courriel ou des renseignements qu'il contient par
> une
> personne autre que le ou les destinataires désignés est interdite. Si vous
> recevez
> ce courriel par erreur, veuillez le supprimer immédiatement et envoyer sans
> délai à
> l'expéditeur un message électronique pour l'aviser que vous avez éliminé de
> votre
> ordinateur toute copie du courriel reçu.
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Jeffrey Ryan
jeffrey.r...@lemnica.com
www.lemnica.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] hook for when R quits
Take a look at reg.finalizer. You'd have to create an object internally that would persist until R exits - and a related function to handle cleanup of course. HTH Jeff On Fri, Mar 11, 2011 at 12:08 PM, Michael Lawrence wrote: > Hi, > > Is there any way that a package can listen for when R quits? The Qt stuff is > hooking into platform-specific event loops and when those die unexpectedly > (from the perspective of Qt), it aborts, causing an annoying error dialog. > If we could catch when R is killed, we could cleanup, like we do with > .onUnload. > > Thanks, > Michael > > [[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Jeffrey Ryan jeffrey.r...@lemnica.com www.lemnica.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Detecting bad lexical scoping
I've recently hunted down a troublesome bug in my own code, and am looking for an easy mechanism to detect this kind of error in other R code. The problem was an undefined variable inside of a function. Unfortunately, R looked for that variable in the global environment and found it since there was variable with that name in my testing scripts (note to self: do not name things "x"). Is there an easy way to report all the non-local objects accessed in a function? Is there any easy way around the usual scoping rules? I want to be able to get to base functions, and am willing to namespace:: or ::: access all of my own functions (it's in a package) if necessary to block the standard scoping rules. The language def section on environments made me hurt. Thanks, C Ryan King Dept Health Studies University of Chicago __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] help.request() for packages?
For what it is worth, I too would like to see something regarding a "Support" field in the description. One issue with a single maintainer email is that it does make it difficult to assure that questions get properly routed/answered given projects that have multiple contributors or an active community behind them. I would think even hinting to the best R-SIG list would be useful (in my case I typically only follow R-SIG-Finance closely and miss some questions that go to R-help) At the very least, it would make it more obvious to users where they should send general questions about a package. Best, Jeff On Tue, Apr 26, 2011 at 3:08 PM, Matthew Dowle wrote: > Hi, > > Have I missed something, or misunderstood? > > The r-help posting guide asks users to contact the package maintainer : > > "If the question relates to a contributed package, e.g., one > downloaded from CRAN, try contacting the package maintainer first. > [snip] ONLY [only is bold font] send such questions to R-help or R-devel > if you get no reply or need further assistance. This applies to both > requests for help and to bug reports." > > but the R-ext guide contains : > > "The mandatory Maintainer field should give a single name with a > valid (RFC 2822) email address in angle brackets (for sending bug > reports etc.). It should not end in a period or comma. For a public > package it should be a person, not a mailing list and not a corporate > entity: do ensure that it is valid and will remain valid for the > lifetime of the package." > > Currently, data.table contains the datatable-help mailing list in the > 'Maintainer' field, with the posting guide in mind (and service levels > for users). This mailing list is where we would like users to ask > questions about the package, not r-help, and not a single person. > However, R-exts says that the 'Maintainer' email address should not be a > mailing list. > > There seems to be two requirements: > i) a non-bouncing email address that CRAN maintainers can use - more > like the 'Administrator' of the package > ii) a support address for users to send questions and bug reports > > The BugReports field in DESCRIPTION is for bugs only, and allows only a > URL, not an email address. bug.reports() has a 'package' argument and > emails the Maintainer field if the BugReports URL is not provided by the > package. So, BugReports seems close, but not quite what we'd like. > > help.request() appears to have no package argument (I checked R 2.13.0). > > Could a "Support" field (or better name) be added to DESCRIPTION, and a > 'package' argument added to help.request() which uses it? Then the > semantics of the Maintainer field can be closer to what the CRAN > maintainers seem to think of it; i.e., the package 'Administrator'. > > Have I misunderstood or missed an option? > > Matthew > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Jeffrey Ryan jeffrey.r...@lemnica.com www.lemnica.com R/Finance 2011 April 29th and 30th in Chicago | www.RinFinance.com [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] C-Side: Applying a function (given as param) to data (given as param)
Oliver,
For an example of moving averages, take a look at the C source of the xts and
TTR packages. The sources are browsable on R-forge.
In short, REAL etc are functions to extract the data of an SEXP. They need to
match the types coming in. So your C needs to check the type and branch
accordingly.
It is all in the guide as well as in working example code in R sources as well
as many hundreds of package sources. You have access to it all, so spend the
time just reading the sources is my recommendation.
Best,
Jeff
Jeffrey Ryan|Founder|jeffrey.r...@lemnica.com
www.lemnica.com
On Jun 3, 2011, at 3:19 PM, oliver wrote:
> On Fri, Jun 03, 2011 at 11:14:39AM -0500, Douglas Bates wrote:
>> On Fri, Jun 3, 2011 at 5:17 AM, oliver wrote:
>>> Hello,
>>>
>>> I'm implementing a package (C-extension),
>>> where one function gets data and a function
>>> that needs to be applied to the data.
>>>
>>> I want to apply the function to (parts of)
>>> the data on the C-side.
>>>
>>> 1) how do I apply a function (given via SEXP) to data
>>> 2) how do I select parts of the data (also provided via SEXP)?
>>
>> Not to be facetious but you begin by reading the "Writing R Extensions"
>> manual.
>
> I already read inside it.
> If there would be no question open i would not have registered to this
> mailing list
> and woulod not have asked that question.
> Obviously my question was not answered in the "Writing R Extensions",
> so if you can give me a hint this would be nice.
>
>
>>
>> An alternative is to read the vignette Rcpp-Introduction available as
>> http://dirk.eddelbuettel.com/code/rcpp/Rcpp-introduction.pdf and soon
>
> I use C, not C++.
>
> But maybe it helps too.
>
> I already created my own package with R and C successfully some days ago.
>
> But so far I did not used fucntion pointers coming in via SEXP parameters.
>
> And that was my specific question.
>
>
>
>
>> to be in The R Journal. They show an explicit example of apply in
>> compiled code (C++ using the Rcpp structures, in their case).
>
>
> As just mentioned: I already created successfully a C-extension for R.
>
> But I would like to know, how to call a function that I get via
> SEXP as parameter. How can I find out the function definition,
> for example the arity of the function and which arguments
> a function uses.
>
> The problem is, that the C-standard (at least the first ANSI-C standard)
> does not guarantee portability for C-pointers.
> To be portable, for example the function pointer you use must
> definitely be of same type as the function you use.
>
> So I need to know how I can use the SEXP-function pointers.
>
>
> To be more concrete, this is how my function's API looks like
> at the moment:
>
> SEXP movapply( SEXP data, SEXP width, SEXP func )
> {
> /* some code */
>
> return ( result );
> }
>
>
>
> data will be vector or list or matrix
> width will be int value (I think vector of length 1)
> func will be a function pointer of the type that is given as argument
>
> I don't know on which kind of pointer to cast.
> I think I will cast to a pure C-type, but then all data also must
> match to the function definition.
>
> What if the function wants to work on integer, but the data is double?
>
> Somehow this must be handled, and I think the experts here can just point me
> directly to some kind of docs or maybe older postinmgs here, which explain
> this?
>
>
> Ciao,
> Oliver
>
> __
> 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
Re: [Rd] "warning: assignment discards qualifiers from pointer target type"
On Wed, Jun 8, 2011 at 7:17 PM, oliver wrote:
> On Wed, Jun 08, 2011 at 02:23:29PM -0400, Simon Urbanek wrote:
> >
> > On Jun 8, 2011, at 12:08 PM, oliver wrote:
> >
> > > On Wed, Jun 08, 2011 at 12:22:10PM +0100, Prof Brian Ripley wrote:
> > >> On Tue, 7 Jun 2011, Duncan Murdoch wrote:
> > >>
> > >>> On 07/06/2011 9:08 AM, oliver wrote:
> > >>>> Hello,
> > >>>>
> > >>>> following an advice here from the list I looked into sources of
> other
> > >>>> packages (xts) and found the TYPEOF() macro/function, which really
> is
> > >>>> helpful.
> > >>
> > >> It is documented, of course, but actually better alternatives are
> > >> described in 'Writing R Extensions'.
> > >>
> > >> We would urge you to study the R sources rather than copy bad habits
> > >> from randomly chosen package sources.
> > > [...]
> > >
> > > Hmhh, it was not randomly chosen, it was, what I got as a hint here on
> the list.
> > >
> >
> > It was not provided to you to look at how it checks arguments. For basic
> > usage it's better to look at the R code. The coding styles vary a lot in
> > packages (and so does the quality of packages) - some of them are really
> bad,
> > but you have to remember that most people write packages in their free
> time and
> > are not programmers...
>
> OK, I see.
>
Of course - most of R core aren't "programmers" either - whatever that
means. Statisticians, mathematicians, etc...
;-)
Most contributed packages aren't meant to be case studies in a comp-sci
class either, they are meant to solve real world problems - problems that
many of us work on daily.
That said, I'd also say look to R sources first, but since many things in R
core aren't available in the API - you aren't really able to copy the 'best
practices' alluded to. And sometimes you've got to bootstrap solutions when
the list is otherwise silent. Another reason that you should look outside
of R sources in addition to inside of them is that the community code is far
more abundant that the core code. Sort of like theory vs. practice - they
only teach so much in school.
For reference, TYPEOF is straight from R source (of course):
http://svn.r-project.org/R/trunk/src/main/subset.c
Cheers,
Jeff
>
>
> [...]
> > >> and there is no
> > >> check in that code that LENGTH(filename_sexp) > 0 (or == 1). In the
> > >> R sources you will often see things like
> > >>
> > >>if(!isString(sfile) || LENGTH(sfile) < 1)
> > >>error("invalid '%s' argument", "description");
> > > [...]
> > >
> > > If it's a vector, I can just pic the first element.
> >
> > Yes, but only if it's not a vector of length zero - hence the necessary
> check.
> >
> >
> > > Or does LENGTH(sfile) give the length of the string itself
> > > (like strlen(3))?
> > >
> >
> > No.
> [...]
>
> OK, I looked at this now.
>
> LENGTH() checks the length of the vector.
>
> Good to know this.
>
> So the problem of a vector of length 0 can be with any arguments of type
> SEXP,
> hence I will need to check ANY arg on it's length.
>
> This is vital to stability under any situation.
>
> Thanks for this valuable hint!
>
> I will add checks for all my SEXP-args.
>
>
> Ciao,
> Oliver
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Jeffrey Ryan
jeffrey.r...@lemnica.com
www.lemnica.com
www.esotericR.com
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Performance of .C and .Call functions vs. native R code
The .Call overhead isn't the issue. If you'd like some insight into what you are doing wrong (and right), you need to provide code for the list to reproduce your timings with. This is outlined in the posting guide as well. Best, Jeff On Jul 13, 2011, at 8:28 AM, asmahani wrote: > Hello, > > I am in the process of writing an R extension for parallelized MCMC, with > heavy use of compiled code (C++). I have been getting my feet wet by > implementing a simple matrix-vector multiplication function in C++ (which > calls a BLAS level 2 function dgemv), and comparing it to the '%*%' operator > in R (which apparently calls a BLAS level 3 function dgemm). > > Interestingly, I cannot replicate the performance of the R native operator, > using either '.C' or '.Call'. The relative times are 17 (R), 30 (.C), and 26 > (.Call). In other words, R native operator is 1.5x faster than my compiled > code. Can you explain to me why this is? Through testing I strongly suspect > that the BLAS function itself isn't what takes the bulk part of the time, > but perhaps data transfer and other overhead associated with the calls (.C > and .Call) are the main issues. Are there any ways to reach the performance > level of native R code in this case? > > Thank you, > Alireza Mahani > > -- > View this message in context: > http://r.789695.n4.nabble.com/Performance-of-C-and-Call-functions-vs-native-R-code-tp3665017p3665017.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 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] CRAN mirror size mushrooming; consider archiving some?
Or one could buy an iPod and host it from there ;-) 160 GB for US$250. Uwe's plan is probably better though... Jeff On Tue, Jul 26, 2011 at 5:08 PM, Hadley Wickham wrote: > >> I'm setting up a new CRAN mirror and filled up the disk space the > >> server allotted me. I asked for more, then filled that up. Now the > >> system administrators want me to buy an $800 fiber channel card and a > >> storage device. I'm going to do that, but it does make want to > >> suggest to you that this is a problem. > > > > Why? Just for the mirror? That's nonsense. A 6 year old outdated desktop > > machine (say upgraded to 2GB RAM) with a 1T harddisc for 50$ should be > fine > > for your first tries. The bottleneck will probably be your network > > connection rather than the storage. > > Another perspective is that it costs ~$10 / month to store 68 Gb of > data on amazon's S3. And then you pay 12c / GB for download. > > Hadley > > -- > Assistant Professor / Dobelman Family Junior Chair > Department of Statistics / Rice University > http://had.co.nz/ > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Jeffrey Ryan jeffrey.r...@lemnica.com www.lemnica.com www.esotericR.com [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] slightly speeding up readChar()
Michael, The mmap package currently provides an Ops method for comparisons, which returns something like which(i==) does in R - since a vector of logicals the same size would be likely too big to handle in many cases. At some point I'll implement mmap to mmap operations, though for vectorized ops that result in non-logical output (i.e. numeric), I haven't yet decided on how that should be implemented. Something like a results buffer on disk/memory has been my thinking, but anyone with additional (better!) suggestions please feel free to send me ideas off list. I'll look to add some basic summary statistics as well. Note that you need to have a binary representation on disk (via fwrite in C, or writeBin or as.mmap in R) for this to work. But the package currently supports something like 16 data types, including bit logicals, fixed width character strings (\0 delim vectors), floats (4 byte), and 64 bit ints. The vignette covers a lot of the details. Additionally if you have struct-style data (think row-oriented, with varying types), you can use the struct() feature. This maps to an R list, but allows for very fast access if you are pulling complete rows. example(mmap) example(types) example(struct) The R-forge version has more than the CRAN version at this moment, but I'll be pushing a new one to CRAN soon. Jeff On Fri, Aug 5, 2011 at 8:22 AM, Michael Lachmann wrote: > > On 5 Aug 2011, at 1:20AM, Dirk Eddelbuettel wrote: > > > When you know the (fixed) structure of the data, the CRAN package mmap > can be > > a huge winner. > > Thanks! I didn't know that. > > Is there a package that provides methods for mmap, like sum(x) or maybe > even y=x+z > where x, and z are mmaps? > > I assume that once you mmap to a huge file, you do operations on it by > working on chunks at a time... are there packages for that, or do I have to > write my own code? > > Thanks! > > Michael > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Jeffrey Ryan jeffrey.r...@lemnica.com www.lemnica.com www.esotericR.com [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Non-GPL C (or R) inside of a package
R-devel,
I am interested in creating a package that requires non-GPL'd (commercial) C
code to work. In essence it is a single .c file with no use of R headers
(all .C callable functions). For example's sake:
1 #include
2
3 void test (int *a) {
4 *a = 101;
5 }
The package isn't destined for CRAN, and I realize that this isn't R-legal,
but looking for some expert advice from anyone else who may have encountered
this previously.
The question is whether or not one can distribute code that has multiple
licenses (.c or individual .R files), including some that are not
GPL-compatible, as a tar.gz (or binary) file. i.e., does the packaging
process [R CMD ***] cause everything to become GPL, as we are using R itself
to build the package?
I can of course provide the C libs in this case as a separate install, but
that adds complexity to the overall build and install process.
Thanks,
Jeff
--
Jeffrey Ryan
jeffrey.r...@lemnica.com
www.lemnica.com
www.esotericR.com
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Non-GPL C (or R) inside of a package
On Tue, Aug 30, 2011 at 3:52 PM, Prof Brian Ripley
wrote:
>
> On Tue, 30 Aug 2011, Duncan Murdoch wrote:
>
>> On 30/08/2011 1:50 PM, Jeffrey Ryan wrote:
>>>
>>> R-devel,
>>>
>>> I am interested in creating a package that requires non-GPL'd (commercial)
>>> C code to work. In essence it is a single .c file with no use of R headers
>>> (all .C callable functions). For example's sake:
>>>
>>> 1 #include
>>> 2
>>> 3 void test (int *a) {
>>> 4 *a = 101;
>>> 5 }
>>>
>>> The package isn't destined for CRAN, and I realize that this isn't R-legal,
>>> but looking for some expert advice from anyone else who may have
>>> encountered this previously.
>>>
>>> The question is whether or not one can distribute code that has multiple
>>> licenses (.c or individual .R files), including some that are not
>>> GPL-compatible, as a tar.gz (or binary) file. i.e., does the packaging
>>> process [R CMD ***] cause everything to become GPL, as we are using R
>>> itself to build the package?
>>>
>> I can only say that the answer to the last question is "no": the author
>> gets to choose the license for what s/he wrote. The fact that you used R to
>> package it is irrelevant. (Some extremists will disagree, and say that
>> because your package is intended to "link" to R, it must be licensed
>> compatibly with the GPL if you distribute it. I don't think that's true.)
>
> If no distribution is involved, the conditions under which the tarball can be
> distributed is not relevant.
>
> As e.g. GNU tar is itself under GPL, using R to do the packaging is no
> different in principle to using GNU tar to do so and I've never heard anyone
> argue that using GNU tar affects the licence of the tarball.
Good point. Thanks.
>
> I don't think that is the same issue as distributing non-GPLed code for use
> with R. In the latter case the issue is what 'link to' actually entails, and
> one source of advice is the GPL FAQs. E.g.
> http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html
> http://www.gnu.org/licenses/gpl-faq.html
I do think this is the same issue. The key part of that rather
wandering FAQ to me is:
http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL
Which states:
"Another similar and very common case is to provide libraries with the
interpreter which are themselves interpreted. For instance, Perl comes
with many Perl modules, and a Java implementation comes with many Java
classes. These libraries and the programs that call them are always
dynamically linked together.
A consequence is that if you choose to use GPL'd Perl modules or Java
classes in your program, you must release the program in a
GPL-compatible way, regardless of the license used in the Perl or Java
interpreter that the combined Perl or Java program will run on."
In my own terms, this seems to say using *ANY* GPL code in your
program - even if interpretted at some later point - forces all code
to be GPLed. e.g. A script that creates a simple vector using
something like "v = 1:10" is using the GPLed base package and
therefore must be GPLed itself.
My case is a bit more subtle, as the code that I am writing makes no
use of any GPL code, aside from the compilation and linking to allow
GPL "R" code to access it.
Jeff
>
>> If you are intending to distribute this file you are putting together,
>> you'll probably want to consult someone who knows the legalities as to
>> whether you can legally link to the commercial library...
>
>
>
>>
>> Duncan Murdoch
>>
>>> I can of course provide the C libs in this case as a separate install, but
>>> that adds complexity to the overall build and install process.
>>>
>>> Thanks,
>>> Jeff
>>>
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
> --
> Brian D. Ripley, rip...@stats.ox.ac.uk
> Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
> University of Oxford, Tel: +44 1865 272861 (self)
> 1 South Parks Road, +44 1865 272866 (PA)
> Oxford OX1 3TG, UK Fax: +44 1865 272595
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Jeffrey Ryan
jeffrey.r...@lemnica.com
www.lemnica.com
www.esotericR.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Non-GPL C (or R) inside of a package
On Wed, Aug 31, 2011 at 10:40 AM, oliver wrote: > On Wed, Aug 31, 2011 at 10:34:38AM -0500, Jeffrey Ryan wrote: > [...] >> My case is a bit more subtle, as the code that I am writing makes no >> use of any GPL code, aside from the compilation and linking to allow >> GPL "R" code to access it. > [...] > > Just ask people from the FSF, if your issue is complicated. > > Or ask the owner of the nmon-GPLed code, if it is possible > to make it open for your project. > > That does not necessarily mean that the same code in olther > products of the company also needs to become open. > > It's possible to make a "fork". > > You just can't make GPLed code again closed. Right. I understand that perfectly. So likely a tarball with varying licenses *might* be ok, even if all are not GPL compatible - since one file wouldn't affect the other. The final compiled work though would have to be GPLd though, since you couldn't hide the GPLd sections under another license. Seems to make sense to me. And the end-user would have to compile it to have it work, and would need to carry a GPL license... yikes what a mess. I think the external library via an additional download is likely the simplest and safest route all around. Best, Jeff > > > Ciao, > Oliver > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Jeffrey Ryan jeffrey.r...@lemnica.com www.lemnica.com www.esotericR.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Is xtable still being maintained?
I would be leery of just taking over as maintainer if a package still works and passes all checks on CRAN. My personal take is that even commercial packages ignore feature requests, and to expect such from an OSS one is expecting too much. Of course patches are welcomed, but they can't honestly be expected to be committed. Even if they are they may be a low priority for the maintainer/author - be it for style, design, or implementation/maintenance purposes. My suggestion would be to continue to ask, but if that doesn't work simply build an extension that others might be able to use with xtable in this case (xtableExtras??). In the absolute last case I would fork it if you feel the need and the intense desire to maintain a whole new version. The caveat of adding another package that duplicates, but only adds one feature (however amazing you think), isn't likely to be helpful to the entire R universe - in fact it is likely harmful. my 2c Jeff On Sat, Sep 10, 2011 at 9:40 AM, Spencer Graves wrote: > > > On 9/10/2011 6:06 AM, Uwe Ligges wrote: >> >> >> On 10.09.2011 13:26, Alastair wrote: >>> >>> Hi, >>> >>> I wonder if anyone knows if the xtable package is still actively being >>> maintained? The last update to the CRAN was about 2 years ago. Earlier in >>> the year I found I wanted to use the short caption option of LaTeX tables >>> to >>> display an abridged title in my table of contents. It was a relatively >>> simple change to get xtable to support this. I bundled up my changes and >>> sent the maintainer David B. Dahl an email and I got absolutely no >>> response? >> >> Try to "ping" - at least I do so in this case. No response would be >> unfortunate, of course. > > > David B. Dahl still has a web site as an Associate Professor at Texas > A&M U. >> >> >>> What's the etiquette for this kind of situation? I think he's done a >>> sterling job maintaining a really useful package; I wanted to help and >>> contribute to the community but if he's not doing it anymore how can >>> anyone >>> get their improvements / bug fixes into circulation? >> >> xtable's DESCRIPTION file says >> >> License: GPL (>= 2) >> >> so go ahead in case you do not get a response. >> >> Best, >> Uwe Ligges > > > xtable has a long list of reverse depends, imports, suggests and > enhances, so many people clearly think it's useful. > > > My preference is to encourage the maintainer(s) to migrate the project > to R-Forge where others can help maintain it and add enhancements (that > shouldn't break current applications) that people feel are generally useful. > (Not everyone responds positively to this kind of suggestion, but some do.) > > > R-Forge also lists tabulaR, which "is a comprehensive package for > presenting quality tabular output within the R Environment. Differing from > xtable and Hmisc, it manipulates, formats and presents tabular data to any R > device stream, which can then be used by any structured format." So far, > however, I was unable to find evidence that the the tabulaR team has done > anything for with R-Forge beyond successfully getting a shell created for > the project. > > > Good luck! > Spencer >> >> >>> >>> Cheers, >>> Alastair >>> >>> -- >>> View this message in context: >>> http://r.789695.n4.nabble.com/Is-xtable-still-being-maintained-tp3803657p3803657.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 >> >> __ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > > > -- > Spencer Graves, PE, PhD > President and Chief Technology Officer > Structure Inspection and Monitoring, Inc. > 751 Emerson Ct. > San José, CA 95126 > ph: 408-655-4567 > web: www.structuremonitoring.com > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Jeffrey Ryan jeffrey.r...@lemnica.com www.lemnica.com www.esotericR.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Is it possible to pass a function argument from R to compiled code in C?
You can't call "R" code as if it is C code. It is R, and requires that it be evaluated. How would your C know what to do with an R pointer... .Call is more efficient than .C, all the time. Check this list and experiment. That said, you can still call "just C" within the .Call "R" function, it really is 'just C' in there. Probably something like a simple example of what you are trying to do would help the list steer you into the right direction (steer, since you seem to be missing something in your thinking on this...) Best, Jeff On Tue, Sep 20, 2011 at 1:07 PM, Alireza Mahani wrote: > OK, thanks. But there are two issues with using ".Call": > > 1- I may give up performance if I am literally running R code inside C, > right? In some ways, wouldn't it defy the purpose of calling a compiled code > if I end up back in R? > > 2- If I use the ".Call" interface, the resulting code will be tailored to R, > i.e. I will end up having the lengthy code with all the R macros in it. I > always prefer to use ".C" interface because I can use the exact same piece > of code inside of a C program, i.e. I can call the same function either from > R or from C. But with .Call, I am passing R's pointers into the function, > which obviously I won't be doing when my call comes from inside of C. > > Nevertheless, it's good to know that there is at least a sub-optimal > solution out there (sub-optimal from my perspective, of course!). > > -Alireza > > -- > View this message in context: > http://r.789695.n4.nabble.com/Is-it-possible-to-pass-a-function-argument-from-R-to-compiled-code-in-C-tp3827563p3827690.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 > -- Jeffrey Ryan jeffrey.r...@lemnica.com www.lemnica.com www.esotericR.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Issue with seek() on gzipped connections in R-devel
seek() in general is a bad idea IMO if you are writing cross-platform code.
?seek
Warning:
Use of ‘seek’ on Windows is discouraged. We have found so many
errors in the Windows implementation of file positioning that
users are advised to use it only at their own risk, and asked not
to waste the R developers' time with bug reports on Windows'
deficiencies.
Aside from making me laugh, the above highlights the core reason to not use IMO.
For not zipped files, you can try the mmap package. ?mmap and ?types
are good starting points. Allows for accessing binary data on disk
with very simple R-like semantics, and is very fast. Not as fast as a
sequential read... but fast. At present this is 'little endian' only
though, but that describes most of the world today.
Best,
Jeff
On Fri, Sep 23, 2011 at 8:58 AM, Jon Clayden wrote:
> Dear all,
>
> In R-devel (2011-09-23 r57050), I'm running into a serious problem
> with seek()ing on connections opened with gzfile(). A warning is
> generated and the file position does not seek to the requested
> location. It doesn't seem to occur all the time - I tried to create a
> small example file to illustrate it, but the problem didn't occur.
> However, it can be seen with a file I use for testing my packages,
> which is available through the URL
> <https://github.com/jonclayden/tractor/blob/master/tests/data/nifti/maskedb0_lia.nii.gz?raw=true>:
>
>> con <- gzfile("~/Downloads/maskedb0_lia.nii.gz","rb")
>> seek(con, 352)
> [1] 0
> Warning message:
> In seek.connection(con, 352) :
> seek on a gzfile connection returned an internal error
>> seek(con, NA)
> [1] 190
>
> The same commands with the same file work as expected in R 2.13.1, and
> have worked over many previous versions of R.
>
>> con <- gzfile("~/Downloads/maskedb0_lia.nii.gz","rb")
>> seek(con, 352)
> [1] 0
>> seek(con, NA)
> [1] 352
>
> My sessionInfo() output is:
>
> R Under development (unstable) (2011-09-23 r57050)
> Platform: x86_64-apple-darwin11.1.0 (64-bit)
>
> locale:
> [1] en_GB.UTF-8/en_US.UTF-8/en_GB.UTF-8/C/en_GB.UTF-8/en_GB.UTF-8
>
> attached base packages:
> [1] splines stats graphics grDevices utils datasets methods
> [8] base
>
> other attached packages:
> [1] tractor.nt_2.0.1 tractor.session_2.0.3 tractor.utils_2.0.0
> [4] tractor.base_2.0.3 reportr_0.2.0
>
> This seems to occur whether or not R is compiled with
> "--with-system-zlib". I see some zlib-related changes mentioned in the
> NEWS, but I don't see any indication that this is expected. Could
> anyone shed any light on it, please?
>
> Thanks and all the best,
> Jon
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Jeffrey Ryan
jeffrey.r...@lemnica.com
www.lemnica.com
www.esotericR.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Issue with seek() on gzipped connections in R-devel
Yes, inelegant would be a good description. Sadly a fact we have to
put up with I guess.
FWIW, I too don't like dependencies. mmap has none, and is cross
platform, but I get the idea.
Good luck,
Jeff
On Fri, Sep 23, 2011 at 11:13 AM, Jon Clayden wrote:
> Thanks for the replies. I take the point, although it does seem like a
> substantial regression (on non-Windows platforms).
>
> I like to keep the external dependencies of my packages minimal, but I
> will look into the mmap package - thanks, Jeff, for the tip.
>
> Aside from that, though, what is the alternative to using seek? If I
> want to read something at (original, uncompressed) byte offset 352, as
> here, do I have to read and discard everything that comes before it
> first? That seems inelegant at best...
>
> Regards,
> Jon
>
>
> On 23 September 2011 16:54, Jeffrey Ryan wrote:
>> seek() in general is a bad idea IMO if you are writing cross-platform code.
>>
>> ?seek
>>
>> Warning:
>>
>> Use of ‘seek’ on Windows is discouraged. We have found so many
>> errors in the Windows implementation of file positioning that
>> users are advised to use it only at their own risk, and asked not
>> to waste the R developers' time with bug reports on Windows'
>> deficiencies.
>>
>> Aside from making me laugh, the above highlights the core reason to not use
>> IMO.
>>
>> For not zipped files, you can try the mmap package. ?mmap and ?types
>> are good starting points. Allows for accessing binary data on disk
>> with very simple R-like semantics, and is very fast. Not as fast as a
>> sequential read... but fast. At present this is 'little endian' only
>> though, but that describes most of the world today.
>>
>> Best,
>> Jeff
>>
>> On Fri, Sep 23, 2011 at 8:58 AM, Jon Clayden wrote:
>>> Dear all,
>>>
>>> In R-devel (2011-09-23 r57050), I'm running into a serious problem
>>> with seek()ing on connections opened with gzfile(). A warning is
>>> generated and the file position does not seek to the requested
>>> location. It doesn't seem to occur all the time - I tried to create a
>>> small example file to illustrate it, but the problem didn't occur.
>>> However, it can be seen with a file I use for testing my packages,
>>> which is available through the URL
>>> <https://github.com/jonclayden/tractor/blob/master/tests/data/nifti/maskedb0_lia.nii.gz?raw=true>:
>>>
>>>> con <- gzfile("~/Downloads/maskedb0_lia.nii.gz","rb")
>>>> seek(con, 352)
>>> [1] 0
>>> Warning message:
>>> In seek.connection(con, 352) :
>>> seek on a gzfile connection returned an internal error
>>>> seek(con, NA)
>>> [1] 190
>>>
>>> The same commands with the same file work as expected in R 2.13.1, and
>>> have worked over many previous versions of R.
>>>
>>>> con <- gzfile("~/Downloads/maskedb0_lia.nii.gz","rb")
>>>> seek(con, 352)
>>> [1] 0
>>>> seek(con, NA)
>>> [1] 352
>>>
>>> My sessionInfo() output is:
>>>
>>> R Under development (unstable) (2011-09-23 r57050)
>>> Platform: x86_64-apple-darwin11.1.0 (64-bit)
>>>
>>> locale:
>>> [1] en_GB.UTF-8/en_US.UTF-8/en_GB.UTF-8/C/en_GB.UTF-8/en_GB.UTF-8
>>>
>>> attached base packages:
>>> [1] splines stats graphics grDevices utils datasets methods
>>> [8] base
>>>
>>> other attached packages:
>>> [1] tractor.nt_2.0.1 tractor.session_2.0.3 tractor.utils_2.0.0
>>> [4] tractor.base_2.0.3 reportr_0.2.0
>>>
>>> This seems to occur whether or not R is compiled with
>>> "--with-system-zlib". I see some zlib-related changes mentioned in the
>>> NEWS, but I don't see any indication that this is expected. Could
>>> anyone shed any light on it, please?
>>>
>>> Thanks and all the best,
>>> Jon
>>>
>>> __
>>> R-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>>
>>
>>
>> --
>> Jeffrey Ryan
>> jeffrey.r...@lemnica.com
>>
>> www.lemnica.com
>> www.esotericR.com
>>
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Jeffrey Ryan
jeffrey.r...@lemnica.com
www.lemnica.com
www.esotericR.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R 4.0.1-4.0.2 built with Intel Composer 19.0-19.1.1, error in "make check" on CentOS 7.7
character(2^30+1)
+ vector("list", 2^30+2)
+ }
>
> ## bad infinite recursion / on.exit / ... interactions
> ## catch the error to permit different error messages emitted
> ## (handling of infinite recursion is different in the AST interpreter
> ## and the byte-code interpreter)
>
> bar <- function() 1+1
> foo <- function() { on.exit(bar()); foo() }
> tryCatch(foo(), error=function(x) TRUE) # now simple "infinite recursion"
*** caught segfault ***
address 0x7fff4dc1b9f8, cause 'memory not mapped'
Traceback:
1: foo()
2: foo()
3: foo()
4: foo()
...
2712: foo()
2713: foo()
2714: foo()
2715: foo()
2716: foo()
2717: foo()
2718: foo()
2719: doTryCatch(return(expr), name, parentenv, handler)
2720: tryCatchOne(expr, names, parentenv, handlers[[1L]])
2721: tryCatchList(expr, classes, parentenv, handlers)
2722: tryCatch(foo(), error = function(x) TRUE)
An irrecoverable exception occurred. R is aborting now ...
---
Thanks in advance.
--
|| \\UTGERS, |---*O*---
||_// the State | Ryan Novosielski - novos...@rutgers.edu
|| \\ University | Sr. Technologist - 973/972.0922 (2x0922) ~*~ RBHS Campus
|| \\of NJ | Office of Advanced Research Computing - MSB C630, Newark
`'
signature.asc
Description: Message signed with OpenPGP
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 4.0.1-4.0.2 built with Intel Composer 19.0-19.1.1, error in "make check" on CentOS 7.7
> On Jun 25, 2020, at 10:31 AM, Bjørn-Helge Mevik wrote:
>
> Signed PGP part
> Ryan Novosielski writes:
>
>> Hi there,
>>
>> I initially asked about this on r-help and was told this might be a better
>> venue. I’m not really convinced from reading the posting guide, but I’ll
>> give it a shot. It was also suggested that the R-Project doesn’t really care
>> about building with “non-standard” compilers, but I can’t find any evidence
>> of that on the website (indeed, there’s some mention of successful past
>> builds, and the build itself is successful).
>>
>> I built R 4.0.2 with the Intel Parallel Studio XE compiler suite, versions
>> 19.0.x to 19.1.1. Build seems to go fine. I built it like this:
>>
>> module purge
>> module load intel/19.1.1
>> module list
>>
>> export CC=icc
>> export CXX=icpc
>> export F77=ifort
>> export FC=ifort
>> export AR=xiar
>> export LD=xild
>>
>> export CFLAGS="-O3 -ipo -qopenmp -axAVX,CORE-AVX2,CORE-AVX512"
>> export F77FLAGS="-O3 -ipo -qopenmp -axAVX,CORE-AVX2,CORE-AVX512"
>> export FFLAGS="-O3 -ipo -qopenmp -axAVX,CORE-AVX2,CORE-AVX512"
>> export CXXFLAGS="-O3 -ipo -qopenmp -axAVX,CORE-AVX2,CORE-AVX512"
>> export MKL="-lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core -liomp5 -lpthread"
>>
>> VERSION=4.0.1
>>
>> /scratch/novosirj/install-files/R-${VERSION}/configure --with-blas="$MKL"
>> --with-lapack --prefix=/opt/sw/packages/intel-19_1/R-Project/${VERSION} && \
>> make -j32 && make check && make -j32 install
>
> For what it is worth, we used to build R with the Intel compilers and
> MKL on our HPC cluster (on CentOS Linux), and we used the following
> setup. Note the comments about -fp-model precise and -ipo. It might no
> longer be a problem, but maybe worth checking.
>
> fast="-ip -O3 -qopt-mem-layout-trans=3 -xHost -mavx"
> ## Notes:
> ## -static and -ipo break compilation
> ## -no-prec-div breaks make check
> ## -fp-model precise is needed for make check
> ## -wd188 removes a lot of warnings (see R Inst. & Adm. manual)
> export CC="icc"
> export CFLAGS="$fast -wd188 -fp-model precise"
> export F77="ifort"
> export FFLAGS="$fast -fp-model precise"
> export CXX="icpc"
> export CXXFLAGS="$fast -fp-model precise"
> export FC="ifort"
> export FCFLAGS="$fast -fp-model precise"
>
> ## This works with intel 2011.10, at least:
> BLAS=--with-blas='-mkl=parallel'
> LAPACK=--with-lapack
>
> ## To make the linker find libraries in modules:
> export LDFLAGS=$(echo $LD_LIBRARY_PATH | sed 's/^/-L/; s/:/ -L/g')
>
> ./configure "$BLAS" "$LAPACK" --enable-BLAS-shlib --enable-R-shlib
> make -j 8
> make check
> make install
Thanks, Bjørn; -ipo no longer breaks compilation (I didn’t specify it, but I
see that it was getting added automatically). I was really hoping that
"-fp-model precise” (which also implies -prec-div which would seem to affect
the other option mentioned) would have an impact on “make check” here, but
apparently not. Also -wd188 is no longer required to hide warnings; this
doesn’t seem to be happening anymore (but remember it myself from earlier on).
I guess it might make sense to check with Intel; we have support. I wish I
could remember if this ever worked right, but I don’t think I thought/knew to
run "make check" on our older builds.
--
|| \\UTGERS, |---*O*---
||_// the State | Ryan Novosielski - novos...@rutgers.edu
|| \\ University | Sr. Technologist - 973/972.0922 (2x0922) ~*~ RBHS Campus
|| \\of NJ | Office of Advanced Research Computing - MSB C630, Newark
`'
signature.asc
Description: Message signed with OpenPGP
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 4.0.1-4.0.2 built with Intel Composer 19.0-19.1.1, error in "make check" on CentOS 7.7
> On Jun 25, 2020, at 8:06 AM, Ivan Krylov wrote:
>
> On Wed, 24 Jun 2020 18:56:06 +0000
> Ryan Novosielski wrote:
>
> On my machine, getOption('expressions') is 5000 and the example from
> the test correctly stops with length(traceback()) == 2500. (And the
> simpler example of f <- function() f(); f() stops with
> length(traceback()) == 5000).
>
>> Traceback:
>
> <...>
>
>> 2718: foo()
>
> This (traceback() being more than 2500 entries long) seems to imply
> that the stack size check is somehow skipped. (Perhaps optimized away?)
> The evaluation depth limit is checked in src/main/eval.c, line 705 [*],
> followed by stack size check. Can you attach the debugger and take a
> look at the values of R_EvalDepth and R_Expressions while executing the
> text? What about R_CStackStart and R_CStackLimit? What is the stack
> size limit (ulimit -s?) on the machine running this test?
I can do that. I figure you may have more experience debugging R than I have,
but I know the R command is a script, and that running the R binary directly
doesn’t result in a working run. So what I’ve tried is to do “gdb /bin/bash”
and then running R from that shell. Is that best/are there guidelines? I’m not
much of an expert in this area. Is there also any special way I need to compile
R to have the appropriate symbols?
The shell I’m running in had 8192 for stack size:
[novosirj@amarel-test1 R-4.0.2-intel-19.1-build]$ ulimit -s
8192
Thanks for your help!
--
|| \\UTGERS, |---*O*---
||_// the State | Ryan Novosielski - novos...@rutgers.edu
|| \\ University | Sr. Technologist - 973/972.0922 (2x0922) ~*~ RBHS Campus
|| \\of NJ | Office of Advanced Research Computing - MSB C630, Newark
`'
signature.asc
Description: Message signed with OpenPGP
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 4.0.1-4.0.5 built with Intel Composer 19.0-19.1.1, error in "make check" on CentOS 7.7-7.9
> On Jun 25, 2020, at 8:06 AM, Ivan Krylov wrote:
>
> On Wed, 24 Jun 2020 18:56:06 +0000
> Ryan Novosielski wrote:
>
> On my machine, getOption('expressions') is 5000 and the example from
> the test correctly stops with length(traceback()) == 2500. (And the
> simpler example of f <- function() f(); f() stops with
> length(traceback()) == 5000).
>
>> Traceback:
>
> <...>
>
>> 2718: foo()
>
> This (traceback() being more than 2500 entries long) seems to imply
> that the stack size check is somehow skipped. (Perhaps optimized away?)
> The evaluation depth limit is checked in src/main/eval.c, line 705 [*],
> followed by stack size check. Can you attach the debugger and take a
> look at the values of R_EvalDepth and R_Expressions while executing the
> text? What about R_CStackStart and R_CStackLimit? What is the stack
> size limit (ulimit -s?) on the machine running this test?
>
> --
> Best regards,
> Ivan
>
> [*]
> https://github.com/wch/r-source/blob/8d7ac4699fba640d030703fa010b66bf26054cbd/src/main/eval.c#L705
Thanks again for your help, Ivan, and also Frederick for pointing out how I
might run the debugger with R.
I’m finally back at this. Here’s what I see, presuming I’ve done this the right
way. Anything of use here as far as troubleshooting?
[novosirj@amarel-test2 bin]$ ./R -d gdb-ia
...
Reading symbols from
/scratch/novosirj/install-files/R-4.0.5-intel-19.1-build/bin/exec/R...
(gdb) run
Starting program:
/scratch/novosirj/install-files/R-4.0.5-intel-19.1-build/bin/exec/R
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
R version 4.0.5 (2021-03-31) -- "Shake and Throw"
Copyright (C) 2021 The R Foundation for Statistical Computing
Platform: x86_64-pc-linux-gnu (64-bit)
...
[Detaching after fork from child process 42089]
[Detaching after fork from child process 42091]
> bar <- function() 1+1
> foo <- function() { on.exit(bar()); foo() }
> tryCatch(foo(), error=function(x) TRUE) # now simple "infinite recursion"
Program received signal SIGSEGV, Segmentation fault.
bcEval.R (body=0x3eb7748, rho=0x3f72770, useCache=TRUE) at
/scratch/novosirj/install-files/R-4.0.5/src/main/eval.c:6478
6478 codebase = pc = BCCODE(body);
(gdb) print R_EvalDepth
$1 = 2729
(gdb) print R_Expressions
$2 = 5000
(gdb) print R_CStackStart
$3 = 140737488207872
(gdb) print R_CStackLimit
$4 = 7969177
(gdb) quit
A debugging session is active.
Inferior 1 [process 42083] will be killed.
Quit anyway? (y or n) y
[novosirj@amarel-test2 bin]$ ulimit -s
8192
--
#BlackLivesMatter
|| \\UTGERS, |---*O*---
||_// the State | Ryan Novosielski - novos...@rutgers.edu
|| \\ University | Sr. Technologist - 973/972.0922 (2x0922) ~*~ RBHS Campus
|| \\of NJ | Office of Advanced Research Computing - MSB C630, Newark
`'
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 4.0.1-4.0.5 built with Intel Composer 19.0-19.1.1, error in "make check" on CentOS 7.7-7.9
> On Apr 15, 2021, at 10:35 AM, Ivan Krylov wrote:
>
> Hello Ryan,
>
> Sorry for not responding right away -- it took me a while to remember
> what I meant back then :)
There was a long pause there, as I didn’t get to try out those debugging
instructions from Frederik right away. They worked great Happy for any
assistance whenever I can get it! Thanks!
Was able to get all of that output, though I wish I had a clue what any of it
meant. Let me know if there’s other stuff that would be helpful.
I should probably note that I’m running this as: ./R -d gdb-ia from within
$BUILDIR/bin. gdb-ia appears to be the Intel copy of gdb (they had their own
debugger but eliminated it sometime back).
> So far I can only say that you get the same ulimit -s of 8192 and
> R_CStackLimit of 8192 * 1024 * .95 that I get on my current machine
> (and now it's the stack size limit that's reached first, not expression
> depth limit). Let's try to get more information.
>
> When you get the SIGSEGV,
>
> 1) What does print $_siginfo._sifields._sigfault show? Try printing at
> least $_siginfo if the first command gives you an error.
(gdb) print $_siginfo._sifields._sigfault
$1 = {si_addr = 0x7f7fecf8, _addr_lsb = 0, _addr_bnd = {_lower =
0x9215f829ff58, _upper = 0x7f7fecf8}}
> 2) When you get the crash, is the body argument accessible? What does
> print *body show?
(gdb) print *body
$2 = {sxpinfo = {type = 21, scalar = 0, obj = 0, alt = 0, gp = 0, mark = 0,
debug = 0, trace = 0, spare = 0, gcgen = 0, gccls = 0,
named = 4, extra = 0}, attrib = 0x16fa4f0, gengc_next_node = 0x3eb7710,
gengc_prev_node = 0x3eb7780, u = {primsxp = {offset = 44368248},
symsxp = {pname = 0x2a50178, value = 0x1b66098, internal = 0x16fa4f0},
listsxp = {carval = 0x2a50178, cdrval = 0x1b66098,
tagval = 0x16fa4f0}, envsxp = {frame = 0x2a50178, enclos = 0x1b66098,
hashtab = 0x16fa4f0}, closxp = {formals = 0x2a50178,
body = 0x1b66098, env = 0x16fa4f0}, promsxp = {value = 0x2a50178, expr =
0x1b66098, env = 0x16fa4f0}}}
> 3) What are the addresses of the local variables when the crash
> happens? Specifically, what do the following commands show:
>
> print &codebase
> print &pc
> print R_CStackDir * (R_CStackStart - (uintptr_t)&codebase)
> print R_CStackDir * (R_CStackStart - (uintptr_t)&pc)
(gdb) print &codebase
$3 = (BCODE **) 0x7f7ff360
(gdb) print &pc
$4 = (BCODE **) 0x7f7ff358
(gdb) print R_CStackDir * (R_CStackStart - (uintptr_t)&codebase)
$5 = 18446744073701307232
(gdb) print R_CStackDir * (R_CStackStart - (uintptr_t)&pc)
$6 = 18446744073701307224
--
#BlackLivesMatter
|| \\UTGERS, |---*O*---
||_// the State | Ryan Novosielski - novos...@rutgers.edu
|| \\ University | Sr. Technologist - 973/972.0922 (2x0922) ~*~ RBHS Campus
|| \\of NJ | Office of Advanced Research Computing - MSB C630, Newark
`'
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 4.0.1-4.0.5 built with Intel Composer 19.0-19.1.1, error in "make check" on CentOS 7.7-7.9
> On Apr 16, 2021, at 12:12 PM, Ivan Krylov wrote:
>
> On Thu, 15 Apr 2021 22:46:56 +0000
> Ryan Novosielski wrote:
>
>> (gdb) print $_siginfo._sifields._sigfault
>> $1 = {
>> si_addr = 0x7f7fecf8, _addr_lsb = 0,
>> _addr_bnd = {_lower = 0x9215f829ff58, _upper = 0x7f7fecf8}
>> }
>
>> (gdb) print R_CStackDir * (R_CStackStart - (uintptr_t)&codebase)
>> $5 = 18446744073701307232
>
> Okay, this is clearly a stack overflow: the faulting address is close
> to addresses of other stack variables, and the stack usage, calculated
> manually as 140737488207872 - 0x7f7ff360, is 8244392, which is
> above the (7969177), but the value that gdb gives you looks really
> strange. I could only get that value when I calculated
> -1 * (140737488207872 - 0x7f7ff360) and reinterpreted it as
> unsigned.
>
> What is the value of R_CStackDir at the moment of crash? Could it have
> somehow became -1 despite the stack growing down?
Well it definitely somehow could have, since it did:
Program received signal SIGSEGV, Segmentation fault.
bcEval.R (body=0x3eb7748, rho=0x3f72770, useCache=TRUE) at
/scratch/novosirj/install-files/R-4.0.5/src/main/eval.c:6478
6478 codebase = pc = BCCODE(body);
(gdb) print R_CStackDir
$1 = -1
--
#BlackLivesMatter
|| \\UTGERS, |---*O*---
||_// the State | Ryan Novosielski - novos...@rutgers.edu
|| \\ University | Sr. Technologist - 973/972.0922 (2x0922) ~*~ RBHS Campus
|| \\of NJ | Office of Advanced Research Computing - MSB C630, Newark
`'
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 4.0.1-4.0.5 built with Intel Composer 19.0-19.1.1, error in "make check" on CentOS 7.7-7.9
> On Apr 16, 2021, at 2:32 PM, Ivan Krylov wrote:
>
> On Fri, 16 Apr 2021 18:06:51 +0000
> Ryan Novosielski wrote:
>
>> Well it definitely somehow could have, since it did
>
> Wow! This is strange, but at least it should be easy to fix. Try editing
> the config.site file in the root of the R source directory and setting
> R_C_STACK_DIRECTION=down there. (Make sure to uncomment the line!)
> Re-run .../configure, make sure that src/include/config.h contains
> #define C_STACK_DIRECTION 1 and build R again.
>
> Does the crash go away?
Will give it a shot, thanks, that’s great!
> If it does, are you interested in finding out
> what went wrong in the configure test for stack direction?
I’m interested in putting in the time to make this build/the tests succeed for
anyone else who wants to use R with the Intel Parallel Studio/oneAPI for sure.
I’m not actually sure whether it makes much difference, vs. gcc, beyond using
the MKL for BLAS/LAPACK, but we do pay for this compiler, and try to use it
anytime we might get a slight boost out of it. One of the reasons too is that
it can do auto-vectorization and build fat binaries for the various processor
instruction sets. I don’t know how much that matters in R either, but if we can
get the best performance out of our system-wide install from that, we want to
do it.
> There are lines in m4/R.m4 that I'm not sure I understand:
>
>if test ${?} = 1; then
> r_cv_cstack_direction=down
>elif test ${?} = 1; then
> r_cv_cstack_direction=up
>fi
>
> How can elif branch have the same condition as the if branch? Shouldn't
> the second test had been for $? = 255? On the other hand, if the elif
> branch was never taken, how did R_CStackDir become -1?
IANAm4P, but that does seem like a pretty good question. I guess there’s
probably some mode of m4 I could run against that and see if there’s any
indication?
--
#BlackLivesMatter
|| \\UTGERS, |---*O*---
||_// the State | Ryan Novosielski - novos...@rutgers.edu
|| \\ University | Sr. Technologist - 973/972.0922 (2x0922) ~*~ RBHS Campus
|| \\of NJ | Office of Advanced Research Computing - MSB C630, Newark
`'
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 4.0.1-4.0.5 built with Intel Composer 19.0-19.1.1, errors in "make check" on CentOS 7.7-7.9
> On Apr 16, 2021, at 2:32 PM, Ivan Krylov wrote: > > On Fri, 16 Apr 2021 18:06:51 +0000 > Ryan Novosielski wrote: > >> Well it definitely somehow could have, since it did > > Wow! This is strange, but at least it should be easy to fix. Try editing > the config.site file in the root of the R source directory and setting > R_C_STACK_DIRECTION=down there. (Make sure to uncomment the line!) > Re-run .../configure, make sure that src/include/config.h contains > #define C_STACK_DIRECTION 1 and build R again. > > Does the crash go away? So, it does, and no other crashes, though the checks fail in a couple of places, and the final status is error: in tests/reg-tests-1d.R, and also reg-packages.R (those are the only two that have .Rout.fail files). make[3]: Entering directory `/scratch/novosirj/install-files/R-4.0.5-intel-19.1-build/tests' running code in '/scratch/novosirj/install-files/R-4.0.5/tests/array-subset.R' ... OK running code in '/scratch/novosirj/install-files/R-4.0.5/tests/reg-tests-1a.R' ... OK running code in '/scratch/novosirj/install-files/R-4.0.5/tests/reg-tests-1b.R' ... OK running code in '/scratch/novosirj/install-files/R-4.0.5/tests/reg-tests-1c.R' ... OK running code in '/scratch/novosirj/install-files/R-4.0.5/tests/reg-tests-1d.R' ...make[3]: *** [reg-tests-1d.Rout] Error 1 running code in '/scratch/novosirj/install-files/R-4.0.5/tests/reg-tests-2.R' ... OK comparing 'reg-tests-2.Rout' to '/scratch/novosirj/install-files/R-4.0.5/tests/reg-tests-2.Rout.save' ... OK running code in '/scratch/novosirj/install-files/R-4.0.5/tests/reg-examples1.R' ... OK running code in '/scratch/novosirj/install-files/R-4.0.5/tests/reg-examples2.R' ... OK running code in '/scratch/novosirj/install-files/R-4.0.5/tests/reg-packages.R' ...make[3]: *** [reg-packages.Rout] Error 1 running code in '/scratch/novosirj/install-files/R-4.0.5/tests/p-qbeta-strict-tst.R' ... OK running code in '/scratch/novosirj/install-files/R-4.0.5/tests/r-strict-tst.R' ... OK running code in '/scratch/novosirj/install-files/R-4.0.5/tests/reg-IO.R' ... OK comparing 'reg-IO.Rout' to '/scratch/novosirj/install-files/R-4.0.5/tests/reg-IO.Rout.save' ... OK running code in '/scratch/novosirj/install-files/R-4.0.5/tests/reg-IO2.R' ... OK comparing 'reg-IO2.Rout' to '/scratch/novosirj/install-files/R-4.0.5/tests/reg-IO2.Rout.save' ... OK running code in '/scratch/novosirj/install-files/R-4.0.5/tests/reg-plot.R' ... OK comparing 'reg-plot.pdf' to '/scratch/novosirj/install-files/R-4.0.5/tests/reg-plot.pdf.save' ... OK running code in '/scratch/novosirj/install-files/R-4.0.5/tests/reg-S4-examples.R' ... OK running code in '/scratch/novosirj/install-files/R-4.0.5/tests/reg-BLAS.R' ... OK make[3]: Leaving directory `/scratch/novosirj/install-files/R-4.0.5-intel-19.1-build/tests' make[2]: *** [test-Reg] Error 2 make[2]: Leaving directory `/scratch/novosirj/install-files/R-4.0.5-intel-19.1-build/tests' make[1]: *** [test-all-basics] Error 1 make[1]: Target `check' not remade because of errors. make[1]: Leaving directory `/scratch/novosirj/install-files/R-4.0.5-intel-19.1-build/tests' make: *** [check] Error 2 I’m a little new to reading these results, so I’m not sure exactly what I’m looking for. I’ve shared them in the event that what I put in this e-mail is useless: reg-tests-1d.Rout.fail: https://rutgersconnect-my.sharepoint.com/:u:/g/personal/novosirj_oarc_rutgers_edu/EYK2JHWQ1-9Dvu6gK9lrkRIBkEyA4QqkeH7C4gmbAYyBBQ?e=lfGJL7 reg-packages.Rout.fail: https://rutgersconnect-my.sharepoint.com/:u:/g/personal/novosirj_oarc_rutgers_edu/EazCjI6fRnNKhQASFPeySBUBENVpCqCljFg3-sokBZJnAw?e=8lwywe Anyhow, there appear to be a number of places, if I have this right: [novosirj@amarel-test2 tests]$ grep -i -B2 ^error reg-packages.Rout.fail building package exSexpr ... Converting Rd files to LaTeX Error in texi2dvi(file = file, pdf = TRUE, clean = clean, quiet = quiet, : pdflatex is not available Error in texi2dvi(file = file, pdf = TRUE, clean = clean, quiet = quiet, : pdflatex is not available Error in running tools::texi2pdf() -- Hmm ... looks like a package Creating pdf output from LaTeX ... Error: R CMD build failed (no tarball) for package exSexpr These maybe seem like they’re OK, and if I don’t have pdf2latex, they’re expected? Unless I should be looking for something else other than “^Error”. That seemed like the only place something could be going wrong. For the regression tests, these seem like some of them are actual problems, but maybe someone here knows if some are expected? [novosirj@amarel-test2 R-4.0.5-intel-19.1-build]$ grep -i -B2 "Asserted error" tests/reg-tests-1d.R
Re: [Rd] R 4.0.1-4.0.5 built with Intel Composer 19.0-19.1.1, errors in "make check" on CentOS 7.7-7.9
> On Apr 17, 2021, at 5:52 AM, Ivan Krylov wrote: > > On Sat, 17 Apr 2021 00:13:42 +0000 > Ryan Novosielski wrote: > >> reg-tests-1d.Rout.fail: >> https://rutgersconnect-my.sharepoint.com/:u:/g/personal/novosirj_oarc_rutgers_edu/EYK2JHWQ1-9Dvu6gK9lrkRIBkEyA4QqkeH7C4gmbAYyBBQ?e=lfGJL7 >> reg-packages.Rout.fail: >> https://rutgersconnect-my.sharepoint.com/:u:/g/personal/novosirj_oarc_rutgers_edu/EazCjI6fRnNKhQASFPeySBUBENVpCqCljFg3-sokBZJnAw?e=8lwywe > > Sorry, these links seem to be asking me to log in. Could you try a > "paste bin" service like https://paste.debian.net/? Sorry about that; I had it set to totally public and tried with a private browser session, but I guess that’s “Awful365” for you. I tried actual Pastebin and it told me that the reg-tests-1d.Rout.fail was offensive. https://paste.debian.net says it’s too large. Let’s give that another whack; both are here: http://www.rnovosielski.ftml.net/r-project/ >> These maybe seem like they’re OK, and if I don’t have pdf2latex, >> they’re expected? > > I've never tried to build R without TeX Live installed. Is there > anything about LaTeX-less installation in 'R Installation and > Administration'? Doesn’t seem to be required unless you want PDF manuals, which I don’t really care about at all; if it were, I’d expect configure to mention that, though yes, I could have read the manual before I got started (by now, who knows, maybe I did; been building R for years). -- #BlackLivesMatter || \\UTGERS, |---*O*--- ||_// the State | Ryan Novosielski - novos...@rutgers.edu || \\ University | Sr. Technologist - 973/972.0922 (2x0922) ~*~ RBHS Campus || \\of NJ | Office of Advanced Research Computing - MSB C630, Newark `' __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] tzone DB lawsuit Implications for R-project?
Does anyone from core have a comment on the implications for the R-project on this: http://www.theregister.co.uk/2011/10/07/unix_time_zone_database_destroyed/ Given the inclusion of the TZ database with R as well as the functionality used by R, is this something that the FSF is looking at yet? Best,Jeff __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] readRDS and saveRDS
I'd second this. Though my thinking was to add writeRDS instead of saveRDS. Jeff On Tue, Oct 18, 2011 at 8:37 AM, Hadley Wickham wrote: > Hi all, > > Is there any chance that readRDS and saveRDS might one day become > read.rds and write.rds? That would make them more consistent with the > other reading and writing functions. > > Hadley > > -- > Assistant Professor / Dobelman Family Junior Chair > Department of Statistics / Rice University > http://had.co.nz/ > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Jeffrey Ryan jeffrey.r...@lemnica.com www.lemnica.com www.esotericR.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] readRDS and saveRDS
As load involves a side-effect, I would think that loadRDS is a bad idea. That said, read/write is far more consistent across all languages and internally with R than read/save is. My (worthless) vote is for writeRDS. Jeff On Tue, Oct 18, 2011 at 11:37 AM, Hadley Wickham wrote: >>> Is there any chance that readRDS and saveRDS might one day become >>> read.rds and write.rds? That would make them more consistent with the >>> other reading and writing functions. >> >> Ending names in .foo is a bad idea because of the S3 naming conventions, so >> I think this is unlikely. But you can always create an alias yourself... > > It just makes teaching that much harder. We have the pairs: > > * read.csv and write.csv > * load and save > * readRDS and saveRDS > > Even loadRDS/saveRDS or readRDS/writeRDS would be better than the current > combo. > > Hadley > > -- > Assistant Professor / Dobelman Family Junior Chair > Department of Statistics / Rice University > http://had.co.nz/ > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Jeffrey Ryan jeffrey.r...@lemnica.com www.lemnica.com www.esotericR.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Efficiency of factor objects
Or better still, extend R via the mechanisms in place. Something akin to a fast factor package. Any change to R causes downstream issues in (hundreds of?) millions of lines of deployed code. It almost seems hard to fathom that a package for this doesn't already exist. Have you searched CRAN? Jeff On Sat, Nov 5, 2011 at 11:30 AM, Milan Bouchet-Valat wrote: > Le vendredi 04 novembre 2011 à 19:19 -0400, Stavros Macrakis a écrit : >> R factors are the natural way to represent factors -- and should be >> efficient since they use small integers. But in fact, for many (but >> not all) operations, R factors are considerably slower than integers, >> or even character strings. This appears to be because whenever a >> factor vector is subsetted, the entire levels vector is copied. > Is it so common for a factor to have so many levels? One can probably > argue that, in that case, using a numeric or character vector is > preferred - factors are no longer the "natural way" of representing this > kind of data. > > Adding code to fix a completely theoretical problem is generally not a > good idea. I think you'd have to come up with a real use case to hope > convincing the developers a change is needed. There are probably many > more interesting areas where speedups can be gained than that. > > > Regards > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Jeffrey Ryan jeffrey.r...@lemnica.com www.lemnica.com www.esotericR.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] seq.Date bug?
format(ISOdate(2012,1:12,1),"%b-%Y") [1] "Jan-2012" "Feb-2012" "Mar-2012" "Apr-2012" "May-2012" "Jun-2012" [7] "Jul-2012" "Aug-2012" "Sep-2012" "Oct-2012" "Nov-2012" "Dec-2012" First of the month is just as clean, and AFAIR they all have a first ;-) Jeff On Tue, Jan 31, 2012 at 2:37 PM, Dirk Eddelbuettel wrote: > > On 31 January 2012 at 15:17, Duncan Murdoch wrote: > | On 12-01-31 2:56 PM, Dirk Eddelbuettel wrote: > | > > | > R> seq(as.Date(Sys.Date()), by="-1 months", length=6) > | > [1] "2012-01-31" "2011-12-31" "2011-12-01" "2011-10-31" "2011-10-01" > "2011-08-31" > | > R> > | > > | > Notice how October appears twice. > | > | > > | > Now, date arithmetic is gruesome but the documentation for seq.Date et al > | > does not hint it wouldn't honour the by= argument. So a bug, or merely a > | > somewhat less than desirable features. > | > | It is giving you Jan 31, Dec 31, Nov 31, Oct 31, Sep 31, Aug 31 -- > | except some of those months don't have 31 days, so it is converting > | those dates to ones that really exist. (This is documented in ?seq.POSIXt.) > | > | Isn't this what you asked for? > > No as I was feeding this into format(..., "%b-%y") to create 'pretty' names, > and the double entries screw that. > > Morale: pick a mid-month date, and shift that. > > Dirk > > | Duncan Murdoch > | > | > | > > | > (And yes, I think I know that Hadley's lubridate has code for this too, > but > | > so may my RcppBDT which is sitting on top of Boost::DateTime code ...) > | > > | > Dirk > | > > | > > -- > "Outside of a dog, a book is a man's best friend. Inside of a dog, it is too > dark to read." -- Groucho Marx > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Jeffrey Ryan jeffrey.r...@lemnica.com www.lemnica.com www.esotericR.com R/Finance 2012: Applied Finance with R www.RinFinance.com See you in Chicago __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] which R package is used for browsing web pages through coding
Probably not R-devel, more likely R-help or google. Why not just use the 6+ solutions you have outlined and use R for what R is good at? Jeff On Fri, Feb 10, 2012 at 4:54 AM, sagarnikam123 wrote: > i know RCurl pakage to retrieve web content,it has limited use, i want > interactive package like > > (in perl--->Mechanize, > In java--->Watij,Prowser,HTMLunit,HTTPunit, > in Ruby>Watir ,etc) > > this modules/packages opens appropriate browser,which can create > queries,retrieves output, clicks buttons, fill up form > automatically,searches keyword in search engine, Downloads many items from > internet > All this is by coding > > if find ,kindly give me sample examples(codes) at list two/five > if not found,give me RCurl's sample codes starting from how to import > library to closing browser, > with explanation for each line of code > > > -- > View this message in context: > http://r.789695.n4.nabble.com/which-R-package-is-used-for-browsing-web-pages-through-coding-tp4375909p4375909.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 -- Jeffrey Ryan jeffrey.r...@lemnica.com www.lemnica.com www.esotericR.com R/Finance 2012: Applied Finance with R www.RinFinance.com See you in Chicago __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Identical copy of base function
Doesn't this also mean that if Matrix is loaded first, det() will be calling Matrix::determinant, which could be quite surprising change in behavior from expectation? This seems rather dangerous and 'untrustworthy' to me - unless I am missing some other hidden mechanism involved here. I haven't read the code yet, and I am sure Matrix will "do the right thing", but I have strong reservations about this behavior when applied to the general universe of R and CRAN. Jeff On Mon, Feb 27, 2012 at 6:03 AM, Martin Maechler wrote: >>>>>> Matthew Dowle >>>>>> on Mon, 27 Feb 2012 09:59:43 + writes: > > > Hello, > > > Regarding this in R-devel/NEWS/New features : > > > o 'library(pkg)' no longer warns about a conflict with a > > function from 'package:base' if the function is an > > identical copy of the base one but with a different > > environment. > > > Why would one want an identical copy in a different > > environment? I'm thinking I may be missing out on a trick > > here. > > Yes, you are ;-) The trick is called ``namespace'' : > > One example which lead me to implement the above: > > The Matrix package has had an identical copy of 'det' for a > while now, but of course in the Matrix namespace. > Because of that, the call to determinant() inside det() will > correctly dispatch Matrix methods for determinant(), whereas > base::det() would not. > > Martin > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Jeffrey Ryan jeffrey.r...@lemnica.com www.lemnica.com www.esotericR.com R/Finance 2012: Applied Finance with R www.RinFinance.com See you in Chicago __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Identical copy of base function
On Mon, Feb 27, 2012 at 9:19 AM, Martin Maechler
wrote:
>>>>>> Jeffrey Ryan
>>>>>> on Mon, 27 Feb 2012 07:39:32 -0600 writes:
>
> > Doesn't this also mean that if Matrix is loaded first,
> > det() will be calling Matrix::determinant, which could be
> > quite surprising change in behavior from expectation?
>
>
> > This seems rather dangerous and 'untrustworthy' to me -
> > unless I am missing some other hidden mechanism involved here.
>
> The only change in R-devel is that library() does not warn about
> *conflicts* in such a case.
Yes, I understand that is only the warning here - but what, aside from
hiding a conflict (which the user may *indeed* care about), does this
accomplish?
To me, a conflict is something to be aware of - hiding it is where I
become concerned.
Without warning, one R script may run differently now depending on
packages loaded, and not just package functions explicitly called by
the script. Without the warning I can envision countless hours
attempting to debug errors - if one is lucky enough to note the change
in behavior.
Behavioral changes can also related to performance. I had seen this
previously with some cbind behavior when the S4 variant from
package:methods overwrote the (much faster) base::cbind by a package
which I will not name (and has since been fixed).
Jeff
> This behavior (and the R code in library()'s checkConflicts())
> is completely analogous to
> importFrom("base", det)
> export(det)
> but as you surely know, we can not (yet?) import from base.
>
> So again: No changed behavior of R, just some warnings less in a
> case where they are typically inappropriate.
>
> > I haven't read the code yet, and I am sure Matrix will "do
> > the right thing", but I have strong reservations about
> > this behavior when applied to the general universe of R
> > and CRAN.
>
> > Jeff
>
> > On Mon, Feb 27, 2012 at 6:03 AM, Martin Maechler
> > wrote:
> >>>>>>> Matthew Dowle on Mon,
> >>>>>>> 27 Feb 2012 09:59:43 + writes:
> >>
> >> > Hello,
> >>
> >> > Regarding this in R-devel/NEWS/New features :
> >>
> >> > o 'library(pkg)' no longer warns about a conflict
> >> with a > function from 'package:base' if the function
> >> is an > identical copy of the base one but with a
> >> different > environment.
> >>
> >> > Why would one want an identical copy in a different
> >> > environment? I'm thinking I may be missing out on a
> >> trick > here.
> >>
> >> Yes, you are ;-) The trick is called ``namespace'' :
> >>
> >> One example which lead me to implement the above:
> >>
> >> The Matrix package has had an identical copy of 'det' for
> >> a while now, but of course in the Matrix namespace.
> >> Because of that, the call to determinant() inside det()
> >> will correctly dispatch Matrix methods for determinant(),
> >> whereas base::det() would not.
> >>
> >> Martin
> >>
> >> __
> >> R-devel@r-project.org mailing list
> >> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
>
> > --
> > Jeffrey Ryan jeffrey.r...@lemnica.com
>
> > www.lemnica.com www.esotericR.com
>
> > R/Finance 2012: Applied Finance with R www.RinFinance.com
>
> > See you in Chicago
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Jeffrey Ryan
jeffrey.r...@lemnica.com
www.lemnica.com
www.esotericR.com
R/Finance 2012: Applied Finance with R
www.RinFinance.com
See you in Chicago
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Julia
Doug, Agreed on the interesting point - looks like it has some real promise. I think the spike in interest could be attributable to Mike Loukides's tweet on Feb 20. (editor at O'Reilly) https://twitter.com/#!/mikeloukides/status/171773229407551488 That is exactly the moment I stumbled upon it. Jeff On Thu, Mar 1, 2012 at 11:06 AM, Douglas Bates wrote: > My purpose in mentioning the Julia language (julialang.org) here is > not to start a flame war. I find it to be a very interesting > development and others who read this list may want to read about it > too. > > It is still very much early days for this language - about the same > stage as R was in 1995 or 1996 when only a few people knew about it - > but Julia holds much potential. There is a thread about "R and > statistical programming" on groups.google.com/group/julia-dev. As > always happens, there is a certain amount of grumbling of the "R IS > S SLW" flavor but there is also some good discussion regarding > features of R (well, S actually) that are central to the language. > (Disclaimer: I am one of the participants discussing the importance of > data frames and formulas in R.) > > If you want to know why Julia has attracted a lot of interest very > recently (like in the last 10 days), as a language it uses multiple > dispatch (like S4 methods) with methods being compiled on the fly > using the LLVM (http://llvm.org) infrastructure. In some ways it > achieves the Holy Grail of languages like R, Matlab, NumPy, ... in > that it combines the speed of compiled languages with the flexibility > of the high-level interpreted language. > > One of the developers, Jeff Bezanson, gave a seminar about the design > of the language at Stanford yesterday, and the video is archived at > http://www.stanford.edu/class/ee380/. You don't see John Chambers on > camera but I am reasonably certain that a couple of the questions and > comments came from him. > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Jeffrey Ryan jeffrey.r...@lemnica.com www.lemnica.com www.esotericR.com R/Finance 2012: Applied Finance with R www.RinFinance.com See you in Chicago __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] CRAN policies
Is there a distinction as to NOTE vs. WARNING that is documented? I've always assumed (wrongly?) that NOTES weren't an issue with publishing on CRAN, but that they may change to WARNINGS at some point. Is the process by which this happens documented somewhere? Jeff On 3/27/12 11:09 AM, "Gabor Grothendieck" wrote: >2012/3/27 Uwe Ligges : >> >> >> On 27.03.2012 17:09, Gabor Grothendieck wrote: >>> >>> On Tue, Mar 27, 2012 at 7:52 AM, Prof Brian Ripley >>> wrote: CRAN has for some time had a policies page at http://cran.r-project.org/web/packages/policies.html and we would like to draw this to the attention of package maintainers. In particular, please - always send a submission email to c...@r-project.org with the package name and version on the subject line. Emails sent to individual members of the team will result in delays at best. - run R CMD check --as-cran on the tarball before you submit it. Do this with the latest version of R possible: definitely R 2.14.2, preferably R 2.15.0 RC or a recent R-devel. (Later versions of R are able to give better diagnostics, e.g. for compiled code and especially on Windows. They may also have extra checks for recently uncovered problems.) Also, please note that CRAN has a very heavy workload (186 packages were published last week) and to remain viable needs package maintainers to make its life as easy as possible. >>> >>> Regarding the part about "warnings or significant notes" in that page, >>> its impossible to know which notes are significant and which ones are >>> not significant except by trial and error. >> >> >> >> Right, it needs human inspection to identify false positives. We believe >> most package maintainers are able to see if he or she is hit by such a >>false >> positive. > >The problem is that a note is generated and the note is correct. Its >not a false positive. But that does not tell you whether its >"significant" or not. There is no way to know. One can either try to >remove all notes (which may not be feasible) or just upload it and by >trial and error find out if its accepted or not. > >-- >Statistics & Software Consulting >GKX Group, GKX Associates Inc. >tel: 1-877-GKX-GROUP >email: ggrothendieck at gmail.com > >__ >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
Re: [Rd] CRAN policies
Thanks Uwe for the clarification on what goes and what stays. Still fuzzy on the notion of "significant" though. Do you have an example or two for the list? Jeff P.S. I meant to also thank all of CRAN volunteers for the momentous efforts involved, and it is nice to see some explanation of how we can help, as well as a peek into what goes on 'behind the curtain' ;-) On 3/27/12 1:19 PM, "Uwe Ligges" wrote: > > >On 27.03.2012 19:10, Jeffrey Ryan wrote: >> Is there a distinction as to NOTE vs. WARNING that is documented? I've >> always assumed (wrongly?) that NOTES weren't an issue with publishing on >> CRAN, but that they may change to WARNINGS at some point. > >We won't kick packages off CRAN for Notes (but we will if Warnings are >not fixed), but we may not accept new submissions with significant Notes. > >Best, >Uwe Ligges > > > >> Is the process by which this happens documented somewhere? >> >> Jeff >> >> On 3/27/12 11:09 AM, "Gabor Grothendieck" >>wrote: >> >>> 2012/3/27 Uwe Ligges: >>>> >>>> >>>> On 27.03.2012 17:09, Gabor Grothendieck wrote: >>>>> >>>>> On Tue, Mar 27, 2012 at 7:52 AM, Prof Brian Ripley >>>>>wrote: >>>>>> >>>>>> CRAN has for some time had a policies page at >>>>>> http://cran.r-project.org/web/packages/policies.html >>>>>> and we would like to draw this to the attention of package >>>>>> maintainers. >>>>>> In >>>>>> particular, please >>>>>> >>>>>> - always send a submission email to c...@r-project.org with the >>>>>> package >>>>>> name and version on the subject line. Emails sent to individual >>>>>> members >>>>>> of >>>>>> the team will result in delays at best. >>>>>> >>>>>> - run R CMD check --as-cran on the tarball before you submit it. Do >>>>>> this with the latest version of R possible: definitely R 2.14.2, >>>>>> preferably R 2.15.0 RC or a recent R-devel. (Later versions of R >>>>>>are >>>>>> able to give better diagnostics, e.g. for compiled code and >>>>>>especially >>>>>> on Windows. They may also have extra checks for recently uncovered >>>>>> problems.) >>>>>> >>>>>> Also, please note that CRAN has a very heavy workload (186 packages >>>>>> were >>>>>> published last week) and to remain viable needs package maintainers >>>>>>to >>>>>> make >>>>>> its life as easy as possible. >>>>>> >>>>> >>>>> Regarding the part about "warnings or significant notes" in that >>>>>page, >>>>> its impossible to know which notes are significant and which ones are >>>>> not significant except by trial and error. >>>> >>>> >>>> >>>> Right, it needs human inspection to identify false positives. We >>>>believe >>>> most package maintainers are able to see if he or she is hit by such a >>>> false >>>> positive. >>> >>> The problem is that a note is generated and the note is correct. Its >>> not a false positive. But that does not tell you whether its >>> "significant" or not. There is no way to know. One can either try to >>> remove all notes (which may not be feasible) or just upload it and by >>> trial and error find out if its accepted or not. >>> >>> -- >>> Statistics& Software Consulting >>> GKX Group, GKX Associates Inc. >>> tel: 1-877-GKX-GROUP >>> email: ggrothendieck at gmail.com >>> >>> __ >>> 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
Re: [Rd] Using other peoples packages from within C-based R-extension
This link may be of help as well... https://stat.ethz.ch/pipermail/r-devel/2008-November/051262.html HTH Jeff On 4/24/12 12:35 PM, "oliver" wrote: >Hello, > >OK, thanks for the information... > > >On Tue, Apr 24, 2012 at 12:02:33PM -0500, Dirk Eddelbuettel wrote: >> >> On 24 April 2012 at 12:39, Duncan Murdoch wrote: >> | On 24/04/2012 12:31 PM, oliver wrote: >> | > Hello, >> | > >> | > what if I want to write a package mixed R/C-extension >> | > and want to use code that is provided by other peoples packages? >> | > >> | > How for example can I use one of the provided wavelet packages >> | > from within my C-based R-extension? >> | > >> | > Somehow I would need to load the other packages and have access to >>the >> | > functions they provide. >> | > I mean I don't want to use the other packages via R-level, but >>directly >> | > on the C-layer. Something like shared libs (dlopen and such stuff) >> | > but via R-API. >> | > >> | > Is there a general aproach to this, and how to do it? >> | >> | See "Registering native routines" in the Writing R Extensions manual. >> >> And there are over 120 packages providing access: >> >>CITAN Cubist GOSim KernSmooth MASS MSBVAR Matrix NetComp PMA >>PopGenome >>QuACN RCurl RODBC RTextTools Rcpp Rigroup Rlabkey Rmosek Rmpfr Rook >>Rserve >>Runuran SASxport SMCP SoDA TraMineR XML actuar adaptivetau akima >>aster >>aster2 bcv bda blme boolfun bstats canvas caret catnet cgh chron >>class >>climdex.pcic clpAPI clue cluster copula cplexAPI cplm datamap devEMF >>edesign expm fastICA fastcluster ff flsa foreign fracdiff >>fuzzyRankTests >>gb glpkAPI gmp gputools grpreg gsmoothr heavy hypred ifs ifultools >>int64 >>interactivity kza lattice lfe lme4 locfit lpSolveAPI markdown mgcv >>minqa >>mugnet ncvreg nlme nnet pedigreemm phangorn phmm potts ppstat qtbase >>qtpaint quadprog rPorta randtoolbox rcdd rdyncall rgeos rggobi >>rmongodb >>rngWELL robustbase rpart rphast rrp rtfbs sde sensitivityPStrat sp >>spatial >>spdep spsurvey spt tree tripack uncompress vines xlsReadWrite xts >>yaml zoo >[...] > >But no wavelets stuff... (?) >(It was more than an example, I'm look for wavelet decompositioning.) > > >> >> Matrix and lme4 is the prototypical example by R Core, MASS also >>provides >> something. I'd probably start with zoo and xts ... >[...] > >You mean with "start with" that I could look how to allow exporting >for my own package? > >At the moment I'm rather looking for how to import symbols and access >fnuctionality >of othera people's packages ... > > >Ciao, > Oliver > >__ >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
Re: [Rd] fast version of split.data.frame or conversion from data.frame to list of its rows
A bit late and possibly tangential.
The mmap package has something called struct() which is really a row-wise array
of heterogenous columns.
As Simon and others have pointed out, R has no way to handle this natively, but
mmap does provide a very measurable performance gain by orienting rows together
in memory (mapped memory to be specific). Since it is all "outside of R" so to
speak, it (mmap) even supports many non-native types, from bit vectors to 64
bit ints with conversion caveats applicable.
example(struct) shows some performance gains with this approach.
There are even some crude methods to convert as is data.frames to mmap struct
object directly (hint: as.mmap)
Again, likely not enough to shoehorn into your effort, but worth a look to see
if it might be useful, and/or see the C design underlying it.
Best,
Jeff
Jeffrey Ryan|Founder|jeffrey.r...@lemnica.com
www.lemnica.com
On May 1, 2012, at 1:44 PM, Antonio Piccolboni wrote:
> On Tue, May 1, 2012 at 11:29 AM, Simon Urbanek
> wrote:
>
>>
>> On May 1, 2012, at 1:26 PM, Antonio Piccolboni
>> wrote:
>>
>>> It seems like people need to hear more context, happy to provide it. I am
>>> implementing a serialization format (typedbytes, HADOOP-1722 if people
>> want
>>> the gory details) to make R and Hadoop interoperate better (RHadoop
>>> project, package rmr). It is a row first format and it's already
>>> implemented as a C extension for R for lists and atomic vectors, where
>> each
>>> element of a vector is a row. I need to extend it to accept data frames
>>> and I was wondering if I can use the existing C code by converting a data
>>> frame to a list of its rows. It sounds like the answer is that it is not
>> a
>>> good idea,
>>
>> Just think about it -- data frames are lists of *columns* because the type
>> of each column is fixed. Treating them row-wise is extremely inefficient,
>> because you can't use any vector type to represent such thing (other than a
>> generic vector containing vectors of length 1).
>>
>
> Thanks, let's say this together with the experiments and other converging
> opinions lays the question to rest.
>
>
>>> that's helpful too in a way because it restricts the options. I
>>> thought I may be missing a simple primitive, like a t() for data frames
>>> (that doesn't coerce to matrix).
>>
>> See above - I think you are misunderstanding data frames - t() makes no
>> sense for data frames.
>>
>
> I think you are misunderstanding my use of t(). Thanks
>
>
> Antonio
>
>
>>
>> Cheers,
>> Simon
>>
>>
>>
>>> On Tue, May 1, 2012 at 5:46 AM, Prof Brian Ripley >> wrote:
>>>
>>>> On 01/05/2012 00:28, Antonio Piccolboni wrote:
>>>>
>>>>> Hi,
>>>>> I was wondering if there is anything more efficient than split to do
>> the
>>>>> kind of conversion in the subject. If I create a data frame as in
>>>>>
>>>>> system.time({fd = data.frame(x=1:2000, y = rnorm(2000), id =
>> paste("x",
>>>>> 1:2000, sep =""))})
>>>>> user system elapsed
>>>>> 0.004 0.000 0.004
>>>>>
>>>>> and then I try to split it
>>>>>
>>>>> system.time(split(fd, 1:nrow(fd)))
>>>>>>
>>>>> user system elapsed
>>>>> 0.333 0.031 0.415
>>>>>
>>>>>
>>>>> You will be quick to notice the roughly two orders of magnitude
>> difference
>>>>> in time between creation and conversion. Granted, it's not written
>>>>> anywhere
>>>>>
>>>>
>>>> Unsurprising when you create three orders of magnitude more data frames,
>>>> is it? That's a list of 2000 data frames. Try
>>>>
>>>> system.time(for(i in 1:2000) data.frame(x = i, y = rnorm(1), id =
>>>> paste0("x", i)))
>>>>
>>>>
>>>>
>>>> that they should be similar but the latter seems interpreter-slow to me
>>>>> (split is implemented with a lapply in the data frame case) There is
>> also
>>>>> a
>>>>> memory issue when I hit about 2 elements (allocating 3GB when
>>>>> interrupted). So before I resort to Rcpp, despite the electrifying
>> feeling
>>>>> of approaching the bare met
[Rd] Capturing signals from within external libs
I have a continuous loop running in an external library that I am calling
from C (R API). This loop is processing events in real time with the
possibility of significant lag between events.
When processing an event, I can make use of R_CheckUserInterrupt, but
while the external library code is waiting on a new event, I don't have an
opportunity to call this - my entry points are only on events.
I can capture a SIGINT by redefining signal(SIGINT, myhandler) before
calling the lib, but I am somewhat at a loss in terms of what I can do
within the handler that would let me pass control back to R.
void myhandler (int s) {
error("interrupt caught!");
}
Works, but I am sure it isn't supposed to. In fact I know it is wrong,
since after interrupting once SIGINTs are subsequently ignored, even if I
reset the signal to the original one (as returned by the first call to
signal).
Currently I can exit(1) of course, but that is tragically bad form IMO,
though will work in my situation.
In short, what is the proper way to handle SIGINT in external code that is
called from R, that allows R to handle the signal. Thoughts or
suggestions appreciated.
Thanks,
Jeff
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Capturing signals from within external libs
Simon,
Thanks for the clarifying example. I fear my current set up fails the
test for 'no R calls', so I think I am stuck on the ugly variant for my
current challenge, but I will be able to use this in other places.
Thanks again,
Jeff
On 5/22/12 4:45 PM, "Simon Urbanek" wrote:
>Jeff,
>
>On May 22, 2012, at 4:31 PM, Jeffrey Ryan wrote:
>
>> I have a continuous loop running in an external library that I am
>>calling
>> from C (R API). This loop is processing events in real time with the
>> possibility of significant lag between events.
>>
>> When processing an event, I can make use of R_CheckUserInterrupt, but
>> while the external library code is waiting on a new event, I don't have
>>an
>> opportunity to call this - my entry points are only on events.
>>
>
>Assuming that while in the library there are no R calls (important!), you
>can use setjmp/longjmp to branch your code depending on whether you raise
>an interrupt or not (see below). This also makes sure that you process
>things on the R side properly
>
>Another alternative is to run your library call on a separate thread and
>have R wait for the result. In that case you don't need to mess with
>interrupts since your library code will run separately from R. The
>downside is that you need to mess with threads which may or may not be an
>issue depending on the complexity of your code and whether you want it to
>be cross-platform or not.
>
>Cheers,
>Simon
>
>
>Example code:
>
>#include
>#include
>#include
>
>#include
>#include /* only needed if you use
>R_interrupts_pending */
>
>static jmp_buf jenv;
>
>static void my_int(int sig) {
> longjmp(jenv, 1); /* this also restores the interrupt handlers */
>}
>
>SEXP my_R_function(...) {
>
>if (setjmp(jenv) == 0) { /* enter your protected code */
> void (*old_sig)(int);
> old_sig = signal(SIGINT, my_int);
> /* call your library here */
> /* restore original INT handler */
> signal(SIGINT, old_sig);
>} else { /* this will get called on interrupt */
> /* you can do what you want - you're back to R-safe code here, so you
>can either raise an error or return from your function */
> /* if you want to trigger regular R interrupt handling, use this: */
> R_interrupts_pending = 1;
> R_CheckUserInterrupt();
> /* the above should not return */
>}
>
>
>
>> I can capture a SIGINT by redefining signal(SIGINT, myhandler) before
>> calling the lib, but I am somewhat at a loss in terms of what I can do
>> within the handler that would let me pass control back to R.
>>
>> void myhandler (int s) {
>> error("interrupt caught!");
>> }
>>
>> Works, but I am sure it isn't supposed to. In fact I know it is wrong,
>> since after interrupting once SIGINTs are subsequently ignored, even if
>>I
>> reset the signal to the original one (as returned by the first call to
>> signal).
>>
>> Currently I can exit(1) of course, but that is tragically bad form IMO,
>> though will work in my situation.
>>
>> In short, what is the proper way to handle SIGINT in external code that
>>is
>> called from R, that allows R to handle the signal. Thoughts or
>> suggestions appreciated.
>>
>> Thanks,
>> Jeff
>>
>> __
>> 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
Re: [Rd] Capturing signals from within external libs
Simon,
Very likely butchered my initial problem explanation. The issue is that I
make a call to a library, something like:
SEXP my_fun() {
...
CB = MyCallback("XYZ"); /* this contains callback functions that in turn
use R */
externalLibCall(CB); /* infinite loop that won't return as it is
capturing streaming data */
/* we never get here */
Return(R_NilValue);
}
My callbacks look something like
on_event_A () {
R_CheckUserInterrupt():
evalRFunctionFromC();
}
But event_A only gets called when a new message arrives. When a new
message arrives the on_event_A gets called from within the external
library code (hence calling R), but only when a message arrives.
At this point R_CheckUserInterrupt() works just fine. The problem is when
the external process is waiting on a new message. I have no entry to
check whether or not a message is available, nothing akin to select().
Basically I only get control in my callback when a new message happens.
So if there is no new message (in the context above it is a message/tick
from an exchange), the process spins/waits/not too sure what happens
internally, but the net result is I don't see anything. I am waiting. It
is at this point that I want to force an interrupt.
My current solution is just to redefine as my SIGINT handler before the
externalLibCall call, with an ungraceful exit() internal to it. Dirty,
but lets me break. In the ideal world I would be returned to the R prompt,
but it isn't overly critical in this application since it is being run
more or less headless as is.
The other problem, which makes me cringe of course, is that this is all
further complicated by the fact that it is not just C, but C++ and running
on Win64 ;-) I tried not to mention that of course ...
Your insights are very appreciated, and I now have further knowledge into
making this work in other applications, but my hope for this one is
dwindling.
Best,
Jeff
On 5/23/12 11:49 AM, "Simon Urbanek" wrote:
>
>On May 23, 2012, at 12:40 PM, Jeffrey Ryan wrote:
>
>> Simon,
>>
>> Thanks for the clarifying example. I fear my current set up fails the
>> test for 'no R calls',
>
>Well, but in that case you already have interrupt points so I'm not sure
>what is the problem? I thought the whole point is that you have long
>processing in some 3rd party library where you can't call R API so that's
>why you need the hack in the first place ...
>
>
>> so I think I am stuck on the ugly variant for my
>> current challenge, but I will be able to use this in other places.
>>
>> Thanks again,
>> Jeff
>>
>> On 5/22/12 4:45 PM, "Simon Urbanek" wrote:
>>
>>> Jeff,
>>>
>>> On May 22, 2012, at 4:31 PM, Jeffrey Ryan wrote:
>>>
>>>> I have a continuous loop running in an external library that I am
>>>> calling
>>>> from C (R API). This loop is processing events in real time with the
>>>> possibility of significant lag between events.
>>>>
>>>> When processing an event, I can make use of R_CheckUserInterrupt, but
>>>> while the external library code is waiting on a new event, I don't
>>>>have
>>>> an
>>>> opportunity to call this - my entry points are only on events.
>>>>
>>>
>>> Assuming that while in the library there are no R calls (important!),
>>>you
>>> can use setjmp/longjmp to branch your code depending on whether you
>>>raise
>>> an interrupt or not (see below). This also makes sure that you process
>>> things on the R side properly
>>>
>>> Another alternative is to run your library call on a separate thread
>>>and
>>> have R wait for the result. In that case you don't need to mess with
>>> interrupts since your library code will run separately from R. The
>>> downside is that you need to mess with threads which may or may not be
>>>an
>>> issue depending on the complexity of your code and whether you want it
>>>to
>>> be cross-platform or not.
>>>
>>> Cheers,
>>> Simon
>>>
>>>
>>> Example code:
>>>
>>> #include
>>> #include
>>> #include
>>>
>>> #include
>>> #include /* only needed if you use
>>> R_interrupts_pending */
>>>
>>> static jmp_buf jenv;
>>>
>>> static void my_int(int sig) {
>>> longjmp(jenv, 1); /* this also restores the interrupt handlers */
>>> }
>>>
>>> SEXP my_R_function(...) {
>>>
>>> if (setjmp(jenv) == 0) { /* enter your protected c
Re: [Rd] Negative years with strptime?
?as.Date
Why would pre years be handled correctly? The help file
explicitly states that they likely will not.
Note:
The default formats follow the rules of the ISO 8601 international
standard which expresses a day as ‘"2001-02-03"’.
If the date string does not specify the date completely, the
returned answer may be system-specific. The most common behaviour
is to assume that a missing year, month or day is the current one.
If it specifies a date incorrectly, reliable implementations will
give an error and the date is reported as ‘NA’. Unfortunately
some common implementations (such as ‘glibc’) are unreliable and
guess at the intended meaning.
Years before 1CE (aka 1AD) will probably not be handled correctly.
On Tue, Jul 10, 2012 at 4:59 PM, Rui Barradas wrote:
> Hello,
>
> Is there a bug with negative dates? Just see:
>
> seq(as.Date("-01-01"), length = 22, by = "-1 year")
> [1] "-01-01" "000/-01-01" "000.-01-01" "000--01-01" "000,-01-01"
> [6] "000+-01-01" "000*-01-01" "000)-01-01" "000(-01-01" "000'-01-01"
> [11] "00/0-01-01" "00//-01-01" "00/.-01-01" "00/--01-01" "00/,-01-01"
> [16] "00/+-01-01" "00/*-01-01" "00/)-01-01" "00/(-01-01" "00/'-01-01"
> [21] "00.0-01-01" "00./-01-01"
>
> See the year number: "after" the zero, i.e., downward from zero, the printed
> character is '/' which happens to be the ascii character before '0', and
> before it's '.', etc. This sequence gives the nine ascii characters before
> zero as last digit of the year, then the 10th is '0' as (now) expected, then
> goes to the second digit, etc.
>
> It seems to stop at the first 9, or else we would have some sort of real
> problem.
>
> Anyway, this doesn't look right.
>
> Rui Barradas
> Em 10-07-2012 22:17, Winston Chang escreveu:
>
>> Is there a way to make as.Date() and strptime() process strings with
>> negative years? It appears that Date objects can contain negative years
>> and
>> you can convert them to strings, but you can't convert them back to Date
>> objects.
>>
>>
>> x <- as.Date(c("0001-01-24", "0500-01-24"))
>> as.character(x)
>> # "0001-01-24" "0500-02-02"
>> as.Date(as.character(x))
>> # "0001-01-24" "0500-01-24"
>>
>> # Minus 391 days gives negative year
>> as.character(x - 391)
>> # "-001-12-30" "0498-12-29"
>>
>> # Can't convert this string back to Date
>> as.Date(as.character(x - 391))
>> # Error during wrapup: character string is not in a standard unambiguous
>> format
>>
>>
>> # as.Date.character uses strptime, so we can try using strptime directly
>> strptime(as.character(x), "%Y-%m-%d")
>> # "0001-01-24" "0500-01-24"
>>
>> strptime(as.character(x - 391), "%Y-%m-%d")
>> # NA "0498-12-29"
>>
>>
>> Thanks,
>> -Winston
>>
>> [[alternative HTML version deleted]]
>>
>> __
>> 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
--
Jeffrey Ryan
jeffrey.r...@lemnica.com
www.lemnica.com
www.esotericR.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] chown, chgrp?
library(pwned)? On Wed, Aug 15, 2012 at 10:56 AM, Barry Rowlingson wrote: > On Wed, Aug 15, 2012 at 2:47 PM, Simon Urbanek > wrote: > >> >> ... and moreover with the increasing adoption of ACL on unix and >> non-existence of uid/gid on Windows this is more an archaic curiosity so I >> don't think it makes sense to add it at this point. >> > > It does however raise the question, "What is Hadley up to now?" :) > > Barry > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Jeffrey Ryan jeffrey.r...@lemnica.com www.lemnica.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] include dll in R-package
Any package can link to external DLLs. You'll need to make that an explicit dependency, have some configure script and distribute the library somewhere else, but many packages on CRAN already do this. My RBerkeley uses a user installed Oracle Berkeley DB that is linked to at configure time, of course there are many other examples as well. And distributing _off_ CRAN is of course a reasonable alternative. HTH Jeff On Fri, Aug 24, 2012 at 9:21 AM, Kasper Daniel Hansen wrote: > On Fri, Aug 24, 2012 at 10:16 AM, Dirk Eddelbuettel wrote: > >> >> On 24 August 2012 at 09:06, LIYING HUANG wrote: >> | We have several projects in the center done by researchers over years >> | in Fortran, there are copy right issues etc to prevent us from >> >> | giving away the source codes, but a lot of social scientist are >> >> | interested to use the program. We tried to use dlls to make plugins >> | (available in our website) in various statistics platforms >> | (SAS, STATA and R) to make it available to general public. >> | >> | We used to be able to build R package using dll on version R-2.7.0, >> | , but failed to build with newer R version with the same source. >> | Any help is greatly appreciated. >> | >> | When I try to build R package for newer version of R, I could build >> | to get "lcca_1.0.0.tar.gz", but when I "R CMD check lcca_1.0.0.tar.gz", >> | I got error message as: >> | >> | * using log directory 'D:/project/LCCA/lcca.Rcheck' >> | * using R version 2.15.1 (2012-06-22) >> | * using platform: i386-pc-mingw32 (32-bit) >> | * using session charset: ISO8859-1 >> | * checking for file 'lcca/DESCRIPTION' ... OK >> | * checking extension type ... Package >> | * this is package 'lcca' version '1.0.0' >> | * checking package namespace information ... OK >> | * checking package dependencies ... OK >> | * checking if this is a source package ... OK >> | * checking if there is a namespace ... OK >> | * checking for executable files ... WARNING >> | Found the following executable file(s): >> | libs/lcca.dll >> | Source packages should not contain undeclared executable files. >> | See section 'Package structure' in the 'Writing R Extensions' manual. >> | * checking whether package 'lcca' can be installed ... ERROR >> >> This tells you that in order to have a proper package, you need to include >> the very source code you want to hide. >> >> This is a CRAN Policy decision enforced by current R versions (but not the >> rather old version you compared against), and there is now way around it. >> You could try to construct "defunct" packages lacking the DLLs and instruct >> the users to get them from somewhere else, but that is at the same rather >> error prone (as you will lack all the built-time checks you would have with >> source code, as well as a better assurrance that compatible tools are used) >> and distasteful as CRAN is about Open Source. >> >> So your best bet may be to go back to the copyright holders >> > > Dirk's comments are extremely relevant if you were hoping to host the > package on CRAN (which you basically won't be allowed to). You can still > distribute it from your institutions homepage I think. > > Kasper > > [[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Jeffrey Ryan jeffrey.r...@lemnica.com www.lemnica.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Arrays Partial unserialization
There is no such tool to my knowledge, though the mmap package can do very similar things. In fact, it will be able to do this exactly once I apply a contributed patch to handle endianess. The issue is that rds files are compressed by default, so directly reading requires uncompressing, which makes subset selection not possible, at least to the best of my knowledge of the compression algorithms in use. (BDR's reply after this one clarifies) What you can do though is writeBin by column, and read in incrementally. Take a look at the mmap package, specifically: example(mmap) example(struct) example(types) The struct one is quite useful for data.frame like structures on disk, including the ability to modify struct padding etc. This one is more row oriented, so lets you store various types in row-oriented fashion in one file. ?mmap.csv is an example function that will also let you read csv files directly into an 'mmap' form - and shows the 'struct' functionality. At some point I will write an article on all of this, but the vignette for mmap is illustrative of most of the value. The indexing package on R-forge (as well as talks about it given by me at useR 2010 and R/Finance 2012) may also be of use - though that is more 'database' rather than a more simplistic sequential stepping through data on disk. HTH Jeff On Fri, Aug 31, 2012 at 9:41 AM, Duncan Murdoch wrote: > On 31/08/2012 9:47 AM, Damien Georges wrote: >> >> Hi all, >> >> I'm working with some huge array in R and I need to load several ones to >> apply some functions that requires to have all my arrays values for each >> cell... >> >> To make it possible, I would like to load only a part (for example 100 >> cells) of all my arrays, apply my function, delete all cells loaded, >> loaded following cells and so on. >> >> Is it possible to unserialize (or load) only a defined part of an R array >> ? >> Do you know some tools that might help me? > > > I don't know of any tools to do that, but there are tools to maintain large > objects in files, and load only parts of them at a time, e.g. the ff > package. Or you could simply use readBin and writeBin to do the same > yourself. > >> >> Finally, I did lot of research to find the way array (and all other R >> object) are serialized into binary object, but I found nothing >> explaining really algorithms involved. If someone has some information >> on this topic, I'm interesting in. > > > You can read the source for this; it is in src/main/serialize.c. > > Duncan Murdoch > >> >> Hoping my request is understandable, >> >> All the best, >> >> Damien.G >> >> __ >> 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 -- Jeffrey Ryan jeffrey.r...@lemnica.com www.lemnica.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R crashes when printing a named numeric vector of a specific class - Bug?
print(x) in print.bar is calling print.bar again.
You need to do something like print(unclass(x))
HTH
Jeff
On Tue, Sep 11, 2012 at 9:53 AM, Basil Abou El-Komboz
wrote:
> Dear useR's,
>
> today I stumbled over an interesting phenomenon: First, I created a
> named numeric vector with a certain class and several attributes via the
> structure() function. After that, I implemented a simple print method
> for this class. When calling this function it produces an endless loop
> of print calls until R crashes. :/
>
> What is going on here? Is this a bug or have I done something completely
> wrong? :)
>
> Below is a minimal example which reproduces the behavior. Be careful
> when calling foo() as this automatically calls print.bar() which causes
> R to crash (at least on my PC, see further informations about my system
> below.)
>
> Greetings,
> Basil
>
> --
>
> Minimal example:
>
> foo <- function () {
> x <- c("A" = 1.3, "B" = 0.7, "C" = -0.3)
> structure(x, class = "bar")
> }
>
> print.bar <- function (x, ...) {
> print(x, ...)
> }
>
> --
>
> Further informations about my system:
>
>> version
> _
> platform x86_64-unknown-linux-gnu
> arch x86_64
> os linux-gnu
> system x86_64, linux-gnu
> status
> major 2
> minor 15.1
> year 2012
> month 06
> day22
> svn rev59600
> language R
> version.string R version 2.15.1 (2012-06-22)
> nickname Roasted Marshmallows
>
>> sessionInfo()
>
> R version 2.15.1 (2012-06-22)
> Platform: x86_64-unknown-linux-gnu (64-bit)
>
> locale:
> [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
> LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8 LC_MONETARY=en_US.UTF-8
> [6] LC_MESSAGES=en_US.UTF-8LC_PAPER=C LC_NAME=C
> LC_ADDRESS=C LC_TELEPHONE=C
> [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
>
> attached base packages:
> [1] stats graphics grDevices utils datasets methods base
>
> loaded via a namespace (and not attached):
> [1] compiler_2.15.1 tools_2.15.1
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Jeffrey Ryan
jeffrey.r...@lemnica.com
www.lemnica.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] methods cbind2 bind_activation disrupts cbind everywhere
Refreshing the memory on performance:
http://r.789695.n4.nabble.com/reduce-limit-number-of-arguments-in-methods-cbind-td921600.html#a921601
My issue had been resolved by a more careful approach taken by timeSeries.
The other option is wholesale deprecation of S4 ... but I won't start
that conversation with either of you ;-)
Jeff
On Fri, Sep 14, 2012 at 3:00 AM, Martin Maechler
wrote:
>>>>>> Martin Morgan
>>>>>> on Wed, 12 Sep 2012 15:23:02 -0700 writes:
>
> > The methods package ?cbind2 includes the instruction to
> > use via methods:::bind_activation(TRUE).
>
> well, "instruction" only if one wants to magically enable its
> use for cbind(), rbind()
>
> > use via methods:::bind_activation(TRUE). This changes the
> > default definition of cbind globally, disrupting proper
> > evaluation in packages not using cbind2.
>
> { really disrupting? I seem to only recall examples of
> performance loss, but that memory is fading.. }
>
> > evaluation in packages not using cbind2. Is cbind2 a
> > hold-over from a time when ... could not be used for
> > dispatch?
>
> Yes, exactly.
>
> As I'm sure you know well, and ?dotMethods explains,
> the ... dispatch was introduced only in R 2.8.0,
> *and* if you read that help page, it is alluded to several times
> that the implementation is still not "perfect" because it
> entails restrictions, and also because its implementation in
> pure R rather than (partially) C.
>
> I had hoped (but not spent work myself, alas!) that there would
> be evolution from there on, but it seems we forgot about it.
>
> > What is a safe way for a package to use cbind2?
>
> to define methods for cbind2 / rbind2, with nice multiple
> dispatch on both arguments, as the 'Matrix' package has been
> doing for many years (long before R 2.8.0) --> Matrix/R/bind.R
>
> And then, instead of "bind_activation",
> Matrix now also defines cBind() & rBind()
> as substitutes for cbind(), rbind(),
> simply as using methods:::cbind() which recursively calls
> cbind2(), rbind2().
>
> This has still the big drawback that cbind() fails on "Matrix"
> matrices {and even with quite an unhelpful error message!},
> and useRs must learn to use cBind() instead
> not ideal, at all.
>
>
> In an ideal R world,
> 1) the "..." S4 dispatch would be improved and made faster
> 2) that part of Matrix would be rewritten, so that cbind() and rbind()
>would work via '...' dispatch on both "Matrix" matrices and
>all standard R objects (atomic vectors, "matrix", data.frame,...),
>and the use of cBind() and rBind() could be deprecated.
>
> I also have a vague recollection that '2)' was not just a job to
> be done with finite some effort, but rather seemed not easily
> achievable with the current restriction of "..." dispatch
> needing all arguments to be of the same superclass.
> We would have to define
>
> setGeneric("cbind", signature = "...")
> setGeneric("rbind", signature = "...")
>
> setMethod("cbind", "Mnumber", function(..., deparse.level=1) {
>
>
> })
>
> similarly to what I do in the Rmpfr package,
> and where "Mnumber" is a *large* class union... defined in
> Rmpfr/R/AllClasses.R and if you look in there, you see comments
> with FIXME ... basically the solution was +- ok, but not really
> entirely satisfactory to me.
>
> Still, we maybe should really discuss to have the above two
> setGeneric()s in 'methods', and possibly also some class union /
> superclass definitions there (that other packages could use!) possibly even
> with
> setMethod("cbind", ,
> function(..., deparse.level=1) {
> ..
> })
> and of course the same with rbind().
>
>
> > This came up in the context of complex package
> > dependencies in Bioconductor, as detailed in this thread
> > (sorry for the html).
>
> > https://stat.ethz.ch/pipermail/bioc-devel/2012-September/003617.html
>
> > --
> > Dr. Martin Morgan Fred Hutchinson Cancer Research Center
> > 1100 Fairview Ave. N. PO Box 19024 Seattle, WA 98109
>
> > __
> > 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
--
Jeffrey Ryan
jeffrey.r...@lemnica.com
www.lemnica.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Behavior or as.environment in function arguments/call (and force() behaviors...)
Happy 2013!
Can someone with more knowledge of edge case scoping/eval rules explain
what is happening below? Happens in all the versions of R I have on hand.
Behavior itself is confusing, but ?as.environment also provides no clue.
The term used in that doc is 'search list', which is ambiguous, but the
see also section mentions search(), so I would *think* that is what is
intended. Either way Fn1() below can't really be explained.
Major question is what in the world is Fn1 doing, and why is Fn2 not equal
to Fn3? [ Fn3/Fn4 are doing what I want. ]
Fn1 <- function(x="test",pos=-1,env=as.environment(pos)) {
ls(env)
}
Fn2 <- function(x="test",pos=-1,env=as.environment(pos)) {
force(env)
ls(env)
}
Fn3 <- function(x="test",pos=-1,env=as.environment(pos)) {
# should be the same as force() in Fn2, but not
# ?force
# Note:
#
#This is semantic sugar: just evaluating the symbol will do the
#same thing (see the examples).
env
ls(env)
}
Fn4 <- function(x="test",pos=-1,env=as.environment(pos)) {
# same as Fn3
env <- env
ls(env)
}
Fn1()
Fn2()
Fn3()
Fn4()
ls()
## output #
> Fn1()
[1] "doTryCatch" "expr" "handler""name" "parentenv"
> Fn2()
[1] "env" "pos" "x"
> Fn3()
[1] "Fn1" "Fn2" "Fn3" "Fn4"
> Fn4()
[1] "Fn1" "Fn2" "Fn3" "Fn4"
### .GlobalEnv
> ls()
[1] "Fn1" "Fn2" "Fn3" "Fn4"
> R.version
_
platform x86_64-apple-darwin11.2.0
arch x86_64
os darwin11.2.0
system x86_64, darwin11.2.0
status
major 2
minor 15.1
year 2012
month 06
day22
svn rev59600
language R
version.string R version 2.15.1 (2012-06-22)
nickname Roasted Marshmallows
> R.version
_
platform x86_64-apple-darwin11.2.0
arch x86_64
os darwin11.2.0
system x86_64, darwin11.2.0
status Under development (unstable)
major 3
minor 0.0
year 2012
month 12
day28
svn rev61464
language R
version.string R Under development (unstable) (2012-12-28 r61464)
nickname Unsuffered Consequences
--
Jeffrey Ryan
jeffrey.r...@lemnica.com
www.lemnica.com
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Behavior or as.environment in function arguments/call (and force() behaviors...)
Thanks Duncan.
I was hoping that pos= would be more useful, but envir is a bit easier to
grasp in terms of consistency.
The lazy eval was also pointed out to me off-list as a source of the
'weirdness' if you will, which makes perfect sense in retrospect.
Thanks for the prompt clarification, and I'm glad I wasn't just
missing/misreading the primary docs.
Best,
Jeff
On Tue, Jan 1, 2013 at 4:21 PM, Duncan Murdoch wrote:
> On 13-01-01 4:35 PM, Jeff Ryan wrote:
>
>> Happy 2013!
>>
>> Can someone with more knowledge of edge case scoping/eval rules explain
>> what is happening below? Happens in all the versions of R I have on hand.
>>
>
> Even though it is used as a default in a number of places, the pos==-1
> value is really poorly documented. You need to look in the source, in
> particular src/main/envir.c, function pos2env. There you'll see that
> pos==-1 is special cased to be the environment from which pos.to.env
> (or as.environment in your case) was called. For non-negative values, it
> indexes the search list (i.e. the list returned by search().) Other values
> are errors.
>
> The trouble in your examples is that this location varies. In Fn1, it is
> being called in the ls() call. In Fn2, it is in the force() call. In Fn3
> and Fn4, it's the Fn3/Fn4 call.
>
> In spite of what the docs say in ?get, I would rarely if ever use a pos
> argument to as.environment. Use an environment and pass it as envir.
>
> Duncan Murdoch
>
>
>
>> Behavior itself is confusing, but ?as.environment also provides no clue.
>> The term used in that doc is 'search list', which is ambiguous, but the
>> see also section mentions search(), so I would *think* that is what is
>> intended. Either way Fn1() below can't really be explained.
>>
>> Major question is what in the world is Fn1 doing, and why is Fn2 not equal
>> to Fn3? [ Fn3/Fn4 are doing what I want. ]
>>
>>
>> Fn1 <- function(x="test",pos=-1,env=**as.environment(pos)) {
>> ls(env)
>> }
>>
>> Fn2 <- function(x="test",pos=-1,env=**as.environment(pos)) {
>> force(env)
>> ls(env)
>> }
>>
>> Fn3 <- function(x="test",pos=-1,env=**as.environment(pos)) {
>> # should be the same as force() in Fn2, but not
>> # ?force
>> # Note:
>> #
>> #This is semantic sugar: just evaluating the symbol will do the
>> #same thing (see the examples).
>> env
>> ls(env)
>> }
>>
>> Fn4 <- function(x="test",pos=-1,env=**as.environment(pos)) {
>> # same as Fn3
>> env <- env
>> ls(env)
>> }
>>
>> Fn1()
>> Fn2()
>> Fn3()
>> Fn4()
>> ls()
>>
>> ## output #
>>
>>> Fn1()
>>>
>> [1] "doTryCatch" "expr" "handler""name" "parentenv"
>>
>> Fn2()
>>>
>> [1] "env" "pos" "x"
>>
>> Fn3()
>>>
>> [1] "Fn1" "Fn2" "Fn3" "Fn4"
>>
>> Fn4()
>>>
>> [1] "Fn1" "Fn2" "Fn3" "Fn4"
>>
>> ### .GlobalEnv
>>
>>> ls()
>>>
>> [1] "Fn1" "Fn2" "Fn3" "Fn4"
>>
>> R.version
>>>
>> _
>> platform x86_64-apple-darwin11.2.0
>> arch x86_64
>> os darwin11.2.0
>> system x86_64, darwin11.2.0
>> status
>> major 2
>> minor 15.1
>> year 2012
>> month 06
>> day22
>> svn rev59600
>> language R
>> version.string R version 2.15.1 (2012-06-22)
>> nickname Roasted Marshmallows
>>
>> R.version
>>>
>> _
>> platform x86_64-apple-darwin11.2.0
>> arch x86_64
>> os darwin11.2.0
>> system x86_64, darwin11.2.0
>> status Under development (unstable)
>> major 3
>> minor 0.0
>> year 2012
>> month 12
>> day28
>> svn rev61464
>> language R
>> version.string R Under development (unstable) (2012-12-28 r61464)
>> nickname Unsuffered Consequences
>>
>>
>
--
Jeffrey Ryan
jeffrey.r...@lemnica.com
www.lemnica.com
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] formal vs. passed args: parent.frame() behavior.
Happy 2013, Day 2.
I can't seem to figure out why parent.frame() works differently depending
on whether it is a formal/default argument or a passed argument.
# code: basic setup
tmp <- tempfile()
A <- 101
save(A,file=tmp);rm(A)
# these work as expected, loading into the parent of the call load()
load(tmp);str(A);rm(A)
load(tmp, parent.frame());str(A);rm(A)
load(tmp, environment());str(A);rm(A)
# but these are odd, using local()
# works
local( { load(tmp); str(A) } )
#FAILS even though env=parent.frame() by default !?!!
local( { load(tmp,env=parent.frame()); str(A) } )
# works as well!
local( { load(tmp,env=environment()); str(A) } )
ls()## NOT in .GlobalEnv, correct!
args(load) ## env=parent.frame() by default, but is it???
My question is why parent.frame() can't be specified in the args without
changing the behavior of the call itself if you aren't at the top level.
What am I missing?
Jeff
# output #
> tmp <- tempfile()
> A <- 101
> save(A,file=tmp);rm(A)
>
> # these work as expected, loading into the parent of the call load()
> load(tmp);str(A);rm(A)
num 101
> load(tmp, parent.frame());str(A);rm(A)
num 101
> load(tmp, environment());str(A);rm(A)
num 101
>
>
>
> # but these are odd, using local()
>
> # works
> local( { load(tmp); str(A) } )
num 101
>
> #fails even though env=parent.frame() by default !?!!
> local( { load(tmp,env=parent.frame()); str(A) } )
Error in str(A) : object 'A' not found
>
> # works as well!
> local( { load(tmp,env=environment()); str(A) } )
num 101
>
> ls()## NOT in .GlobalEnv, correct!
[1] "tmp"
> args(load) ## env=parent.frame() by default, but is it???
function (file, envir = parent.frame())
NULL
>
--
Jeffrey Ryan
jeffrey.r...@lemnica.com
www.lemnica.com
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Passing R code from webpage
Another really great tool, leveraging Simon's incredible work with Rserve, is to use pyRserve. Combined with Flask as a web framework you can do quite a bit with very minimal code. http://flask.pocoo.org/ http://pypi.python.org/pypi/pyRserve/ HTH Jeff On Sun, Feb 17, 2013 at 12:10 PM, Simon Urbanek wrote: > > On Feb 17, 2013, at 12:09 PM, Matevz Pavlic wrote: > > > Hi, > > > > yes, i saw that about Cshtml...but it's done already, can't change it > now. > > > > Are there any samples of web pages or some samples to download for > FastRWeb? > > I am having troubles understanding how to install this and get it to > work... > > > > There is the INSTALL file in the package with all the details. Sample > scripts (example*) will be installed as part of the installation process -- > if you want to look at them first, they are in the inst/web.R directory of > the package sources. An example HTML page with JS to use AJAX is in the > web/index.html file. Jay Emerson also has a blog entry about installing > FastRWeb > > http://jayemerson.blogspot.com/2011/10/setting-up-fastrwebrserve-on-ubuntu.html > You can ask questions about FastRWeb or Rserve on the stats-rosuda-devel > mailing list. > > Cheers, > Simon > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Jeffrey Ryan jeffrey.r...@lemnica.com www.lemnica.com R/Finance 2013: Applied R in Finance May 17, 18 Chicago, IL www.RinFinance.com [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] readBin on binary non-blocking connections (Windows & Unix differences/bugs)
R-devel:
I am encountering a consistency issue using socketConnection and
readBin with *non-blocking* connections on Unix and Windows XP (no
Vista to test).
I am a bit confused by the behavior of *non-blocking* connections
under Windows specifically. When calling readBin on a non-blocking
connection when there is no data to read on the socket, the connection
under Unix will return a vector of zero-length matching the type of
the 'what' argument to the readBin call.
The same call under Windows returns random data unless called with
what=raw(), which instead returns an error.
A simple example using two R processes to illustrate on one machine:
#
# PROCESS 1 (Windows/Unix -- the same code for both):
#
# Open the connection and don't write anything
s <- socketConnection(port=, server=TRUE, blocking=TRUE,open="ab")
#
# PROCESS 2 (Windows) use this to read:
#
s <- socketConnection(port=,blocking=FALSE,open="ab")
readBin(s, character())
readBin(s, character())
readBin(s, double())
readBin(s, raw())
# > readBin(s, character())
# [1] "\020âƒ\...@ûƒ\001 $ƒ\001 $ƒ\001 $ƒ\001 $ƒ\001 $ƒ\001 $ƒ\001
$ƒ\001 $ƒ\001 ...
# > readBin(s, character())
# [1] "X\n"
# > readBin(s, double())
# [1] 1.255609e-316
# > readBin(s, raw())
# Error in readBin(s, raw()) : negative length vectors are not allowed
##
# Using a *nix, the above works as I would expect
#
# PROCESS 2 (Unixes -- this example OSX 10.4, but is consistent on
other flavors)
#
s <- socketConnection(port=,blocking=FALSE, open="ab")
readBin(s, character())
readBin(s, raw())
readBin(s, double())
# > readBin(s, character())
# character(0)
# > readBin(s, raw())
# raw(0)
# > readBin(s, double())
# numeric(0)
Is this a bug in R or Windows? Is there a workaround? I would like
to have readBin on non-blocking connections work consistently across
platforms. When data is present, both platforms behave consistently.
Incidentally, the readBin calls in my program are not using R as the
server, the above code is simply to illustrate the problem.
The fact that the raw() returns an error on Windows seems to indicate
that the error is able to be caught, and could be tested for.
One other interesting point of note; the character() calls on Windows
will return not just random data, but very non-random R type strings.
Somehow non-allocated memory is being read.
> readBin(s, character(),100)
[1] "X\n"
[2] "spatch"
[3] ""
[4] ""
[5] "X\n"
[6] "ssion"
[7] "\002"
[8] " $ƒ\001À|Ó\001\030[Ó\001°N¡\001°N¡\001 $ƒ\001\004"
[9] "H\024¢\001\f\025¢\001,œŒ\001\002\002"
[10] "è\026¢\001 $ƒ\001\005"
[11] ""
[12] "s.logical"
...
[75] "8}ò\001À~ò\001\020—ò\001 $ƒ\001Œ}ò\001 $ƒ\001ô–ò\001
$ƒ\001¼–ò\001ˆ~ò\0014~ò\001Ø–ò\001È|ò\001€—ò\001¸—ò\001\034}ò\001œ—ò\001
$ƒ\001¬|ò\001 \177ò\001"
[76] " $ƒ\001 $ƒ\001ˆ•ò\001\030•ò\001T”ò\001 $ƒ\001 $ƒ\001
$ƒ\001¬“ò\0010–ò\001 $ƒ\001 $ƒ\001¼–ò\0014•ò\001
\177ò\001X“ò\001\034”ò\001 $ƒ\001Œ”ò\001Ì’ò\001
|ò\001\004“ò\001ä“ò\0010\177ò\001ø•ò\001è{ò\001<“ò\001
$ƒ\001Ü•ò\001à}ò\001 “ò\001 $ƒ\001 $ƒ\001\024\177ò\001
$ƒ\001t“ò\001¨”ò\001ü}ò\001 $ƒ\001 $ƒ\001t|ò\001 $ƒ\001
$ƒ\001ô\177ò\001œ—ò\001ä|ò\001 |ò\001 $ƒ\001d—ò\001
$ƒ\001è’ò\001x{ò\001 $ƒ\001"
[77] "' must be of length 1"
This behavior has been noticed by me at least as early as 2.6, and is
currently seen under 2.9.0.
Thanks for any pointers,
Jeff Ryan
--
Jeffrey Ryan
jeffrey.r...@insightalgo.com
ia: insight algorithmics
www.insightalgo.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] readBin on binary non-blocking connections (Windows & Unix differences/bugs)
Thanks Gabor. Unfortunately read/writeLines won't work in this particular application. Nor does readChar, as the returned values are not of a fixed size. I need to read each unknown length "character" up until an embedded null. readBin does this (almost) perfectly. My current workaround is to simply force blocking=TRUE on Windows users, but that seems not to be the right answer. An alternate approach may be to rewrite readBin to allow for some sort of buffering mechanism. If readBin first reads in data as raw(), it would be possible to test for an error and return via some switch statement the appropriate length zero vector. The main issue is that by reading in raw bytes I have to explicitly convert to the appropriate data types (nul terminated character strings in this case). The second (bigger?) issue is that all readBin calls would have to first look to the buffer before reading from the connection again. This would require the buffer to be available --- either as an R connection addition, or as a global variable. The best option of course is for readBin to correctly catch the error cases, but without guidance from those who know the full details of sockets in R, I am afraid that option isn't realistic at this moment. Jeff On Mon, May 18, 2009 at 1:01 PM, Gabor Grothendieck wrote: > Ryacas uses non-blocking sockets and works across all platforms > but uses readLines/writeLines, rather than readBin, to communicate with > yacas. You could look at its source code in case it brings anything to mind. > > On Mon, May 18, 2009 at 1:40 PM, Jeff Ryan wrote: >> R-devel: >> >> I am encountering a consistency issue using socketConnection and >> readBin with *non-blocking* connections on Unix and Windows XP (no >> Vista to test). >> >> I am a bit confused by the behavior of *non-blocking* connections >> under Windows specifically. When calling readBin on a non-blocking >> connection when there is no data to read on the socket, the connection >> under Unix will return a vector of zero-length matching the type of >> the 'what' argument to the readBin call. >> >> The same call under Windows returns random data unless called with >> what=raw(), which instead returns an error. >> >> >> A simple example using two R processes to illustrate on one machine: >> >> >> # >> # PROCESS 1 (Windows/Unix -- the same code for both): >> # >> >> # Open the connection and don't write anything >> >> s <- socketConnection(port=, server=TRUE, blocking=TRUE,open="ab") >> >> # >> # PROCESS 2 (Windows) use this to read: >> # >> >> s <- socketConnection(port=,blocking=FALSE,open="ab") >> readBin(s, character()) >> readBin(s, character()) >> readBin(s, double()) >> readBin(s, raw()) >> >> # > readBin(s, character()) >> # [1] "\020âƒ\...@ûƒ\001 $ƒ\001 $ƒ\001 $ƒ\001 $ƒ\001 $ƒ\001 $ƒ\001 >> $ƒ\001 $ƒ\001 ... >> # > readBin(s, character()) >> # [1] "X\n" >> # > readBin(s, double()) >> # [1] 1.255609e-316 >> # > readBin(s, raw()) >> # Error in readBin(s, raw()) : negative length vectors are not allowed >> >> ## >> # Using a *nix, the above works as I would expect >> # >> # PROCESS 2 (Unixes -- this example OSX 10.4, but is consistent on >> other flavors) >> # >> >> s <- socketConnection(port=,blocking=FALSE, open="ab") >> readBin(s, character()) >> readBin(s, raw()) >> readBin(s, double()) >> >> # > readBin(s, character()) >> # character(0) >> # > readBin(s, raw()) >> # raw(0) >> # > readBin(s, double()) >> # numeric(0) >> >> Is this a bug in R or Windows? Is there a workaround? I would like >> to have readBin on non-blocking connections work consistently across >> platforms. When data is present, both platforms behave consistently. >> Incidentally, the readBin calls in my program are not using R as the >> server, the above code is simply to illustrate the problem. >> >> The fact that the raw() returns an error on Windows seems to indicate >> that the error is able to be caught, and could be tested for. >> >> One other i
Re: [Rd] readBin on binary non-blocking connections (Windows & Unix differences/bugs)
R-devel: I'll escalate this to a bug report once I can fully document, but something is seriously wrong with readBin on non-blocking connections. >From ?readBin Value: For 'readBin', a vector of appropriate mode and length the number of items read (which might be less than 'n'). On Windows, 'n' elements are always returned. If 'n' < items waiting to be read, then the vector of length 'n' will be returned with the expected items. If n > items, a vector of length n (yes, n) will be returned, padded with random values taken from (somewhere???) in memory. As expressed in a previous email, if what=raw() and n > items, the entire process fails with an error. The items are effectively read and discarded. I would be interested in assisting further with a patch, but I would hope that someone (R-core or otherwise) who knows a bit more about the internals of socket connections in R (w.r.t Windows - as *nix works fine) could provide some much needed insight. Best, Jeff Ryan On Mon, May 18, 2009 at 12:40 PM, Jeff Ryan wrote: > R-devel: > > I am encountering a consistency issue using socketConnection and > readBin with *non-blocking* connections on Unix and Windows XP (no > Vista to test). > > I am a bit confused by the behavior of *non-blocking* connections > under Windows specifically. When calling readBin on a non-blocking > connection when there is no data to read on the socket, the connection > under Unix will return a vector of zero-length matching the type of > the 'what' argument to the readBin call. > > The same call under Windows returns random data unless called with > what=raw(), which instead returns an error. > > > A simple example using two R processes to illustrate on one machine: > > > # > # PROCESS 1 (Windows/Unix -- the same code for both): > # > > # Open the connection and don't write anything > > s <- socketConnection(port=, server=TRUE, blocking=TRUE,open="ab") > > # > # PROCESS 2 (Windows) use this to read: > # > > s <- socketConnection(port=,blocking=FALSE,open="ab") > readBin(s, character()) > readBin(s, character()) > readBin(s, double()) > readBin(s, raw()) > > # > readBin(s, character()) > # [1] "\020âƒ\...@ûƒ\001 $ƒ\001 $ƒ\001 $ƒ\001 $ƒ\001 $ƒ\001 $ƒ\001 > $ƒ\001 $ƒ\001 ... > # > readBin(s, character()) > # [1] "X\n" > # > readBin(s, double()) > # [1] 1.255609e-316 > # > readBin(s, raw()) > # Error in readBin(s, raw()) : negative length vectors are not allowed > > ## > # Using a *nix, the above works as I would expect > # > # PROCESS 2 (Unixes -- this example OSX 10.4, but is consistent on > other flavors) > # > > s <- socketConnection(port=,blocking=FALSE, open="ab") > readBin(s, character()) > readBin(s, raw()) > readBin(s, double()) > > # > readBin(s, character()) > # character(0) > # > readBin(s, raw()) > # raw(0) > # > readBin(s, double()) > # numeric(0) > > Is this a bug in R or Windows? Is there a workaround? I would like > to have readBin on non-blocking connections work consistently across > platforms. When data is present, both platforms behave consistently. > Incidentally, the readBin calls in my program are not using R as the > server, the above code is simply to illustrate the problem. > > The fact that the raw() returns an error on Windows seems to indicate > that the error is able to be caught, and could be tested for. > > One other interesting point of note; the character() calls on Windows > will return not just random data, but very non-random R type strings. > Somehow non-allocated memory is being read. > >> readBin(s, character(),100) > [1] "X\n" > [2] "spatch" > [3] "" > [4] "" > [5] "X\n" > [6] "ssion" > [7] "\002" > [8] " $ƒ\001À|Ó\001\030[Ó\001°N¡\001°N¡\001 $ƒ\001\004" > [9] "H\024¢\001\f\025¢\001,œŒ\001\002\002" > [10] "è\026¢\001 $ƒ\001\005" > [11] "" > [12] "s.logical" > ... > [75] "8}ò\001À~ò\001\020—ò\001 $ƒ\001Œ}ò\001 $ƒ\001ô–ò\001 > $ƒ\001¼–ò\001ˆ~ò\0014~ò\001Ø–ò\001È|ò\001€—ò\001¸—ò\001\034}ò\001œ—ò\001 > $ƒ\001
Re: [Rd] beginner's guide to C++ programming with R packages?
If your just looking to build and test a single function written in C/C
++ you can try:
R CMD SHLIB my.c
Which will produce a object that can be loaded in R with 'dyn.load'.
A simple R script including dyn.load('my.so') with your basic tests
can then be run with:
R --vanilla < my.R
HTH
Jeff
Jeffrey A. Ryan
jeffrey.r...@insightalgo.com
ia: insight algorithmics
www.insightalgo.com
On Jun 26, 2009, at 2:43 PM, Paul Johnson wrote:
Hello, again.
I'm interested to learn how programmers develop & test C/C++ code with
R packages in Linux. I've been reading R source and the manual on
Writing R Extensions but there are just a couple of details I can't
understand. I wish I could watch over a developer's shoulder to see
how people actually do this.
I've tested a bit. I am able to take package.tar.gz file, open it up,
fiddle the source code, and then run
R CMD check package-dir
from the directory above "package-dir" ,
R CMD build package-dir
and
R CMD INSTALL
on the tarball that is produced. Then in R, I can load the package
and use it.
That part is "all good", but somewhat tedious. I don't want to
entirely recompile and reinstall the whole package just to test one
function. I notice that R CMD check creates a new directory called
"package.Rcheck" and the shared objects and example code of the
package are in there. Can I force R to use those *.so files instead
of the ones in /usr/lib/R ?
I also wonder "what is wrong with gprof? In the Writing R Extensions
manual, it describes "oprofile" and "sprof" for Linux. I will try
them, but they are unfamilar to me. I've used gprof in the past in C
projects, and it is a pretty painless thing to add a compiler flag
-pg, run the program, and then review gmon.out. The Writing R
Extensions manual does not mention gprof in its section on Linux, but
it does mention it under Solaris. There is a somewhat ambiguous
statement:
3.4.2 Solaris
On 64-bit (only) Solaris, the standard profiling tool gprof collects
information from shared libraries compiled with -pg.
Does "(only)" here mean to differentiate Solaris from other Linux/Unix
systems? Or does it differentiate 64bit Solaris from other Solaris?
But this draws me back to the basic question. I don't want to run R
CMD INSTALL 20 times per hour. How do developers "actually" test
their code?
pj
--
Paul E. Johnson
Professor, Political Science
1541 Lilac Lane, Room 504
University of Kansas
__
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
Re: [Rd] How to create a permanent dataset in R.
The biggest help would come by not pretending to be Albert Einstein. hTh, Jeff On Fri, Jul 24, 2009 at 1:11 AM, Albert EINstEIN wrote: > > > Hi everybody, > > Actually, we know that If we create a dataset in R ,after closing the > session the dataset automatically is closed. I tried for creating dataset > permanently in R.I am facing the problem of creating permanent dataset. > can we create dataset permanently If possible? > Could somebody help me out in this aspect,plz? Any help would be > appreciated. > > Thanks in advance. > -- > View this message in context: > http://www.nabble.com/How-to-create-a-permanent-dataset-in-R.-tp24639146p24639146.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 > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] inheriting C symbols
This has been discussed before:
http://www.nabble.com/Dynamic-linking-to-binary-code-from-other-packages---td20167535.html#a20474561
Take a look at 'xts' on cran, or R-forge. Specifically:
http://r-forge.r-project.org/plugins/scmsvn/viewcvs.php/pkg/inst/api_example/README?rev=386&root=xts&view=markup
HTH
Jeff
On Wed, Aug 5, 2009 at 11:29 AM, Terry Therneau wrote:
> The package coxme depends heavily on bdsmatrix, to the point of needing
> access to some of its C calls. The kinship package (in progress) uses
> the R level functions in bdsmatrix, but not the C calls. That is, I
> don't want to always export the symbols.
>
> For testing I can use an explicit dyn.load('somepath/bsdmatrix.so',
> local=F). How do I incorporate such a dependency in the DESCRIPTION
> file for coxme, so that it happens in general?
>
> Terry T.
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Jeffrey Ryan
jeffrey.r...@insightalgo.com
ia: insight algorithmics
www.insightalgo.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] inheriting C symbols
Terry,
I think I don't quite follow what you want to do.
You have a package that needs to access the R level functions in
another, or the C level functions?
Do you need access *from R* for the above, or *from new C code*?
If you are just looking to call .Call("other_package", ...) I think
your only strategy is to list it as a dependency. Is there some
reason you don't want to do that?
Once it is a dependency you can simply call the C routines like they
are called within the package's R code.
Jeff
On Wed, Aug 5, 2009 at 2:24 PM, Terry Therneau wrote:
> Thanks for the information. I'd looked through the manual but missed
> this. Follow-up questions
>
> 1. I'd never paid much attention to that whole "register routines"
> section of the manual because a) it didn't seem necessary (my code
> worked anyway) and b) it's quite complex. Your answer is that if I dig
> into it, there is a way to export routines. Is there any other real
> advantage to registration?
>
> 2. The simpler method is to use a local=FALSE argument to dyn.load.
> Since it wasn't mentioned, I'll assume that there is no way to add text
> to the DESCRIPTION file saying "and load the symbols too"? It would be
> much simpler. Also a bit more dangerous of course, since function
> prototypes are not being exported via a header.
>
> Terry T
>
>
> On Wed, 2009-08-05 at 11:54 -0500, Jeff Ryan wrote:
>> This has been discussed before:
>>
>> http://www.nabble.com/Dynamic-linking-to-binary-code-from-other-packages---td20167535.html#a20474561
>>
>> Take a look at 'xts' on cran, or R-forge. Specifically:
>>
>> http://r-forge.r-project.org/plugins/scmsvn/viewcvs.php/pkg/inst/api_example/README?rev=386&root=xts&view=markup
>>
>> HTH
>> Jeff
>>
>> On Wed, Aug 5, 2009 at 11:29 AM, Terry Therneau wrote:
>> > The package coxme depends heavily on bdsmatrix, to the point of needing
>> > access to some of its C calls. The kinship package (in progress) uses
>> > the R level functions in bdsmatrix, but not the C calls. That is, I
>> > don't want to always export the symbols.
>> >
>> > For testing I can use an explicit dyn.load('somepath/bsdmatrix.so',
>> > local=F). How do I incorporate such a dependency in the DESCRIPTION
>> > file for coxme, so that it happens in general?
>> >
>> > Terry T.
>> >
>> > __
>> > R-devel@r-project.org mailing list
>> > https://stat.ethz.ch/mailman/listinfo/r-devel
>> >
>>
>>
>>
>
>
--
Jeffrey Ryan
jeffrey.r...@insightalgo.com
ia: insight algorithmics
www.insightalgo.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Bug in nlm, found using sem; failure in several flavors (PR#13881)
sMC43NTQ5Nzg3 > NzczMDk1NTMsMC45NTczMjQzNDE2NjE5NzIsLTAuMTgzMDA1NTg3NTUxNjI0 > LDAuNTIzMTgzOTkzODk3NjMyLC0wLjE5NzgzMzM1NDQzMDkwNywtMC4yMjg0 > MzQ3MTMwNjE3NzYsLTAuMjYzNTg3NzQ2MDIxMTc0LC0wLjA0NTM5NzEzNzc3 > MDA4NDUsMC4zMzAwNzU2NjY1MjY3NjEsLTAuMjM0NzA3NTE3Njc3NTg2LC0w > LjIzOTEyNjk3MTQ4MDYyNQ0KIm9ubHlzZWxmIiwtMC4xNDY2MjYzNDcyMTk4 > NzksMC4wMDk2MzA1MDQ3NDM1ODAzNCwwLjAzMjE2OTMyODE5ODg2NjksLTAu > MTk3NTA2NzA1OTE3MTIzLC0wLjI2MjM0MDQyNTgyNDA1MiwtMC4xODMwMDU1 > ODc1NTE2MjQsMC45NDc4NTI0MTU0NDM2NjMsLTAuMjY4MzMzOTc5Mjk1NjEy > LDAuMDc4NzE5MTg3OTIxNTY1NCwwLjA4MDA1NTQ0MzA5MzgwMzYsMC4xNjM1 > OTUyNzc0OTg3NTgsLTAuMDA1MDcyNjg2MDg0MTc3MDQsLTAuMTYwMTM3NTQ1 > ODcxNDQ4LDAuMjExMjU3MjUyMjg3OTc5LDAuMTQ3ODg0MzUyNTg4NDk5DQoi > bWFueWRpbWVuc2lvbnMiLDAuMTQ2MzU0MDI3Nzk3MTAxLDAuMDI4Mzg5NDM3 > MzMxNjY4NCwwLjA2NDYzMTIzMjYxODcwOTYsMC40NzQ3MjMzMzI0Njk4NzUs > MC42NTY3MTc1MzMzNjExNzYsMC41MjMxODM5OTM4OTc2MzIsLTAuMjY4MzMz > OTc5Mjk1NjEyLDAuOTQ5OTE3NjYyNjE2MTYsLTAuMTEzMjk1NjY3NDA4MTc3 > LC0wLjE4MTU3NjQ3MzE3MDc4NCwtMC4yNzkyOTg0MTcxNzcyNjEsMC4wNDQy > NDgxMjM1MDgyNTI4LDAuMjU4MzQ5NzAyNDYwNjYzLC0wLjE5Njk5MzM0NjMz > NzIxNCwtMC4yMjI1MzM5NTI2MzM0ODINCiJob3dtdWNoaW5mbyIsLTAuMTMy > ODg3NTk2OTAyNTA2LDAuMDE4ODAyNzUzOTQ2MzI5OSwwLjAxMDI5NDUwODU2 > NTEyNDYsLTAuMTI5MDkxMzI5ODE2MjAxLC0wLjE2MDQyNzEzOTY3MzAxOCwt > MC4xOTc4MzMzNTQ0MzA5MDcsMC4wNzg3MTkxODc5MjE1NjU0LC0wLjExMzI5 > NTY2NzQwODE3NywwLjk0NjcyMjc0NjEzNzQxNSwwLjcwNjk3NjAxNTU4MjIx > OCwwLjA5MjMxOTI3MDQ0Mzk5MzQsMC4yMTMwMzIyNDI0NzMzMTUsLTAuMjA5 > ODgyNDMxNzY1MTEwLDAuMjM5MTI0NTUxNjI5NTU5LDAuMjE5MDc4MzUyODkw > NjU3DQoiZXF1YWxpbmZvIiwtMC4xNzM5NjUwNjkxMTEwMjUsLTAuMDE1NzAy > NjM4MTUxNTk4NSwtMC4wMTk2NzU5OTk3OTIzMDA5LC0wLjE4OTIyOTEyMzcw > NTM0MSwtMC4yMzYyMTA4NTYwODM5MDIsLTAuMjI4NDM0NzEzMDYxNzc2LDAu > MDgwMDU1NDQzMDkzODAzNiwtMC4xODE1NzY0NzMxNzA3ODQsMC43MDY5NzYw > MTU1ODIyMTgsMC45NjQ1MTc1NjI3NzgzMjgsMC4xODA1MTczMjU3NTIzODcs > MC4xNjM4NDQ2NDA0OTU5ODMsLTAuMjEzODA0NTUwMDQzMjM5LDAuMjU4MDMy > MzIyODI0NTk5LDAuMTkxODIwNDQ3NDA0MzM1DQoiY291bGRhdm9pZCIsLTAu > MjY4NDU5MTYyOTMwNTY3LC0wLjE0NTc5NTAwNjc0MTg4NCwtMC4xNzg3NjU1 > NjMzNTQ4MjgsLTAuNDYyMTk1ODM5MjY1MDM1LC0wLjM4NTQ1MjEwMDA0NjYy > MywtMC4yNjM1ODc3NDYwMjExNzQsMC4xNjM1OTUyNzc0OTg3NTgsLTAuMjc5 > Mjk4NDE3MTc3MjYxLDAuMDkyMzE5MjcwNDQzOTkzNCwwLjE4MDUxNzMyNTc1 > MjM4NywwLjk2MzIzNzMwOTczMDcyNiwtMC4xMjAxMzAxOTYzOTI0MDYsLTAu > MDY4OTY1OTY1NzA1NzA5MSwwLjE2NTUzMzIwODc0MzU0NywwLjE5MTQyMTEz > NDE4OTY4Mg0KInBvc291dGNvbWUiLC0wLjA2NzgwOTUzNzUwNzYyMjIsMC4x > NDIwMzQzOTY5MDY4NzksMC4xNTEzNDM1Njc3NjE4NTksMC4xMjQxNTgzMzk1 > MjczMjIsMC4wMjM4Nzc1NzI4Mjc3MTU3LC0wLjA0NTM5NzEzNzc3MDA4NDUs > LTAuMDA1MDcyNjg2MDg0MTc3MDQsMC4wNDQyNDgxMjM1MDgyNTI4LDAuMjEz > MDMyMjQyNDczMzE1LDAuMTYzODQ0NjQwNDk1OTgzLC0wLjEyMDEzMDE5NjM5 > MjQwNiwwLjkzOTEwNzcxNzE4NjM4NSwtMC4yOTEyNjIzOTE4Mjc2NzEsMC4y > NTYyNzQxOTU5ODMwMDQsMC4zNDY0NDE0MTExMTYxNDcNCiJuZWdvdXRjb21l > IiwwLjE4MDU0OTkyNTAyNDM3NywwLjAwOTgxNTM4Mzk4NDM0ODUxLC0wLjAz > MzY1NTkwNjMzMDc4MzUsMC4xNjA2NjEzMDc0ODY1NTksMC4zMjQ1MjU2NTMx > NjQ1MDgsMC4zMzAwNzU2NjY1MjY3NjEsLTAuMTYwMTM3NTQ1ODcxNDQ4LDAu > MjU4MzQ5NzAyNDYwNjYzLC0wLjIwOTg4MjQzMTc2NTExMCwtMC4yMTM4MDQ1 > NTAwNDMyMzksLTAuMDY4OTY1OTY1NzA1NzA5MSwtMC4yOTEyNjIzOTE4Mjc2 > NzEsMC45NTI1NTI5NjU3OTY0MjEsLTAuMjIxOTE3MjIyOTMwMTksLTAuMjMx > MDMyMDE0OTI3Mzk3DQoiY29udHJvbCIsLTAuMDQyMDg0NDM2NDAzNzg3NCww > LjA3MDU4Njg3NTY1Mzk3MzIsMC4wOTI5MDYyMjc5MzM0ODk4LC0wLjA4NjQ1 > NzM3Mjc0NjYyNjUsLTAuMjQwNjM0ODA0ODg3MDU1LC0wLjIzNDcwNzUxNzY3 > NzU4NiwwLjIxMTI1NzI1MjI4Nzk3OSwtMC4xOTY5OTMzNDYzMzcyMTQsMC4y > MzkxMjQ1NTE2Mjk1NTksMC4yNTgwMzIzMjI4MjQ1OTksMC4xNjU1MzMyMDg3 > NDM1NDcsMC4yNTYyNzQxOTU5ODMwMDQsLTAuMjIxOTE3MjIyOTMwMTksMC45 > Mzc2MDc1MzMxODY1NzYsMC4zMTI2NjQxOTk2MzE2MjANCiJkZXNpcmVkIiwt > MC4wNzMwNTc3ODk2OTAyOTY3LDAuMTA4MDAwNDQ5MzI4MzEzLDAuMTU5NzM1 > NjE4NDIzMzM1LC0wLjA2ODM2NzQ4NDI0OTg4MDEsLTAuMjMzNjk2NTU0MTg5 > MTY0LC0wLjIzOTEyNjk3MTQ4MDYyNSwwLjE0Nzg4NDM1MjU4ODQ5OSwtMC4y > MjI1MzM5NTI2MzM0ODIsMC4yMTkwNzgzNTI4OTA2NTcsMC4xOTE4MjA0NDc0 > MDQzMzUsMC4xOTE0MjExMzQxODk2ODIsMC4zNDY0NDE0MTExMTYxNDcsLTAu > MjMxMDMyMDE0OTI3Mzk3LDAuMzEyNjY0MTk5NjMxNjIwLDAuOTYzMTMxNjM5 > NTYwMTA4DQo= > > --1660387551-1458482416-1249639718=:2997-- > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Jeffrey Ryan jeffrey.r...@insightalgo.com ia: insight algorithmics www.insightalgo.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Why is strptime always returning a vector of length 9 ?
The reason is in the ?strptime under value:
'strptime' turns character representations into an object of class
'"POSIXlt"'. The timezone is used to set the 'isdst' component
and to set the '"tzone"' attribute if 'tz != ""'.
And POSIXlt is a list of length 9.
HTH
Jeff
On Sun, Aug 9, 2009 at 10:35 AM, Gabor
Grothendieck wrote:
> Try this to see its components:
>
>> str(unclass(xd))
> List of 9
> $ sec : num [1:6] 0 0 0 0 0 0
> $ min : int [1:6] 0 0 0 0 0 0
> $ hour : int [1:6] 0 0 0 0 0 0
> $ mday : int [1:6] 9 31 12 12 30 30
> $ mon : int [1:6] 2 4 10 10 6 6
> $ year : int [1:6] 107 107 108 108 109 109
> $ wday : int [1:6] 5 4 3 3 4 4
> $ yday : int [1:6] 67 150 316 316 210 210
> $ isdst: int [1:6] 0 1 0 0 1 1
>
> and read R News 4/1 for more.
>
> On Sun, Aug 9, 2009 at 10:20 AM, laurent wrote:
>> Dear List,
>>
>>
>> I am having an issue with strptime (see below).
>> I can reproduce it on R-2.8, R-2.9, and R-2.10-dev, I tempted to see
>> either a bug or my misunderstanding (and then I just don't currently see
>> where).
>>
>> # setup:
>> x <- c("March 09, 2007", "May 31, 2007", "November 12, 2008", "November
>> 12, 2008", "July 30, 2009", "July 30, 2009" )
>>
>> # showing the problem
>>> length(x)
>> 6
>>> xd <- strptime(x, format = "%B %d, %Y")
>>> length(xd)
>> 9
>>> xd[1:9]
>> [1] "2007-03-09" "2007-05-31" "2008-11-12" "2008-11-12" "2009-07-30"
>> [6] "2009-07-30" NA NA NA
>>> length(strptime(rep(x, 2), format="%B %d, %Y"))
>> [1] 9
>>> strptime(rep(x, 2), format="%B %d, %Y")[1:12]
>> [1] "2007-03-09" "2007-05-31" "2008-11-12" "2008-11-12" "2009-07-30"
>> [6] "2009-07-30" "2007-03-09" "2007-05-31" "2008-11-12" "2008-11-12"
>> [11] "2009-07-30" "2009-07-30
>>
>> Any pointer would be appreciated.
>>
>>
>>
>> L.
>>
>> __
>> 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
>
--
Jeffrey Ryan
jeffrey.r...@insightalgo.com
ia: insight algorithmics
www.insightalgo.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] CRAN Server download statistics (Was: R Usage Statistics)
While I think download statistics are potentially interesting for developers, done incorrectly it can very likely damage the community. A basic data reporting problem, with all of the caveats attached. This information has also been readily available from the main CRAN mirror for years: http://www.r-project.org/awstats/awstats.cran.r-project.org.html http://cran.r-project.org/report_cran.html Best, Jeff On Sun, Nov 22, 2009 at 6:18 PM, Fellows, Ian wrote: > Hi All, > > It seems that the question of how may people use (or download) R, and it's > packages is one that comes up on a fairly regular basis in a variety of > forums (There was also recent thread on the subject on Stack Overflow). A > couple of students at UCLA (including myself), wanted to address the issue, > so we set up a system to get and parse the cran.stat.ucla.edu APACHE logs > every night, and display some basic statistics. Right now, we have a working > sketch of a site based on one week of observations. > > http://neolab.stat.ucla.edu/cranstats/ > > We would very much like to incorporate data from all CRAN mirrors, including > cran.r-project.org. We would also like to set this up in a way that is > minimally invasive for the site administrators. Internally, our administrator > has set up a protected directory with the last couple days of cran activity. > We then pull that down using curl. > > What would be the best and easiest way for the CRAN mirrors to share their > data? Is the contact information for the administrators available anywhere? > > > Thank you, > Ian Fellows > > > > > From: r-devel-boun...@r-project.org [r-devel-boun...@r-project.org] On Behalf > Of Steven McKinney [smckin...@bccrc.ca] > Sent: Thursday, November 19, 2009 2:21 PM > To: Kevin R. Coombes; r-devel@r-project.org > Subject: Re: [Rd] R Usage Statistics > > Hi Kevin, > > What a surprising comment from a reviewer for BMC Bioinformatics. > > I just did a PubMed search for "limma" and "aroma.affymetrix", > just two methods for which I use R software regularly. > "limma" yields 28 hits, several of which are published > in BMC Bioinformatics. Bengtsson's aroma.affymetrix paper > "Estimation and assessment of raw copy numbers at the single locus level." > is already cited by 6 others. > > It almost seems too easy to work up lists of usage of R packages. > > Spotfire is an application built around S-Plus that has widespread use > in the biopharmaceutical industry at a minimum. Vivek Ranadive's > TIBCO company just purchased Insightful, the S-Plus company. > (They bought Spotfire previously.) > Mr. Ranadive does not spend money on environments that are > not appropriate for deploying applications. > > You could easily cull a list of corporation names from the > various R email listservs as well. > > Press back with the reviewer. Reviewers can learn new things > and will respond to arguments with good evidence behind them. > Good luck! > > > Steven McKinney > > > > From: r-devel-boun...@r-project.org [r-devel-boun...@r-project.org] On Behalf > Of Kevin R. Coombes [krcoom...@mdacc.tmc.edu] > Sent: November 19, 2009 10:47 AM > To: r-devel@r-project.org > Subject: [Rd] R Usage Statistics > > Hi, > > I got the following comment from the reviewer of a paper (describing an > algorithm implemented in R) that I submitted to BMC Bioinformatics: > > "Finally, which useful for exploratory work and some prototyping, > neither R nor S-Plus are appropriate environments for deploying user > applications that would receive much use." > > I can certainly respond by pointing out that CRAN contains more than > 2000 packages and Bioconductor contains more than 350. However, does > anyone have statistics on how often R (and possibly some R packages) are > downloaded, or on how many people actually use R? > > Thanks, > Kevin > > __ > 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 > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Jeffrey Ryan jeffrey.r...@insightalgo.com ia: insight algorithmics www.insightalgo.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Rcpp: Clarifying the meaning of GPL?
This is fantastically off-topic, and has nothing to do with *R*. Out of "courtesy" to this list, the subscribers, and future readers, please take this off-list where it belongs. Jeff On Tue, Dec 22, 2009 at 11:27 PM, Dominick Samperi wrote: > Stavros Macrakis wrote: >> >> That said, as a matter of courtesy and clarity, I'd think that a fork >> should use a different name. > > Yes, the point is that this is not a legal or technical matter, it is a > matter of professional courtesy. > > I take this as one vote for the name change. > > On US copyright law, this should not be confused with "copyright" notices > that appear in GPL > source code. Remember that these are really "copyleft" notices, and copyleft > is designed to > protect the rights of copiers, not original contributors. My concern about > the copyright notice > should be viewed in the same spirit as the name change (professional > courtesy). > > Since GPL is largely silent on these issues I have asked the R community to > vote... > > Thanks, > Dominick > > ______ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Jeffrey Ryan jeffrey.r...@insightalgo.com ia: insight algorithmics www.insightalgo.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Rcpp: Clarifying the meaning of GPL?
uot; >>>> notices that appear in GPL >>>> source code. Remember that these are really "copyleft" notices, >>>> and copyleft is designed to >>>> protect the rights of copiers, not original contributors. >>>> >>>> >>>> The copyright notice is a correct and legally valid copyright notice. The >>>> GPL (copyleft) is the copyright *license*. Like all licenses, it defines >>>> the relationship between authors and copiers. The GPL explicitly avoided >>>> the so-called "obnoxious BSD advertising clause", which has requirements >>>> about giving credit. >>>> >>>> -s >>>> >>>> >>> >> >> [[alternative HTML version deleted]] >> >> __ >> 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 > -- Jeffrey Ryan jeffrey.r...@insightalgo.com ia: insight algorithmics www.insightalgo.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] optional package dependency
Hi Ross, The quantmod package makes available routines from a variety of contributed packages, but gets around your issues with a bit of, um, trickery. Take a look here (unless your name is Kurt ;-) ): http://r-forge.r-project.org/plugins/scmsvn/viewcvs.php/pkg/R/buildModel.methods.R?rev=367&root=quantmod&view=markup It would be nice to have Suggests really mean suggests to check, but I am sure there is a good reason it doesn't. HTH Jeff On Fri, Jan 15, 2010 at 12:00 AM, Ross Boylan wrote: > I have a package that can use rmpi, but works fine without it. None of > the automatic test code invokes rmpi functionality. (One test file > illustrates how to use it, but has quit() as its first command.) > > What's the best way to handle this? In particular, what is the > appropriate form for upload to CRAN? > > When I omitted rmpi from the DESCRITPION file R CMD check gave > > * checking R code for possible problems ... NOTE > alldone: no visible global function definition for ‘mpi.bcast.Robj’ > alldone: no visible global function definition for ‘mpi.exit’ > > followed by many more warnings. > > When I add > Suggests: Rmpi > in DESCRIPTION the check stops if the package is not installed: > > * checking package dependencies ... ERROR > Packages required but not available: > Rmpi > > Rmpi is not required, but I gather from previous discussion on this list > that suggests basically means required for R CMD check. > > NAMESPACE seems to raise similar issues; I don't see any mechanism for > optional imports. Also, I have not used namespaces, and am not eager to > destabilize things so close to release. At least, I hope I'm close to > release :) > > Thanks for any advice. > > Ross Boylan > > P.S. Thanks, Duncan, for your recent advice on my help format problem > with R 2.7. I removed the nested \description, and now things look OK. > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Jeffrey Ryan jeffrey.r...@insightalgo.com ia: insight algorithmics www.insightalgo.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Portability of a C function
Take a look here, as this may help clear up the unanswered questions:
https://stat.ethz.ch/pipermail/r-devel/2008-November/051262.html
HTH
Jeff
Jeffrey A. Ryan
jeffrey.r...@insightalgo.com
ia: insight algorithmics
www.insightalgo.com
On Feb 14, 2010, at 3:18 PM, Christophe Genolini paris10.fr> wrote:
Thanks, this helps a lot.
So if I understand correctly:
in package P1, I want to export printMatrix and printMatrixInt. In
my file P1.c, I have to add
void R_init_P1(DllInfo *info){
R_registerCCallable("longitudinalData","printMatrix",printMatrix);
R_registerCCallable
("longitudinalData","printMatrixInt",printMatrixInt);
};
In P2.c, I have to add :
void R_init_P2(DllInfo *info){
printMatrix = R_GetCCallable("longitudinalData","printMatrix");
printMatrixInt = R_GetCCallable
("longitudinalData","printMatrixInt");
};
I still have a problem here: "Writing R ext" say that 'printMatrix'
and 'printMatrixInt' should have "an appropriate declaration". What
is the appropriate declaration?
Christophe
Hello,
This was discussed this week in the thread "LinkingTo and C++".
It is possible, and documented in WRE section 5.4 :
http://cran.r-project.org/doc/manuals/R-exts.html#Registering-native-routines
Romain
On 02/14/2010 12:58 PM, Christophe Genolini wrote:
Hi the list,
In a package P1, I write a function f1 in C, potentially an internal
function (not to be called from R).
In a package P2, I write a function f2 in C. The f2 function needs
to
use f1 from P1. Is it possible ?
--- 8< In file P1.c -
double f1(x,y){
}
--- 8< In file P2.c -
void f2(x,y,z){
double result;
result = f1(x,y);
}
Thanks
Christophe
__
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] gc() reports bytes (MB) but uses notation for bits (Mb)
I am not a standards expert, but the notation here seems incorrect to me: > gc() used (Mb) gc trigger (Mb) max used (Mb) Ncells 138668 7.5 650970 34.8 492193 26.3 Vcells 6668566 50.9 18582019 141.8 17001419 129.8 In the IEEE 1541-2002 document ( http://en.wikipedia.org/wiki/IEEE_1541-2002) the recommended notation for bytes is a capital B, whereas bits is either a lower case "b", (or "bits" per IEC 60027-2) Both documents, while possibly in disagreement as to the prefix (e.g. M vs. Mi) agree that B is for bytes. gc's output is commonly considered confusing, or at least not overly obvious to many, but the notational confusion surely can't help. Additional link: http://physics.nist.gov/cuu/Units/binary.html Thanks, Jeff -- Jeffrey Ryan jeffrey.r...@insightalgo.com ia: insight algorithmics www.insightalgo.com [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] ranges and contiguity checking
Providing the wrapper would allow for both performance as well as
user-simplicity.
x[RANGE(1,1e6)] and x[1:1e6] could both be handled internally, where:
RANGE <- function(from,to) {
structure(seq(from,to), class="RANGE")
}
Just testing for a 'RANGE' object in your [. method would let the
optimization be up to the end user.
The 'xts' package provides something similar with respect to subsetting by
time. We accept a character string conforming to ISO8601 style time ranges,
as well as standard classes that would be available to subset any other
matrix-like object.
The ISO way will get you fast binary searching over the time-index, whereas
using POSIX time is a linear search.
HTH
Jeff
On Wed, May 12, 2010 at 3:27 PM, James Bullard wrote:
> >> -Original Message-
> >> From: r-devel-boun...@r-project.org
> >> [mailto:r-devel-boun...@r-project.org] On Behalf Of Duncan Murdoch
> >> Sent: Wednesday, May 12, 2010 11:35 AM
> >> To: bull...@stat.berkeley.edu
> >> Cc: r-de...@stat.math.ethz.ch
> >> Subject: Re: [Rd] ranges and contiguity checking
> >>
> >> On 12/05/2010 2:18 PM, James Bullard wrote:
> >> > Hi All,
> >> >
> >> > I am interfacing to some C libraries (hdf5) and I have
> >> methods defined for
> >> > '[', these methods do hyperslab selection, however, currently I am
> >> > limiting slab selection to contiguous blocks, i.e., things
> >> defined like:
> >> > i:(i+k). I don't do any contiguity checking at this point,
> >> I just grab the
> >> > max and min of the range and them potentially do an
> >> in-memory subselection
> >> > which is what I am definitely trying to avoid. Besides
> >> using deparse, I
> >> > can't see anyway to figure out that these things (i:(i+k)
> >> and c(i, i+1,
> >> > ..., i+k)) are different.
> >> >
> >> > I have always liked how 1:10 was a valid expression in R
> >> (as opposed to
> >> > python where it is not by itself.), however I'd somehow
> >> like to know that
> >> > the thing was contiguous range without examining the un-evaluated
> >> > expression or worse, all(diff(i:(i+k)) == 1)
> >
> > You could define a sequence class, say 'hfcSeq'
> > and insist that the indices given to [.hfc are
> > hfcSeq objects. E.g., instead of
> > hcf[i:(i+k)]
> > the user would use
> > hcf[hfcSeq(i,i+k)]
> > or
> > index <- hcfSeq(i,i+k)
> > hcf[index]
> > max, min, and range methods for hcfSeq
> > would just inspect one or both of its
> > elements.
>
> I could do this, but I wanted it to not matter to the user whether or not
> they were dealing with a HDF5Dataset or a plain-old matrix.
>
> It seems like I cannot define methods on: ':'. If I could do that then I
> could implement an immutable 'range' class which would be good, but then
> I'd have to also implement: '['(matrix, range) -- which would be easy, but
> still more work than I wanted to do.
>
> I guess I was thinking that there is some inherent value in an immutable
> native range type which is constant in time and memory for construction.
> Then I could define methods on '['(matrix, range) and '['(matrix,
> integer). I'm pretty confident this is more less what is happening in the
> IRanges package in Bioconductor, but (maybe for the lack of support for
> setting methods on ':') it is happening in a way that makes things very
> non-transparent to a user. As it stands, I can optimize for performance by
> using a IRange-type wrapper or I can optimize for code-clarity by killing
> performance.
>
> thanks again, jim
>
>
>
>
>
> >
> > Bill Dunlap
> > Spotfire, TIBCO Software
> > wdunlap tibco.com
> >
> >>
> >> You can implement all(diff(x) == 1) more efficiently in C,
> >> but I don't
> >> see how you could hope to do any better than that without
> >> putting very
> >> un-R-like restrictions on your code. Do you really want to say that
> >>
> >> A[i:(i+k)]
> >>
> >> is legal, but
> >>
> >> x <- i:(i+k)
> >> A[x]
> >>
> >> is not? That will be very confusing for your users. The problem is
> >> that objects don't remember where they came from, only arguments to
> >> functions do, and functions that make use of this fact mainly
> >> do it for
> >> decorating the output (nice labels in plots) or making error messages
> >> more intelligible.
> >>
> >> Duncan Murdoch
> >>
> >> __
> >> 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
>
--
Jeffrey Ryan
jeffrey.r...@insightalgo.com
ia: insight algorithmics
www.insightalgo.com
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Restrict access to variables in parent environment
This isn't like a local variable though, since any function above the
baseenv() in the search path will also not be found.
> f
function(a) { rnorm(b) }
> f()
Error in f() : could not find function "rnorm"
Jeff
On Fri, May 14, 2010 at 9:20 AM, Hadley Wickham wrote:
> > Hello All,
> >
> > By default, a reference of a variable in a function cause R to look
> > for the variable in the parent environment if it is not available in
> > the current environment (without generating any errors or warnings).
> > I'm wondering if there is a way to revert this behaviors, such that it
> > will not look for the parent environment and will generate an error if
> > the variable is not available in the current environment. Is this
> > tuning has to be done at the C level?
>
> Try this:
> b <- 1
> f <- function(a) {
> b
> }
>
> environment(f) <- baseenv()
> f()
>
> Hadley
>
> --
> Assistant Professor / Dobelman Family Junior Chair
> Department of Statistics / Rice University
> http://had.co.nz/
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Jeffrey Ryan
jeffrey.r...@insightalgo.com
ia: insight algorithmics
www.insightalgo.com
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] segfault on 2.11.0 with large POSIXct vector using as.character
Running "as.character" on a large POSIXct causes a segfault on my 2.11 (2010-04-22) install. Seems to crash at around 9e4 ... on OSX and Ubuntu at least. > invisible(as.character(Sys.time()+1:7e4)) > invisible(as.character(Sys.time()+1:8e4)) > invisible(as.character(Sys.time()+1:9e4)) Error: segfault from C stack overflow > invisible(as.character(Sys.time()+1:5e5)) Error: segfault from C stack overflow Thanks, Jeff > sessionInfo() R version 2.11.0 (2010-04-22) x86_64-apple-darwin10.2.0 locale: [1] en_US.UTF-8/en_US.UTF-8/C/C/en_US.UTF-8/en_US.UTF-8 attached base packages: [1] stats graphics grDevices utils datasets methods base > sessionInfo() R version 2.11.0 (2010-04-22) i486-pc-linux-gnu locale: [1] LC_CTYPE=en_US.utf8 LC_NUMERIC=C [3] LC_TIME=en_US.utf8LC_COLLATE=en_US.utf8 [5] LC_MONETARY=C LC_MESSAGES=en_US.utf8 [7] LC_PAPER=en_US.utf8 LC_NAME=C [9] LC_ADDRESS=C LC_TELEPHONE=C [11] LC_MEASUREMENT=en_US.utf8 LC_IDENTIFICATION=C attached base packages: [1] stats graphics grDevices utils datasets methods base > -- Jeffrey Ryan jeffrey.r...@insightalgo.com ia: insight algorithmics www.insightalgo.com [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] segfault on 2.11.0 with large POSIXct vector using as.character
> > > This has been fixed for a while in R-patched. The 2.11.1 release on Monday > should be fine. > Apparently people aren't running the betas/release candidates. You really > should run the test versions to flush out bugs. If you'd run the > pre-release versions of 2.11.0, this bug would likely have been found before > release. The standard tests can miss things; the advantage of open source > is there are many eyes looking for bugs. But if those eyes are closed, the > model doesn't work. > I'd say it does work, and did. As far as catching before release, that sounds great, as great as having no bugs. I am not too sure that my tests could have caught a bug that the got passed the R tests though, so passing along a segfault issue to those who might know the source better seemed prudent -- even if I could only have the time to test against the released version. Thanks for the fix! Jeff > Duncan Murdoch > > >> >>> invisible(as.character(Sys.time()+1:7e4)) >>> invisible(as.character(Sys.time()+1:8e4)) >>> invisible(as.character(Sys.time()+1:9e4)) >>> >>> >> Error: segfault from C stack overflow >> >> >> >> >>> invisible(as.character(Sys.time()+1:5e5)) >>> >>> >> Error: segfault from C stack overflow >> >> Thanks, >> Jeff >> >> >> >>> sessionInfo() >>> >>> >> R version 2.11.0 (2010-04-22) >> x86_64-apple-darwin10.2.0 >> >> locale: >> [1] en_US.UTF-8/en_US.UTF-8/C/C/en_US.UTF-8/en_US.UTF-8 >> >> attached base packages: >> [1] stats graphics grDevices utils datasets methods base >> >> >> >> >>> sessionInfo() >>> >>> >> R version 2.11.0 (2010-04-22) >> i486-pc-linux-gnu >> >> locale: >> [1] LC_CTYPE=en_US.utf8 LC_NUMERIC=C >> [3] LC_TIME=en_US.utf8LC_COLLATE=en_US.utf8 >> [5] LC_MONETARY=C LC_MESSAGES=en_US.utf8 >> [7] LC_PAPER=en_US.utf8 LC_NAME=C >> [9] LC_ADDRESS=C LC_TELEPHONE=C >> [11] LC_MEASUREMENT=en_US.utf8 LC_IDENTIFICATION=C >> >> attached base packages: >> [1] stats graphics grDevices utils datasets methods base >> >> >> > > -- Jeffrey Ryan jeffrey.r...@insightalgo.com ia: insight algorithmics www.insightalgo.com [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] as.Date.numeric origin default
R-devel, I would like to second Gabor Grothendieck's request from September ( http://www.nabble.com/as.Date.numeric-to12962733.html#a12962733 ) on adding a default value (1970-01-01) to the origin argument of as.Date.numeric. I realize there is good reason to allow for origin to be specified, but I don't see why it must be up to the user at each and every invocation if most (if not all) users will simply be using 1970-01-01. My first contact was building quantmod for CRAN - many more hidden errors occur as I test on R-devel. It just seems to me to be an easy compromise to what will undoubtedly cost many hours of debugging across all packages/users. Thank you for your consideration, Jeff Ryan __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] numbers after dot missing (PR#10663)
YOU can fix the "problem" : ) Try: > identical(76079320.32 + 21374.27 + 7630.04 + 28432.47,76136757.1) [1] TRUE > identical(76079320.32 + 21374.27 + 7630.04 + 28432.47,76136757) [1] FALSE > options(digits=10) > 76079320.32 + 21374.27 + 7630.04 + 28432.47 [1] 76136757.1 > sessionInfo() R version 2.7.0 Under development (unstable) (2007-12-25 r43783) i386-apple-darwin8.11.1 locale: C attached base packages: [1] graphics grDevices utils datasets stats methods base other attached packages: [1] quantmod_0.3-2 Defaults_1.1-1 xts_0.0-6 zoo_1.4-1 loaded via a namespace (and not attached): [1] grid_2.7.0 lattice_0.17-2 rpart_3.1-36 > On Jan 30, 2008 1:45 AM, <[EMAIL PROTECTED]> wrote: > Full_Name: Michael > Version: 2.6.1 > OS: Windows XP > Submission from: (NULL) (81.223.30.219) > > > i recognized a problem with the numbers behind a dot, an example: > > 76079320.32+21374.27+7630.04+28432.47 > [1] 76136757 // should be 76,136,757.10 > > > 32+27+4+47 // proof it should be xxx.1 > [1] 110 > > that kind of problem happened more than 1 time > > hope u can fix it :) > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- There's a way to do it better - find it. Thomas A. Edison __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Routine and Deep testing with R CMD check
A combination of RUnit from CRAN and .Rbuildignore provide a workable solution for the 'xts' package I work on, though this obviously removes the tests from the distributed code. http://cran.r-project.org/web/packages/RUnit/index.html --and-- http://wiki.r-project.org/rwiki/doku.php?id=developers:runit Jeff On Wed, Jun 11, 2008 at 10:05 AM, Kevin R. Coombes <[EMAIL PROTECTED]> wrote: > Hi, > > I recently provoked some discussion over on the BioConductor developer list > about testing and R CMD check. In brief, the salient points that arose from > the discussion are: > > [1] Because of the need for a nightly build of BioConductor, the tests (in > the ./tests directory) of a package that run routinely as part of "R CMD > check" must complete in five minutes. > [2] Nontrivial regression testing of complex algorithms on real data can > easily take longer than five minutes. > [3] Maintaining and improving code that works on various kinds of "omics" > data is greatly facilitated by the inclusion of nontrivial regression tests. > > Of course, points [1] and [3] are incompatible in the current setup. Both > could, however, be accommodated by changing the way "R CMD check" runs test > scripts. There are at least two ways this could be accomplished. > > One possibility would be to define a separate directory as part of the > package structure to store the more complex, longer, "deep" tests. That is, > one might have >package/R >package/man >package/tests >package/deeptests [or some better name] > Then the default for "R CMD check" would be to run all the .R scripts in > tests but none of the .R scripts in deep tests. However, one would also have > to add an option, perhaps something like >R CMD check --run-deeptests [package] > to run the more elaborate test scripts. > > The second possibility would be to keep all the tests in the same (existing > ./tests) directory but include a standard file in that directory to indicate > which scripts are more complex. This would be a little trickier to design, > since it would be nice to keep the existing behavior for someone who ignores > the new structure. One, could however, allow for something like > > > ## CONTROLTESTS > > complex: test1.R, test3.R > simple: test2.R, test4.R > - > > The default (in the absence of A CONTROLTESTS file or for scripts in the > directory that are not listed in the file) is to assume "simple", which > would then get the existing behavior without changes to existing packages. > > How hard would it be to implement one of these approaches for R CMD check? > > -- Kevin > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- There's a way to do it better - find it. Thomas A. Edison __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Passing method to returns() /fSeries (PR#12713)
This is a concern of the package maintainer. Nothing to do with
R-devel or R-bugs.
See the Rmetrics site or fSeries package details for their contact information.
Jeff
On Fri, Sep 5, 2008 at 10:05 AM, <[EMAIL PROTECTED]> wrote:
> Full_Name: Robert Iquiapaza
> Version: 2.7.2
> OS: Vista
> Submission from: (NULL) (69.127.35.170)
>
>
> In the help Examples for returns(fSeries) it is said that you can pass the
> method to compute ("continuous", "discrete", "compound", "simple") returns
> using
> 'type='
> i.e.
> # Discrete Returns:
> returns(MSFT, type = "discrete")
> However when you use 'type' it does compute always the continuous returns, no
> matter what method you select.
> The only way to get the discrete returns is using 'method=' instead
> i.e
> # Discrete Returns:
> returns(MSFT, method = "discrete")
> I think the help and pdf documentation need to be updated
>
> Robert
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Jeffrey Ryan
[EMAIL PROTECTED]
ia: insight algorithmics
www.insightalgo.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Dates in C api
If you are looking for examples of handling dates/times (specifically
POSIXct) within C code, the dev branch of xts has quite a bit of code
now.
http://r-forge.r-project.org/plugins/scmsvn/viewcvs.php/dev/pkg/src/?root=xts
Assigning the class (or any attribute) within the C code will be much
faster than doing it outside of C, at least in my experience with
larger data.
setAttrib(ans, R_ClassSymbol, mkString("Date"))
HTH
Jeff
On Wed, Sep 17, 2008 at 12:24 PM, Lee, Philip (IT)
<[EMAIL PROTECTED]> wrote:
> r-devel,
>
> I've been trying to write a C plugin for R, and I'm struggling to
> understand how dates are represented.
>
> I can create a date in R:
>> mydate<-as.Date(1, origin="1900-01-01") mydate
> [1] "1900-01-02"
>
> When I pass my date to a plugin, though, it's type is that of a real.
> There doesn't seem to be a date type in Rinternals.h, is there a way to
> recognize that a value is a date rather than a real?
>
> Equally, does anyone know if it's possible to create date values in the
> C api?
>
> Thanks,
> Phil Lee
>
> Philip Lee
> Morgan Stanley | Technology
> 750 Seventh Avenue, 12th Floor | New York, NY 10019
> [EMAIL PROTECTED]
>
>
> NOTICE: If received in error, please destroy and notify sender. Sender does
> not intend to waive confidentiality or privilege. Use of this email is
> prohibited when received in error.
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Jeffrey Ryan
[EMAIL PROTECTED]
ia: insight algorithmics
www.insightalgo.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] conditionally import a namespace?
Or something along the lines of:
Suggests: RGtk2
f <- function (x, ...)
{
stopifnot("package:RGtk2" %in% search() || require("RGtk2", quietly = TRUE))
# do Rgtk2 stuff here
}
Jeff
On Thu, Oct 30, 2008 at 9:15 AM, Martin Maechler
<[EMAIL PROTECTED]> wrote:
>>>>>> "FA" == Felix Andrews <[EMAIL PROTECTED]>
>>>>>> on Thu, 30 Oct 2008 17:40:17 +1100 writes:
>
>FA> Dear R-devel,
>FA> I have a problem defining the dependencies for a package.
>
>FA> My package (latticist, not yet released) "Suggests" RGtk2, but
>FA> specifically does not require it. If RGtk2 is available, the user can
>FA> call a function that builds a GUI with RGtk2. However, I do not want
>FA> to attach the RGtk2 namespace, because it is irrelevant to the user
>FA> and exports about 7500 symbols.
>
>FA> Last time I asked a similar question to this, Professor Ripley noted
>FA> that the usual method to get around this situation is the use an
>FA> explicit package prefix to function calls (the `::` operator). But
>FA> this is not so easy with non-standard functions. Take this chunk of
>FA> code:
>
>FA> widg <- gtkComboBoxEntryNewText()
>FA> widg$show()
>FA> widg["width-request"] <- 100
>
>FA> The first call is easy to prefix, as RGtk2::gtkComboBoxEntryNewText()
>FA> but the others, `$.RGtkObject` and `[<-.RGtkObject` are not.
>
> indeed.
>
>FA> While I *could* rewrite all the code to use explicit functions, I
>FA> think, the resulting code would be much less clear.
>
>FA> Essentially what I want to do is conditionally import the RGtk2
> namespace.
>FA> Any suggestions?
>
> Maybe something along the line of
>
> if(is.function(try(RGtk2::gtkComboBoxEntryNewText))) {
> library(RGtk2)
>
>
> }
>
> ??
>
> Regards,
> Martin
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Jeffrey Ryan
[EMAIL PROTECTED]
ia: insight algorithmics
www.insightalgo.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] .C(..., DUP=FALSE) memory costs depending on input size?
Marcel,
If you are writing the C code from scratch, take a look at either
.Call or .External, as both make no copies of the input objects, and
require no explicit conversion to the underlying storage type
(numeric/integer/etc) within the function call.
An even greater benefit is that you will also have access to the
actual R objects within C.
Jeff
On Thu, Nov 6, 2008 at 2:05 PM, MarcelK <[EMAIL PROTECTED]> wrote:
>
> Hello,
>
> I'm trying to create my own C code for use within R. While optimizing the
> code I've noticed that even while only using pointers to get my data to C
> the time needed still depends on data (vector) size.
>
> To test this, I've created an empty C function to which I've send vectors
> containing various sizes of elements. The time needed for each call is
> measured and plotted. I would expect a flat line (a little above y=0) since
> the only thing send are pointers. What I do not expect is to see a linear
> climbing line when the vector size increases. Initializing the vectors isn't
> being measured, only the '.C' call to an empty C function, see below.
>
> Is there anything I'm missing that can explain this input-size dependent
> latency? The only reason I can think of is that these vectors are being
> copied along the way.
>
> What follows is both the R and C code which I use only for testing and a
> plot of both measurements with DUP=TRUE and DUP=FALSE:
>
> (RED: DUP=FALSE, GREEN: DUP=TRUE)
> http://www.nabble.com/file/p20368695/CandR.png
>
>
> R code:
> --
> # sequence from 512 to 2^23 with 2^17 stepsize
> a <- seq(512, 2^23, 2^17)
> # storage for wall time
> h <- length(a); j <- length(a)
> for (i in 1:length(a)) {
>x <- as.double(1:a[i])
>y <- as.double(x)
># system.time()[3] is (actual) wall time
>h[i] <- system.time(.C("commTest", x, y, DUP=FALSE))[3]
>j[i] <- system.time(.C("commTest", x, y, DUP=TRUE))[3]
>x <- 0
>y <- 0
> }
> # plot:
> plot(a, h, type="l", col="red", xlab="Vector Size -->", ylab="Time in
> Seconds -->"); lines(a, j, col="green")
>
>
> C code:
> ---
> #include
> extern "C" {
>void commTest(double* a, double* b);
> }
>
> /*
> * Empty function
> * Just testing communication costs between R --> C
> */
> void commTest(double* a, double* b) {
> /* Do ab-so-lute-ly-nothing.. */
> }
>
> System Details:
> -
> Linux gpu 2.6.18-6-amd64 #1 SMP Thu May 8 06:49:39 UTC 2008 x86_64 GNU/Linux
> R version 2.7.1 (2008-06-23)
> --
> View this message in context:
> http://www.nabble.com/.C%28...%2C-DUP%3DFALSE%29-memory-costs-depending-on-input-size--tp20368695p20368695.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
>
--
Jeffrey Ryan
[EMAIL PROTECTED]
ia: insight algorithmics
www.insightalgo.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Dynamic linking to binary code from other packages??
Charles,
> I've looked through the "Writing R Extensions" manual, and can't find
> this documented very clearly. A previous question to the list gave me
> the very kind response pasted below. I've looked at the suggested
> examples (lme4 using C functions from Matrix).
It isn't really "clearly" explained. I will give it a try though.
You can't use compiled/packaged functions from within _your_ compiled
code unless the package that you are referring to (affxparser) makes
them available for export.
If affxparser doesn't do this you are back to Dirk's method.
For the sake of others who have gone down this road I will explain
what I know, and probably in the process learn what I may be doing
wrong. (all of this I learned by reading the sources for R and lme4
and Matrix).
Matrix has a copy of the Matrix.h header in its /inst directory,
specifically /inst/include/Matrix.h
This gets installed as /include/Matrix.h, which is where LinkingTo
links to during compilation.
You (or the affxparser author) will also need a handful of C calls
that are complementary to ones in the package you are getting the
functions from.
An example from Matrix:
/include/Matrix_stubs.c contains
...
CHM_DN attribute_hidden
M_as_cholmod_dense(CHM_DN ans, SEXP x)
{
static CHM_DN(*fun)(CHM_DN,SEXP) = NULL;
if(fun == NULL)
fun = (CHM_DN(*)(CHM_DN,SEXP))
R_GetCCallable("Matrix", "as_cholmod_dense");
return fun(ans, x);
}
...
The above is far from obvious, so I will try my best to explain.
With respect to the R_GetCCallable call, Writing R Extensions says:
" p_myCfun = R_GetCCallable("packA", "myCfun");
The author of packB is responsible for ensuring that p_myCfun has an
appropriate declaration. What exactly that means was hard to determine
at first."
Taking the first line, the first CHM_DN is the function return type
(could be int, SEXP, etc), and the second (along with the SEXP) is the
argument type(s).
Generalized you'd have something like:
SEXP attribute_hidden
FUNNAME(SEXP ans, SEXP x)
{
static SEXP(*fun)(SEXP,SEXP) = NULL;
if(fun == NULL)
fun = (SEXP(*)(SEXP,SEXP))
R_GetCCallable("PACKAGE", "FUNCTION");
return fun(ans, x);
}
lme4 then simply "#include"s this .c file in a file
/src/local_stubs.c, which is compiled right along side of the src code
in lme4.
At this point you can then use the functions that are
'exported/registered' as you would a C function defined in your own
package.
The other side of this is what the Matrix (affxparser?) package needs
to do. It needs a registration routine that specifically registers
the routines as callable using:
R_RegisterCCallable (which is documented in Writing R Extensions)
In Matrix this is in /src/init.c via a macro.
A simpler in-progress bit of code can be found in the /dev branch of
xts on R-forge. Take a look at
http://r-forge.r-project.org/scm/?group_id=118
/dev/src/init.c
/dev/inst/include/xts.h
/dev/inst/include/xts_stubs.c
As far as C++ goes, I would suspect the Matrix package again has all
the bits you are looking for.
HTH
Jeff
--
Jeffrey Ryan
[EMAIL PROTECTED]
ia: insight algorithmics
www.insightalgo.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem trying to download rimage package (second try)
You are receiving no reply to your request as you are asking a list for R package and core developers about a single package (1 of 1600+ on CRAN alone). 1) You should first try everything possible yourself to fix the problem, AND show your work... (as per posting rules) 2) Then contact the maintainer (as per posting rules). 3) Then ask R-help (not R-devel), and only then (if ever) as a last resort come here for general install questions. The package description to get you to step #2: http://cran.r-project.org/web/packages/rimage/index.html Jeff On Fri, Nov 14, 2008 at 5:34 PM, Shantanu D <[EMAIL PROTECTED]> wrote: > Hi, > There seems to have been some problem with posting my earlier message and am > providing a link to the problem I faced which is at > https://stat.ethz.ch/pipermail/r-devel/attachments/20081114/84972faf/attachment.pl > Any help would be appreciated as I need to use this package urgently and > also tried various other things without luck > Thanks > >[[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Jeffrey Ryan [EMAIL PROTECTED] ia: insight algorithmics www.insightalgo.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] reduce limit number of arguments in methods:::cbind
My 2c: The real issue for me is that this approach to handling S4 objects by altering R functions for the worse is incorrect. (by calling bind_activation) m <- matrix(1:2e6L) # 2 million obs > system.time(cbind(m,m)) user system elapsed 0.027 0.017 0.044 > methods:::bind_activation(TRUE) [1] FALSE # the additional overhead of cbind is now damaging to cbind S3 methods > system.time(cbind(m,m)) user system elapsed 0.043 0.034 0.077 [~175% of the original time] Wouldn't a better near-term approach involve writing S3 methods to dispatch on. > methods:::bind_activation(FALSE) > library(Matrix) > M <- Matrix(1:10) > cbind(M,M) M M [1,] ? ? > cbind.dgeMatrix <- function(..., deparse.level=1) methods:::cbind(..., > deparse.level=deparse.level) > cbind(M,M) 10 x 2 Matrix of class "dgeMatrix" [,1] [,2] [1,]11 [2,]22 [3,]33 [4,]44 [5,]55 [6,]66 [7,]77 [8,]88 [9,]99 [10,] 10 10 # this approach "does no harm" to regular S3 methods > system.time(cbind(m,m)) user system elapsed 0.028 0.017 0.045 Obviously this negates part of the S4 dispatch value, but that can be had by calling cbind2 directly. Jeff -- Jeffrey Ryan [EMAIL PROTECTED] ia: insight algorithmics www.insightalgo.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] any suggestions to deal with 'Argument list too long' for a R CMD check?
Never used, but I seem to recall that this was good for that: http://en.wikipedia.org/wiki/Xargs Jeff On Tue, Dec 9, 2008 at 3:13 PM, Whit Armstrong <[EMAIL PROTECTED]> wrote: > Since, gcc was using upwards of 2gb of ram to compile my package, I > just split all the functions into individual files. > > I guess I'm too clever for myself, because now I get hit with the > "Argument list too long" error. > > Is there a way to deal with this aside from writing my own configure > script (which could possibly feed the gcc commands one by one). > > -Whit > > RHEL 5 > [EMAIL PROTECTED] uname -a > Linux linuxsvr.kls.corp 2.6.18-92.1.18.el5 #1 SMP Wed Nov 5 09:00:19 > EST 2008 x86_64 x86_64 x86_64 GNU/Linux > > from 00install.out: > > * Installing *source* package 'RFincad' ... > ** libs > g++ -I/usr/local/lib64/R/include -I/usr/local/include > -I./RAbstraction -I./R.tslib.backend -I./tslib -fpic -g -O2 -c > aaAccrual_days_act252.cpp -o aaAccrual_days_act2\ > 52.o > make: execvp: g++: Argument list too long > make: *** [aaAccrual_days_act252.o] Error 127 > ERROR: compilation failed for package 'RFincad' > ** Removing > '/home/whit/dvl/fincad.utils/fincad.generate.R/RFincad.Rcheck/RFincad' > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Jeffrey Ryan [EMAIL PROTECTED] ia: insight algorithmics www.insightalgo.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] package development
.
>
> In my experience there are two differ sorts of problems that I think could
> benefit from some improvement. The first is that there should be a standard
> way to have extra tests, that do not get run in the normal CRAN testing
> cycle, or by developers when using a "quick" R CMD check, but can be run
> with a standard mechanism. I do this by putting the tests in a separate
> package, and I have seen reports of different mechanisms, but I think they
> are all somewhat ad hoc. Currently, if you put too much testing in your
> package then all the testing gets omitted on some CRAN testing platforms.
> Just a common directory like extraTests/ would be a good start.
>
> The second problem is that a developer usually needs to run tests/ when code
> in R/ has been changed, but probably not run tests/ when the changes are
> only in man/, demos/, or inst/doc/. The checking that needs to be done in
> those cases is reduced from the full R CMD check. A common way to attack
> this is with a good Makefile. I wrote an article in R News a few years ago
> about my attempts to do this, and my Makefiles are available, but there is
> some customization necessary, and there is lots of room for improvement. It
> does (mostly) work with make -j, so days of testing on a single processor
> machine can be accomplished in a few hours on multicore machines (for me,
> mileage may vary). I have not addressed the idea of trying to specialize
> files in tests/ to specific code files in R/. (I think others have tried to
> do this with a "unit testing" approach.)
>
> Paul Gilbert
>
>> I find the process I follow is to organize the files in the distribution
>> structure from the beginning. When adding new functions, I'll generally
>> use source() a few times to get the syntax right, and perhaps run simple
>> tests. (But remember, if you use a NAMESPACE, the functions may not behave
>> the same when they're sourced into the global environment.) In the early
>> stages, I'll do a lot of installs of the packages.
>>
>> If I was porting a big package and wanted to find syntax errors, to work
>> around the not-very-helpful error message you saw I'd do something like
>>
>> for (f in list.files("pkg/R", full=TRUE)) source(f)
>>
>> which will report the error more informatively.
>>
>> Duncan Murdoch
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
>
> La version française suit le texte anglais.
>
>
>
> This email may contain privileged and/or confidential in...{{dropped:26}}
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Jeffrey Ryan
jeffrey.r...@insightalgo.com
ia: insight algorithmics
www.insightalgo.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] package development
I think the /tmp file gets removed: ERROR: lazy loading failed for package 'xts' ** Removing '/private/tmp/Rinst625532301/xts' ERROR Installation failed. Removing '/tmp/Rinst625532301' At least it seems to when I run R CMD from the shell. > > Yes, there are several options for not distributing tests. I was thinking > more about how to distribute them with a simple mechanism for anyone to run > them, but in a way that they are not run by the usual R CMD check. > You can still distribute the tests in the inst/unitTests directory, you would just have to make sure that the calling script in the /tests directory is commented out. Alternately you could have that /tests/doRUnit.R script (or whatever you call it/them) check for some environment variable to be set before running the full suite. Jeff __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] length of POSIXlt object (PR#13482)
Read the docs. POSIXlt is a list of 9 elements. Each element length is
what you think it should be returning. That is not correct.
?POSIXlt
Details:
There are two basic classes of date/times. Class '"POSIXct"'
represents the (signed) number of seconds since the beginning of
1970 as a numeric vector. Class '"POSIXlt"' is a named list of
vectors representing
> unclass(as.POSIXlt(as.POSIXlt('2007-01-01')+1:11))
$sec
[1] 1 2 3 4 5 6 7 8 9 10 11
$min
[1] 0 0 0 0 0 0 0 0 0 0 0
$hour
[1] 0 0 0 0 0 0 0 0 0 0 0
$mday
[1] 1 1 1 1 1 1 1 1 1 1 1
$mon
[1] 0 0 0 0 0 0 0 0 0 0 0
$year
[1] 107 107 107 107 107 107 107 107 107 107 107
$wday
[1] 1 1 1 1 1 1 1 1 1 1 1
$yday
[1] 0 0 0 0 0 0 0 0 0 0 0
$isdst
[1] 0 0 0 0 0 0 0 0 0 0 0
attr(,"tzone")
[1] """CST" "CDT"
Jeff
On Wed, Jan 28, 2009 at 4:15 PM, wrote:
> The length() of a POSIXlt object is given as 9 regardless of the actual
> length. For example:
>
>> make.date.time
> function (year=c(2006,2006),month=c(8,8),day=2:5,hour=13,minute=45)
> {# convert year, etc., into POSIXlt object
> #
> d=as.character(make.date(year,month,day))
> t=paste(hour,minute,sep=":")
> as.POSIXlt(paste(d,t))
> }
>> t=make.date.time()
>> t
> [1] "2006-08-02 13:45:00" "2006-08-03 13:45:00" "2006-08-04 13:45:00"
> [4] "2006-08-05 13:45:00"
>> length(t)
> [1] 9
>> t[1]
> [1] "2006-08-02 13:45:00"
>> length(t[1])
> [1] 9
>
>
>
> --
> blog.sethroberts.net
> www.shangriladiet.com
> boards.shangriladiet.com
> cell phone 510 418 7753 (Berkeley)
>
>[[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Jeffrey Ryan
jeffrey.r...@insightalgo.com
ia: insight algorithmics
www.insightalgo.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] POSIXlt, POSIXct, strptime, GMT and 1969-12-31 23:59:59
R-devel:
Some very inconsistent behavior, that I can't seem to find documented.
Sys.setenv(TZ="GMT")
str(unclass(strptime("1969-12-31 23:59:59","%Y-%m-%d %H:%M:%S")))
List of 9
$ sec : num 59
$ min : int 59
$ hour : int 23
$ mday : int 31
$ mon : int 11
$ year : int 69
$ wday : int 3
$ yday : int 364
$ isdst: int 0
- attr(*, "tzone")= chr "GMT"
# setting to 59 seconds now reports 0
str(unclass(as.POSIXlt("1969-12-31 23:59:59")))
List of 9
$ sec : num 0
$ min : int 59
$ hour : int 23
$ mday : int 31
$ mon : int 11
$ year : int 69
$ wday : int 3
$ yday : int 364
$ isdst: int 0
- attr(*, "tzone")= chr "GMT"
>
Setting the secs in the string to 58 returns a correct structure:
str(unclass(as.POSIXlt("1969-12-31 23:59:58")))
List of 9
$ sec : num 58
$ min : int 59
$ hour : int 23
$ mday : int 31
$ mon : int 11
$ year : int 69
$ wday : int 3
$ yday : int 364
$ isdst: int 0
- attr(*, "tzone")= chr "GMT"
Some additional strangeness occurs once as.POSIXct is called:
str(as.POSIXct(as.POSIXlt("1969-12-31 23:59:58")))
POSIXct[1:1], format: "1969-12-31 23:59:58"
# this incorrectly ignores the secs
str(as.POSIXct(as.POSIXlt("1969-12-31 23:59:59")))
POSIXct[1:1], format: "1969-12-31 23:59:00"
# this should be -1, if I am not mistaken
str(as.POSIXct(strptime("1969-12-31 23:59:59","%Y-%m-%d %H:%M:%S")))
POSIXct[1:1], format: NA
According to ?strptime NA should be returned if the time doesn't
exist. As far as I can tell, 1969-12-31 23:59:59 does exists.
Using a simple C program (source follows this message):
[veblen:~/Rforge/xts] jryan% ./a.out
Date as tm struct (POSIXlt):1969-12-31 23:59:59
sec: 59
min: 59
hour: 23
mday: 31
mon: 11
year: 69
wday: 3
yday: 364
seconds since the Epoch: -1
Which gives the -1. This is all run on a Intel Mac, though has been
tested on FreeBSD and Ubuntu as well with the same outcome. It does
seem to work fine on Windows though. I think the workaround for
Windows is what is causing the failure elsewhere.
As far as I can see, the code that is causing this is do_asPOSIXct in
datetime.c:
695 if(!R_FINITE(secs) || tm.tm_min == NA_INTEGER ||
696tm.tm_hour == NA_INTEGER || tm.tm_mday == NA_INTEGER ||
697tm.tm_mon == NA_INTEGER || tm.tm_year == NA_INTEGER)
698 REAL(ans)[i] = NA_REAL;
699 else {
700 errno = 0;
701 tmp = mktime0(&tm, 1 - isgmt);
702 #ifdef MKTIME_SETS_ERRNO
703 REAL(ans)[i] = errno ? NA_REAL : tmp + (secs - fsecs);
704 #else
705 REAL(ans)[i] = (tmp == (double)(-1)) ?
706 NA_REAL : tmp + (secs - fsecs);
707 #endif
708 }
I haven't been able to look further into this logic, but the test for
-1 strikes me as where this is happening.
Thank you for any insight you can provide.
Jeff
> sessionInfo()
R version 2.9.0 Under development (unstable) (2009-02-27 r48020)
i386-apple-darwin8.11.1
locale:
C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
# C PROGRAM #
#include
#include
/*
code modified from:
http://www.opengroup.org/onlinepubs/009695399/functions/strptime.html
by Jeff Ryan
*/
struct tm tm;
time_t t;
int main()
{
char DATE[] = "1969-12-31 23:59:59";
printf("Date as tm struct (POSIXlt):%s\n", DATE);
strptime(DATE, "%Y-%m-%d %H:%M:%S", &tm);
tm.tm_isdst = -1; /* Not set by strptime(); tells mktime()
to determine whether daylight saving time
is in effect */
t = mktime(&tm);
printf(
" sec: %d\n"
" min: %d\n"
" hour: %d\n"
" mday: %d\n"
" mon: %d\n"
" year: %d\n"
" wday: %d\n"
" yday: %d\n",
tm.tm_sec,
tm.tm_min,
tm.tm_hour,
tm.tm_mday,
tm.tm_mon,
tm.tm_year,
tm.tm_wday,
tm.tm_yday);
printf("seconds since the Epoch: %d\n", t);
return 0;
}
--
Jeffrey Ryan
jeffrey.r...@insightalgo.com
ia: insight algorithmics
www.insightalgo.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
