Re: [Rd] lubridate does not install on FreeBSD any more
Am 11.01.2012 11:58 (UTC+1) schrieb Rainer Hurling: On 11.01.2012 11:32 (UTC+1), Uwe Ligges wrote: On 11.01.2012 11:13, Rainer Hurling wrote: With newest R devel #sessionInfo() R Under development (unstable) (2012-01-10 r58085) Platform: amd64-portbld-freebsd10.0 (64-bit) locale: [1] de_DE.ISO8859-15/de_DE.ISO8859-15/de_DE.ISO8859-15/C/de_DE.ISO8859-15/de_DE.ISO8859-15 attached base packages: [1] stats graphics grDevices utils datasets methods base I get the following error when I try to build and install lubridate from sources on FreeBSD 10.0-CURRENT (amd64): #R CMD INSTALL lubridate_0.2.6.tar.gz * installing to library '/usr/local/lib/R/library' * installing *source* package 'lubridate' ... ** package 'lubridate' successfully unpacked and MD5 sums checked ** R ** data ** moving datasets to lazyload DB ** inst ** preparing package for lazy loading ** help *** installing help indices ** building package indices ** testing if installed package can be loaded During startup - Warning messages: 1: Setting LC_CTYPE failed, using C 2: Setting LC_TIME failed, using C 3: Setting LC_MESSAGES failed, using C 4: Setting LC_PAPER failed, using C Error : .onLoad failed in loadNamespace() for 'lubridate', details: call: utils::assignInNamespace(+.Date, add_dates, base) error: locked binding of '+.Date' cannot be changed Error: loading failed Execution halted ERROR: loading failed * removing '/usr/local/lib/R/library/lubridate' * restoring previous '/usr/local/lib/R/library/lubridate' Do you have any idea what is going on here? Yes: locked bindings cannot be changed in R-devel any more, and lubridate does that. The maintainer has been asked for an update already. Uwe Ligges Thanks in advance, Rainer Hurling Thanks, Uwe Ligges and Peter Dalgaard, for clarifying this. So we have to wait for an update ... Just for the record. With the new version 1.1.0 I am able to build and install lubridate on FreeBSD again. Thanks for the work, Rainer Hurling __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R tcltk Gui and Rpy2
I think I have it. I am using Tkinter and Rpy2. It seems to be working nicely. -- View this message in context: http://r.789695.n4.nabble.com/R-tcltk-Gui-and-Rpy2-tp4442989p4448848.html Sent from the R devel mailing list archive at Nabble.com. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Julia
There are many experts on this topic. I'll keep this short. Newer Fortran Languages allow for call by value, but call by reference is the typical and historically, the only approach (there was a time when you could change the value of 1 to 2!). C only calls by value except that the value can be a pointer! So, havoc is just a * away. I'm very pleased to be on this list and read the discussion. Thank you Douglas Bates for sending the first message. I like R and will continue to use it. However, I also think that strict call by value can get you into trouble, just trouble of a different kind. I'm not sure we will ever yearn for Julia ouR-Julia, but it is sure fun to think about what might be possible with this language. And having fun is one key objective. Nick Crookston 2012/3/5 oliver oli...@first.in-berlin.de: On Mon, Mar 05, 2012 at 03:58:59PM -0800, Hervé Pagès wrote: Hi Oliver, On 03/05/2012 09:08 AM, oliver wrote: On Mon, Mar 05, 2012 at 03:53:28PM +, William Dunlap wrote: I haven't used Julia yet, but from my quick reading of the docs it looks like arguments to functions are passed by reference and not by value, so functions can change their arguments. My recollection from when I first started using S (in the course of a job helping profs and grad students do statistical programming, c. 1983) is that not having to worry about in-place algorithms changing your data gave S a big advantage over Fortran or C. [...] C also uses Call-by-Value. C *only* uses Call-by-Value. [...] Yes, that's what I meant. With also I meant, that it uses call-by-value, as some other languages also do. 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
[Rd] Rserve compilation error
Hi, I am trying to install Rserve 1.7-0 on CentOS 6. But I get this compilation error - /usr/lib64/Revo-5.0/R-2.13.2/lib64/R/lib/libiomp5.so: undefined reference to `pthread_atfork' I tried other versions of Rserve (0.6-5 and 0.6-8) without any success. How do I get around this issue? My goal is to run FastRWeb (which uses Rserve). Thanks in advance. Joydeep. -- View this message in context: http://r.789695.n4.nabble.com/Rserve-compilation-error-tp4450774p4450774.html Sent from the R devel mailing list archive at Nabble.com. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Rserve compilation error
On 06/03/2012 18:08, jbanerjee wrote: Hi, I am trying to install Rserve 1.7-0 on CentOS 6. But I get this compilation error - /usr/lib64/Revo-5.0/R-2.13.2/lib64/R/lib/libiomp5.so: undefined reference to `pthread_atfork' I tried other versions of Rserve (0.6-5 and 0.6-8) without any success. How do I get around this issue? My goal is to run FastRWeb (which uses Rserve). That message is not from compilation (it is a linker message), and in any case comes from the (non-R-core) build of R you used. R as distributed does not have any such library in $R_HOME/lib, so I think you need to ask the people who built your R (presumably Revolution) for help. -- 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, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] .Internal(inspect(x)) gives overly verbose output for reference classes
Even for an extremely simple instance of a reference class x - setRefClass(x) y - x$new() calling the internal inspect function .Internal(inspect(y)) produces enough output that it takes several minutes to print to the console. (Actually I gave up and terminated the command after ~10 mins. It isn't clear whether the output would eventually complete.) Are reference classes really so complicated inside, or is this a bug? __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Julia
On Tue, Mar 6, 2012 at 3:56 AM, oliver oli...@first.in-berlin.de wrote: On Mon, Mar 05, 2012 at 04:54:05PM -0800, Nicholas Crookston wrote: There are many experts on this topic. I'll keep this short. Newer Fortran Languages allow for call by value, but call by reference is the typical and historically, the only approach (there was a time when you could change the value of 1 to 2!). Oh, strange. C only calls by value except that the value can be a pointer! So, havoc is just a * away. [...] For me there was no havoc at this point, but for others maybe. There are also other languages that only use call-by-value... ...functional languages are that way in principal. Nevertheless internally they may heavily use pointers and even if you have values that are large arrays for example, they internally just give a pointer to that data structure. (That's, why functional languages are not necessarily slow just because you act on large data and have no references in that language. (A common misunderstanding about functional languages must be slow because they have nor references.) The pointer-stuff is just hidden. Even they ((non-purely) functional languages) may have references, their concept of references is different. (See OCaml for example.) There you can use references to change values in place, but the reference itself is a functional value, and you will never have access to the pointer stuff directly. Hence no problems with mem-arithmetics and dangling pointer's or Null-pointers. [...] I like R and will continue to use it. However, I also think that strict call by value can get you into trouble, just trouble of a different kind. Can you elaborate more on this? What problems do you have in mind? And what kind of references do you have in mind? The C-like pointers or something like OCaml's ref's? OCaml refs are an escape hatch from the pure functional programming paradigm where nothing can be changed once given a value, an extreme form of pass-by-value. Similarly, most languages that are advertised as pass-by-value include some kind of escape hatch that permits you to work with pointers (or mutable vectors) for improved runtime performance. The speed issues arise for two main reasons: interpreting code is much slower than running machine code, and copying large data structures can be expensive. Pass-by-value semantics forces this to happen in many situations where the compiler/interpreter cannot safely optimize it away. Based on the video Julia manages the speed issue by viewing everything like a template, thus generating new methods based on type inference. This means there isn't a lot of runtime type checking for dispatch, because customized methods were already generated, but this can lead to another problem: code bloat. There are no free lunches. I'm not sure we will ever yearn for Julia ouR-Julia, but it is sure fun to think about what might be possible with this language. And having fun is one key objective. I have fun if things work. And if the tools do, what I want to achieve... ...and the fun is better, if they do it elegantly. Do you ask for references in R? And what kind of references do you have in mind, and why does it hurt you not to have them? Can you give examples, so that it's easier to see, whwere you miss something? Ciao, Oliver P.S.: The speed issue of R was coming up more than once; in some blog posts it was mentioned. would it make sense to start a seperated thread of it? In one of the blog-articles I read, it was mourned about how NA / missing values were handled, and that NA should maybe become thrown out, just to get higher speed. I would not like to have that. Handling NA as special case IMHO is a very good way. Don't remember if the article I have in mind just argued about HOW this was handled, or if it should be thrown out completely. Making the handling of it better and more performant I think is a good idea, ignoring NA IMHO is a bad idea. But maybe that really would be worth a seperate thread? __ 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] isGeneric() can return an error
Hi, I wonder if this is a feature or a bug: isGeneric() Error in genericForPrimitive(f) : methods may not be defined for primitive function ‘’ in this version of R isGeneric(:) Error in genericForPrimitive(f) : methods may not be defined for primitive function ‘:’ in this version of R According to the man page: ‘isGeneric’: Is there a function named ‘f’, and if so, is it a generic? So it sounds like it should be a YES or NO answer. In any case the error message is confusing: it suggests that I'm trying to define methods for , but I'm not. This is with R 2.13, R 2.14 and R 2.15.0 alpha. Thanks, H. -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M1-B514 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpa...@fhcrc.org Phone: (206) 667-5791 Fax:(206) 667-1319 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] .Internal(inspect(x)) gives overly verbose output for reference classes
On 12-03-07 10:37 AM, Duncan Murdoch wrote: On 12-03-07 9:52 AM, Richard Cotton wrote: Even for an extremely simple instance of a reference class x- setRefClass(x) y- x$new() calling the internal inspect function .Internal(inspect(y)) produces enough output that it takes several minutes to print to the console. (Actually I gave up and terminated the command after ~10 mins. It isn't clear whether the output would eventually complete.) Are reference classes really so complicated inside, or is this a bug? __ If you look at the output, you'll see it's looping. When I hit Esc, I saw that .self is an S4SXP with an attribute .xData which is an environment containing the same .self, ad infinitum. So I'd say it's a bug in inspect(). It can handle the case of an environment holding itself, but I think it was written before S4SXPs contained themselves, and it looks like it's not checking for that. I'll take a look if someone else doesn't get there first... There are a couple of optional arguments to inspect that let you avoid this infinite recursion, e.g. .Internal(inspect(y, 5)) will limit the recursion depth to 5, and that's sufficient for this example. It would be possible to put loop detection into the function, or default to a finite depth, but I'd rather not mess it up: keeping debugging aids simple but powerful seems like a good idea to me. You can always hit Esc to stop the display if it goes into a loop, then set a depth limit as above. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
